결론부터 말하자면: AI에게 전부 맡기면 빠를 것이라고 생각했지만, 실제로 효과가 있었던 것은 「설계는 자신, 초안은 AI, 판단은 자신」이라는 역할 분담의 패턴을 정하는 것이었다. AI의 정밀도를 높이는 궁리보다, 이 경계선을 긋는 것이 더 효과가 컸다.

「AI 에이전트(AI Agent)에게 지시만 내리면, 개인 개발은 순식간에 끝난다」라고 진심으로 생각했던 시기가 있다. 실제로 AI 에이전트 에디터를 열고, 떠오르는 자동화 아이디어를 차례차례 던지고 있었다.

당시에는 「AI가 쓸 수 있다면, 지시만 내리면 손이 빈다」라는 이미지를 가지고 있어서, 여러 아이디어를 동시에 병행하여 실행하려고 했다. 실제로는 각각의 진척도를 확인하는 수고가 쌓여, 오히려 손이 비기는커녕 항상 어느 한쪽 화면을 신경 쓰고 있는 상태가 되어 있었다. 여러 태스크를 동시에 진행하고 있다고 생각했지만, 실제로는 주의력이 분산되어 있었을 뿐이었다는 것이 솔직한 심정이다.

하지만 몇 주간 계속해 보니, 생각만큼 빨라지지 않고 있다는 것을 깨달았다. 오히려 AI에게 지시를 내리는 시간, 출력을 다시 읽는 시간, 방향성이 어긋나 다시 설명하는 시간을 합치면, 스스로 처음부터 쓰는 편이 더 빠른 케이스조차 있었다.

원인은 단순했다. 「어디까지 AI에게 맡기고, 어디서부터 자신이 할 것인가」를 정하지 않고, 그 상황의 기분에 따라 통째로 맡기거나 세세하게 간섭하는 것을 반복했기 때문이다. 맡기는 방식이 매번 흔들리니 AI의 출력 품질도 안정되지 않는다. 기술력의 문제가 아니라, 분담 설계를 하지 않았을 뿐이었다.

지금은 「설계는 자신, 초안은 AI, 판단은 자신」이라는 패턴으로 안착했다. 구체적으로는 다음의 3단계 스텝을 매번 같은 순서로 돌린다.

• 무엇을 만들 것인지, 왜 필요한지를 자신의 언어로 1~2줄로 요약한다 (이 부분은 AI에게 쓰게 하지 않는다)
• 그 1~2줄을 바탕으로, AI에게 구현 초안과 분기안을 여러 개 내놓게 한다
• 초안을 자신이 읽고, 채택·기각·수정 지시를 내린다

이 사이클로 안착한 이후부터, 1건당 실제 작업 시간이 60~90분 정도로 안정되었다. 화려한 숫자는 아니지만, 「매번 같은 절차로 돌릴 수 있다」라는 재현성이 개인 개발을 1년 동안 지속하는 데 있어서 더 효과적이다.

처음에 시도한 것은 「이것을 자동화해 줘」라고 한 마디만 던지는 방식이었다. 편해 보였지만, AI가 전제를 마음대로 보완하여 구현하기 때문에 나온 코드가 자신의 이미지와 다른 경우가 많아, 결국 설명을 다시 해야 하는 상황이 되었다.

다음에 시도한 것은 반대로, 구현 절차를 한 줄씩 세세하게 지시하는 방식이다. 이것은 이것대로 지시를 쓰는 시간이 스스로 코드를 쓰는 시간보다 길어져 버려, AI를 사용하는 의미가 퇴색되었다. 세세하게 지시할수록 안전하다고 생각했는데, 실제로는 「지시를 쓰는」 새로운 작업이 늘어났을 뿐이었다는 것은 당시에는 예상하지 못했던 함정이다.

몇 번의 시행착오 끝에 최종적으로 도달한 것이 다음과 같은 「역할 분담 프롬프트(Prompt)」다. 두 가지 극단적인 방식 사이를 몇 번이나 오가며 겨우 안착할 곳을 찾은 형태다.

당신은 코드의 초안을 만드는 담당입니다.
다음 목적에 대해, 구현 방침을 2~3가지 패턴으로 제안해 주세요.
구현 자체는, 제가 방침을 선택한 후에 다시 의뢰하겠습니다.
...

이 템플릿의 포인트는, 「구현하게 만드는 것」이 아니라 「방침을 여러 개 내놓게 하는 것」을 AI의 역할로 고정한 점에 있다. 방침의 채택 여부는 반드시 자신이 결정한다. 이 경계선을 매번 무너뜨리지 않도록 한 뒤부터 AI와의 상호작용이 안정되었다.

실제로 이 템플릿을 사용한 예시를 하나 들겠다. 「외부 API에서 데이터를 가져와 시트에 추가하고 싶다」라는 목적에 대해 AI로부터 돌아온 방침은 다음 3가지 패턴이었다.

• 트리거마다 1번만 API를 호출하고, 취득 건수만큼만 추가한다 (심플함)
• 취득 누락을 방지하기 위해, 지난 취득 시각을 기록하고 차분(Difference)만 취득한다 (다소 복잡함)
• 실패 시의 재시도 로직까지 포함하여 일괄 구현한다 (가장 복잡함)

처음에는 3번을 선택하고 싶었지만, 「이번 주는 우선 돌아가는 것을 보고 싶다」라는 목적에 되돌아가 1번을 선택하여 구현하게 했다. 재시도 메커니즘은 실제로 실패를 경험한 후에 나중에 추가하면 된다는 판단이었다. 방침을 여러 개 나란히 보여줌으로써 이러한 우선순위 판단을 하기 쉬워졌다.

의뢰를 분할할 때 사용하고 있는 체크리스트를 그대로 텍스트로 남겨둔다. GAS(Google Apps Script)에 국한되지 않고, 어떤 언어의 태스크에서도 유용하게 사용할 수 있다.

[의뢰 분할 체크리스트]
1. 목적 (1~2줄, 자신의 언어로)
2. 완성 조건 (무엇이 되면 끝나는가)
...

이 체크리스트를 채운 뒤에 AI에게 던지도록 한 것만으로도, 재작업(Retake) 횟수가 눈에 띄게 줄었다.

처음에는 이 체크리스트를 매번 성실하게 모든 항목을 채웠지만, 익숙해지다 보니 「목적」과 「건드려서는 안 되는 범위」라는 두 항목만 명확하다면 나머지는 대화의 흐름 속에서 자연스럽게 전달되는 경우가 많다는 것을 알게 되었다. 다만 처음 다루는 테마일 때는 번거롭더라도 5개 항목을 모두 채우도록 하고 있다.

특히 「건드려서는 안 되는 범위」는 나중에 다시 돌아보면 가장 생략하기 쉬운 항목이면서도, 생략했을 때에 한해서 예상치 못한 재작성(Rewrite)이 일어난다는 경험칙이 있다. 번거롭더라도 명시해 둘 가치가 있는 항목이라고 느끼고 있다.

가장 시간을 낭비했던 시기는 AI의 첫 출력을 「단번에 정답」이라고 기대했던 때다. 출력이 예상과 다르면 「지시가 잘못된 것인지, AI의 이해가 얕은 것인지」를 구분하지 않고, 감각적으로 프롬프트(Prompt)를 다시 작성하곤 했다. 이래서는 같은 실수를 반복할 뿐이었다. 지금 돌이켜보면, 원인을 구분하지 않고 무턱대고 프롬프트를 바꾸던 시기가 체감상 가장 소모적이었던 기간이었다.

중간부터는 리뷰 관점을 미리 정해두기로 했다. 「목적에 부합하는가」, 「제약을 지키고 있는가」, 「불필요한 처리를 늘리지 않았는가」라는 세 가지만 매번 확인한다. 관점을 고정한 것만으로도 리뷰에 걸리는 시간과 지적의 질이 안정되었다.

이 세 가지 관점은 처음에는 내 머릿속에만 두었으나, 피곤할 때일수록 하나씩 빠뜨린다는 것을 깨닫고 의뢰 템플릿(Template) 끝에 매번 붙여넣도록 했다. 소소하지만, 눈에 보이는 형태로 만들어 두는 효과는 크다.

역할 분담의 형식을 정하고 나서 예상치 못했던 효과도 몇 가지 있었다. 하나는 AI와의 주고받은 로그(Log)를 다시 살펴볼 때, 무엇을 맡기고 무엇을 스스로 판단했는지를 나중에 추적하기 쉬워졌다는 점이다. 또 하나는 같은 형식을 매번 사용함으로써 AI에게 보내는 의뢰문 자체를 매번 처음부터 생각할 필요가 없어졌고, 템플릿에 목적과 제약만 채워 넣으면 되게 되었다는 점이다.

돌이켜보면 형식을 정하기 전에는 「어떻게 지시해야 좋은 출력이 나올까」만을 생각했지만, 형식을 정한 후에는 「무엇을 내가 하고 무엇을 맡길 것인가」를 생각하게 되었다. 질문을 던지는 방식 자체가 바뀌었다는 것이 가장 큰 변화였을지도 모른다.

이 변화를 깨닫고 나서부터는 AI 도구 자체의 성능 비교나 신기능을 쫓는 데 이전만큼 시간을 쓰지 않게 되었다. 도구의 성능보다 나 자신의 사용법 설계가 결과에 미치는 영향이 더 크다는 것을 실감하고 있기 때문이다.

AI에게 맡기면 개인 개발도 순식간에 끝날 것이라는 이미지를 가지고 있었지만, 실제로 효과가 있었던 것은 「AI 사용법이 능숙해지는 것」이 아니라 「나와 AI의 역할을 결정하는 것」이었다. 화려한 효율화 이야기가 아니라, 소소한 선 긋기에 관한 이야기다. 이 형식은 이번뿐만 아니라 이후의 52주 내내 반복해서 사용하게 될 것이다.

다음 회차에서는 이 형식을 사용하여 실제로 구축한 첫 번째 자동화 「GAS × Gemini API로 매일 아침 뉴스 요약 메일 받기」에 대해 쓰겠다.

note(이 이야기의 뒷이야기·소감은 이쪽): https://note.com/kar8

• Claude Code 공식 문서: https://docs.claude.com/en/docs/claude-code
• Google Apps Script 공식 문서: https://developers.google.com/apps-script