비개발자가 업무 자동화를 AI 에이전트에게 맡길 때의 설계: 입력, 진행 과정, 결과 수령 방식 결정하기

‘이 업무를 자동화해 줘’라고 AI 에이전트에게 부탁할 때, 비개발자인 제가 결정하는 것은 구현 방법이 아닙니다. 결정하는 것은 **무엇이 들어오는지(입력), 사람은 무엇을 하고 있는지(과정), 그리고 결과를 어디서 받을지(출력)**의 세 가지입니다.

다루는 소재는 저희 회사(株式会社AI Orchestra)에서 매일 돌아가는 시스템입니다. 회사 홈페이지 문의 양식에 문의가 도착하면, AI가 상대 회사의 기본 정보를 리서치하고, 문의 내용으로부터 니즈를 추측하여 분석 메일을 보내고, Notion 데이터베이스에 저장합니다. 비개발자인 제가 직접 만든 것이며, 영상에서는 Codex(모델은 GPT-6 Astra)에게 요청하는 형태로 제작 과정을 실연했습니다.

이 글은 제작 과정의 매뉴얼이 아니라, 부탁하기 전에 결정해 두어야 할 것들을 설계 이야기로 정리한 읽을거리입니다. 화면 조작까지 포함하여 영상으로 보고 싶은 분은 여기를 참고해 주세요(5분 39초).

소재의 전체 개요

사람이 하던 때는 문의가 도착할 때마다 회사명으로 검색하고, 홈페이지나 IR 자료를 읽어본 후 회신이나 상담 준비를 했습니다. 지금은 그 사전 준비가 끝난 상태로 메일이 도착합니다.

설계로서 결정한 것은 다음 세 가지뿐입니다.

• 사람이 하던 일을 적어내기 (Write out what people do)
• 에이전트에게 전달할 컨텍스트를 정하기 (Determine the context to pass to the agent)
• 정보의 수령 방식을 플로우(Flow)와 스톡(Stock)으로 결정하기 (Decide how to receive information, using flow and stock)

1. 사람이 하던 일을 적어내기: 사양서는 ‘현재 자신의 절차’

자동화를 부탁할 때, 가장 먼저 작성하는 것은 'AI가 해줬으면 하는 것'이 아니라, 지금 사람이 하고 있는 일입니다.

제 경우의 상황은 이랬습니다. 문의가 도착하면 회사명으로 검색하여 직원 수나 매출액 같은 회사 규모를 조사합니다. 홈페이지와 IR 자료를 읽습니다. 문의에 적힌 내용으로부터 니즈를 추측합니다. 그 위에 제안 자료를 만들고, 첫 상담을 진행합니다.

요약하자면, '회사 기본 정보 리서치'와 '니즈 추측'의 두 가지입니다. 이 2줄이 그대로 사양서가 됩니다.

적어내기 과정에서 빠지는 것: 무의식적인 판단

직접 움직여 보니, 사람의 절차에는 적어내는 과정에 나타나지 않는 판단들이 섞여 있다는 것을 알게 되었습니다.

첫 번째는 같은 회사명이라도 다른 회사를 제외하는 판단입니다. 사람은 검색 결과를 봤을 때, 사업 내용이나 소재지를 보고 '이건 다른 회사다'라고 무의식적으로 걸러냅니다. AI에게 회사명만 전달하면, 이 부분이 빠져서 다른 회사의 정보로 리포트가 채워지는 경우가 있었습니다. 지금은 본 조사 전에 메일 주소의 도메인이나, 문의 본문에 적힌 사업 내용 같은 단서를 이용해 후보 회사를 대조하는 단계를 넣었습니다. 단서가 모이지 않을 때는 회사를 임의로 정하지 않고 '불명'이라고 작성하게 합니다.

또 하나는 모르는 경우 공란으로 두는 판단입니다. 사람은 찾지 못한 숫자는 적지 않습니다. AI에게는, 찾지 못하면 '비공개', '불명'이라고 적고, 추측은 추측임을 명확히 밝힌다는 것을 말로 전달할 필요가 있었습니다.

‘사람이 하던 일을 적어내기’는 한 번에 끝나는 작업이 아니었습니다. 나온 결과를 보고, '내가 여기서 무엇을 판단했었나'를 추가하는 과정이기도 했습니다.

2. 전달할 컨텍스트 결정하기: 진입점・절차・출구

다음으로 생각하는 것은, 어디까지 전달해야 원하는 대로 움직여 줄 수 있느냐입니다. 영상에서 Codex에게 전달한 것은 세 가지였습니다.

반대로, 요청문에 넣지 않은 것도 있습니다. 어떤 서비스를 어떻게 연결할지, 어떤 코드를 사용할지 같은 구현 지정입니다. 영상의 요청문에 적은 것은 진입점・절차・출구 세 가지뿐이었습니다.

또 하나 결정한 것이 있습니다. Codex에게 부탁할 때는 반드시 프론티어 모델(지금이라면 GPT-6 Astra)을 사용합니다. 저렴한 모델로 시험해 보면, AI의 현재 한계치를 알 수 없습니다. '이 정도는 할 수 있다'라는 감각은 설계의 전제가 됩니다.

3. 받을 방식을 플로우와 스톡으로 결정하기

마지막으로 정하는 것이 출구입니다. 여기서는 '메일로 통지해 달라'에서 끝내지 않고, 정보의 성질에 따라 두 가지로 나누었습니다.

이 분류 방식을 정하자 세부적인 설계도 거기서 결정되었습니다.

플로우는 읽는 사람마다 분리한다. 알림 메일은 그대로 회신하면 문의한 사람에게 전달되도록 했습니다. 여기에 분석 내용까지 담으면, 답장 인용구로 상대방에게 노출될 수 있습니다. 분석 메일은 사내에서만 보는 별도의 메일을 사용했습니다.

스톡은 AI가 작성하는 열과 사람이 작성하는 열을 분리한다. 회사 규모나 매출액은 AI가 채우는 열입니다. 대응 상태(미처리・회신 완료・상담 진행 중 등)는 사람이 업데이트하는 열이며, 나중에 조사를 다시 하더라도 AI가 덮어쓰지 않도록 했습니다.

실패도 플로우와 스톡으로 받는다. 리서치가 실패하면 그 시점에 실패 알림 메일이 도착합니다. 재시도해도 완료되지 않은 문의는 문의 정보만 담은 페이지를 Notion에 만듭니다. 이는 잘 안 되었을 때 알아차릴 수 있는 것과, 목록에서 빠지지 않게 하는 두 가지 측면을 모두 확보하기 위함입니다.

부탁하기 전에, 자신에게 물어볼 것

영상에서는 이 3단계를 '사내 업무 효율화의 공식'이라고 부릅니다. 문의 대응에만 국한되지 않고, 다른 업무를 맡길 때도 같은 순서로 질문을 던질 수 있습니다.

• 지금 사람은 무엇을 하고 있는가. 그 속에서 무의식적으로 하는 판단은 무엇인가?
• 진입점(어떤 데이터가 어디서 들어오는가)・절차・출구 중, 아직 말로 표현하지 못한 것은 무엇인가?
• 결과 중, 바로 알아차리고 싶은 것(플로우)은 무엇이고, 쌓아두고 되돌아보고 싶은 것(스톡)은 무엇인가?

'미야치🧑💻식 3단계'라는 이름으로 소개하는 것입니다. 도구 사용법이라기보다는 생각할 때의 습관에 가깝다고 생각합니다.

요약

• 사양서는 '지금 사람이 하고 있는 것'. 작성 시작부터 빠지는 무의식적인 판단은 결과를 보면서 추가한다.
• 전달할 컨텍스트는 진입점(URL)・절차(사람의 워크플로우)・출구(아웃풋 형태)
• 수령 방식은 플로우(메일)와 스톡(Notion)으로 나눈다. 읽는 사람, 쓰는 사람, 실패 처리도 이 분류에서 결정된다.

Codex에 요청문을 보내는 곳과 도착한 분석 메일・Notion 데이터베이스 화면은 영상에서 보여드렸습니다. 화면 조작까지 영상으로 보고 싶은 분은 여기를 참고해 주세요.

Discussion