AI 지원 고지: 이 기사는 Claude의 도움을 받아 초안이 작성되었습니다. 모든 기술적 내용, 디자인 결정, 코드 참조 및 스크린샷은 제가 airCloset에서 설계하고 운영하는 프로덕션 시스템을 반영하며, 문장은 출판 전 제가 직접 수정하였습니다.

안녕하세요, 저는 일본의 패션 렌탈 구독 서비스인 airCloset의 CTO Ryan입니다.

"AI와 함께 모든 것이 변한다"는 것이 지배적인 분위기입니다. 내부 AI 플랫폼 (cortex)을 구축하고 운영해 온 저의 경험은 이와는 다른 방향을 가리킵니다. 원칙은 전혀 변하지 않습니다. 오직 기계 장치(machinery)만이 변할 뿐입니다. 이 포스트는 제가 원칙으로 다루게 된 것, 무엇을 깨뜨려야 한다고 결론 내렸는지, 그리고 그 분리에 담긴 사고방식에 관한 것입니다.

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

저는 이전에 개별 요소들에 대해 작성한 적이 있습니다: code-graph, product-graph, db-graph, biz-graph, AI-Observability, auto-review harness, 그리고 Self-Healing입니다. 이 포스트는 그 중 어느 것에 관한 것도 아닙니다.

이것은 그 모든 것들의 배후에 자리 잡은 설계 원칙, 즉 한 단계 더 높은 추상화 수준에 관한 것이며, 구축 기록(build log)이라기보다는 에세이에 가깝습니다.

그 원칙을 한 문장으로 요약하자면 다음과 같습니다: 어떻게 하면 정확한 정보에 접근 가능하게(accessible) 만들 것인가? 이는 오래된 질문입니다. 도서관, 법률 판례집, 백과사전, 검색 엔진 — 모든 시대는 그 시대가 제공하는 도구를 사용하여 자신만의 해답을 내놓았습니다. 사람들이 "패러다임 전환 (paradigm shifts)"라고 부르는 기술 혁명조차도 대부분 단지 그 "수단"을 바꾸었을 뿐입니다. 근본적인 질문은 변하지 않았습니다.

이제 AI가 등장했습니다. 저의 해석은(아마도 논쟁의 여지가 없는 해석이겠지만) AI의 변화는 최소한 인터넷의 규모와 맞먹으며, 어쩌면 그보다 더 클 것이라는 점입니다. 이전의 모든 패러다임 전환과 마찬가지로, "어떻게 하면 정확한 정보에 접근 가능하게 만들 것인가?"라는 질문에 답하는 수단은 밑바닥부터 재설계될 것입니다. 이것이 바로 이 포스트의 주제인 AI-Native 재설계 (AI-Native Redesign) 입니다. 이는 모든 것을 수행하는 인간에게 최적화된 설계 위에 "AI 도구"나 RAG 레이어를 덧붙이는 것이 아니라, AI를 기정사실로 간주하고 전체 설계를 다시 구축하는 관점입니다.

근본 원칙

원칙을 세 개의 노드로 분할하기

제가 사용하는 프레임워크는 원칙을 세 개의 노드 — 생성 (creation) / 유지보수 (maintenance) / 소비 (consumption) — 로 분할하는 것입니다. 누군가(또는 무언가)가 그것을 생성합니다. 누군가 그것을 유지보수합니다. 누군가 그것을 소비합니다.

도서관의 경우: 생성 = 카탈로그 및 분류 체계, 유지보수 = 새로운 도서 추가 및 서가 업데이트, 소비 = 누군가 책을 빌리는 것. 법률 판례집과 변호사의 경우: 생성 = 법원의 판결문 작성, 유지보수 = 말뭉치(corpus)에 새로운 사례 추가, 소비 = 변호사가 의뢰인을 위해 일치하는 사례를 찾는 것. 기업의 엔지니어링 문서의 경우: 생성 = 사양서(spec) 또는 README 작성, 유지보수 = 코드 변경 시 문서 업데이트, 소비 = 다른 엔지니어가 구현 중에 문서를 읽는 것. 모든 경우에서, 이 세 개의 노드 각각에는 이를 담당하는 주체가 있으며, 세 노드가 모두 계속 돌아갈 때에만 전체 시스템이 작동합니다.

이 세 가지가 신뢰와 인센티브 (incentive)의 사슬로 묶여 있는 한, 시스템은 스스로를 지탱합니다. 만약 그중 하나라도 이탈한다면, 전체 시스템은 부정적인 소용돌이 (negative spiral) 속으로 빠져들며 품질이 저하됩니다. 구체적인 메커니즘에 대해서는 이 장의 뒷부분에서 다시 다루겠습니다.

여기서 "정보 (Information)"는 도메인에 따라 형태가 변합니다. 책 속의 지식, 법적 판례, 기업의 내부 문서, 서비스의 런타임 동작 (runtime behavior), 고객 트렌드, 결정 뒤에 숨겨진 추론 (reasoning) 등이 그것입니다. 이들의 공통점은 다음과 같습니다: 정보가 단 한 사람의 머릿속에만 머물러 있는 한, 규모 (scale)가 커지는 순간 전체 시스템은 작동을 멈춘다는 것입니다. 정보가 검색 가능한 형태로 저장되어 있고, 누군가 필요할 때 접근할 수 있을 때 비로소 규모의 경제 (scale)가 작동하기 시작합니다.

변한 것과 변하지 않은 것

수단은 많이 변했습니다. 점토판, 구전 전통, 필사본, 사전과 색인, 인쇄기, 법전과 변호사, 도서관 분류 체계, 그리고 지난 수십 년간의 위키 (wikis)와 종이 문서, APM (Application Performance Monitoring) 및 구조화된 로그 (structured logs), 검색 가능한 지식 베이스 (knowledge bases), 분산 트레이싱 (distributed tracing), 웹 규모의 검색 엔진, BI 대시보드, RAG (Retrieval-Augmented Generation)에 이르기까지 말입니다. 각 시대는 자신이 가진 도구를 사용하여 이 세 노드의 균형을 최적화하려고 시도해 왔습니다.

90년대에 위키가 적합했던 이유는 "인간이 쓰고, 인간이 업데이트하며, 인간이 검색한다"는 형태가 당시 가능한 유일한 방식이었기 때문입니다. 2000년대에 APM이 등장한 이유는 기계가 생성하는 텔레메트리 (telemetry)를 보관할 수 있을 만큼 저장 비용이 저렴해졌기 때문입니다. 각 세대는 그 시대의 주체와 그에 대응하는 고유한 도구를 가지고 있었습니다.

하지만 근본적인 질문은 변하지 않았습니다. 모든 분야의 모든 시대는 그 시대의 도구를 사용하여 "정확한 정보에 접근할 수 있게 만든다"라는 동일한 문제를 해결해 왔습니다. 어떤 의미에서 각 세대는 의식적으로 세 노드(three-node)의 균형을 설계해 왔습니다. 하지만 인간이 루프(loop) 안에 포함되는 순간, 그들은 작성 과정을 생략하거나, 업데이트를 잊거나, 잘못된 정보를 입력하고, 결국 유지보수를 중단하게 되어 전체 시스템이 붕괴됩니다. 일부 시스템(도서관 시스템, 법적 프레임워크, 확립된 학문 분야 등)은 버텨냈지만, 대부분은 인간의 한계가 제약 조건(binding constraint)이 되어 부정적인 나선(negative-spiral)의 측면으로 떨어졌습니다.

AI가 다른 점은 창작과 유지보수가 많은 인간의 노동 없이도 수행될 수 있는 범위를 극적으로 넓힌다는 것입니다. 창작과 유지보수를 자동화하는 것 자체는 이미 오래된 뉴스입니다. 결정론적 시스템 (Deterministic systems)이 그 중 엄청난 양을 다루어 왔으며, 너무나 광범위하게 퍼져 있어 이제는 우리가 인지조차 못 할 정도입니다. 이는 단순히 엔지니어링 인프라 (APM, CI/CD, 로그 수집, 스키마 검증)에만 국한되지 않습니다. 미디어 서비스도 동일한 형태 위에서 작동합니다. 기사가 시스템을 통해 생성, 업데이트, 삭제되면, 배포 시스템이 이를 앱, 웹사이트, 그리고 인쇄본으로 전달합니다. 은행 거래, 이커머스 카탈로그, 지도 앱의 라우팅 데이터, 소셜 네트워크의 타임라인 등도 마찬가지입니다. 결정론적 자동화는 어디에나 존재하며, 너무나 조용히 작동하기에 그것이 존재한다는 사실을 잊기 쉽습니다.

하지만 결정론적 자동화 (deterministic automation)에는 한계가 있습니다. 그것이 손댈 수 없는 작업 영역이 존재합니다. 질적 판단 (qualitative judgment), 디자인 컨텍스트 (design context) 설명하기, 코드 변경에 맞춰 문서 업데이트하기, 주석 추가하기 등 — 즉, 해석과 컨텍스트가 필요한 모든 작업입니다. AI는 이 영역에 발을 들이는 첫 번째 존재입니다. 또한 AI는 소비 측면 (consumption side)에 위치할 수도 있습니다 (APM 예시에서, 이는 인간이 수행하던 "대시보드를 살펴보고 개선 루프를 닫는" 작업을 AI가 실행함을 의미합니다). 인간의 요구사항이 구조적으로 감소하면, 많은 도메인이 처음으로 선순환 (positive spiral)을 돌리기 시작할 수 있습니다. 하지만 이 확장된 역량을 조직 고유의 루프 (loops)에 어떻게 연결할 것인가는 여전히 인간의 설계 결정 (human design call) 영역입니다. 이것이 바로 이 포스트 — AI-Native 재설계 (AI-Native Redesign) — 가 다루고자 하는 내용입니다.

이 포스트의 지향점
AI는 결정론적 자동화의 대체재가 아닙니다. 그것은 결정론적 도구들이 결코 도달하지 못했던 영역을 자동화 범위 (automation envelope) 안으로 가져오는 새로운 역량입니다. 하지만 그 확장된 역량을 중심으로 조직의 루프를 재설계하는 것이야말로 이를 실질적인 변화로 바꾸는 핵심입니다.

각 노드(Node)에 대한 심층 분석

생성 (Creation). 정보를 나중에 찾아볼 수 있는 형태로 만드는 것입니다. 코드의 구조를 문서로 작성하는 것, 로그 (logs)와 트레이스 (traces)를 방출하도록 런타임 (runtime)을 계측 (instrumenting)하는 것, 결정 뒤에 숨겨진 추론 과정을 디자인 문서로 남기는 것, 고객 트렌드를 KPI 정의로 전환하는 것 등이 해당됩니다. 누군가(또는 무언가)가 다시 돌아와 확인할 수 있는 형태로 무언가를 남기는 모든 행위가 이에 속합니다.

유지보수 (Maintenance). 소스 (source)가 변경됨에 따라 이미 작성된 내용이 소스로부터 멀어지지 않도록 유지하는 것입니다. 코드가 변경되면 문서도 따라가야 합니다. 서비스 토폴로지 (service topology)가 변경되면 지표 정의 (metric definitions)도 따라가야 합니다. 고객 트렌드가 변하면 KPI도 따라가야 합니다. 결정 사항이 뒤집히면 기록도 따라가야 합니다. 생성이 단발적인 행위라면, 유지보수는 결코 끝나지 않는 상시적인 과업입니다.

소비 (Consumption). 저장된 것을 실제로 찾아내어 의사결정이나 행동에 사용하는 단계입니다. 인간이 읽는 것, 기계가 쿼리 (Query) 하는 것, 알림 (Alert) 이 발생하는 것, AI 에이전트 (AI agents) 가 컨텍스트 (Context) 를 가져오는 것 모두가 여기에 해당합니다.

이것들은 순차적인 단계(생성 → 유지보수 → 소비)가 아닙니다. 이것들은 상호 신뢰와 인센티브 (Incentive) 에 의해 결합된 하나의 시스템입니다. 즉, 어느 하나를 고립시켜 평가할 수 없습니다.

부정적 나선 (The Negative Spiral) — 왜 대부분의 실제 환경에서 붕괴하는가

구체적으로, 상호 의존성은 다음과 같은 모습으로 나타납니다:

• 소비되지 않는다면, 아무도 그것을 생성할 동기를 얻지 못합니다. 아무도 읽지 않는 문서를 계속 작성하지는 않습니다. 아무도 보지 않는 대시보드 (Dashboard) 를 다듬는 엔지니어는 없습니다.
• 유지보수되지 않는다면, 소비하기에 부적합해집니다. 6개월 전의 문서는 누군가의 머릿속에서 "아마도 오래된 정보일 것"이라는 태그가 붙어 건너뛰게 됩니다. 마지막 제품 변경 이후 지표 정의 (Metric definition) 가 어긋난 대시보드는 조용히 잘못된 의사결정의 씨앗이 됩니다.
• 생성되지 않는다면, 애초에 유지보수할 대상이 없습니다. 쿼리 가능한 (Queryable) 형태로 저장되지 않은 정보는 변화에 따라 추적될 수 없습니다.

세 측면 모두가 "내 역할이 수행할 가치가 있다"고 믿는 한, 루프 (Loop) 는 계속 돌아갑니다. 하지만 어느 하나라도 비용이 너무 많이 들게 되면, 나머지 두 측면도 인센티브를 잃게 됩니다. "아무도 안 읽을 거야, 어차피 썩어버릴 텐데", "업데이트했는데 아무도 신경 안 쓰네", "검색해 봐도 오래됐거나 틀렸어" — 이 세 가지 별개의 변명들이 서로를 강화하며 부정적 나선 (Negative spiral) 의 속도를 높입니다.

대부분의 환경에서 이것이 붕괴하는 방식
세 노드 (Nodes) 중 어느 하나라도 비용이 너무 많이 들면, 나머지 두 노드는 투자할 이유를 잃습니다. 문서화 문화가 정착되지 않고, 모니터링 스택 (Monitoring stacks) 이 노후화되며, 지식 베이스 (Knowledge bases) 가 조용히 공동화되는 이유는 도구의 문제가 아니라 구조적인 문제입니다. 세 노드 사이의 균형이 유지되어야 하며, 그렇지 않으면 전체 시스템은 침묵 속에서 부패합니다.

그렇기 때문에 단일 노드에 패치를 적용하는 것만으로는 결코 문제를 해결할 수 없습니다. 많은 사람들이 "우리 Confluence에는 10만 개의 페이지가 있지만 아무도 읽거나 업데이트하지 않는다"는 식의 사례를 본 적이 있을 것입니다. 이것은 Confluence의 문제가 아닙니다. 세 가지 노드(생성 및 유지 관리) 중 최소 두 개가 계속해서 비용이 많이 드는 상태로 남아 있고, 적용된 해결책이 소비(consumption) 측면의 검색 기능뿐일 때 발생하는 현상입니다. 루프(loop)는 결코 닫히지 않습니다.

Three-node loop: negative spiral vs. positive spiral. A system built on the assumption that humans handle every node slides into a negative spiral where each side reinforces the others' reasons not to invest. Rebuilding with AI as a given — each of the three nodes as an AI × deterministic hybrid, where the split is a design call and deterministic is preferred — turns it into a self-sustaining positive spiral

이 포스트의 나머지 내용

이후의 모든 내용은 동일한 원칙을 바탕으로 작동합니다: 정보를 접근 가능하게 만들고, 이를 세 개의 노드로 구성된 루프(loop)로 실행하는 것입니다.