2024년 4분기 회고

인수인계, 개발만 하는 게 아니었다

입사 후 첫 일주일은 인수인계를 받는 기간이었다. 프로젝트 설정과 개발자 환경 세팅부터 시작해서, 프로젝트에서 쓰는 외부 라이브러리와 여러 SDK 툴의 사용법을 배웠다.

그런데 막상 배워보니 iOS 개발자의 일이라는 게 단순히 코드를 짜는 것만은 아니었다. 에어브릿지, 브레이즈, 데이터독처럼 앱을 개발하고 운영하는 데 필요한 여러 마케팅 요소들까지 함께 다뤄야 했다. '개발 및 운영'이라는 말 안에 이렇게 많은 것들이 들어 있는 줄은 미처 몰랐다. 지금까지는 순수하게 앱을 만드는 것만 생각했는데, 실무는 그보다 훨씬 넓은 영역을 챙겨야 하는 일이었다.

전임자가 떠나고, 코드와 나만 남았다

전임자가 퇴사하고 나자 본격적으로 프로젝트 파악에 들어갔다. 그런데 코드를 읽는 것부터가 쉽지 않았다.

가장 먼저 나를 당황하게 만든 것은 프로젝트 안에 private으로 선언된 것이 하나도 없다는 사실이었다. 클래스 안의 함수도, 변수도 전부 외부에 열려 있었다. 그러다 보니 로직을 파악하는 데 정신이 나갈 지경이었다. 이 함수를 어디서 호출하는지, 이 화면은 어떤 경로로 진입하는지, 왜 이런 코드가 여기 있는지 흐름을 전혀 잡을 수가 없었다.

코드는 aClass.bView.cSubView.dValue = 0 같은 식으로 객체 내부를 깊게 파고들어 값을 직접 바꾸고 있었고, 그마저도 한 군데에서만 바뀌는 게 아니었다. 이렇게 값을 변경하는 함수들이 전부 private이 아니다 보니 외부 객체에서 마음대로 호출하고 있었다. 결국 어느 한 부분을 이해하려면 프로젝트 전체를 다 알고 있어야 한다는 뜻이었다. 이건 정말 답이 없었다.

거기에 폴더명이 한글로 되어 있어서 파악이 더 어려웠다. 네이밍은 직관적이지 않았고, 그 네이밍에 맞는 파일들이 실제로 그 자리에 있지도 않았다. 스토리보드도 마찬가지였다. Main.storyboard 하나에 화면을 20개는 때려박아 놓으니 파일을 불러오는 것조차 버거웠다.

하필 이 시점에 찾아온 대규모 개편

그렇게 코드를 파악하고 있던 와중에 쇼핑몰이 크게 개편을 하게 되었다. 그에 맞춰 앱에도 수정 사항이 많아졌는데, 앞서 말한 이유들 때문에 사이드 이펙트가 어디서 터질지 예측할 수가 없어서 정말 힘들었다.

그래도 프로젝트 전반에 걸쳐 손을 대야 했기 때문에, 역설적으로 코드 파악은 오히려 더 빠르게 할 수 있었다. 사실 private이 하나도 없다는 것과 한글 폴더링이 워낙 충격적이었던 터라, 그 뒤로는 웬만한 것에는 놀라지도 않는 상태가 되어 있었다.

셀 높이에 비즈니스 로직이 들어 있다니

그런 나조차도 가장 골때린다고 느낀 로직이 하나 있었다. 바로 셀(cell) 높이에 비즈니스 로직이 들어가 있던 것이었다. 셀 높이가 44라는 것을 기준으로 화면 계산을 하고, 그 계산 위에 구매와 장바구니 로직이 얹혀 있었다.

그래서 이 44라는 값을 수정하는 순간, 상품이 구매나 장바구니에 담기지 않는 상황이 발생했다. 화면 수치와 핵심 비즈니스 로직이 이렇게 얽혀 있으니, 이걸 제대로 뜯어내 리팩토링하는 것이 이 시기에 가장 힘든 작업이었다.

웹을 그대로 옮겨온 API, 그리고 재귀의 늪

쇼핑몰 자체가 웹 중심이었고 그 웹마저 오래되어 레거시 코드가 많았다. 앱이 메인이 아니다 보니 API 설계 같은 것들도 웹에서 쓰던 방식 그대로 만들어진 게 너무 많았다.

예를 들어 상품 여러 개를 담는 경우를 생각해보자. 상품 ID와 개수를 담은 구조체를 만들어 배열에 넣고 한 번만 호출하면 될 일이다. 그런데 여기서는 상품을 담으려면 재귀 호출을 해야 했다. 첫 번째 상품의 ID와 수량을 호출한 다음, 그 응답(response)에서 ID를 뽑아 파라미터로 넘기고, 거기에 두 번째 상품 ID를 넣어 다시 호출하는 식이었다. 게다가 재귀로 호출하는 도중 하나라도 실패하면 전체가 실패였다.

문제는 이렇게 재귀 함수로 호출하는 로직이 프로젝트 곳곳에 많았다는 것이다. 이런 부분들 때문에 업무를 하는 게 너무나 힘들었다.

혼자서 세 개를 동시에, 그런데 다 다르다

특히 혼자 개발하다 보니 동원몰, 더반찬, 아르르 세 개의 프로젝트를 전부 수정해야 하는 경우가 가장 큰 문제였다. 같은 일을 세 번 하는 것까지는 그렇다 쳐도, 각 프로젝트마다 로직을 이상하게 커스텀해서 가져다 붙여 놓은 탓에, 분명 똑같은 작업인데도 매번 처음부터 다시 다 수정해야 하는 일이 비일비재했다.

이런 일들을 겪으면서 나는 결심했다. 다음 분기의 목표는 앱 전체 리팩토링이다. 3분기부터 어렴풋이 품고 있던 모듈화와 아키텍처 재설계라는 생각이, 이 시기를 직접 겪고 나니 막연한 다짐이 아니라 반드시 해야만 하는 일이라는 확신으로 바뀌었다. 그 이야기는 다음 분기 회고에서 이어가려 한다.