한 사람이 만들고 열 사람이 쓰는 시스템

소수 인원으로 사내 시스템을 만들 때 속도를 내는 방법은 빨리 쓰는 것이 아니었습니다. 나중에 합류할 사람이 읽을 것을 전제로 두는 것이었습니다.

사내 관리 시스템은 지금 열 명 남짓이 사용합니다. 만드는 쪽은 그보다 훨씬 적습니다. 이 조건에서 가장 흔한 실패는 "일단 돌아가게" 만들고 넘어가는 것입니다. 문제는 그게 실패라는 사실이 몇 달 뒤에야 드러난다는 점입니다.

값이 두 곳에 있으면 반드시 어긋난다

가장 많이 지키려고 하는 규칙은 "원천은 한 곳"입니다. 추상적으로 들리지만 실제로는 아주 구체적인 이야기입니다.

사업자 정보는 원래 푸터 컴포넌트 안에 있었습니다. 그런데 검색엔진에 넘기는 구조화 데이터도 같은 값을 써야 했습니다. 두 곳에 적어 두면 한쪽만 고쳐지고, 화면에 보이는 주소와 검색 결과에 나오는 주소가 달라집니다. 그래서 값을 파일 하나로 빼고 양쪽이 그것을 읽게 했습니다.

사이트맵도 같습니다. 라우트 목록과 사이트맵 목록을 따로 관리하면, 지운 페이지가 사이트맵에 남아 있게 됩니다. 실제로 존재하지 않는 주소 여덟 개를 검색엔진에 광고하고 있던 적이 있습니다.

같은 값을 두 번 적는 순간, 그 둘이 어긋나는 것은 시간 문제일 뿐입니다.

결정에는 이유를 붙여 남긴다

한 사람이 개발할 때 문서를 쓰지 않는 이유는 명확합니다. 읽을 사람이 없으니까요. 그런데 몇 달 뒤의 자신은 다른 사람입니다.

그래서 "무엇을 했다"보다 "왜 그렇게 뒀는지"를 남깁니다. 특히 이상하게 보이는 코드에 이유가 필요합니다. 데이터베이스 연결에서 캐시 설정을 0으로 두는 부분이 그렇습니다. 이유를 모르면 최적화라며 되돌리게 되고, 되돌리면 운영에서 터집니다.

한 걸음 더 나가서, 의도적으로 뺀 것도 이유와 함께 남깁니다. 가짜 실시간 카운터를 만들었다가 지웠습니다. 숫자가 몇 초마다 바뀌면 살아 있는 것처럼 보이지만, 그건 신뢰를 만드는 방향이 아니라 반대입니다. 이 기록이 없으면 비슷한 제안이 다시 올라옵니다.

나중에 합류할 사람을 기준으로 삼는다

인력이 늘어날 가능성을 열어 두고 있습니다. 그래서 판단 기준을 "지금 내가 빠르게"에서 "다음 사람이 하루 안에 파악할 수 있게"로 바꿨습니다. 이 기준은 생각보다 많은 결정을 자동으로 정리해 줍니다.

• 폴더 구조는 취향이 아니라 관례를 따른다 — 설명할 것이 줄어든다.
• 컴포넌트 상단 주석에 "이 화면이 무엇이고 왜 이 형태인지"를 쓴다.
• 숫자를 코드에 박을 때는 그 숫자에 연쇄되는 다른 값들을 함께 적어 둔다.

작은 팀에서 속도를 만드는 것은 빨리 쓰는 손이 아니라, 다시 이해하는 데 드는 시간을 줄이는 구조라고 생각합니다.