Let’s Swift에서 새롭게 알게 된 내용들 중 인상 깊었던 내용들을 정리해 보았습니다. 세션에서 발표된 내용들은 이미 http://letswift.kr/2019/ 에 올라와 있거나 올라올 예정이므로, 저는 주로 티타임에서 들었던 내용들 중 인상깊었던 내용들을 위주로 적어보겠습니다.
iOS 프리랜서 생활
사실 저는 프리랜서 생활은 감히 엄두를 내지 못했습니다. 위시캣등의 사이트에 올라와 있는 프리랜서 분들의 포트폴리오가 너무 멋지고 쟁쟁해, 나같이 보잘 것 없는 사람에게 일을 맡길 사람이 있을리가 없다고 생각해버린거죠.
하지만 장왕수님은 다른 이야기를 해주셨습니다. 현재 iOS개발자에 대한 수요는 그야말로 빗발치는 수준이라고 말이죠. 자연스럽게 일거리를 어디에서 구하느냐는 질문이 나왔습니다. 저는 당연히 프리랜서 일은 크몽이나 위시캣 같은 곳에서 일을 구해야 하는 줄 알았어요. 하지만 왕수님의 대답은, “잡코리아 등에 이력서, 포트폴리오 등을 올려 놓으면 전화가 아주 많이 온다”는 것이었습니다.
크몽 같은 곳에서는 어떤 완제품을 기간 안에 납품하는 조건의 계약이 많은데, 잡코리아를 통해 전화 오는 계약들은 대부분 단기 계약직이라는 얘기도 해주셨습니다. 특정 기간 동안 특정 회사에 출근하여 그 회사에서 지시하는 업무를 수행하고, 계약 기간이 끝나면 깔금하게 헤어지는 방식의 계약이 훨씬 부담없고 또 많다더군요.
이런 계약의 장점은, 보수가 일반적으로 (상당히!) 더 많고, 인간관계에서 오는 스트레스가 상대적으로 적다는 것이랍니다. 다만 관리되지 않은 코드베이스에서 일해야 하는 경우가 많고, 개발자로서 성장하기에는 좋지 않은 환경이라고도 하셨죠. 또 대기업들 중에는, 프리랜서 기간을 연차로 계산하지 않는 곳들도 많다는 것도 알게 되었습니다.
SendBird의 sdk개발기
SendBird의 황규영님께서 진행해 주셨습니다. sdk개발은 평소에 접해볼 일일 적어서 굉장히 흥미로웠어요.
sdk개발자가 가장 신경쓰는 지점 중 하나는 backward compatibility라고 합니다. 고객의 앱은 낮은iOS 버전을 지원하고 있는데, 내가 만든 SDK가 minimum version을 올려버려서 고객의 앱이 덩달아 minimum version을 올려야만 하는 상황이 오면 안 되니까요.
그래서 Backward Compatibility를 지키기 위하여, 이를 방해하는 어떤 디펜던시도 들이지 않기 위해 굉장히 노력한다고 하셨습니다. 실제로 지금도 WebSocket통신을 하는 부분만 외부 라이브러리로 해결하고, 그 외에는 어떤 의존성도 없다고 하시더라고요.
물론 이제는 binary framework이 지원되기 때문에, 이런 제약에서 앞으로는 좀 더 자유롭겠지만, 이런 제약 아래서 개발을 하는 것도 굉장히 재미있을 것 같았습니다. 어디에도 의존하지 않으려 하다보면, 그만큼 언어와 하드웨어, 프레임워크에 대해 좀 더 깊은 식견을 가지게 될 테니까요.
가장 안타까웠던 이야기는, 크래시 리포팅에 대한 이야기였습니다. 저는 제가 만든 앱에서 크래시가 발생하면, 바로 크래시리포트를 보고 제가 짠 코드의 정확히 어디서 크래시가 나왔는지를 알 수 있지만, sdk개발자는 본인들의 코드가 다른 회사의 앱에 실려서 나가는 것이기 때문에 크래시 리포트를 직접 볼 수 없는 경우가 많다고 하더군요. 고객사에서 크래시 지점을 스크린샷으로 찍어서 보내주는 경우도 있고, 고객사의 담당자가 개발자가 아닌 경우도 있어서 원인을 파악하기 위해 아주 긴 전화통화를 하는 경우도 있었다고 합니다.
이런 상황을 막기 위해 매우 방어적으로 코딩하고 또 방대한 테스트케이스를 작성했다고 해요. 사실 앱개발에서는 테스트를 작성하기 어려운 분야가 많은데, 그래도 sdk에서는 테스트를 작성하기 용이한 분야가 더 많을 것 같네요. 테스트를 많이 작성해야 한다는 것은 부담일 수도 있겠지만, TDD의 경쾌한 리듬으로 개발을 할 수 도 있을 것 같다는 생각을 했습니다.
쏘카의 개발 문화
VCNC가 쏘카에 합류 했을 때, 쏘카앱의 상태는 굉장히 좋지 않았나 봅니다. 사실 당시의 신문기사들이나 여러 매체에 올라온 글들을 읽어봐도, 단지 쏘카 앱의 품질이 나쁜 수준이 아니라, 조직문화 전반에서 어떤 문제가 있었던 것은 사실이었던 것 같습니다.
VCNC에서 쏘카로 넘어오신 우경재님은, 그 상황을 꽤 극적으로 바꾸신 듯 합니다. 팀원들은 좋은 품질의 제품을 만들고, 또 자발적으로 여러 기술을 공부하는 모임도 만들어지는 좋은 문화가 자리잡게 된 것 같습니다. 당연히 어떤 분께서 “그런 좋은 문화를 어떻게 퍼뜨릴 수 있었는가?“라는 질문을 하셨죠.
이에 대한 경재님의 대답은 단순했습니다. 회사의 결정권자가 경재님에서 충분한 권한을 위임해 주었기에 무리없이 나쁜 문화들을 없애고 좋은 문화들이 자리 잡히도록 유도 할 수 있었다는 거지요. 어찌보면 힘빠지는 이야기 일 수도 있겠지만, 굉장히 중요한 이야기라고 생각합니다. 결국 유능한 사람에게 충분한 권한을 주는 것이 회사 운영의 처음이자 끝인 것 같아요.
또 쏘카가 SignInWithApple을 상당히 초반에 도입한, 또는 도입 할 수 있었던 배경을 여쭤보았습니다. 경재님께서는, “애플의 여러 기능들을 우리가 적극 활용하고 있다”는 점을 애플에 어필하고, 그로 인해 앱스토어에서 Featured 되기 위해, 짧은 기간안에 조금은 무리를 해서 기능을 완성시켰다고 하시더군요.
사실 저도 WWDC에서 돌아오자마자, “9월에 앱스토어에 피쳐 되는 것”을 목표로 개발을 시작했습니다. 처음에는 시리 단축어를 노렸어요. “시리야, 플리토로 ‘사랑해 번역해줘'”를 말하면, 시리가 플리토로 번역해주는 기능을 만들려 했지요. 하지만 놀랍게도 iOS13에서는 시리가 그냥 한국어를 번역해 주고 있었습니다.
거기서 김이 새고, 저희 팀은 9월 전까지 다크모드를 지원하는 것을 목표로 움직였습니다. 그런데 다크모드 지원은 생각보다 손이 많이 가고 시간이 오래 걸리는 작업이더라고요. 결국 9월 중순에 다크모드가 포함된 버전을 배포 할 수 있었지만, 미래 애플 측에 연락을 넣지 않았기에 앱스토어에 소개되거나 하지는 못했습니다.
사실 생각해보면 올해 발표된 여러 기능들 중 가장 빠른 시간 안에 구현 할 수 있는 기능은 Sign in With Apple 이었던 것 같아요. 물론 백앤드 개발자분들의 스케줄이 잘 맞지 않아서 포기하게 된 측면이 강하지만, 우리 앱이 앱스토어에 피쳐 될 수 있는 좋은 기회라는 점을 좀 더 강조 했더라면 우선순위를 좀 더 높일 수 있었을테고, 그랬다면 플리토도 9월에 앱스토어에 한 번 더 피쳐 될 수도 있었을텐데 하는 생각이 들었습니다.
스타일 쉐어의 개발문화
스타일쉐어에서 준비한 티타임은 TV쇼를 방불케 할 정도로 본격적이었습니다. 다른 티타임 세션들은 자연스럽게 여러 질문이 오고가는 스타일이었다면, 스타일쉐어의 티타임은 물론 여러 질문들이 오고가기는 했지만, 어디까지나 전수열님이 의도한 몇 가지의 굵직한 주제들을 중심으로 이야기가 진행되었던 것 같습니다.
초반에는 스타일쉐어의 PR문화에 대해 이야기 해 주셨는데, 직접 회사의 Private저장소의 PR들을 보여주면서 PR문화를 소개해 주셨어요. 다른 회사의 PR을 본 것도 처음이어서 굉장히 흥미로웠지만, 그 PR들 하나하나에 들어간 정성들이 보여서 굉장히 자극이 되었습니다.
저도 평소에 PR을 정성껏 쓴다고는 자부하고 있습니다만, 스타일쉐어의 PR들을 보고 더 분발해야겠다고 생각했어요. 이 코드를 작성하게 된 동기, 구현 방식, 테스트한 내용을 충분히 글로 적었을 뿐만 아니라, 간단한 UML같은 것들을 아이패드로 그려서 첨부하기도 했더라고요. 해당 화면의 스크린샷이나 동영상이 첨부된 경우도 많았고요. “이 정도 되는 PR이라면, 리뷰 할 맛이 나겠다”라는 생각이 들었습니다.
또 PR을 편하게 하기 위해 XcodeGen을 사용한 이야기도 해 주셨습니다. 사실 저희도 pbxproj파일의 컨플릭을 막기 위해 XcodeGen을 도입하려 시도한 적이 있었습니다. 하지만 XcodeGen을 제대로 실행할 yml파일을 만드는 일이 결코 만만치 않았어요. 아직 pbxproj파일을 자동으로 yml파일로 만들어주는 툴이 아직 없거든요. 그러니 제가 만든 yml파일을 바탕으로 XcodeGen이 만들어낸 pbxproj 파일이 기존의 pbxproj파일과 동일한 행동을 하는지를 확인해야 했는데, 그걸 일일이 비교하고 있자니 눈이 빠질 것 같아 중간에 포기한 기억이 있습니다. 제가 뭐 하나라도 놓쳐서 문제가 생길 수도 있겠다는 두려움도 있었고요.
그런 어려움을 어떻게 극복했는지를 여쭤보았는데, 대답은 역시 간단했습니다. “눈이 빠지게” 두 파일을 비교하면서 yml파일을 만들었다는 거지요.
하지만 생각보다 이 “눈이 빠지게” 두 파일을 비교하는 기간은 사실 하루 정도 밖에 걸리지 않았다고 합니다. 오히려 그 외의 여러가지 분야에서 삽질을 하는 기간이 더 걸렸다고도 하셨지요. 하지만 그 모든 삽질의 끝에 XcodeGen을 성공적으로 활용할 수 있게 되었고, 결국 그 투자는 충분히 값어치를 하고 있다고 해주셨습니다.
사실 지금의 플리토 코드베이스는 워낙 모듈화가 잘 되어있어서 컨플릭이 날 일이 거의 없고, 심지어는 pbxproj 파일이 눈에 익숙해져서 컨플릭이 나도 어느 정도 부담없이 수정을 할 수 있게 되어서 XcodeGen에 대한 필요가 높지는 않습니다. 하지만 다음에 다른 프로젝트를 하게 된다면, 반드시 시도해 봐야겠다고 생각했습니다.
또 스타일쉐어는 기존에는 다른 여러 회사들처럼 Jira와 Confluence를 활용해서 문서를 작성했지만, 지금은 Notion을 주로 사용하고 있다고 합니다. Confluence에서는 문서를 작성하는게 불편하고 재미없어서 자꾸 문서를 작성하지 않게 되었지만, Notion으로 옮기고 나니, 문서 작성이 재미있고 부담이 없어져서 문서의 양 자체가 확연히 늘어났다고 하더군요.
저희 팀에서도 비슷한 문제의식을 느껴서 Notion으로의 이전을 시도해 보았습니다만, 생각보다 쉽지는 않았습니다. Confluence의 문서들이 비록 여러 export를 지원하기는 하지만, 모든 문서가 한 큐에 아름답게 Notion으로 export되지는 않았기 때문에 결국 문서들을 하나하나 확인해 가면서 옮겨야 했죠. 하지만 그렇게 옮기기에는 그 동안 쌓인 문서의 양이 너무 많았기 때문에 결국 Notion은 개발팀 내에서만 활용하고 다른 팀들과 소통해야 하는 곳에서는, 그리고 다른 팀들은 여전히 Confluence를 쓰고 있지요.
스타일쉐어에서는 그런 문제를 어떻게 해결했냐고 여쭤보았는데, 그 대답이 굉장히 인상적이었습니다. 먼저 개발팀 내에서부터 차근차근 이전을 시도하고, 또 한 번에 옮기는 것이 아니라 “손이 닿는 문서는 무조건 Notion으로 옮기는” 전략으로 점진적으로 문서들을 이전했다고 합니다. 그렇게 1년이 흐르고서도 Confluence나 Google Drive에 남아있는 문서들은, 마치 1년 내내 입지 않았던 옷을 앞으로도 입지 않을 옷으로 여기고 처분하듯, 앞으로도 자주 보지 않게 될 문서들로 여기고 아카이빙했다는 것이지요.
아주 합리적이고도 부담이 없는 방법이라고 생각했습니다. 플리토에서도 스타일쉐어의 이런 전략을 참고해서 Notion을 더 적극적으로 활용하자고 해 봐야겠어요.
마치며
짧은 시간 동안, 정말 어디가서 돈 주고도 들을 수 없는 귀중한 경험들을 들을 수 있었던 소중한 시간이었습니다. 열심히 티타임을 준비해주신 발표자분들과 행사를 준비해주신 분들에게 다시 한 번 감사드립니다. 