원문: https://blog.passionoil.co/code-ownership/
2020년 11월 30일 글 입니다.
그때는 맞고 지금은 틀리다 - 코드 오너쉽 by 새발
난 XP(extreme programming)을 좋아한다. 오랜 생각인 “개발은 도구다”를 극대화할 수 있는 게 바로 XP라서.
xp에서는 여러 실천법과 규칙을 제시 하는데, 그 중 코드와 프로덕트에 대한 오너쉽을 개발팀 전체가 가져가는 collective ownership 이 앞서 말한 생각을 극대화 해주는 중요 포인트다.
현재 크클 개발팀은 3명이며, 이번 해 7월 까지는 2명이었다. 팀이라고 부르기 애매한 규모다. 때문에 개발 문화와 프로세스는 개발팀 리드인 내 취향이 많이 묻었다. 코드 오너쉽에 대해서도 내 취향이 두드러졌다. 앞서 말한 “개발은 도구다”라는 생각은 자연스레 “크클 개발팀은 앱/서버/웹 넘나들며 개발할 수 있어야 한다”로 이어졌다. 좋은 팀원들 덕에 내 생각은 큰 무리 없이 개발팀에 적용됐다. 그리고 크클 개발팀의 강점으로 자리잡았다. 백조(대표)도 나름 개발팀을 자부하는 듯 했다. 앱 출시 후 1년간은 그렇게 큰 문제가 없었다.
크클 앱은 퀄리티를 낮추는 대신 굉장히 빠르게 개발되었다. 기억으로는 2019년 8월 말 쯤 기획과 디자인을 시작했고, 10월 초~중순 쯤 첫 버전을 릴리즈 했다. 워드프레스로 만들어져 있던 크클 웹사이트를 유지하며 새로운 DB와 서버, 새로운 앱을 개발했다. 개발 시작은 혼자 했고, 개발 중간에 짱짱 개발자 “해달”이 합류했다. 첫 릴리즈 약 한달 후가 되어서야 스프린트를 도입 했고 스프린트 주기는 1주일이었다. 평균 1.7주에 한번 정도 크고 작은 릴리즈를 진행했다.
1년이 지나 2020년 8월이 되었다. 퀄리티나 버그 발생 빈도, 관리자 사이트가 좀 아쉬웠지만, 릴리즈 빈도는 만족스러웠다. 일정과 버그, 유저 CS말고는 평화로웠다. 그런데 갑작스럽게 그동안 조용히 쌓이던 기술 부채, 주로 코드 복잡도가 개발팀의 발목을 낚아챘다. 깊이를 알 수 없는 물탱크에 물을 계속 붓다가 어느 순간 물이 넘쳐서 도저히 막을 수 없는 그런 느낌이었다. 다행인 건 넘치는 물이 익사할 만큼은 아니라는 것.
그리고 그제서야 부랴부랴 리뉴얼과 리팩터링을 진행했다. 새로운 피쳐 개발과 유지보수와 함께 해야했기 떄문에 진행이 더뎠다. 2달 정도가 지난 지금 약 40%정도의 중요한 기능들을 리팩토링, 리뉴얼 했다. 아마 내년 1분기 내로는 끝나지 않을까 싶다.
높은 코드 복잡도가 가져다 주는 악영향은 매우 크다. 일정 예측 실패나 버그 발생 빈도를 높이는 것도 높이는 거지만, 개발자의 의욕을 낮추고 두려움을 키우는 게 제일 문제라 생각한다. 빠르게 첫 버전을 릴리즈해야 했기에 크클 코드 베이스는 그렇게 좋지 않았다. 서버 구조도 큰 신경을 못썼고, 워드프레스로 만들어진 기존 사이트를 새로운 앱/서버와 함께 운영해야 해서 각 시스템 사이의 간극을 맞추기도 어려웠다. 복잡한 코드 베이스와 환경에서 빠르게 기능을 치고 나가야 했다. 서비스 상에서의 비지니스 로직이 정립되지 않아 기능에 대한 룰도 자주 바뀌었다. 새로운 기능을 릴리즈 하면 그 다음 기능을 개발하는데 다시 몰두 했다.
위 상황에서 리팩터링할 시점을 잡지 못한 게 근본적 원인이다. 리팩터링은 사치라고 생각했고, 그저 새로운 기능 개발에만 매달렸다. 그땐 이 생각이 맞았고 지금은 틀렸다.
맨 처음 언급한 collective ownership의 가장 큰 장점은 개발팀 전체가 코드와 프로덕트에 대한 오너쉽을 모두 가져가 개발팀 누구나 기능 개발과 유지보수를 할 수 있도록 하는 것이다. 빠른 기능 개발에 대한 은탄환 같이 보인다. 내 실수이기도 하지만, 여기서의 가장 큰 맹점은 “코드, 서비스, 개발 환경에 대한 품질 관리”가 전제가 되어있어야 한다. 이는 xp의 다른 실천법에도 언급되고 관리된다. 예를 들어 TDD, CI, 코드 디자인 개선 등. 나는 “빠른 개발, 높은 릴리즈 빈도, 개발은 도구다”라는 생각에 갇혀 이것들을 등한시 했다.
이제는 챙겨야 하고, 부랴부랴 챙기고 있지만 문제는 개발팀의 프로세스와 문화에 녹아들 때 까지는 시간과 비용이 들어간 다는 것. 그리고 계속 새로운 기능 개발을 치고 나가야 한다는 것. 동시에 두가지를 하기엔 아직 개발팀은 작고 소중한 자원이다. 묘수가 필요하다.
묘수라고 하기엔 너무 간단하지만, 개발팀에서는 collective ownership을 유지한 채 프로젝트 별로 약한 code ownership을 가져가도록 했다. 현재 웹/앱/서버 이렇게 총 3개의 프로젝트를 각 개발자가 하나씩 들고 갔다. 오월은 웹을, 새발(나)은 서버를, 해달은 앱을.
각 프로젝트에 대한 코드 오너쉽을 가지면 아래와 같은 역할을 맡게 된다.
- 해당 프로젝트에 코드 복잡도를 관리하고 구조와 방향성에 대한 권한을 제일 크게 가진다.
- 프로젝트에 리팩터링이나 리뉴얼이 필요할 경우 일감 범위와 일정을 조절할 수 있다.
- CI/CD, 자동화, 개발 환경 개선, TDD나 QA등 등 품질을 높일 수 있는 여러 도구들을 도입할 수 있다.
러프하게 2달 정도 시행했지만 코드 품질과 구조가 굉장히 깔끔해지고 있다. 당연하게도 릴리즈 빈도는 줄어들었다. 조금 불안했지만 좋은 트레이드 오프라 생각했다. 크클 개발팀은 앞으로 더 많은 기능들을 탄탄하고 적은 비용으로, 적은 스트레스로 개발할 수 있을 것이다.
