신입 iOS 개발자의 "치약 프로젝트" 회고

들어가며

안녕하세요 BXP Pod에서 iOS 개발을 맡고 있는 강수진입니다.

 

작년 6월에 입사한 저는 반년이 조금 넘는 시간 동안 "치약" 프로젝트에 참여해왔는데요! 프로젝트가 끝나가는 시점, 저는 어떤 일을 했으며, 무엇을 배우고 느꼈는지 등을 시간 순으로 공유하려고 합니다. (긴 글 주의!)

 

개인 블로그에 작성할법한 너무 개인적 회고인가.. 도 싶지만, 신입 개발자는 어떻게 일을 하고 배워나가는지, 여러분들의 첫 입사를 떠올리며 가볍게 읽어주셨으면 좋겠습니다. :)

6월

저는 6월 말에 이베이 코리아에 iOS 개발자로 합류했습니다. 처음 자리에 놓여있던 풍선이 가장 기억에 남네요 ㅎㅎ (이제 풍선에 붙어있던 스티커는 제 노트북으로 옮겨왔습니다)

 

이때는 VX Pod 이었군요

경구님께서 보내 주신 입사 축하 메일도 확인할 수 있습니다.

 

7월

입사하자마자 정해진 저의 업무는 "치약" 프로젝트의 SRP/LP 페이지를 개발하는 것이었습니다.

처음 그 소식을 들었을 때 "음.. 치약이 뭔데요..? SRP/LP는 또 뭐고요 ㅎㅎ..?"라는 생각이 가장 먼저 들었던 것 같은데요, 우선 SRP/LP 페이지는 각각 Search Result Page와 Listing Page의 약자로, 검색 결과 상품 페이지와 카테고리 상품 페이지를 뜻합니다.

 

각각 SRP / LP 화면 입니다

그럼 "치약" 프로젝트란 뭘까요? 사실 원래 이 프로젝트의 이름은 2020년도에 진행될 프로젝트라고 해서 2020 프로젝트"였다고 해요. 하지만 2020과 2080이 글자로 썼을 때 비슷해 보였는지, 어떤 한 분이 "2080? 치약?"이라고 한 것에서 지금의 치약 프로젝트로 이름이 바뀌게 됩니다.

 

디자인 시스템 정립을 포함한 UX/UI 개선, 유저 데이터 트래킹을 통한 개인화, 모듈화를 통한 유연성 및 확장성 증대, 아이템 데이터 구조화를 통한 상품 정보 개선, Façade API 구축 및 API 속도 개선 등 지마켓의 전반적인 리모델링이 바로 이 프로젝트의 내용이고요. (우선 제가 알고 있는 것만 써놨지만, 실제로는 훨씬 더 많을 거예요. 혹시 언급이 안되었더라도 양해 부탁드립니다 ( _ _ ))

 

iOS 개발 관점에서 "치약"에서 (지금 와서 제가 느낀) 진행되는 일은 크게 아래와 같았습니다.

• UI (뷰) 전면 개편
• 새로운 Façade API 사용. 이 김에 기존에 사용하던 레거시 라이브러리 제거 후 새 라이브러리 도입
• Objective-C로 남아있는 legacy 제거 → Swift 변경
• 모듈 수정이 용이하도록 유연하게 변경될 수 있는 코드 설계
• 새로운 유저 트래킹 시스템으로 데이터 트래킹 및 데이터 정합성 체크
• (회의를 거쳐 일부 도메인에 한해) RxSwift 도입

이러한 상황에서 제가 가장 먼저 한 것은 기획서를 읽으며 요구 사항을, 제플린을 보며 새로운 UI를 파악한 것입니다. 그 후 업무 분장 내용을 보며 세부적으로 내가 무엇을 맡게 될지 인지하고, 해당 UI가 기능적인 요구 사항과 맞지 않는 부분은 없는지, 뷰는 어떤 식으로 구성해야 할지 등을 고민했습니다.

 

초반에 가장 어려웠던 부분은 코드 분석으로, "모듈 수정이 용이하도록, 유연하게 변경될 수 있는 코드 설계"를 이해하는 것이었습니다. 다행히 옥션의 LP/SRP는 모듈화를 위한 구조가 이미 짜여있었기 때문에, 호출부를 역순으로 추적해가고, 기존 코드를 조금씩 바꿔 돌려가면서 이해를 해나갔습니다. (이 때문에 한동안 제 시뮬레이터의 옥션은 배경이 초록색에, 아이템 사이 간격은 엄청 크고.. 그랬답니다 ㅎㅎ..)

 

문제는 코드만 봐서는 큰 구조 자체를 완전히 이해할 수 없다는 것이었습니다. 왜냐면 모듈화를 위해 사내 툴에서 별도로 진행해야 하는 작업들이 있었는데, 이에 얽힌 것들 또한 코드로 녹아져 있기 때문이었죠.

 

지마켓도 모듈화 작업에 들어가면서 이 등록 작업에 관한 회의가 있었는데 (아마 입사 후 첫 회의였던), 이때 하나도 이해 못했던 기억이 납니다 ㅎㅎ 어리둥절하게 질문하니까 친절히 설명해주신 후 마지막에 "직접 등록해보시는 게 제일 이해하는데 빠를 거예요~"라고 말씀해주셨더라죠..

 

운 좋게 지마켓 개편에 참여하면서 사내 툴에 직접 등록을 진행하고, 이 데이터가 iOS에서는 코드로 어떻게 연관되어 있는지 대조해보는 과정은 추후 모듈화의 큰 구조를 이해하는데 많은 도움이 되었습니다. 물론 회의 때 열심히 받아 적은 내용을 계속 정독하기도 했고요!

 

한편 개념만 알고 있던 Git Flow를 적용해서 개발을 한다는 사실이 재밌고 신기했습니다 (내가 feature 브랜치를 따다니..! ㅇ0ㅇ). 본격적으로 작업을 하기 전에, 한번 git에 대한 설명을 들은 적도 있는데 "델타의 집합"이다 라는 말이 가장 기억에 남습니다. 즉 변화량(diff)의 집합이란 의미인데, 이때 같이 말씀 주신 내용들 덕분에 git graph를 보는데 큰 도움이 되었습니다.

 

Jira 사이트에 들어가 보기도 했는데, "귀하에게 할당된 이슈가 없습니다"만 떠서 대체 여긴 어떻게 사용하는 거지..? 했던 기억도 나네요 (지금은 볼 수 없는 화면이지만요.. ㅎ)

8월

8월은 본격적으로 백엔드 개발자, 디자이너, PM 분들과도 협업하면서 코드를 작성을 시작한 달입니다. 7월 말에 슬랙 방이 파졌군요. 대화를 할 때는 추후 커뮤니케이션 오해에서 비롯될 리스크를 최소화하고자, 잘 이해가 안 되는 부분은 물론, 이해가 되었다고 생각한 부분까지도 한 번 더 체크하려고 노력했습니다. (이 과정을 통해 잘못 이해했던 정보들을 바로 잡았던 적이 많습니다 ㅎ.. 친절히 다시 설명해주신 모든 분들께 감사드려요! )

 

이때는 지마켓용 뷰 모델이 많이 안 나왔을 때라, 기존 옥션용 뷰 모델을 보면서 대충 어떻게 나오겠구나를 우선 파악한 후 개편될 사항과 맞지 않는 부분은 여쭤보고 했습니다. 처음부터 단체 방에 여쭤보기에는 조금 소심한 마음이 들어서 개인적으로 슬랙 드리다가, 다 같이 공유드리는 게 아무래도 맞는 거 같아 슬슬 용기를 내어 단체 슬랙 방에 등장했고요 ㅎㅎ

 

다른 WG 에 계신 개발자분께 드린 첫 슬랙..!! 도 나름 용기가 필요했답니다 ㅜ

통신 코드를 작성할 때는 모듈화 구조에 맞는 몇몇 작업들이 선행되어야 했는데, 이 작업들이 익숙지 않아 초반에 많이 헤맸습니다. 나름 제대로 한 것 같은데 왜 데이터가 안 들어오지..? 하는 상황의 연속이었죠.

 

이 과정에서 print로 값을 찍어서 확인하는 것에 한계를 느끼고, debug bar에 있는 메뉴들을 공부하며 디버깅하는 법을 좀 더 본격적으로 배웠습니다. step out은 아직도 잘 안 쓰긴 하지만, 나머지 것들은 필요에 따라 어느 정도 잘 사용하고 있답니다! 또한 특정 함수가 어떻게 호출되었는지 알기 위해 break point를 걸어 call Hierarchy를 확인하거나, 런타임 시 뷰의 구조 및 레이아웃을 확인하기 위해 view Hierarchy 살펴보기도 했고요 :)

 

발표로만 들어보던 lldb도 사용하게 되었는데, 사실 아직까지는 po 명령어만 사용하는 수준이라 기회가 될 때 더 제대로 공부해보고자 합니다.

 

그리고 존재만 알고 있었던 서브 모듈을 직접 건드려보고 메인 프로젝트에서 어떻게 버전 관리를 하는지 배우고 경험해보았습니다. 서브 모듈에는 공통적으로 사용할 내용들이 들어가기 때문에, 새로운 함수를 작성할 때는 마크업 형식에 따라 최대한 주석을 자세히 작성했습니다. 아쉽게도 정착된 코드 리뷰 프로세스가 없어서 종종 "이렇게 짜도 되는 건가..??" 생각하며 개발했지만, 이처럼 공통적인 함수를 작성할 때에는 별도의 요청을 통해 한 분 이상의 코드 리뷰를 받으려고 노력했습니다.

 

Objective-C 코드도 이때 처음으로 작성해봤습니다. 입사 전에는 어떻게든 피해왔던 건데.. 결국 맞닥뜨렸었네요 ㅎ 이슈 한 개를 핸들링하는 거였는데(결국 Swift로 대체되어 반영되진 않았지만) 이 덕분에 지금 옵젝 씨를 읽을 때 거부감이 덜.. 한 거겠죠?! 물론 싫은 건 디폴트입니다~!

 

옵젝씨를 이슈를 주시면서 말해주셨습니다 ㅎ

주변에 디자이너 친구들이 많아서 그런지 입사하고도 빨리 디자이너 분들과 같이 일해보고 싶었는데, 8월부터 제플린과 슬랙을 오가면서 활발히 의견을 나눌 수 있었습니다.

 

저의 제플린 첫 코멘트!

신기했던 것은 저는 디자인이 결정되면 어떻게든 똑같이 구현해야 하는 줄 알았는데, 개발 상황이나 효율에 따라 디자인도 어느 정도 유동적이게 조정 가능하다는 점이었습니다. 그래서 스펙대로 구현이 어려울 때는 디자이너 분도 조정이 필요한 이유를 공감하도록, 안 되는 이유를 최대한 자세히 설명드리고자 했습니다. 또한 디자인 변경이 필요할 것 같으면 안드로이드 개발자 분과 먼저 얘기하는 것도 잊지 않았고요!

 

iOS 개발자들 간 각자 제플린을 보면서, 공통으로 들어가야 하는 UI / 인터렉션 등에 대해서도 얘기를 나눴는데요, 각 스펙을 아우르기 위해서는 어느 정도로 유연하게 공통 모듈을 설계해야 하는지 고민하는 모습을 지켜볼 수 있었습니다.

 

중간에 바캉스 데이라고 해서 회사에서 준 아이스크림을 먹으면서 일을 하기도 했었네요 ㅎㅎ 이 즈음 입사 인터뷰도 진행했습니다. 또한 UX writing/message 아이디어 워크숍에 참여해 사용자에게 친근하고 재밌는 UX를 구축하는 데 도움이 되고자 열심히 의견도 내봤는데, 도움이 되었던 걸까 모르겠네요 ㅎ 거기서 먹었던 과자가 맛있었습니다..◠‿◠

 

쿠 앤 크 조 아

그리고 8월은 대망의 100% 재택이 재개된 달이기도 합니다. 재택 이후 급격히 줄어든 걸음 수를 보세요..

 

재택이 100%로 전환되면서 대부분의 소통은 슬랙으로 이뤄졌는데, 가장 좋았던 점은 기록이 남으니 계속 복기가 가능하고 충분히 생각한 후에 대답을 할 수 있다는 것이었습니다. 그리고 다른 분들의 대화 키워드를 위키 검색을 통해 살펴보면서, 기타 업무 내용을 파악할 수도 있었고요. 하지만 직접 얼굴 보고 도움받으면 빠르게 해결될 것도 슬랙으로 소통해야 하는 부분들은 아쉬웠습니다.

9월

9월에는 iOS 앱 화면 전환 애니메이션 아이디어를 모집하는 건에서, 예제 코드를 첨부하며 저의 생각을 공유했습니다. 이를 바탕으로 기존 코드의 변경 없이 해당 요구 사항을 만족하는데 일조할 수 있었는데, 아이디어를 다른 사람들과 공유하는 과정은 떨리지만 설렜고, 결국 채택되는 것을 보며 보람을 느꼈습니다.

 

이 외에는 전 월과 마찬가지로 API나 디자인을 확인하며, 안 맞는 부분이나 더 필요할 것 같은 부분들을 서로 맞춰가며 정신없이 작업했습니다. 데이터가 예상대로 들어오지 않을 때에는 반드시 postman에서 먼저 값을 확인하고 백엔드 개발자 분들께 요청드려야 하는 사안이 맞는지 판단한 후 질문하려고 노력했습니다.

 

저와 같이 일하는 백엔드 개발자분들이 작업하는 API가 aggregator의 역할을 하고 있다는 사실도 알았습니다. 원래 저는 DB 연결부터 시작해서 뷰에 필요한 정보를 내려주는 작업을 A부터 Z까지 다 개발해주시면 그걸 연동해서 쓰는 건 줄 알았죠..! 즉, 지금까지 조그마한 프로젝트만 진행해본 경험상 데이터는 하나의 API만 거쳐서 오는 것으로 생각했습니다. (사실 관련해서 입사 초기에 잠깐 설명들은 적도 있는데, 음.. aggregator.. 모아주는 거.. 하고 완전한 이해는 못한 상태였거든요 ㅎ)

 

원래 이해했던 구조

하지만 관련된 설명을 조금씩 듣고, 슬랙에서 오가는 대화의 맥락을 파악하고, 위키에서도 이것저것 살펴본 결과 아래 그림과 같이 하나의 뷰에 필요한 정보는 (우리는 서비스가 크기 때문에) 각각의 API에 나뉘어 있을 수 있다는 걸 이해하고, 그것을 뷰에 맞게 합쳐 내리는 또 다른 API의 개념을 알게 되었습니다.

 

프런트 개발자 입장에서 여러 API에 요청하는 대신, 한 곳에만 요청해도 된다는 점이 좋았지만, 다른 워킹 그룹에서 제공하는 API 개발이 딜레이 될 때, 다음 일정 공유를 다이렉트로 하기 어렵다는 아쉬운 부분도 있었습니다.

 

비슷한 개념으로 하나의 아이템 정보를 가져올 때도 DB 연동으로 한 번에 가져오는 것이 아니라, 각각 다른 WG에서 제공하는 API를 써야 하는 상황일 수도 있음을 알았습니다. 물론 사진은 임의로 나눠 놓은 것이지만요.

 

한편, 위에서 모듈화 작업을 위해서는 사내 툴 등록 작업이 필요했다고 말씀드렸는데요! 이 작업을 완전히 이해하지는 못한 채로 눈치껏 진행해오다가, 궁금한 점이 생겨 여쭤본 질문에 큰 깨달음을 얻기도 했습니다. 이런 식으로 조금씩 내가 어떤 프로세스 안에서 무엇을 하고 있는지에 대한 감을 익혀나갔습니다. 

 

그리고 월 말부터 이슈 체킹을 위한 데일리 미팅이 매일 아침 9:30에 시작되었습니다. 이 데일리 미팅은 릴리즈 전까지, 즉 1월까지 진행되었는데 초반에는 10명대로 시작했다가 후반에는 40명대까지 늘어났었더라죠.. 빠르게 이슈 상황을 공유하고 이에 따라 기간을 늘리거나, 기간을 맞추기 위해 대안을 찾는 등의 기민한 대응이 인상 깊었습니다. 물론 이때도 못 알아듣는 말이 대부분이었고, 이 회의에서 제가 하는 말이 있었다면 "이슈 없습니다~" 정도였지만요 ㅋㅎ..

 

9월의 귀여운 고양이를 보세요!

10월

이전 달과 마찬가지 프로세스로 개발했지만 달라진 것이 있다면 git에 조금 더 익숙해졌다는 것입니다. 작업 초반에는 기존에 알고 써왔던 commit, merge, pull, push, checkout, stash 정도만 자주 사용했습니다. 그마저도 꼬이거나 잘못될까 무서워서 후덜덜 떨면서 말이죠 ㅎㅎ.. 하지만 이 즈음부터 revert, patch, rebase, reset, cherrypick, amend 정도의 개념을 더 자세히 익히고 일부 적극적으로 사용하게 되었던 것 같습니다.

 

10월은 가장 바쁜 달이었는데, 왜냐하면 개인 QA 일정이 11월 2일로 잡혀있기 때문이었습니다. 따라서 10월 말까지는 어느 정도 개발 마무리가 되어야 했었죠. 하지만 아직 API에서 내려오지 않는 데이터도 있었고, 미처 뷰 모델이 정의되지 않은 경우도 있었기 때문에 일정을 맞출 수 있겠지..?라는 생각이 들기도 했었습니다. 이래저래 처리해야 하는 일들이 많아서 새벽까지 작업한 날도 많았고.. 정신적으로 좀 힘든 달이었습니다.

 

이때는 UI 작성 및 API 처리 외에도 유저 데이터 트래킹 처리를 1차로 진행했는데요, 유저가 검색어를 입력했을 때, 버튼을 클릭했을 때 등 상황에 필요한 정보를 트래킹 하는 과정을 통해 트래킹의 개념, 필요성, 보내야 하는 정보 등을 알 수 있게 되었습니다. 처음에는 트래킹 개념 및 상황 등이 생소해서 관련 wiki 들을 몇 번이나 정독해야만 했고, 처리 방법도 잘 이해되지 않아 이미 작업된 코드를 참고하고 질문도 했지만요. 어려웠던 과정이지만, 유저 트래킹이라는 안목을 얻게 된 값진 경험이었습니다. 비슷한 개념으로 광고 트래킹 쪽도 같이 살펴보면서 회사에서 제공하는 광고의 종류(클릭 별, 노출 별 등)와 종류에 따른 처리 방법을 배우기도 했고요.

 

바빴던 와중에 회사에서 지원해주는 인프런 강의를 처음으로 듣고 개인 기술 블로그에 정리를 시작했습니다. GCD 관련 강의인데, 비동기와 동시성을 이해하는데 큰 도움이 되고 있습니다 (아직도 다 듣진 못했습니다 ㅎㅎ).

 

11월

11월은 QA가 시작된 달으로, 드디어 입사 후 첫 지라를 받게 되었습니다. 물론 처음엔 상태 변경하는 방법부터 도움을 받았답니다 ㅎㅎ

 

정식으로 저에게 할당된 첫 지라 이슈!

1. 지라에 이슈가 올라온 것을 확인
2. To do를 진행 중(In Progress)으로 상태 변경
3. 뚝딱뚝딱 작업 후 커밋
4. Archive로. ipa 파일 빼내서 이베이 스토어 개인 QA 항목에 올림
5. In Review로 상태 변경 후 댓글로 링크 전달
6. PM분이나 디자이너분이 확인 후 Done으로 상태 변경

대충 위의 프로세스로 작업이 진행되었는데, 이때 아쉬웠던 점은 어떤 이슈 때문에 젠킨스 자동 빌드가 안돼서 CI/CD를 경험해보지 못했다는 점입니다. 다르게 생각하면 이 기회에 직접 Archive 후 사내 store에 올리는 경험을 할 수 있었던 걸까요?

 

항상 "지마켓 말아요~"의 자세한 과정이 궁금했는데, 이를 직접 진행해본 달이었습니다. .ipa 로 파일을 빼내고 스토어에 올리는 과정을 "말다"라고 표현하는 게 재밌지 않나요? ㅎㅎ

 

드디어 풀린 7월의 떡밥..!

QA를 진행하면서 1차로 놀란 점은 PM 분들이 체크하는 케이스들이 매우 세세하게 정리되어 있다는 것이었습니다.

 

그리고 2차로 놀란 점은 디자이너 분들이 1-2mm 오차를 판별해내시는 것이었죠.. 도대체.. 어떻게..?라는 충격과 공포의 연속이었다고요..

 

앞서 말씀드린 데이터 트래킹 작업 후에, 데이터가 정의된 대로 잘 들어오나 확인하는 자체 QA도 진행했습니다. 문제는 XCode에서 디버그 포인트를 걸어서 일일이 API로 내려오는 값과 엑셀에 정의된 값이 맞는지 비교하는 과정이 너무 시간도 오래 걸리고 비효율적으로 느껴진다는 것이었습니다. 따라서 json과 excel 값을 비교해 차이점을 출력해주는 python 프로그램을 작성하고, 그렇게 나온 결괏값을 수정 요청을 드릴 때 함께 공유드렸습니다. 이렇게 동료분의 수정이 요구되는 사항을 얘기할 때는 항상 현재 상황을 명확히 하고 대안까지 같이 제시하려고 노력했습니다. (사실 해당 프로그램을 작성하게 된 계기는 11월 PAWS 소식지 마지막에 나온 문구에서 영감을 받은 것이기도 합니다.)

 

또 기억나는 건 이상한 deinit 시점을 해결하는 과정에서 memory graph를 보는 경험을 해보았다는 것입니다. 결국 해당 이슈는 다른 동료분이 해결해 주셨지만요..! ㅎ 아직 메모리 사이클은 어려운 것 같아요 🤔

 

11월 말에는 API 형상이 dev 뿐만 아니라 stg 에도 배포되면서 스테이징 환경에서의 도메인 테스트가 가능하게 되었습니다. 실제 데이터를 바탕으로 더 다양한 케이스를 확인할 수 있게 되었죠! dev와 stg를 오가며 확인하면서, 도메인 환경이 분리된다는 개념을 좀 더 명확히 이해했던 것 같습니다. (크게 dev-stg-real으로 분리된 환경 경험)

 

지라 이슈들을 어느 정도 해결하고서는 남는 시간에는 LP/SRP의 모듈화와 관련된 API 위키 문서를 정독했어요. 물론 이해 못하는 게 더 많았지만, 대충 뒤에서는 이런 식으로 돌아가고 있었구나.. 정도의 느낌을 잡으려고 노력했습니다. 그중 고구마..🍠 를 키워드로 한 이슈가 있었던 게 생각나네요 ㅎㅎ 그냥 키워드가 고구마인 게 재밌어서 웃으며 읽었습니다. 중간중간 궁금한 내용들은 댓글을 남기기도 했는데, 모든 글마다 친절하고 자세히 설명 주신 덕분에 이해에 많은 도움이 되었답니다.

 

한편 iOS 그룹 슬랙에서 나온 대화 내용을 더 공부하는 과정에서 모두와 함께 공유하면 좋겠다 싶은 주제도 생겨, 이를 정리해 이베이 블로그에 기고했습니다. 이러한 글들이 쌓여 추후 우리의 개발 문화를 알리는 데 도움을 줄 수 있을 것이라고 생각했기 때문입니다. 이 글을 보는 분은 짐작할 수 있으시겠지만, 원래 정리하는 것을 좋아해서 회사 블로그 외, 개인 블로그에도 틈틈이 배운 내용들을 작성해 왔는데요, 현재 기준으로는 입사 후 33개의 글을 작성했네요 ㅎㅎ 총개수가 100개가 조금 넘는데 1/3 정도를 입사 후에 작성했군요!

 

마지막으로 11월은 특히 여러 동료분들이 격려되는 말씀을 해주셨던 달이랍니다! 많은 힘이 되었어요 ㅠㅠ 감동 ㅠ

12월

12월에는 전체적인 플로우를 포함해 확인하는 통합 QA에 들어갔습니다.

 

이때쯤부터 데일리 미팅에 참여하는 인원이 엄청 많아진 거 같은데, 발언하는 분들을 보며 러프하게 도메인 별 담당자를 파악할 수 있어서 좋았습니다. 릴리즈를 위한 시간이 얼마 남지 않은 상황이었기 때문에 남은 이슈 중 우선순위를 정하고, 크리티컬 하지 않은 사항들은 postLTS(릴리즈 이후로 처리할 것)로 라벨링 하며 기간을 맞추기 위해 신속하게 의사 결정하는 모습이 인상 깊었습니다.

 

개발적으로는 동료분께서 깔끔한 git graph를 위해 rebase에 대한 강의를 해주셔서 rebase를 적극적으로 쓰기 시작했습니다. 또한 파이어 베이스 동적 링크 핸들링을 경험해보며, iOS의 URI 스킴과 유니버설 링크도 같이 공부했습니다. 저희 회사에서는 특정 상황으로 인해, 동적 링크를 테스트하기 위해서는 Archive를 Enterprise 옵션이 아닌 AdHoc으로 빼내야 했는데, 이때 이 둘의 차이를 알고 애플이 🐏아치라는 것도 다시 한번 느꼈답니다..◠‿◠게다가 시뮬레이터에는 동적 링크 테스트가 잘 안되어서, 개발 환경에 맞는 테스트폰을 대여하고자 약 4개월 만에 회사에 출근했습니다. 약간 건물이랑 낯가리긴 했는데.. 오랜만에 가니 자리에 굿즈들이 쌓여있어서 좋았습니다.

 

사실 박스에 붙어있는 동그란 이베이 스티커가 가장 갖고 싶었어요

디자인 시스템이 정리되어가고 있는 피그마도 조금씩 살펴봤는데, 이때 궁금한 점을 디자인 시스템을 총괄하는 분께 여쭤 보며 디자인과 관련된 새로운 지식도 얻을 수 있었습니다. 예를 들어 컬러 팔레트는 어떤 과정을 통해 정의되는지를 생각해 볼 때 "디자이너분들이 예쁜 색깔을 투표해서 정해지는 건가..?" 정도밖에 떠오르지 않았는데 대화를 나누며 어떤 이유와 기준을 가지고 결과물이 도출되는지에 대해 알게 되었습니다. 완전히 다른 분야에서는 어떻게 일하는지 들을 수 있어서 매우 흥미로웠습니다.

1월

1월은 배포가 진행된 달입니다. 치약 프로젝트 배포 예정일은 1월 7일이었는데 iOS는 앱 심사가 필요하기 때문에 그보다 3일 빠른 1월 4일에 개발을 마무리 짓고 심사 요청을 올렸습니다. 급한 건들을 4일까지 처리하기 위해 새벽까지 다른 분들과 작업하면서, 이게 유튜브로 보던 개발자의 삶인가...!! 하고 흥미진진했더랬죠. 5일에 나온 심사 결과는 슬프게도 리젝이었고, 저는 조용히 Resolution Center에서 리젝 사유를 읽어봤습니다 👀 그리고 이 즈음에 Git Flow에 따라 hotfix 브랜치가 따지는 것을 보았고요.

 

1월 7일, 대망의 배포일에는 새벽 2시부터 고객들의 서비스 진입을 막은 후 필요한 소스 코드들을 배포하고, 추가 이슈가 없는지 확인하는 과정들을 지켜봤습니다. 이 시간에 화면은 어떻게 보이는지 궁금해서 늦게까지 깨어있는데, 그 와중에 수정 배포한 앱이 두 번째로 리젝 당했다는 메일도 받았더랬죠..!

 

각각 앱 / 모바일 웹으로 들어갔을 때

아침에 일어났더니 간밤의 치열한 흔적들이 메일로 남아있었고, 9월부터 3개월 넘게 진행되었던 데일리 미팅 또한 마무리됩니다. 시원 섭섭했어요 ㅠ(사실 오후에도 이슈가 계속 나와서 아침에 딱! 끝난 건 아니지만요)

 

이어서 오후 8시가 안된 시점, iOS도 심사가 통과되어 출시되었다는 메일을 받았습니다. 정말 큰 대여정이 끝난 기분이었어요.

 

이후 지금까지는 postLTS 건들을 처리하며, 2월 앱 배포를 준비하고 있답니다. 접근성 QA가 특히 많이 들어오고 있는데, 이를 통해 입사 전 프로젝트를 할 때는 생각지 못했던 시각 장애 고객 군을 고려하고, 해당 관점에서는 어떻게 서비스를 제공해야 하는지 생각, 구현하는 값진 경험을 하고 있습니다.

 

한편 데이터 트래킹을 위해 사용하는 비슷한 두 함수 중 하나는 HUE에서 데이터가 정상적으로 찍히고, 나머지 하나는 찍히지 않는다는 이슈도 있었습니다. 이때 proxyman이라는 디버깅 툴의 패킷 캡처 기능을 통해 데이터 형식이 다르게 나간다는 것을 확인하고 문제 해결의 실마리를 잡기도 했습니다.

 

여유 시간에는 wiki에서 현재 프로젝트와 관련된 문서를 읽고 댓글로 질문도 남기며 상세 내용과 히스토리 파악에 신경 썼습니다. 가장 뿌듯했던 점은 처음 봤을 때 전혀 이해가 되지 않았던 아키텍처가, 기술 하나하나를 틈틈이 공부한 결과 러프하게나마 읽을 수 있게 되었다는 점입니다! 위키에서 제 도메인과 관련된 페이지뿐만 아니라 다른 곳들도 둘러볼 때가 종종 있는데요, 이때 가장 신기한 상황은 ext4나 raid 등 학부에서 배운 개념들이 불쑥불쑥 나올 때입니다. 뭔가 시험 볼 때 빼고 다신 볼일 없다고 생각했던 단어들이 등장할 때 "오.. 이게 여기서 나와버리네?" 하며 흥미를 가지고 한번 더 읽게 되는 듯해요 ㅎㅎ

마치며

이렇게 반년이 넘는 기간 동안 큰 프로젝트를 진행하며 배우고 느꼈던 것들을 정리해보았는데요, 입사하자마자 전반적인 프로세스를 경험하고 많은 것들을 배워볼 수 있었던 기회가 참 행운이라고 생각되네요 :) 아직도 많이 미숙하지만 여기까지 올 수 있게 도움을 주신 모든 분들께 감사드리며 이 글을 마칩니다. 감사합니다!

 

웰컴 풍선에 붙어있던 스티커는 제 노트북으로 옮겨왔답니다. 완벽한 수미상관!