문서를 쓰는 게 아니라,
앱이 읽을 데이터를 만든다

SI 일을 해보면 코드보다 문서가 먼저 사람을 지치게 합니다. 킥오프 회의가 끝나면 회의록을 작업 개요로 옮기고, 같은 내용을 제안서 톤으로 다시 쓰고, 기능 목록을 요구사항 표로 풀고, 그걸 또 WBS 태스크로 쪼갭니다. 매주 주간 보고서가 따라붙고, 끝나면 결과보고서를 씁니다. 한 번 정한 내용을 형식만 바꿔 대여섯 번 옮겨 적는 일 — 가치는 낮은데 빠지면 납품이 안 되는, 전형적인 반복 노동입니다. 이걸 하네스에 넘기기로 했습니다.

그런데 한 가지를 먼저 분명히 했습니다. 이건 '글쓰기 자동화'가 아닙니다. 우리 ERP는 문서를 PDF 한 장이 아니라 섹션·행 단위의 데이터로 저장합니다. 작업 개요에는 `summary`·`goals`·`scope` 같은 정해진 섹션 키가 있고, 요구사항은 `category`·`priority`·`story_points` 컬럼을 가진 행입니다. 앱은 이 키로 데이터를 읽어 화면을 그립니다. 그래서 하네스가 만들 산출물은 멋진 산문이 아니라, 앱의 SECTIONS 스키마에 1:1로 정렬된 구조여야 했습니다. 키 하나가 어긋나면 앱이 그 섹션을 못 읽습니다.

왜 그냥 쓰지 않고 이렇게 만들었나

한 번 호출이 만들어내는 것

흐름은 이렇습니다. /up-si 제안서 한 줄을 던지면, 하네스가 먼저 프로젝트 컨텍스트와 회의록을 읽습니다. 그다음 제안서의 7개 섹션 — 제안 요약·수행 범위·사업비·일정·팀 구성·기술 접근·가정 사항 — 을 앱이 기대하는 키로 채웁니다. 미확정 단가는 `[확인 필요]`로 남기고, 리스크 테이블까지 붙입니다. 저장 전 Self-Review로 '7개 섹션이 다 찼는가, budget에 역할별 MM·단가가 있는가'를 스스로 점검하고, 통과하면 ERP에 push합니다. 사람이 한 일은 문서 종류를 고른 것뿐입니다.

여기엔 이 시리즈에서 반복해온 원칙이 그대로 들어 있습니다. 지어내지 않기 — 모르는 수치는 채우지 말고 표시하라(`[확인 필요]`). 생성과 검증 분리 — 쓰는 즉시 저장하지 않고 체크리스트를 통과해야 한다. 역할 경계 — SI 문서 에이전트는 절대 소스 코드를 건드리지 않는다. 그리고 디스크가 진실 — 연동이 끊겨도 docs/si/*.md 는 남고, ERP는 그걸 언제든 다시 읽어들일 수 있습니다.

문서 자동화에서 진짜 어려운 부분

이 일의 난이도는 문장 생성에 있지 않습니다. LLM은 그럴듯한 제안서를 얼마든지 씁니다. 어려운 건 그 출력이 앱이 실제로 읽어들일 수 있는 형태인가입니다. 섹션 키가 하나 어긋나면, 행 기반 문서의 JSON 스키마가 안 맞으면, 담당자 이름이 ERP의 프로필명과 매칭되지 않으면 — 문서는 멀쩡해 보여도 앱 안에서는 빈칸입니다. 그래서 이 하네스의 핵심 가치는 글솜씨가 아니라 스키마 충실도에 있습니다. 자유 산문을 구조화된 데이터로 바꾸는 그 변환을, 사람이 매번 손으로 하지 않게 만든 것입니다.

그리고 자동화될수록 사람의 자리는 더 분명해집니다. 하네스는 회의록을 문서 형식으로 옮기고 스키마를 맞추는 일을 가져갔지만, 사업비가 맞는지, 일정이 현실적인지, 고객에게 약속해도 되는 범위인지는 여전히 사람이 판단합니다. `[확인 필요]` 표시는 바로 그 경계선입니다 — 기계가 옮긴 것과 사람이 책임질 것을 갈라놓는 표시. 문서를 빨리 만들수록, 그 표시를 끝까지 확인하는 일이 더 중요해집니다.