 |
인사이드 안드로이드 -  송형주 외 지음/위키북스 |
회사에서 안드로이드 프레임워크 스터디 교재로 사용한 책이다. 소스 코드 레벨에서 프레임워크의 작동을 설명해주기 때문에 개발자들 스터디 교재로는 딱이다.
다만, 안드로이드 앱을 만들기 위한 내용은 다루지 않는다. 안드로이드 자체가 어떻게 작동하는지 이해하기 위한 목적이라면 추천하고 싶다.
챕터가 11개 인데, 긴 과정을 거쳐서 설명하는 주제는 ‘안드로이드에서 ActivityManagerService 라는 서비스가 어떻게 동작하는가?’ 이다. 서비스를 설명하기 위해 바인더 IPC 를 설명하고, 액티비티의 생성과정을 설명하기 위해 zygote 를 설명하는 식이다.
어쨋든 명확한 주제와 군더더기 없는 소스코드 설명으로 안드로이드의 기반을 이해하는 데 큰 도움이 되었다.
젠킨스를 이용해서 데일리 빌드를 내도록 설정 완료 했다. 현재 개발 환경이 빌드하기가 무척 복잡하고 까다로운 편인데, 젠킨스는 이런 것도 그리 어렵지 않게 설정할 수 있게 충분히 유연했다.
현재 환경은 펌웨어 등을 만들기 위한 소스코드들이 서브버전으로 관리되는 저장소에 들어가 있고, 안드로이드 프레임웍 코드들이 repo 라는 git 기반 툴의 저장소에 관리되고 있다.
펌웨어를 빌드하기 위해서는 이 둘을 오가며 빌드를 해줘야 하는데, 그때 마다 환경 셋업을 위한 스크립트를 따로 돌려줘야 한다.
그래서 적절히 안드로이드 빌드 하는 부분과, 빌드 전 필요한 pre-build, 빌드 후 작업을 위한 post-build 의 세단계로 나누어 데일리 빌드를 구축했다.
지금은 한시간 오십분정도 걸리는데, 병렬화와 재컴파일할 필요없는 것들을 바이너리로 처리하는 개선을 하고 나면 시간은 훨씬 줄어들 것 같다.
어젯밤에 잘 때 보니 밥그릇에 사료가 가득차 있지 않았다. 잠자리에 누우면서 ‘내일 아침에 꼭 가득 채워주고 출근해야 겠구나’ 했는데, 아침에 여느날처럼 허둥대다 그만 사료를 안주고 간 모양이다.
퇴근 후 집에 오니 아내가 나보고 고양이 간식 뜯어서 주고 갔냐고 묻는다. 난 그런적이 없었다. 살펴보니, 지퍼백에 넣어뒀던 간식 2개를 꺼내서 먹었더라. 하나는 예전에 내가 봉지를 뜯어놨던 육포. 다른 하나는 사료 비슷하게 생긴건데, 이건 직접 꺼내서 뜯어서 먹었다. 위의 사진이 그 인증샷.
웬지 모를 미안함에 더해서 뭉클하고 느껴지는 그 기특함. 혹시 내가 안 볼때는 두 발로 서서 다니지 않을까 싶다. 아무튼 다음에는 사료 꼭 챙겨주마.
안미안미.
한 스프린트 동안 개발이 진행되었다. 다음 스프린트를 준비해야 하는 시점이다. 스펙에 새로운 기능을 추가하기 전에 결정해야하는 사항들이 있다. 먼저 그 기능이 유용한가라는 질문부터, 보다 중요한 다른 것이 있지 않나 하는 질문까지. 무엇보다 현재 제품의 상태가 어느정도 인지 체감하는 것이 필요하다.
팀원들이 현재 제품의 상태를 피부로 느끼지 못하고 있다. 허공에 뜬 기획이 슬슬 꿈틀댄다. 이런 저런 기능을 무질서하게 추가해달라는 요청들이 생기기 시작한다.
다함께 현재 상태의 제품을 테스트한다. 이 테스트는 익숙한 개발환경을 떠나 고객의 입장이 되어 보도록 노력하는 데 중점을 둔다. 가능한 개발팀원 모두가 빠짐없이 참여하도록 한다.
개밥 먹기를 시행한다. 제품을 사서 쓰는 고객의 입장이 되어, 직접 제품을 써본다. 도그푸딩의 결과로 제품에 대한 피드백을 가능한 많이 구해온다.
PM 이라는 role name 이 지칭하는 역할은 여러 개다. 뒤 의 ‘M’ 은 Manager 인 경우가 대부분이데, 앞의 ‘P’ 가 Project, Product, Program 등으로 다양하다.
검색을 해보니 각각에 대해 정리한 글이 있다. Project Manager, Program Manager, Product Manager.
문서의 일부를 인용하면,
즉, Project Manager 는 해당 프로젝트를 진행하기 위한 권한을 위임 받은 사람이며 하나의 프로젝트 진행을 책임진다. Program Manager 는 Project Manager 의 연장선에 있는데, 현실에서는 Program Manager 한 명이 여러 개의 Project 에 참여하는 경우가 많다.
반면, Product Manager 는 이 둘과는 조금 다르다. 고객의 입장을 대변하여 그 피드백을 제품 개발에 반영할 수 있도록 수집해온다. 명확히 선을 긋는 것이 쉽지 않으나, 그 역할이 정의하는 바대로 이해하자면, Product Manager 는 마케팅 부서에 속하는 역할이다. 이 글 에서 Product Manager 의 requirement 에 MBA 가 있는 이유도 그 때문일 것이다. (다만 링크한 글에서 Product Manager 가 각 기능에 대해 명세하고 우선순위까지 정한다고 하는데, 이것은 역할에 대해 조금 오해한 것이거나 그 회사의 특수한 상황에서 기인한 것일 확률이 높다.)
개발자들이라면 Product Manager 와는 별로 만나지 않고 일하는 경우가 더 많다. 이들이 수집해온 요구사항은 다른 사람에 의해 제품에 대한 스펙으로 바뀌어 전달되기 때문이다. 이보다 매일 같이 부딫혀야 하는 사람은 Program/Project Manager 일 것이니, 이 role 에 대한 이해가 더 중요할 것 같다. 다음 글에서 Program Manager 얘기를 해보려고 한다.