AI Engineer World's Fair 2026 참관기

이 문서의 구성

AIE WF에서 다뤄진 논의는 크게 세 갈래였고, 이 세 갈래는 따로 노는 주제가 아니라 하나의 SDLC 루프 위에서 맞물립니다.

인간이 과제와 중요한 판단을 정의한다        ← 3부 (AI-Native Development)
  ↓
Context / Harness / Loop로 에이전트를 움직인다  ← 2부
  ↓
Trace와 Evals로 성과를 검증한다               ← 1부
  ↓
인간과 팀이 판단하고 다음 개선으로 연결한다     ← 3부

부	주제	핵심 질문
1부	Evals and Agent Improvement	에이전트가 실패했을 때 어디서 실패했는지 어떻게 아는가
2부	Context / Harness / Loop Engineering	무엇을 보여주고, 무엇을 허용하고, 어디까지 맡길 것인가
3부	AI-Native Software Development	에이전트를 전제로 개인과 팀의 개발은 어떻게 재설계되는가

1부. 에이전트의 실패를 관측하고, 평가하고, 개선으로 연결한다 — Evals and Agent Improvement

얼마 전 AI Engineer World's Fair 2026에 다녀왔습니다. AI Engineer World's Fair(이하 AIE WF)는 샌프란시스코에서 열린 기술 콘퍼런스입니다. AI 에이전트와 LLM 애플리케이션을 어떻게 개발하고 운영하는지, 그 실전 노하우가 오가는 자리입니다.

AIEWF2026-1

이번에 참가하면서 특히 실무에 바로 연결된다고 느낀 주제 중 하나가 Evals and Agent Improvement였습니다.

AI 에이전트는 PoC 수준이라면 비교적 쉽게 동작합니다. 프롬프트를 쓰고, Tool을 붙이고, 몇 번 돌려봐서 그럴듯한 출력이 나오면 "동작했다"고 말할 수 있죠.

하지만 프로덕션에서 문제가 되는 건 그 다음부터입니다.

에이전트가 실패했을 때 어디서 실패했는가
수정으로 정말 개선된 것인가
예전에 되던 것을 망가뜨리지는 않았는가
평가기(Eval) 자체는 믿을 수 있는가

이 부분을 애매하게 남겨둔 채 에이전트를 운영하면 결국 "좋아 보이는 출력을 보고 프롬프트를 만지작거리는" 수준에 머무릅니다.

이 글에서는 AIE WF에서 들은 내용을 바탕으로 에이전트의 실패를 어떻게 관측하고, 평가하고, 개선으로 연결할 것인지를 정리합니다.

1. 에이전트는 "동작했다"만으로는 부족하다

인상적이었던 대목은 에이전트를 대하는 관점이었습니다. 에이전트를 "한 번 동작하는 것"으로 보지 않습니다. "지속적으로 평가하고 개선하는 대상"으로 다룹니다.

AI 에이전트는 단일 LLM 호출이 아닙니다. Tool call, Retrieval, Reasoning, 중간 출력, 최종 출력을 포함하는 다단 시스템입니다.

그래서 최종 출력만 봐서는 실패 원인을 알 수 없습니다.

예를 들어 최종 출력이 그럴듯하게 틀렸다고 해도 원인은 여러 갈래입니다.

가져온 정보가 나빴다
Tool call의 인자가 틀렸다
중간 추론에서 해석을 잘못했다
마지막 문장화 단계에서 근거 이상의 내용을 썼다

따라서 에이전트 개발에서는 실패를 관측 가능하게 만드는 일이 핵심입니다. 최종 답변만 들여다봐서는 거기까지 가지 못합니다.

1.1 Evals도 얼마든지 거짓말을 한다

한편으로 Evals만 넣으면 안심이냐 하면 그것도 아닙니다.

특히 LLM as a Judge에는 몇 가지 전형적인 편향이 있습니다. Kumar 씨의 세션에서는 다음 편향을 짚었습니다.

position bias: 먼저 제시된 선택지를 고르기 쉽다
sycophancy: 사용자나 후보 답변에 영합하기 쉽다
self-preference: 같은 모델 패밀리의 출력을 선호하기 쉽다
verbosity bias: 길고 자신감 있어 보이는 답변을 높게 평가하기 쉽다

Arize 워크숍에서도 비슷한 편향을 다뤘습니다.

position bias, length bias, confidence bias, self-preference

LLM as a Judge는 "평가기"이긴 하지만 "진리"는 아닙니다.

그래서 이 글에서는 "Evals를 넣는다"에서 멈추지 않습니다. 에이전트의 실패를 관측하고, 평가를 단계적으로 키우고, 그 평가 자체도 의심하면서 개선 실험까지 이어가는 흐름을 다룹니다.

국내 서비스에 LLM as a Judge를 붙여보면 원문에 나온 네 가지 외에 두 가지가 더 걸립니다. 하나는 언어 비대칭입니다. 같은 Rubric이라도 영어 출력보다 한국어 출력에서 판정이 흔들리는 경우가 많아 Rubric 자체를 한국어로 쓰고 few-shot 예시도 한국어 실패 사례로 채우는 편이 일치율이 높습니다. 다른 하나는 문체 편향입니다. 존댓말·격식체로 정중하게 쓰인 답변이 근거가 부족해도 높은 점수를 받는 경향이 있어서 Rubric에 "문체와 정중함은 평가 대상이 아니다"를 명시적으로 못 박아 두는 게 안전합니다.

1.2 작게 시작한다: LLM as a Judge에 곧바로 뛰어들지 않는다

평가 체계는 작게 시작해야 합니다.

처음부터 완벽한 평가 체계나 자동 개선 구조를 만드는 건 어렵습니다. 미성숙한 평가 기준을 그대로 둔 채 자동 개선을 돌리면 품질이 좋아지지 않습니다. "평가의 구멍을 파고드는 최적화"가 될 뿐입니다.

현실적으로는 다음 순서로 키우는 편이 낫습니다.

Trace
  ↓
Error Analysis
  ↓
Code-Based Eval
  ↓
LLM as a Judge
  ↓
Meta Evaluation
  ↓
Auto Improvement

여기서는 곧바로 LLM as a Judge에 뛰어들지 않는 게 중요합니다.

출력의 필수 항목, enum, 참조 ID 같은 건 LLM에게 평가시킬 필요가 없습니다. 코드로 검증하면 끝납니다. LLM as a Judge를 정말 써야 하는 곳은 코드로는 판정하기 어려운 의미적 품질입니다.

작게 시작한다고 평가를 대충 한다는 뜻은 아닙니다. 관측할 수 있는 것, 코드로 지킬 수 있는 것, LLM에게 판단시킬 것, 사람이 확인해야 할 것을 갈라놓는 작업입니다.

2. Trace: 에이전트의 실패를 관측한다

에이전트 개선의 첫걸음은 Trace입니다.

이번 AIE WF에서는 많은 기업이 이미 Observability 인프라를 기본값으로 깔아두었다고 느꼈습니다.

단순히 로그를 남기자는 이야기가 아닙니다. 에이전트의 행동을 나중에 분석하고 비교하고 개선하려면 그에 맞는 데이터가 필요한데 그 중요성을 많은 기업이 이미 알아챘다는 방증이라고 생각합니다.

이 점은 예전에 제가 썼던 글과도 연결되는 사고방식입니다.

그 글에서 Observability를 다음과 같이 정리했습니다.

관측 단위는 "처리가 실행된 단위"가 아니라, "나중에 비교·교체·개선하고 싶은 단위"로 잘라야 한다.

AIE WF에서 나온 Trace/Evals 이야기와도 그대로 이어집니다.

Trace를 자르는 방식이 나쁘면 실패는 보이지 않습니다. 실패가 보이지 않으면 Eval도 쓸 수 없습니다. Eval을 쓸 수 없으면 개선 실험도 못 합니다.

에이전트 개선에서 Trace는 개선 루프의 토대입니다.

국내 도입 시 Observability 스택 선택지 발표장에서는 Arize AX(SaaS)를 전제로 설명합니다. 다만 국내 금융·공공·의료처럼 망분리나 데이터 국외 반출 제약이 걸리는 환경에서는 SaaS 트레이싱 도구에 프롬프트와 사용자 입력을 그대로 올리기 어렵습니다. 이럴 때는 셀프호스팅이 가능한 대안을 찾게 됩니다. Langfuse는 Docker Compose로 온프레미스 구성이 가능하고, Arize Phoenix도 OSS 버전을 자체 서버에 올릴 수 있습니다. 표준을 맞추고 싶다면 OpenTelemetry의 GenAI semantic conventions를 계측 레이어로 두고, 백엔드만 교체 가능하게 설계해 두는 쪽이 나중에 이관 비용이 적습니다. 어느 쪽이든 Trace에 개인정보가 섞이는 걸 전제로 저장 전에 마스킹 훅을 한 단계 두는 것을 권합니다.

3. Evals: 싸게 지킬 수 있는 것부터, 의미적 품질로

Trace를 확보했다면 다음은 Eval입니다.

다만 여기에도 순서가 있습니다.

3.1 Code-Based Eval: 결정적으로 판정할 수 있는 것을 지킨다

Code-Based Eval은 LLM을 쓰지 않고 결정적으로 판정하는 평가입니다.

예를 들어 이런 항목은 Code-Based Eval의 몫입니다.

필수 항목이 채워져 있는가
참조 ID가 후보 리스트에 존재하는가
추출값의 근거 텍스트가 원본 페이지에 존재하는가

이전 글에서도 LLM 출력을 pageId나 구조화 데이터로 제한하고, ID 검증·근거(evidence) 검증을 코드 쪽에서 처리하는 설계를 다뤘습니다.

Eval 관점에서도 마찬가지입니다. 코드로 판정할 수 있는 것은 코드로 검증하는 편이 싸고, 빠르고, CI에도 태우기 쉽습니다.

예를 들어 Arize 워크숍에서는 금융 상품을 수집해 리포트를 작성하는 에이전트를 놓고 종목 코드가 지정한 범위 안에 있는지 체크하는 Eval을 보여줬습니다.

class MentionsEvaluator(CodeEvaluator):
    def evaluate(
        self,
        *,
        query: Optional[str] = None,
        report: Optional[str] = None,
        **kwargs: Any,
    ) -> EvaluationResult:
        # Extract ticker symbols from the input (uppercase 1-5 letter words)
        tickers = re.findall(r"\b([A-Z]{1,5})\b", query)
        # Filter to likely tickers (skip common words)
        likely_tickers = [
            t
            for t in tickers
            if len(t) >= 2
            and t not in ("AI", "US", "CEO", "CFO", "IPO", "ETF", "AWS", "USE")
        ]
    
        if not likely_tickers or not report:
            return EvaluationResult(
                label = "unknown",
                score = 0
            )
    
        missing = [t for t in likely_tickers if t not in report.upper()]
    
        if not missing:
            return EvaluationResult(
                label = "pass",
                score = 1
            )
        else:
            return EvaluationResult(
                label = "fail",
                score = 0
            )

LLM이 잘못된 정보를 참조하지는 않는지 정도의 거친 확인이라면 이 Code-Based Eval만으로 충분합니다.

한국 환경 적용 시 주의 위 예시는 미국 주식 티커(대문자 1~5글자)를 전제로 한 정규식입니다. 한국 시장을 다루는 에이전트라면 종목 코드가 005930처럼 6자리 숫자이므로 r"\b(\d{6})\b" 형태로 바꾸고, 우선주(005935)나 ETF 코드까지 포함할지 결정해야 합니다. 또한 국내 리포트는 티커보다 종목명("삼성전자")으로 언급되는 경우가 많아 코드↔종목명 매핑 테이블을 두고 둘 중 하나라도 언급되면 통과시키는 방식이 실무적입니다.

3.2 LLM as a Judge: 의미적 품질을 본다

물론 코드로는 평가하기 어려운 의미적 품질도 있습니다. 이런 평가에는 LLM as a Judge가 유효합니다.

Arize 워크숍에서는 Correctness / Faithfulness / Actionability 같은 관점을 나눠서 LLM에게 평가시키는 예를 보여줬습니다.

특히 하나의 Evaluator에서는 하나의 관점(Dimension)만 본다는 원칙이 중요합니다.

다음은 워크숍에서 소개된 예시입니다.

from phoenix.evals import ClassificationEvaluator

actionability_template = """
You are an expert financial analyst evaluator. Your task is to judge whether
a financial report provides actionable investment guidance, not just raw data.

ACTIONABLE — The report:
- Contains specific recommendations (buy/sell/hold or equivalent guidance)
- Identifies concrete risks with supporting data
- Includes forward-looking analysis, not just historical data
- Provides context for WHY recommendations are made

NOT ACTIONABLE — The report:
- Only summarizes publicly available data without interpretation
- Lacks specific recommendations or next steps
- Presents risks without supporting evidence
- Contains only backward-looking analysis

Here are examples of each:

Example — ACTIONABLE:
\"Based on NVDA's 122% YoY revenue growth driven by data center demand,
strong forward P/E of 35x relative to sector median of 22x, and expanding
margins, NVDA presents a compelling growth position. Key risk: concentration
in AI training chips (~70% of revenue). Recommendation: accumulate on
pullbacks below $800.\"

Example — NOT ACTIONABLE:
\"NVDA is a major player in the semiconductor industry. The company has seen
significant growth in recent years driven by AI demand. NVDA's stock has
performed well. Investors should consider various factors when making
investment decisions.\"

<user_query>
{input}
</user_query>

<financial_report>
{output}
</financial_report>
"""

actionability_evaluator = ClassificationEvaluator(
    name="actionability",
    llm=llm,
    prompt_template=actionability_template,
    choices={"actionable": 1.0, "not actionable": 0.0},
)

이 예시와 함께 좋은 판정 기준(Rubric) 프롬프트를 쓰는 요령도 나왔습니다.

Role을 명확히 한다
pass/fail의 평가 기준을 구체적으로 쓴다
입력 데이터와 평가 대상을 XML tag 등으로 명확히 구분한다
출력 선택지는 프롬프트 밖에 쓴다

여기서 특히 와닿았던 건 평가 기준을 책상에서 만들지 말라는 대목이었습니다.

Trace를 읽고, 에러와 엣지 케이스를 평가해서 실제 실패 사례에서 평가 기준을 만든다.

다음은 이 워크숍에서 나온 말인데 실전적이고 공감이 갔습니다.

오늘 발견한 Failure가, 내일의 Criteria가 된다

3.3 Meta Evaluation: Judge 자체를 의심한다

LLM as a Judge를 만들었다고 끝이 아닙니다.

이 Evaluator 자체도 평가해야 합니다.

흐름은 단순합니다.

실제 Trace를 몇 개 고른다
사람이 정답 레이블을 붙인다
같은 Trace를 LLM as a Judge에게 평가시킨다
사람 레이블과 LLM 레이블의 일치율을 본다
불일치 이유를 읽고 Rubric을 개선한다

사람 레이블과의 일치율은 80~85% 정도를 기준으로 보면 좋다고 합니다. 100% 일치라면 적은 데이터에 과적합됐을 가능성도 있습니다.

일치율만 보면 속는다 단순 일치율(accuracy)은 레이블이 한쪽으로 쏠려 있을 때 쉽게 부풀려집니다. pass가 90%인 데이터셋이라면 무조건 pass만 뱉는 Judge도 일치율 90%가 나옵니다. 그래서 실무에서는 우연 일치를 보정한 Cohen's kappa를 함께 보고, pass/fail 각각의 precision·recall을 나눠서 확인하는 편이 안전합니다. 특히 놓치면 안 되는 실패를 잡는 게 목적이라면 fail 쪽 recall을 주 지표로 삼아야 합니다.

4. Trace Mining과 Auto Improvement

Trace와 Eval이 갖춰져야 비로소 개선 루프가 돕니다.

4.1 Trace는 개선 데이터가 된다

LangChain 세션에서는 Observability와 Continual Learning을 동전의 양면처럼 다뤘는데 이 대목이 인상적이었습니다.

Observability와 Continual Learning은 동전의 양면이다

에이전트가 환경에서 동작하면 tool call, 중간 출력, 최종 출력 등이 Trace로 남습니다.

이것들은 그대로 개선 데이터가 됩니다.

Trace에서 실패 분류, Eval 데이터셋, 회귀 테스트(regression test), 프롬프트·Tool 개선용 데이터, 증류(distillation)나 Fine-Tuning용 데이터가 나옵니다.

일단 v1을 만들어 돌린다. Trace를 모은다. Trace를 정리·분류한다. 그 데이터로 개선 실험을 한다.

Continuously Improving Agents의 Recipe. v1 에이전트를 돌리고, Trace를 모으고, Trace data를 정리하고, 그 데이터로 실험하는 흐름.

소박하지만 꽤 실무적이라고 느꼈습니다.

4.2 평가 결과를 개선 실험으로 연결한다

워크숍에서는 Judge의 평가 이유 텍스트를 사용해 에이전트의 프롬프트를 개선하는 흐름을 보여줬습니다.

구체적으로는 평가에서 실패한 Trace를 모아 그 Judge 결과를 LLM에 넘겨 프롬프트를 개선시킵니다. 그다음 개선된 에이전트를 같은 실패 데이터셋에 돌려보고 실험 결과로 비교합니다.

The SDLC closing on itself

이 그림은 Arize AX를 전제로 합니다. 프로덕션 트래픽에서 Trace가 생기고, 온라인 Eval로 평가되고, 실패 이유가 평가 이유 텍스트로 쌓입니다. 그걸 바탕으로 수정안을 만들고, 수정안을 실험으로 검증하고, 다시 프로덕션 환경으로 되돌리는 루프가 제시되어 있었습니다.

이 이상적인 루프가 잘 돌아가면 에이전트는 프로덕션에서 지속적으로 개선됩니다.

다만 평가가 어긋나면 개선도 어긋납니다. 검증되지 않은 LLM as a Judge를 믿고 개선 루프를 돌리면 에이전트는 정말로 좋아지는 대신 Judge의 버릇에 최적화될 수 있습니다.

4.3 Auto Improvement는 출발점이 아니라 도달점

Trace와 Eval이 갖춰지면 그 결과로 에이전트를 자동 개선하는 데까지 갈 수 있습니다.

다른 세션에서는 그 예로 GEPA를 소개했습니다. GEPA는 평가 점수뿐 아니라 Trace, Tool의 에러, Evaluator의 피드백 같은 텍스트 정보까지 LLM에게 분석시켜 프롬프트 개선 후보를 만드는 기법입니다.

GEPA: Reflective Prompt Optimization for Agents

자세한 내용은 GEPA 리포지토리나 GEPA를 간단히 쓸 수 있는 optimize_anything을 참조해 주세요.

GEPA — https://github.com/gepa-ai/gepa
optimize_anything — https://gepa-ai.github.io/gepa/ (참고 아티팩트: https://github.com/gepa-ai/optimize-anything-artifact)

GEPA 같은 자동 개선 구조 자체는 획기적이고, 앞으로 주류가 되리라 봅니다. 다만 한 가지는 짚고 넘어가야겠습니다. Auto Improvement는 출발점이 아니라 도달점입니다.

Trace가 있고, Error Analysis가 있고, Code-Based Eval이 있고, LLM as a Judge가 있고, 그 Judge 자체의 신뢰성을 검증하고 나서야 비로소 Auto Improvement로 나아갈 의미가 생깁니다.

5. 정리

AIE WF의 Evals 계열 세션들을 보면 에이전트 개발의 중심이 옮겨가고 있습니다.

지금까지는 좋은 프롬프트를 쓰는 것, 강한 모델을 고르는 것, Tool을 연결하는 것에 관심이 쏠리기 쉬웠습니다.

하지만 프로덕션에서 에이전트를 운영할 거라면 실패를 관측하고, 평가하고, 개선 실험으로 연결하는 루프가 반드시 필요합니다.

처음부터 크게 시작할 필요는 없습니다.

먼저 Trace를 남긴다. Trace에서 실패를 분류한다. Eval을 만든다. 그 Eval도 사람 레이블로 검증한다. 마지막으로 평가 결과를 개선 실험으로 연결한다.

AIE WF에서 얻은 가장 실무적인 배움은 하나입니다. 에이전트 개선은 마법이 아니라 관측 가능한 학습 루프로 설계하는 일입니다.

이번 글에서는 Eval에 좁혀서 소개했지만 에이전트는 프롬프트만으로 성립하지 않습니다. 특히 Context, Harness, 그리고 Loop의 설계가 필수적입니다.

이어지는 2부에서는 이 Context / Harness / Loop Engineering에 관한 세션을 소개하며 2026년 시점의 현재 위치를 깊이 파보겠습니다.

2부. Context / Harness / Loop Engineering — 에이전트 시스템의 설계 레이어

1부에서는 AIE WF에서 들은 Evals and Agent Improvement 내용을 바탕으로 에이전트의 실패를 어떻게 관측하고 평가해서 개선으로 연결할지를 정리했습니다.

2부에서는 조금 더 에이전트 시스템 전체의 설계로 파고들어 Context Engineering / Harness Engineering / Loop Engineering을 정리합니다.

1. Context Engineering의 현재 위치

Context Engineering 자체는 이미 당연한 전제가 됐습니다. 이번 콘퍼런스에서 느낀 건 많은 기업이 벌써 그다음 레벨의 논의로 들어가 있다는 점이었습니다.

Context Engineering이라고 하면 RAG나 MCP, 혹은 Skills를 떠올리는 분이 많을 겁니다.

물론 이것들 자체는 중요합니다.

다만 AIE WF에서는 MCP나 Tool을 그냥 도입하기만 해서는 금방 벽에 부딪힌다는 이야기가 반복해서 나왔습니다.

1.1 MCP는 Context의 입구일 뿐, Context Engine이 아니다

LinkedIn 세션에서는 사내의 대규모 코드베이스에서 Coding Agent를 쓸 때 부딪히는 과제를 소개했습니다.

Cursor나 Claude Code를 직원들에게 나눠줘도 그것만으로는 사내 코드베이스에서 제대로 동작하지 않습니다.

그래서 우선 코드 검색 MCP를 만들고 Docs, Jira, Slack, 데이터 인프라, Feature Flags 등을 연결했습니다.

LinkedIn의 MCP

하지만 그것만으로는 복잡한 업무를 안정적으로 해내기에 부족했다고 합니다.

사내 지식은 Docs, Wiki, Slack, 티켓 등으로 흩어집니다. 정보원마다 얼마나 오래됐는지도, 얼마나 믿을 만한지도 다릅니다. 여기에 Tool을 늘리면 Tool 검색이 Context를 압박합니다. 한 번 올바른 절차에 도달해도 그 지식은 다음 세션으로 인계되지 않습니다.

발표자료에는 Docs / Jira / Slack 조합은 실리콘밸리 기본값에 가깝습니다. 국내에서는 Notion·Confluence에 두레이·잔디·카카오워크·스윗 같은 국산 협업툴이 섞이고 여기에 카카오톡 오픈채팅방이 사실상의 장애 대응 채널로 굴러가는 경우도 흔합니다. 문제는 MCP 커버리지입니다. Slack·Jira·Notion은 공식 또는 준공식 서버가 있지만 두레이는 커뮤니티가 올린 비공식 서버가 여럿 있는 정도이고 그 외 국산 툴은 공개 REST API 위에 사내 래퍼를 직접 얹어야 하는 경우가 대부분입니다. LinkedIn 사례를 그대로 따라가려면 "MCP를 붙인다"가 아니라 "MCP를 만든다"부터 공수를 잡아야 합니다.

1.2 Skills / Playbook으로 Context를 운용한다

LinkedIn의 해결책은 Playbook(Skills)을 MCP 경유로 배포하는 것이었습니다.

Playbook은 에이전트 입장에서 보면 Tool처럼 발견해서 호출합니다. 다만 그 자체가 외부 API를 때리는 Tool은 아닙니다. 사내 절차와 운용 지식을 에이전트에게 넘기기 위한 Context 그 자체입니다.

LinkedIn에서는 Skill이라는 개념이 나오기 전부터 이런 구조를 만들어왔기 때문에 Playbook이라고 부른다고 합니다.

LinkedIn Playbooks

예를 들어 어떤 알럿을 조사할 때 어느 로그를 봐야 하는지, 어느 서비스의 어느 운용 절차를 따라야 하는지, 티켓은 어떻게 갱신해야 하는지가 Playbook으로 관리됩니다.

툴은 다음 3가지가 준비돼 있고 순서대로 실행된다고 합니다.

search: playbook 검색
get_schema: playbook의 실행 스키마를 조회
execute: 지정 스키마의 입력을 바탕으로 더 세부적인 업무 절차와 필요한 컨텍스트가 반환됨

다음은 Playbook의 대표적인 예입니다. 아래는 개념을 보여주는 예시이고 실제로는 더 상세한 컨텍스트 정보가 반환된다고 합니다.

name: airflow_dag_authoring
description: Create Airflow DAGs at LinkedIn.
inputs:
  dag_name: "user_features_daily"
  schedule: "0 13 * * *"
instructions: |
  ## Concepts
  ## Steps
    1. Set up env       → create_repo
    2. Author DAG       → airflow_app_create
    3. Add Spark task   → spark_batch_operator
    4. Deploy           → deploy
  ## Best practices
  ## Gotchas
    - timezone-naive datetimes
    - retries default to 0
  ## Verification
  ## Troubleshooting

이 예시의 각 Step은 create_repo나 airflow_app_create 같은 Sub Playbook을 호출합니다.

이런 LinkedIn의 Playbook에는 몇 가지 설계 원칙이 있었습니다.

Self-contained: 하나의 Playbook은 특정 태스크에 닫힌 Context로 설계한다
Composable: 작은 Playbook으로 분해해서 조합할 수 있게 한다
Progressive discovery: 작업 진행에 따라 필요한 Context만 가져오게 한다

이 playbook들은 리포지토리 상의 Playbook과 조직 전체의 Playbook 두 종류로 관리된다고 합니다.

더 흥미로웠던 것은 Playbook의 자기 개선입니다.

흐름은 다음과 같은 이미지입니다.

Playbook을 사용해 엔지니어가 에이전트로 작업
세션 종료 시 에이전트가 오래되었거나 부족한 정보를 지적
필요에 따라 엔지니어가 에이전트에게 갱신 의뢰
에이전트가 편집한 PR을 생성
사람이 Approve하고 머지

Self-improving playbooks

Context를 정적인 문서로 두지 않고 에이전트의 이용 이력을 통해 갱신되는 운용 자산으로 다루는 사고방식입니다.

1.3 "정보 접근"을 "쓸 수 있는 Context"로 바꾸는 Context Engine

Unblocked 세션에서도 비슷한 문제의식을 다뤘습니다.

인간 엔지니어는 실제 실무 속에서 질문하고, PR을 리뷰받고, Slack에서 논의하면서 "이 회사에서는 어떻게 만들어야 하는가", "이 리포지토리에서는 무엇을 조심해야 하는가", "이 변경은 누구에게 물어봐야 하는가"를 알게 됩니다.

에이전트에게 보이지 않는 암묵지

한편 에이전트는 매번 그 Context를 갖지 않은 채로 기동합니다. MCP를 연결하면 정보에 접근할 수는 있습니다. 다만 그 정보를 태스크에 실제로 쓰는 건 다른 이야기입니다.

그런 의미에서 인간은 매일의 업무를 통해 머릿속에 Context Engine을 만들어 갑니다.

Unblocked 세션에서는 Context Engine에 필요한 요소를 정리했습니다. 에이전트가 인간의 업무를 대체할 때 쓰는 엔진입니다.

Unified system context: 코드, PR, 티켓, Slack, 장애 관리 등을 통합
Targeted retrieval: 태스크에 필요한 정보만 가져옴
Conflict resolution: 모순되면 갱신 일시나 정보원의 신뢰도로 순위 매김
Personalized relevance: 질문자, 리포지토리, 기능 등으로 좁힘
Token optimization: 검색 결과를 압축해서 전달
Permission enforcement: 사용자나 에이전트의 접근 권한에 준함

Context Engine

Unblocked는 Context Engine 회사이니 주장을 받아들이는 방식이나 실제 구축 방법은 주의가 필요합니다. 다만 문제의식과 사고방식은 많은 기업이 받아들일 가치가 있는 관점이라고 느꼈습니다.

1.4 Context Engineering은 A2A로 확장된다

Context Engineering은 단일 에이전트 이야기에서 그치지 않습니다.

Town 세션에서는 A2A나 여러 사일로를 넘나드는 Context의 취급이 테마였습니다.

이 세션은 에이전트의 실행을 Search Problem으로 봤습니다.

Running an agent is a search problem

에이전트가 최종적으로 사용자에게 응답할 때 그 직전의 Context Window에 얼마나 올바른 정보를 모았는지가 에이전트의 성능을 결정합니다.

멀티 에이전트의 이상 상태를 one context window, many silos로 짚어낸 대목이 인상적이었습니다.

여러 에이전트를 생각하면 정보는 개인의 메일, 팀의 Slack, 외부 파트너와의 주고받음 등 여러 사일로로 나뉩니다. 그것들을 전부 모든 에이전트에게 보여줘도 되는 것도 아닙니다.

세션에서는 구현 패턴으로 다음 몇 가지를 들었습니다.

신뢰 경계 안쪽에서는 넓게 접근시킨다
관계성이나 점수 같은 Signal만 공유한다
공유 사일로를 의도적으로 만든다
인간을 정보의 중계점으로 삼는다
블랙박스 안에서 넓은 정보를 내부적으로 탐색하고 정보 공개 직전에만 인간에게 승인을 요구한다

어느 쪽이든 일장일단이 있습니다. 장기적으로는 완전 자동화를 목표로 하겠지만 우선은 가장 안전한 주변부부터 자동화 범위를 넓혀 나가야 한다는 주장이었습니다.

Context Engineering의 질문은 이제 "Agent에게 무엇을 넘길 것인가"에 머물지 않습니다. "여러 에이전트·여러 사일로·여러 권한 사이에서 어떤 Context를 어디까지 유통시킬 것인가"까지 넓어졌습니다.

2. Harness Engineering: Context만으로는 에이전트가 안전하게 움직이지 않는다

Context Engineering은 기본적으로 에이전트에게 무엇을 보여줄 것인가를 다룹니다.

하지만 에이전트가 Tool을 호출하고, 상태를 고쳐 쓰고, 외부 시스템에 부작용을 일으킨다면 문제는 Context만으로 닫히지 않습니다.

여기서 나오는 것이 Harness Engineering입니다.

2.1 5가지 장애 사례로 배우는 Harness Engineering

OpenAI의 Govindarajan 씨 세션에서는 에이전트의 5가지 장애 사례를 들었습니다. 에이전트의 프로덕션 장애 대부분은 모델의 추론 실패가 아니라 Harness의 실패라는 설명이었습니다.

State hole: 에이전트는 OK를 반환했는데 실제로는 저장되지 않았다
Overlapping writers: 여러 쓰기가 경합한다
Dangling tool call: 툴이 조용히 죽어서 에이전트가 계속 기다린다
Approval Drift: 부여한 실행 권한이 드리프트한다
Missing Proof: Agent는 완료했다고 말하는데 증거가 없다

이런 실패는 코딩 에이전트를 일상적으로 써온 사람이라면 누구나 겪어본 적이 있지 않을까요?

이 세션에서는 이 장애들을 해결하면서 얻은 중요한 3가지 관점을 소개했습니다.

Own the state: 정본(source of truth)은 어디인가, 누가 갱신할 수 있는가, 어떻게 복원할 수 있는가
Order the mutation: 갱신 순서나 동시 실행을 어떻게 제어할 것인가
Prove the action: 무엇이 제안·허가·실행되었는가, 그것을 어떻게 증명할 것인가

이처럼 신뢰할 수 있는 에이전트를 구축하려면 모델이나 Context보다 오히려 더 전통적인 시스템 관점이 중요합니다. 그 에이전트가 실제로 건드리는 정본(source of truth), 실행 순서, 그 증적 말입니다.

특히 이 세션에서는 모델을 엔진, Harness를 자동차 전체에 비유한 것이 인상적이었습니다.

the model is the engine

이런 Harness와 모델의 경계 이야기는 예전에 제가 정리했던 모델과 코드의 책무 경계 이야기와도 통하는 데가 있다고 느꼈습니다.

2.2 Codex로 보는 Harness의 구현 책무

또 다른 OpenAI 세션에서는 Codex 내부에서 Harness가 구체적으로 무엇을 담당하는지를 소개했습니다.

Codex는 허가된 조작을 명시적인 Tool로 제공합니다. 파일 편집에는 apply_patch, 조사나 테스트 실행에는 Shell, 브라우저 조작에는 Playwright를 사용한 코드 실행을 붙이는 식입니다.

이 조작들이 전부 Sandbox를 통한다는 점이 중요합니다. Codex 내에서는 실행하는 OS마다 각각에 맞는 Sandbox를 쓰고 모델이 조작할 수 있는 범위를 실행 환경 쪽에서 제한합니다.

한편 Sandbox를 엄격하게 하면 인간에게 승인을 요구하는 일이 늘어나 장기 태스크가 멈추기 쉬워집니다. 그래서 Codex는 경계를 넘는 조작을 서브에이전트가 심사하는 Auto-review를 도입했습니다.

Auto-review는 실행 예정인 조작뿐 아니라 사용자의 지시, 대상, 예상되는 부작용 등을 확인해서 그 조작이 사용자로부터 허가된 범위인지를 판정합니다. 예를 들어 명시적으로 의뢰받은 로컬 파일 삭제는 승인해도 파일을 외부로 송신하는 조작은 다른 리스크로 다룹니다.

Auto-review

에이전트의 안정성·안전성은 프롬프트로 신중하게 행동하게 만드는 것만으로는 만들어지지 않습니다. 이 세션에서 얻은 배움이었습니다.

모델에게 넘길 Tool, Sandbox의 경계, 승인 조건을 Harness 쪽에서 설계해야 비로소 에이전트의 행동이 제어 범위 안으로 들어옵니다. Harness는 모델 호출의 래퍼가 아닙니다. 모델의 의도를 제약된 실행으로 변환하는 Runtime입니다.

3. Loop Engineering: 장기 태스크를 제어 가능하게 만든다

모델과 Harness가 진화하면서 에이전트의 1회 실행은 비교적 안정적으로 동작합니다. 한편 몇 시간·며칠·여러 스텝에 걸친 태스크를 맡기면 Context가 비대해지거나 Memory가 틀리면서 인간의 의도에서 조금씩 어긋나 갑니다.

여기서 필요해지는 개념이 Loop Engineering입니다.

3.1 Loop를 Control Theory로 설계한다

HumanLayer의 Mistele 씨 세션은 기존 oRPC procedure를 Effect 기반 구현으로 마이그레이션하는 Loop를 소재로 삼았습니다. 여기서 Loop Engineering을 Control Theory로 설명했습니다. 현재 상태를 관측하고, 목표와 현재의 차분을 구하고, 그 차분을 작게 만드는 변경을 가하는 방식입니다.

Control Theory

Sensor가 현재 상태를 관측하고, Controller가 다음에 어떤 변경을 할지 결정하고, Actuator가 실제로 변경을 가하고, 그것을 Sensor가 다시 관측하면서 에이전트의 제어 루프가 돌아갑니다.

여기서 에이전트를 모든 역할에 쓰면 안 됩니다.

이 세션의 예에서는 아직 마이그레이션되지 않은 코드를 검출하는 Sensor에 ast-grep을 썼고 대상 선택도 결정적인 로직으로 처리했습니다. 에이전트는 선택된 대상을 수정하는 Actuator로 씁니다.

예를 들어 ast-grep의 실행 결과로 다음을 소개했습니다.

$ ast-grep scan -r rule.yml --color never --json \
  | jq '[.[] | {ruleId, file, message, severity}] | sort_by(.severity, .file, .ruleId)'
[
  {
    "ruleId": "orpc-unmigrated-procedure",
    "file": "apps/admin-dashboard-api/src/orpc/campaign/automation.ts",
    "message": "Classic .handler procedure — not yet migrated to Effect.",
    "severity": "warning"
  },
  {
    "ruleId": "orpc-unmigrated-procedure",
    "file": "apps/admin-dashboard-api/src/orpc/campaign/automation.ts",
    "message": "Classic .handler procedure — not yet migrated to Effect.",
    "severity": "warning"
  },
  {
    "ruleId": "orpc-unmigrated-proc…(가려져서 안 보임)",
    "file": "apps/admin-dashboard-…(중략)…ign/get-user.ts",
    "message": "Classic .handler …(중략)…grated to Effect.",
    "severity": "warning"
  }
]

Loop Engineering에서는 에이전트의 자유도를 올리기보다 한 번에 변경할 수 있는 범위를 한정하는 게 중요하다는 주장이었는데 저도 공감되는 부분이 컸습니다.

실제로 코드베이스 전체를 한 번에 변경하지 않고 1회의 Loop로 작은 PR을 만들었습니다. Loop의 속도는 모델이 생성할 수 있는 양이 아니라 인간이나 팀이 확인할 수 있는 양에 맞춰야 합니다.

참고로 이 세션에서는 다음 Skill로 Loop를 설계하는 것을 소개했으니 관심 있는 분은 리포지토리를 들여다보면 좋을 것 같습니다.

npx skills add humanlayer/skills --skill design-control-loop

3.2 Loop를 키우기 위한 Human on the Loop

이 Mistele 씨 세션에서는 피드백을 MD 파일로 관리하면서 Loop를 키워 나가는 방법도 소개했습니다.

PR 상에서 인간이 /iterate라고 코멘트하면 에이전트가 코드를 수정하면서 피드백 파일도 함께 갱신하는 구조입니다.

이 방법에는 다음과 같은 장점이 있습니다.

개선 내용이 Git에 남는다
틀렸으면 revert할 수 있다
루프 전체가 서서히 개선된다

이번 세션에서 Loop의 대상 태스크는 애초에 레거시 코드 마이그레이션이라는 한정적인 태스크였습니다. 역시 작게 시작하는 것이 중요하다고 느끼기도 했습니다.

3.3 Goal / Loop / Schedule로 Babysitting에서 Autonomy로

WorkOS 세션에서는 에이전트를 일일이 감시하는 Babysitting에서 Autonomy로 옮기는 방법으로 Goal, Loop, Schedule을 소개했습니다.

Goal: 명확하고 측정 가능한 종료 상태까지 실행한다
Loop: 정지 조건이나 시간 제한까지 처리를 반복한다
Schedule: 성공한 처리를 정기적으로, 또는 이벤트를 계기로 실행한다

예를 들어 "실패하고 있는 테스트를 전부 통과시킨다"는 Goal, "큐에서 태스크를 가져와 순서대로 구현한다"는 Loop입니다.

다만 단순히 "완료할 때까지 열심히 해"라고 지시하는 것만으로는 안정되지 않습니다. 실행 대상, 성공 조건, 대상 외, 필수 검증, 인간을 다시 불러야 하는 조건까지 정의해야 합니다.

특히 완료 조건이나 검증은 결정론적으로 구현해 둬야 합니다. 예를 들어 lint, typecheck, test 등을 Hooks로 구현하거나 코드베이스의 검증 게이트를 준비합니다. Hooks에서의 검증은 이미 하고 있는 분도 많을 겁니다.

이 세션에서는 다른 프로바이더(Codex)의 에이전트에게 리뷰시키는 방법도 소개했습니다. 이건 바로 도입할 수 있으니 해봐야 합니다.

크로스 프로바이더 리뷰를 실제로 붙일 때

같은 모델에게 자기가 쓴 코드를 리뷰시키면 self-preference 편향이 그대로 걸립니다(1부의 LLM as a Judge 편향과 같은 문제입니다). 그래서 작성과 리뷰를 다른 프로바이더로 가르는 게 유효합니다. 실무에서 붙이는 지점은 보통 CI입니다. GitHub Actions의 pull_request 트리거에서 작성 쪽과 다른 CLI를 헤드리스로 돌려 리뷰 코멘트를 남기는 형태가 가장 손이 덜 갑니다. 다만 국내 기업 환경에서는 두 프로바이더 모두에 대해 소스 코드 외부 전송 승인을 따로 받아야 하는 경우가 많으니 PoC 전에 보안 검토 트랙을 먼저 열어두는 편이 빠릅니다.

Loop Engineering의 목표는 에이전트를 오래 움직이게 하는 데 있지 않습니다. 완료 조건과 검증 경로를 명확히 해서 인간이 일일이 지시하지 않아도 작업이 이어지는 구조를 만드는 일입니다.

이런 Loop를 여러 개 병행해서 돌리면 다음 질문은 개인이나 팀이 에이전트를 어떻게 관리하는가입니다. 이 점도 AIE WF에서 다뤄졌으므로 3부에서 소개하겠습니다.

4. 정리

2026년의 에이전트 개발은 Context Engineering, Harness Engineering, Loop Engineering으로 레이어마다 고도화되고 있습니다. 이미 "MCP로 Tool을 연결한다" 수준의 이야기는 당연한 존재입니다.

앞으로는 조직의 지식을 여러 소스에서 최적의 입도(granularity)로 Context Window에 넣고, Harness로 권한·상태·실행 경계를 제어하고, Loop로 장기 태스크를 인간의 의도로 수렴시키는 설계가 중요해집니다.

경쟁력은 단순히 강한 모델을 쓸 수 있는가로 갈리지 않습니다. 에이전트가 쓰는 지식, 행동, 지속적인 실행을 조직으로서 어디까지 설계·개선할 수 있는가에서 갈립니다.

여러 Loop를 병행해서 돌리게 되면 다음에 묻게 되는 것은 개인이나 팀의 일하는 방식입니다. 이 점은 3부에서 AI-Native Software Development로 정리하겠습니다.

3부. AI-Native Software Development — 개인과 팀의 개발 방식은 어떻게 바뀌는가

1부와 2부에서는 AIE WF에서 들은 내용을 바탕으로 Evals와 Context / Harness / Loop Engineering을 정리했습니다.

3부에서는 개발 프로세스 전체에 좀 더 초점을 맞춰 AI-Native Software Development를 생각해 봅니다.

AIE WF에서 들은 세션을 바탕으로 다음 물음을 따라가 보겠습니다.

AI 에이전트로 개인과 팀의 개발 방법은 어떻게 바뀌는가

1. 구현이 빨라져도 개발 전체가 빨라진다고는 할 수 없다

에이전트가 가장 크게 바꿔 놓는 건 소프트웨어 개발의 구현 비용입니다.

Matt Dailey 씨는 세션에서 기존 개발 프로세스와 AI를 전제로 한 개발 프로세스를 나란히 놓고 비교했습니다. 결론은 Plan의 중요성이 더 커진다는 것이었습니다.

기존 개발 프로세스는 크게 나누면 이렇습니다.

Plan: 인간이 요건이나 설계를 생각한다
  ↓
Implement: 코드 구현
  ↓
Polish: 리뷰·테스트

에이전트를 전제로 하면 이 형태는 다음과 같이 바뀝니다.

Plan
  ↓
Agent Implement
  ↓
Polish

구현의 대부분을 에이전트가 담당하면서 인간의 일은 앞뒤로 나뉩니다.

전반부에서는 무엇을 만들 것인가, 어떻게 만들 것인가를 생각합니다. 후반부에서는 에이전트가 만든 것이 정말 의도한 것인지 확인하고 필요에 따라 수정합니다.

세션에서는 전반부의 계획과 의사결정을 맡는 Plan 영역을 Decision Layer라고 불렀습니다.

에이전트 시대의 개발에서는 코드를 쓰는 속도보다 의사결정의 속도와 품질이 중요해집니다.

1.1 Code Velocity에서 Idea Velocity로

Ref.의 Matt Dailey 씨는 이런 상태를 Velocity Sickness라고 불렀습니다. 에이전트 때문에 생성량만 늘어나는데 정작 팀이나 이용자는 그걸 소화하지 못하는 상황입니다.

구현이 빨라진 탓에 구현하는 것 자체가 목적이 됩니다.

구현량이 늘어난다
  ↓
만든 것을 내보내고 싶어진다
  ↓
리뷰나 검증이 따라가지 못한다
  ↓
이용되지 않는 기능이나 기술 부채가 늘어난다
  ↓
더 빨리 만들어야 한다고 느낀다

세션은 여기에 대한 답으로 Code Velocity에서 Idea Velocity로 옮겨 가자고 제안했습니다.

Code Velocity to Idea Velocity

에이전트가 있다고 바로 구현에 들어가지 않습니다. 여러 선택지를 조사하고 비교해서 만들 가치가 있는 것만 고릅니다.

계획해 본 결과 구현하지 않기로 결론이 나도 정상입니다.

오히려 그쪽이 에이전트가 가져오는 큰 생산성 향상이라는 주장인데 저 자신도 공감되는 부분이 많았습니다. 낮은 비용으로 여러 안을 검토하고 가치가 낮은 안은 구현에 들어가기 전에 버린다는 겁니다.

에이전트의 가치는 코드를 대량으로 찍어내는 데 그치지 않습니다. 구현 비용이 높아 여태 비교조차 못 했던 선택지까지 검토해서 더 나은 결정을 내리는 데도 있습니다.

1.2 Docs, Not Chat

Matt Dailey 씨는 Plan에 관해 조금 더 구체적인 방법론도 소개했습니다.

핵심은 공유 가능한 문서를 Decision Layer 한가운데 두라는 겁니다. 그래서 에이전트=Action, 문서=State라고 표현했습니다.

Docs, Not Chat

다만 이 "문서"란 Plan-Mode나 완전한 스펙 주도 개발(spec-driven development)을 말하는 게 아닙니다.

더 코어한 의사결정이나 요건의 레이어입니다. 예를 들어 구현 전에 다음 내용을 문서로 정리합니다.

해결하고 싶은 과제, 현재 시스템 구성
채택할 설계, 비교한 선택지, 채택하지 않은 이유
태스크의 스코프, 미해결 논점, 완료 후에 확인할 것

이 문서를 관리하면

구현에 들어가기 전에 팀에서 미리 리뷰한다
이른 단계에서 구현 방향을 하나로 맞춘다
같은 문서를 기점으로 작업을 재개한다
중요한 판단은 인간이 쥔다

같은 장점이 있습니다.

일상적으로 코딩 에이전트를 쓰는 엔지니어라면 많은 분이 공감할 이야기일 것입니다.

저 자신도 요건 정리 자료, Design Doc / ADR, 코딩 가이드라인(명명 규칙, 모듈 책무, 아키텍처 등)을 리포지토리 안에 MD로 관리하면서 에이전트가 짜는 코드를 제어합니다.

그렇다고는 해도 무엇을 관리하고 무엇을 리뷰할지는 팀의 룰이나 만드는 대상에 따라 달라집니다. 그 부분은 팀에서 의사결정해서 통일하는 게 좋습니다.

코드베이스를 이해한 상태에서 사람이 판단해야 할 중요한 논점만 공유 문서로 세션 밖에 꺼내 놓으면 됩니다.

Decision Layer 문서를 실제로 어디에 둘 것인가 발표자료에서는 "리포지토리 안에 MD로 관리한다"까지만 말하는데, 실무에서는 배치 규칙을 정해두지 않으면 문서가 흩어져서 에이전트도 사람도 못 찾습니다. 지금 굳어지고 있는 관례는 대략 세 층입니다. 에이전트가 매번 읽는 상시 규칙(명명 규칙, 모듈 책무, 금지 사항)은 리포지토리 루트의 AGENTS.md 또는 CLAUDE.md에 둡니다. 한 번 정하면 오래 가는 설계 판단은 docs/adr/NNNN-*.md 형태의 ADR로 남기고, 이번 작업 한정인 요건·스코프·미해결 논점은 docs/plan/ 아래 티켓 번호를 붙여 둔 뒤 머지 시점에 정리합니다. 핵심은 "에이전트가 항상 읽을 것"과 "사람이 나중에 찾아볼 것"을 물리적으로 분리하는 데 있습니다. 전자를 늘리면 Context를 압박하고, 후자를 상시 규칙에 섞으면 에이전트가 오래된 결정을 현재 규칙으로 착각합니다.

2. 개인의 개발은 "구현"에서 "여러 목표의 관리"로 바뀐다

WorkOS 워크숍의 발표자는 평소 코딩 에이전트 세션을 8~12개 정도 동시에 돌리고 있었습니다. 각각의 변경을 Git worktree로 분리하고 tmux나 세션 요약을 써서 상태를 관리합니다.

Conductor 세션에서도 여러 코딩 에이전트를 한 화면에서 관리하는 워크플로를 보여 줬습니다.

다만 에이전트를 몇 개 돌릴 수 있는가 자체에는 그다지 의미가 없다고 생각합니다.

에이전트를 몇 대 띄우느냐는 핵심이 아닙니다. 독립적으로 굴러가는 일을 찾아 확인 가능한 단위로 맡기면 됩니다.

2.1 재현 가능한 목표와 검증 방법을 설정한다

WorkOS 워크숍에서는 Goal, Loop, Schedule을 제시했습니다. 에이전트를 일일이 들여다보는 Babysitting에서 Autonomy로 넘어가는 방법입니다.

Goal: 명확한 종료 상태까지 실행한다
Loop: 정지 조건까지 같은 처리를 반복한다
Schedule: 성공한 처리를 정기적으로 실행한다

Hook, Goal, Loop, Schedule

어느 경우든 에이전트가 스스로 "완료했습니다"라고 신고하는 것만으로는 부족합니다. 완료 판정은 외부에서 확인 가능한 방법으로 내려야 합니다.

구체적인 예로는 다음 Verification Gate를 들었습니다.

lint, typecheck, test를 Hook으로 실행한다
다른 프로바이더의 모델에서 Second Opinion을 얻는다

다른 모델로 리뷰를 돌리는 방식은 OpenAI의 또 다른 세션에서도 나왔습니다. Claude Code의 Codex 플러그인이 그 예입니다.

물론 다른 모델의 평가라고 늘 옳은 건 아닙니다. 인간의 리뷰를 대신할 수단이라기보다 검증 수단을 하나 더 늘리는 장치로 보는 편이 적절합니다.

이 세션의 요점은 목표 설정 쪽에 있다고 생각합니다. 구현 절차를 세세하게 지시하는 대신 다른 사람이든 에이전트든 달성 여부를 판정할 목표를 세우라는 겁니다.

2.2 AI-Native한 개발을 진행하는 6가지 원칙

Conductor 세션에서는 AI-Native한 개발을 진행하기 위한 6가지 원칙을 소개했습니다. 많은 코딩 에이전트 이용자를 관찰하면서 보이기 시작한 원칙들입니다.

Stay near the frontier: 새로운 모델이나 워크플로를 이른 단계에서 시험하고, 무엇이 가능해졌는지를 지속적으로 파악한다
Don't try to beat the market: 독자적인 개발 환경을 과도하게 짜 넣지 않는다
Create slop-free zones: 모든 변경을 같은 기준으로 다루지 않고, 인간이 엄격하게 리뷰할 영역을 정한다
Feed the beast: Slack, 회의, 문서 등 조직 내 정보를 에이전트가 이용할 수 있는 상태로 만든다
Free-range agents: 에이전트를 개인 PC에 가두지 않고, 격리된 클라우드 환경에서 실행한다
Orchestras, not factories: 에이전트에 대량의 태스크를 투입하는 Software Factory가 아니라, 인간이 방향을 정하고 인간과 에이전트를 협조시키는 Orchestra를 목표로 한다

이것들은 확립된 유일한 개발 방법이라기보다 현재의 선진적인 이용자에게서 보이기 시작한 하나의 방향성입니다.

특히 Git worktree나 전용 UI, 클라우드에서 에이전트를 돌리는 방식 같은 구체적인 수단은 모델과 코딩 에이전트가 진화하면 바뀔 수 있습니다.

그래도 문제의식 자체에는 공감합니다. 최신 능력을 계속 시험해 보면서 직접 만들 범위를 좁히고 인간이 품질을 담보할 영역을 분명히 해 두자는 이야기니까요.

특정 워크플로를 정답으로 못 박기보다 자신들의 개발에 필요한 부분을 가려내서 시험해 보는 게 중요합니다.

Free-range agents는 국내에서 가장 먼저 막히는 항목 6가지 원칙 중 국내 조직이 그대로 따라 하기 가장 어려운 게 Free-range agents입니다. 에이전트를 격리된 클라우드에서 돌린다는 건 사내 소스가 외부 실행 환경에 올라간다는 뜻이라, 망분리 대상이거나 고객사 소스를 다루는 SI·금융권에서는 보안 심의부터 걸립니다. 현실적인 절충안은 두 가지입니다. 하나는 실행 환경을 사내에 두는 것 — 자체 호스팅 러너(GitHub Actions self-hosted runner 등)에 컨테이너를 띄우고 에이전트를 그 안에서만 돌리면 "격리"와 "사외 반출 없음"을 동시에 만족합니다. 다른 하나는 대상 리포지토리를 등급으로 나누는 것 — 내부 도구·문서·PoC 리포지토리부터 클라우드 실행을 허용하고, 고객 데이터나 핵심 로직이 든 리포지토리는 로컬 실행으로 남깁니다. 원칙 자체를 버릴 필요는 없고, 적용 범위를 등급으로 자르면 됩니다.

2.3 작게 시작해서 단계적으로 자율성을 올린다

WorkOS 워크숍은 처음부터 에이전트를 무인으로 돌리지 않았습니다. 사람이 함께 붙어 성공시킨 처리를 단계적으로 자동화했습니다.

예를 들어 우선 여러 체크를 전부 통과시키는 것을 Goal로 삼아 코드를 수정합니다. 그 후 같은 체크와 수정을 Loop로 실행하고 안정적으로 동작하는 것을 확인하고 나서 Schedule을 통한 정기 실행으로 옮깁니다.

리포팅 처리도 마찬가지였습니다. 먼저 사람과의 세션 안에서 동작시켜 보고 그다음 매일 실행하는 Schedule로 넘겼습니다.

인간과 함께 실행한다
  ↓
Goal로서 완료를 확인한다
  ↓
Loop로서 반복한다
  ↓
Schedule로서 정기 실행한다

Goal, Loop, Schedule이라는 구체적인 분류는 앞으로 다른 형태로 바뀔 수도 있습니다. 적어도 아래 방침은 다른 세션을 포함해 공통이었던 것 같습니다.

결과를 명확히 확인할 수 있는 일부터 시작한다
가능한 부분은 코드로 검증한다
한 번 성공시키고 나서 자율성을 올린다
판단할 수 없는 경우는 인간에게 되돌린다

lint나 test를 통과시키는 것 자체는 기존 개발에서도 당연합니다.

하지만 에이전트에게 일을 맡길수록 그 당연한 것을 대화로 지시하는 선에서 끝내면 안 됩니다. 회피할 수 없는 검증 경로로 설계해 두는 쪽이 중요해집니다.

개인이 여러 에이전트를 쓰기만 하는 거라면 Git worktree나 터미널에서의 관리로도 성립합니다.

그런데 관계된 사람이 늘어나면 목표와 진척, 산출물이 개인 PC나 Chat 안에 갇혀 있다는 게 다음 과제로 떠오릅니다. 그래서 에이전트와의 작업을 팀 전체가 공유하는 "Multiplayer한" 개발 환경이 필요해집니다.

3. 팀 개발은 "개인의 에이전트"에서 "Multiplayer"로 바뀐다

앞 절에서 본 대로 개인이 여러 에이전트를 쓰는 수준이라면 Git worktree나 터미널 관리로도 성립합니다.

하지만 팀 단위로 쓰기 시작하면 에이전트가 개인 PC나 Chat에 갇혀 있다는 점이 문제가 됩니다.

다른 멤버가 작업 상황을 파악할 수 없다
작업을 시작한 사람만 추가 지시를 내릴 수 있다
Slack, GitHub, 개발 환경 사이에서 문맥이 분단된다
담당자가 자리를 비우면 작업을 인계할 수 없다

Superconductor 세션은 여기서 Multiplayer agentic engineering으로 옮겨 가자고 제안했습니다. 여러 인간과 에이전트가 같은 작업에 함께 붙는 방식입니다.

3.1 에이전트의 세션을 팀의 공유 작업으로 만든다

세션에서는 Slack, 데스크톱 앱, GitHub 어디서든 같은 에이전트 세션에 접근하는 구조를 보여 줬습니다.

Make agent work visible and collaborative across the team

예를 들어 고객 지원 담당자가 Slack에서 버그를 보고하면 에이전트가 조사를 시작합니다. 그 후 엔지니어가 도중에 참가해서 구현 방침을 수정하고 최종 변경분을 GitHub에서 리뷰합니다.

이때 팀이 모든 Tool Call이나 긴 대화 이력까지 따라갈 필요는 없습니다. 확인할 건 이 정도입니다.

무엇을 목적으로 하는가
누가 작업을 시작했는가
현재 어디까지 진행되었는가
어떤 산출물이 생성되었는가
누가 방향 수정이나 리뷰를 했는가

세션에서는 코드뿐 아니라 스크린샷이나 동영상 같은 산출물까지 같은 작업 공간에서 공유하는 예를 들었습니다.

Conductor 세션에서도 데모를 보여 줬습니다. 클라우드 워크스페이스를 여러 명이 함께 들여다보고 다른 멤버가 돌리고 있는 에이전트의 작업에 참가하는 모습이었습니다.

구체적인 UI나 구현 방법은 앞으로 바뀌겠지만 에이전트의 작업을 개인 채팅에서 꺼내 팀이 함께 붙을 수 있는 공유 작업으로 다루는 방향성은 중요하다고 느꼈습니다.

3.2 조직 내의 시그널을 확인 가능한 산출물로 변환한다

Superconductor 세션은 Slack, 사내 회의, 고객과의 대화, 버그 트래커 같은 정보를 에이전트에게 넘기는 예도 보여 줬습니다. 그 결과물이 티켓, 프로토타입, Pull Request입니다.

Turn every external signal into code your team can quickly evaluate

예를 들어 회의 Bot이 논의에서 아이디어를 추출하고, 기존 작업과의 중복을 확인한 다음 티켓을 만들고, 에이전트가 구현을 시작합니다.

이렇게 되면 지원이나 영업 같은 비엔지니어도 코드를 쓰지 않고 프로덕트 개발에 참가할 여지가 생깁니다.

다만 회의 중에 나온 아이디어나 고객 요청을 그대로 프로덕션 코드로 변환하는 것은 위험합니다.

현실적으로는 이런 흐름으로 보는 게 좋습니다.

고객 요청·회의·Slack
  ↓
과제 후보를 추출
  ↓
에이전트가 조사·프로토타입을 작성
  ↓
인간이 가치와 방향성을 판단
  ↓
본 구현·리뷰

에이전트의 역할은 조직 내의 모든 발언을 자동으로 구현하는 데 있지 않습니다. 애매한 요청을 팀이 평가할 수 있는 구체적인 산출물로 바꿔 놓는 데 있습니다.

어떤 정보를 입력으로 이용할 것인가, 누가 작업을 시작할 수 있는가, 어디까지 자동으로 진행할 것인가는 조직이나 프로덕트에 따라 다릅니다.

이번에 소개된 공유 세션이나 회의 Bot도 현시점에서의 구현안 중 하나입니다.

이런 문제의식에는 저도 공감합니다. 에이전트가 개인의 생산성 향상에 그치지 않고 조직의 정보와 개발 프로세스를 접속하는 존재로 바뀌고 있다는 겁니다.

팀 전체가 에이전트를 쓸 생각이라면 모델의 성능만 볼 게 아니라 목표와 진척, 산출물, 인간의 판단을 어떻게 공유할지까지 설계해야 합니다.

4. 에이전트에게 구현을 맡겨도 인간의 품질 책임은 남는다

여기까지 개인이나 팀이 여러 에이전트와 개발하는 방법을 봐 왔습니다.

그런데 에이전트가 생성하는 코드가 늘어날수록 최종적인 품질은 누가 담보하느냐는 문제가 남습니다.

구현은 물론 리뷰까지 에이전트에게 맡기고 인간이 코드를 읽지 않는 "Software Factory"를 목표로 하는 사고방식도 있습니다. 하지만 AIE WF의 세션에서는 현재의 모델로 거기까지 자동화하는 데 신중한 의견이 많았습니다.

4.1 코딩 에이전트가 담당할 수 있는 변경은 넓어지고 있다

Wisedocs 세션은 10개 이상의 레거시 리포지토리를 모노레포로 재구축한 프로젝트를 소재로 삼았습니다. 당시 사용한 모델과 현재의 모델에 같은 리팩터링 태스크를 던져 비교했습니다.

당시의 o3는 3시간 넘게 주고받고도 사람이 코드를 손봐야 했다고 합니다.

o3로는 잘 되지 않았다

현재의 모델은 같은 태스크를 20~25분 정도에 거의 끝냈습니다. 단순히 코드를 생성한 게 아니라 Plan, Shell, SubAgent, Test 등을 쓰면서 자율적으로 조사와 검증을 진행했다는 점도 큰 차이입니다.

예전에는 여러 명이서 약 2개월 걸리던 라이브러리 선정이나 PoC 작성도 마찬가지입니다. 지금은 Deep Research, 후보별 SubAgent, PoC 생성을 조합하면 기간이 크게 줄어든다고 설명했습니다.

물론 이것은 Wisedocs의 특정 코드베이스와 태스크를 사용한 사례이므로 모델 전반의 성능을 나타내는 일반적인 벤치마크는 아닙니다.

그래도 코딩 에이전트가 담당하는 일의 범위는 분명히 넓어졌습니다. 부분적인 코드 생성에 그치던 것이 조사와 계획, 구현, 검증까지 포함하는 긴 태스크로 옮겨 갔습니다.

다만 리팩터링 전체를 GPT-5.5 X-High에 한 번에 맡긴 실험은 달랐습니다. 만들어진 것이 주로 Scaffolding이었고 필요한 모델이나 배포 처리까지는 구현되지 않았습니다.

모델과 Harness가 급속히 진화하고 있긴 하지만 반년 규모의 재구축을 한 번에 맡겨 자기 검증까지 포함해 완료하는 단계는 아직 아닙니다.

4.2 테스트가 통과하는 것과 유지보수가 가능한 것은 별개

HumanLayer 세션의 주장은 이렇습니다. 현재의 모델은 개별 태스크를 완료하고 테스트를 통과시키는 데는 강하지만 코드베이스의 유지보수성을 장기적으로 지켜내는 일에는 약하다는 겁니다.

이유 중 하나는 문제가 표면화되기까지의 시간입니다.

테스트 실패
  → 구현 직후에 검출할 수 있다

나쁜 설계나 기술 부채
  → 몇 주·몇 개월 후의 변경에서 문제가 된다

일반적인 코딩 벤치마크는 지정된 문제를 해결하고 기존 테스트와 추가 테스트를 통과하면 성공으로 판정합니다.

하지만 그 변경으로 의존 관계가 복잡해지거나, 중복 코드가 늘어나거나, 장래의 변경이 어려워져도 단기적인 평가에는 나타나지 않습니다.

Wisedocs 세션에서도 레거시 코드와 바이브 코딩의 공통점을 짚었습니다.

중복된 코드가 늘어난다
성능이나 품질이 낮다
구현의 배경을 아무도 이해하지 못한다

에이전트로 리팩터링이 쉬워졌다고 기술 부채를 방치해도 되는 건 아닙니다. Wisedocs는 모델의 진화를 기다리는 대신 당시 6개월을 들여 재구축했고 그 판단이 타당했다고 결론지었습니다. 실제로 그 후의 개발 속도와 처리 성능, 비용이 개선됐기 때문입니다.

즉 에이전트가 코드를 빠르게 생성하는 것과 장기적으로 변경하기 쉬운 코드베이스를 만드는 것은 별개의 문제입니다.

4.3 상류에서 합의하고 리뷰 가능한 단위로 나눈다

HumanLayer 세션은 복잡한 변경일수록 리뷰하기 쉬운 형태로 만드는 게 중요하다고 설명했습니다. 인간의 리뷰를 없애자는 얘기가 아닙니다.

optimizing the lights-on software factory

이 그림에서 인상적이었던 대목은 이렇습니다. PRODUCT / ARCHITECTURE / PROGRAM DESIGN / VERTICAL SLICES 같은 상류의 정리에 30분을 들이면 그 후의 코드 리뷰나 재작업(rework)에 걸리는 몇 시간이 절약된다고 정리했습니다.

에이전트에게 구현을 맡기면 AGENT BUILDS THE THING 부분은 확실히 빨라집니다.

문제는 그 전 단계입니다. 과제 설정이나 설계가 애매한 채로 넘어가면 Pull Request 리뷰나 회귀 테스트, 사람이 확인하는 부담이 그대로 늘어나 버립니다.

세션이 제안한 흐름은 이렇습니다.

Product Review: 해결할 과제와 기대하는 동작을 확인한다
  ↓
Architecture: 컴포넌트, 데이터 모델, 외부 연동을 설계한다
  ↓
Program Design: 타입, 메서드, 모듈, 호출 관계를 정리한다
  ↓
Vertical Slices: 동작 확인 가능한 작은 구현 단위로 분할한다
  ↓
Agent Implementation: 합의한 설계에 따라 에이전트가 구현한다
  ↓
Agentic Code Review / Regression Testing: 에이전트가 리뷰와 회귀 테스트를 수행한다
  ↓
Human Code Review: 인간이 설계와의 정합성과 최종 품질을 확인한다

물론 모든 변경을 이렇게 무거운 설계 프로세스에 태우라는 얘기는 아닙니다.

작고 영향 범위가 한정된 변경이라면 그대로 에이전트에게 맡겨도 됩니다.

대신 데이터 모델, 외부 연동, 모듈 경계처럼 나중에 효과가 나타나는 논점은 구현 전에 인간이 맞춰 두는 편이 좋다는 주장입니다.

이것은 3부 1장에서 본 Decision Layer 이야기와도 이어집니다.

중요한 의사결정을 먼저 공유 문서로 꺼내 놓고 그 내용을 바탕으로 변경을 Vertical Slice로 나눕니다. 그러면 에이전트가 만드는 변경을 인간이 리뷰 가능한 단위로 유지하기 쉬워집니다.

물론 어디까지 사전에 정해야 할지는 팀이나 프로덕트에 따라 다릅니다.

인간 리뷰를 병목으로 보고 깎아내기보다 리뷰하기 쉬운 변경을 만드는 방향으로 전 공정을 강화한다는 사고방식이었습니다. 현시점에서는 꽤 실무적이라고 느꼈습니다.

5. 정리

여기까지가 AIE WF에서 얻은 배움을 정리하는 3부 구성의 마지막입니다.

지금까지 AI 에이전트 개발을 3가지 관점에서 정리해 왔습니다.

Evals: 실패를 관측하고, 평가하고, 개선으로 연결한다
Context / Harness / Loop Engineering: 필요한 지식을 넘기고, 실행 범위를 제어하고, 장기 태스크를 목표로 수렴시킨다
AI-Native Software Development: 에이전트를 전제로 개인과 팀의 개발 방법을 재설계한다

세 가지는 따로 노는 테마가 아닙니다. SDLC라는 루프 안에서 서로 교차하는 구성 요소입니다.

인간이 과제와 중요한 판단을 정의한다
  ↓
Context / Harness / Loop로 에이전트를 움직인다
  ↓
Trace와 Evals로 성과를 검증한다
  ↓
인간과 팀이 판단하고 다음 개선으로 연결한다

구체적인 툴이나 워크플로는 앞으로도 크게 바뀔 거라고 생각합니다.

다음 방향성만큼은 당분간 그대로일 것 같습니다.

에이전트의 자기 신고가 아니라 외부에서 검증 가능하게 한다
중요한 의사결정을 개인의 채팅에 가두지 않는다
작고 확인 가능한 단위부터 자율성을 올린다
구현량이 아니라 사용자에게 전달하는 가치를 최적화한다
최종적인 품질과 방향성에는 인간이 책임을 진다

AI-Native Software Development란 단순히 에이전트에게 코드를 쓰게 하는 것이 아닙니다.

인간이 판단하고, 에이전트가 실행하고, 시스템이 검증하고, 팀이 학습하는 개발 프로세스를 만드는 것입니다.

마치며

이번에 이런 귀중한 기회를 마련해 준 회사와, 참가를 뒷받침해 주신 분들께 감사드립니다. 현지에서 많은 실천 사례와 논의를 접하면서 엔지니어로서 크게 성장할 수 있었습니다.

AI의 진화로 모델의 성능뿐 아니라 Context, Harness, Evals, 개발 프로세스, 조직의 형태까지 짧은 기간에 계속 바뀌고 있습니다. 이번에 소개한 방법론도 완성형이 아니라 몇 개월 후에는 다른 형태로 바뀌어 있을지도 모릅니다.

그래도 에이전트에게 무엇을 맡기고, 어떻게 검증하고, 인간이 어디서 판단과 책임을 가질 것인가라는 물음은 앞으로 더 중요해질 것입니다.

앞으로도 계속 진화하는 AI와, 그것을 실제 가치로 연결하는 엔지니어링의 변화에 주목하면서 우리의 개발에 받아들여 가고 싶습니다.

이 문서의 구성

목차

1부. 에이전트의 실패를 관측하고, 평가하고, 개선으로 연결한다 — Evals and Agent Improvement

1. 에이전트는 "동작했다"만으로는 부족하다

1.1 Evals도 얼마든지 거짓말을 한다

1.2 작게 시작한다: LLM as a Judge에 곧바로 뛰어들지 않는다

2. Trace: 에이전트의 실패를 관측한다

3. Evals: 싸게 지킬 수 있는 것부터, 의미적 품질로

3.1 Code-Based Eval: 결정적으로 판정할 수 있는 것을 지킨다

3.2 LLM as a Judge: 의미적 품질을 본다

3.3 Meta Evaluation: Judge 자체를 의심한다

4. Trace Mining과 Auto Improvement

4.1 Trace는 개선 데이터가 된다

4.2 평가 결과를 개선 실험으로 연결한다

4.3 Auto Improvement는 출발점이 아니라 도달점

5. 정리

2부. Context / Harness / Loop Engineering — 에이전트 시스템의 설계 레이어

1. Context Engineering의 현재 위치

1.1 MCP는 Context의 입구일 뿐, Context Engine이 아니다

1.2 Skills / Playbook으로 Context를 운용한다

1.3 "정보 접근"을 "쓸 수 있는 Context"로 바꾸는 Context Engine

1.4 Context Engineering은 A2A로 확장된다

2. Harness Engineering: Context만으로는 에이전트가 안전하게 움직이지 않는다

2.1 5가지 장애 사례로 배우는 Harness Engineering

2.2 Codex로 보는 Harness의 구현 책무

3. Loop Engineering: 장기 태스크를 제어 가능하게 만든다

3.1 Loop를 Control Theory로 설계한다

3.2 Loop를 키우기 위한 Human on the Loop

3.3 Goal / Loop / Schedule로 Babysitting에서 Autonomy로

4. 정리

3부. AI-Native Software Development — 개인과 팀의 개발 방식은 어떻게 바뀌는가

1. 구현이 빨라져도 개발 전체가 빨라진다고는 할 수 없다

1.1 Code Velocity에서 Idea Velocity로

1.2 Docs, Not Chat

2. 개인의 개발은 "구현"에서 "여러 목표의 관리"로 바뀐다

2.1 재현 가능한 목표와 검증 방법을 설정한다

2.2 AI-Native한 개발을 진행하는 6가지 원칙

2.3 작게 시작해서 단계적으로 자율성을 올린다

3. 팀 개발은 "개인의 에이전트"에서 "Multiplayer"로 바뀐다

3.1 에이전트의 세션을 팀의 공유 작업으로 만든다

3.2 조직 내의 시그널을 확인 가능한 산출물로 변환한다

4. 에이전트에게 구현을 맡겨도 인간의 품질 책임은 남는다

4.1 코딩 에이전트가 담당할 수 있는 변경은 넓어지고 있다

4.2 테스트가 통과하는 것과 유지보수가 가능한 것은 별개

4.3 상류에서 합의하고 리뷰 가능한 단위로 나눈다

5. 정리

마치며

관련 글

Claude Code 도입, 잘되는 회사와 안 되는 회사는 무엇이 다른가

MCP가 '당연한 것'이 된 2026년, 개인의 업무 연결은 어디까지 자동화할 수 있을까

Claude 전체 기능 총정리 | 플랜별·Code/Cowork 비교 【2026년 7월판】

댓글 0