그때는 맞고 지금은 틀리다 – 코드 오너쉽

새발의 개발 회고

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개의 프로젝트를 각 개발자가 하나씩 들고 갔다. 오월은 웹을, 새발(나)은 서버를, 해달은 앱을.

각 프로젝트에 대한 코드 오너쉽을 가지면 아래와 같은 역할을 맡게 된다.

  1. 해당 프로젝트에 코드 복잡도를 관리하고 구조와 방향성에 대한 권한을 제일 크게 가진다.
  2. 프로젝트에 리팩터링이나 리뉴얼이 필요할 경우 일감 범위와 일정을 조절할 수 있다.
  3. CI/CD, 자동화, 개발 환경 개선, TDD나 QA등 등 품질을 높일 수 있는 여러 도구들을 도입할 수 있다.

러프하게 2달 정도 시행했지만 코드 품질과 구조가 굉장히 깔끔해지고 있다. 당연하게도 릴리즈 빈도는 줄어들었다. 조금 불안했지만 좋은 트레이드 오프라 생각했다. 크클 개발팀은 앞으로 더 많은 기능들을 탄탄하고 적은 비용으로, 적은 스트레스로 개발할 수 있을 것이다.

회사의 막내가 TF리드가 되었다. 그 회고

우리 회사의 CTO(Chief Technology Officer, 최고 기술 개발자)인 새발은 항상 문제가 발생하면 말하곤 했다.

이 문제에 대한 원인을 파악해야합니다.

이전까진 왜 그가 문제의 원인에 집착하는지 몰랐다.

그런데 최근 마케팅의 강력한 툴 중 하나인 회사 서비스 체험권 tf팀의 리드가 되면서 새발의 말을 이해할 수 있었다. 웁스! 실무 1년차인 나에게 이런 중요하고 큰 사이즈의 프로젝트가 떨어지다니!
이 사실은 알바로 회사에 발을 담근 나의 성장이 증명됨과 동시에
업무 경력이 없는 나의 약점을 남들보다 두 세배로 학습하며 더 탄탄히 다지며
운전을 시작해야한다는 사실의 시발탄이었다. 걱정대로 문제는 시작과 동시에 터졌다.
여기서 리드인 내가 실수한 첫 번째 문제.

아무리 뛰어난 능력을 가진 팀원이라도 문제와 목표에 공감이 되지 않으면 당연하게 능력을 발휘하지 않는다, 아니 발휘할 수 없다. 이들의 능력을 200%까지 끌어 올리는게 리드의 역할이다.
나는 처음부터 자신 없는 태도로 회의를 이끌었다. 그러면서도 강압적이었다.
TF(Task Force의 약자,어떤 과제를 성취하기 위해 필요한 전문가들로 구성되고 기한이 정해진 임시조직)라는 틀에 갇힌것일까.
압도적인 속도만이 성과라고 생각했던 탓에 이미
구상해놓은 그림이 아니면 팀원들이 낸 의견이 들리지 않았다. ex)이 날 테스트 발송을 하면 문제가 생길수도 있어요. 꼼꼼히 다지고 가는게 맞는 방법일 수 있습니다.

조금 늦은 사후 회고방식을 도입해서 원인을 찾아봤다.
내가 Pm의 역할을 정말 이해했다면,
위 의견에 대해 재고해보고 일정을 무리해서 타이트하게 잡지 않았을 것이다.
그랬다면 이용권 미지급이라는 실수를 범하지 않고 체크할 수 있는 시간이 분명 확보 되었을것이다.
또 그랬다면 소중한 자원인 개발자의 피로도를 늘리지 않았을것이고 개발의 디테일은 올라갔을것이다. 그러면 함께하는 팀원들과 나는 불안함은 줄고 tf팀을 위해 생각하는 시간이 늘었을것이다.
나는 안해도 되는 실수를 경험하고서야 이 사실을 깨달았다.
결국 커뮤니케이션 비용이 올라갔고 TF 초기에 설정한 목표 자체는 달성하지 못했다.

실수는 아프지만 대신 되풀이하지 않을 반사신경을 만들어준다.
5why방식에 의거하여 문제가 발생한 원인을 찾아보자.

문제1

질문은 ” 기획은 빨랐다. 그런데 왜 리드는 예상 일정을 정확하게 예측하지 못했나.”

  • 문제 : 회의 자리에서 개발일정까지 모두 결론 내려야 했다는 생각에 사로 잡혔다. 개발에 대한 이해도가 없는 상태이기 때문에 무리한 일정이라는 사실을 인지하지 못했다.

→ 그렇다면 문제의 원인은 무엇일까?

  1. 왜 회의 자리에서 사이즈와 일정까지 모두 확정해야했나: TF체험권의 검증 기간은 3주였기 때문에 일정 내 개발과 배포가 진행되지 않으면 검증이 불가했다. 담당 PM은 목표 달성을 위해 빠른 일정이 필요하다고 판단했다.
  2. 왜 목표 달성을 위한 다른 방법을 검토하지 못했나: 마케팅 시즌이 다가오면 기존 업무를 수행하는데도 빡세기 때문에 유일하게 가설 검증이 가능한 시간이라고 판단했다.
  3. 왜 리드는 다른 방법을 고려하지 못했나: 다른 방법을 고려하는 시간을 쏟기엔 TF의 기간이 짧았다.
    개발팀의 리소스 부족을 인지했기 때문에 해당 회의에서 빨리 결론을 내려야 했다. 팀원과 닫른 방법을 논의해서 다시 결정하기 어려운 상황이었다.
  4. 왜 일정대로 업무를 진행해야했나:일정보다는 해당 TF에서 홈페이지를 구축하여 절대 숫자보다는 검증 자체가 중요했다. 일정이 더 걸리더라도 확인하고자 하는 가설을 검증하는게 먼저니까. 우선순위를 나중에 깨달았다.

질문을 종합해보면 개발 일정이 미뤄진 것이 문제라기보다 정확한 일정을 추정하는 과정에서 시행착오가 있었다. 일정 추정이 불확실한 데는 크게 두 가지 이유가 있었다.

  • 개발 일정을 논의하기 위한 명확한 문서가 없었다. 문서가 없으니 관련 개발의 사이즈 검토도 회의자리나 구두로 대략적인 수준에서 이루어졌다. 담당 개발자가 대략적인 일정을 말하면 리드는 그 일정이 픽스라고 생각했다. 정확한 일정을 잡으려면 QA를 돌려서 필요한 기능이 무엇인지 기획이 탄탄해야했고 개발자는 코드를 까봐야 정확한 일정을 산정할 수 있다.
  • 지표에 너무 초점을 맞춘것. 진짜 중요한점은 가설 검증에 있었다. 일정이 촉박한 상황이라 빠르게 일정을 논의하고, 빨리 개발해야한다는 생각이 지배적이다 보니 해당 회의 자리에서 일정을 모두 논의하고 결정하게 되었다.

문제2 현장 매니저들과의 소통

나에겐 당연하지만 그들에겐 당연하지 않았던 사실

  1. tf리드는 팀장급의 업무 지시 권한을 갖는다
  2. 이 tf는 회사의 중요한 프로젝트이다.
  3. 커뮤니티매니저의 업무 리소스를 고려하여 기획을 한다.

정보의 비대칭은 의구심을 낳는다.

그들의 의구심

  1. 홍이가 왜 팀장급의 업무 지시 권한을 갖게 되었는가 -홍이는 tf성공 경험이 있는 팀원이며, 우리 회사에서는 업무적 성과를 이룬 팀원에겐 더 많은 기회가 주어진다.
  2. 내가 이 일을 왜 해야하지? -pm은 미리 목표에 aligin을 시키지 못했다. 더 나아가 회사에서 진행하는 프로젝트에서 자주 현장 매저니들과 자주 얼라인이 되지 않은채 일을 실행했다.
  3. 왜 커뮤니티 매니저의 리소스를 고려하지 않고 기획을 하지? -기획단계에선 현장 매니저들의 리소스와 생각을 상당 부분을 고려하여 진행한다. 정보의 공유가 부재했다는 사실을 인지하고 기획의 의도와 공지사항을 전달했을 때 현장 매니저는 납득하지 못했고 그 이유를 리드에게 물어보지 않았다. 사무실과 현장의 신뢰감이 없다.

현장에서 근무하는 팀원들이 이 사실을 당연히 알 거라고 생각한 곳에서부터 갭은 시작되었다.
이 사실은 이번 tf팀에서의 문제로 시작 되었지만 그간 사무실과 현장매니저들과의 정보 공유가 얼마나 안되어 있었는지 수면 위로 드러나게 되었고 원인을 발견했으니 다양한 해결책이 될 법한 것들을 시도해볼 수 있었다. TF팀에 현장 매니저 합류, 팀 채널에 지점장 합류, 공지 채널 오픈, 전달 내용은 구두가 아닌 문서 작성으로등의 방식이었다.
이후에 문서로 공유함에도 불구하고 병목은 생겼기 때문에 이 문제는 아직은 ing가 맞는 것 같다.

해결책을 적용하고 평가하기

문제의 근본적인 원인을 찾아냈으니 해결할 방법을 고민한다!
이번 TF팀의 경우 문제 발견과 동시에 바로 해결책을 적용해보았다.
개발 일정 산정이 어렵다는 문제는 2가지 근본 원인

  1. 개발 스펙을 논의하는 문서가 없다.
  2. 목표달성 때문에 일정에 대한 압박이 컸다.

이에 대한 해결책은 아래와 같다.

  1. 협업 문서를 작성한다: 이 문서에는 기획에 담긴 내용을 어떻게 개발할지, 서로의 생각을 동기화하는 싱크업 미팅, 일감/일정 산정,유저 스토리보드를 QA템플릿을 이용해 진행한다. 이후 추가 수정 사항, 버그가 발생할 경우 2차로 추가 작업을 진행한다. 타임라인을 병렬적으로 확인할 수 있어야한다. 아이데이션 문서도 작성한다. 작은 것이라도 좋으니 아젠다와 얼라인, 아이데이션의 목표는 꼭 도출한다.
  2. 매주, 계획했던 목표와 일정에 문제가 없는지 논의하고, 팀원들과도 주기적으로 목표나 일정을 조정해나간다.

목표지표를 보자면 이번 TF실패했지만
협업시 발생하는 자주 발생하는 문제들의 원인을 파악하여 수면 위로 올렸고, 툴의 검증을 이뤄냈다는 점에서 개인적으로 만족스러운 TF리드 경험이었다고 말할 수 있다.