디디움은 네 명이 만든다. 기획, 화면, 서버, AI를 한 사람씩 맡고, 기획 문서랑 코드를 한 저장소(코드와 문서를 모아 두고 같이 고치는 곳)에 같이 둔다. 혼자 만들 땐 필요 없던 규칙이 넷이 되니까 생겼다. 그 과정에서 팀 규칙 문서에 네 가지를 적었다. 특히 서로의 일이 만나는 지점에서 필요한 것들이다.
네 역할로 나눴다고 기능이 네 조각으로 깔끔하게 나뉘지는 않는다. 사용자가 이력을 확인하는 기능 하나만 봐도, 확인 기준을 정하는 기획, 후보와 원문을 보여 주는 화면, 상태를 저장하는 서버, 근거를 추출하는 AI가 다 연결된다. 각자 맡은 부분을 잘 만들어도, 이어지는 곳에서 서로 다른 뜻으로 쓰면 사용자는 그걸 한 기능으로 쓸 수가 없다.
그래서 팀 규칙은 각자의 작업 방식을 전부 맞추기보다, 서로의 일이 맞닿는 부분을 정하는 데 집중했다.
기획도 같이 한다
규칙 얘기 전에, 디디움에서 바꾼 게 하나 있다. 기획을 나 혼자 잡지 않는다. 이제는 개발자도 기획을 해야 하는 시대라고 생각해서, 조금 느리더라도 같이 논의하면서 기획하는 쪽을 골랐다. 반대로 개발 쪽은 기획자도 같이 본다.
9월 초에는 기획안을 팀에 열어 놓고 검토를 받았다. 서버, 화면, AI 담당 세 사람이 각자 검토 문서를 올렸고, 지적이 27건 나왔다. 그걸 하나씩 기획서와 대조해서 판정하고, 받은 이유와 안 받은 이유를 문서 하나에 같이 남겼다. 21건은 받았고, 4건은 일부만 받았다. 1건은 받으면 안 되는 것으로 판명됐고, 1건은 맞는 지적이지만 아직 못 닫았다.
제일 컸던 건 서버 담당이 짚은 목적 문제였다. 이게 대회용인지, 상품 완성이 목표인지부터 정해야 한다는 것. 맞춰 보니 기획서 로드맵대로 가면 대회 제출 마감까지 배포된 서비스가 안 나왔다. 그래서 제품 기준선은 그대로 두고, 그중 대회까지 만들 부분만 따로 떼어 냈다. 자기소개서가 통째로 빠져 있다는 것도 AI 담당이 짚어서 들어갔다.
반대로 받지 않은 것도 있다. 공고 주소만 넣으면 원문을 가져오자는 제안이었는데, 약관을 직접 확인해 보니 사전 허락 없는 자동 수집을 금지하고 있었다. 사용자가 직접 준 주소 한 건이라도 서버가 그 페이지를 읽으면 같은 조항에 걸린다.
1인 빌더(혼자 기획부터 개발까지 다 하는 사람)로 만드는 것보다 속도는 물론 느릴 수 있다. 의견마다 받은 이유와 안 받은 이유를 남기는 수고도 든다. 하지만 혼자 만들면, 여러 사람의 다른 생각과 경험에서 나오는 서비스의 엣지(남들과 다른 날카로운 한 끗)가 부족해질 수 있다. 그래서 협업은 반드시 필요하다고 생각한다.
이렇게 같이 기획하는 방식은 이번이 처음이다. 아래 네 규칙도 그렇게 같이 일하면서 하나씩 필요해진 것들이다.
하나. 기획 문서가 기준이다
뭘 만들지는 기획 문서가 정한다. 화면이나 정책, 데이터 구조가 문서랑 달라져야 하면 문서를 먼저 고치고 코드를 고친다. 급해서 코드부터 바꿨다면 그 사실을 리뷰 요청(바꾼 내용을 다른 사람에게 확인해 달라는 요청)에 적는다. 조용히 넘어가지 않는 게 규칙이다.
예를 들어 제출 조건을 바꾸는 건 버튼 문구만 고치는 걸로 안 끝난다. 어떤 이력이 제출 가능한지, 서버가 어떤 상태에서 파일을 만들지, 화면이 어떤 이유를 안내할지가 같이 바뀐다. 문서를 먼저 고쳐 두면 다른 담당자도 같은 변경을 보고 작업할 수 있다.
개인 참고 구현이랑 팀 제품도 구분한다. 팀 규칙에는 개인 디디움의 코드와 검증 수치를 팀 제품의 완료 근거로 옮기지 않는다고 적었다. 한 사람이 실험한 경로가 팀 저장소에서도 그대로 될 거라고 가정하지 않으려고.
둘. 합치는 사람은 리뷰한 사람이다
각자 자기 브랜치(남의 작업과 섞이지 않게 따로 떼어 둔 작업 공간)에서 작업하고, 자동 검사를 통과한 다음 리뷰를 요청한다. 작업을 합치는 버튼은 만든 사람이 아니라 리뷰한 사람이 누른다.
리뷰에는 기다리는 시간이 든다. 혼자 할 때처럼 바로 합치면 더 빠를 수도 있다. 대신 연결된 영역을 맡은 사람이 변경을 읽고 확인할 기회가 생긴다. 원문 근거를 다루는 규칙처럼 여러 역할에 걸친 변경은, 만든 사람이 자기 영역에서 본 결과만으로 끝내기 어렵다.
셋. 겹치는 파일에는 주인이 있다
충돌은 대부분 여러 사람이 같은 파일을 고칠 때 생긴다. 그래서 세 곳에 주인을 정했다.
- 공통 디자인 값: 색과 간격처럼 여러 화면이 같이 쓰는 값은 화면 담당이 관리한다. 기능마다 필요한 값을 제각각 추가하지 않게 요청하는 길을 뒀다.
- 데이터베이스 변경 파일: 데이터를 저장하는 구조를 바꾸는 파일은 서버 담당이 관리한다. 팀 문서에는 두 사람이 같은 날 만들면 변경 번호가 겹칠 수 있다는 이유도 적혀 있다.
- 핵심 데이터 모양: 다른 담당자가 데이터를 읽고 쓰는 건 자유지만, 항목 이름이나 구조를 바꿀 땐 미리 알린다. 그 데이터를 받는 화면과 AI 코드에도 영향이 가니까.
모든 파일에 담당자를 붙인 건 아니다. 여러 사람이 같이 고칠 때 다른 영역까지 영향을 주는 곳 세 군데에만 경계를 둔 것이다.
한 기능이 여러 층을 지날 때는 아래층이 먼저라는 규칙도 있다. 로그인처럼 인증 처리랑 화면이 이어지는 기능은, 화면만 먼저 완성했다고 끝난 게 아니다. 서로 기다려야 하는 관계를 확인하고 순서를 잡아야 한다.
넷. 근거 없이 됐다고 말하지 않는다
"확인했다"는 말은 근거가 아니다. 실행한 명령이랑 실제 결과를 적고, 브라우저로 못 봤으면 못 봤다고 쓴다. 기능이 끝났는지는 기획한 기능과 실제 상태를 한 줄씩 비교하는 대조표에서 판단한다.
확인하지 못한 걸 말하지 않고 넘어가면, 읽는 사람은 확인한 걸로 받아들인다. 그래서 못 본 건 못 봤다고 꼭 적는다.
예를 들어 "로그인 확인함" 한 줄보다, 어떤 환경에서 로그인했고 어떤 화면까지 갔는지 적는 게 다음 사람한테 훨씬 도움이 된다. 자동 검사만 돌렸으면 브라우저 확인을 한 것처럼 쓰지 않고, 브라우저에서 눌러 봤어도 다른 기기까지 봤다고 넓혀 말하지 않는다. 확인한 범위를 정확히 남기는 규칙이다.
기능별 대조표에도 완료 표시만 넣는 게 아니라 그 판단의 근거를 같이 채우게 했다. 기획한 기능, 실제 작업, 확인 결과가 이어져 있어야 다음 담당자가 어디서부터 이어 보면 되는지 안다.
아직 맞춰 가는 중
규칙이 넷뿐인 데도 이유가 있다. 처음부터 다 정해 두기보다, 나머지는 각자 하던 대로 하고 실제로 부딪히는 일이 생기면 그때 한 줄씩 더하기로 했다.
돌아보면 화면과 정책을 정하는 것만으로는 부족했다. 이력을 확인한다는 말 하나도 화면, 서버, AI가 다르게 받아들이면 기능이 이어지지 않는다. 그래서 바뀐 기준을 어디서 읽고, 뭘 확인해야 끝났다고 말할지를 같이 정해 둔 거다.
물론 규칙 네 개를 적었다고 협업 문제가 다 풀린 건 아니다. 같이 기획하는 방식도, 이 규칙들도 이번이 처음이라 아직 맞춰 가는 중이다. 부딪히면서 새로 생기는 규칙과 바뀌는 방식은 계속 이어서 적어 가려고 한다.