AI 에이전트가 코드를 짜고 PR을 올리는 시대에, 에이전트가 “잘 작동한다”는 것의 기준은 무엇일까. Google Chrome팀의 Addy Osmani가 최근 이 질문에 정면으로 답하는 글을 내놨다.
이미지 출처: Unsplash
그가 말하는 “스킬(Skill)”은 단순한 문서가 아니다. 프론트매터(frontmatter)가 달린 마크다운 파일로, 특정 상황이 감지될 때 에이전트의 컨텍스트에 자동으로 주입되는 구조화된 워크플로우다. 차이는 미묘하지만 중요하다. “테스트를 잘 작성해야 한다”고 설명하는 문서와, “먼저 실패하는 테스트를 작성하고, 실행해서 실패를 확인하고, 최소한의 코드를 구현하고, 성공을 검증한 뒤 리팩터링한다”고 단계를 명시하는 워크플로우는 전혀 다른 결과를 낳는다.
Osmani가 강조하는 핵심 원칙은 “prose 대신 process”다. 에이전트는 그럴듯하게 들리는 텍스트를 생성하는 데 능숙하지만, 실질적인 엔지니어링 작업은 구체적인 단계와 종료 조건이 명시되지 않으면 건너뛰는 경향이 있다. 에세이는 읽히지만, 워크플로우는 실행된다는 것이다.
시니어 엔지니어의 판단을 자동화하는 방법
스킬 설계에서 흥미로운 개념은 “합리화 방지 테이블(anti-rationalization table)”이다. 에이전트가 규칙을 우회하려 할 때 자주 쓰는 핑계를 미리 목록으로 만들어, 스킬 안에 반박을 함께 적어두는 방식이다.
이미지 출처: Unsplash
“이건 너무 단순해서 테스트가 필요 없어”라는 합리화가 나올 법한 자리에 “단순한 코드도 깨진다. 테스트는 30초면 쓴다”는 반박을 미리 명시해두는 식이다. 검증(Verification)을 선택사항이 아니라 워크플로우의 필수 종료 조건으로 만드는 것, 그리고 컨텍스트가 실제로 필요한 순간에만 관련 스킬을 로드하는 점진적 공개(Progressive Disclosure) 방식도 핵심 원칙으로 꼽힌다.
구조는 실제 개발 조직의 생애주기를 반영한다. 정의(Define) → 계획(Plan) → 빌드(Build) → 검증(Verify) → 리뷰(Review) → 출시(Ship)의 여섯 단계다. 에이전트 코딩 도구가 이미 여러 종류 나와 있고, 각각 다른 방식으로 컨텍스트를 주입한다. Osmani의 접근은 특정 도구에 종속되지 않고, 마크다운 명세 자체를 엔지니어링 표준으로 삼는 방향이다.
결국 이 글이 던지는 질문은 간단하다. 시니어 엔지니어의 판단 — 테스트를 먼저 쓰고, 검증하고, 범위를 지키는 습관 — 을 어떻게 에이전트의 기본값으로 만들 것인가. 에이전트가 더 강력해질수록 이 질문의 무게도 함께 커진다.
출처