개발자 프로필

안녕하세요 프랙티컬(주) 대표 컨설턴트 & 개발자 박병일입니다. 축적된 IT 지식과 스타트업 컨설팅 및 개발 경험을 기반으로 프랙티컬한 솔루션을 제안하고 개발합니다.

Results-oriented software developer and research professional with 25 years experience in both development and research positions. I make it my goal to create software with the user in mind, creating applications with a useable and intuitive user interface experience. I also understand the importance of creating highly readable and easily maintainable source code. I am constantly striving to learn new technologies and look to ways to better myself in this rapidly changing industry.

보유기술

개발언어(최근 가장 많이 쓰고있는 언어순)

  • Java Script
    • Node.js
      • Vue.js
      • React.js
  • Objective-C
  • Swift
  • C++
    • OpenCV
  • SQL
  • Python
  • Go
  • Delphi(Object Pascal)

주로쓰는 개발툴

  • WebStorm – JS 개발툴
  • XCode – iOS앱 개발툴
  • Goland – Go 언어 개발툴
  • Pycharm – Phthon 개발툴
  • Delphi – Object Pascal(Windows Platform)

플랫폼

  • Mac & OSX – 주로쓰는 OS
  • Ubuntu – 주로쓰는 서버 OS
  • AWS – 주로 사용하는 Cloud

개발경험

기술 관련

  • Productivity(생산성)
    • 개발에 있어서 생산성은 20대때부터 개인적으로 고민해 오던 오래된 화두입니다. 아래에 나열된 기술목록들은 가능한 더 높은 생산성을 가진 도구를 찾기 위한 저의 노력의 과정이라고 할 수 있습니다. 적은 시간으로 더 좋은 결과를 얻게 된다면 비즈니스의 영역에서 비용을 줄일 수 있고 개발자 입장에서는 더 많은 시간을 확보할 수 있습니다. 시간을 어떻게 쓰는가는 개인의 역량 문제겠지만요.
  • iOS(iPhone)
    • 스티브잡스가 했던 첫번째 아이폰 프레젠테이션을 기억합니다. 제 개발자 인생의 전환점이었습니다. 2008년 가을 한국에서 아이폰을 살 수 없어서 아이팟과 맥미니를 바로 구입했고 아이폰 개발자의 길로 접어들었습니다.
  • Objective-C
    • Obj-C는 쉽지 않습니다. 하지만 확실히 직관적입니다. 이 언어를 배우기 위해 3개월을 두문불출하고 정진했습니다. 2009년 4월에 첫번째 앱을 앱스토어에 업로드했습니다. 개인적으로 앱 다운로드 기록은 [오늘의 명언]이 국내에서 누적 100만 다운로드 이상을 경험한 적이 있습니다. 이후 개인앱으로 앱스토어에 업로드한 앱 개수는 약 60여개입니다.
  • Swift
    • 개인적으로 늦게까지 Obj-C를 고수하고 있었습니다. 이유는 Swift 문법의 변화가 너무 심했고 컴파일 속도가 느린것도 한몫 했지요. 다만 최근 많은 안정화 과정을 거쳐서 성능도 좋아졌다는 판단이 서 BBuzzArt의 가장 최근 버전 앱에 도입하여 개발했습니다.
      • 간결한 코드를 유지하면서도 직관성을 유지하려는 Apple의 노력은 인정하지만 미래를 기대하는 것은 쉽지 않다는 개인적 생각입니다.
  • Native App & Hybrid App
    • Native App 개발을 오래 해왔지만 배포가 불편하다는 문제는 소프트웨어가 늘 변화해야만 한다는 명제와 상충합니다. 요구사항은 늘 변하고 빠르게 그 요구사항에 대응해야하지만 성능 역시 보장이 되어야 한다는 아이러니를 늘 안고 개발을 하게 됩니다.
      • 개인적인 경험에 비추어 본다면 어떤 선택을 해야 하는가는 어떤 서비스를 만들 것인가와 관계있습니다. 저는 그동안 컨텐츠 관련 비즈니스가 많았던 관계로 Native에서 Hybrid의 방향으로 계속해서 변화를 모색해왔으며, 2017년 React Native를 도입해서 iOS와 Android를 통합했고 2018년 iOS, Android, Web을 완전히 통합하는 서비스 개발을 마무리했습니다.
  • JavaScript
    • JavaScript의 중요성은 최근 수년간 하늘 높은줄 모르고 올라가고 있습니다. 과거 Jquery 기반의 DOM Controller에서 벗어나 Angular, React, Vue 등등 성공한 프레임워크들이 등장했으며 Node.js에 이르러 서버 개발에까지 손을 뻗치고 있습니다.
      • 특히 React Native는 iOS, Android를 넘어서 Oculus등 다른 플랫폼에 이식되면서 사용성을 늘리고 있습니다. 열심히 더 공부해야 합니다.
  • JQuery
    • 이젠 안씁니다. 아예~ 이말을 하고 싶었습니다. 제발 쓰지 맙시다.
  • AWS
    • 이제는 클라우드 없는 서비스는 생각할 수도 없습니다. 특별히 글로벌로 비즈니스 계획이 있다면 AWS의 선택은 필수적입니다.
      • 아래의 기능들과 연계하면 완전한 시너지를 낼 수 있습니다. 전부 서비스에서 사용해 봤습니다.
      • 지난 2년간 DDOS 때문에 느려진 적은 있었지만 장애가 난 적은 한번도 없었습니다. 너무 AWS 광고한 느낌이긴 하지만 스타트업에서 서비스 인프라에 신경쓰기 시작하면 끝이 없습니다 그돈으로..
      • AWS S3 Storage
      • 생각보다 비싸지 않습니다. 데이터 유실이나 백업 걱정 없이 운영 가능 합니다.
      • AWS CloudFront (CDN)
      • 글로벌 서비스라면 필수 항목입니다. 아카마이와 비교해도 성능이 떨어지지 않습니다.
      • AWS Lambda
      • 마이크로 서비스 구현하기 좋습니다. 아직 개발 생산성이 좋지 않습니다만 Alexa 연동 때문에 써봤습니다.
      • AWS ELB
      • 제 생각에 로드발란서에는 두가지 목적이 있습니다. 서비스 사용자의 폭주에 대비하여 트래픽을 분산하는 효과도 있지만 서버 업그레이드에도 굉장히 유용합니다. 로드발란서를 앞단에 놓고 서비스를 업데이트하면 중단 없이 업데이트를 진행할 수 있어, 낮에도 아무때나 서비스를 변경할 수 있습니다.
      • AWS RDS
      • RDS 기반으로 MySQL을 주로 사용했습니다. DB서버를 RDS를 사용한 이유는 역시 관리의 용이성과 안정성 때문입니다. 백업 걱정이 없고 데이터 유실의 걱정이 없습니다.
  • Google
    • Google Vision API
      • 이미지 컨텐츠가 많은 기업이라면 필수입니다.
      • 모든 기업들이 머신러닝 시스템을 개발하려고 애쓰고 있는데 머신러닝이 비즈니스의 목적이 아니라면 사서 쓰는게 이익이라고 생각합니다.
      • 많이 비싸지 않더군요.
      • https://bipark.github.io/3
    • Google Natural Language API(자연어분석)
      • 비전과 마찬가지로 텍스트 컨텐츠에 대하여 자연어를 머신러닝 방식으로 분석해줍니다. 문법, 문장의 감정, 키워드의 강도 등을 데이터로 뽑아줍니다.
      • 컨텐츠 업체에서 진짜로 해야 하는 머신러닝은 위의 두가지 결과를 기반으로 사용자의 Activity를 연결해서 경향성을 파악하는 용도로 개발하는 것이 가장 좋다고 생각합니다.
    • Google Firebase
      • 만약 서비스를 새로 개발하려고 한다면 추천해 드립니다.
      • 위에 AWS 인프라가 전혀(거의) 필요없습니다.
      • 서비스 개발을 위한 종합 선물세트입니다.
      • 이런게 있는데 왜 안쓰는지 모르겠습니다. 뭐.. 저도 일부만 써봤습니다.
    • Google GA
      • Google Analytics는 필수이지만 키워드와 이벤트를 적절히 사용하면 사용자와 이벤트를 잘 추적할 수 있습니다.
      • Google Tag Manager라는 것도 있는데 개발자 입장에서는 옥상옥 느낌입니다. 마케팅에서 이런 저런 요구를 하는데 그때그때 소스에 이벤트 추적 코드를 넣는게 귀찮습니다. 하지만 아직 뾰족한 방법을 못 찾았습니다.
  • Amazon Alexa
    • 보이스 컨트롤을 이용한 Canvas 컨텐츠 컨트롤을 위해 사용해 봤습니다.
      • 회원을 특정하기 위해서는 OAuth 시스템을 서비스 내에 갖추고 있어야 합니다.
      • 그것을 위해 OAuth를 개발하던 도중에 퇴사했습니다. ㅠ.ㅠ
  • Java Spring
    • 레거시가 있어서 어쩔 수 없이 썼습니다.
      • 하지만 큰 문제 없이 잘 돌아가더군요.
      • 사실 잘 모릅니다. 그래서 전문가를 뽑았습니다.
  • Web(HTML5)
    • React.js
      • 개인적으로는 2015년 부터 사용 경험이 있습니다.
      • 상태 관리를 위한 Redux 사용합니다.
      • 현재 가장 HOT한 프레임워크
      • 페이스북에서 개발하고 밀고 있어서 장기적인 확장 가능성이 높고 사용자가 많습니다.
      • React Native
      • React Framework를 기반으로 iOS, Android에서 Native 성능을 낼 수 있는 하이브리드 Framework
      • 최근 1년간 이 프레임워크를 이용하여 앱을 개발했습니다.
      • https://bipark.github.io/2
      • Next.js
      • React.js가 SPA(Single Page Application)라서 SSR이 안되는 문제를 해결하기 위해 사용되는 서버용 React 프레임워크
      • React.js로 개발할때 검색엔진 또는 소셜 공유를 위한 Bot에 대응하기 위해 사용합니다.
      • Vue.js
      • 최근 가장 떠오르는 Web UI Framework
      • 백오피스 프로젝트 및 스몰 토이 프로젝트에 다수 사용했습니다.
      • 개발이 용이하고, 상태관리가 React에 비해 쉬워서 빠른 구현을 할 수 있습니다.
      • Nuxt.js
      • Vue.js를 위한 SSR용 서버 프레임워크
  • SSR
    • 최근 SPA 기반으로 Web 서비스를 개발하게 됨에 따라 검색엔진 Bot이나 공유 엔진에 대응할 수 없는 문제를 해결하기 위해 개발되었습니다.
    • 검색엔진 & 소셜공유에 대응하기 위해서는 필수적으로 요구되는 기능입니다.
  • SEO
    • Search Engine Optimization
      • 마케팅 활동의 가장 중요한 진입점으로 검색엔진에 대한 대응은 매우 중요합니다.
      • 구글을 비롯한 검색엔진 그리고 소셜 네트워크 공유등에 대한 기술적 및 기능적 대응이 필요합니다.
      • SEO를 잘하면 마케팅 비용을 많이 줄일 수 있습니다.
      • 하지만 SEO는 단시간에 결과를 얻기 힘들고 조심스럽게 오래도록 Optimazation 하는 것이 좋습니다.
      • 블로그 참조 https://bipark.github.io/7
  • Facebook
    • 페이스북은 소셜뿐만이 아니라 프레임워크로 생각해야 합니다.
      • 고객의 유입, 추적, 분석 등의 유저 액티비티와 서비스 결합도를 높이는 쪽으로 개발을 진행하는 것이 좋습니다.
  • 분석, 모니터링
    • 개발 시점에서 Query 성능 분석을 통하여 향후 발생할 수 있는 병목을 미리 제거할 수 있어야 합니다.
      • 운영 상황에서의 실시간 성능 분석은 실제 상황에서 빠르게 대응방법을 찾아낼 수 있습니다.
      • Whatap.oi, Jennifer 등의 분석 서비스를 이용할 수 있습니다.

개인적인 기술

  • IoT 콤포넌트 장비에 관심이 많습니다.
  • 홈 자동화 시스템을 취미로 개발 하기도 했고 스마트 미러를 개발하기도 했습니다.
  • 영어능력
    • 기술문서를 읽고 해석할 수 있습니다.
      • 애플 WWDC, Google I/O등의 컨퍼런스 동영상을 자막없이 들을 수 있습니다.
      • 다수의 해외 출장 & 여행 경험이 있고 기초적인 커뮤니케이션이 가능하고 기술적 커뮤니케이션 역시 가능합니다.

스타트업을 위한 소프트웨어를 개발 합니다

스타트업을 위한 기술 컨설팅과 소프트웨어를 개발 하고 있습니다.

오랫동안 많은 스타트업과 함께 일한 경험을 기반으로 경험이 적은 스타트업에서 일어 날 수 있는 많은 시행 착오를 줄이고 가장 효율적이고 적은 비용으로 목표를 달성 할 수 있는 방법을 제시 합니다. 서비스 플랫폼, 개발도구, 업무의 효율성을 높일 수 있는 다양한 도구와 개발팀 구성, 리크루팅 까지 테크 비즈니스 전반에 걸쳐 함께 협의 하고 목표를 달성하게 위해 협력 합니다.

더 자세한 문의는 rtlink.park@gmail.com 로 해주세요

웹서비스의 검색엔진 최적화 (SEO) 작업

개발 과정에서 웹서비스의 검색엔진 최적화 (SEO) 작업 진행 과정을 정리 해봤습니다. 내부 기록과 비슷한 작업을 하는 분들을 위해 두서없이 정리 했습니다.

  • 컨텐츠 서비스를 하고 있는 입장에서 SEO(search engine optimization – 검색엔진 최적화)는 엄청나게 중요한 기능이지만 웹 클라이언트를 SPA로 만들고 있던 타력 때문에 리뉴얼때도 어쩔 수 없이 SPA(React)로 진행 할 수 밖에 없었음
  • 웹 SPA Applications은 기능을 구현하고 서비스를 만들기에 용이 하지만 Client에서 서비스를 구동 시킨다는 근본적인 한계 때문에 검색엔진 최적화에는 치명적인 문제를 안고 있었음.
  • 그래서 만든 대안이 프록시 서버 – 가장 시급한 일이 페이스북 Open Graph에 대한 대응이었기 때문에 페이스북 검색봇이 서비스에 접근하면 User Agent를 확인하고 별도의 프록시 서버로 리다이렉션하여 Open Graph 메타 데이터를 전송하는것으로 기능 구현함
  • 구글봇 역시 프록시에서 처리 하였지만 프록시 서버에서 전달하는 데이터가 실제 서비스의 코어 데이터만 전달 하다보니 검색엔진이 크롤러가 온전한 컨텐츠를 모두 가지고 가지 못하는 문제가 생기고 각 컨텐츠 페이지의 링크 구조가 온전하게 검색엔진에 전송되지 않아서 검색 키워드에 대한 검색 결과가 완전하지 나나타지 않는 현상이 발생 하고 있었음
  • 서버 랜더링이 위의 문제들에 대한 완전한 해결방안임을 알고는 있었지만 레거시 코드와 기능 구현 문제로 SSR전환을 쉽게 결정하지 못하는 상태로 상당한 시간이 지나감
  • React의 경우 Next라는 프레임워크로 서버사이드 랜더링 기능이 지원 되고 있지만 기존에 사용중이던 클라이언트 Navigation 시스템과 User Management 시스템의 상당한 변경 이슈로 결정을 망설이게됨
  • 하지만 꼭 해야 하는 일이라서 Next – React 기반의 프로토타이핑 개발을 진행해서 기존 코드와의 변경점을 확인하고 실제 개발에 착수. https://github.com/zeit/next.js/

동시에 구글 서치엔진 SEO 기능에 대한 서베이 및 개발 진행

  • 구글 검색엔진 최적화에 관련한 자료는 대부분 https://developers.google.com/search/docs/guides/ 에서 찾을 수 있음
  • https://www.google.com/webmasters/tools/home 에서 구글 SEO 관련 셋팅을 진행함
  • 각 컨텐츠에 맞는 구조화 데이터에 대한 메타 데이터 및 LD+Json 스크립트를 지원하면 더 품부한 검색 결과 및 검색결과에서 더 좋은 표시 결과를 얻을 수 있음
  • LD+Json은 버즈아트의 경우 컨텐츠를 http://schema.org/VisualArtwork 의 구조와 같이 생성하도록 구성, 다른 컨텐츠 구조는 적절한 스키마를 찾아서 데이터를 삽입하는 과정을 거침
  • SiteMap은 가능 하면 모든 링크를 크롤링 후 생성해서 업로드 해주는 것이 원하는 경색 결과를 얻을 수 있음
  • 상용 서비스를 이용할 수도 있고 크롤러를 만들 수도 있음
  • 우리는 https://github.com/lgraubner/sitemap-generator 를 이용하여 Node.js 기반으로 만들어 사용함
  • 컨텐츠는 매일 생성되므로 가능한 자주 SiteMap을 생성하여 업데이트 해주는 것이 SEO에 최적화에 좋은것으로 판단
  • 메타 데이터의 생성은 Next – Head Tag를 이용하여 서버 랜더링 상황에서 Setting

결론

  • SEO는 참을성이 필요한 작업으로 생각됨
  • 검색엔진의 요청사항을 파악하고 꾸준한 업데이트와 최적화의 과정을 거쳐야 최적화 가능
  • 작업 완료 이후에도 검색봇이 크롤링 해서 인덱싱 하는 과정에 상당한 시간이 소요되므로 개발완료 이후 1~2달에 걸쳐 꾸준히 검색결과의 변화를 확인하고 조금씩 옵티마이즈하는 과정을 거쳐서 최적화 해야함

오픈 소스 마이튜브(My-Tube)

소스 다운로드 링크 – https://github.com/bipark/my-tube
  • 마이튜브(My-Tube)는 오픈소스 기반의 동영상 큐레이션 서비스와 큐레이션 관리를 위한 백오피스 프로젝트가 포함된 서비스 솔루션입니다.
  • 이 프로젝트를 사용하여 사용자의 취향에 대응 할 수 있는 유튜브 기반의 동영상 큐레이션 서비스를 구축 & 운영 할 수 있습니다.

주요기능

  • 메인픽 – 스페셜 피쳐링
  • 카테고리별 조회
  • 인기 큐레이션
  • 인기 동영상
  • 최근 업로드
  • 동영상 및 큐레이션 검색 기능
  • 개인별 프로필 – 좋아요 / 북마크 / 뷰히스토리
  • 동영상 플레이어
  • 카테고리별 연속 플레이 기능
  • 불량 동영상 신고 기능
  • 회원 가입
  • 소셜공유 – 페이스북, 구글+, 트위터, 핀터레스트
  • 댓글
  • 북마크 / 라이크
  • 회원 반응에 변동되는 순위 시스템
  • 반응형 스타일을 지원 – 모바일 페이지를 별도로 만들 필요가 없습니다.
  • 구글 SEO(Search Engine Optimazation)에 최적화 되어 있습니다.
  • 구글 구조화된 데이터(Structured Data)를 지원합니다. – VideoObject(마크업: schema.org)
  • SSR(Server Side Rendering)을 지원 하는 구조
  • 사용자 문의
  • 공지사항
  • 개인정보 취급방침 / 서비스 이용약관
  • 로그인 / 회원가입

웹 서비스 검색 & 공유 최적화

인터넷으로 홈페이지를 서비스하고 있는 회사들의 상당수가 개발과 마케팅에 많은 비용을 쓰지만 의외로 검색 & 공유 최적화에는 돈을 쓰지 않는 편입니다. 이유는 이런 대응은 주로 마케팅의 영역에서 해야 한다는 개발 조직의 생각과 기술을 모르는 마케팅 조직의 대응방법에서 나오는 생각의 차이 때문입니다.

개발 조직에서 기존의 개발 업무에 약간의 노력을 더하면 홍보 & 마케팅에 쓰는 비용을 줄이거나 홍보의 효과를 극대화하는 방법을 찾을 수 있습니다. 그것은 흔히 검색 최적화라고 불리는 SEO(Search Engine Optimization)와 소셜 공유 최적화 입니다. 최초 서비스 개발시에 이런 기술들을 적용하는 것이 기장 이상적이지만 이미 운영중인 서비스에도 검색 & 공유 최적화를 할 수 있는 많은 방법들이 있습니다.

검색 최적화 방안

  • 검색 최적화의 방법은 구글도 모릅니다 – 검색 알고리듬이 계속 변화하고 있습니다.
  • 하지만 구글에서 제시하고 있는 가이드가 있습니다. 물론 가이드대로 해도 잘되지 않는 경우가 적지 않습니다.
  • 데이터를 측정할 수 있는 다양한 방법이 있기 때문에 결과를 측정해가면서 작은 조정들을 계속해 나가는 것이 가장 최선의 방법입니다.
  • 검색 최적화의 가장 좋은 방법은 Google Search Console https://www.google.com/webmasters/tools/home 에서 지시하고 있는 기능들을 구현하고 시간을 가지며 결과를 측정해서 조정하는 방법입니다.

검색 노출 향상을 위한 구조화된 데이터

구글 구조화된 데이터 (Google Structured Data)

  • 컨텐츠의 타입에 따라 구조화된 데이터를 지원(ld+json)하면 검색결과에서 더 다양한 형태로(이미지, 동영상 등) 결과를 조회할 수 있습니다.
  • 구조화된 데이터는 https://schema.org 에 정의된 schema 타입으로 서비스 데이터를 구조적으로 정의해서 표준화된 형태의 디스플레이 구조로 만들어 검색 결과로 나타나도록 보여줍니다.
  • “application/ld+json” 타입의 데이터를 검색봇에게 제공하여 구글이 표준화된 조회 결과를 나타낼 수 있도록 합니다.
  • 이미지, 동영상, 책, 상품 등의 검색 결과들을 아래 링크와 같은 형태로 최적화 시켜줍니다. 아래 링크에서 검색 결과를 조회할 수 있습니다.
  • https://developers.google.com/search/docs/guides/search-gallery?hl=ko
  • 기존 서비스를 수정할 수 없다면 프록시 서버 타입으로 검색봇에 대하여 대응할 수 있습니다. – 3.3 참조

Sitemap 작성 및 등록

  • Sitemap을 작성하는 것은 크롤링봇에게 컨텐츠의 정확한 주소를 알려 주는 것과 같습니다.
  • Sitemap 생성기를 활용하여 만든 Sitemap을 업로드 하여 주기적으로 페이지 변화를 구글에게 알려줍니다.
  • 서비스 내부에 페이지 변화가 생기면 자동으로 Sitemap을 생성하여 즉각 대응할 수도 있습니다.

데이터 하이라이터

  • 일정하고 표준화된 서비스 페이지의 경우 좀 더 쉽고 간단한 방법으로 검색결과를 표시할 수 있습니다.
  • https://support.google.com/webmasters/answer/2692911?hl=en

robot.txt 설정

  • 크롤링의 원하는 페이지 또는 보안이 필요한 페이지를 명확히 구분하여 크롤링봇의 접근을 제어해야 합니다.
  • Web Server, Api Server, Back Office 등에 대한 접근 권한을 차별화하여 웹 보안성도 확인해야 합니다.
  • 로봇 배제 표준 프로토콜 지원
  • https://en.wikipedia.org/wiki/Robots_exclusion_standard#About_the_standard

SSR(Server Side Rendering)

  • SSR은 HTML 데이터의 일부 혹은 전부를 서버에서 생성해서 클라이언트(웹브라우저)에게 전달하는 방식입니다. 반대로 SPA(Single Page Application)는 클라이언트(브라우저)에서 HTML을 생성하고 데이터만 API 서버에서 받아서 결합하는 타입입니다. 따라서 렌더링을 하지 않는 Bot 형태의 접근자에 대한 일반적 처리에 어려움이 있습니다.
  • 현재 오픈되어 있는 서비스의 타입(SSR 인지 SPA인지)에 따라 검색 & 공유 봇에 대한 대응 방법이 다를 수 있습니다.
  • 서버 렌더링(Node.js, PHP등..)의 경우 소스 레벨의 수정을 통하여 메타 데이터를 코드에 삽입할 수 있습니다.
  • SPA(Single Page Application)방식의 서비스(React, Vue, Angular 등등..)라면 프록시 서버를 개발하여 특정 봇에만 대응하는 기능을 추가해서 기존 서비스와 별도의 운영이 가능합니다.
  • SPA 서비스를 SSR로 변환하는 방법도 가능합니다.
  • 기존 서비스 소스가 있다는 가정 하에 React.js의 경우 Next.js를 도입하고 일부 코드를 수정하여 SSR을 도입할 수 있습니다.
  • Vue.js의 경우 Nuxt.js 프레임워크를 도입할 수 있습니다.

프록시 서버 – SSR이 안되면

  • SSR(서버 사이드 랜더링)이 불가능한 시스템에 대한 검색엔진 대응 방법
  • 기존 서비스가 SPA 이거나 소스레벨의 수정이 불가능하면 Proxy Server를 이용하는 방법을 사용할 수 있습니다.
  • 서비스에 접근하는 접속의 UserAgent를 확인하여 검색봇, 공유봇 등을 구분하고 별도의 서버로 Redirect 합니다. 검색 봇에게는 위의 검색 결과에 필요한 정보를 제공하고, 공유봇에게는 공유를 위한 Open Graph 데이터만을 제공하는 별도의 서버를 구성할 수 있습니다.
  • 기존 시스템과 별도의 개발이 진행되어야 하지만 단지 봇을 위한 대응이므로 UI가 없는 서버만으로 대응이 가능합니다. 따라서 개발이 비교적 쉬운 편입니다.

소셜 공유 & 최적화 방안

  • 소셜 공유는 데이터를 사용자들이 자발적으로 다른 사용자에게 전달하게 하는 가장 좋은 홍보 & 마케팅 도구입니다.
  • 물론 기본적으로 사용자가 공유하고 싶은 컨텐츠를 만드는 것이 가장 중요하지만 쉽게 공유할 수 있도록 서비스를 구성하는 것도 매우 중요합니다.
  • 소셜공유는 대략 두가지 기술적인 방법으로 이루어집니다.
  • 첫번째는 사용자가 공유하는 시점에서 공유 데이터를 생성해서 소셜 서비스에 직접적으로 업로드하는 타입입니다.
  • 두번째는 Page Link를 등록하면 공유봇이 Site를 방문하여 제공된 데이터를 가지고 와서 포스팅하는 방법입니다.
  • 후자의 경우 Facebook이 대표적이고 Open Graph라는 TAG 기반의 정보를 활용합니다.

소셜 데이터 공유

  • 일반적인 데이터 공유는 플랫폼 별로 다양한 오픈 소스 공유 버튼을 이용하는 것이 편리하고 좋습니다.
  • JavaScript 기반의 다양한 프론트엔드 오픈소스들이 존재하므로 플랫폼에 따라 여러가지 오픈소스를 테스트한 후 가장 적합하고 쓰기 쉬운 것을 선택하는 것이 좋습니다.
  • iOS, Android 플랫폼의 경우 Facebook SDK, Firebase SDK 등을 활용하여 기능을 구현하는 것이 일반적입니다.

오픈 그래프 공유

  • Open Graph는 페이스북에서 만든 이후 다양한 소셜 서비스에서 이를 사용하고 있는데 페이스북과 트위터가 대표적입니다.
  • 이를 지원하기 위해서는 컨텐츠를 제공하는 각 페이지에서 META TAG를 이용하여 페이지가 이 컨텐츠를 소셜에 제공하고자 하는 의도를 미리 정의 해 두어야만 합니다.
  • META TAG 없이 공유된 페이지는 내용에 따라 서비스 의도에 부합하지 않는 데이터를 제공하게 될 수도 있습니다.
  • 페이지에서 제공하고자 하는 정보와 Open Graph의 Object Type을 맞추면 페이스북 타임라인에 제공되는 UI를 컨텐츠에 적합한 다양한 모양으로 제공할 수 있습니다.
  • 오픈 그래프에 정의된 다양한 옵션들은 다음 링크에서 참조하세요
  • https://developers.facebook.com/docs/reference/opengraph
  • 공유 디버거를 통하여 공유 결과를 미리 조회할 수 있습니다.
  • https://developers.facebook.com/tools/debug/sharing

리액트 네이티브(React Native) 프로젝트에서 생각해야할 것들

리액트 네이티브(React Native) 프로젝트에서 생각해야할 것들

  • 최근 프로젝트에서 프론트앤드 기술 스택을 페이스북의 React 와 React Native(이하 RN)로 통일(?) 했습니다. 기존의 기술스택(Angular & Native)을 버리고 완전 새로운 기술 스택(React Native & React)을 도입해서 앱과 웹 프론트 개발을 완료 했습니다. 아래 몇가지 이야기로 왜 기술을 바꿨는지 어떤점이 좋은점이고 위험한지 정리해봤습니다.

기술 스택 변경의 이유

  • 스타트업들은 작은 회사 입니다. 많은 기술 인력을 채용할 여력이 없고 운영할 능력도 부족합니다. 하지만 한 팀이 되어야 하고 동일한 어조로 서로 소통 할 수 있어야 한다고 생각 했습니다. React와 RN은 동일한 자바스크립트 기술 기반위에 있어서 적은 개발팀 내부에서 여러가지 언어와 기술 스택이 분리되어 있어서 언어들이 달라서 발생할 수 있는 분리 장벽이 없습니다. 그리고 누군가 어려운 일이 생기면 서로 도움을 주고 받을 수 있는 팀 구조를 만들 수 있다고 생각 했습니다. 이게 작은팀에서는 꽤 중요한 요소 입니다.

크로스플랫폼에 대한 개인적인 환상

  • 제 개인적으로 크로스플랫폼이라는 말에 아주 오~래 된 환상이 있었습니다. 한번 만들면 여기 저기서 돌릴 수 있어 라는 말은 석기시대 때부터 있었던 사기(?) 같은 이야기 였고 자바가 어느정도 그문제를 해결하는가 싶더니 최근엔 LLVM을 통해서 많은 언어들이 이젠 진짜 가능한것 처럼 이야기 하고 있습니다. 리액트와 RN 역시 그 대열에 서 있긴 하지만 역간 다른 스텐스를 취합니다.
  • 페이스북 개발팀은 니가 잘하면 한 70% 정도의 코드는 공유 할 수 있을거야~ 라고 말하더군요. 이정도면 대박 아닌가 하는 생각도 선택의 이유였습니다. 결국은 개인적인 환상을 성취하기 위해 회사를 위험에 빠트리게 됩니다.

선택의 불안감

  • 하지만 불안감이 존재 했습니다. 개인적으로는 꽤 오랫동안 아이폰으로 네이티브 개발을 해왔기 때문에 RN이 네이티브의 성능을 따라갈 수 있을지 의문스러웠습니다. 그리고 RN은 글을 쓰고 있는 현재도 버전 0.45에 머물고 있고 국내에서 성공 사례로 알려진 케이스도 별로 없었습니다.
  • 게다가 RN으로 시작 했다가 네이티브로 돌아간 이야기(https://brunch.co.kr/@jamess/5) 와 같은 블로그가 불안감을 더 높이기도 했습니다.

파일럿 프로젝트

  • 그래서 파일럿 프로젝트를 먼저 하기로 했습니다. 성능을 한번 보면 되겠지 싶었습니다. 그리고 새로 만난 팀원들의 합도 한번 맞춰 보구요.
  • 일주일 정도의 작업끝에 메인 피드 하나를 만들어서 각종폰에서 테스트 했습니다. 아이폰은 매우 훌륭한 성능이 나왔고 안드로이드는 뭔가 찜짐하긴 했지만 커스터마이즈를 좀 하고 캐싱을 좀 하면 나아 지겠지 하는 생각으로 이정도면 시작 할만하다고 평가 했습니다.
  • 하지만 그게 아니었다는게 나중에 밝혀 집니다.

RN 개발의 기술적인 포인트들

  • 결론적으로 파일럿 프로젝트를 포함해서 아이폰, 안드로이드, 웹프론트를 4명의 인원으로 약 3개월(100일)만에 개발완료하고 성공적(?)으로 서비스를 오픈 했습니다.
  • 그 과정에서 겪은 몇가지 기술적 혹은 개발 운영 측면에서 본 문제점 및 해결 방안을 아래와 같이 정리 해보겠습니다.

CSS

  • RN의 개발과정은 웹프론의 개발 과정과 동일한 순서와 방법으로 진행 하는 것이 좋습니다. 웹프론트를 개발해 보신분은 아시겠지만 UI 디자인이 나오면 CSS를 이용해 화면을 먼저 만들게 됩니다. 그리고 HTML이 나오면 거기에 데이터를 입히는 과정을 진행 하죠.
  • 기존 네이티브앱 개발은 한명의 개발자가 화면구성과 데이터 연결을 동시에 작업하는 것이 일반적이었지만 RN의 특성상 CSS를 이용한 화면 구성이 이루어 지므로 CSS를 잘 다루는 웹 퍼블리셔가 필수적인 요소입니다.
  • 다행히 저희팀에는 CSS를 아주 잘 다루는 개발자가 있었습니다. 이것이 중요한 또 한가지 이유는 일반적으로 Hot-Loading을 이용한 시뮬레이터 기반에서 개발을 하게 되는데 이게 주로 아이폰 시뮬레이터 기반에서 개발을 시작하기 때문에 나중에 안드로이드에 올려보면 화면이 깨지거나 오동작을 하는 경우가 꽤 빈번하게 발생합니다. 이유는 아직 RN이 베타라서 그럴 수도 있고 CSS를 깔끔하게 정리 하지 못한 탓일 수도 있습니다만 제 생각으로는 RN으로 만든앱들에서 UI관련된 오류 문제는 거의 CSS를 잘못 만든 탓이 아닌가 싶습니다.

리스트 컨트롤

  • 앱개발에서 가장 많이 쓰는 컨트롤은 리스트 컨트롤입니다. 아이폰과 안드로이드 각각 다른 이름의 리스트 컨트롤이 있지만 앱화면의 거의 대부분은 이 리스트 컨트롤 기반으로이루어진다고 해도 과언이 아닙니다. RN에도 ListView라는 리스트 컨트롤이 있습니다.
  • 저희팀이 앱을 거의 다만들고 여러가지 폰에서 테스트를 시작하면서 고난에 빠지게 된 이유가 이 ListView 때문이었습니다. 아이폰은 매우 깔끔하게 잘 돌아갔습니다. 물론 아이폰도 리스트를 계속해서 로딩 하다보면 메모리 부족 현상이 나타나면서 앱이 크래시 되는 문제가 더러 있었습니다만 가장 심하게 나타난 것은 역시 안드로이드 구중에서도 하위 기종에서 문제가 많았습니다.
  • 10페이지를 넘기지 못하고 앱이 죽어 버리는 경우가 다반사 였습니다. 꽤 심각 했습니다. 문제의 해결방법을 찾던중 RN의 3월 이후 버전에 FlatList 라는 컨트롤이 있다는걸 발견 했습니다. 몇일이 걸리긴 했지만 ListView를 FlatList로 변경 했습니다.
  • 링크(https://facebook.github.io/react-native/blog/2017/03/13/better-list-views.html)를 살펴 보시면 알 수 있겠지만 FlatList는 메모리 사용과 성능 문제에서 기존 ListView가 가지고 있던 문제들을 대부분 해결 했고 저희팀도 결과로 확인 할수 있었습니다.
  • 안드로이드 하위 기종에서도 크래시없이 거의 모든 페이지를 보여주는 결과를 보여 줬습니다.

브리지 라이브러리

  • RN은 기본적으로 웹뷰가 아닌 네이티브 방식으로 실행됩니다. JS를 통해 만든 코드를 앱 내부에 임포트된 네이티브 코드를 실행 시키면서 기존의 웹뷰 빙식의 하이브리드 앱보다 더 빠르게 실행 시킬 수 있도록 만든 플랫폼입니다. 이것은 기존에 만든 네이티브 스테틱 라이브러리를 사용할 수도 있다는 이야기 이기도 합니다. RN에서 지원해 주지 않는 기능들은 네이티브로 만들어서 연결 할 수도 있다는 이야기 입니다. 그것을 위해 존재하는 연결방법이 브리지 라이브러리 입니다.
  • https://js.coach/react-native 에는 이미 만들어서 사용가능하게 구성된 상당이 많은 라이브러리들이 있고 그 라이브러리들은 아이폰과 안드로이드를 동시에 지원 하도록 구성된 것들이 많습니다.
  • 하드웨어 연결 혹은 카메라, 비디오, 기타 다양한 기능을 가진 브리지 라이브러리들이 있고 만약 없다면 스스로 만들 수도 있습니다.

자바스크립트

  • 웹프론트팀을 운영하고 있는 회사라면 JS 기술 혹은 환경에 대해 익숙 할 수도 있지만 네이티브앱만 만들어 왔다면 JS로 앱을 만드는 일에는 꽤 많은 허들이 존재 할것 같습니다.
  • ES6, Webpack 기타등등.. 너무 많은 디펜던시에 얽혀 있어서 요즘은 JS헬이라는 말도 있을 정도입니다만 Create-React-Native-App과 같은 cli도구를 이용하면 기본적인 환경 구성은 쉽게 할 수도 있습니다. (https://github.com/react-community/create-react-native-app)
  • 그렇지만 JS를 이용한 개발은 어쩔 수 없는 공부시간이 필요한것 같습니다. 최근에는 TypeScript를 많이들 사용해서 JS의 Type 오류들을 해결해 나가면서 구조화 시키는 기술들을 많이 사용하고 있는것으로 확인하고 있습니다. 저희도 다음 업그레이드에서는 TypeScript를 도입해 보려고 준비하고 있습니다.

결론

  • RN은 매우 매력적입니다.
  • 개인적으로 가장 매력적인것은 더이상 아이폰앱을 만드는 AutoLayout을 사용하지 않아도 된다는 부분이었습니다. 사실 애플이 AutoLayout을 도입한건 매우 큰 실책이라고 여전히 생각하고 있습니다. Flex Layout얼마나 좋은데요.
  • 아이폰과 안드로이드를 한개의 코드 베이스로 개발하고 동일한 기술스택으로 웹까지 개발 할 수 있다는 것은 예산이 적은 스타트업에겐 매우 좋은 소식이 아닐 수 없습니다. 하지만 기존의 개발 습성과 기술 전환에 들어가는 리스크와 비용을 생각하면 쉽게 올라 탈 수 있는 말은 아닌것 같습니다.