Anthropic의 한 고객사가 단 24시간 만에 단일 포지션에 2,740 개의 지원서를 받았습니다.
어떤 프롬프트도 직접 작성해서 그렇게 오래 유지될 수 없습니다.
그 이력서를 읽는 리크루터는 "백엔드 5년 경력, 스타트업 배경, Python 능숙"이라는 프롬프트로 시작합니다.
이틀이 지나 첫 번째 배치를 살펴보고 나면, 실제로는 0에서 1을 만들어 본 사람이 필요하다는 것을 깨닫습니다.
프롬프트는 이미 틀렸고, 아직 두 번째 100개의 지원서도 읽지 않았습니다.
가장 빠르게 출시하는 팀들은 더 이상 그런 방식으로 프롬프트를 작성하지 않습니다.
그들은 사용자가 실제로 결정하는 것을 지켜보고 배경에서 스스로 다시 작성하는 시스템을 구축했습니다.
사용자가 자신의 선호도가 바뀌었다는 것을 알아차릴 때쯤이면, 프롬프트는 이미 그에 맞춰 변화해 있습니다.
이 방식은 인간이 판단을 내리고 모델이 이를 도와주는 모든 곳에서 작동합니다.
채용, 지원 티켓 분류, 콘텐츠 검수, 코드 리뷰, 딜 평가에 이르기까지.
단계별로 구축하는 방법은 다음과 같습니다.
프롬프트는 설정(config)이 아니라, 견습생입니다
무엇보다 먼저 당신의 사고 전환이 필요합니다.
설정은 한 번 정해두면 잊어버리는 것입니다.
견습생은 당신이 일하는 모습을 지켜보고, 당신이 실제로 무엇을 중요하게 여기는지 파악한 후, 스스로 조정합니다.
당신의 프롬프트는 바로 이 두 번째 것이어야 합니다.
Nick Mayhew가 Anthropic 무대에서 선보인 시스템에서, 이 견습생은 일반 마크다운 파일입니다.
그들은 이것을 이상적인 지원자 프로필이라고 부릅니다.
가중치도, 규칙도, 순서도도 없습니다. 리크루터가 누구를 채용하려는지 설명하는 평범한 영어 문장일 뿐입니다.
리크루터가 지원자를 승인하거나 거절할 때마다 시스템이 이를 기록합니다.
"이 지원자는 Python 경험이 충분하지 않다"와 같은 모든 코멘트가 저장됩니다.
프로필에 대한 모든 수동 편집도 저장됩니다.
이 결정들의 집합이 프롬프트가 업데이트되는 기준으로 삼는 훈련 신호입니다.
한 번이 아니라 100번의 결정이 중요한 이유
첫 번째 반응은 모든 행동 후에 프롬프트를 업데이트하는 것입니다. 그러지 마세요.
한 번의 결정은 잡음(noise)에 불과합니다. 단 한 번의 거절은 사용자가 실제로 원하는 것이 무엇인지에 대해 거의 아무것도 알려주지 않습니다. 다음 중 어떤 이유일 수도 있습니다.
- 사용자가 피곤했거나 주의가 산만했습니다
- 입력 내용이 실제 선호도와는 무관한 방식으로 이상했습니다
- 실수로 클릭했습니다
- 명백한 케이스에 대해 빠르게 처리했습니다
- 의도적으로 시스템을 테스트하고 있었습니다
이러한 경우에 프롬프트를 다시 작성한다면, 허상을 쫓기 시작하는 것입니다.
100번의 결정은 신호(signal)입니다.
패턴이 보입니다: 사용자가 스타트업 경험이 없는 지원자를 계속해서 거절하고 있습니다.
이는 단순한 기분이 아니라 선호도입니다. 이제 업데이트할 때입니다.
Nick은 무대에서 이 점을 직접적으로 밝혔습니다.
매 클릭마다가 아니라, 100~200번의 결정마다 패턴을 발견하기 시작합니다.
비용 측면도 중요합니다.
모든 행동마다 고급 모델을 실행하면 점심시간 전에 예산이 바닥납니다.
배치(batch) 단위로 실행해야 시스템을 프로덕션에서 유지할 수 있습니다.
하나의 거대한 에이전트가 아닌, 두 개의 레이어로 시스템을 분할하세요
유혹은 평가와 학습, 업데이트를 모두 한 번에 수행하는 하나의 거대한 에이전트를 만드는 것입니다.
이는 확장이 불가능하고, 감당할 수 없는 토큰을 소모합니다.
실제로 작동하는 패턴은 매우 다른 역할을 가진 두 개의 레이어입니다.
하위 레이어는 평가자입니다. 저렴하고, 빠르며, 모든 입력에 대해 실행됩니다.
채용 사례에서 이것은 모든 이력서를 현재 프로필과 비교하여 점수를 매기는 Haiku입니다.
하루에 수천 건입니다. 좁은 작업: 입력을 받고, 현재 프롬프트를 받고, 구조화된 판단을 반환합니다.
상위 레이어는 견습생입니다. 더 느리고, 더 똑똑하며, 드물게 실행됩니다.
이는 인간이 내린 결정만을 관찰합니다.
각 배치마다 하나의 질문을 던집니다: 프롬프트가 여전히 사용자가 실제로 선택하고 있는 것과 일치합니까?
그렇지 않다면, 다시 작성합니다.
대부분의 팀은 이 분할을 건너뜁니다.
모든 요청마다 최첨단 모델을 핫 패스(hot path)에 배치하고, 비용이 폭발하며, 시스템은 결국 폐기됩니다.
평가를 학습으로부터 분리하는 것이 시스템을 프로덕션에서 살아있게 유지하는 비결입니다.
프롬프트를 규칙이 아닌 산문(prose) 형태로 작성하세요
이것이 대부분의 자기 개선 시스템이 조용히 죽어가는 지점입니다.
본능은 설정(config)을 작성하는 것입니다: 경력 연수에 30% 가중치, 회사 규모에 20%, 교육에 10%, 키워드 플래그 등.
이는 엄격해 보입니다. 하지만 모델이 실제로 업데이트할 수 없는 시스템을 만들어냅니다. 업데이트할 대상이 숫자 외에는 없기 때문입니다.
그리고 숫자는 리크루터가 왜 '아니오'라고 말했는지 포착하지 못합니다.
실제로 작동하는 형식은 마크다운으로 작성된 평범한 영어 문장입니다.
"우리는 제품을 0에서 1로 출시해본 사람을 원하며, 이상적으로는 직원 50명 미만의 스타트업에서의 경험이 있어야 합니다."
"강력한 엔지니어링 문화가 특정 기술 스택보다 더 중요합니다."
"위험 신호: 직원 수 1000명 이상인 회사에서만 일한 경험."
이것이 바로 견습생이 실제로 다시 쓸 수 있는 프롬프트입니다.
문장을 추가하고, 제거하고, 표현을 구체화할 수 있습니다.
가중치가 적용된 채점 기준표로는 그렇게 할 수 없습니다.
피드백 루프가 곧 제품 그 자체입니다
이 네 가지 요소가 자리 잡으면, 시스템은 스스로 작동합니다.
사용자가 결정을 내립니다. 평가자가 현재 프롬프트를 기준으로 점수를 매깁니다.
100번의 결정마다 견습생이 그 결과를 읽고 프롬프트를 다시 작성합니다.
다음 배치의 입력은 새로운 버전을 기준으로 평가됩니다.
사용자는 프롬프트에 대해 생각할 필요가 전혀 없습니다.
단지 인간만이 내릴 수 있는 결정을 계속 내리면 됩니다.
프롬프트는 그 아래에서 자동으로 업데이트됩니다.
이것이 대부분의 팀이 Claude 시스템을 출시할 때 놓치는 부분입니다.
그들은 프롬프트를 완성해야 할 인도물(deliverable)로 취급합니다.
가장 많은 것을 출시하는 팀은 프롬프트를 항상 학습하는 레이어로 취급합니다.
첫날부터 그렇게 구축하면, 단어를 조정하는 데 수 주를 낭비하지 않게 됩니다.
제품을 출시하는 데 시간을 쏟게 됩니다.
저를 팔로우하고 제 Telegram 채널을 구독하세요:
