노코드 에이전트에서 노프롬프트 에이전트로 전환하게 된 과정

우리가 Reach를 시작했을 때, 계획은 간단했습니다. 우리는 이미 연락을 주고받던 수많은 소규모 비즈니스들, 즉 WhatsApp을 주로 사용하며 "기술 팀"이 없는 실제 중소기업(SMBs)들을 보유하고 있었습니다. 우리는 그들에게 고객과 대화하는 AI 에이전트를 제공하고, 지침(instructions)을 위한 깔끔한 스타터 템플릿을 건네준 뒤, 그들이 거기서부터 직접 수정할 수 있도록 했습니다.

우리의 모든 베팅은 이것이었습니다: 사람들에게 좋은 시작 프롬프트(starting prompt)와 템플릿을 제공하면, 그들이 알아서 잘 따라올 것이다.

지금 생각하면 웃음이 나올 정도로 우리는 완전히 틀렸습니다.

아무도 경고해주지 않는 부분

기술적 지식이 없는 사람들이 프롬프트 엔지니어링(prompt engineering)을 시도하는 것을 지켜보며 배우게 되는 사실이 하나 있습니다. 바로 지침을 작성하는 것이 어려운 부분이 아니라는 점입니다. 진짜 어려운 부분은 _작업을 추상적으로 생각하는 것_입니다.

우리는 사업주에게 대부분 잘 작동하는 에이전트를 건네주며 "무언가 잘못되면 지침을 그냥 조정하세요"라고 말하곤 했습니다. 쉬워 보이지만, 그렇지 않습니다. 자리에 앉아 대화가 흘러갈 수 있는 모든 방식을 상상하고, 기계가 따라야 할 규칙을 작성하는 것은 하나의 기술입니다. 그것은 기본적으로 하나의 직업입니다. 그리고 꽃집이나 부동산 사무실을 운영하는 것과는 완전히 다른 직업입니다.

그래서 그들은 막혔습니다. 지침 편집기(instructions editor)를 열었다가, 멍하니 바라보다가, 다시 닫아버리곤 했습니다. 우리가 설계한 반복 루프(iteration loop)가 그들에게 파트타임 프롬프트 엔지니어(prompt engineers)가 될 것을 요구했기 때문에, 에이전트는 평범한 수준에 머물렀습니다. 그들 중 몇몇은 그냥 조용히 떠나갔습니다.

그것은 뼈아픈 경험이었지만, 우리에게 실제 문제가 무엇인지 가르쳐 주었습니다.

"반복(iteration)"이 실제로 어떤 모습이었나

우리는 그들을 대신해 수동으로 반복 작업을 수행하기 시작했습니다. 그리고 이를 수십 번 반복하자 하나의 패턴이 눈에 띄었습니다.

피드백은 결코 추상적인 변화로 이어지지 않았습니다. 그것은 결코 우리로 하여금 "에이전트의 페르소나(persona)를 재고"하거나 "시스템 프롬프트(system prompt)를 재구성"하게 만드는 종류의 것이 아니었습니다. 그것은 아주 작고 구체적이며, 실제 대화와 연결된 것이었습니다:

• "모든 서비스를 제안하고 있는데, 솔직히 대부분의 고객은 이 세 가지만 신경 써요. 이것들을 밀어주세요."
• "웹사이트에서 영업시간을 가져왔는데 그냥 틀렸어요. 몇 달 전에 바꿨는데 말이죠."

이것들은 한 줄짜리 수정 사항들이었습니다. 주인은 실제 대화를 보는 순간 무엇이 잘못되었는지 정확히 알고 있었습니다. 다만 그 내용을 어떻게 프롬프트 (prompt) 수정으로 바꿀지 전혀 몰랐을 뿐이며, 솔직히 말해서 그럴 필요도 없어야 했습니다.

그때 깨달음이 왔습니다. 고객에게 필요한 것은 프롬프트 에디터 (prompt editor)가 아니라는 사실을 말입니다. 고객에게 필요한 것은 실제 대화를 가리키며 "이것 - 이걸 고쳐주세요"라고 말하는 것이었습니다.

"노프롬프트 (no-prompt)" 파이프라인

그래서 우리는 모든 것을 뒤집었습니다. 사람들에게 사용 사례 (use cases)를 상상하게 하고 (어려운 일), 지침을 작성하게 하는 (이 또한 어려운 일) 대신, 그들이 이미 잘하고 있는 것, 즉 실제로 일어난 대화에 반응하는 것을 중심으로 루프 (loop)를 구축했습니다.

흐름은 다음과 같습니다:

1. 주인은 에이전트와 고객 사이의 실제 기존 대화를 읽습니다. 가설은 없습니다. "만약 누군가 X라고 묻는다면" 같은 상황은 없습니다.
2. 그들은 대화에 평이한 언어로 코멘트를 남깁니다 - "이 서비스를 추천하지 마세요", "영업시간이 틀렸어요", "시작할 때 좀 더 따뜻하게 말하세요".
3. 그 코멘트는 처리 파이프라인 (processing pipeline)으로 들어갑니다. 단순히 메모리로 추가되는 것이 아닙니다. 기존 지침과 모순되지 않도록 가드레일 (guardrails)을 통과하고, 변경 사항이 기존 내용과 일관성을 유지하도록 지식 베이스 (knowledge base)에서 관련 참조를 가져오며, 충돌을 해결합니다.
4. 그런 다음 그에 따라 시스템 프롬프트 (system prompt)와 지식 베이스를 업데이트합니다.

모든 엔지니어링에 앞선 핵심 설계 결정은 다음과 같았습니다: 에이전트의 역할은 인간이 되는 것이 아닙니다. 에이전트의 역할은 반복적이고 잘 알려진 것들에 즉각적으로 답하고, 그 외의 모든 것은 실제 사람에게 넘기는 것입니다. 우리가 에이전트에게 인간의 일을 시키려는 시도를 멈추자, 피드백도 더 단순해졌습니다. 우리가 오직 지루하고 반복 가능한 부분만을 수정하고 있었기 때문입니다.

프롬프트 박스 제거하기

이 이야기의 기묘한 결말은 이렇습니다. 해당 파이프라인을 운영한 지 한 달 정도 지났을 때, 우리는 우리 자신의 제품을 바라보며 시스템 프롬프트 에디터(system prompt editor) — 우리가 플랫폼 전체를 구축했던 바로 그 핵심 요소 — 가 쓸모없는 짐이 되었다는 사실을 깨달았습니다. 아무도 그것을 필요로 하지 않았습니다. 모든 의미 있는 개선은 이제 누군가가 가공되지 않은 지침(raw instructions)을 편집하는 방식이 아니라, 대화 피드백을 통해 이루어지고 있었습니다.

그래서 우리는 UI에서 그것을 제거했습니다.

자신의 손으로 제품의 핵심이 단 한 달 만에 쓸모없어지는 것을 지켜보는 것은 기묘한 기분입니다. 하지만 그것이 바로 이 시대에 무언가를 만드는 경험의 전부이기도 합니다. 지면은 계속해서 움직이고 있으며, 때로는 여러분이 가장 자랑스러워했던 기능을 삭제하는 것이 최선의 선택일 수 있습니다. 모델과 그 주변의 워크플로우(workflow)가 그 기능을 불필요하게 만들었기 때문입니다.

만약 여러분이 비기술적 사용자(non-technical users)를 위한 에이전트 도구를 구축하고 있다면, 저의 솔직한 조언은 이렇습니다. 그들에게 프롬프트를 작성하는 법을 가르치려 하지 마세요. 그들이 이미 이해하고 있는 결과물(artifact) — 즉, 실제 대화 — 를 중심으로 루프(loop)를 구축하고, 번역은 시스템이 하도록 맡기십시오.

저희는 Kindway에서 이 기술을 구축하고 있습니다. 에이전트 플랫폼은 Reach이며, WhatsApp, Instagram 등을 사용하는 중소기업(SMBs)을 위한 AI 에이전트입니다. 댓글을 통해 기술적인 이야기를 나누는 것을 환영합니다.