오류에서 초능력으로: AI 보조 개발을 가능하게 하는 8가지 에이전트 기술

GenAI 개발의 오류 (Fallacies of GenAI Development)에서는 AI 보조 개발을 망가뜨리는 8가지 가정을 명시했습니다. 이에 대한 해결책은 엔지니어가 반드시 이해하고 적용해야 하는 '인간의 지식'으로 틀이 잡혀 있었습니다.

하지만 해결책이 반드시 엔지니어의 머릿속에만 머물러 있을 필요는 없습니다. 에이전트의 워크플로 (workflow) 안에 존재할 수 있습니다.

Superpowers와 같은 프로젝트는 에이전트가 구조화된 방법론을 따를 수 있음을 증명했습니다. 즉, 코딩 전 브레인스토밍을 하고, 구현 전 테스트를 작성하며, 성공을 선언하기 전 사양(spec)에 따라 검토하는 방식입니다. 이러한 기술들은 제안 사항이 아니라 필수적인 워크플로 (workflow)입니다. 에이전트는 어떤 작업을 수행하기 전에 관련 기술이 있는지 확인합니다.

동일한 접근 방식이 '오류 (Fallacies)'의 해결책에도 적용됩니다. 각 해결책은 자동으로 실행되는 에이전트 기술 (agent skill)로 인코딩될 수 있습니다. 엔지니어는 "생성하기 전에 기존 라이브러리가 있는지 확인하라"는 내용을 기억할 필요가 없습니다. 에이전트가 이를 필수 단계로 수행합니다.

다음은 8가지 기술입니다. 각 기술은 하나의 오류를 해결합니다. 각 기술은 현재의 에이전트 역량으로 오늘날 충분히 달성 가능합니다.

하지만 그 전에, 중요한 경계선이 있습니다.

에이전트 기술과 인간의 판단 사이의 경계

오류 (Fallacy) 해결책의 모든 것이 자동화되어야 하는 것은 아닙니다. 오류 (Fallacies) 시리즈 자체에서도 이에 대해 경고합니다. 오류 #3 (AI는 AI를 검증할 수 없다)와 오류 #4 (검토 생략)가 존재하는 이유는 팀들이 인간의 몫으로 남겨두어야 했을 판단 (judgment calls)을 자동화했기 때문입니다.

아래의 각 기술은 두 부분으로 나뉩니다:

기계적인 부분 (에이전트가 수행): 기존 라이브러리 검색. 컴파일러 (compiler) 실행. 린터 (linter) 실행. 사양 (specification) 파일 읽기. 경계값 계산. 이것들은 결정론적 출력 (deterministic outputs)을 가진 결정론적 동작 (deterministic actions)입니다. 에이전트가 이를 실행합니다. 판단 (judgment)이 필요하지 않습니다.

판단 단계 (에이전트가 이를 인간에게 제시함): "이것이 올바른 라이브러리인가요?" "이 아키텍처 제약 조건 (architectural constraint)이 여전히 적용되나요?" "이 새롭게 발견된 결정 사항을 새로운 사양 (spec)으로 만들어야 할까요?" 이러한 질문들은 문맥 (context), 도메인 지식 (domain knowledge), 그리고 전략적 사고 (strategic thinking)를 필요로 합니다. 에이전트는 질문을 표면화 (surface)하고, 인간이 이에 답합니다.

에이전트는 실무적인 작업 (LEGWORK)을 수행합니다. 인간은 결정 (CALL)을 내립니다. 결정을 내리려고 시도하는 에이전트가 바로 오류 #3 — AI를 사용하여 AI를 검증하는 것입니다. 실무적인 작업을 수행하지 않는 에이전트는 기계적인 작업에 인간의 주의력을 낭비하게 만듭니다 (오류 #4).

잘못된 예: 에이전트가 "이 라이브러리가 올바른 선택이다"라고 결정함 → 오류 #3
잘못된 예: 인간이 수동으로 라이브러리를 검색함             → 오류 #4
올바른 예: 에이전트가 검색 후 트레이드오프 (tradeoffs)가 포함된 3가지 옵션을 제시함 → 인간이 선택함

아래의 모든 기술은 이 경계를 준수합니다. 구분되는 지점을 주의 깊게 살펴보세요: **[MECHANICAL]**로 표시된 단계는 에이전트가 자율적으로 수행하는 작업입니다. **[SURFACE]**로 표시된 단계는 에이전트가 인간의 결정을 위해 제시하는 작업입니다.

기술 1: 컴포즈 우선 (Compose-First)

오류 #1 해결: 더 빠른 생성 ≠ 더 빠른 엔지니어링

발동 시점: 구현 코드 (implementation code)를 생성하기 전.

에이전트가 하는 일:

1. [MECHANICAL] 작업 분석: 어떤 기능 (capability)이 필요한가?
2. [MECHANICAL] 코드베이스 (codebase) 내에서 이미 해당 기능을 제공하는 기존 함수 검색
3. [MECHANICAL] 해당 기능을 제공하는 잘 관리되는 업스트림 라이브러리 (upstream libraries) 검색
...

이것이 초능력인 이유: 생성하는 대신 컴포즈 (compose)하는 에이전트는 동일한 기능을 구현하는 데 필요한 코드를 80-95% 적게 생성합니다. 코드량이 적다는 것은 유지보수, 테스트, 디버깅, 보안 작업이 줄어든다는 것을 의미합니다. 에이전트는 타자수가 아닌 사서 (librarian)가 됩니다. 기능은 확장되면서 코드베이스는 축소됩니다.

실제 사례:

기술이 없을 때:
    작업: "HTTP 재시도 로직 추가"
    에이전트: 150줄의 재시도 구현 코드를 생성함
...

기술 2: 속성 검사 (Property-Check)

오류 #2 해결: 그럴듯함 ≠ 정확함

발동 시점: 코드를 생성한 후, 인간에게 제시하기 전.

에이전트가 하는 일:

1. [MECHANICAL] 프로젝트의 속성 정의(존재하는 경우)를 읽습니다:
                .properties/ 디렉토리, INVARIANTS.md, CI 체크 설정,
                타입 제약 조건 (type constraints), API 계약 (API contracts),
                스키마 정의 (schema definitions)
...

이것이 왜 초능력인가: 에이전트는 단순히 그럴듯한 코드를 생성하는 데 그치지 않습니다. 인간이 확인하기 전에 자신의 출력을 선언된 속성들과 대조하여 검증합니다. 인간은 단순히 올바르게 보이는 코드가 아니라, 팀의 안전 경계(safety boundaries)에 따라 이미 평가가 완료된 코드를 전달받게 됩니다.

실제 사례:

기술이 없을 때:
    에이전트가 API 엔드포인트를 생성합니다. 올바르게 보입니다. 인간이 병합합니다.
    엔드포인트가 인증 없이 개인정보(PII)를 반환합니다. 운영 환경에서 발견됩니다.
...

기술 3: 기계적 검증 (Mechanical-Verify)

오류 #3 해결: AI는 AI를 검증할 수 없다

발동 시점: 에이전트가 자신의 출력을 검증해야 할 때.

에이전트가 하는 일:

1. [MECHANICAL] 검증할 각 속성을 분류합니다:
                타입 제약 조건 (Type constraint) → 컴파일러 실행
                API 계약 (API contract)    → 계약 테스트 (contract test) 실행
...

이것이 왜 초능력인가: 에이전트는 자신의 출력을 스스로 판단할 수 있는 척하는 것을 멈춥니다. 가능한 모든 기계적 체크를 실행하고, 자신의 '의견(OPINION)'이 아닌 '결과(RESULTS)'를 제시합니다. 주관적인 속성에 대해서는 스스로 검토하지 않고, 인간에게 질문을 던집니다. 에이전트는 자신이 결정론적으로(deterministically) 검증할 수 있는 것과 그렇지 않은 것을 알고 있습니다.

실제 사례:

기술이 없을 때:
    에이전트가 자신의 코드를 검토합니다: "이것은 올바르게 보입니다."
    코드에 에이전트가 잡아내지 못한 미묘한 타입 불일치(type mismatch)가 있습니다.
...

기술 4: 코드 작성 전 명세화 (Spec-Before-Code)

오류 #4 해결: 리뷰를 생략하는 것 ≠ 병목 현상을 제거하는 것

발동 시점: 구현을 작성하기 전, 브레인스토밍/계획 단계 이후.

**에이전트가 하는 일:

1. [MECHANICAL] 대상 모듈을 규정하는 모든 사양(specifications)을 읽습니다: 모듈 인터페이스(module interface), API 계약(API contract), 데이터베이스 스키마(database schema), ADR(Architecture Decision Records), 컨벤션(conventions)
2. [MECHANICAL] 적용되는 제약 사항(constraints) 목록을 추출합니다
   ...

이것이 초능력인 이유: 에이전트는 단순히 코드를 생성하고 누군가가 검토해주기를 바라지 않습니다. 에이전트는 기존 사양을 읽고, 인간과 함께 제약 사항을 확인하며, 해당 제약 사항 내에서 코드를 생성하고, 준수 여부를 검증합니다. 인간은 코드(크고 느림) 대신 제약 사항 목록(작고 빠름)을 검토합니다. 검토의 단계가 적절한 수준으로 이동합니다 — 인간을 위한 사양 검토, 에이전트를 위한 코드 검증.

실제 사례:

기술이 없을 때:
    에이전트가 코드를 생성합니다. 인간이 200줄을 검토합니다. 45분이 소요됩니다.
    코드가 결과 타입(result types) 대신 예외(exceptions)를 사용한다는 점을 놓칩니다.
...

기술 5: 출력 감사 (Output-Audit)

오류 #5 해결: 더 나은 컨텍스트(context) ≠ 올바른 출력(correct output)

발동 시점: 생성 후, 특히 검색된 컨텍스트에 포함되지 않은 속성(properties)을 기준으로 출력을 확인하는 단계.

에이전트가 하는 일:

1. [MECHANICAL] 코드를 생성한 후, 프로젝트 문서에서 적용 가능하지만 원래 컨텍스트에는 없었던 아키텍처 속성을 검색합니다:
                - 타임아웃(timeout), 인증(authentication), 개인정보(PII), 동시성(concurrency)을 언급하는 ADR
...

이것이 초능력인 이유: 에이전트는 자신의 컨텍스트 한계를 스스로 보완합니다. RAG(Retrieval-Augmented Generation)는 작업과 의미론적으로 유사한 문서를 검색합니다. 하지만 아키텍처 속성은 그것이 규정하는 코드와 의미론적으로 멀리 떨어져 있습니다. 이 기술은 RAG가 놓칠 수 있는 속성들을 명시적으로 검색합니다 — 왜냐하면 그러한 속성들은 벡터 공간(vector space)에서 구현 작업과 유사하지 않은 ADR, 컨벤션 문서, CI 설정 등에 존재하기 때문입니다.

실제 사례:

기술이 없을 때:
    RAG가 올바른 API 문서를 검색합니다. 에이전트가 올바른 API 호출을 생성합니다.
    코드가 내부 타임아웃 없이 동기식 외부 호출을 수행합니다
...

기술 6: 삭제 인지 (Deletion-Aware)

오류 해결 (Resolves Fallacy #6): 생성된 코드는 부채(liability)다

에이전트가 작동하는 시점: 구현(implementation) 및 리팩터링(refactoring) 작업 중.

에이전트의 동작:

1. [기계적 (MECHANICAL)] 코드를 생성하기 전, 코드베이스(codebase)에서 동일하거나 유사한 기능의 기존 구현체를 검색합니다.
2. [표면적 (SURFACE)] 중복 항목이 발견될 경우: "기존 구현체 3개를 발견했습니다..."
...```

**이것이 초능력인 이유:** 에이전트가 코드베이스의 규모를 능동적으로 줄여줍니다. 모든 작업에 대해 새로운 코드를 생성하는 기본 동작 대신, 에이전트는 중복을 검색하고, 공유 함수를 추출하며, 불필요한 구현체를 삭제합니다. 삭제 대 추가 비율(deletions-to-additions ratio)이 개선됩니다. 작업이 진행될수록 유지보수 부담이 증가하는 대신 감소하게 됩니다.

**실제 사례:**

기술이 없을 때:
한 달 동안 다섯 명의 개발자가 에이전트에게 날짜 형식 지정(date formatting)을 요청합니다.
다섯 개의 구현체가 존재합니다. 그중 하나에서 버그가 발견됩니다. 나머지 네 개는 여전히 고장 난 상태로 남습니다.
...

## 기술 7: 경계 읽기 (Boundary-Read)

**오류 해결 (Resolves Fallacy #7):** 명세(specs)는 이미 존재하며, 새로운 작업이 아니다

**에이전트가 작동하는 시점:** 모든 작업의 시작 시점, 코드 생성 전.

**에이전트의 동작:**

1. [기계적 (MECHANICAL)] 작업이 타겟팅하는 모듈/패키지(module/package)를 식별합니다.
2. [기계적 (MECHANICAL)] 해당 모듈의 기존 경계(boundaries)를 읽습니다:
   내보낸 인터페이스(exported interface), 임포트 제한(import restrictions), API 계약(API contract),
   ...

**이것이 초능력인 이유:** 에이전트가 기존 명세를 무시하는 대신, 이를 최우선 제약 조건(first-class constraints)으로 취급합니다. 대부분의 에이전트는 우연히 모듈의 스타일과 일치하는 코드를 생성할 뿐입니다. 하지만 이 에이전트는 인터페이스 정의를 읽고, 무엇이 내보내졌고 무엇이 그렇지 않은지를 파악하며, 경계를 위반하는 코드 생성을 거부합니다. 팀이 이미 구축해 놓은 파나스(Parnas) 경계가 마침내 에이전트 스스로에 의해 강제됩니다.

**실제 사례:**

기술이 없을 때:
에이전트가 다른 모듈의 내부 패키지를 임포트하는 코드를 생성합니다.
린터(linter)가 이를 잡아내지 못합니다. 헥사고날(hexagonal)...
...

## 기술 8: 프로토콜 동기화 (Protocol-Sync)

**오류 #8 해결:** 에이전트가 많아질수록 생산성이 높아진다 (More agents ≠ more productivity)

**발생 시점:** 모든 작업의 시작 단계, 또는 여러 에이전트가 동일한 코드베이스(codebase)에서 작업할 때.

**에이전트의 역할:**

1. [기계적 작업] 공유 명세(specification) 저장소 읽기:
   명명 규칙(naming conventions), 에러 처리 전략(error handling strategy),
   재시도 정책(retry policy), API 계약 버전(API contract versions),
   아키텍처 결정 기록(architecture decision records)
   ...

**이것이 초능력인 이유:** 에이전트가 보이지 않는 아키텍처 결정을 임의로 내리지 않기 때문입니다. 에이전트는 조정 프로토콜(coordination protocols, 공유 명세)을 읽고 이를 따르며, 명세에 포함되지 않은 결정 사항이 발견되면 이를 표시(flag)합니다. 별도의 조정 회의 없이도 여러 에이전트가 동일한 규칙, 동일한 에러 처리, 동일한 재시도 전략을 따르는 코드를 생성합니다. 명세는 프로토콜이며, 에이전트는 노드(node)입니다. 이를 통해 분산 시스템(distributed system)은 일관성(consistent)을 유지합니다.

**실제 사례:**

기술이 없을 때:
에이전트 A는 JSON 필드에 camelCase를 사용함.
에이전트 B는 snake_case를 사용함.
...

## 이것들이 "단순히 프롬프트를 더 잘 작성하는 것"과 다른 점

이것들은 프롬프트 개선이 아닙니다. 에이전트의 행동과 인간의 판단 사이에 명확한 경계를 두는 구조적인 워크플로우(workflow)의 변화입니다.

프롬프팅 (Prompting): "기존 라이브러리가 있는지 확인하는 것을 기억하세요"
→ 에이전트가 할 수도 있고 안 할 수도 있음. 확률적(Probabilistic)임.

...

이 경계는 이러한 기술들을 오류 #3(AI가 AI를 검증함)과 구분해 줍니다. 에이전트는 검색, 읽기, 체크 실행, 결과 수집과 같은 철저하고 결정론적인(deterministic) 기초 작업(legwork)을 수행합니다. 인간은 어떤 라이브러리를 사용할지, 제약 조건이 적용되는지, 명세에 누락된 결정 사항을 새로운 명세로 만들어야 하는지 등의 판단(judgment calls)을 내립니다. 이 경계를 넘어서는 에이전트는 상관관계가 있는 실패 모드(correlated failure modes)를 통해 판단을 자동화하려 합니다. 반면 이 경계를 존중하는 에이전트는 기계적인 작업을 수행함으로써, 인간의 판단이 정말 중요한 곳에 쓰일 수 있도록 자유를 부여합니다.

Superpowers 프레임워크는 이러한 차이를 증명했습니다. 기술 (Skills)은 단순한 제안이 아닙니다. 그것은 트리거 (triggers)에 따라 실행되는 필수적인 워크플로우 (workflows)입니다. 에이전트는 어떤 작업을 수행하기 전에 관련 기술이 있는지 확인합니다. 기술은 사후 고려 사항이 아니라 에이전트 프로세스의 일부로서 실행됩니다.

위의 각 기술은 다음을 포함합니다:

- **트리거 (trigger)** (언제 실행되는가)
- **프로세스 (process)** (에이전트가 단계별로 무엇을 하는가)
- **검증 (verification)** (기술이 올바르게 실행되었음을 어떻게 확인하는가)
- **보고 (report)** (에이전트가 인간에게 무엇을 전달하는가)

이는 Superpowers가 브레인스토밍 (brainstorming), TDD (테스트 주도 개발), 그리고 코드 리뷰 (code review)를 위해 사용하는 것과 동일한 구조입니다. 오류 해결 (Fallacy resolutions) 또한 동일한 프레임워크에 부합합니다. 왜냐로 그것들도 동일한 종류의 것, 즉 알려진 실패 모드 (failure mode)를 방지하는 구조화된 워크플로우이기 때문입니다.

## 복합 효과 (The compound effect)

8가지 기술을 동시에 실행하는 에이전트는: