AI는 지니가 아닙니다. 함수(Function)처럼 다루세요.

대부분의 사람들은 검색창을 사용하는 방식대로 AI를 사용합니다. 질문을 입력하고, 답변을 읽고, 다음으로 넘어가는 식이죠. 이는 일회성 궁금증을 해결하는 데는 효과적입니다. 하지만 매주 반복하는 업무에는 적합하지 않습니다. 매번 맥락을 다시 설명해야 하며, 신뢰할 수 있는 결과물을 쌓아갈 수 없기 때문입니다.

소형 비서(Small assistant)는 다릅니다. 이는 고정된 입력(Input)과 고정된 출력(Output) 형태를 가지고, 한 번 설정하면 작동하는 하나의 좁은 작업(Narrow task)입니다. 실행하고, 확인하고, 개선합니다. 몇 번의 반복 과정을 거치면, 그것은 단순한 데모를 넘어 실제로 큰 비중을 차지하는 도구가 됩니다.

프레임워크의 홍수 속에서 빠지지 않고 소형 비서를 구축하는 방법은 다음과 같습니다.

좁게 시작하세요: 하나의 작업, 하나의 입력, 하나의 출력

"내 업무를 위한 비서"를 만들려고 하지 마세요. 엉망인 회의록을 세 개의 불렛 포인트(Bullet points)로 변환하는 도구를 만드세요. 다음과 같은 특성을 가진 작업을 선택하십시오:

• 반복적인 것 (매주 또는 매일 수행하는 작업)
• 지루한 것 (수동 작업이 사라져도 아무도 아쉬워하지 않을 작업)
• 검증 가능한 것 (출력을 보고 틀렸는지 여부를 즉시 알 수 있는 작업)

마지막 항목이 가장 중요합니다. 10초 안에 좋은 출력과 나쁜 출력을 구분할 수 없다면, 그 비서를 신뢰할 수 없으며 개선할 수도 없습니다.

좋은 시작 작업 예시: 답장 이메일 초안 작성, 문서 요약, 난잡한 데이터 정규화(Normalizing), 텍스트에서 필드 추출.

예시: 함수로서의 이메일 초안 작성

프롬프트(Prompt)를 함수 시그니처(Function signature)라고 생각하세요. 입력이 들어가면 구조화된 초안이 나옵니다.

def draft_reply(incoming_email: str, tone: str = "friendly, brief") -> str:
    prompt = f"""
    당신은 나를 대신하여 답장을 작성하고 있습니다. 사실을 지어내지 마세요.
...

두 줄의 문장이 핵심적인 역할을 합니다: "사실을 지어내지 마세요"와 [PLACEHOLDER] 규칙입니다. 이 두 가지가 결합되어, 자신만만한 환각(Hallucination)을 사용자가 채워 넣을 수 있는 눈에 보이는 공백으로 바꿔줍니다. 목표는 오류를 조용히 숨기는 것이 아니라, 명확하게 드러나게 만드는 것입니다.

예시: 실제로 신뢰할 수 있는 요약

요약의 실패 유형은 원문에 등장하지 않았는데도 그럴듯하게 들리는 문장을 생성하는 것입니다. 증거를 강제하면 이러한 문제는 사라집니다.

아래 문서를 5개의 불렛 포인트로 요약하세요.
각 불렛 포인트마다, 해당 내용의 근거가 되는 정확한 문장을 인용하세요.
만약 어떤 주장에 뒷받침하는 인용구가 없다면, 해당 내용을 삭제하세요.

이제 확인하는 데 몇 초밖에 걸리지 않습니다. 인용구를 훑어보고, 그것이 텍스트에 존재하는지 확인하면 됩니다. 당신은 모델의 판단에 의존하는 것이 아니라, 모델의 복사 능력에만 의존하는 것이며, 이는 훨씬 더 신뢰할 수 있습니다.

예시: 안전망을 갖춘 데이터 정제 (data cleanup)

일관되지 않은 데이터(국가명, 직함, 날짜 형식)를 정제하는 것은 매우 적합한 작업이지만, 동시에 조용한 오류가 숨어들기 쉬운 곳이기도 합니다. 모델이 데이터를 제자리에서 직접 다시 쓰게 하지 마세요. 먼저 검토할 수 있도록 매핑 (mapping) 결과를 출력하게 하세요.

입력 값: ["USA", "u.s.a", "United States", "Amrica"]
JSON 반환: {original: normalized}.
확신이 없는 값은 병합하지 마세요. "REVIEW"로 표시하세요.

원본 컬럼을 유지한 채 코드로 매핑을 적용하고, "REVIEW"로 표시된 항목은 눈으로 직접 확인합니다. 모델은 제안하고, 당신의 코드가 결정합니다.

출력물 검증 (모두가 건너뛰는 단계)

어시스턴트 (assistant)에 의존하기 전에, 아주 작은 골든 세트 (golden set)를 만드세요. 당신이 실제로 원했던 출력값과 쌍을 이룬 10~20개의 실제 입력값들입니다. 프롬프트를 변경할 때마다 이를 다시 실행하세요. 이것이 "더 나아진 것 같다"라는 느낌과 "실제로 개선되었다"라는 사실의 차이를 만듭니다.

대부분의 문제를 잡아낼 수 있는 저렴한 확인 방법들:

• 코드 내 단언문 (Assertions): 유효한 JSON인가? 필수 필드가 존재하는가? 남겨진 플레이스홀더 (placeholder)는 없는가?
• 스팟 체크 (Spot-check) 습관: "작동한다"라고 판단한 후에도 다섯 개 중 하나는 읽어보기
• 거절 경로 (Refusal path): 모델이 불확실할 때는 추측하지 말고 그렇다고 말해야 함

실제 단계가 있을 때만 에이전트 (agent)를 추가하세요

에이전트 (agent)는 단순히 한 단계 이상의 작업을 수행하고 한두 개의 도구 (tool)를 호출하는 어시스턴트일 뿐입니다. 작업이 진정으로 단계(가져오기, 결정하기, 실행하기)를 가지고 있을 때 에이전트를 활용하세요. 받은 편지함을 읽고, 각 메시지를 분류하며, 쉬운 메시지에 대한 답장 초안을 작성하는 분류 도우미 (triage helper)는 합리적인 첫 번째 에이전트가 될 수 있습니다.

AI가 아닌 부분은 결정론적 (deterministic)으로 유지하세요. 모델은 분류와 초안 작성을 하게 하고, 일반적인 코드가 가져오기, 보내기, 루프 (looping)를 수행하게 하세요. 모델에게 넘기는 모든 단계는 편향되거나 벗어날 수 있는 (drift) 단계입니다.

이 방식이 취약한 부분

한계를 솔직하게 인정하십시오.

• 저렴한 검증 (cheap verification)이 불가능한 작업(전략, 판단, 법적 또는 금융적 이해관계가 걸린 모든 것)은 적합하지 않습니다. 결과물을 확인하는 데 직접 일을 하는 것만큼 시간이 걸린다면, 아무것도 절약한 것이 아닙니다.
• 실제 입력값이 테스트 세트(test set)보다 기이해지면 출력값은 드리프트 (drift)합니다. 골든 세트 (golden set)는 이를 늦춰줄 뿐, 멈추게 하지는 못합니다.
• 규모가 커지면 실수가 증폭됩니다. 직접 읽어보는 10개의 초안에 대해서는 낮은 오류율이 괜찮을지 몰라도, 읽지 않고 보내는 1,000개의 초안에 대해서는 재앙입니다.

이 중 어느 것도 이 접근 방식 자체를 무효화하지는 않습니다. 다만 검증은 선택적인 장식이 아니라는 뜻입니다. 검증은 하중을 견디는 벽 (load-bearing wall)입니다.

반복하기: 성공적인 실행을 사양 (spec)으로 승격시키기

실행 결과가 훌륭하게 나왔을 때, 단순히 즐기기만 하지 마세요. 잘 작동했던 부분을 규칙이나 예시로서 프롬프트 (prompt)에 다시 복사해 넣으세요. 몇 주가 지나면 프롬프트는 해당 작업이 어떻게 수행되어야 하는지에 대한 작은 사양 (spec)으로 변하며, 어시스턴트는 가장 좋은 의미에서 지루해집니다. 즉, 예측 가능해집니다.

이번 주에 작업 하나를 선택하십시오. 좁은 범위의 버전을 출시하고, 검증하며, 그것이 다음 기능을 얻을 자격을 갖추게 하세요.

저는 AI를 채팅 장난감에서 작업 도구로 바꾸는 것에 대해 글을 씁니다. 저는 실제 실습을 통해 Claude를 배우는 게임 기반 아카데미인 AGINE Academy를 구축하는 것을 돕고 있습니다. 이는 독립적인 제품이며 Anthropic과 관련이 없습니다.