입사 2주년 회고

입사 후 2년을 타임라인 리뷰 방법론으로 회고합니다.

2020년 8월, 11번째 멤버로 현 회사에 합류했는데 어느덧 24명 중 6번째 멤버가 되었다. 신규입사자가 합류할 떄마다 상대적으로 오랜 기간 재직 중이라는 것이 느껴진다. 19살 신입이 창립 3년도 되지 않은 스타트업에 많은 변화와 성장을 만들겠다는 패기와 열정이 매력적이었는지 경력자를 찾던 회사의 첫 신입으로 합류한 것은 아직도 뿌듯하다. 그 패기와 열정 덕분에 2년간 회사에도 나에게도 많은 변화와 성장이 있었고, 만 2년차 개발자가 된 지금도 변화와 성장에 대한 열망은 가득하다.

조직 구조와 업무 프로세스, 제품 등 다양한 변화는 신입에게 많은 성장과 경험을 가져다 주었다. 아는 게 많아질수록 회사와 나 자신의 부족함이 더 많이 보이지만 부족함을 발견하고 채워나가는 것은 성장을 만들기에 즐겁다. 마냥 개발이 재미있었던 학생이 없었다면 이토록 적성과 능력이 부합하는 직업을 가질 수 없었을테니, iOS 개발자로 진로를 정한 2019년의 나에게 고마움을 전하며 회고를 시작하려 한다.

2020.08 ~ 2020.12

입사하고 약 한달간은 제품/코드 분석과 소프트랜딩을 위한 작은 태스크를 진행했다. 당시에는 제품 구분없이 태스크 단위의 업무 프로세스였기 때문에 3개의 제품에 대한 태스크를 진행했고, 배포/업무 프로세스를 경험했다. 이 기간에는 업무가 비교적 쉬운만큼 조직 문화 등 개발 업무 외의 부분에도 많은 의견을 내면서 조직에 대한 이해도를 높였다.

작은 태스크들을 모두 처리한 후에는 생산성 제품의 2.0 개발 업무를 맡았다. 다른 팀원들은 신규 프로젝트에 매진하느라 혼자 맡게 되었고, 완전히 새로운 앱으로 재탄생하는 수준의 업데이트이기 때문에 새로운 요구사항에 맞춰 새로 개발하기 시작했다. 회사에서 처음으로 테스트코드와 RxSwift 기반의 반응형 프로그래밍을 도입하며 이상적인 코드를 작성하는 것에 만족해 협업에 대한 갈증을 삼켰다. 코드 리뷰와 주기적인 개발팀 미팅을 통해 독립적으로 개발하는 것 치고 제법 긴밀하게 협업했지만, 내 코드에 확신이 없고 검증받고 싶었던 시기였기에 이 정도로는 부족했다.

하지만 이상적인 코드 작성은 신규 프로젝트에 긴급 투입되면서 잠시 중단되었다. 신규 프로젝트에 나를 제외한 개발팀 전원이 집중하고 있었기에 협업에 대한 기대감이 있었지만, 이미 존재하는 코드베이스 위에 기능 하나를 맡아 독립적으로 개발하게 되면서 나의 갈증을 채우진 못했다. 그래도 당시에는 같은 코드베이스 위에서 개발하고, 같은 제품에 대한 이해가 있다는 것만으로 꽤나 위안이 되었다.

2021.01 ~ 2021.10

신규 프로젝트가 어느정도 마무리된 후에는 생산성 제품의 2.0 개발 업무를 이어서 진행했다. 약 9개월 간 이 제품을 담당하며 정말 많은 변화와 성장이 있었다. 다양한 경험을 통해 여러 방면으로 성장할 수 있었음에 감사하고, 다른 제품을 맡고 있는 지금도 이 제품에 대한 애증이 남아있다.

개발 능력 향상

2.0의 새로운 코드만 작성할 줄 알았으나 기존 이슈를 먼저 빠르게 처리해야 하는 상황이 발생했다. 이러한 이슈를 해결하며 앱 안정화에 기여하는 것은 성취감을 느낄 수 있었고, 디버깅 능력과 기존 코드 분석력 또한 크게 좋아졌다. 1.0과 2.0을 병행하다보니 git 활용 능력도 향상되었다. 1.0 코드를 어느정도 재사용하기 위해 objc코드를 swift코드로 컨버팅했을때는 objective-c의 매력을 조금이나마 맛볼 수 있었다.

애플 프레임워크에 대한 이해도와 활용력이 가장 많이 향상되었는데, 공식 문서를 읽는 습관을 들이며 문제를 이렇게 맛깔나는 방법으로 해결할 수 있다는 것에 감탄했다. 시간을 다루는 생산성 제품이기에 컴퓨터 공학에서 시간을 어떻게 다루는지 이해하는 것이 아주 중요했는데, 처음에는 Timezone이나 Calendar 개념을 이해하지 못했다. 직접 관련 데이터 모델을 설계할 때 즈음 개념을 이해할 수 있었는데 선배님들이 이런 멋진 표준과 체계, 개념을 확립해주신 것에 경외했다. 그러면서 나도 언젠가 하나의 문제를 해결하는 시스템을 만들고 싶다는 생각이 커졌다. (가장 큰 도움이 되었던 글)

문제 해결 능력이 전반적으로 향상되었다. 문제 해결 능력은 문제를 올바르게 정의하는 것을 시작으로 분석, 솔루션 탐색, 가설 및 계획 수립, 우선순위 정렬, 실행과 모니터링까지 개발자에게 가장 중요한 역량이라고 생각한다. 대부분의 문제는 기본적인 센스를 활용해 해결할 수 있었기에 입사 초기에는 자만했던 적도 있다. 하지만 경험이 쌓일수록 문제를 해결하는 것에서 더 나아가 잘 해결하려 했고 자만이라는 단어는 잊혀졌다. 개발 없이도 해결 가능한 문제 등 다양한 유형의 문제를 통해 문제를 정확하게 정의할 수 있게 되었고, 생각할 수 있는 솔루션의 범위가 넓어졌으며 문제 해결에 걸리는 시간이 줄었다는 것이 가장 유의미한 성장이라고 생각한다.

업무 프로세스 개선 / 프로젝트 관리

이 프로젝트를 진행하면서 조직에 가장 많이 기여한 부분은 업무 프로세스 개선과 프로젝트 관리라고 생각한다. 무에서 유를 창조했다고 할 수 있을만큼 문서화에 많은 기여를 했다. 지금 생각해보면 히스토리를 확인하기 어려운 경우 이해관계자에게 직접 확인하는 비효율을 가장 많이 경험했기 때문에 더 집착했던 것 같다. 또한 이 프로젝트는 나 혼자 개발했기 때문에 내가 부재한 경우, 히스토리를 아무도 알 수 없겠다는 생각에 문서화를 습관처럼 했다. 위키 형태 문서에 요구사항은 물론 개발 스펙, 히스토리, 리서치 결과, 복잡한 로직 설명까지 빠짐없이 기록했고 새로운 이해관계자가 합류하는 경우 특히 큰 도움이 되었다. 이 프로젝트의 위키를 시발점으로 문서화 시스템이 고도화되기 시작했다.

리소스가 부족한 스타트업에서 중요한 효율을 극대화하기 위해, 자동화에도 관심을 기울였다. 개발자가 주먹구구식으로 하던 문자열 관리는 노션 데이터베이스를 활용한 자동화로 디자이너도 접근해 수정할 수 있도록 하였고, 지역화의 기반이 되었다. SwiftLint와 CI를 도입하여 기본적인 컨벤션/코드스타일/빌드실패 관련 리뷰를 최소화했다. 이 때 리서치했던 내용을 바탕으로 신규입사자 팀원이 주요 프로젝트에도 CI/CD를 적용해주셨고, 관련 업무에 효율이 크게 늘어 아주 만족스럽다.

이 프로젝트는 개인이 제품 구분 없이 태스크 단위로 일하던 방식에서 스쿼드 조직으로 일하는 방식으로 전환한 첫 번째 프로젝트였다. 이 프로젝트가 기존대비 업무가 원활하게 이루어졌음을 참고하여 2021년부터 스쿼드 조직으로 전격 전환되었는데, 이 경험은 정말 어디에서도 하기 어려운 경험이었다고 생각한다. 당시에는 PO도, PM도 없이 의사결정권자와 메이커 2명으로 이루어진 작은 조직이었기에 시행착오를 정말 많이 겪었다. 나를 제외하고 유일한 메이커였던 프로덕트 디자이너 팀원은 다른 스쿼드에 중복으로 포함되어 있었기 때문에 자연스레 내가 스크럼 마스터 역할을 맡게 되었다. (당시에는 스크럼 마스터라는 명확할 역할은 아니었고, PM 정도로 생각했다.) 스크럼 마스터 역할을 맡으면서 우선순위에 대한 고민을 가장 많이 했다. 제품 특성 상 수많은 예외케이스가 존재했는데, 예외케이스들은 항상 일정을 추정할 때 드러나지 않다가 개발 도중 드러났다. 예외케이스를 대응하지 않으면 데이터 무결성에 문제가 생기기 때문에 반드시 대응해야만 했고, 이는 일정 지연의 원인이 되었다.

일정 지연을 해결하기 위해 시도했던 것은 우선순위에 따른 작업 진행이었다. 스프린트 범위에 포함된 태스크를 high, medium, low priority로 분류하고 예상치 못한 일정 지연이 발생하는 경우 low 태스크를 다음 스프린트로 이관하는 단순한 방법이었다. 사실 굉장히 기본적이고 당연하다고 볼 수 있으나 일정 관리에 익숙하지 않던 당시에는 파격적인 방법이었고, 잘 작동했다. 또한 스프린트와 릴리즈가 별개로 이루어졌고 작업자는 거의 나 혼자였기 때문에 가능한 방법이었다. 이러한 시도와 노력 덕분에 처음 치고 스크럼 마스터로서의 역할을 잘 해낼 수 있었다.

MLP (Minimum Lovable Product)

프로젝트를 진행하면서 가장 재미있었던 부분을 꼽으라면 프로덕트 디자이너 팀원과 MLP를 만드는 과정을 꼽을 것이다. 제품을 개발하며 가장 중요하게 생각했던 것은 사용자였다. 사용자가 어떻게 하면 이 제품을 사랑할 수 있을까를 생각하며 다양한 user case에 대해 끊임없이 토론했다. 디자이너와 이렇게 긴밀하게 협업한 경험은 처음이었으나, 다시는 이런 협업을 경험할 수 없을 것 같다라는 생각이 들 정도로 재밌었고, 얻은 것도 많다. 제품 특성 상 개발과 제품 요구사항이 밀접한 관계를 가지기 때문에 제품 요구사항 논의를 위해 개발 측면에서의 설명이 필요했다. 구현 방법과 데이터 흐름에 대해 최대한 이해하기 쉽고 상세하게 설명하려 노력했고, 결과적으로 최적의 스펙과 상호 이해 그리고 UI/UX에 대한 이해를 얻을 수 있었다.

아쉬운 점은 비즈니스 측면에서 드러났다. 사용자가 사랑하는 제품을 만들면서 많은 경험과 동기부여를 얻었지만, 예상했던 프로젝트 일정을 훌쩍 넘겼다. 이는 비즈니스 측면에서 빠르게 실험하고 검증할 기회를 무산시켰다. 물론 예상했던 일정이 완전히 불가능한 일정이었고 다른 요소의 영향도 많았으나 일정 지연의 가장 큰 원인은 욕심이었다. MVP를 너무 크게 잡았고 욕심이 너무 많았다. 막연히 잘하고 싶었는데 제품 품질에 대한 욕심만 과도했다. 완벽한 제품도 좋지만, 조금 부족한 제품이라도 빠르게 실험하고 검증하는 것 또한 중요하다는 것을 몰랐다. 특히 빠르게 변화하고 성장해야 하는 스타트업에서 말이다. 이 경험을 반면교사 삼아 상황에 따라 욕심을 버리는 법을 체득했다.

컨디션 관리

입사 1주년(현장 실습 기간으로 인해 실제 근로 계약은 10월에 이루어졌다)에 받은 동료 피드백이다. 입사 후 1년간 나는 컨디션 관리가 얼마나 중요한지 건강을 갉아먹으며 깨달았다. 원인 불명의 두통과 이명, 어지러움 증상으로 인해 입원과 MRI검사까지 했다. 큰 병에 걸렸구나 걱정하며 검사 결과를 받아보니 원인은 단순 과로와 극심한 스트레스였다. 입원했을 때 즈음에는 이 프로젝트를 마무리하고 다른 프로젝트에 합류할 준비를 하고 있었다. 그래서 입원 당시 과로는 무슨 스트레스도 없어서 진단 결과를 받아들이기 힘들었다. 하지만 동료 피드백을 받고 1년 간 업무시간과 야근 횟수, 업무 과몰입을 돌아보니 이미 쓰러졌어야 했는데 운동으로 겨우 버텼구나 생각했다.

욕심이 많았기 때문에 내 능력 이상을 보여주고 싶었다. 그래서 더 많은 시간을 업무에 투자하여 내 가치를 인정받고 제품을 성장시켜야겠다고 생각했다. 초과근무는 기본이고, 개인 시간에도 업무를 위한 학습을 하는 등 완전히 과몰입 상태였다. 업무를 잘 하는 방법을 체득하는 동안 일과 삶을 분리하는 방법, 업무시간을 관리하는 방법 등 컨디션 관리 방법과 그 중요성은 체득하지 못했다. 문제를 올바르게 인식하지 못하고 스스로 운동하고 더 학습하며 이상적인 생활을 하면 나아질 것이라 착각했다. 회사의 우선순위를 나 자신의 우선순위 보다 높게 책정했던 것이다.

스트레스의 원인 중 나머지 하나는 제품을 혼자 책임지는 것에 대한 부담과 고립감이었다. 항상 당차고 자신있는 모습을 보였지만, 개발자로서는 나에게 확신이 없었기 때문에 부담과 고립감은 더 심했다. 제품의 개수에 비해 인력이 부족하니 방도가 없다는 사실을 알았고, 그래서 팀원들과 부담을 나누면 안된다고 생각했다. 내가 해결할 수 있는 것은 혼자 해결하는 것이 맞다고 생각했다. 혼자 하다가 도저히 스스로 결정할 수 없고, 절실히 도움이 필요할 때는 자료를 잘 정리하여 최선의 도움을 받고자 했다. 하지만 제품 특성 상 아무리 자세히 정리하고 설명해도 제품 전반에 대한 이해가 없다면 도움이 필요한 부분을 이해할 수 없었고, 결국 내가 원하는 수준의 도움까지는 도달하지 못했다. 이 또한 욕심이었다. 팀원들의 도움이 없었다면 많은 부분에서 실패하고 더 많은 부담과 고립감을 느꼈을 것이다. 고립감을 해소하기 위해(누군가 내 업무를 알아주길 바라며) 업무 상황과 히스토리를 누구나 쉽게 확인할 수 있게끔 아사나 프로젝트 정리에도 신경썼지만 이 또한 별로 도움되지 않았다.

컨디션 관리도 프로 개발자의 덕목이라는 것을 깨닫고서는 건강전도사가 되었다. 나 자신이 건강하고, 행복하지 않으면 일을 하는 의미가 없다. 이 경험을 통해 지금 프로젝트에서는 컨디션 관리를 아주 잘 해내고 있다.

2021.11 ~

생산성 제품의 2.0 개발 업무를 마무리한 후, 회사의 주력 그래픽 제품을 맡게 되었다. 이 제품 스쿼드는 PO를 포함한 다양한 직군이 일하고, iOS 개발자가 2명 이상이기 때문에 다양한 협업을 경험하고 있다. 팀원들이 가진 경험과 장점을 나에 맞게 체득하여 길지 않은 기간이지만 폭발적으로 성장했다.

개발 능력 향상

이 제품은 objective-c 코드가 대부분이었고, 정리 중인 상태였기 때문에 레거시로 가득했다. 가장 먼저 생산성에 영향을 미치는 요소들을 틈날 때마다 제거했다. 디렉토리 구조를 개선하여 파일 탐색을 용이하게 만들고, 사용되지 않는 파일은 스프린트 단위로 모아두었다가 릴리즈 후 일괄 삭제하는 규칙을 만들었다. 백엔드 연동이라는 큰 작업을 위해서 objective-c 코드를 swift 코드로 컨버팅하고 리팩터링했다. Combine을 도입하고, 타입 간의 의존성을 최소화하여 변경에 유연하도록 수정했다. 노력한 결과 swift 코드가 objective-c 코드 비율을 넘어섰고, 최근 새로 작성하는 코드에는 단위 테스트까지 적용했다. 코드 품질이 개선되면서 생산성이 대폭 향상되었고, 버그와 크래시가 눈에 띄게 줄었다. 코드를 개선하는 작업은 조금 힘들지만 엄청나게 재미있다는 생각이 들었던 경험이었다.

한 번에 개선하기에는 리스크가 큰 규모였기 때문에, 결합도가 매우 높은 아키텍쳐에서 네트워킹이 가능할 정도까지만 결합도를 최소화한 아키텍쳐로 개선했다. 컨버팅과 함께 진행해 피로감이 존재했으나 아키텍쳐 설계 능력이 많이 향상되어 뿌듯하다. 혼자 개발하는 것이 아니었기에 팀원과 함께 고민하고 도메인 지식을 쌓는 과정에서 신뢰를 얻은 것 같아 좋았다. 지금도 개선하고 있어 내년에는 어떤 코드가 되어 있을지 기대된다.

이전 구조	개선된 구조

그래픽 제품인만큼 컴퓨터 그래픽에 대한 이해가 요구되는데, 기반 지식이 없던 상태에서 이해하려니 처음에는 조금 힘들었다. 애플의 그래픽 프레임워크를 시작으로 지금도 공부하고 있는데 끝이 보이지 않아 더 재밌다. 평생 공부해도 모르는 정보가 있을 것 같다. 백엔드, 안드로이드 개발자 팀원과도 협업하면서 다른 플랫폼간의 프로토콜을 정의하는 능력, 이미 존재하는 기술 또는 표준을 활용하는 능력, 올바른 자료 구조를 사용하는 능력이 생겼다. 다양한 협업을 통해 팀원들의 장점을 흡수하여 개발적인 시야가 넓어진 것은 덤이다.

업무 프로세스 개선 / 프로젝트 관리

혼자 일하는 것이 아닌, 두 명의 iOS 개발자가 팀으로서 일하기까지는 시행착오가 많았다. 나도 팀으로 일하는 것이 처음이었고, 팀원은 혼자 일한 경험이 더 많으셨다. 우선 서로의 생각을 이해하고 규칙을 정립하기 위해 초기에는 오버커뮤니케이션하며 결과를 문서화했다. 브랜치 관리 전략, 코드 스타일 등 혼자 일할 때는 조금씩 달랐던 부분을 맞췄다. 혼자 개발할 때 들었던 고립감은 사라지고 팀으로서 일을 더 잘하기 위해 노력하는 과정은 행복했다. 내가 부족한 부분은 팀원이 채워주고, 팀원이 부족한 부분은 내가 채워주며 서로 성장하는 과정은 모두에게 유의미했다. 팀원의 섬세함과 많은 경험을 통해 단기간에 내 시야는 넓어졌고, 나의 일정 관리와 소프트스킬을 통해 팀원의 업무 방식은 변화했다. 일의 맺고 끊음이 원활하게 이루어지고, 초과근무가 사라져 생산성이 크게 향상된 우리 팀의 모습을 볼 때마다 놀랍고 동기부여된다. 타인에게 선한 영향력을 발휘하는 것 만큼 행복한 경험은 없다는 것을 또 한 번 느꼈다.

같은 iOS 개발자 뿐 아니라 안드로이드 개발자, 백엔드 개발자, PO, 디자이너 등 다양한 직군과 협업하며 기록의 중요성이 커졌다. 이해관계자가 많아진만큼 자잘한 작업과 커뮤니케이션이 생겼고, 하나를 놓치는 경우 업무에 영향이 가기도 했다. 그래서 개인 업무를 기록하기 시작했고, 기록을 시작한 이래로 지금까지 무언가 누락한 경우는 손에 꼽을 정도로 드물다. 개인 업무 기록 일지는 우선순위 결정에도 도움이 된다. 우선순위가 높은 업무와, 낮은 업무를 분류하여 일함으로써 중요한 업무에 집중할 수 있어졌고, 일과 삶을 분리하는 데에도 많은 도움이 되었다. 직군이 다른 팀원과 일하면서 문제를 여러 명이 함께 해결해야 하다보니 또 다른 문제 해결 능력이 향상되었다. 이슈라이징 시 미스커뮤니케이션(비효율)을 방지하기 위해 명확하게 문제를 정의하였고, 장단점과 함께 솔루션을 제안했다. 문제 해결을 위한 커뮤니케이션을 주도하여 회의도 준비 및 주관했다. 한 번은 회의를 잘 준비하여 정확한 시간에 최적의 결과를 도출해낸 적이 있는데, 한 팀원으로부터 회의를 잘 이끌어주셔서 감사하다는 칭찬을 받았다. 이런 경험들은 아직까지도 기분이 좋다.

일정 지연의 원인이 생산성 제품을 개발할 때와는 상이했기에 우선순위에 따른 작업 진행만으로는 일정 문제를 해결할 수 없었다. 개발 상황 공유가 제대로 이루어지지 않으면서 발생하는 일정 지연은 부담감을 높여 초과 근무를 만들었고, 초과 근무는 생산성을 저하키는 악순환으로 이어졌다. 이를 해결하기 위해 팀 전체에 개발 상황을 자주 공유했고, 일정 추정의 정확도를 높이기 위해 여러 방법론을 학습하고 다음 스프린트부터 당장 적용했다. 결과는 매우 효과적이었다. 초과근무와 공유없는 일정 지연이 사라진 것이다. 이 두가지는 팀의 동기부여에 엄청난 영향을 미쳤다.

컨디션 관리

생산성 제품을 개발할 때 겪은 경험을 기반으로 컨디션 관리에 많은 노력을 기울였다. 야근과 초과근무는 존재했지만, 컨디션에 영향을 미칠 정도는 아니었다. 초과근무를 한다고 해도 일과 삶을 분리하여 개인 시간에 휴식을 가지고, 여행을 가는 방법으로 컨디션은 유지했다. 회복탄력성을 높게 유지하기 위해 루틴도 만들고, 규칙적인 식사와 운동은 당연히 지속했다. 하지만 중요한 것은 나 자신의 컨디션뿐만이 아니었다. 팀 전체의 컨디션은 나에게도 영향을 미쳤고, 동기부여까지 저하시켰다. 아무리 개인적으로 컨디션관리를 해도 생활에 대부분을 차지하는 회사에서의 영향은 무시할 수 없었다. 이를 깨닫고 위에서 언급한대로 문제를 해결해 드라마틱한 근무 시간 개선을 이루어냈고 지금까지도 컨디션을 항상 최적으로 유지하고 있다.

초과근무에 크게 시달리던 3월 근무 시간	주 41시간에 가까워진 5월 근무 시간

근무 시간 개선과 개인 컨디션 관리는 시너지 효과가 굉장했다. 지난 해, 병가 3개를 모두 사용하고 건강 악화로 인한 연차까지 사용한 것과 달리, 올해(2022)는 컨디션 관리와 별개의 영역(코로나 확진, 발목 염좌)으로 인한 병가 1개만을 사용했다. 또한 가장 중요한 업무 만족도가 높아졌고, 커리어에 대한 확신과 자신감이 생겼다. 초과 근무하지 않고 효율적으로 집중해서 일하는 것이 진정한 프로라는 것도 깨달았다. 피드백에 대한 개선이 성공적으로 이루어졌고, 목표를 달성했다는 사실도 나를 행복하게 만든다. 최근에는 스크럼 마스터를 맡게 되었는데, 다양한 기회를 얻을 수 있음에 감사하며 관리에 대한 학습도 해보려 한다. 2년이라는 기간에도 아주 많은 변화와 성장이 이루어졌는데, 앞으로 내가 또 어떤 경험을 통해 성장할지 기대된다.