나는 모델 파라미터(model parameters), 컨텍스트 제한(context limits), API 플래그(API flags)에 관한 질문이 나올 것이라 예상하며 Claude Certified Architect 시험을 치렀다. 하지만 결과는 달랐다. 이 시험은 단순한 상식을 거의 테스트하지 않는다. 대신 판단력을 테스트한다. 고장 난 에이전트와 네 가지 그럴듯한 해결책이 주어졌을 때, 어떤 것이 실제로 근본 원인을 해결하는가?

흥미로운 점은 이 모든 것이 아주 적은 수의 아이디어에 기반하고 있다는 것이었다. 몇 가지 동일한 규칙들이 계속해서 "정답"을 결정하고 있었으며, 이 규칙들은 실제 사용자가 에이전트를 사용하기 시작했을 때 에이전트가 버텨낼 수 있을지를 결정하는 바로 그 규칙들이기도 하다. 아래에는 내가 계속 마주쳤던 12가지 규칙과, 해결책처럼 보이지만 실제로는 그렇지 않은 4가지 함정을 정리했다.

이 내용은 공개된 시험 가이드를 바탕으로 작성한 나만의 학습 자료이다. 이는 내가 구축하는 방식을 반영할 뿐, Anthropic의 공식 입장은 아니다.

12가지 규칙

1. 프롬프트가 아닌 코드에서 결정론(determinism)을 강제하라
   만약 어떤 규칙이 매번 반드시 실행되어야 한다면, 그것은 프롬프트가 할 일이 아니다. 프롬프트는 모델이 대개 따르는 제안이다. "대개"라는 말은 보장이 아니다. 보장이 필요할 때는 훅(hook), 게이트(gate), 또는 허용 목록(allowlist)에 배치하라. 코드는 강제하고, 산문(prose)은 요청한다.

2. 근본 원인을 해결하는 가장 저렴한 해결책을 선택하라
   서브시스템(subsystem)을 구축하기 전에, 몇 분 만에 해결할 수 있는 레버들을 시도하라: 더 날카로운 도구 설명(tool description), 명시적인 수락 기준(acceptance criterion), 또는 설정(config) 변경 등이다. "X를 구축해야 한다"라고 느끼는 대부분의 순간은 저렴한 해결책을 먼저 테스트하고 나면 사라진다. 한 줄의 변경으로 해결되지 않을 때에만 분류기(classifier)를 찾아라.

3. 잘못된 도구 선택? 설명(descriptions)부터 시작하라
   에이전트가 계속해서 잘못된 도구를 선택한다면, 모델이 아니라 도구 설명이 원인인 경우가 거의 항상 그렇다. 도구 설명은 모델이 선택을 내릴 때 사용하는 주요 신호이다. 퓨샷 예시(few-shot examples)를 건드리기 전에, 해당 도구를 언제 사용해야 하고 언제 사용하지 말아야 하는지 정확하게 말하도록 설명을 다시 작성하라.

4. 과잉 엔지니어링(Over-engineering)은 거의 항상 오답이다
   범위를 좁히고 프롬프트를 개선하는 것이 엔지니어들이 예상하는 것보다 훨씬 더 자주 새로운 서브시스템을 만드는 것보다 효과적이다.

추가하는 모든 서브시스템은 디버깅(debug), 모니터링(monitor)하고 동기화(sync)해야 할 대상이 하나 더 늘어남을 의미합니다. 복잡성(Complexity)은 한 번 지불하고 끝나는 비용이 아니라, 영원히 지불해야 하는 비용입니다.

5. 더 큰 컨텍스트 윈도우(context window)가 어텐션(attention) 문제를 해결해주지는 않는다
   윈도우에 더 많은 내용을 채워 넣는다고 해서 모델이 중요한 것에 더 잘 집중(attention)하게 되는 것은 아닙니다. 오히려 그 반대인 경우가 많습니다. 분해(Decomposition)와 구조화(structure)가 어텐션을 해결합니다: 더 작은 작업, 더 깔끔한 입력, 명확한 경계가 필요합니다. "그냥 컨텍스트가 더 큰 모델을 사용하세요"라는 말은 해결책이 아닙니다.

6. 모델의 확신(confidence)과 어조(tone)는 신호가 아니다
   확신에 찬 어조의 답변이 반드시 정답인 것은 아닙니다. 모델 스스로 평가한 확신도는 보정(calibrated)이 잘 되어 있지 않으며, 어려운 사례일수록 모델은 자신이 틀렸을 때 오히려 가장 확신에 차 있는 경우가 많습니다. 모델이 주장하는 확신 정도를 기준으로 의사결정을 제한하지 마세요. 외부의 무언가로 검증하십시오.

7. 독립적인 인스턴스(instance)가 자기 검토(self-review)보다 낫다
   자신의 작업물을 스스로 채점하는 모델은 자신의 작업물에 편향(biased)됩니다. 출력을 생성했다는 기억이 없는 새로운 인스턴스는 훨씬 더 많은 오류를 잡아냅니다. 진정한 검토 단계가 필요하다면, 작성자에게 스스로 확인하라고 요청하지 말고 별도의 검토자(reviewer)를 실행하십시오.

8. 도구에 대한 최소 권한 원칙(Least privilege for tools)
   각 에이전트 역할에는 대략 4~5개 정도의, 꼭 필요한 도구만 부여하십시오. 이는 보안 문제일 뿐만 아니라 성능 문제이기도 합니다. 도구가 많아지면 선택 품질이 눈에 띄게 저하됩니다. 메뉴가 길어질수록 모델은 선택 능력이 떨어집니다. 거대한 도구 상자보다 적지만 날카로운 도구가 더 낫습니다.

9. 모든 곳에서 구조화(Structure)가 자유 형식 텍스트(free text)보다 낫다
   구조화된 오류, 구조화된 출력, 에이전트 간의 구조화된 인계(handoffs), 그리고 이 모든 과정에서의 명확한 출처(provenance)가 필요합니다. 컴포넌트 사이의 자유 형식 산문(free-text prose)은 정보가 조용히 부패하는 곳입니다. 에이전트 A가 에이전트 B에게 전달할 때는 문단이 아니라 스키마(schema)를 전달하십시오.

10. 오류를 억제하지 말고, 당황하지 마라
    일시적인 실패(transient failures)는 로컬에서 처리하십시오: 불안정한 네트워크 호출은 재시도(retry)하고, 백오프(back off)하고, 다음으로 넘어가십시오. 그 외의 모든 사항은 코디네이터(coordinator)가 결정할 수 있도록 컨텍스트(context)와 함께 에스컬레이션(escalate)하십시오.

피해야 할 두 가지 실패 모드(failure modes)는 오류를 조용히 삼켜버리는 것과, 복구 가능한 문제 때문에 전체 실행(run)을 중단시키는 것입니다.

11. 지연 시간(latency) 요구 사항에 맞춰 API를 선택하십시오
    Batch API는 비용이 약 절반 정도이지만 최대 24시간이 걸릴 수 있습니다. 이는 밤샘 작업(overnight job)에는 훌륭하지만, 사람이 기다리고 있는 작업에는 쓸모가 없습니다. 사람이 대기해야 하는 작업에는 동기식 호출(synchronous calls)을 선택하고, 나머지는 배치(batch)를 선택하십시오. 비용과 지연 시간은 의도적으로 선택해야 하는 트레이드오프(trade-off)입니다.

12. 재시도(retry)는 형식을 수정할 뿐, 누락된 데이터를 찾아내지는 못합니다
    호출을 재시도하면 잘못된 구조(malformed structure)를 바로잡을 수 있습니다. 하지만 소스에 없었던 정보를 마법처럼 불러올 수는 없습니다. 데이터가 없다면 다시 실행하는 것은 토큰(tokens)과 시간만 낭비할 뿐입니다. 재시도를 하기 전에 어떤 문제인지 파악하십시오.

네 가지 함정
이것들은 그 순간에는 똑똑해 보이지만 나중에 비용을 치르게 만드는 답변들입니다. 이들 각각은 유혹적이지만 잘못된 선택지로 나타납니다.

"프롬프트(prompt)에 필수 사항이라고 그냥 적으세요." 이는 결정론(determinism)이 정확히 필요할 때 나타나지만, 결정론은 프롬프트가 제공할 수 없는 유일한 것입니다. 규칙 1을 참조하십시오.
"퓨샷(few-shot) 예시를 추가하세요." 모호한 판단이 필요한 경우에는 진정으로 유용합니다. 하지만 엄격한 규칙의 경우에는 보장 없이 보장되는 듯한 착각만을 불러일으키므로 쓸모가 없습니다.
"분류기(classifier)를 구축하세요." 저렴한 레버(levers)들을 테스트하기도 전에 선택하게 되는 무거운 해결책입니다. 때로는 맞을 수도 있지만, 대개는 시기상조입니다. 규칙 2를 참조하십시오.
"모든 것을 수행하는 하나의 도구(tool)를 만드세요." 도구들을 병합하는 것은 단순화처럼 느껴집니다. 하지만 이는 모델이 하나의 과부하된 도구 안에서 의도(intent)를 추측해야 하므로 선택(selection) 과정을 더 악화시킵니다. 규칙 8을 참조하십시오.

세 가지 아이디어로 수렴됩니다
세부 사항을 걷어내면 12가지 규칙은 사실 세 가지로 요약됩니다:

항상 작동해야 하는 것은 요청(request)이 아니라 코드(code)에 포함되어야 합니다. 결정론(Determinism)은 문구(wording)의 결정이 아니라 아키텍처(architecture)의 결정입니다.

수정의 복잡성을 문제의 크기에 맞추십시오. 저렴한 레버(lever)를 먼저 사용하고, 서브시스템(subsystem)은 마지막에 고려하십시오.

산문(prose)이 아닌 구조(structure)를 전달하십시오. 컴포넌트(component) 사이에서는 문장(sentence)보다 스키마(schema)가 더 효과적입니다.

이 중 어느 것도 생소한 것이 아닙니다. 이는 데모(demo)는 잘 되지만 3개월 뒤에도 여전히 작동하고 있는 에이전트와 그렇지 않은 에이전트의 차이입니다. 시험이 이를 보상하는 이유는 프로덕션(production) 환경이 이를 보상하기 때문입니다.

Szymon Paluch. 저는 에이전트 시스템 전략(agentic system strategy) 분야에서 팀들과 협업하며, Claude Code와 에이전트들을 데모 단계에서 프로덕션 단계로 전환하는 일을 하고 있습니다.

AI 에이전트 구축을 위한 12가지 규칙 | Szymon Paluch

Claude Certified Architect 시험 준비를 위한 전체 치트 시트(cheat-sheet)입니다: 12가지 규칙, 7가지 반복되는 함정, 5개 도메인(domain)의 세부 사항, 그리고 사실 관계 표(facts table)를 포함합니다. 에이전트가 프로덕션에서 살아남을지를 결정하는 규칙들입니다.

favicon szymonpaluch.com