나는야 CTO

자유멘토링이 활발한 소마 초기, 한 멘토님의 멘토링을 들은 우리는 각자 성향과 희망을 고려하여 CEO, CPO, CTO 포지션을 나눠 가지게 되었다.
3명 밖에 없는 팀에 C레벨이 3명인 게 참 재밌는 상황이지만, 본래의 의미를 조금 덜어내고 우리에게 적용되는 내용은 아래와 같았다.

CEO는 팀장으로서 전체적인 일정을 짠다.
CPO는 PM이 가져온 내용을 함께 토론하며 약점을 보완한다.
CTO는 CEO와 CPO가 결정한 기획을 바탕으로 구체적인 개발 일정을 이끌어 나간다.

이 중 나는 CTO를 맡게 되었는데, 솔직히 프로젝트 초반에는 할 일이 별로 없었다. 스프린트 플래닝도 다함께 했고, 테스트도 각자의 지인들과 함께 임의의 시간대에 진행하게 되었다. 매니징은 멘토님이 해주시는 것만으로도 따라가기 벅찰 정도였다.

하지만 프로젝트를 거듭하고, 우리 팀만의 agile 프로세스를 위한 체계가 점점 잡혀가자 중요한 것들이 많아졌다. 첫번째로 가장 고민이 많아진 것은 우리 팀의 CEO를 맡은 팀원이었다. 감사하게도 그러한 고민이 많다는 것을 잘 말씀해주셔서 그 사실을 알게 되었다. 몇 주 뒤를 내다보며 스프린트 플래닝을 하고, 회의에서 모든 팀원들이 의견을 낼 수 있도록 하며, 의사결정 절차와 시간은 효율적인지, 멘토님&사무국분들과는 어떻게 연락할지 등 많은 부분에서 주의를 기울이고 계셨다.

이러한 고민을 듣고 있었을 때, 나 또한 가만히 있을 수는 없었다. 한명의 같은 팀원으로서, 또 CTO로서 CEO와 나눌만한 이야기를 갖춰야겠다는 생각이 들었다. 그리고 CEO가 위와 같은 사항들을 고민하고 있을 때, CTO는 팀을 위해 어떤 것을 고민할 수 있을지 생각해보게 되었다.

그러다 3번째 스프린트에서 사건이 하나 생겼다.

우리는 전반적인 사용성을 모두 검증받기 위해 처음으로 외부 테스터를 모집했다. 지금까지는 팀원들과 팀원들의 지인들로만 테스트를 진행했었는데 이번에는 오후 6시 이후부터 테스트를 부탁한다는 처음으로, 고객과의 약속이 생긴 것이었다.

결론부터 말하자면, 간신히 맞췄다. 아니, 반은 맞추고 반은 못맞췄다. 예정대로라면 테스트 권장 시간 30분 전까지 배포를 마쳐놓고, 사용자들이 정말로 테스트하기 괜찮은 상태인지 팀원들이 먼저 테스트해볼 생각이었다. 그런데 예상보다 개발이 늦어지게 되었고...이 사실을 배포가 끝났어야할 테스트 권장 시간 30분 전에 팀원분이 연락을 주셔서 알았다!

우선 30분 전에 App Distribution 링크를 보내는 데에는 이미 실패했으니 본격 테스트 권장 시간인 6시까지는 맞춰야한다고 생각했다. 많은 개발자들이 잘 하고 있다고해서 개발 기한을 맞추는 게 쉬운 일이기만 한 것은 아니니 당황할 필요는 없다고 생각했다. 그리고 우리 팀원분이 스케줄링 능력이 떨어져서 이런 일이 발생한 것도 아니었다.

우선 급하게 머지를 해서 새롭게 개발된 기능이 돌아가는 것만 확인하고 사용자들에게 Distribution된 앱을 다운받을 수 있도록 링크를 보냈다. 처음으로 설치한 Crashlytics에는 온갖 비정상 종료 로그가 찍혀나왔다. 급하게 머지한 테스트 앱을 사용해서 그런걸지도 모른다는 생각이, 수많은 비정상 종료 로그를 보다가 들었다.

하지만 회고는 해야죠

나는 이 일이 터진 이유는 사용자와의 중요한 약속이 있음에도 아무도 그것에 대해 미리 진행 상황을 실시간으로 확인하고, 알림을 주는 사람이 없었기 때문이라고 보았다. 원하는 기능 여부와 별개로, 우선 하던 것까지 마무리를 하고 배포를 하는 것은 그보다는 쉽게 할 수 있는 일이었다. 그랬다면 미리 확인도 제대로 하지 못한 앱으로 고객이 테스트하는 일은 막을 수 있었을 것이다.

이것을 계기로 다음 스프린트에서는 이러한 개발 일정에 관해 CTO인 내가 주도적으로 확인하고 개발 일정 매니징에 기여하기로 했다. 그리고 추가로, CTO가 하는 일에 관해 조언을 구하기 시작했다.

그래서, 여기서 CTO는 진짜 뭐하면 되나요?

내가 없어도 동일한 생산성이 나게 하기

저희 꼭꼭 소마 끝까지 함께해요~ 하고 약속했던 우리팀에서는 한 번도 상상해보지 못한 사항이었다. 한 사람이 빠져도 팀이 동일한 생상선과 퍼포먼스가 나려면 어떻게 해야할까?

여기서 첫번째로 필요한 게 클린 코드였다. 자세한 클린 코드 내용은 현재 스터디를 진행하며 알아보고 있으니 여기 서술은 패스. 아무튼 지금도 코드리뷰를 얼추 하고 있긴 했지만 클린 코드에 더욱 목숨을 걸어야하는 사람은 나였던 것이다!!

그리고 문서화가 필요하다. 우리 팀 내의 개발 가이드라인이 정립되어 있어야한다고 하셨다. 클린코드 스터디에서 배웠으니까 대충 알겠지하고 생각하지 말고 잘 정리를 해두는 것이 좋겠다고 생각했다.

기술적 부채 트래킹하기

기술적 부채를 얼마나 쌓아야하고 이것을 언제 상황해야하는지에 관한 판단을 하는 것이 CTO라고 하셨다. 기술적 부채란 아 이거 이렇게 짰어야 하는데 혹은 아 이거 이렇게 짜면 안됐는데하는 생각이 들게하는 모든 것을 말한다.

이러한 기술적 부채를 본 프로젝트 시간에 하면 너무 시간이 촉박하기 때문에, 이것을 해결하는 데에 개인 공부 시간인 챕터 시간을 활용하면 좋다고 하셨다. 그래서 큰맘 먹고... 원래 챕터 시간에 하려던 ts 프로젝트를 포기하고 이 부분에 더욱 열중해보기로 했다! 사이드 프로젝트는 언제든지 할 수 있지만 실시간으로 쌓여나가는 기술적 부채를 해결해보는 경험이 훨씬 나에게도 값진 경험이 될 것이라고 생각했기 때문이다.