맥을 쓰다보면 Parallel Desktop , Clean My Mac 같은 솔루션들이 끊임없이 매출을 창출하기 위해 버전을 관리하는 방법들을 내놓고 있다. 물론 새버전이 나올때마다 새롭게 사게해서, 짜증이긴 하지만.. 그 들도 먹고 살아야 하니 어쩔수없다. 그 만큼 가치가 있다면 계속 돈주고 사야지. 그럼 솔루션 업체 입장에서는 어떻게 해야 저항없이 고객들이 새 버전으로 솔루션을 업그레이드 할수있게 만들 수 있을가? […]

무려 3년이 다 되어가지만,  일전에  SaaSTR이라는  컨퍼런스에 다녀왔다.  (좋은 행사에 보내주신, WhaTap 에 이동인 대표님에게 감사를 드린다) AppDynamics가 Cisco에 4조에 인수된 사건과 발생하였고,  SaaS에서 내놓으라는 회사에서 자신의 노하우와 여러 기반 기술을 공유한 행사였다.   여기서  크게 관심을 가진 세션이 있었는데 CPO가 무엇을해야 되는지에 대한 세션이었다.

CPO(최고 제품 개발자) 또는 VPP (VP of Product)가  해야 되는 일

  • 물건을 잘 파는 거, 향후 전략, 마켓팅과 연합.
  • 일반 고객 / 중요 고객 / 엔지니어 팀과 이야기 하면서 방향을 잡아가는 것.
  • 지휘자 / 커뮤니케이터 / 오케스트레이션, 오가나이제이션
  • 팀간에 ceo가 vision을 실행한다면 그걸 하게 만들어야 되는 역할.

CPO(VPP)와 프로덕트 관리자와 다른 것은 무엇인가요?

  • 접점이 달라진다. 팀원을 이끄는게 아니라, 고객과 이야기 하고 고객이 원하는 product으로 갈수 있게 이끌어야 한다.
    leadership이 달라진다. pm은 엔지니터링 팀을 이끌고 잘 돌아가는게 하는게 목적.
  • CPO(VPP)는 정말 다양한 백그라운드를 가지고 있다.
    – 디자이너 출신: 고객의 경험을 중심. 어떠한 성격을 가지는지. 어떻게 고객과 점접을 가지고 이야기 하는지.
    – 엔지니어 출신: 실현 가능한지, Scope은 얼마인지에 집중이 필요하다.

Cx 레벨간의 차이는 무엇인가요?

  • CEO는 비전을 제시한다
  • CPO는 사용자가 어떠한 느낌을 가질지, 어떠한 기능을 제공할지 고민을 해야 한다.
  • CTO는 자동차의 엔진을 잘 만들어야 한다.

CPO가 해야 할일을 구체적으로 알려주세요.

  • 고객과의 접점을 늘리고, 어떠한 제품과 기능을 제공해야 하는지, 많은 이야기를 해야 한다.
  • 유저 스토리를 만들고 왜 사용하고, 어떻게 진행하고 등에 대해서 끊임없이 이끌어야 한다.
  • engineer , marketer, customer 간에 조율하고 이끌어야 한다.
  • context switching 을 잘해야 한다. 7일에 7개의 언어를 배우듯이 여기 저기 왔다 갔다 잘해야 한다. 상황에 맞게 변신하는게 매우 중요하다.

계속 읽기

marshal / unmarshal  – encode / decode에 대한 go의 개념들

Marshal 이란?

구조체 또는 객체의 데이터를 json으로 byte[]로 만드는 것이 json.Marshal의 역할입니다.   여기까지는 그냥 string이며  http상에서는 문서로써 바로 전달이 가능하지요.  http상에서는 모든게 문서이니깐요 🙂

(marshalling의 원래의미 –  군대에서 준비태세를 갖추는것을 말하는 것인데, 네트워크-전쟁으로 나아가기 전에 어떤 포멧- 무기로 싸울지 준비태세를 갖추는 것으로 이해하면 됩니다)

Serialization 이란?

하지만 일정한 크기로 잘게 나누어서 물 흐르듯이  계속 보내기 위해서는 stream 형태로 전달할 필요가 있습니다.  node.js가 서버 사이드 언어이므로 최상위 객체 EventEmitter바로 밑에 stream 으로 흐르게 딱 박혀있습니다 (왜 갑자기 node.js 이야기를 하냐면 stream이 그만큼 서버 사이트 프로그래밍에 중요하다는 의미이고 node.js 도 stream 형태로 데이터를 전송하는 것이 기본 골격이라는 의미입니다)

 

golang에서는 Encode  (Serialization) 라 불러주세요

golang에서는 serialization, 즉 byte[] 데이터를 stream화 하는 녀석의 이름이 encode라고 부르네요.

golang made

json.Marshal , Encode 의 개념도

계속 읽기

안드로이드에서 종종 만나는 문제가   NullPointer Exception이며 또 하나는 OOM (Out Of Memory) 입니다. Crash Report 서비스인 UrQA ( http://www.urqa.io) 를 운영하면서 많은 문제들을 볼수 있습니다. 하지만 위 두 문제는 모든 앱이 다 겪고 있는 문제죠. (현재 URQA는 300개가 넘는 업체가 사용하고 있으며, 안드로이드 뿐만 아니라 곧 iOS, Unity, JS를 지원하게 됩니다. 내부 테스트 중입니다)

 

이러한 문제를 어떻게 해결할까? 에 대해 해당 디바이스를 직접 구하지 않는 한 답은 없지만, 개발자 선에서 해결할수 있는 방법이 Profiler가 아닐까 생각이 듭니다. 하지만 안드로이드 Profiler는 처음 접하기에 러닝 커브가 좀 있고,  이것들을 어떻게 활용하는지 많은 분들이 잘 모릅니다.

또한 안드로이드 OOM (Out of Memory)의 주 원인인 BITMAP. 이것을 어떻게 다루는 것이 좋은지 안드로이드 개발자 사이트에 있으나, 그 밑단에 많은 개념들을 숙지하고 있어야 합니다.

  • JVM과 다른 Dalvik 의 메모리 관리 기법
  • 다양한 Reference를 사용하여, Garbage Collection 시 불 필요한 리소스를  빠르게 수거하는 방법
  • 그리고 Heap Dump를 이해하기 위해 MAT라는 툴을 사용해야 하는데 보는 방법

이 외에도 많은 숨겨진 지식들이 있어야 Profiler를 제대로 활용할수 잇고,  그 문제에 대한 해결책을 찾아갈수 있습니다.

계속 읽기

TDD

꽤 진부하면서도, 논쟁거리가 될수도 있지만, 개인적인 경험과 고민 끝에 글을 나누고자 한다. 꽤 스타트업을 기술적, 아키텍팅 쪽을 컨설팅하면서 지켜보아 왔던 경험치를 가지고 말씀 드리는 겁니다.  (물론 삼성이라는 대기업만 다닌 니가 스타트업을 얼마나 잘 알아? 라고 물어보실수 있지만 말랑 스튜디오, 빙글, 이노피아 테크 등 꽤 많은 업체들을 컨설팅하고 이야기를 나누고, 그들을 지켜보온 경험치라고 생각을 해주시면 될듯 합니다)

개발자들에게 TDD의 도입을  물으면 찬반이 매우 명확한 편입니다. 특히 큰 규모의 라이브 시스템을 운영한  웹 개발자 분들은 TDD를 통해 조기에 많은 문제를 잡고, 찐한 경험 이야기를 해주십니다. 100%로 동의합니다. 많은 유저들이 동시에 모여서 나가는 서비스라면 품질이 매우 중요해지고,  돌다리도 두들기고 건너가는 것이 맞습니다.  큰 웹서비스를 경험하신 분 입장에서는 TDD 가 큰 보험이 되며, 그 다음 Step을 넘어가는 좋은 보험이 되죠.

은총알은 없다.

특정 방법론, 전략이 A 상황에서는 좋은 약이 될수 있지만, 모든 상황에  항상 옳다고 할수 있을까요?

어떤 방법론이든, 기법이든 항상 장단이 있습니다. 전달을 할때 꽤 신중하게 전달을 해야 한다고 봅니다. “TDD는 좋다!” , “내가 해본 경험으로서는 정말 보험이 되고 든든한 녀석이다!!”  라고 말을 하지만, 모든 상황에서 적절한 방법인지는 정말 고민을 해봐야 합니다. 정말 크게 이슈가 되었던 Joel과 Bob 삼촌의 TDD 논쟁 사건을 보더라도, Joel쪽에 공감하는 사람도 제법있습니다.  이 논쟁에서 Bob 삼촌의 이야기를 지지하는 사람도 있지만, 아닌 사람도 꽤 많다는 것이죠..

정말 공감가는 글이 있는데,  바로 TDD역시 비용의 문제라는 것이다.  미물님께써 적은신 글을 보고 크게 공감을 하고 있습니다.   바로 비용이라는 측면에서 바라보아야 한다는 것입니다. 또한 지금 xper 에서 논의되고 있는 “TDD 는 죽었다.”  라는 글을 보면 공감할 부분이 꽤 있습니다.

계속 읽기

소마에 멘티들과 지난 몇개월 동안 재미난 프로젝트를 진행했습니다.

조재우, 노성현, 윤강호, 박종훈    (사진은 추후 잘 나온걸로 공개하겠습니다.)

안드로이드 테스트 자동화와 프로파일러를 직접 구축한 프로젝트를 진행했습니다. 기획, 개발 총 3달이 걸렸으며, 아직 시장에 바로 나가기에는 좀더 다듬을 필요는 있습니다.

일단 보시죠. 백번 듣는것 보다는 보시는게 더 나을거 같습니다.

기존 프로파일러와 다르게 SaaS 형태로 접근성을 높였으며,  테스트를 쉽게 그리고 프로파일링도 쉽게 만들기 위해 큰 고심을 했습니다. 몇몇 업체를 만나 안드로이트의 동적 분석, 자동화 테스트를 도와 드렸으며, 시행 착오를 겪으면서 조금씩 더 개선하고 있습니다.

계속 읽기

종종 멈춘다거나, 빈번하게 죽는 앱이라면 사용하시지 않겠죠. 그렇다고 전체 개발자중 1인 개발자가 70%인  상황이라. 개발자들의 TDD, Profiling 등을 통해 품질을 검증해서 앱이 나오기는 매우 힘듭니다. 

그래서 아실말한 분은 다 아시겠지만, Android 에는 크래쉬 리포트라는 서비스가 있습니다.  대표적인 것으로 Bugsense , ACRA, Crashlytics 같은 것이 있죠. 품질을 시키기 위해 이러한 서비스를 사용하는 경우가 전체 앱에서 10%정도 밖에 안됩니다.

왜 이러한 서비스를 사용하지 않는 걸가? 그리고 기존 Bugsense , ACRA, Crashlytics같은 서비스들의 불편함은 무얼까 고민을 했습니다. 그래서 만들어진 서비스가 바로 UrQA 입니다 .  초기 서비스에는  양현철, 정승수, 안정원 이 3명이 매우 빠르게 고생해서 만들었습니다.  3개월안에 기획, 구현, 디자인 까지 이 3인방이 끝냈습니다.  소마에 멘티들로 정말 최고의 실력을 가졌고, 세상에 도움이 되는 서비스를 만들었기에 박수를 치고 싶습니다.  한번 보시죠..

등급화, 쉬운 재현,  Native (C언어)를 지원하는 것에 초점을 맞추었고, 오픈소스이며 서비스도 ucloud의 커뮤니티 지원으로 무료로 운영중입니다.

이 서비스를 자랑하고 싶기도 하고, 많은 애용을 말씀 드립니다.  크게 홍보하지 않았지만 100개의 앱이 넘게 저희의 서비스르 무료로 이용하고 있습니다.

계속 읽기

PLoP이 드디어 20주년을 맞이 했습니다.

20주년 행사인 만큼, 초기 패턴을 이끌었던 맴버들이 대거 참석한다는 것이고, 가장 먼저 PLoP 이 열렸던 성지인 Allerton Park에서 열립니다. 책에서 본 그곳에서 책에서나 보는 대가들과 만난다니 기쁘네요.

  • Ralph Johnson
  • Ward Cunningham
  • Rebecca Wirfs_Brock
  • Joseph Yoder
  • Richard Gabriel
  • Joshua Kerivsky

계속 읽기

may2010-2x3릴리즈 및 설치 프로세스에 대한 디버깅이 프로젝트가 종료되는 시점까지도 진행되지 못하는 경우가 많습니다. 어떤 프로젝트에서는 설치도구를 작성하는 일이 릴리즈 엔지니어에게‘필요악’으로 주어집니다. 리뷰나 데모는 모든 것이 잘 동작함을 보장하기 위해 수작업으로 수행하는 경우가 많습니다. 결과적으로 팀은 너무 늦어서 변경하지 못할때까지도 릴리즈 프로세스 및 릴리즈하는 환경을 경험하지 못합니다.

설치/릴리즈 프로세스는 첫 번째로 고객에게 보여지는 것입니다. 단순한 설치/릴리즈 프로세스는 신뢰할 만한(또는 최소한 디버깅하기 쉬운) 동작 환경을 갖는 첫 단계입니다. 릴리즈된 소프트웨어는 고객이 사용하는 것입니다. 릴리즈된 프로그램이 올바르게 설치되는 것을 보장할 수 없다면, 여러분은 제대로 소프트웨어를 사용하지 못한 고객으로부터 많은 질문을 받게 될 것입니다.

설치 프로세스가 있는 프로젝트로 시작하면 제품 개발 주기 동안 프로세스를 발전시킬수 있는 시간을 벌 뿐만 아니라, 설치를 좀 더 쉽게 할 수 있도록 애플리케이션 코드를 변경할 수 있는 기회를 얻게 됩니다. 설치 프로세스를 주기적으로 수행하고 테스트함으로써 여러분이 작성한 코드가 개발 환경이나 테스트 환경뿐 아니라 사용자의 환경에서도 동작한다는 것을 확인할 수 있습니다.

계속 읽기

NIPA 소프트웨어 공학센터의 지원으로, Android Application Block이라는 안드로이드 참조 아키텍쳐 모델을 만들었습니다 .

컨퍼런스를 통해서 먼저 소개하였고, 프리젠테이션을 통해서 안드로이드의 문제를 해결할때 필요한 여러 오픈소스들을 설명해 드렸습니다.  (재미난 것은 외국에서도 Android Bootstrap이라는 형태로 기존 Android의  문제를 해결하기 위해 여러 오픈소스를 묶어 제공을 했고, 안드로이드 개발자에게는 꽤 인기가 좋은 것으로 알고 있습니다.  )

이 버전보다 더욱 업데이트된 모바일 참조 아키텍처 (안드로이드) 를 발간 하였습니다. (링크를 통해 다운 받으시면 됩니다 – 소프트웨어 공학센터에 이메일 가입이 필요합니다)

안드로이드 어플리케이션 블록 아키텍처 

기존의 안드로이드의 구조(젤리 빈 기준)는 진성주 군과 분석하여  정리해보았습니다 (이 링크를 클릭하시면 됩니다).

그리고 저희가 몇가지 오픈소스들을 더해서 아래와 같이 추가된 모델을 만들었습니다.  새로 추가된 오픈소스가  기존의 어떤 안드로이드 패키지와 연관이 있는지 색깔을 입혀 표현을 하였습니다.

android application block_nipa

계속 읽기