iOS 개발자 첫 회사에서의 1년 돌아보기

 

작년 11월 초부터 면접을 보러 다닌 것 같다. 서류를 넣기 시작한 건 10월 말쯤부터였다. 원래 취업을 더 미루려고 생각했는데, 작년 10월 중순쯤 모 기업의 공채에 지원하려고 서류를 공들여 썼던 게 발단이 됐다. 그런데 서류를 다 쓰고 보니 여기만 넣기 아까워서 다른 데도 넣어보자.. 했던 게 날 1달만에 회사원의 길로 인도했다.

 

첫 회사 입사

지금 회사를 선택한 이유는 여러 가지지만, 가장 큰 이유는 라이브 서비스를 운영 중이고 실제 고객들이 10만 명 단위로 존재한다는 점이었다. 당시 면접을 봤던 보스가 면접 보실 때 지원자인 나를 정말 성의껏 대해주셨다는 점도 한몫했다. 보스의 인품이 저렇다면 조직 분위기도 괜찮겠다는 생각이 들었고, 회사 규모도 나쁘지 않아서 재직 중에 회사가 갑자기 문을 닫는 일도 없겠구나 싶었다. 면접을 보고 나오면서 붙었다는 확신이 들었다. 오퍼가 왔을 때도 바로 받아들였다.

솔직히 정말 많이 부족한 상황에서 거의 운으로 붙었다는 생각이 든다. 입사할 당시의 나는 뭔가 개념을 알긴 알았지만 어렴풋이, 혹은 반만 알고 있는 상태였다. 그래서 붙고 나서 뷰 짜는 거랑 API 통신하는 기초... 뭐 그런 걸 열심히 공부해갔던 기억이 난다.

 

프로굴에 들어가도 맥락만 알면 산다 

가장 궁금했던 게 '현업에서는 과연 어떤 스타일의 코드를 쓸까?' 하는 것이었다.

그 당시의 나는 다른 사람들과 협업해본 경험이 아주 적어서 내가 작업하는 방식이 맞는지, 프로젝트의 organization은 어떻게 해야 하는지, 코드 정리는 어떻게 해야 하는지 등 여러 가지 의문을 품고 있었다. 한마디로 내 스타일에 크게 자신이 없었다.

회사 코드라 자세히 설명할 순 없지만, 지엽적인 기능 구현은 스택오버플로우에서 찾아서 조금만 수정해서 사용하기도 한다. 하지만 핵심 기능들은 이미 전임자가 쉽게 작성할 수 있도록 작업해둔 것이 있거나, 미리 extension으로 빼서 작성돼 있었다. 미리 작업된 게 있는 경우에는 그 방식을 따르면 됐는데, 문제는 그 방식이 바로 눈에 익지는 않는다는 점이었다.

입사하고 가장 어려웠던 것들을 3가지만 꼽는다면 다음과 같다.

• API 통신부
• 컬렉션뷰 구성
• 플레이어 (가장 어려움)

신입이 어려워서 헤매는 건 당연한 일일 수도 있겠지만, 그 때 나는 아무때나 질문하는 건 좋지 않다고 생각했고, 찾아보면 나오는 뻔한 내용을 질문하지 않으려고 최대한 알아낼 수 있는 데까지 알아내기 위해 업무 시간 내내 열심히 코드를 봤다. 어차피 2주 반 동안은 큰 에픽 할당이 안 돼서 이슈 보드에 남은 오래된 잔여 이슈들을 탈탈 털어서 해결할 수 있는 충분한 시간이 있었다. 그렇게 이해한 것들을 컨플루언스에, 노트패드에 흐름을 적어가며 노력했다.

 

노력은 빛을 발했다. 입사하고 열흘 뒤, 플레이어 심장부에 가까운 곳에서 일어나는 에러를 잡고 오래된 이슈 티켓 하나를 닫았다. 그 이슈는 이전 클립이나 다음 클립으로 넘길 때 슬라이더가 다른 위치로 이동하면서 깜빡이는 것처럼 보인다는 이슈였다. 

그렇다면 이 이슈를 촉발하는 원인은 "클립을 이동하는 것"이다. 그래서 코드에서 클립 이동부를 찾고, 그것이 종국에 어디까지 흘러가는지를 계속 추적했다. 그러다 보니 플레이어 코드까지 도착하게 됐는데, 원인은 곧 찾아낼 수 있었다.

버퍼링이 있을 때 그 값을 broadcast하고 있었다. 슬라이더는 그 버퍼링이 있는 값을 잘못 받아서 잠시 다른 위치로 이동하게 되었고 이슈가 그래서 생기는 거였다.

이슈는 금방 닫을 수 있었고, 조금 행복해졌다. 앱의 핵심인 플레이어를 조금 더 잘 알게 됐다는 생각이 들어서였다.

플레이어는 지금도 매우 복잡하고, 나도 로직을 다 외우지는 않으니 이슈가 자주 나오는 것 같은 부분만 흐름을 알고 있다. 이슈를 해결하면서 깨달은 점은 아무리 어렵고 복잡한 코드에서 발생한 이슈라고 하더라도, 실타래를 잡아 엉킨 부분을 푼다는 느낌으로 실타래 끝을 찾아내는 데 일단 집중한 뒤 맥락을 잡아 들어가면 생각보다 어렵지 않은 이슈일 수도 있다는 점이다. 

 

입사 다음날의 티켓

입사하고 첫날은 인사하러 다니고 회의에 들어가고 컴퓨터에 이것저것 설치하고 코드를 보다가 집에 갔다.

그 다음날 아침, M 대리님이 캔틴에 가봤냐고 하시면서 같이 캔틴에서 얘기나 하다가 오자고 하셨다. 한 30분 정도 담소를 나누고 돌아오니 내 앞으로 티켓이 할당되어 있었다. 

난... 순간 뭔가 잘못된 건 아닐까 하는 생각이 들었다. 어제 입사했는데 티켓을...? 지라를 열어 티켓에 등록된 기획서를 확인해보니 그렇게 어려운 내용은 아닌 것 같았지만 혹시 잘못 할당된 건 아닐까 하는 생각이 들었다. 일단 기획서를 보고 코드에서 해당하는 부분을 찾아 이 부분을 어떻게 수정할지 방안을 몇 개 정도 생각한 다음 티켓을 할당해주신 이사님께 가서 여쭤보니, 브랜치 전략과 실무를 익히는 데 이만한 게 없다면서 직접 해보라고 말씀해주셨다. 꾸벅 인사하고 자리로 돌아가서 일을 했다. 기획에서 요구하는 부분은 어떤 버튼을 단순히 삭제하는 것이었고, 나는 해당 버튼을 다른 데서도 사용하는 곳은 없는지 확인한 다음 코드를 삭제해 커밋을 올렸다.

생각해보면 그 때 계속 코드를 보고 있었다면 적응하는 게 좀 늦어졌을 것 같다. 나는 실무를 겪고 계속 도전하면서 어렵고 망신당할 거 같으면 습득력이 빨라지는 사람이라 그 방식이 정말 좋았다고 생각한다. 물론 그 때는 좀 막막했지만 말이다. ^^;

 

카플레이와 SceneDelegate 도입의 문

입사하고 약 3주 정도는 작업이 없어서 다른 분들께 할당됐지만 오랫동안 해결되지 않은 티켓들을 내가 가져가서 해결하기 시작했다. 플레이어 이슈, 뷰 이슈... 다양한 부분에서 발생한 이슈들을 해결하면서 코드가 어떻게 동작하는지 조금씩 익숙해지기 시작할 때 정식으로 에픽 프로젝트가 주어졌다.

안드로이드는 작년에 오토를 배포했지만 애플은 작업할 사람도 없고 해서 카플레이를 진행하지 않았다고 했다. 그래서 카플레이는 기획서도 없고, 오토 기획서를 보면서 거의 그대로 따라하는 게 요구사항의 전부였다.

언뜻 보면 쉬워보이지만 사실 카플레이를 서비스하는 앱은 지도, 음악, 간혹 메신저쯤인지라 별로 많지가 않다. 사정이 이렇다 보니 개인이 정리해둔 블로그나 팁 문서 등은 거의 없고, 공식문서에 의존해서 만들어야만 하는 피쳐였다(하지만 지나고 나서 생각해보니 공식이 제일 좋은겨). 한국어로 된 카플레이 자료를 찾을 가능성은 희박했다.

다행히도 평소에도 영어로 검색하는 게 습관처럼 굳어져서 이 점은 문제가 아니었지만, 이슈가 있을 때 그 원인을 겪은 사람의 리포트가 없다는 건... 생각보다 외롭고 혼란스러운 일이긴 했다. 더구나 플레이어 기능도 품고 있다 보니 원래 플레이어가 품고 있는 이슈들이 카플레이에서도 발생할 수 있다는 리스크까지 있었다.

카플레이를 개발하면서 크게 3가지를 알아야 했다.

• 카플레이의 동작 원리
  • 특히 앱이 종료된 상태에서 카플레이만 단독으로 실행했을 때 어디까지 실행되는지
• 플레이어
• SceneDelegate 도입으로 나타날 수 있는 사이드 이펙트 (기존은 AppDelegate만 사용했다)

우리 앱은 iOS 11까지 지원하고 있었고, Scene을 사용할 일이 없어서 AppDelegate만 사용하고 있었는데 카플레이를 개발하려면 SceneDelegate가 필요하다 보니 겸사겸사 추가하게 됐다. 처음에는 자잘한 사고들이 많았다. 딥링크를 안 탄다, 소셜 회원 로그인이 안 된다 등... 개인 프로젝트를 할 때는 minimum target으로 보통 iOS 13, 14 정도를 두니까 AppDelegate만 있는 레거시 프로젝트에 SceneDelegate를 도입할 때 어떤 것들을 고려해야 하는지 생각할 필요가 없었지만 실무에 오니 그런 것도 한 번쯤 생각을 해야 했다. 어쨌거나, 좋은 기회였다고 생각한다.

 

뭐 이런저런 우여곡절이 있었지만, 사실은 카플레이를 개발하면서 묘한 행복을 느꼈다. 연말이었고, 나를 제외한 거의 모든 사람들이 연차를 소진하기 위해 사무실을 떠나 있었다. 조용한 사무실에서 애매한 것들은 질문하기 위해 남겨놓고 분명한 것들부터 만들기 시작하며 기분 좋은 두근거림을 느꼈다. 오늘 내가 이렇게 개발한 게 유저들에게 전달되겠구나. 좋은데? 

카플레이는 약 2.5주간의 개발 기간을 거치고 QA를 마친 뒤 배포됐다. 이 때... 배포하고 또 라이브 사고가 터졌지만 말이다... ^^; 

이 때 라이브 사고 터진 건 정말 두려웠다. 그야말로 눈 앞이 캄캄했다. 이사님 차가 있는 주차장까지 따라내려가서 직접 재현해보고 재생이 멈추는 걸 확인하고는 식은땀이 날 정도였다. 카플레이 시뮬레이터에서는 재현되지 않고 실차에서만 재현되는 이슈인 데다가 원인을 짐작할 수 없었다. 야근하고 열심히 검색하고 이런저런 방법을 시도하다가 이튿날 퇴근할 무렵에 마침내 해결책을 찾았을 때는 만세라도 부르고 싶은 심정이었다.

 

두 번째 업무, 현상을 재현해라

입사하고 첫 3개월간 내 역할은 iOS 파트에 쌓여 있던 숙원사업을 마무리짓는 것이었다.

카플레이 배포를 마치고 나서는 콘텐츠 다운로드 중 랜덤한 확률로 다운로드가 중단되는 이슈를 재현하는 업무를 받았다. 그렇다. 그것을 해결하는 게 아니라 재현만 하는 것이 내게 주어진 업무였다. 이왕이면 해결까지 하라고 지시하시지 왜 재현만 하라고 했을까? 이유는 그 이슈가 개발팀에서 재현이 안 된 지 4개월이 넘은 이슈였기 때문이었다. 안드로이드는 오프라인 모드가 애진작에 나갔는데, iOS는 오프라인 모드 구현은 잘됐지만 다운로드 중단 현상이 너무 자주 나타나서 QA에서 이 퀄리티로는 검증할 수 없다고 해서 작업 자체가 블락된 상태였다. 그 이슈는 절대로 해결되지 않을 것처럼 보였다.

우리는 DRM을 위해 외부 SDK를 계약해서 사용하고 있는데, 이 SDK의 문제는 아닐까 하고 모두 의심하고 있었다. 그러던 차에 입사한 나는 곧 그 실험에 투입됐다.

 

그 작업은 확실히 지루하긴 했다. QA에선 이게 언제 중단된다고 한 걸까? 난 잘 되는데... 재현이 통 안 됐다.

작업을 할당하신 이사님께서도 지루하고, 앞을 못 보는데 코끼리 다리를 만지면서 파악해야 하는 것처럼 막막할 거라고 "미안하다"라고까지 말씀하신ㅋㅋㅋㅋ 작업이었다. 하지만 입사한 지 얼마 안 됐고 나를 증명해보이고 싶다는 생각에 의욕이 넘쳤고, 열심히 시도했다.

 

그런데 계속 시도하다 보니 갑자기 재현이 됐다. 많은 클립을 다운로드하면서 이 화면 저 화면 왔다갔다하던 중 한 클립에서 다운로드가 멈췄다.

폰을 쭉 주시하고 있던 나는 머릿속으로 이런저런 가설을 세워봤다. 와이파이 속도가 느렸고, 나는 다운로드 화면을 이탈했다. 혹시 속도의 문제일까? 아니면 내가 화면을 이탈해서? 

다운로드를 취소한 다음 다시 시작했다. 그리고 화면을 이탈했다가 진입했다가를 반복했다. 10번 시도하면 1-2번 정도 재현되기 시작했다. 곧 공통점을 발견할 수 있었다. 다운로드가 거의 다 될 때쯤 화면을 이탈하면 간헐적으로 중단됐다.

왜 그럴까? 다운로드가 완료된 다음 수행하는 코드를 타고타고 들어갔다.

 

곧 원인을 발견했다.

다운로드가 100%까지 완료되면, 그 클립을 저장할 Realm 객체를 만들고 Realm에 저장하는 것까지 수행해야 했다. 그래야만 비로소 진짜 작업이 완료되는 것이었고, 그 다음 대기 중인 클립의 다운로드를 시작할 수 있었다. 이 과정 중, 동영상의 경우 자막이 들어간 클립의 경우 서버에서 자막을 받아오는 API를 요청하게 되어 있었다.

그런데 바로 그 때 화면을 이탈하면, Requestable인 뷰컨트롤러가 사라져 요청이 취소되고 completion이 실행되지 않아 그 뒤의 다운로드를 전혀 시작할 수 없었던 것이었다. 그래서 다운로드가 중단된 것으로 보이는 것이다(물론 실제로도 중단됐다).

유레카! 난 내친김에 해결도 보기로 결정했다. 원인을 알고, 그것을 고칠 방법도 알고 있으니 해결을 하지 않을 이유가 없었다.

이 이슈에는 크게 2가지 문제가 있었다.

• 연속된 다운로드 작업 중, 언제 사라질지 모르는 현재 화면을 요청 객체로 사용했다.
• 동영상이 아닌 클립을 다운로드받을 때도 자막 파일을 받는 API를 요청했다.

이 2가지를 모두 올바르게 수정했고, 그 뒤로 다운로드 중 중단되는 이슈는 다시는 나타나지 않았다.

이 이슈를 해결하고 오프라인 모드에 남아 있던 티켓을 모두 내가 받아서 2주 동안 해결한 뒤, 곧 오프라인 모드를 배포할 수 있었다. 

내가 크게 인정받게 된 때는 아마 이 때부터였던 것 같다. 프로덕트팀 부장님께서 포상으로 돈가스와 커피를 하사하셨다. ㅋㅋㅋ 정말이지 행복한 기억이다. 이 맛에 개발한다.

 

일감이 없을 때는 크래시리틱스 이슈를 없애자

3월에 구글 로그인 피쳐를 추가하고 나서는 마땅히 작업이 없었는데, 이 때 Realm 데이터베이스를 점검하고 플레이어를 수정했다. 플레이어에 옵셔널 변수를 강제로 언랩핑 시도하는 실행문이 많았고, 실제로 크래시리틱스에도 이런저런 이유로 죽는 것들 중 상당수의 출처가 플레이어였다.

나 혼자 일정을 잡아서 티켓을 만들고 브랜치를 딴 다음 플레이어의 !를 제거하고 그 자리에 ?를 넣거나 guard 문으로 nil이 아닌지 체크하는 문장들을 넣었다. 강제 언랩핑 문장이 은근히 많아서 제거하고도 제대로 플레이어가 동작하는지 테스트하는 데 시간이 조금 걸렸다. 

작업을 마치고 배포했을 때, 며칠간 그 버전의 크래시리틱스 정상종료율은 99.4% 수준을 유지할 수 있었다.

 

이 작업을 하면서 동시에 Realm 데이터베이스를 제대로 사용하고 싶다는 생각에 그 쪽도 겸해서 봤다. 물론 그렇게 쓴 데는 이유가 있을 거고 전에 작업한 사람들을 존중해야 하긴 하지만, Realm을 싱글턴으로 사용하고 있는 건 항상 마음에 걸렸다. 그도 그럴 것이, Realm 객체를 싱글턴으로 사용하기 때문에 그 객체를 생성한 메인 스레드에서만 사용해야 하기 때문이었다. 그래서 다른 스레드에서 Realm에 접근하려고 하면 어김없이 강제종료되는 무자비한 일이 일어나서 반드시 고치고 싶었다. 

내 딴에는 정말 고치고 싶어서 여러 가지 방법으로 설득을 시도했으나 결국에는 잘 안 됐다. 하지만, 덕분에 Realm을 여러 스레드 간 써야 할 때는 어떻게 써야 하는지, Realm을 제대로 쓰려면 어떻게 해야 하는지, Best practices는 무엇인지 공부할 수 있었던 기회가 돼서 후회는 전혀 하지 않는다. 어떤 작업이든 공부할 기회는 만들 수 있다.

 

장기 프로젝트와 슬럼프, 극복은 사이드로

4월이 되면서 본격적으로 뷰 작업에 들어갔다. 새로운 서비스 출시를 준비하면서 앱을 대대적으로 개편하는 작업을 했는데, 사실 뷰 작업을 딥하게 들어간 건 그 때가 처음이었다. 그 전까지는 플레이어 등을 만지면서 UI보다는 서비스에 더 집중했기 때문이다. API도 대거 개편되고 새로 생성되는 게 많았는데, 이 과정에서 백엔드 개발자인 K님, D님과 얘기를 많이 하게 됐다. 기획팀과 디자인팀과도 커뮤니케이션을 많이 시도하게 되어, 개인적으로는 이 시기부터 진정한 개발자로 거듭날 수 있었다고 생각한다.

우리는 컬렉션뷰를 구성할 때 전임자가 만들어놓은 조금 특이한 것을 사용하는데, 처음에 그걸 어떻게 쓰는 건지 모르겠어서 한 2, 3일 정도는 계속 어떻게 쓰는지를 확인했던 것 같다. 그러다가 갑자기 깨달음을 얻은 것마냥 이해해서 뷰 작업에도 속도가 붙긴 했지만, 처음 며칠 동안은 정말이지 너무 어려워서 쥐구멍 파고 숨고 싶을 정도였다.

메인 작업은 나와 J님이 분담해서 작업했다. 그 작업이 한 달 걸렸는데, 작업이 완료될 무렵에 M 대리님이 퇴사를 하신다고 하셨다. M 대리님이 맡았던 큰 작업을 J님이 맡기로 해서 이제 뷰 작업은 나 혼자 하게 됐다. 일정이 빡빡해서 5월까지는 정말 야근을 하루 걸러 하루 계속 했던 것 같다. 그렇게 하지 않으면 일정을 맞추기도, 퀄리티를 올리기도 어려웠다. 심적으로도 차라리 야근해서 일찍 끝내는 게 더 편안했다.

 

한 두 달 정도 그렇게 작업을 하다가 여름부터는 작업의 강도가 점차 줄기 시작했다. 한 달 전까진 약간 타이트하게 진행하다가 금방 루즈해지니 꼭 슬럼프가 찾아오는 것만 같았다. 차라리 일이 다시 많아졌으면, 하는 바람이 생길 정도였다.

그 즈음 휴가를 쓰고 집에서 하루 정도 쉬었다. 쉬면서 내 슬럼프의 원인이 무엇일지 생각해봤다. 회사 일로는 충분히 성장할 수 없다는 생각이 들어서, 라는 결론에 다다랐다. 사실 그렇기는 했다. 새로운 기술을 도입하는 데에도 한계가 있었기 때문이다. (어지간한 이유가 있지 않고서야 최소 버전이 iOS 13 이상이어야 하는 이유가 바로 여기 있다) 사람들도 다들 지쳐 있었고 전반적으로 텐션이 너무 떨어져 있는 것이 원인이었던 것 같다.

문득 나는 정말 오랫동안 사이드 프로젝트를 돌보지 않고 있었음을 깨달았다. 회사에서 성장할 수 없다면 사이드 프로젝트를 통해 내 스스로 성장을 도모해야 하거늘... 그 사실을 잊고 있었다.

 

그래서 9월부터 다시 사이드 프로젝트를 잡았다. 그 전에 MVC로 운영하고 일부에만 RxSwift를 도입했던 것을, 뷰모델을 전격 도입해서 한 번 배포하고, 관심을 갖고 있던 ReactorKit으로 다시 고치기 시작했다. 

회사에서 할 일을 마치고 퇴근해 집에서 내 일을 하다 보니 마음이 정리되는 것 같았다. 특히, 10월에 부산에 한 번 다녀온 게 리프레시에 도움이 많이 됐다. 

 

최근에는 새로운 사이드 프로젝트를 시작하려고 생각 중이다. 이제 ReactorKit에 조금 익숙해진 것 같지만 테스트 코드를 작성하지 않고 있어서, 기존에 작업하던 것에도 테스트 코드를 추가하고 새로 작업하는 데에도 테스트를 염두에 둘 생각이다.

 

잘한 것과 아쉬운 것

수확 - 직장 편

• 첫 프로젝트로 카플레이를 맡아 배포했다.
  • AppDelegate만 사용하던 레거시 프로젝트에 SceneDelegate를 도입할 때 고려해야 할 점들을 배웠다. (딥 링 크)
  • 앱을 켜지 않고 카플레이만 단독으로 사용할 때 고려해야 할 점들을 배웠다.
  • 백그라운드 재생에 필요한 것을 알았다.
• 두루두루 디버깅하는 방법을 배웠다.
  • Xcode 내 LLDB 디버거를 잘 다루게 된 것 같다. 콜스택을 어느 정도 읽을 수 있게 됐고, LLDB 명령어를 사용해 값을 조회하는 등 간단한 디버깅 정도는 할 수 있게 됐다.
  • Crashlytics 에러를 보고 원인을 추정해 해결할 수 있는 능력을 갖추게 됐다.
  • Sentry와 Kibana를 통해 로그를 조회하고 응답에서 에러를 찾아낼 수 있게 됐다. 특히 Sentry를 볼 줄 알게 된 것이 디버깅에 큰 도움이 됐다. Crashlytics의 경우 회원 id가 조회되지 않아서 Sentry나 Kibana 로그에서 해당 시간대와 강제종료된 곳에서 요청하는 API 등을 추정해 에러 케이스를 찾았는데 점점 정확하고 빨라지고 있다.
  • 경험 실증적으로 에러를 잡아내는 스킬이 늘고 있다. 처음 이 스킬이 나타난 건 오프라인 모드에서 블락된 작업, 다운로드 중단 현상을 재현할 때의 일이었다. 상황 판단을 빨리 해서 4개월간 블락된 작업을 1.5일만에 원인 파악 및 해결까지 완료했고, 3주 뒤에는 상용 배포했다.
• 일정 예측이 정확해졌다.
  • 프로젝트에 익숙해지고 나니까 새 작업을 맡을 때 일정을 비교적 정확하게 예측할 수 있게 됐다.
  • 그래도 혹시 모를 에러가 있을 수 있으니 버퍼를 조금 넉넉하게 잡긴 하지만, 특별한 이슈가 있지 않는 이상 항상 일정 안에 종료할 수 있게 됐다.
• 기획, 디자인과의 커뮤니케이션에 자신감이 생겼다.
  • 그 동안은 기획서나 티켓에 적혀 있는데, 혹은 너무 당연한데 바보같이 질문하는 것일까봐 질문을 망설였는데 지금은 기획서와 디자인을 꼼꼼히 확인하고도 중의적으로 해석될 수 있다거나 모호한 게 있어서 의문이 생기면 질문한다. 주로 슬랙으로 질문하는데, 말로 하는 게 더 빠르고 정확한 경우에는 가서 여쭤보기도 한다. 그러고 나면 슬랙에 구두로 답변받은 것을 정리해서 올려둔다.
  • 질문하거나 의견 제시를 하기 전에는 최대한 기획, 디자인의 의도를 살리는 식으로, 악의적인 톤으로 들리지 않도록 조심한다. 결국 사람이 하는 일이라서 감정 상하지 않게 서로서로 조심하는 게 좋은 일이라고 생각한다.
  • 개발, 기획, 디자인이 원 팀이 되어 좋은 프로덕트를 만들기 위해 노력하는 것이 중요하다고 생각한다. 다행히 다들 좋으신 분들이라 지금까지 수월하게 일할 수 있었던 것 같다.
• 남는 시간을 잘 활용할 수 있게 됐다.
  • 작업과 작업 사이, QA를 대기하거나 할 때 시간이 남을 때가 있다. 그럴 때 고정적으로 하는 일은
    • (1) Crashlytics 확인 - 최근 배포 버전에서 새로운 에러가 없는지 확인하고 해결할 수 있는 일을 잡는다.
    • (2) SwiftLint 에러 확인 - 코드 내에서 lint 에러가 있는 부분을 잡아 수정할 수 있는 부분을 수정한다.
    • (3) 내 작업 돌아보기 - 내가 작업했던 부분에서 공통으로 묶을 수 있는 부분 등을 잡아 수정한다.
    • (4) 컨플루언스 문서 작업 - 작업했던 부분 중 조금 어려웠던 부분이나 검색해도 잘 안 나오는데 어떻게든 해결한 건에 대해서는 컨플 문서를 남긴다. 문서를 작성하거나, 이미 작성된 문서를 읽기 좋게 수정한다.
    • (5) 테크 세션 준비를 위한 개인 공부 - 4번까지 했는데도 시간이 남으면 테크 세션을 위해 공부를 한다. 조만간 Realm이나 ReactorKit을 이용한 단방향 반응형 프로그래밍에 대해 한 번 준비할까 한다.

잘한 것

• 기존 사이드 프로젝트에 파이어베이스 애널리틱스를 추가했다. Crashlytics를 보려고 설치한 거긴 한데, 내 생각보다는 많은 사람들이 사용하고 있었다. 홍보도 안 했는데 어떻게 알고 설치한 걸까? 괜히 신기했다.
• 체력 보강을 위해 헬스를 시작했다. 이두에 근육이 많이 붙었고, 체중은 돌아왔지만 오히려 체중이 적었을 때보다 지금이 더 균형잡혀 보인다.
• 리프레시를 위해 피아노를 잠시 다시 시작했다. 취미의 장점은 하루 동안 쌓였던 묵은 스트레스를 아름다운 방향으로 풀 수 있다는 점인 것 같다. 사이드를 시작하면서 피아노 수업과 잠시 이별하기로 했지만, 30분 정도 걸으면 있는 연습실을 가끔 대여해 피아노를 연습할 예정이다.
• 몰랐는데 이 블로그 방문자가 50만 명을 돌파했다. ^^; 보통 조회수는 토플 글에서 많이 나오는 것 같긴 하지만, 개발을 하면서 마주치는 양질의 에러 디버깅 글을 올려 iOS 개발하시는 분들이 한 번쯤 참고할 수 있는 그런 블로그를 운영하고 싶은 마음이 있다.

아쉬운 것

• 올해 목표 중 SwiftUI와 Combine, async-await을 이용해 앱을 만들려고 다짐했지만 회사 일을 하느라 힘을 다 쏟아서 집에 오면 쉬기 바빴다. 사이드를 다시 돌보기 시작한 건 가을부터로 너무 늦었다고 생각 중이다.
• 회사 일정 외 개인 일정을 소화하는 데 시간 관리를 잘 못한 것 같다. 10분 단위로 타임 트래커를 작성해볼까 고려하고 있다.
• 회사 일을 핑계로 사이드 프로젝트나 다른 공부에 소홀했다고 생각한다. 무엇보다 계획이 제대로 지켜지지 않는 때가 많았다. 내 스스로 계획-실천-보상 피드백 루프를 형성할 수 있게끔 해야 할 것 같다.

 

내년 목표

1. SOLID 원칙을 지키는 코드를 짜고 싶다. swift를 잘 이해하고 사용하는 것도 중요하지만, 원칙을 지키려면 이론으로 학습하고 실제 적용하는 것도 병행해야 하는데 여간 쉬운 일이 아닌 것 같다. 
2. ReactorKit을 더 잘 다루고 싶다. 처음 ReactorKit을 접했을 때 어려웠던 건 뷰 사이에 어떻게 State를 전달할 수 있을지, Service를 어떻게 이용할 수 있을지 같은 것들이었는데 아직도 조금 헷갈릴 때가 있다. 헷갈리지 않고 싶다.
3. 테스트 코드를 짜는 습관을 들이고 싶다. 그런데 테스트 코드는 기본적인 내용 외에는 인터넷에 예제 자료가 그리 많지 않아서 개인적으로 공부가 필요할 것 같다. 연말에 조금씩 자료를 모아 연습을 시작해야 할 것 같다.
4. SwiftUI와 Combine, async-await을 경험하고 싶다. 사이드 프로젝트는 이것들을 이용해서 해볼까 싶다.
5. 새로운 운동을 시작하고 싶다. 집 근처에 양궁장이 있는 걸 알게 됐다. 조만간 등록하러 갈 생각인데, 헬스 외에 시작하는 새로운 운동이 될 것 같다. 활을 꾸준히 쏘고 싶다.

 

마치며

우여곡절이 많았지만 한 해가 잘 넘어가고 있다. 그간 정말 많은 일이 있었고 나도 변했다고 생각한다. 그 동안 나를 잘 지지해준 가족과 친구들(특히 같은 업계에서 일하는 ㅅㅇ 언니와 ㅈㅇ, ㅇㅇ이는 만날 때마다 힘이 된다. 정말 고맙다), 주변 동료들에게 감사를 표하고 싶다.