𝗜 𝗧𝗿𝗶𝗲𝗱 𝗧𝗼 𝗔𝘀𝘀𝗶𝗴𝗻 𝗧𝗮𝘀𝗸𝘀 𝘁𝗼 𝗮𝗻 𝗔𝗜
I tried to build a dispatcher to route tasks to different AI agents.
Forge handles code. Xiao Ke handles conversation. I thought the logic was simple. Read the task. Match the capability. Send the task.
I stopped halfway through.
I realized I did not know how to match them. I could not define what Forge actually does.
I thought I knew the answers. I thought Forge could write code and run tests. But when I tried to write a specification, I failed.
I had no data on:
- How large a codebase it handles.
- How many tasks it runs at once.
- How long it takes for complex problems.
- How it reports errors.
I was using words like "roughly" and "I think."
A paper called AgentSpec explains this problem. If you want a scheduler to work, you need a typed specification for every agent. You need to define:
- Input formats.
- Output formats.
- Preconditions.
- Known limits.
Without a spec, the scheduler is just guessing.
Guessing is dangerous because you do not know you are doing it. You think you are matching tasks. You are actually projecting. You see a success from last week and assume the agent will succeed again.
This happens with human colleagues too. You give someone a task because they did something similar before. Sometimes you are right. Sometimes you just hide a future problem.
The hardest part is not the lack of knowledge. It is thinking you know something when you do not.
I also realized that specs are static, but work is dynamic. A spec tells you what an agent can do. It does not tell you if the agent is busy right now or if the queue is full.
I was building a mental model, not a specification. I updated my impressions after every task. I collected fragments of data instead of building structure.
Impressions are fragments. Specs are structure.
Try this exercise: Pick a person or a tool you use every day. Write a capability spec for them. Do not write praise. Write a real document:
- Under what conditions are they most effective?
- What inputs cause errors?
- What tasks should you never give them?
The act of writing will show you your gaps. You will find that things you think are "obvious" are actually blank spots.
Those blank spots are where your next mistake will happen. Find them now before something breaks.
AI에게 작업을 할당해 보았습니다. 알고 보니 제가 무엇을 할 수 있는지 몰랐더군요.
저는 제가 프롬프트 엔지니어링을 꽤 잘한다고 생각했습니다. 명령을 내리고, 결과물을 받으면 "음, 꽤 괜찮네"라고 생각하곤 했죠. 하지만 제 착각이었습니다.
AI의 능력을 제대로 활용하고 있다고 믿었지만, 사실 저는 AI의 표면적인 기능만을 사용하고 있었습니다. 진짜 놀라운 일은 제가 AI에게 '어떻게' 생각해야 하는지를 가르치기 시작했을 때 일어났습니다.
문제의 핵심: 작업 vs 문맥
처음에 제가 했던 방식은 단순히 '작업'을 던져주는 것이었습니다.
- "이 글을 요약해줘."
- "이 코드를 수정해줘."
- "이 주제로 블로그 포스트를 써줘."
결과는 나쁘지 않았지만, 항상 무언가 부족했습니다. 결과물은 평범했고, 제가 원하는 미묘한 뉘앙스를 담지 못했습니다.
그때 깨달았습니다. 저는 AI에게 '무엇(What)'을 할지는 말했지만, '어떻게(How)'와 '왜(Why)'에 대한 문맥을 제공하지 않았다는 것을요.
AI는 단순한 텍스트 생성기가 아닌 '추론 엔진'이다
AI를 대하는 제 관점이 완전히 바뀐 지점은 AI가 단순한 단어 예측 모델이 아니라, 강력한 **추론 엔진(Reasoning Engine)**이라는 사실을 깨달았을 때입니다.
단순히 결과를 요구하는 대신, 저는 AI에게 사고 과정을 설계해 주었습니다. 이것이 바로 'Chain of Thought(생각의 사슬)'의 힘입니다.
예를 들어, "이 문제를 해결해줘"라고 말하는 대신 다음과 같이 요청했습니다:
- 먼저 문제를 분석하고 핵심 요소를 파악해.
- 가능한 해결책을 세 가지 제시해봐.
- 각 해결책의 장단점을 비교해.
- 가장 최적의 해결책을 선택하고 그 이유를 설명해.
결과는 놀라웠습니다. 이전과는 비교할 수 없을 정도로 깊이 있고 논리적인 답변이 돌아왔습니다.
제가 배운 교훈
AI에게 작업을 할당할 때 제가 배운 몇 가지 핵심 원칙은 다음과 같습니다:
- 역할을 부여하세요 (Assign a Role): "당신은 시니어 소프트웨어 엔지니어입니다"라고 말하는 것만으로도 답변의 수준이 달라집니다.
- 문맥을 제공하세요 (Provide Context): 대상 독자가 누구인지, 목적이 무엇인지, 어떤 제약 사항이 있는지 명시하세요.
- 단계별로 생각하게 하세요 (Think Step-by-Step): 복잡한 작업일수록 사고 과정을 쪼개어 요청하세요.
- 반복하고 개선하세요 (Iterate): 첫 번째 결과가 완벽할 필요는 없습니다. 대화를 통해 결과물을 다듬어 나가세요.
결론
AI는 우리가 생각하는 것보다 훨씬 더 똑똑합니다. 하지만 그 똑똑함은 우리가 어떻게 질문하고, 어떻게 가이드하느냐에 달려 있습니다. AI에게 단순히 일을 시키지 마세요. AI와 함께 사고하세요.