안녕하세요, airCloset의 CTO인 Ryan입니다.

면책 조항 (Disclaimer): 이 글에서 언급되는 "cortex"는 airCloset에서 자체적으로 구축한 AI 플랫폼의 내부 코드네임입니다. Snowflake Cortex 또는 Palo Alto Networks Cortex와 같은 기존 상용 서비스와는 관련이 없습니다.

이번 시리즈의 다섯 편의 포스트를 통해 저는 cortex의 하네스 (harness)가 어떻게 구성되는지 한 단계씩 살펴보았습니다: 전체적인 그림, 지식 그래프 (knowledge graph), 자동 리뷰 (Auto Review), 자가 치유 (Self-Healing) + 재발 방지 (Recurrence Prevention), 그리고 비엔지니어의 PR (Pull Request)까지 말이죠. 이 모든 과정을 거치며, 마무리를 위해 한 단계 더 아래로 내려가 보고자 합니다. 애초에 저는 왜 이것을 만들고 있는 걸까요? 이 포스트가 다루고자 하는 내용입니다.

다섯 편의 포스트가 독립적으로 보일 수 있지만, 그 뿌리는 하나이며, 그 하나를 말로 표현하지 않고서는 이 시리즈를 깔끔하게 마무리할 수 없습니다. 철학과 더불어, 성공한 사례만을 기록할 때 드러나지 않는 실패들 — 제가 무엇을 버렸는지, 어디서 넘어졌는지 — 을 되돌아봄으로써, 유사한 시도를 하려는 모든 분에게 참고 지점이 되고자 합니다.

시리즈 인덱스 (Series Index)

#	주제 (Theme)	주요 장면 (Key scene)	기사 (Article)
1	시리즈 소개: cortex의 하네스 (harness)	PR 자동 병합 / 인지하기도 전에 사고가 자가 치유됨	ai-harness-intro
...

기원 — 2025년에 내가 고민했던 것

cortex를 구축하기 시작했을 때, 제가 답을 얻고 싶었던 질문은 하나였습니다:

어떻게 하면 AI가 시스템을 정확하게 이해하도록 만들 수 있을까?

만약 AI가 시스템을 정확하게 이해할 수 있다면, PR 리뷰 (PR review), 버그 조사 (bug investigation), 그리고 수정 (fixes) 작업을 모두 위임할 수 있으며, 비엔지니어 (non-engineers)조차도 스스로 개발을 시작할 수 있게 될 것입니다. 반대로, 제가 "정확하게 이해하는 것"에 막혀 있는 한, 그 이후의 모든 하위 단계는 불안정한 기반 위에 놓이게 됩니다. 그래서 저는 개별적인 메커니즘을 만들기 전에 **전제 조건 레이어 (prerequisite layer)**에 많은 시간을 할애했습니다.

두 가지 명확한 접근 방식 모두 한계에 부딪혔습니다.

벽 1: 컨텍스트 윈도우 (Context Window)의 한계

첫 번째 본능적인 반응은 "필요할지도 모르는 모든 정보를 그냥 다 줘버리자"입니다. 코드베이스, 문서, DB 스키마, 인프라 정의를 프롬프트에 전부 쑤셔 넣으면 AI가 전체 그림을 파악할 수 있을 것이라 생각합니다.

하지만 이는 크기 문제에서 실패합니다. 우리 회사의 코드베이스, 문서, 스키마, 인프라를 모두 합치면 그 어떤 현실적인 컨텍스트 윈도우 (Context Window)에도 들어갈 수 없습니다.

"컨텍스트 윈도우는 계속 커질 것이고, 결국에는 해결되지 않을까?" — 이 생각을 하면 할수록, 그 방향으로는 미래가 보이지 않았습니다.

Gemini와 같이 컨텍스트 윈도우가 매우 큰 모델이라 할지라도, 한계치에 가깝게 밀어붙이면 동작이 불안정해집니다. 중간 정보가 누락되고, 무관한 토큰들이 결론을 엉뚱한 방향으로 왜곡합니다. 이것은 모델 선택의 문제가 아니라, 구조적인 어텐션 (Attention) 문제입니다. 무관한 토큰을 더 많이 섞을수록, 관련 토큰에 대한 어텐션 비율은 기계적으로 떨어집니다. 이는 문서화된 "lost in the middle" 현상(긴 입력값의 시작과 끝에 배치된 정보는 사용되지만, 중간에 배치된 정보는 사실상 무시되는 현상)이며, 컨텍스트 윈도우를 가득 채우면 당신이 전달했다고 생각한 정보가 실제로는 모델에게 보이지 않는 상태에 정기적으로 빠지게 됩니다.

"Lost in the middle" 자체는 롱 컨텍스트 (Long-context) 모델이 발전함에 따라 완화될 수 있으므로, 저는 이를 핵심 논거라기보다는 경험적인 뒷받침 근거로 취급합니다. 진짜 벽은 그 아래에 있는 **재귀적 (Recursive)**인 벽입니다. 즉, "크기" 문제가 해결되더라도, 어떤 토큰이 필요하고 어떤 것이 필요하지 않은지를 판단할 수 있는 더 높은 수준의 컨텍스트 (Context)가 즉시 필요하게 됩니다. 이 문제는 재귀적이며 원칙적으로 컨텍스트 윈도우 크기만으로는 해결될 수 없습니다. 정보는 구조화되어야 하며, 그렇지 않으면 AI는 올바른 판단을 내리지 못합니다. 이는 인간에게도 해당되는 사실이지만, 인간은 한 단계 더 낫습니다. 왜냐하면 LLM은 자신이 모른다는 사실을 인지하지 못하며, 그럼에도 불구하고 자신 있게 답변하기 때문입니다. 눈에 보이게 막히는 것보다, 조용히 틀리는 것이 더 나쁩니다.

계속해서 커지는 컨텍스트 윈도우 (context-window) 방식은 실질적인 해결책이 보이지 않았습니다.

벽 2: 학습에 의존하지 마라

또 다른 명백한 선택지는 AI 자체가 학습하게 만드는 것입니다. 조직별로 미세 조정 (Fine-tune)을 하고, 우리의 코드베이스, 문서, 비즈니스 로직을 가르치는 것이죠. 저도 이를 고려했습니다. 하지만 현재는 실행하고 있지 않습니다.

두 가지 이유 때문입니다. 첫째, 학습 내용을 실제 운영 환경 (production)에 적용하는 것은 여전히 연구 단계에 머물러 있었고 (2025년 당시 그랬으며, 이 글을 쓰는 2026년에도 여전히 그렇습니다), 실제 배포까지 가는 길은 아직 멉니다. 다른 이유는 더 까다롭습니다. 설령 학습이 가능하더라도, "망각"이 극도로 어렵다는 점입니다.

비즈니스 시스템은 "현재의 진실"을 반영해야 합니다. 설계가 변경되고, DB 스키마가 변경되며, 비즈니스 규칙이 바뀔 때, 여러분은 오래된 지식을 적극적으로 지우고 싶어 할 것입니다. 하지만 "LLM 가중치 (weights)에 구워진 내용 중 이 부분만 삭제하기"는 연구 수준에서도 해결되지 않은 문제입니다. 심지어 이를 지칭하는 **머신 언러닝 (machine unlearning)**이라는 분야가 따로 있을 정도로 그 난이도가 높습니다. 게다가 모델에게 새로운 것을 가르치는 것은 관련 없는 기존 지식까지 파괴하기도 합니다 (이를 파괴적 간섭 (destructive interference) 또는 **파괴적 망각 (catastrophic forgetting)**이라고 부릅니다). 학습에 의존하면 이 두 가지 문제가 동시에 발생하며, 일관성을 유지하기 위한 비용이 폭발적으로 증가합니다.

저는 "학습하지 못함"을 단점으로 취급하는 대신, 다음과 같은 결론에 도달했습니다. 학습하지 않기 때문에, 외부 지식을 교체하는 것만으로도 현재 상태를 반영하기에 충분하며, 일관성을 유지하는 이야기가 훨씬 단순해진다는 것입니다. 당시 저의 결정은 그것이었습니다.

탈출구 — GraphRAG + MCP

컨텍스트 윈도우 방향도, 학습 방향도 미래가 보이지 않던 차에 저는 GraphRAG 개념을 접하게 되었습니다.

GraphRAG 자체는 다른 곳에서도 널리 논의되고 있지만, 저에게 그것이 의미했던 바는 다음과 같은 프레임워크였습니다. "필요한 순간에, 필요한 컨텍스트만을 공급하라." 여기에 MCP (LLM을 외부 도구와 연결하기 위한 Anthropic의 프로토콜)를 결합하면, AI는 스스로 필요한 것을 가져올 수 있습니다.

결정적인 차이는 이 구조가 AI로 하여금 에이전트 방식 (agentically)으로 그래프를 탐색할 수 있게 해준다는 점이었습니다. "모든 것을 읽고 추론을 통해 관련 부분을 찾는다"가 아니라, AI가 필요한 노드(node)에 도달하여 사실(fact)을 직접 추출하는 것입니다. 이는 다음과 같은 결론으로 이어집니다.

AI가 추론하게 만드는 대신, 사실을 컨텍스트 (context)로 제공하라.

이 한 문장이 cortex 전체 설계 철학의 핵심이 되었습니다.

제가 처음 만든 것은 정적 분석 기반의 **코드 그래프 (code-graph)**였으나, 시행착오 끝에 이를 버리고 어노테이션 (annotation) 기반의 **제품 그래프 (product-graph, cpg)**에 도달했습니다. 자세한 내용은 시행착오 섹션에서 다룹니다.

애초에 나는 AI를 신뢰하지 않는다

기원을 한 문장으로 요약하자면 다음과 같습니다.

나는 AI가 나를 대신해 빈칸을 채워줄 것이라고 믿지 않는다.

여기서 "신뢰하지 않는다"는 것은 "믿음이 없다"는 뜻과는 다릅니다. Claude / GPT / Gemini의 생성 품질을 의심하는 것이 아닙니다. 제가 의미하는 바는 다음과 같습니다.

• AI는 전달받지 않은 컨텍스트 (context)를 알지 못한다.
• AI는 스스로, 그리고 지시받지 않고서는 이상적인 상태를 만들어내지 못한다.

첫 번째는 모델의 발전이 아무리 이루어져도 변하지 않을 진실입니다. 아키텍처 (architecturally) 관점에서, LLM은 학습 데이터에 없었거나 이번 세션의 컨텍스트 (context)에 포함되지 않은 정보는 알 수 없습니다. "분명 더 똑똑한 모델이 나오면 알아낼 것이다"라고 생각할 수도 있지만, 저는 그런 미래가 오지 않을 것이라고 봅니다. '더 똑똑해지는 것'은 실질적인 방향이지만, '똑똑함' 그 자체만으로는 '모르는 것'을 보완할 수 없습니다.

두 번째는 책임, 그리고 인간이 그 책임을 지는 것에 관한 문제입니다. AI는 무엇이 "이상적"인지 스스로 결정할 수 없습니다. AI가 시도할 때, 실제 상황과는 약간 동떨어진 일반적인 베스트 프랙티스 (best-practice) 답변에 도달할 뿐입니다. 이상적인 상태는 비즈니스, 조직, 그리고 시점에 따라 달라집니다. 인간이 이를 말로 표현하여 전달하지 않는 한, AI는 이 중 그 어떤 것도 볼 수 없습니다.

따라서 그러한 확신은 **AI의 능력을 과소평가하는 것이 아니라, AI가 전제 조건을 스스로 자동 완성(auto-complete)하도록 내버려 두지 않겠다는 설계 결정 (design decision)**입니다.

AI를 마스터한다는 것은 AI에게 자유를 주는 것이 아니라, 그 출력을 예측 가능한 범위 내로 가두는 것입니다.

그 출력을 가두는 메커니즘이 바로 이 시리즈에서 설명해 온 하네스 (harness)입니다.

그래서 나는 AI를 결정론 (determinism)에 묶어두기 위해 하네스를 구축한다

"AI가 추론하게 만들지 말고, 결정론 (determinism)에 의존하라"는 관점으로 각 포스트를 읽어보면, 다섯 개의 포스트 모두 서로 다른 계층에서 나타나는 동일한 확신임을 알 수 있습니다.

Part 2 — 지식 그래프 (Knowledge Graph): AI가 코드베이스를 검색하게 만드는 대신, 이 메커니즘은 코드베이스를 읽기 쉽게 만드는 방향으로 기울어져 있습니다. @graph-* 어노테이션 (annotations)을 통해 코드 / 문서 / DB / 인프라가 하나의 그래프로 통합되므로, AI는 관련 부분을 찾기 위해 grep을 수행하거나 추론할 필요가 없습니다. 이는 원천 (origin) 섹션에서 언급한 "컨텍스트로서 사실을 제공하라"를 직접적으로 구현한 것입니다. → cortex-product-graph

Part 3 — 자동 리뷰 차원 (Auto Review Dimensions): 9가지 리뷰 차원 (책임 / 심각도 / 유형 SSoT 등)이 사전에 고정됩니다. AI가 리뷰를 수행할 때, 무엇을 점검할지는 AI가 추론할 수 있는 영역이 아닙니다. "PR을 전체적으로 살펴보기"는 AI에게 너무 많은 추론의 여지를 주기 때문에, 차원을 분할하여 각 차원을 개별적인 질문으로 판단합니다. 차원 = 하네스에 의해 고정됨, 평가 = AI의 역할. → cortex-auto-review

Part 4 — 자가 치유 (Self-Healing) + 재발 방지 (Recurrence Prevention): 알림(Alert) → 조사(Investigation) → 수정 PR(Fix PR) → 재배포(Redeploy). 이 흐름 자체가 고정되어 있습니다. AI는 매번 "사고에 어떻게 대응해야 하는가"를 고민하지 않습니다. 그리고 재발 방지(Recurrence Prevention) — 동일한 함정에 두 번 빠지지 않도록 린트(Lint) / CI 게이트(CI gates)를 추가하는 것 — 는 AI가 다시는 그러지 않을 것이라고 믿는 것이 아니라, 게이트에서 기계적으로 거부하는 것입니다. 달리 말하자면, 저는 AI가 실수를 절대 반복하지 않을 것이라고 기대하지 않습니다. → cortex-self-healing

Part 5 — 비엔지니어 PR (Non-Engineer PRs): 만약 이 안전장치(Harness)가 품질을 유지해주지 않았다면, 비즈니스 측 인원들이 프로덕션에 직접 PR을 여는 방식은 단 하루도 버티지 못했을 것입니다. 반대로, 위에서 언급한 세 가지 메커니즘(컨텍스트 고정, 차원 고정, 함정의 기계적 차단)이 중첩되어 있다면, 요구사항에 가장 가까운 사람이 변경 사항을 직접 배포할 수 있습니다. 번역 계층(Translation layer)과 엔지니어링 우선순위 큐(Engineering priority queue)는 결정론(Determinism)을 밀어붙인 결과로 나타난 하류의 결과물로서 사라졌습니다. → cortex-non-engineer-prs

따라서 다섯 편의 포스트를 통해 다룬 내용은 서로 다른 계층에서 구현된 "AI가 추론하게 만들지 말고, 결정론(Determinism)에 의존하라"는 것입니다. 그 뿌리에는 하나의 확신이 있습니다.

"AI가 추론하게 만들지 말고, 결정론에 의존하라"는 말이 실제로 의미하는 것

몇 번 언급되었던 이 문구를 더 날카롭게 다듬어 보겠습니다.

"결정론에 의존하라"는 것이 AI에게 추론할 여지를 전혀 주지 말라는 뜻은 아닙니다. 코드 생성, 리뷰 결과 판단, 에러 로그로부터 근본 원인(Root causes) 가설 세우기 등은 AI가 추론하지 않는다면 아무런 작업도 이루어지지 않는 영역들입니다.

제가 결정론에 의존하고자 하는 곳은 변동성(Variance)이 허용되지 않는 영역들입니다. 구체적으로는 다음과 같습니다:

• 코드베이스의 어느 부분을 살펴볼 것인가 — AI가 유추(Analogy)를 통해 추측하게 하지 마세요. 지식 그래프(Knowledge Graph)에서 결정론적(Deterministically)으로 가져오세요.
• 어떤 리뷰 차원(Review Dimensions)을 적용할 것인가 — AI가 "중요해 보이는 차원"을 선택하게 두지 마세요. 차원 목록을 사전에 고정하세요.
• 장애(Incident)에 어떻게 대응할 것인가 — 매번 AI가 워크플로우를 생각하게 만들지 마세요. 알람 발생 → PR 수정 경로를 고정하세요.
• 같은 함정에 두 번 빠지지 않기 — AI에게 "주의하도록 노력해"라고 요청하지 마세요. 린트(Lint)나 CI가 기계적으로 이를 거부하게 하세요.

추론(Inference)이 허용되는 곳과 허용되지 않는 곳 사이의 이 경계선을 구현하는 것이 바로 하네스(Harness)입니다. 5부의 비유를 빌려오자면, 하네스는 탈선할 수 없는 레일을 깔아주는 것입니다. 그 레일 위에서 AI는 자유롭게 달릴 수 있지만(추론은 추론으로서 작동합니다), 레일 밖으로 옆으로 튕겨 나갈 수는 없습니다.