플리토 취업
나중에 알았지만, 동료들은 내 면접을 보고 굉장히 흥분했다고 한다. 기술면접 질문에 대해 눈을 반짝이며 노트에 그림을 그려가며 열심히 설명하는 지원자는 없었다고 말이다. 그 전에 여러 면접에서 떨어지면서 자신감이 많이 떨어진 상태였지만, 결과적으로 내 열정과 가치를 높이 평가해주는 동료들을 만나 굉장히 즐거운 한 해가 되었다.
일반적으로 회사생활이 즐겁기 어렵지만, 2018년의 회사생활은 즐거웠다. 매일 출근하면서 “오늘은 또 뭘 해볼까?”라는 생각으로 가슴이 뛰었다. 뭘 해보자고 했을 때 적극적으로 반응해주고 격려해주고 칭찬해주는 동료들이 있어서 가능한 일이었다. 회사생활에서 사실 힘든 건 결국 인간관계인데, 그런 면에서 좋은 팀원들을 만나 행복했다.
코드리뷰
처음에는 서로 스타일이 맞지 않는 부분이 있었고 맞춰가면서 어려운 부분도 많았다. 하지만 코딩 가이드라인을 다시 정하고, 정적분석기를 도입하고 필요한 경우 짝프로그래밍을 하기도 하면서 점점 호흡을 맞추어 나갔다.
기여한 것
•
앱 시작시 콜백헬 개선과 테스트코드 도입CallBackhell로 이루어져 있던 앱시작화면을 RxSwift를 사용해 재작성했다. 사용자에게는 그저 로딩화면이겠지만, 여기서 뭔가 문제가 생기면 앱 전체에 영향을 끼치기 때문에 굉장히 무서웠다. 실제로 선임개발자는 내가 이 일을 벌이는데에 우려를 표하기도 했다.하지만 앱시작 로직은 중요한 만큼 이해하기 쉬어야 한다고 생각했기 때문에 결국 리팩토링을 단행했다. 아직 내 실력을 완전히 신뢰받지 못했기 때문에 테스트코드를 작성했다. 실제로 유용하게 쓰인 첫 테스트코드였던 것 같다. 실제로 이 테스트코드 덕분에 동료들이 이 코드를 더 신뢰하고 안심하고 머지할 수 있었던 것 같다. 그리고 실제로 나중에 이 코드에 실수가 있었던 것이 드러났는데, 테스트코드가 깨지면서 그 실수를 일찍 캐치할 수 있었다. 날짜와 관련된 코드여서 바로 버그가 드러나지 않았지만, 다행히 유저들한테 영향을 끼치기 전에 일찍 캐치해서 바로 고칠 수 있었다. 테스트코드의 유용성을 확인한 첫 케이스였다.
•
빌드타임 줄이기 프로젝트내가 입사했던 2018년 2월의 Xcode9 빌드 속도는 괴에엥장히 느렸다. 너무나 느려서 거의 하루종일 빌드만 하다가 퇴근하는 느낌이었다. 어서 빨리 멋진 코드를 작성해 동료들의 신뢰를 얻어야 하는데, 빌드가 느리니 내가 코드를 잘 짰는지 못 짰는지 테스트하는데 시간을 다 보내고 있었다.그래서 빌드타임줄이기 프로젝트를 깃헙 프로젝트로 만들었다. 빌드시간을 분석하고, Xcode의 여러 설정들을 바꿔보고, 프레임워크를 분리하고, 빌드를 느리게만드는 코딩 컨벤션을 파악하고 여러 노력을 기울였다.그 노력의 결과 빌드시간이 많이 줄어들기는 했지만, Xcode10이 나오니까 그냥 훨씬 빨라졌다 ㅠㅠ
•
1개 App → n개 프레임워크 분리하지만 빌드타임 줄이기 프로젝트가 아주 무용한 건 아니었다. 특히 그 중에 한 항목이었던 프레임워크 분리는 2018년에 가장 잘 한 일 중 하나라고 생각한다.일단 모델들을 대부분 FLT Foundation 으로 옮겼고, 기본 단위가 되는 view component 들도 FLT UIKit으로 옮겼다. 이 두 프레임워크만 import시킨 간단한 앱 프로젝트인 FLTPlayGround를 만들었다. 웬만한 프로토타입은 여기서 다 개발 할 수 있었다. 앱전체를 빌드하지 않았기 때문에 개발속도가 훨씬 빨라졌다.단순히 빌드시간만 빨라진게 아니라, 코드 자체가 훨씬 건강해졌다. 모델 클래스들을 별도 프레임워크로 떼어내려다보니, 아주 간단한 모델도 프레임워크로 따로 떼어내기가 쉽지 않다는 것을 깨닫게 되었다. 아주 간단하다고 생각했는데, 속성으로 아주 복잡한 모델을 가지고 있었고 그 모델들이 또 다른 클래스들과 아주 복잡한 의존성 관계를 맺고 있었다.일단 프레임워크를 만들기 위해서는 그 의존성부터 걷어내야했다. 결국 의존성주입에 어느정도 의존을 하긴 했지만, 대부분 의존성주입에 의존하지 않고 코드 자체를 없애거나(필요 없어진 코드가 많았다), Apple의 네이티브 API를 활용해서 의존성들을 걷어냈다. 지금은 탭바의 탭 별로 프레임워크를 만들려 하고있다. 최근 서비스에 탭 하나가 추가되었는데, 이 탭의 ViewModel들은 별도의 프레임워크로 관리되고 있다. 다른 탭들도 차근차근 그렇게 별도의 프레임워크로 만들 예정이다.
•
테스트코드 커버리지 2 → 30%테스트코드 커버리지를 획기적으로 올렸다. 개발자 커뮤니티에 나가서 얘기를 들어봐도, 특히 모바일 앱에서 테스트코드를 적극적으로 작성하는 회사는 많지 않은 듯 하다. 테스트코드를 작성하다보니 그 이유를 알 것 같다. 모바일 앱의 테스트자동화는 매우 어렵다. 하지만 차근차근, 아니 주말까지 투자해서 어그적어그적 테스트코드를 작성해서 테스트 커버리지를 많이 올렸다. 특히 분리해낸 프레임워크들은 80% 가까이 커버가 되고 있다. 또 내가 완전히 새로 작성한 화면들은 대부분 90%이상 테스트 커버리지를 유지하고 있다. 이것도 요령이 붙으니까 할만하지, 그렇지 않으면 금방 포기하게 된다. 이런 요령이야말로 정말 개발자들에게 필요한 지식일텐데, 이런 노하우를 다루는 리소스가 정말 없었다. 나중에 내가 정리해서 책으로 내야겠다.UI테스트를 작성했는데, 굉장히 좋은 경험이었다. UI테스트로 서비스의 핵심 로직을 안전하게 테스트를 하고 나니까 새 앱을 배포할 때 굉장히 안심이 되었다. 백개의 유닛테스트보다 하나의 제대로 짜인 UI테스트가 훨씬 안심이 된다.UI테스트는 전체 코드의 20%정도만 테스트하지만, 그 20%만 잘 돌아가는 것이 확실하다면 사실 다른 코드에서 버그가 일어나는 것은 부차적인 문제다. 예를 들어 카톡앱에서 카톡이 안되면 크리티컬하지만, 카톡 앱에서 이모티콘 구매에 문제가 일어나는 것은 나중에 고치면 된다.
•
CI 적용테스트도 어느정도 만들었겠다, Let’s Swift의 여러 세션들을 보고 자극을 받아 CI 서비스를 쓰기 시작했다. 여러 회사들의 서비스와 요금을 비교해서 Bitrise를 골랐다. 회사를 설득하기 위해 가장 저렴한 서비스를 고른 것도 있고, 동료들에게 “이거 별로 어렵지 않아요!”라면서 추천할 수 있는 예쁜 UI를 제공하기도 했기 때문이었다.하지만 CI를 돌리는 일은 쉽지 않았다. 특히 애플의 인증서들이 골치를 많이 썩였다. Bitrise의 FAQ나 다른 여러 Issue들을 봐도 우리만 이런 문제를 겪는건 아닌 듯 했다. 분명 문서에서 시키는대로 했는데도 빌드를 돌리고 30분정도가 지나면 빌드가 실패했다는 메일이 날라왔다. 아마 한 100번정도는 연달아 빌드를 실패했던 것 같다. 문서들조차 업데이트 되지 않는 문서들이 최신 문서들과 서로 다른 말을 하고 있는 경우가 있었다. 서로 다른 말을 하고 있다는 것도 시행착오를 겪고 난 뒤에나 알게 되었다. 그 과정에서 애플의 인증서 시스템에 대해 다시 철저히 복습을 할 수 있었다. 사실 각종 인증서들은 개발환경을 처음 셋팅할 때만 신경을 썼지, 정확히 뭐가 뭔지 몰랐었는데, 이번 기회에 확실하게 이것저것 이해하게 되었다. 애플은 한국정부랑 의외로 쿵짝이 잘 맞을지도 모른다는 생각을 했다. 인증의 인증의 인증을 겪는 경험은 민원 24시를 쓸때랑 비슷한 느낌이었다.다행히 결국 CI서버는 결국 잘 돌아가게 되었다. 특히 CI서버가 헝가리에 있었기 때문에, 기존에 눈치채지 못했던 여러 Formatter관련 버그들도 발견할 수 있었다. 또 앱스토어에 앱을 올릴 때마다 신경쓰던 빌드넘버/ProductionKey/ 및 여러 자질구레한 설정값들을 확실하게 검사하거나 강제할 수 있어서 실수할 걱정들을 많이 줄였다.
•
중요 버그 해결
◦
DateFormatterFlitto의 크래시율은 높지 않았지만, 아주 간헐적으로, 그리고 꾸준히 DateFormatting을 하는 코드에서 크래시가 발생했다. 하지만 아무리 노력해도 그 크래시는 재현을 할 수 없었다. 무엇보다 그 빈도가 높지 않아 팀에서는 손을 놓고 있었다.하지만 나는 오기가 생겼다. 그래서 Fabric에 올라오는 로그들을 눈을 가늘게 뜨고 열심히 살펴봤다. 그리고 그 로그들 사이에서 어떤 공통점을 발견했다. 일단 크래시 대부분이 iPhone5, 그리고 iOS10에서 발생하고 있었다. DateFormatter Crash라고 구글링하면 리소스들이 나오지 않지만, DateFormatter + iPhone5 + iOS10 으로 조합해서 구글링을 하지 바로 여러 SO 글들과 리소스들이 나왔다. 결국 문제는 우리는 당연히 사용자가 그레고리안 달력을 쓸거라 생각하고, “2018년 3월 7일”같은 날짜를 formatting하려 했는데, 사용자가 “헤이세이 20년 3월 7일”같은 날짜를 쓰고 있으니 포매팅하는데 문제가 생겼던 것이다. 그리고 그와중에 32bit컴퓨터에서는 오버플로우 문제까지 터져 앱이 크래시가 났던 것이다. 이 버그 해결은 아주 중요한 교훈을 여러 개 주었다.
▪
일본에서 달력을 “일본력”으로 해놓은 일본인들이
▪
32bit 기기인 iPhone5에서 DateFormatting을 하려 할 때 나타나는 문제였다
▪
재현이 안 되는 버그를 재현하려면, 로그를 꼼꼼히 봐야 한다.
▪
DateFormatting은 어렵다. 직접하려 하지 말고 애플에게 맡겨라
▪
글로벌 서비스를 제공하려면 생각을 글로벌하게 하고 다양한 변수들에 대해 공부해야 한다.
◦
Memory Leak사실 입사하자마자, 앱을 디버깅하면서 “메모리를 너무 많이먹는데”라고 생각을 하긴 했다. 하지만 앱을 쓰는데 전혀 문제가 없어서 별 신경을 쓰지 않고 있었다.하지만 이미지 관련 신기능을 테스트하면서, 메모리누수가 심각하다는 것을 깨달았다. 기존에는 텍스트 데이터들만 누수가 되었기 때문에 그 규모가 심각하지 않았고, 아직 유저들 대부분이 텍스트관련 서비스들만 사용하고 있기 때문에 문제가 가시화 되지 않았던 것이다.하지만 메모리 누수는 정말 심각했다. 문제가 어디서부터 발생하는지 알 수 없을 정도였다. 하지만 WWDC의 iOS Memory Deep Dive, Advanced Debugging with LLDB 등을 보면서 메모리 디버깅 스킬을 익혔다. 스킬을 익히고 보니 메모리 이슈 디버깅은 심오한 세계였다. 하지만 일단 평범한 개발자가 되기 위해서는 두 가지만 기억하면 될 것 같다.일단 메모리누수는 RxSwift에 대한 이해가 부족한 상태에서 RxSwift를 도입하던 초창기 코드들에서 발생했다. 볼 것도 없이 클로저에서 self를 strong하게 참조해서 발생한 문제였다. 문제는 그런 코드들이 아주 널리 펴져있었고, 특히 가장 중요한 코어 부분에 많이 있었다. 그 메모리 누수들을 모두 확인하고, 제거하고, 다른 팀원들이 그런 실수를 하려 할 때마다 코드리뷰에서 열심히 지적했다. 그 결과 평소에 200메가의 메모리를 사용하던 플리토 앱은 이제 메모리 누수 없이 100메가 이하의 메모리를 쓰게 되었다.
▪
이미지는 아주 큰 메모리를 차지한다. 설령 하드디스크에서는 그렇지 않더라도. 그러니까 커다란 메모리 누수가 발생한다면 이미지 관련 코드를 보면 된다.
▪
클로저에서 self는 주의해서 써야 한다. 안 그러면 retain cycle이 생긴다.
•
신기능 지원회사에서 누가 시키지는 않았지만, 아이폰의 신기능들을 우리 앱에 적용시켜보고 싶었다. 그러지 않고는 자존심이 상했다. 그래서 개인시간등을 투자해 아래의 기능들을 앱에 추가시켰다.
◦
시리 단축어 지원
◦
provisional notification 지원
◦
Native Speech To Text 지원
▪
기존에는 사용자의 음성입력을 구글로 보내서 STT 결과값을 네트워크로 받는 형태였다.
▪
하지만 iOS 10부터 SFSpeechRecognizer를 쓸 수 있게 되었기 때문에, 그리고 애는 LiveSpeechRecognizing도 할 수 있기 때문에 당연히 이걸 쓰는게 좋았다.
▪
하지만 이 부분의 코드들도 굉장히 오래되고 callBackHell에 겹겹히 싸여있는 형국이어서 작지 않은 리팩토링을 단행해야 했다.
▪
하지만 결국 리팩토링을 완료했고, 그 과정에서 더 테스트하기 좋은 코드들로 코드들을 잘게 쪼갤 수 있었다.
◦
password autofil 지원
◦
커스텀 툴팁에서 UIReferenceLibraryViewController 보여주기 지원
◦
LoadingAnimator 개선
▪
기존에는 8개의 그림파일들을 가지고 8fps짜리 애니메이션을 보여주고 있었다.
▪
하나의 그림파일로 CABasicAnimation을 사용해 60fps 애니메이션을 만들었다.
◦
Lottie 추가
▪
디자이너분들에게 “에프터 이팩트를 배워서 로띠 를 만들어주세요!”라고 요구할 수가 없었다.
▪
하지만 Lottie에니메이션을 포기할 수는 없었다.
▪
▪
내가 직접 써보고, 장단점을 파악해 디자이너 및 프론트앤드, 앱팀 분들에게 공유했다. 내년에는 좀더 예쁜 애니메이션이 들어간 앱을 만들 수 있을 것 같다.
총평
“계획 한 것을 그대로 실천”하는 한 해는 아니었다. 정보통신기사를 따려 했지만 따지 않았고, 듣기로 한 강의를 듣지 않은 경우도 있었다. 한 달에 100만원씩 꼬박꼬박 저금하려 했지만 연애를 하고 나서는 그러지 못했다.
하지만 후회되는 바는 하나도 없다. 정보통신기사를 따진 못했지만 굉장히 유익한 경험을 많이 했고, 100만원씩 저금을 하진 못했지만 연인과의 추억을 잔뜩 쌓았다.
하지만 내년에는 계획을 그대로 실천하는 한 해를 보내고 싶다. 그러기 위해 내년의 목표를 구체적이고 현실적으로 잡아야겠다.