Ethan Hur 
제가 속한 프로젝트 개발팀이 2019년 5월 5일부터 18일까지 2주간 기술부채를 청산하기 위해 베트남으로 출장을 다녀왔습니다. 출장을 떠나게 된 이유는 개발 팀이 다낭 간 이야기를 참고하시기 바랍니다.
굳이 출장까지 가서 기술부채를 해결하려고 한 이유는 몇 가지가 있는데, 리프레시를 위한 목적도 있었고 최대한 interrupt 를 받지 않고 집중해서 일할 수 있는 환경을 만들기 위해서였습니다. (사실은 집에 도망갈 수 없는 환경을…크흠)
지금부터 저희 개발팀이 기술부채를 해결하기 위해 밟은 스텝을 시간순으로 소개해보도록 하겠습니다.
1. 티켓 선정
출장을 떠나기에 앞서서 그동안 쌓아놨던 이슈 중 이번 출장에서 해결할만한 기술부채 이슈들을 정리했습니다.
선정한 이슈들은 기존 프로젝트에서 우선순위가 밀려 해결하지 못하고 있던 이슈들이었고, 기술부채의 정의에 맞게 지속적으로 자원을 투입하게 만드는 이슈들을 위주로 선정했습니다. 여기서 자원 은 Human Resource 와 Computing Resource 를 둘 다 포함하는 의미로 사용했습니다.
위와 같은 기준으로 이슈 후보들에 대해서 팀원들이 투표를 해서 출장의 목표를 정할 수 있었고, 크게 보면 다음과 같은 이슈들이 있었습니다.
빌드 파이프라인 관련 이슈
기존에는 CI 파이프라인에서 네트워크 등의 이슈로 빌드의 후반 페이즈에서 실패할 경우 Unity 쪽부터 처음부터 다시 빌드를 해야 했었고, 이로 인해 많은 시간이 낭비되는 경우가 꽤 있었습니다. 이를 마지막으로 성공한 Stage 부터 다시 시도할 수 있다면 빌드가 실패할 때마다 낭비되는 시간을 절약할 수 있을 거라 생각했습니다.
모듈화 관련 이슈
기존에 서비스하는 프로덕트에서 서버와 클라이언트에서 기능적인 부분을 분리하여 모듈화를 진행했습니다. 모듈화를 통해 서로 다른 팀끼리 서로가 맡은 부분에 대해 신경쓰지 않고 작업을 할 수 있기를 바랬지만, 모듈화가 100프로 진행되지 않아서 계속해서 각 팀의 진행상황을 체크하며 작업을 해야 하는 이슈가 있었습니다. 이는 계속적인 커뮤니케이션 비용으로 이어졌기 때문에, 코드 모듈화를 완료하기로 결정했습니다.
레거시 라이브러리 제거
기존에 쓰고 있던 오픈소스 ORM 라이브러리가 있었는데, 새 프로젝트 출시 전 급하게 기능을 추가해야 해서 2년전에 내부에 포크해서 써왔습니다. 문제는 해당 라이브러리가 더이상 maintain 이 되지 않아 방치가 되어 있었고, 기능을 추가해서 머지하기도 힘들었습니다. 그래서 저희는 이를 완전히 제거하고, 커뮤니티에서 잘 관리되고 있는 라이브러리로 바꾸기로 했습니다.
각종 최적화 이슈
그 밖에도 유니티 클라이언트에서의 최적화(스크롤, 웹 이미지 다운로더 등)와, 비효율적으로 쓰고 있었던 데이터베이스 테이블을 용도에 맞게 분리하여 유니티 클라이언트와 데이터베이스의 성능을 향상시키려고 했습니다.
잠재적인 어뷰징 이슈 제거
서비스하는 어플리케이션의 복잡도가 높아지다보니, 개발 당시에는 미처 알지 못했던 어뷰징 이슈들이 몇개 있었습니다. 실제 어뷰징이 발생했는지 사후 모니터링만 하고, 근본적인 원인은 해결하지 않은 채 서비스를 개발하고 있었기 때문에 이를 해결하고 싶어 이슈에 포함시켰습니다.
위에 언급한 이슈들과 함께, 기타 생산성을 저해하는 이슈들을 합쳐서 크고 작은 19개의 이슈를 이번 기술부채 출장의 목표로 선정하였습니다.
2. 출장을 가서
docker-compose up
위 사진이 저희가 베트남 다낭에서 머물렀던 숙소입니다. 개발팀은 여기서 2주간 기술부채를 해결하기 위해 많은 노력을 기울였습니다.
사무실과 떨어진 환경에서 가장 달랐던 점은 집중도였습니다. 사무실에서는 항상 각종 이슈들에 대해 대화를 나누는 사람들이 많았는데, 이곳에서는 코딩에만 집중할 수 있는 환경이어서 좋았습니다.
또한, 매일 진행 상황을 체크하기 위해 데일리 스크럼을 진행했습니다. 기존에는 주간회의를 진행했었기 때문에 서로의 상황에 대해 드문드문 공유가 되었다면, 스크럼을 통해 매일 진행상황을 공유하며 서로 일이 잘 안풀릴 때 조언을 주고받을 수 있어 좋았던 것 같습니다.
출장을 가서 주중에는 위 이슈들에 대한 구현을 계속해서 했기 때문에 그냥 언제나처럼 코딩과 삽질을 열심히 했습니다.
그리고 서울 오피스에서 일할 때와는 다르게 베트남에 완전히 고립된 환경이었기 때문에, 퇴근 후에도 팀과 같이 지낼 수 있었습니다. 그러다보니 많은 대화를 통해 팀워크를 쌓을 수 있었고, 저녁에는 (맥주 한잔씩 마시며) 프로덕트와 개발 관련 많은 이야기를 나눌 수 있었습니다.
(당연히) 주말에는 일을 하지 않고, 다낭 시내에 여행을 다녀왔습니다. 대표님 감사합니다.
3. 결과
팀원 7명이 2주간의 작업을 통해 다음과 같은 결과를 얻을 수 있었습니다.
- 초기에 선정한 19개 이슈 중 17개
- 중간에 추가로 발생한 2개 이슈
2개의 이슈는 기간 내에 해결하지 못했는데, 이는 잘못된 이슈선정 때문이었다고 생각합니다. 이슈의 내용은 다음과 같았는데,
- 피크시간 때 latency 경감할 방안 분석
- kuberenetes 인증구조 개선
위 두 이슈를 해결하지 못한 이유는 이슈 자체가 모호했고, 티켓 선정 과정에서 고려를 못한 부분이 있었기 때문이었다고 판단됩니다.
전자의 경우 latency 의 원인부터 찾아야 하며, 워낙 복합적인 이슈가 있을 가능성이 높습니다. bottleneck 을 모르는 상황에서 이를 찾아서 해결하는 것까지 2주에 하는 것은 불가능했습니다. 이슈를 좀 더 명확하게 나누어, 원인을 분석하기 위한 스텝부터 했었어야 했다고 생각합니다.
후자의 경우 kubernetes 의 초기 셋업에도 많은 오버헤드가 있었고, kubernetes 를 쓰는 다른 팀의 니즈까지 고려하여 회사 전체적으로 설계할 필요가 있었는데 팀 이슈로 해결하려다 보니 다소 문제가 발생했습니다. 또한 작업자분이 kubernetes 에 익숙하지 않았던 점도 시간을 잡아먹는 요소였습니다.
그 외의 다른 이슈들은 큰 문제 없이 잘 해결하였습니다.
4. Lessons
이번 기술부채 출장을 통해 여러가지 lesson 을 얻었는데, 굵직한 것만 나열해보면 다음과 같습니다.
A. 라이브러리를 함부로 포크하면 안된다
포크하고 쓸 당시에는 편하겠지만, 인하우스 라이브러리는 나중에 관리 코스트가 눈더미처럼 불어나게 됩니다. 더군다나 포크하고 작업한 사람이 퇴사하게 되면, 히스토리가 잘 관리되지 않아 이를 계속 발전시키기도 어렵습니다.그래서 정말 급하지 않다면 해당 레포에 PR을 날리는 것을 언제나 1순위로 고려해보아야 합니다.
B. 기술부채의 완전한 해결은 어렵다: 고리대출에서 저리대출로
이번 일의 목표가 기술부채 해결이지만, 아이러니하게도 많이 고민했던 내용은 “이게 오버엔지니어링이 아닐까?” 였습니다. 빌드 파이프라인의 경우 OS 별로 나눠진 파이프라인의 공통된 stage 를 합치는 이야기까지 나왔지만, 조사를 해보니 그렇게 어설프게 구현했다가 관리 코스트가 되려 커질 수도 있어서 그냥 OS 별 빌드 파이프라인에서 재시도를 하는 걸로 결론을 냈습니다. 이처럼 결국 기술부채 해결 또한 가성비의 문제이고, 우리는 엔지니어이므로 trade-off 를 잘 하는 것이 중요할 것입니다.
C. 테스트의 진가
이번 기술부채 출장에서 뼈저리게 느낀 내용 중 하나입니다. 이번에 기술부채를 해결할 때 테스트로 인해 큰 어려움도 겪었고 큰 도움도 받았습니다. 이번 작업으로 인해 서비스의 거의 모든 피쳐가 영향을 받았지만, 테스트 커버리지가 높지 않아 거의 모든 피쳐를 손수 테스트해야 하여 테스트에만 꼬박 하루가 걸렸습니다.
반대로, 테스트 커버리지에서 생각치 못했던 버그 하나를 잡아, 큰 문제 없이 고쳐지기도 했습니다. 낮은 테스트 커버리지도 부채라는 생각이 들기도 했습니다. 기존 앱에서 확장하는 경우는 사람이 테스트 하는 것이 더 효율적일 수 있지만, 이번 케이스와 같이 전체를 뜯어고치는 경우에는 테스트 케이스가 많은 시간을 절약해줄 수 있다는 것을 몸소 느꼈습니다.
5. 적용
출장에서 돌아온 이후, 그동안 개발했던 서버가 배포되었습니다. 기존에 서비스를 운영하면서 피크시간 때 latency 가 올라가는 문제가 있었는데, 최적화된 새 서버를 배포한 이후에는 피크타임에서의 latency 가 반 가까이 줄어든 것을 확인할 수 있었습니다.
기술부채의 해결은 기본적으로 생산성 향상을 목표로 하지만, 때때로 어떤 이슈들은 위 그래프처럼 유저 경험에 큰 영향을 미치기도 합니다. 이번 출장을 통해 베이글코드의 구성원들은 기술부채가 무엇인지, 그리고 기술부채의 해결이 생산성과 유저경험을 얼마나 향상시킬 수 있는지 깨닫게 되었습니다. 앞으로도 신규 개발과 부채 해결 사이에서 균형을 잘 잡아 좋은 서비스를 만들 수 있도록 노력할 것입니다.