5개월의 회고 — HEDVION 의 첫 분기
셋이서 시작한 풀스택 팀 HEDVION이 지난 5개월을 돌아보며 무엇을 배웠는지, 어디서 실패했는지 솔직하게 기록한다.
시작은 단순했다
작년 12월, 슬렉스와 밍스, 그리고 나 — 세 명이 따로따로 일하면서 비슷한 문제를 반복해서 풀고 있다는 걸 알아챘다. 배포 자동화, 서버 설정, 클라이언트 요구사항 정리. 아무도 혼자서 이걸 다 잘하지 못했다. 그래서 팀을 만들었다. 이름은 HEDVION. 특별한 의미보다는 우리 셋이 납득할 수 있는 이름이었다.
5개월이 지났다. 돌이켜보면 계획대로 된 게 별로 없다. 그런데 그게 꼭 나쁜 얘기는 아니다.
우리가 틀렸던 것들
처음에는 프로젝트 단위로 역할을 나누면 된다고 생각했다. 한 명이 백엔드, 한 명이 프론트, 한 명이 인프라. 실제로 해보니 경계가 그렇게 깔끔하지 않았다. 프론트를 짜다 보면 API 구조를 바꿔야 했고, 인프라를 건드리다 보면 배포 방식이 코드에 영향을 줬다.
두 번째로 틀린 것은 문서화였다. 초반에는 아무것도 적지 않았다. 세 명이 다 알고 있으니까. 3개월쯤 지나서 밍스가 “이거 왜 이렇게 돼 있어?”라고 물었을 때 아무도 기억 못 했다. 그때부터 운영 규칙을 텍스트로 남기기 시작했다.
세 번째는 납기 추정이다. 팀이 작으면 빠를 거라고 기대했다. 결정 속도는 빠른데, 실행 속도는 인원이 적어서 느렸다. 당연한 얘기인데 실제로 겪어보니 생각보다 타격이 컸다.
그래도 잘 된 것들
커뮤니케이션 비용이 낮았다. 슬랙에서 세 글자 보내면 의도가 통했다. 대기업에서 이메일 쓰고 승인받고 했던 것들이 15분 안에 결정됐다.
기술 선택도 빨랐다. 누군가 “이거 써보자”고 하면 다음 날 실제 코드에 들어가 있었다. 사전 검토 프로세스 같은 게 없었는데, 오히려 그게 학습 속도를 높였다.
블로그도 생각보다 가치 있었다. 처음엔 정리 겸 포트폴리오 정도로 생각했는데, 글을 쓰면서 스스로 생각이 정리됐다. 그게 실제 작업 품질에 영향을 줬다.
다음 5개월
팀 규모는 당분간 세 명으로 간다. 지금 구조가 아직 우리한테 맞는지 확인이 안 됐는데 사람을 더 넣는 건 성급하다. 클라이언트는 한 번에 두 곳 이상 받지 않는다. 우리가 잘할 수 있는 일의 범위를 지킨다.
돌아보면 실패한 지점들이 오히려 더 선명하게 기억에 남는다. 그게 다음 5개월의 재료다.
— by slecs