Context Engine으로 병합 가능한 코드 생성하기

URL: https://www.youtube.com/watch?v=qdAkxLoYNI8
날짜: 2026-08-28
원본 발행일: 2026-08-27
채널: aiDotEngineer
발표자: Peter Werry
소속: Unblocked

📌 핵심 질문 / Context Engine이 병합 가능한 코드를 만드는 방식

==정보에 접근할 수 있다는 것(access to information)은 조직의 이해(understanding)와 같지 않다. Context Engine은 코드, 과거 결정, 팀 관례, Slack 논의, 아키텍처 근거를 현재 작업에 맞게 연결해 에이전트가 처음부터 다시 발견하지 않도록 만든다.==

• 에이전트는 새 작업을 시작할 때마다 지식을 초기화하는 신입 엔지니어처럼 코드베이스와 조직의 작업 방식을 다시 찾아야 한다.
• 위키나 백만 토큰 컨텍스트 창에 정보를 모두 넣는 방식은 필요한 정보의 위치와 관계를 알려주지 못하고, 작업과 무관한 정보로 에이전트를 산만하게 만든다.
• Context Engine은 관련 출처를 함께 제시해 인간이 답을 검증하고, Claude Code 같은 에이전트가 정확한 다음 단계로 이동하도록 한다.

핵심 가치는 짧은 작업 하나의 초기 토큰 비용을 줄이는 데만 있지 않다. 잘못된 가정과 잘못된 계획이 뒤 단계의 재탐색·재실행 루프를 일으키는 것을 막아 전체 실행 과정의 비용과 시간을 누적해서 낮추는 데 있다.

1. 에이전트 시대에 다시 정의되는 조직 컨텍스트

사람과 에이전트 모두에게 조직 컨텍스트(organizational context)를 전달해야 코드 작업이 실제 조직의 방식과 맞아진다.

1.1. 에이전트 이전의 인간은 컨텍스트 레이어였다

1. 사람이 직접 조립하던 지식

   1. 분산된 정보 탐색: 필요한 대상을 찾기 위해 서로 다른 데이터 소스와 그 안에서 진행된 논의를 샅샅이 뒤지고, 코드베이스를 따라가며 정보를 연결했다.
   2. 암묵지(tribal knowledge) 형성: 코드가 발전하는 동안 왜 그런 구조가 되었는지, 조직이 어떻게 빌드·테스트·배포하는지에 관한 맥락을 사람이 기억 속에 쌓았다.

2. 운영 경험이 남긴 조직의 흔적

   1. 배틀 스카(battle scars): 인시던트와 장애를 처리하면서 조직은 무엇이 깨졌고 어떻게 대응했는지에 대한 경험을 축적했다.
   2. 문서화된 결과: 코드 작성, 아키텍처 문서화, 장애 대응이 반복되며 현재의 규칙과 설계 근거가 만들어졌다.

1.2. 에이전트는 매 작업마다 첫 출근하는 전문가다

1. 새 직원 비유

   1. 전문가이지만 조직에는 처음이다: 에이전트는 유능한 소프트웨어 엔지니어가 처음 온 신입 직원처럼 보이지만, 새 작업을 시작할 때마다 이전 작업에서 얻은 조직 지식을 초기화한다.
   2. 반복되는 온보딩: 모든 작업에서 코드베이스를 다시 읽고, 조직이 소프트웨어를 빌드하고 테스트하고 배포하는 방식을 재발견해야 한다.

2. 재발견의 구조적 비용

   1. 코드만으로 부족함: 구현은 볼 수 있어도 코드가 그런 선택을 한 의도와 과거의 트레이드오프까지 자연스럽게 복원하지는 못한다.
   2. 작업마다 같은 조직 비용 발생: 사람이 이미 알고 있는 규칙과 장애 경험을 에이전트가 매번 다시 찾으면서, 인간이 컨텍스트 레이어로 맡던 일이 에이전트의 탐색 비용으로 바뀐다.

2. AI 성숙도 곡선과 컨텍스트 병목

에이전트의 자동화 수준이 높아질수록 조직 컨텍스트를 전달하는 능력이 핵심 병목이 된다.

2.1. 자동완성에서 소프트웨어 팩토리까지

1. 초기 단계: 코드 자동완성

   1. GPT-3.5 시대의 자동완성: Copilot 같은 도구는 코드 작성의 다음 토큰을 제안하는 수준에서 출발했다.
   2. Cursor로의 확장: 개발자는 Cursor를 사용하면서 단순 자동완성보다 넓은 작업 단위에서 에이전트와 협력하기 시작했다.

2. 중간 단계: 조직 지식의 구조화

   1. 조직 위키: 팀은 컨텍스트 문제를 해결하기 위해 조직 위키를 만들기 시작했지만, 위키의 존재만으로 에이전트가 필요한 정보의 위치를 알게 되지는 않는다.
   2. MCP와 스킬: 에이전트에 MCP(Model Context Protocol)와 스킬을 주어 컨텍스트를 탐색하고 조립하는 방법을 가르치는 단계가 현재 많은 팀의 위치다.
   3. 성숙도 4~5단계: 사람들은 컨텍스트가 병목이라는 사실을 이해하고 엔지니어링 팀을 위한 해결책을 만들고 있다.

3. 목표 단계: 소프트웨어 팩토리

   1. 성숙도 8단계: 소프트웨어 팩토리는 에이전트가 전체 개발 흐름을 더 많이 자동화하는 방향을 상징한다.
   2. 알려지지 않은 미지(unknown unknowns)의 전달: 자동화가 진행될수록 이미 알고 있는 정보가 아니라 무엇을 찾아야 하는지조차 모르는 영역까지 컨텍스트를 전달해야 한다.
   3. 조직 컨텍스트 없이는 자동화 불가: 에이전트는 조직의 맥락을 얻지 못하면 길을 잃기 때문에 완전 자동화된 운영을 수행할 수 없다.

2.2. 정보 접근과 이해 사이의 간극

1. 위키를 붙이는 것만으로 해결되지 않는 이유

   1. 위치 정보의 부재: claude.md나 위키 레이아웃을 연결해도 현재 작업에 필요한 정보가 어디 있는지와 어떤 순서로 확인해야 하는지를 알려주지 않는다.
   2. 검색과 이해의 차이: 에이전트는 위키에서 그럴듯한 항목을 검색할 수 있지만, 여러 조각이 어떻게 하나의 설계와 작업 계획으로 이어지는지까지 자동으로 정리하지 못한다.

2. 방사선학의 ‘검색 만족(satisfaction of search)’

   1. X선의 사례: 방사선 전문의가 X선에서 암의 징후가 있을 법한 영역을 찾다가 지표 하나를 발견하고 검사를 멈추면, 진단을 바꿀 수 있는 다른 중요한 지표를 놓칠 수 있다.
   2. 에이전트의 조기 종료: 에이전트도 맞다고 생각한 정보 하나를 찾으면 탐색을 멈추며, 그 정보가 실제로는 더 중요한 의존성·결정·제약과 연결되어 있을 수 있다는 사실을 놓친다.

3. 관계와 미래 계획을 증류하지 못하는 문제

   1. 의존성 상호작용: 정보를 둘러보고 찾는 것만으로는 의존성들이 서로 어떻게 상호작용하는지 이해할 수 없다.
   2. 아키텍처와 범위: 현재 아키텍처와 미래 계획이 다음 작업의 범위를 어떻게 제한하는지 파악하려면 탐색 결과를 관계망과 설계 논리로 증류해야 한다.

2.3. 모든 정보를 컨텍스트 창에 넣는 방식의 한계

1. 백만 토큰도 충분하지 않다

   1. 용량의 한계: 조직 컨텍스트는 백만 토큰짜리 컨텍스트 창에도 모두 들어가지 않을 만큼 많다.
   2. 한꺼번에 추론하려는 착각: 코드베이스와 아키텍처 문서를 통째로 넣으면 에이전트가 모든 것을 동시에 추론할 것 같지만 실제 작업은 그렇게 작동하지 않는다.

2. 작업 흐름의 산만함

   1. 작업별 흐름(task-specific flow): 특정 작업에는 그 작업에 필요한 정보가 집중적으로 들어와야 한다.
   2. 토큰과 시간 낭비: 관련 없는 정보가 에이전트의 시선을 이쪽저쪽으로 끌면 불필요한 토큰과 시간이 소모된다.

3. ‘정말 중요한 것’ 찾기

   1. Unknown unknowns의 재표현: Claude Code의 Tariq가 키노트에서 말한 ‘unknown unknowns’는 ‘정말 중요한 것들을 찾는 일’이라고 다시 표현할 수 있다.
   2. 얼음산의 수면 위: 에이전트가 바로 볼 수 있는 것은 코드와 코드에 대한 조작이다.
   3. 얼음산 아래: 실제 의도(intent), 팀 관례(conventions), 과거 결정(past decisions), Slack에서 나눈 논의, 아키텍처의 근거(rationale)는 코드 아래에 숨어 있다.

3. 인간의 검증과 Context Engine의 실제 동작

조직 컨텍스트는 에이전트뿐 아니라 최종 책임을 지는 인간에게도 필요한 형태로 제공되어야 한다.

3.1. Source Mark Engine 질문과 생성된 아키텍처

1. 인간 레이어는 사라지지 않는다

   1. 코드베이스에 대한 인간의 질문: 사람은 여전히 자신의 코드베이스에 관해 질문하고 내부 구성 요소의 동작을 이해해야 한다.
   2. 병합의 책임: PR에서 Merge를 누르는 최종 책임은 인간에게 있으므로, 변경 내용과 아키텍처를 이해하지 않은 채 에이전트의 답을 그대로 승인할 수 없다.

2. Source Mark Engine에 대한 답변

   1. 내부 구성 요소 이해: Unblocked는 시스템의 내부 구성 요소인 Source Mark Engine에 대해 아키텍처를 비교적 정확하게 설명했다.
   2. 존재하지 않던 다이어그램: 화면에 나타난 아키텍처 다이어그램은 미리 작성된 문서가 아니라, 현재 코드의 동작 방식과 미래 아키텍처 제안을 조합해 새로 생성된 것이다.

3. 작업을 보여주는 답변

   1. 검증 가능한 출처: 답변이 어디서 나왔는지 출처를 함께 보여주면 사람이 답이 완전히 정확하지 않은 지점을 찾아 지식 기반을 수정할 수 있다.
   2. 신뢰 형성: 출처 제시는 단순한 기능보다 신뢰를 쌓는 장치이며, 에이전트가 점점 더 이런 검증 과정을 대신 수행할 수 있게 된다.

3.2. Slack의 결정과 실시간 컨텍스트

1. 결정이 만들어지는 장소

   1. Slack의 역할: 많은 설계·운영 결정이 Slack에서 논의되므로, 조직 이해에는 저장된 문서뿐 아니라 대화의 맥락도 필요하다.
   2. 높은 확신의 개입: Unblocked는 답변에 기여할 수 있다고 판단할 때 Slack 대화에 끼어들고, 확신이 낮으면 자동으로 말하지 않는다.

2. 직접 질문과 응답

   1. Unblocked 호출: 자동 개입이 일어나지 않아도 사용자가 Unblocked를 직접 지정해 같은 질문을 할 수 있다.
   2. 통합된 답변: 관련 컨텍스트가 있다고 판단하면 Unblocked는 답변을 제공하고, 코드·문서·대화에 걸친 정보를 한곳에서 확인하게 한다.

4. 같은 최적화 계획에서 드러난 비용 차이

Context Engine의 효과는 단일 탐색 비용보다 뒤따르는 실행 루프에서 크게 나타난다.

4.1. Context 없이 만든 Source Mark Calculator 계획

1. Claude Code의 독립 탐색

   1. 요청: Source Mark Calculator를 최적화할 계획을 Unblocked 없이 Claude Code에 요청했다.
   2. 탐색 방식: Claude Code는 코드베이스를 검색하고 알고리즘이 어떻게 작동하는지 추론해 계획을 만들었다.

2. 그럴듯하지만 놓친 뉘앙스

   1. 기본 품질: 코드 검색과 알고리즘 분석만으로도 꽤 좋은 결론에 도달했다.
   2. 맥락의 누락: 향후 개선 가능성을 논의한 PR, 관련 Slack 대화, Notion과 아키텍처 문서에 있는 조직의 의도까지는 충분히 반영하지 못했다.

4.2. Context를 붙여 만든 계획

1. 관련 출처의 연결

   1. 미래 가능성: Unblocked는 Source Mark Calculator의 미래 개선 가능성을 논의한 PR을 찾아 계획에 반영했다.
   2. 결정의 맥락: Slack 대화, Notion, 아키텍처 문서를 함께 찾아 단순 구현 분석보다 깊은 뉘앙스를 포착했다.

2. Claude가 바로 이어서 작업할 수 있는 형태

   1. 출처 반환: 각 출처는 답변에 함께 반환되며, Claude는 추가 설명이 필요할 때 정확히 어느 곳으로 이동해야 하는지 안다.
   2. 검증과 실행의 연결: 사람이 계획의 근거를 확인할 수 있고, 에이전트는 확인된 맥락을 다음 실행 단계의 입력으로 사용할 수 있다.

4.3. 비용보다 중요한 누적 효과

1. 측정된 단일 작업 차이

   1. Context 사용: Unblocked와 함께 계획을 만드는 데 1분가량 걸렸고 총비용은 1달러 미만이었다.
   2. Context 미사용: Unblocked 없이 수행하면 약 2분이 걸렸고 컨텍스트를 직접 수집하는 비용이 더 컸다.
   3. 벽시계 시간 주의: 화면의 전체 경과 시간은 페이지를 약 한 시간 열어 둔 탓이므로 실제 비교 시간으로 해석하면 안 된다.

2. 탐색량과 정확도의 차이

   1. 더 많은 발견 작업: Context가 없으면 에이전트가 주변을 더 오래 둘러보며 필요한 정보를 직접 찾아야 한다.
   2. 잘못된 발견: 더 큰 문제는 오래 탐색하는 것 자체가 아니라, 올바르지 않은 정보나 불완전한 관계를 발견할 수 있다는 점이다.

3. 잘못된 가정의 루프

   1. 후속 단계의 오염: 잘못된 발견은 실행 후반부를 잘못된 계획과 가정 위에서 진행하게 만든다.
   2. 반복 재실행: 사람과 에이전트는 앞 단계로 돌아가 다시 탐색하고 계획을 고치며 여러 번 루프를 돌아야 한다.
   3. 핵심 가치: Context Engine의 진짜 가치는 짧은 첫 작업의 비용이 아니라 전체 과정에서 루프가 누적되지 않도록 하는 데 있다.
   4. 키노트의 보강: Sonar의 Tariq가 말한 것처럼 루프는 누적되므로, 처음부터 끝까지 효율적인 컨텍스트를 유지해야 한다.

5. 코드 리뷰 에이전트에 조직 지능을 적용하기

조직 컨텍스트는 원천 데이터의 검색을 넘어 팀의 지식과 전문성을 판단하는 지능으로 확장된다.

5.1. 팀의 베스트 프랙티스와 전문성 신호

1. 데이터를 넘어선 조직 지능

   1. PR과 추가 데이터 소스: Unblocked는 Pull Request 데이터를 비롯한 여러 데이터 소스를 살펴본다.
   2. 베스트 프랙티스 합성: 코드베이스에 맞는 베스트 프랙티스(best practices)를 생성해 에이전트가 조직의 방식에 맞춰 움직이도록 한다.

2. 코드 리뷰에 컨텍스트를 노출하기

   1. 리뷰 에이전트 연결: 합성된 베스트 프랙티스를 코드 리뷰 에이전트에도 보여주어, 일반론적 지적보다 팀에 실제로 중요한 리뷰를 우선한다.
   2. Richie의 반응: Unblocked가 제안한 코멘트를 본 선임 엔지니어 Richie는 “멋지다. 내가 할 법한 말이다”라고 반응했다.
   3. 실제 과거 발언: 그 코멘트는 Richie가 실제로 과거에 했던 말이었으며, 시스템이 그의 이전 리뷰 맥락을 다시 끌어올린 결과였다.

3. 전문성에 따른 우선순위

   1. 신호로서의 시니어리티: 팀 구성원의 시니어리티(seniority)와 전문성(expertise)을 중요한 리뷰 코멘트를 부스트하는 신호로 사용한다.
   2. 조직에 맞는 중요도: 모든 코멘트를 같은 무게로 다루지 않고, 특정 영역을 실제로 잘 아는 사람이 강조해 온 지적에 더 높은 가중치를 준다.

5.2. 리뷰 이슈 급감의 원인 추적과 자동 수정

1. 이상 징후 발견

   1. 급격한 감소: Richie는 코드 리뷰에서 드러나는 이슈의 수가 갑자기 급격히 줄어든 사실을 발견했다.
   2. Unblocked와 디버깅: 그는 Unblocked와 함께 원인을 끝까지 추적했고, 대략적인 문제의 원인을 파악한 뒤 수정을 요청했다.

2. 클라우드 에이전트의 내부 실험

   1. 실험 단계: Unblocked가 클라우드에서 에이전트로 실행되는 기능은 당시 내부적으로 실험 중이었다.
   2. 맥락을 손에 쥔 수정: 에이전트가 조직 컨텍스트를 즉시 사용할 수 있으므로 단순한 수정 코드뿐 아니라 수정의 배경까지 연결할 수 있었다.

3. PR과 대화의 연결

   1. 수정 PR 생성: 에이전트는 문제를 고친 PR을 생성했다.
   2. 수정 이유의 복원: PR은 변경 사항만 제시하지 않고, 왜 그 수정이 만들어졌는지 관련 대화와 과거 맥락을 함께 연결했다.
   3. Claude 4.8 전환의 영향: Claude 4.8로 전환한 뒤 리뷰 이슈가 크게 줄었고, Richie는 그 감소가 모델의 동작 차이에서 비롯된 것으로 직접 연관 지었다.
   4. Slack 원문까지 도달: Unblocked는 그 상관관계를 담은 Slack 대화를 찾아 과거 이력을 다시 연결했고, 최종 PR은 그 근거를 포함한 상태가 되었다.

6. 오픈소스 도구로 만드는 조직 컨텍스트

GitHub 기록과 팀의 코드 리뷰 관계를 구조화하면 Context Engine의 기반이 되는 지식망을 직접 탐색할 수 있다.

6.1. Document Query Engine

1. GitHub 기록의 수집

   1. 오픈소스 공개: Document Query Engine은 누구나 내려받아 실행할 수 있는 오픈소스 프로젝트다.
   2. PR 이력 수집: GitHub 저장소를 대상으로 과거 Pull Request를 수집하고, 조직이 실제로 어떤 문서를 남겼는지 읽는다.

2. 문서 스키마의 합성

   1. 샘플 기반 스키마: 수집한 문서 일부를 샘플링해 그 문서들에 맞는 스키마(schema)를 합성한다.
   2. 임의의 질의: 생성된 스키마 위에서 원하는 질문을 던지고, 에이전트 채팅을 통해 저장소의 여러 종류의 인사이트를 얻을 수 있다.

3. 공개 워크숍과의 연결

   1. 워크숍 소개: 이 도구는 월요일 워크숍에서 소개된 내용이며, 다음 날 다시 이야기할 가능성도 언급되었다.
   2. 실험 진입점: 자체 Context Engine에 가입하기 전에도 조직의 과거 결정과 리뷰 기록을 질의하는 감각을 익힐 수 있는 진입점이다.

6.2. Engineering Social Graph

1. 전문성과 팀 관계의 모델링

   1. 사회적 그래프: Engineering Social Graph는 팀 내 전문성과 관계를 파악하는 도구다.
   2. 작은 팀의 구조: Unblocked 팀은 비교적 작으며, 그래프의 클러스터는 서로 연결된 사람들의 묶음과 팀 구조의 대략적인 형태를 보여준다.

2. 코드 리뷰 관계의 시각화

   1. 선의 의미: 사람 사이의 선은 서로의 코드를 리뷰하는 관계를 나타낸다.
   2. 팀 레이블 생성: 관계를 클러스터링하면 각 집단에 팀 레이블을 붙일 수 있다.

3. 전문가 커버리지의 빈틈

   1. 코드베이스 범위 확인: 그래프는 코드베이스 각 영역이 어떤 사람들의 리뷰를 받고 있는지 보여준다.
   2. 구멍 탐지: 특정 영역에 전문가 커버리지가 부족한 곳을 찾아 리뷰 체계의 빈틈을 파악할 수 있다.
   3. Context Engine 내부 활용: 이런 전문성·관계 데이터는 실제 Context Engine이 관련 컨텍스트와 리뷰 신호를 선택하는 데 사용된다.

7. Context Engine을 직접 비교해 보는 진입점

가입 전에 작업별 컨텍스트가 결과에 어떤 차이를 만드는지 직접 비교할 수 있는 시뮬레이터가 제공된다.

7.1. Context Engine Simulator

1. 작업별 컨텍스트 자동 구축

   1. 백그라운드 조립: Context Engine Simulator는 작업마다 뒤에서 컨텍스트를 구성한다.
   2. 작업 실행에 주입: 만들어진 컨텍스트를 실제 작업을 수행하는 에이전트에 전달해 조직 지식이 있는 상태에서 진행하게 한다.

2. 유무 비교

   1. 두 가지 실행: 같은 작업을 컨텍스트가 있는 경우와 없는 경우에 각각 실행한다.
   2. 차이 확인: 사용자는 두 결과의 탐색량, 답변 품질, 계획의 정확도와 실행 차이를 비교할 수 있다.

3. 접근 방법과 마무리 안내

   1. QR 코드: 현장에서 QR 코드를 띄워 스마트폰으로 빠르게 촬영해 시뮬레이터에 접근하도록 했다.
   2. 고객이 체감한 결과: 고객의 표현은 “토큰 50% 감소, 더 빠른 트리아지, 더 나은 답변”이었다.

7.2. 현장 마무리와 다음 발표

1. 이어지는 세션

   1. Brandon의 발표: 동료 Brandon은 10분 뒤 2020호실에서 Context Engine이 할 수 있는 더 높은 수준의 기능을 자세히 이야기할 예정이었다.
   2. 참석 권유: Peter Werry는 곧 그 장소로 이동할 것이며 참석자들도 함께 따라오라고 권했다.

2. 가벼운 농담

   1. 코코넛: 마지막에는 참석자들에게 코코넛을 받는 것을 잊지 말라고 덧붙이며 음악과 함께 마무리했다.

주요 발언 모음

“A context engine delivers organizational context to both your human workers and now increasingly your agents.”

“Agents are like new employees. They reset their knowledge every time you start a new task.”

“Access to information doesn't equal understanding.”

“They find something that they think is correct and then they stop.”

“The real value of a context engine is not like the upfront cost on these short tasks. It's the compounding effect.”

“50% fewer tokens, faster triage, better answers.”

핵심 데이터 & 수치

• 1달러 미만: Unblocked와 함께 Source Mark Calculator 최적화 계획을 생성하는 총비용이 1달러 미만이었다.
• 약 1분: Context를 사용한 계획 생성에 걸린 실제 작업 시간은 약 1분이었다.
• 약 2분: Context 없이 코드베이스를 직접 탐색한 계획 생성에는 약 2분이 걸렸다.
• 백만 토큰: 백만 토큰 컨텍스트 창에 코드베이스와 아키텍처 문서를 모두 넣어도 조직 컨텍스트의 양과 산만함 문제를 해결하지 못한다.
• 성숙도 4~5단계: 많은 엔지니어링 팀이 컨텍스트가 병목임을 인식하고 해결책을 구축하는 현재 위치다.
• 성숙도 8단계: 소프트웨어 팩토리와 에이전트 기반 전면 자동화가 향하는 방향이다.
• 50% 적은 토큰: 고객이 Context Engine의 효과로 제시한 토큰 사용량 감소다.
• 10분: Brandon의 후속 발표가 시작되기까지 남은 시간이었다.
• 2020호실: Brandon의 Context Engine 심화 발표 장소였다.

결론 및 시사점

1. 코드 생성보다 컨텍스트 설계가 우선이다: 에이전트의 코딩 능력이 좋아져도 조직의 의도·관례·결정·아키텍처 근거를 연결하지 않으면 병합 가능한 결과를 안정적으로 만들기 어렵다.
2. 위키를 늘리는 방식에서 관계를 조립하는 방식으로 이동해야 한다: 정보의 양을 키우기보다 현재 작업에 필요한 출처와 그 사이의 관계를 찾아 제공해야 한다.
3. 작업 단위 컨텍스트를 사용해야 한다: 전체 저장소를 무작정 컨텍스트 창에 밀어 넣지 말고, 작업별로 관련 정보와 실행 흐름을 집중시켜야 한다.
4. 출처를 보여주는 답변이 신뢰를 만든다: 인간은 PR 병합의 책임을 지므로 에이전트의 답변을 검증할 수 있어야 하며, 출처 연결은 검증과 수정의 경로를 제공한다.
5. 조직 지식을 실행 루프 전체에 전달해야 한다: 초기 탐색을 조금 줄이는 것보다 잘못된 계획과 가정에서 시작하는 후속 루프를 막는 것이 비용 절감에 더 중요하다.
6. 전문성을 리뷰 우선순위에 반영해야 한다: 시니어리티와 영역 전문성을 신호로 사용하면 팀의 실제 베스트 프랙티스와 가까운 코드 리뷰를 만들 수 있다.
7. 과거의 대화는 운영 자산이다: Slack 논의와 이전 PR은 현재 코드만으로 복원하기 어려운 설계 의도와 장애 경험을 담고 있으므로 검색 가능한 조직 지식으로 보존해야 한다.
8. GitHub와 리뷰 그래프가 컨텍스트의 기반이 된다: PR 문서 질의와 코드 리뷰 관계 분석은 어떤 지식과 전문가를 현재 작업에 연결할지 결정하는 실용적 데이터 소스다.
9. 동일 작업의 비교 실험부터 시작할 수 있다: Context Engine Simulator처럼 컨텍스트 유무를 비교하면 토큰, 탐색, 답변, 재작업의 차이를 조직의 실제 작업으로 검증할 수 있다.
10. 최종 목표는 소프트웨어 팩토리다: 완전 자동화는 모델을 더 강하게 만드는 문제만이 아니라, 알려지지 않은 미지와 조직의 판단 기준을 에이전트에 지속적으로 전달하는 문제다.

핵심 요약 (20줄)

1. Unblocked는 사람과 에이전트에게 조직 컨텍스트를 전달하는 Context Engine을 만든다.
2. 에이전트는 새 작업을 시작할 때마다 지식을 초기화하는 신입 엔지니어처럼 행동한다.
3. 에이전트는 코드베이스의 빌드·테스트·배포 방식을 작업마다 다시 발견해야 한다.
4. 조직은 장애와 인시던트를 거치며 코드·문서·결정·관례라는 배틀 스카를 축적한다.
5. AI 성숙도는 GPT-3.5 시대의 자동완성에서 Cursor와 조직 위키를 거쳐 소프트웨어 팩토리로 이동한다.
6. MCP와 스킬은 에이전트가 조직 컨텍스트를 탐색하도록 가르치는 현재의 접근 방식이다.
7. 위키나 claude.md를 연결하는 것만으로는 에이전트가 필요한 정보와 관계를 이해하지 못한다.
8. 방사선학의 검색 만족처럼 에이전트는 그럴듯한 정보 하나를 찾으면 탐색을 일찍 멈출 수 있다.
9. 코드베이스와 문서를 백만 토큰 창에 모두 넣으면 용량 부족과 작업 흐름의 산만함이 발생한다.
10. 코드 아래에는 구현 의도, 팀 관례, 과거 결정, Slack 논의, 아키텍처 근거가 숨어 있다.
11. Source Mark Engine에 대한 답변은 코드와 미래 아키텍처 제안에서 존재하지 않던 다이어그램을 생성했다.
12. 답변에 출처를 붙이면 인간이 근거를 검증하고 지식 기반을 수정할 수 있다.
13. Unblocked를 사용한 Source Mark Calculator 계획은 약 1분과 1달러 미만의 비용으로 완성됐다.
14. Context 없이 같은 계획을 만들면 약 2분이 걸리고 더 많은 탐색 비용이 발생했다.
15. 잘못된 정보 발견은 후속 실행을 잘못된 계획과 가정 위에 올려 반복 루프를 만든다.
16. 코드 리뷰 에이전트는 PR과 조직의 베스트 프랙티스를 결합해 팀에 맞는 코멘트를 우선한다.
17. 시니어리티와 전문성은 실제로 중요한 리뷰 코멘트를 부스트하는 신호로 쓰인다.
18. Document Query Engine은 GitHub PR 이력을 수집하고 문서 스키마를 합성해 질의를 지원한다.
19. Engineering Social Graph는 코드 리뷰 관계와 전문가 커버리지의 빈틈을 시각화한다.
20. Context Engine의 핵심 효과는 50% 적은 토큰, 빠른 트리아지, 더 나은 답변과 누적 루프 감소다.