반년 뒤에도 돌아갈까

오늘 만들 파일 자체는 꽤 오래 갑니다. 단일 HTML은 브라우저만 있으면 열리고, 브라우저는 옛 문법을 좀처럼 버리지 않습니다. 십 년 전 페이지가 지금도 열리는 이유가 그것입니다.

문제는 바깥에 기대는 부분입니다. 오늘 만들 도구는 세 곳에 기댑니다. AI 해석을 받는 곳, 데이터를 저장하는 곳, 엑셀을 읽고 차트를 그리는 라이브러리를 내려받는 곳입니다. 이 셋은 우리 것이 아닙니다.

API 키는 만료되거나 요금제가 바뀝니다. 데이터베이스는 무료 플랜이면 한동안 안 쓸 때 멈추는 경우가 있어 다음 분기에 열었더니 연결이 안 되는 일이 생깁니다. 라이브러리는 주소가 바뀌거나 새 버전이 올라가면서 동작이 달라집니다. 어느 것도 우리가 손쓸 수 없고, 대개 필요한 순간에 알게 됩니다.

그리고 이 모든 것보다 흔한 일이 있습니다. 만든 사람이 자리를 옮기는 것입니다. 인사이동은 매년 있고, 그때 남는 것이 코드 파일 하나뿐이면 아무도 손대지 못합니다. 열어봐야 무슨 뜻인지 모르니 결국 새로 만들거나, 더 흔하게는 다시 엑셀로 돌아갑니다.

그래서 이 과정은 결과물을 둘로 봅니다. 하나는 도구이고 다른 하나는 그 도구를 다시 만들 수 있는 문서입니다. 뒤엣것을 PRD라고 부릅니다. 제품 요구사항 문서라는 뜻인데, 이름보다 중요한 것은 쓰임입니다. 앱이 깨져도, 담당자가 바뀌어도, 이 문서만 있으면 AI로 언제든 다시 만들 수 있습니다. 코드는 결과이고 PRD는 원본입니다. 원본이 있으면 결과는 몇 번이든 다시 뽑을 수 있지만, 결과만 있으면 원본을 복원할 수 없습니다.

한 가지 더 있습니다. PRD를 프로젝트 지시문에 넣어두면 그다음 모든 대화가 그 규격 안에서 움직입니다. 어제 설명한 컬럼 이름을 오늘 다시 설명하지 않아도 되고, "아까 말한 기준대로"라고만 해도 통합니다. 대화를 새로 시작해도 마찬가지입니다. 이것이 개인의 기억에 의존하던 일을 문서에 옮기는 방식입니다.

일곱 항목

템플릿은 일곱 항목입니다. 항목마다 미리 막으려는 사고가 다릅니다.

1번은 목적입니다. 한 문장으로 적습니다. 여기서 막히면 아직 만들 때가 아닙니다. "무엇을 넣으면 무엇이 나오는 도구"로 적히지 않는 일은 요구가 덜 여문 것이고, 그 상태로 시작하면 만드는 도중에 방향이 계속 바뀝니다. 2번은 입력과 출력 명세인데 컬럼 이름까지 적습니다. 한글과 공백을 쓰지 않고 단위를 이름에 넣고 날짜 형식을 통일합니다. 이 규칙 하나가 나중에 생길 오류의 절반을 미리 막습니다. 3번은 판정 규칙입니다. 기준값과 그 근거를 함께 적습니다. 이 항목이 비면 AI가 알아서 판단하게 되고, 그 순간 결과를 검증할 방법이 사라집니다.

4번은 AI의 역할입니다. 무엇을 맡길지보다 무엇을 맡기지 않을지가 중요한 항목입니다. 그리고 키가 없거나 오류가 났을 때 무엇으로 대신할지를 미리 정해둡니다. 실무에서는 도구가 멈추는 것이 틀린 답보다 나쁠 때가 많습니다. 5번은 기술 제약입니다. 서버 없이 브라우저에서 도는 파일 하나로 묶으면 배포도 인수인계도 단순해집니다. 6번은 완료 기준인데 뒤에서 따로 다룹니다. 7번은 유지와 확장으로, 지금 만들지 않기로 한 것을 적는 자리입니다. 나중에 "왜 이건 없지"라는 질문에 이 목록이 답이 됩니다.

기준이 바뀌었을 때

기준값이 바뀌었다고 해봅시다. 유류 오염 판정선을 500에서 800으로 올려야 한다면, 코드를 열어 숫자를 찾아 고치면 그날은 됩니다. 그런데 그렇게 몇 번 하고 나면 문서에는 500이 적혀 있고 코드는 800으로 돌아갑니다. 어느 쪽이 맞는지 확인하려면 코드를 읽을 줄 알아야 하고, 결국 만든 사람만 아는 도구가 됩니다.

PRD의 3번을 고치고 "이 문서대로 다시 만들어줘"라고 하면 문서와 도구가 늘 같은 것을 말합니다. 손이 한 번 더 가는 것 같지만 실제로는 덜 갑니다. 코드에서 그 숫자가 어디 있는지 찾는 시간이 없어지기 때문입니다. 개인의 재주가 부서의 자산이 되는 갈림길이 여기입니다.