반복 산출물 생성을 AI에 맡긴 기록 — 무엇을 넘길 수 있고 무엇은 넘길 수 없었나

이 글의 범위를 먼저 분명히 해둔다. 실무 맥락을 다루지만 회사명, 제품명, 프로젝트명, 도메인 특성은 드러내지 않는다. 수치로 된 생산성 지표도 쓰지 않는다. 남는 것은 산출물을 다루는 방식에 대한 판단, 그리고 AI에 맡길 수 있는 것과 맡길 수 없는 것의 경계에 대한 관찰이다.

---

1. 같은 문서를 또 쓰고 있다는 자각

9년차쯤 되면 내가 쓰는 문서가 내 손에서 처음 태어나는 것이 아니라는 사실이 점점 선명해진다. 기능 명세서의 목차는 어느 프로젝트에서나 비슷하다. 테스트 계획서의 항목 구성도 조금씩 바뀔 뿐 큰 틀은 재활용된다. 설계 다이어그램도 익숙한 관계들을 반복해서 그린다. 프로젝트마다 새로 쓰는 것 같지만, 실제로는 같은 뼈대에 이름만 바꿔 끼우고 있는 경우가 많다.

이 자각이 어느 날 왔다. 특별한 계기는 없었다. 평일 어느 오후에 또 비슷한 문서를 새로 시작하고 있었고, 문득 "이걸 몇 번째 쓰고 있지"라는 생각이 들었다. 이 질문은 생산성의 언어로 번역하면 "이 시간은 어디로 가고 있는가"가 된다.

내가 쓰는 문서 중에는 내 판단과 맥락이 온전히 담겨야 하는 것이 있고, 그렇지 않은 것도 있었다. 판단이 들어가야 하는 문서를 쓰는 시간은 내 일의 본체다. 그렇지 않은 문서를 쓰는 시간은 내 시간 중 가장 대체 가능한 종류였다. 이 종류의 시간이 내 근무 시간에서 차지하는 비중이 적지 않다는 사실도 함께 자각됐다.

이 자각 이후 한동안 "그럼 이걸 AI에 넘길 수 있을까"라는 질문을 들고 다녔다. 답이 쉽게 나오지 않았다. 모든 반복 문서가 AI 자동화에 적합한 것은 아니었기 때문이다.

2. 무엇이 AI에 넘기기 좋은 산출물인가

넘기기 좋은 산출물과 그렇지 않은 산출물을 가르는 기준을 세 축으로 정리하게 됐다. 이 프레임은 누가 가르쳐준 것이 아니라 몇 번 맡겨보고 실패하면서 얻은 것이다.

첫째 축은 형식의 정형성이다. 템플릿이 명확하고, 섹션 구조가 정해져 있고, 각 섹션에 들어갈 내용의 성격이 일정한 문서는 넘기기 좋다. 반대로 "이번 건은 어떻게 쓰지"부터 고민해야 하는 비정형 문서는 AI가 생성한 초안이 방향을 찾지 못한다. 결국 내가 전체 구조를 다시 잡아야 하고, 그 시간이 처음부터 쓰는 시간과 크게 다르지 않다. 정형성이 높은 산출물일수록 AI의 상대적 이점이 커진다.

둘째 축은 입력의 구조화 정도다. 생성하려는 문서의 내용이 이미 다른 산출물 안에 존재하는지를 보면 된다. 예를 들어 요구사항이 잘 정리된 문서가 있고 거기에서 파생되는 설계 문서를 만든다면, 입력이 구조화되어 있다는 뜻이다. AI에 요구사항을 컨텍스트로 주고 설계 문서를 생성하게 하면 상당 부분을 맡길 수 있다. 반대로 입력이 흩어져 있고 내 머릿속에서 조합해야 나오는 내용이라면 AI가 쓸 재료가 부족하다. 내가 재료를 정리해서 주는 시간이 오히려 직접 쓰는 시간보다 길어질 수 있다.

셋째 축은 판단의 외부성이다. 문서에 들어갈 판단이 외부 기준 — 명시된 요구사항, 정의된 인터페이스, 문서화된 규칙 — 에 의존할수록 AI에 넘기기 좋다. 외부 기준을 컨텍스트로 주면 AI가 그 기준에 맞춰 일관되게 판단한다. 반대로 판단이 작성자의 도메인 감각, 조직 내부 정치, 암묵 규범에 의존할수록 AI는 맞는 답을 쓸 수 없다. 이런 판단은 겉으로 드러난 기준에 없는 정보로 내려지는 것이어서 컨텍스트로 옮기는 것 자체가 불가능하다.

세 축이 모두 높은 산출물은 드물지만 존재한다. 템플릿이 명확하고, 입력이 다른 문서에 이미 있고, 판단이 외부 기준에 의존하는 경우. 이런 산출물은 AI에 넘기는 순간 내 시간이 실질적으로 회수된다. 세 축 중 한두 개만 높은 경우는 부분적으로만 넘길 수 있고, 세 축 모두 낮으면 넘기려는 시도 자체가 역효과를 냈다. 몇 번 실패한 뒤 나는 세 축을 모두 점검한 후에만 자동화 시도를 하는 습관을 들였다.

3. 넘긴 것, 어떻게 넘겼나

세 축이 모두 높은 산출물을 AI에 넘기는 것은 단순히 "이걸 생성해줘"라고 요청하는 것과 다르다. 몇 가지 구조적 작업이 필요했다.

첫 번째는 프롬프트 구조화였다. 템플릿을 그대로 복사해서 붙여넣고 "이걸 채워줘"라고 하면 품질이 일정하지 않았다. 그래서 프롬프트를 세 층으로 나누어 구성했다. 템플릿 층, 입력 정보 층, 작성 규칙 층이다. 템플릿 층은 결과물이 따라야 할 형식이다. 입력 정보 층은 채워 넣을 재료다. 작성 규칙 층은 "이런 표현은 피하라", "이 섹션은 이런 관점으로 써라" 같은 암묵적 규범을 명시적으로 적어둔 부분이다. 이 세 층을 구분해서 주자 결과의 일관성이 달라졌다. 특히 작성 규칙 층을 따로 뺀 것이 핵심이었다. 규칙을 템플릿 안에 녹여서 주면 지켜지지 않는 경우가 많은데, 별도 섹션으로 빼서 "이 규칙을 지켜서 템플릿을 채우라"고 명시적으로 요청하면 준수율이 높아진다.

두 번째는 입력 정보의 재활용 파이프라인이었다. 어떤 산출물은 다른 산출물의 파생이다. 요구사항 문서가 있으면 그걸 기반으로 설계 문서가 나오고, 설계 문서가 있으면 테스트 문서가 파생된다. 이 파생 관계를 파이프라인으로 구조화했다. 원천 문서 한 편이 업데이트되면 그로부터 파생되는 여러 문서를 순차적으로 AI에 생성시키는 흐름이다. 문서를 개별적으로 AI에 맡기는 것과, 파생 관계를 따라 연쇄적으로 맡기는 것은 결과 품질이 다르다. 후자에서는 문서 간 일관성이 자연스럽게 확보된다. 앞 문서가 뒤 문서의 컨텍스트가 되기 때문이다.

세 번째는 검증 루프였다. 이것이 가장 중요했다. AI가 생성한 결과를 그대로 쓴 적이 없다. 항상 검증 단계를 거쳤다. 흥미로운 것은 검증도 AI에 맡길 수 있다는 사실이었다. 생성 세션과 검증 세션을 분리하면, 검증 세션은 생성된 결과를 편향 없이 읽는다. 이것은 2편에서 말한 Writer/Reviewer 패턴의 문서 버전이다. 검증 세션에 "이 문서에서 작성 규칙이 지켜지지 않은 부분, 입력 정보와 어긋나는 부분, 내부 논리가 맞지 않는 부분을 찾으라"고 요청한다. 생성된 결과의 결함이 이 단계에서 많이 걸러진다. 그다음 내가 최종 검토를 한다. 세 단계가 되는 셈이다 — 생성, AI 검증, 사람 검증.

네 번째는 프롬프트 자체의 버전 관리였다. 결과 품질이 프로젝트마다 조금씩 달라지는 것이 관찰됐고, 그 원인이 프롬프트에 있다는 것도 알게 됐다. 그래서 프롬프트를 코드처럼 관리하기 시작했다. 파일로 저장하고, 버전을 붙이고, 바꿀 때마다 무엇을 왜 바꿨는지 메모를 남겼다. 어느 시점부터는 프롬프트 수정 이력이 일종의 내부 노트가 됐다. "이 표현을 빼니까 결과가 좋아졌다", "이 제약을 추가하니까 지나치게 뻣뻣해졌다" 같은 관찰이 쌓였다. 이건 프롬프트 엔지니어링이라는 이름을 붙이기도 거창한, 그냥 매뉴얼 튜닝이었다. 하지만 이 튜닝의 축적이 다른 프로젝트에 재사용되며 복리로 돌아왔다.

4. 넘길 수 없었던 것

자동화를 이야기하는 글은 대개 성공담으로 끝난다. 이 글은 그렇게 닫고 싶지 않다. 세 축이 모두 높은 산출물을 AI에 넘긴 뒤에도, 여전히 내 손에 남은 작업이 적지 않았기 때문이다.

첫째, 판단이 암묵 규범에 의존하는 작업이 남았다. 같은 문서라도 어떤 정보를 어느 수준까지 드러내고 어느 수준에서 멈출지, 어떤 표현은 쓰고 어떤 표현은 피할지 같은 결정이 있다. 이 결정은 규칙으로 적혀 있지 않다. 조직 안에서 오래 일하며 몸에 밴 감각이다. AI에 프롬프트로 전달하려 해도 잘 전달되지 않았다. 왜냐하면 나 자신도 이 감각을 완전히 언어화하지 못하기 때문이다. 언어화되지 않은 것은 프롬프트가 되지 못한다. 결국 이 부분은 생성된 초안을 내가 다시 읽으며 미세 조정하는 작업으로 남았다.

둘째, 이해관계자 간 조율이 필요한 작업이 남았다. 문서는 결국 누군가에게 전달된다. 전달받는 사람이 어떤 반응을 보일지 예상하며 쓰는 부분이 있다. 이 예상은 그 사람들을 겪어본 경험에서 나온다. AI에 "이 문서를 읽을 사람이 이런 특성을 가지고 있으니 그에 맞게 써라"고 주면 일반적인 레벨까지는 반영된다. 그러나 "이 사람은 이 주제에 예민하니 이 대목은 부드럽게 써야 한다" 같은 세밀한 조정은 내 몫이다. 자동화 이후에도 이 종류의 가다듬기는 오히려 더 중요해졌다. AI가 빠르게 써준 초안이 오히려 이런 조정의 필요를 더 선명하게 드러내기 때문이다.

셋째, 최종 책임을 지는 작업이 남았다. 그리고 이건 자동화되어서는 안 된다. 어떤 문서든 마지막에는 사람의 검토와 서명이 있다. 그 서명은 단순한 절차가 아니라 "이 문서에 쓰인 내용에 대해 내가 책임진다"는 선언이다. 이 선언의 책임성을 AI에 넘길 수 있다고 생각하면 자동화는 잘못된 방향으로 흐른다. AI가 쓴 초안을 내가 서명하는 것과, AI가 서명까지 하는 것은 전혀 다른 일이다. 후자로 넘어가는 순간 품질 관리의 마지막 보루가 사라진다.

이 세 가지가 남은 뒤에야 나는 AI 자동화가 대체가 아니라 재분배라는 것을 이해했다. 내 시간을 줄이는 도구가 아니라, 내 시간을 다른 종류의 일에 옮기는 도구라는 것.

5. 시간이 어디로 갔나

자동화 뒤에 아낀 시간을 어디에 썼는가를 돌아보면, 그 시간은 사라지지 않았다. 재배치됐다.

일부는 판단에 썼다. 자동화되기 전에는 문서 초안을 쓰느라 판단할 여유가 없었다. 초안이 자동으로 나오자 내가 초안을 읽고 "이 방향이 맞는가"를 묻는 시간이 생겼다. 그 시간은 원래 있어야 했던 시간이었는데 그동안 없었던 것이다.

일부는 사이드 프로젝트에 썼다. 이 시리즈 1편과 2편에서 다룬 Lemuel Mall이 그 시간에서 나왔다. AI가 내 실무 산출물을 일부 맡아준 덕에, 나는 Spring AI로 RAG를 붙이고 프론트에서 LLM UX를 고민할 시간을 확보했다. 아이러니하게도 AI를 실무에서 쓰는 경험이 사이드 프로젝트에서 AI를 다루는 시간을 만들어낸 셈이다.

일부는 이 시리즈를 쓰는 데 썼다. 이 글을 쓰고 있는 이 시간도 어떤 의미에서는 AI가 돌려준 시간의 일부다.

그리고 일부는 아이와 저녁을 먹는 데 썼다. 이게 제일 중요했을 수도 있다.

자동화의 목적은 시간 단축이 아니라 시간의 재배치다. 이 관점이 생기고 나서는 "얼마나 빨라졌는가"를 묻는 대신 "아낀 시간이 어디로 갔는가"를 묻는다. 후자가 훨씬 어려운 질문이고, 훨씬 정직한 질문이다.

다음 편은 시리즈의 마지막 편이다. 2편에서 예고했던 대로, 멀티 에이전트 파이프라인을 실제로 쓴 다른 프로젝트의 회고로 돌아간다. Lemuel Mall이 "안 쓴 이유"를 정리한 글이었다면, 마지막 글은 "썼을 때 어땠는지"의 이야기가 된다. 파이프라인에 대한 내 입장이 거기서 완결된다.