2019년이 절반이 넘게 지났네요. 정신 없었던 반년이었습니다. 작년 회고의 마지막을 보니, “올해 목표를 명확히 하자”는 얘기가 있던데, 음.. 명시적으로 목표를 제대로 정리해 놓지는 않았네요. 그래도 “테스트 커버리지 증가” 와 “접근성 향상”을 중요 목표로 잡았었고, 이 목표에는 나름 부합하는 전반기 였던 것 같습니다.
아케이드 비디오 타입 추가
“프레임워크 분리”라는 작업의 진가를 느낄 수 있었던 작업이었습니다. 아케이드라는 기능을 별도의 프레임워크로 빼 놓았기에, 상당히 큰 규모의 작업이었음에도 병렬로 진행되던 다른 작업들과 컨플릭 거의 없이 순조롭게 기능을 만들 수 있었습니다.
특히 동영상 재생 모듈을 만들 때도, 딱 동영상 재생 모듈만 개발 할 수 있는 환경을 만들 수 있었기에, 생각보다 많은 시행착오를 겪었음에도 불구하고 빠른 시일 안에 개발을 끝낼 수 있었습니다.
다만 현재는 Youtube의 iframe을 활용하는 방식의 동영상 재생 방식을 쓰고 있는데, 여러가지 한계를 느끼고 있습니다. 무엇보다도 Youtube의 경우에는 일시정지를 했을 때, 내가 딱 일시정지를 한 시점의 프레임에 일시정지가 되지 않고, “가장 가까운 일시정지 가능한 프레임”으로 이동해 일시정지가 되는 시스템이어서 그만큼 정교함이 떨어집니다.
추후 비디오 파일을 자체적으로 우리 서버 및 앱에서 다루게 되거나, 혹은 Vimeo등의 다른 비디오 서비스 API를 활용하게 되더라도 그런 변화에 유연하게 대처 할 수 있도록 API를 만든다고 만들었는데, 음… 정말 그런지는, 나중에 그런 순간이 왔을 때 알게 되겠죠?
OSS 라이센스 표시 추가
입사하고 가장 잘 한 일이라고 스스로 생각하는 일입니다. 오픈소스 소프트웨어를 쓴다면, 마땅히 라이센스에 따라서 Credit을 표시 해 줘야만 합니다. 이런 걸 존중해야 한다는 건, 학부생 시절이나 혹은 학원 수강생 시절에 충분히 교육을 받아야 하는 부분이라고 생각하는데, 안타깝게도 OSS를 쓰는 방법을 가르치는 곳들은 많아도 그것을 존중하는 법은 그 만큼 중요하게 여겨지지 않는 것 같습니다.
저도 우리 앱이 이런 라이센스를 제대로 표시하지 않고 있다는 걸 깨닫고 처음에는 꽤 충격을 받았습니다. 하지만 곧바로 동료들을 설득했고, 동료들은 다행히 제 의견에 빠르게 동의 해 주었습니다.
처음에는 앱 내부의 설정 페이지 등에 라이센스란을 따로 만드는 방식으로 만들었다가, 아예 iOS설정 앱의 Settings.bundle안에 Acknowledgement를 넣는 방식으로 바꿨습니다. 왜냐면 설정페이지 같은 경우는, 로그인 유무에 따라 접근 하지 못 할 수도 있지만, Settings.bundle안에 넣는 방식은 언제 어디서든 접근 가능 하기 때문이지요.
앱 런칭타임 측정 시작
WWDC의 여러 세션 및 문서를 보면, 애플은 앱런칭타임을 굉장히 중요하게 생각한다는 것을 알 수 있습니다. 실제로도 애플이 만든 아이폰앱들을 실행해보면, LaunchScreen을 볼 일이 거의 없이 순식간에 켜지는 것을 볼 수 있습니다.
빠른 런칭타임은, 고객에게 편리함을 줄 뿐만 아니라 “신뢰감”을 줍니다.
•
이 앱은 고성능 앱이다
•
이 앱은 가볍다
•
이 앱은 쓸데 없는 짓(?) 을 하지 않는다
라는 인상은, 그대로 DAU로 이어지게 됩니다.
하지만 많은 개발자들이 앱런칭타임에 대해 우리가 할 수 있는 일이 별로 없을 것이다 라던가 그 짧은 몇 초는 체감하기 어려울 것이다 같은 이유로 앱런칭타임에 신경을 많이 안 쓰시는 것 같습니다.
하지만 막상 들여다보면 생각보다 제가 할 수 있는 일이 굉장히 많았습니다. 기나긴 applicationDidFinishLaunchingWithOptions 의 내용물들을 줄이거나, 다른 곳으로 옮기거나, 비동기로 실행함으로써 기존 런칭타임의 1/2 수준으로 런칭타임을 줄일 수 있었습니다.
무엇보다 앱런칭타임에 신경을 쓰게 되면, iOS의 빌드과정이나 프레임워크의 구조 등 여러가지 기존에 관심을 가져보지 못했던 주제들에 눈을 뜨게 됩니다. 당장 그 분야들에 대해 전문가가 되지는 않더라도, 내가 공부해야 할 새로운 분야 가 있다는 걸 인지하게 되었다는 것 만으로도, 앱런칭타임에 신경을 쓰게 된 것은 아주 잘 한 일이었다고 생각합니다.
새로운 PR 컨벤션
기존에 저희 팀에서 PR제목을 지정할 때는, JIRA의 이슈 넘버를 따서, “fix: APPISSUE-1431” 같은 식으로 지었습니다. 물론 이 이슈를 JIRA에서 직접 찾아 들어가면 해당 이슈의 히스토리를 파악할 수 있고, 그 파악된 히스토리를 바탕으로 코드를 리뷰하면 문제없이 코드를 리뷰 할 수 있었습니다.
하지만 사람 마음이라는게 간사해서, 종종 해당 JIRA이슈에 들어가지도 않고 그냥 바로 코드를 리뷰하게 되기도 하더군요. 아무래도 이슈번호를 복사해서, JIRA사이트에 들어가서, 그걸 붙여 넣어서 검색을 해서 새 창을 띄워서 히스토리를 파악하는 과정이 귀찮았던 것이죠.
그래서 아예 제목 자체를 “Fix: 어디어디의 버튼이 응답이 없는 현상” 으로 짓도록 컨벤션을 바꿨습니다. 사실 지라이슈의 내부에 들어가도, 이 제목이 내용 자체인 경우가 많더군요. 이렇게 제목에서 문제의 맥락을 파악하고 나니, 번거롭게 지라에 직접 들어가지 않고서도 충분한 맥락을 가지고 Github에서 바로 코드리뷰를 진행 할 수 있었습니다.
새로운 네이밍 컨벤션
저희 팀은 가급적 커밋메시지는 가급적 72자 안에 작성하려 노력하고 있습니다. 그런데 이 룰을 따르려 하다 보면 “SomeViewController에서 이러저러한 일을 하기 위해 “ThatViewController”에서 저러저러한 작업 진행” 같은 문장에서 “ViewController”를 “VC”로 줄이고 싶다는 욕망을 느끼게 되죠. 그래서 저희 팀에서는 ViewController및 ViewModel처럼, 아키텍처와 관련된 클래스들은 HungarianNotation을 쓰기로 했습니다. 어차피 커밋메시지에서 그렇게 줄일 거라면, 실제 이름도 그렇게 짓자는 거였죠. 물론 Hungarian Notation은 앞으로 쓰지 말자는 추세이기는 하지만, 팀원들이 동의한 규모 안에서 제한적으로 적용하는 만큼 오히려 Readability에 도움이 될 거라고 판단했습니다. 이 판단이 옳을지 그를지는… 역시 시간이 지나면 알게 되겠죠?
Mocking Test의 확대 적용
전문번역가카드를 테스트하는 일은 아주 어려웠습니다. 테스트 해야 할 프로세스가 아주 많고 길었거든요. 간단하게 예를 들면
•
요청자가 전문번역가에게 견적 요청
•
전문 번역가가 요청 수락
•
전문 번역 시작
•
마감 다가옴(?)
•
전문 번역 제출
•
or 마감 지남(!!)
이런 종류의 프로세스가 있었습니다.
따라서 “마감 지남” 을 표시하는 UI가 제대로 나오는지를 테스트하려면, 위의 프로세스를 모두 거쳐야만 했었지요. 뭐 하나를 테스트하려면 아주 지난한 과정을 거쳐야만 했습니다.
하지만 아래 영상처럼, MockingUITest를 만들어서, “마감이 지났다고 쳤을 때 카드 UI가 어떻게 보여야 하는지”를 테스트 할 수 있게 되었습니다. 즉, CardUI만을 담당하는 별도의 프레임워크를 import한 작은 앱을 따로 만들어서, 그 앱에서 UI테스트를 돌리는 방식이죠.
WWDC 참여
올해 가장 즐거웠던 기간이었습니다. 길거리에 개발자가 널린 곳에서 아무나 붙잡고 개발 이야기를 마음 껏 할 수 있는 환상적인 기간이었습니다. 너무나 멋진 많은 분들과 정말정말 재미있는 얘기를 실컷 나눴습니다. 내년에는 갈 수 있을지 없을지 모르겠지만, (돈이 아주 많이 들긴 했습니다) 적어도 격년 단위로는 꼭 가야 할 것 같습니다.
주 1회 블로그 글 쓰기
가급적 주 1회 블로그에 글을 쓰기로 했습니다. 5월부터 시작한 일인데, WWDC기간을 비롯해 몇 주 정도는 다짐을 지키지 못한 적도 있었습니다. 하지만 그래도 Notion에 글을 쓰니까 아무래도 훨씬 쉽게 글을 쓰게 되고, 그래서 좀 더 지속적인 글쓰기가 가능해 진 것 같습니다.
특히 Medium에 글을 쓸 때는, 매번 코드 하이라이팅을 위해 gist를 만드는 등의 수고로움이 따랐고, 그런 수고로움을 떠올릴 때부터 글쓰기가 싫어진다든가 하는 부작용이 있었는데, 아무런 부담없이 Notion에다가만 블로그를 쓰니까 훨씬 부담이 준 것 같습니다.
Notion에 글을 쓸 때의 유일한 단점은 피드백입니다. 사람들이 어떤 글을 많이 읽었는지를 알기가 어렵고, 또 이 글에 댓글을 달기도 어려운 구조죠. 하지만 트위터의 Moment로 Notion의 글들을 관리함으로써, 얼마나 많은 분들이 이 글을 읽어주셨는지를 어느 정도 감을 잡을 수 있었고, 또 피드백도 트위터의 멘션으로 받을 수 있기 때문에 당분간 이 포맷으로 글을 써도 제가 필요한 수준의 피드백은 받을 수 있을 것 같습니다.
WordPress, Jeykeyll, Medium등 여러 플랫폼을 사용해 보았습니다만, 결국 “글쓰기가 쉬워야 글이 써진다”는 명제가 정말 진리구나 라는 사실만을 깨달았습니다. 그리고 현재로서 Notion은 제게 가장 글쓰기가 쉬운 플랫폼입니다. 또 Notion은 현재도 계속 진화중이기 때문에, 언젠가는 블로그 플랫폼으로서의 여러 기능들이 추가 될 수도 있지 않을까 하는 행복회로를 돌려봅니다.
•
Update
◦
이 글은 이제 WordPress로 옮겨졌네요. 결론적으로 “돈 내고 WordPress.com” 쓰는 것이 글쓰기도 쉽고 관리도 쉽고 피드백 얻기도 쉽고 암튼 모든 조건을 만족하는 선택이었습니다. 돈이 최고네요! 많이 벌어야겠어요! 
심플 포모도로
제 개인 프로젝트 앱인 심플포모도로를 어느 정도 완성했습니다. 하지만 앱스토어에 아직 제출을 못했네요. 앱스토어에서 돈을 벌려고 하니까 생각보다 훨씬 자질구레한 여러가지 절차가 있더군요. 사실 막상 하나하나 처리해 나가면 별 것 아닐 거라고 생각합니다만, 개발 이외의 문제를 맞딱드리기가 귀찮아 자꾸만 미루고 있네요. 빠른 시일 내에 앱스토어에 제출하고, MacOS버전 및 WatchOS버전도 빨리 만들어야겠습니다.
하반기 계획
하반기에는 SwiftUI를 좀 다뤄봐야 할 것 같습니다. 아마 관심있는 개발자 분들을 모아서 스터디를 모아보려 하는데, 음… 잘 될 지 모르겠네요. 작년말에 사내에서 플러터 스터디를 했을 때는, 각자 플러터로 원하는 앱을 만들어서 먼저 만드는 사람이 졸업 하는 방식이었는데, 나쁘지 않았던 것 같습니다. 생각만 하고 있으면 안 하게 될 게 뻔하니, 이런 곳에라도 적어서 조금이라도 동기부여를 시켜야겠네요. 과연 2019년 회고 때 이 하반기 계획에 대해 어떻게 평가하게 될지 벌써 궁금합니다.