파일명 하나로는 일을 다시 못 시킨다
오전 8시 41분, 저는 내부 원문 자료라는 파일명 하나만 붙잡고 15분째 문서의 몸통을 상상하고 있었습니다. 내용도 출처도 비어 있으니 이 파일이 강의 메모였는지, 코드 실험 기록이었는지 저는 단정할 수 없습니다. 그런데 이 빈칸이 묘하게 익숙했습니다. 결과물 이름은 남았는데, 다음 사람이 같은 일을 다시 해낼 방법은 사라진 상태였기 때문입니다.
제가 요즘 “에이전틱 코드”를 볼 때 제일 먼저 묻는 것도 바로 그 질문입니다. 이건 혼자 잘 돌아가는 멋진 자동화였는가, 아니면 만든 사람만 다시 살릴 수 있는 일회성 요령이었는가.
다들 더 똑똑한 비서를 찾지만 순서를 안 남긴다
다들 에이전틱 코드를 말할 때, 모델이 얼마나 길게 생각하는지부터 봅니다. 도구를 몇 개 붙였는지, 어디까지 자동으로 실행하는지, 얼마나 사람처럼 판단하는지에 시선이 먼저 갑니다. 저도 한동안 거기서 헤맸습니다.
그런데 비개발자 직장인의 실제 업무는 조금 다르게 무너집니다. 일을 잘하는 신입에게 “알아서 정리해줘”라고 던졌는데, 오후에 받아보니 형식은 맞고 맥락은 틀린 문서가 오는 장면과 비슷합니다. 사람이 모자라서가 아니라, 순서와 중단 조건이 없어서 생기는 실패죠.
지난주 저는 번역 초안 하나를 요약본, 카드 문장, 메일용 문장으로 나누는 작업을 하다가 같은 지시를 네 번 다시 썼습니다. 문장 품질은 나쁘지 않았는데, 어느 버전이 통과본인지 제가 직접 다시 판별해야 했습니다. 저는 그때 더 똑똑한 답보다, 덜 헷갈리는 절차가 먼저였다는 걸 다시 배웠습니다.
에이전틱 코드는 자율성보다 재시도 가능성이 먼저다
제 주장은 분명합니다. 에이전틱 코드의 출발점은 “AI가 얼마나 많이 대신하느냐”가 아니라 “사람이 하던 판단 순서를 밖으로 꺼내 다음에도 다시 시킬 수 있느냐”에 있어야 합니다. 이 말에는 동의하지 않는 분도 있을 겁니다. 그래도 저는 시간을 아끼는 쪽에서 여러 번 이겼고, 반대로 감으로 밀어붙였다가 여러 번 졌습니다.
지금 공개된 근거가 비어 있으니 내부 원문 자료의 실제 내용을 근거로 기술을 평가할 수는 없습니다. 대신 제가 직접 써먹고 있는 기준은 남길 수 있습니다. 지난 6월 3일, 저는 1,200자짜리 초안을 카드 9장용 문장과 짧은 뉴스레터 문장으로 재가공하는 루틴을 손봤습니다. 예전 방식에서는 “톤만 조금 낮춰서 다시”, “근거를 하나 더 넣어서 다시”, “첫 문장을 덜 과하게 다시” 같은 말을 다섯 번쯤 이어 붙였습니다. 그날 최종 저장까지 52분이 걸렸습니다.
다음 날에는 순서를 바꿨습니다. 먼저 입력 파일 하나를 고정했고, 금지 표현을 적었고, 통과 기준을 세 줄로 줄였습니다. 그리고 제일 중요하게, 어디서 멈출지를 먼저 써놨습니다. 결과가 기대만큼 좋지 않으면 끝까지 자동으로 밀지 않고 초안 단계에서 끊도록요. 그렇게 바꾸니 같은 종류의 작업이 31분 만에 끝났습니다. 더 인상적이었던 건 이틀 뒤였습니다. 제가 다시 열어도 왜 그렇게 처리했는지 금방 복구됐습니다. 기억에 기대는 작업이 아니라, 순서에 기대는 작업으로 바뀌었기 때문입니다.
제가 자주 쓰는 구분은 아래 표 하나로 정리됩니다.
| 남는 작업 방식 | 금방 무너지는 작업 방식 |
|---|---|
| 입력 파일이 하나로 고정돼 있다 | “아까 보던 최신 파일”에 기대고 있다 |
| 통과 기준이 2~3줄로 적혀 있다 | “좋아 보이면 통과”로 끝난다 |
| 실패하면 멈출 지점이 있다 | 어색해도 끝까지 생성한다 |
| 다음 사람이 같은 순서로 재시도할 수 있다 | 만든 사람만 복구할 수 있다 |
5월 마지막 주에 저는 이 기준을 어겼다가 더 크게 틀렸습니다. 카드 문장 9개와 팟캐스트용 원고를 한 번에 뽑아보겠다고 욕심을 냈는데, 카드 4장부터 근거가 흐려졌고 마지막 원고에서는 금지해둔 표현이 다시 살아났습니다. 겉으로 보면 그럴듯했지만, 막상 발행 직전에는 사람이 처음부터 다시 손봐야 했습니다. 그 실패 이후 저는 확신하게 됐습니다. 에이전틱 코드는 자율성의 크기로 자랑할 일이 아니라, 기억 의존을 얼마나 줄였는지로 평가해야 합니다.
복붙용으로 한 줄만 남기면 이렇습니다.
> “알아서 해줘” 대신 “입력, 판단 기준, 중단 조건부터 적는다.”
감으로 버티는 일이 아직 더 빠른 날도 있다
물론 이 기준이 모든 일에 통하지는 않습니다. 처음 배우는 언어로 짧은 실험을 할 때, 아직 내가 뭘 원하는지도 모를 때, 혹은 문장의 결을 여러 번 흔들어봐야 할 때는 절차를 너무 일찍 고정하는 편이 오히려 손해입니다. 저도 4월에 소개 페이지 문구를 다듬으면서 체크리스트를 여덟 줄이나 써놨다가, 결과가 지나치게 무난해져서 전부 버린 적이 있습니다.
보안이 엄격한 팀도 예외입니다. 입력과 출력이 어디에 남는지 불분명하면, 잘 만든 자동화보다 조심스러운 수동 작업이 맞습니다. 그리고 다시 말하지만, 지금 제 손에 있는 건 내부 원문 자료라는 제목뿐입니다. 실제 본문을 보지 못한 상태에서 그 파일이 어떤 입장을 담았는지까지 대신 말하는 건 무책임합니다. 저는 빈칸은 빈칸으로 남겨두는 편을 택하겠습니다.
오늘은 세 줄만 남기고, 다음 편에서 실패 로그를 보자
오늘 바로 할 일은 하나면 충분합니다. 이번 주에 두 번 이상 반복한 업무 하나만 고르세요. 번역 수정이든, 보고서 요약이든, 카드 문장 정리든 상관없습니다. 그리고 아래 세 줄만 남기면 됩니다.
① 입력은 무엇인가 ② 통과 기준은 무엇인가 ③ 어디서 멈출 것인가
저는 이 세 줄을 적기 전보다 적은 뒤에 훨씬 덜 지칩니다. 자동화가 미래 기술처럼 느껴질 때도 있지만, 실제로 사람을 살리는 건 이런 작은 문장들입니다. 오늘의 다음 단계는, 방금 고른 반복 업무 하나에 이 세 줄을 붙여보는 일입니다. 다음 편에서는 이 세 줄이 어떻게 폴더 이름, 파일 규칙, 검수 로그로 이어져야 진짜로 다시 쓸 수 있는 시스템이 되는지 이어서 보겠습니다.
핵심 정리
- 오전 8시 41분, 저는 내부 원문 자료라는 파일명 하나만 붙잡고 15분째 문서의 몸통을 상상하고 있었습니다.
- 제가 요즘 “에이전틱 코드”를 볼 때 제일 먼저 묻는 것도 바로 그 질문입니다.
- 다들 에이전틱 코드를 말할 때, 모델이 얼마나 길게 생각하는지부터 봅니다.
→ 영어판 보기
