기술부채 청산 출장 후기

내가 속한 프로젝트 개발팀이 2019년 5월 5일부터 18일까지 2주간 기술부채를 청산하기 위해 베트남으로 출장을 다녀왔다.

굳이 출장까지 가서 기술부채를 해결하려고 한 이유는 리프레시를 위한 목적도 있었고, 최대한 interrupt 를 받지 않을 수 있고 집에 도망갈 수 없는 환경을 만들기 위해서였다.

우리 팀이 기술부채를 해결하기 위해 밟은 스텝을 시간순으로 소개하면 다음과 같다.

1. 티켓 선정

먼저, 그동안 쌓아놨던 기술부채 이슈 중 이번 출장에서 해결할 이슈를 정리했다.

선정한 이슈들은 기존 프로젝트에서 계속 해결하지 못하고 있던 이슈들이었고, 기술부채의 정의에 맞게 지속적으로 자원을 투입하게 만드는 이슈들을 위주로 선정하였다.

여기서 자원 은 Human Resource 와 Computing Resource 를 둘 다 포함한다.

위와 같은 기준으로 기존 이슈들에 대해 우선순위를 정해서 분류를 했고, 크게 보면 다음과 같은 이슈들이 있었다.

(서버팀의 입장에서 적었기 때문에, 클라이언트 관련 부분은 자세히 적지 못하였다)

빌드 파이프라인 관련 이슈

기존에는 CI 파이프라인에서 네트워크 등의 이슈로 빌드의 후반 페이즈에서 실패할 경우 처음부터 다시 빌드를 해야 했었고, 이로 인해 많은 시간이 낭비되었다. 이를 마지막으로 성공한 페이즈부터 다시 시도할 수 있다면 빌드가 실패할 때마다 낭비되는 시간을 절약할 수 있을 거라 생각했다.

모듈화 관련 이슈

서버와 클라이언트에서 기능적인 부분을 분리하여 모듈화를 진행하였다. 모듈화의 목적은 기능적으로 분리할 수 있는 부분을 분리하여, 서로 다른 팀끼리 서로가 맡은 부분에 대해 신경쓰지 않고 작업을 하기 위함이었다. 하지만 모듈화가 100프로 진행되지 않아서 계속해서 각 팀의 진행상황을 체크하며 작업을 해야 하는 이슈가 있었다. 이는 계속적인 커뮤니케이션 코스트로 이어졌고, 이를 낭비하지 않기 위해 하다가 만 모듈화를 완료하기로 했다.

레거시 라이브러리 제거

기존에 쓰고 있던 ORM 라이브러리가 있었는데, 새 프로젝트 출시 전 급하게 기능을 추가해야 해서 2년전에 내부에 포크해서 써왔다. 문제는 해당 라이브러리가 더이상 maintain 이 되지 않아 방치가 되어 있었고, 기능을 추가해서 머지하기도 힘들었다. 그래서 우리는 이를 완전히 제거하고, 커뮤니티에서 잘 관리되고 있는 라이브러리로 바꾸기로 했다.

각종 최적화 이슈

그 밖에도 유니티 클라이언트에서의 최적화(스크롤, 웹 이미지 다운로더 등)와, 비효율적으로 쓰고 있었던 데이터베이스 테이블을 수직샤딩하여 유니티 클라이언트와 데이터베이스의 성능을 향상시키려고 했다.

잠재적인 어뷰징 이슈 제거

서비스하는 어플리케이션의 복잡도가 높아지다보니, 개발 당시에는 미처 알지 못했던 어뷰징 이슈들이 몇개 있었다. 실제 어뷰징이 발생했는지 모니터링만 하고 근본적인 원인을 해결하지 않고 서비스를 개발하고 있었기 때문에, 이를 해결하고 싶어 이슈에 포함시켰다.

및 기타 생산성을 저해하는 이슈들을 합쳐서 크고 작은 19개의 이슈를 선정하였다.

2. 출장을 가서

docker-compose up

위 사진이 우리 팀이 베트남 다낭에서 머물렀던 숙소이다. 개발팀은 여기서 2주간 감금 도커라이즈 되어 기술부채를 해결하기 위해 많은 노력을 기울였다.

사무실과 떨어진 환경에서 가장 달랐던 점은 집중도였다.

바쁜 사무실에서는 항상 각종 이슈들에 대해 대화를 나누는 사람들이 많았는데, 이곳에서는 interrupt 되지 않고 코딩에만 집중할 수 있는 환경이어서 좋았다.

또한, 매일 진행 상황을 체크하기 위해 데일리 스크럼을 진행했다. 기존에는 주간회의를 진행했었기 때문에 서로의 상황에 대해 드문드문 공유가 되었다면, 스크럼을 통해 매일 진행상황을 공유하며 서로 일이 잘 안풀릴 때 조언을 주고받을 수 있어 좋았던 것 같다.

출장을 가서 주중에는 위 이슈들에 대한 구현을 계속해서 했기 때문에 사실 별로 쓸 말이 없다. 그냥 언제나처럼 코딩 열심히 했다.

그리고 기존 환경과 완전히 고립감금된 환경이었기 때문에, 퇴근 후에도 팀과 같이 지냈다. 그러다보니 많은 대화를 통해 팀워크를 쌓을 수 있었고, 저녁에 맥주 한잔씩 마시며 프로덕트에 대해 많은 이야기를 나눌 수 있었다.

주말에는 다낭 시내에 여행을 다녀올 수 있었다. 대표님 감사합니다.

3. 결과

팀원 7명이 2주간의 작업을 통해 다음과 같은 결과를 얻을 수 있었다.

• 초기에 선정한 19개 이슈 중 17개
• 중간에 추가로 발생한 2개 이슈

2개의 이슈는 기간 내에 해결하지 못했다. 이는 잘못된 이슈선정 때문이었다고 생각한다. 이슈의 이름은 다음과 같았는데,

피크시간 때 latency 경감할 방안 분석

kuberenetes 인증구조 개선

위 두 이슈를 해결하지 못한 이유는 모호한 이슈였기 때문이라고 생각한다.

전자의 경우 latency 의 원인부터 찾아야 하며, 워낙 복합적인 이슈가 있을 가능성이 높다. bottleneck 을 모르는 상황에서 이를 찾아서 해결하는 것까지 2주에 하는 것은 불가능했다. 이슈를 좀 더 명확하게 나누어, 원인을 분석하기 위한 스텝부터 했었어야 했다고 생각한다.

후자의 경우 kubernetes 의 초기 셋업에도 많은 오버헤드가 있었고, kubernetes 를 쓰는 다른 팀의 니즈까지 고려하여, 회사 전체적으로 설계할 필요가 있었는데 팀 이슈로 해결하려다 보니 다소 문제가 발생했다.

그 외의 다른 이슈들은 큰 문제 없이 잘 해결하였다.

4. Lessons

A. 라이브러리를 함부로 포크하면 안된다

포크하고 쓸 당시에는 편하겠지만, 인하우스 라이브러리는 나중에 관리 코스트가 눈더미처럼 불어난다. 더군다나 포크하고 작업한 사람이 퇴사하게 되면, 히스토리가 잘 관리되지 않아 이를 계속 발전시키기도 어렵다. 정말 급하지 않다면 해당 레포에 PR을 날리는 것을 언제나 1순위로 생각하자.

B. 기술부채의 완전한 해결은 어렵다: 고리대출에서 저리대출로

이번 일의 목표가 기술부채 해결이지만, 아이러니하게도 많이 고민했던 내용은 “이게 오버엔지니어링이 아닐까?” 였다. 빌드 파이프라인의 경우 OS 별로 나눠진 파이프라인의 공통된 stage 를 합치는 이야기까지 나왔지만, 조사를 해보니 그렇게 어설프게 구현했다가 관리 코스트가 되려 커질 수도 있어서 그냥 OS 별 빌드 파이프라인에서 재시도를 하는 걸로 결론지었다. 이처럼 결국 기술부채 해결 또한 가성비의 문제이고, 우리는 엔지니어이므로 trade-off 를 잘 하는 것이 중요할 것이다.

C. 테스트의 진가

이번 기술부채 출장에서 뼈저리게 느낀 내용 중 하나이다. 우리 프로젝트는 아직 테스트 커버리지가 높지 않은데, 이번에 기술부채를 해결할 때 이로 인해 큰 어려움도 겪었고 큰 도움도 받았다. 이번 작업으로 인해, 어플리케이션의 거의 모든 피쳐가 영향을 받아서 모든 피쳐를 손수 테스트해서, 테스트에만 하루가 걸렸다.

반대로, 테스트 커버리지에서 버그 하나를 잡아, 큰 문제 없이 고쳐지기도 했다. 낮은 테스트 커버리지도 부채라는 생각이 들었다. 기존 앱에서 확장하는 경우는 사람이 테스트 하는 것이 더 효율적일 수 있지만, 이번 케이스와 같이 전체를 뜯어고치는 경우에는 테스트 케이스가 많은 시간을 절약해줄 수 있었다.

5. docker-compose down

docker-compose down