AI 시대의 플랫폼 엔지니어링에 대해 생각해 보았다

「AI로 업무 개선을 추진하고 싶다」고 의욕을 내비쳐도, 엔터프라이즈(Enterprise) 현장에서는 왠지 잘 진행되지 않는 경우가 있습니다. 문서는 오래되었고, AI에 권한을 넘기는 것은 두렵고, 누가 AI에게 무엇을 시켰는지 추적할 수 없다 — 이 지점들이 조직에 AI를 도입하려고 할 때 반드시 부딪히는 벽이 아닐까라고 느끼고 있습니다.

본고에서는 이러한 3가지 벽을 정리한 후, **「업무의 디지털 트윈 (Digital Twin)」**이라는 발상으로 이를 극복하는 설계안을 공유합니다.

주의 사항: 본 기사는 실제 운용에서 검증된 설계가 아니라, 현 시점에서 책상 위에서 구성해 본 안입니다. 부분적으로 개인적으로 시도해 보았으나, 조직 도입은 미검증 상태입니다. 또한, AI 클라이언트로서 GitHub Copilot만을 도입하고 있는 조직을 상정하여 작성했습니다. Claude Code 등 다른 클라이언트를 병용하고 있는 경우, 특히 거버넌스(Governance) 계층의 구체적인 대책은 재해석이 필요할 것이라 생각합니다. 기록으로 남겨둠으로써 저 자신의 정리와, 비슷한 문제를 고민하고 계신 분들과의 토론 계기가 되기를 바라며 공개합니다.

본고의 전단이 되는 기사 2개를 들어 놓겠습니다. 본고는 단독으로 읽을 수 있도록 작성되었으므로, 읽지 않은 상태라도 문제없습니다. 배경 논의에 관심 있는 분들의 참고용입니다.

AI가 업무에 들어오는 흐름은 이제 멈추지 않을 것이라 느끼고 있지만, 현장에서 실제로 추진하려고 하면 3가지 벽에 부딪힙니다.

업무 개선은 그 자체로 힘든 작업입니다. AI로 대폭 효율화할 수 있는 잠재력은 느껴지지만, 막상 추진하려고 하면,

암묵지가 문서화되어 있지 않음 - 문서는 있어도 오래되었거나 유지보수(Maintenance)되지 않음

• 기존 업무 플로우(Flow)를 통째로 다시 만들려고 하면 허들이 너무 높아 좌절함

과 같은 벽에 부딪힙니다. 「AI로 대체하기 위한 업무량」이 AI로 인해 절감되는 업무량을 상회해 버리는 상황입니다. 기존 업무 플로우를 파괴하지 않고 도입할 수 있는가가 핵심이 될 것이라고 생각합니다.

애초에 사내 문서가 정비되어 있지 않은 경우가 많은 것 같습니다.

• 레거시(Legacy) 프로덕트에는 문서가 없음
• 있어도 너무 오래됨
• 업무 지식이 사람의 머릿속에만 있음 (유실된 케이스도 있음)

여기에 「AI용 프롬프트 (Prompt)」라는 레이어가 올라가면, 인간용과 AI용으로 별개의 문서를 이중 유지보수하는 상태가 되기 쉽습니다. 유지보수 비용이 2배가 되고, 한쪽이 부패해 가는 미래가 보입니다.

개인적으로는 이 지점이 가장 두렵다고 느낍니다.

• 개인 PC의 GitHub Copilot이 폭주하여 CLI에서 ssh를 실행해, 운영 환경을 망가뜨림 - 개인 로컬 권한으로 AI가 마음대로 명령어를 실행하면 조직으로서 추적이 불가능
• 프롬프트 인젝션 (Prompt Injection) (AI에 대한 지시를 악의적인 문장으로 덮어쓰는 공격)이나 Tool poisoning (검증되지 않은 MCP 툴, 혹은 겉보기에는 양호해 보이지만 description에 악의적인 지시가 심어진 MCP 툴이 섞여 들어와 AI에게 유해한 명령을 실행하게 하는 공격)으로 의도하지 않은 조작이 실행됨

「AI가 무엇을 했는지 조직으로서 추적할 수 없다」, 「누가 어떤 권한으로 AI에게 무엇을 시켰는지 알 수 없다」는 상태는 엔터프라이즈에서는 애초에 도입 검토 대상조차 되지 않는 것이 현실이라고 생각합니다.

주장은 심플하게 요약하면 2점입니다.

• 업무를 "지도"로 만들기 — 사내 앱·DB·로그의 **의존 관계 그래프 (Dependency Graph)**와 Wiki의 절차서를 조합하여, AI가 읽을 수 있는 **"업무의 디지털 트윈"**을 만든다.
• AI에게 "목줄"을 채우기 — MCP (AI에게 외부 툴을 사용하게 하는 표준 프로토콜)를 중앙 집권적으로 관리하여, 운영 환경으로 향하는 위험한 경로만 차단한다.

재료는 의존 관계 그래프 + Wiki + Shell MCP 이 3가지만입니다. 신규 SaaS 도입은 제로, 기존 Wiki도 파괴하지 않습니다. 내일부터 Wiki 페이지 1개를 추가하는 것만으로 시작할 수 있는 구성을 목표로 하고 있습니다.

전체상은 다음과 같습니다.

3가지 기둥 — Wiki / 지식 그래프 (Knowledge Graph) / Shell MCP — 를 순서대로 살펴보겠습니다.

자세한 내용은 지난 기사에서 다루었으므로, 여기서는 요점만 적겠습니다.

• 사내 Wiki의 동일한 페이지에, 인간용 bash 명령어와 AI용 MCP 링크를 병기한다.
• 그 Wiki가 조직으로서 사용해도 좋은 **MCP 화이트리스트 (Whitelist)**를 겸한다.
• 기존 Wiki의 계층 구조는 그대로 유지하며, 페이지에 몇 줄 추가하는 것만으로 운용에 들어갈 수 있다.

## prod 배포 절차
### 인간이 수행할 경우
gh workflow run deploy.yml -f env=prod
...

이것만으로도 사람용과 AI용 절차서가 하나의 **SSoT(Single Source of Truth = 정보의 유일한 출처)**로 통합됩니다. 이중 유지보수 문제가 사라질 것으로 보입니다.

게다가, 비공식 MCP는 Wiki에 올라와 있지 않아 사용할 수 없다는 것 = Tool poisoning도 동시에 차단할 수 있는 구조가 됩니다.

참고: GitOps가 제대로 작동하는 조직이라면, 절차 자체가 코드로 되어 있기 때문에 애초에 이 장치는 필요하지 않을 수도 있습니다. 본고에서 가정하는 것은 'Wiki에 업무 절차가 흩어져 있는' 일반적인 조직입니다.

대략적으로 말하면, '애플리케이션 의존성 맵'을 AI에게 전달하는 이야기입니다.

사내 업무에서 그래프화할 대상은 다양하지만, 플랫폼 엔지니어링 관점에서는 우선 애플리케이션-로그-DB 간의 의존 관계를 포함하는 것이 안전하다고 생각합니다. 이것만으로도 충분히 강력하게 효과가 있을 것입니다.

예를 들어, 다음과 같은 연결 구조입니다.

각 노드는 속성(Property)으로 Wiki 링크(레포지토리, 배포 절차, E2E 절차, Kafka 토픽의 JSON 스키마, Redis 유지보수 절차 등)를 가집니다. 노드와 엣지뿐만 아니라, 각 노드에 연결된 문서로의 링크가 AI가 업무를 추적할 때 발판이 된다는 발상입니다.

MCP에서 '지정 노드부터 추적', '역방향으로 의존 원소를 나열'하는 인터페이스만 그래프에 구현해 두면 충분하다고 생각합니다. Cypher 수준의 표현력은 필요하지 않습니다.

예를 들어, 사용자로부터 다음과 같은 프롬프트가 온 상황을 가정해 보겠습니다.

"api-app-a를 1시간 동안 유지보수로 중단하고 싶어. 영향 범위와 온콜 팀을 알려줘"

이때 AI 에이전트의 추론 단계는 대략 다음과 같이 진행될 것으로 예상됩니다.

• 프롬프트에서 대상 노드 api-app-a를 특정 - 그래프 검색 MCP로 api-app-a의 다운스트림을 추적하여 topic-a(KafkaTopic)를 획득 - 나아가 topic-a의 다운스트림을 추적하여 stream-processor-b를 획득 - 마찬가지로 진행하여 redis-cluster-c에 도달 - 각 노드의 속성에서 온콜 팀과 런북의 Wiki 링크를 수집
• 수집된 정보를 요약하여 사용자에게 답변

핵심은, 이 일련의 추론 단계가 '그래프를 추적하는 작업'만으로 구성되어 있다는 점입니다. 그러면 두 가지 강점이 생겨납니다.

설명 가능성(Explainability): AI에게 '어떻게 추적했어?'라고 나중에 물으면, 그래프 상의 경로로 사람이 추적할 수 있는 형태로 설명하게 할 수 있습니다. 추론 경로가 그래프라는 구조화된 형태로 표현될 수 있기 때문에 블랙박스가 되지 않는다는 발상입니다 (필요하다면 MCP 측에서 접근 로그를 기록해 둘 수도 있습니다). 신규 멤버가 AI의 움직임을 이해하는 데 도움을 줄 수 있습니다.
예측 가능성(Predictability): 그래프를 보면, AI가 어떻게 추론을 진행할지 사전에 어느 정도 상상할 수 있습니다. 동작을 제어 가능한 범위 내로 좁히기 쉬우며, 엔터프라이즈 도입 시 중요해지는 'AI의 블랙박스화를 피한다'는 관점에서도 효과적입니다.

전통적으로는 '자세한 사람에게 물어보는 것'밖에 할 수 없었던 작업이, 그래프를 추적하는 것만으로 설명 가능한 형태로 완료될 수 있다고 예상합니다.

좀 더 생생한 사용 사례도 상상해 보겠습니다.

신규 기능 개발로 여러 태스크나 스토리를 모은 JIRA 에픽(여러 태스크를 하나의 장르로 그룹화한 것)이 떨어졌는데, 그 내용물이 복수 앱에 걸친 개수였던 경우는 흔할 것입니다. 예를 들어 '이벤트 처리 기반의 개편' 에픽 아래에 api-app-a, stream-processor-b, redis-cluster-c 세 앱에 걸쳐진 개수 태스크가 나열되어 있는 경우입니다.

전통적이었다면, 이런 작업은 대략 다음과 같은 흐름이 되기 쉬웠습니다.

• 앱 간의 연계 사양을 전문가들에게 물어본다
• 전단 처리를 개수했을 때, 후속에 무엇이 일어날지 코드와 문서에서 직접 추적한다
• 3개의 컴포넌트를 순차적으로 검증 환경에 배포. 절차서는 각각 다른 Wiki 페이지
• 전부 연결된 후에야 비로소 서비스 전체의 프로토타입을 구동할 수 있다

나레지 그래프가 정비되어 있다면, 이 일련의 흐름을 AI 에이전트에게 맡길 경로가 보입니다. 각 노드의 속성에 deploy_guide나 e2e_guide Wiki 링크를 가지고 있으면, AI는 다음과 같이 동작할 수 있을 것으로 예상됩니다.

• 에픽(Epic)으로부터 관계 노드 식별— 개수 대상(改修対象)을 기점으로 그래프를 따라가며 관계된 Kafka 토픽, 후속 스트림 처리(Stream Processing), 쓰기 대상인 Redis 등을 열거
• 영향 범위 산출— "api-app-a의 로그 포맷 변경이 topic-a의 JSON 스키마에 영향을 주고, 나아가 stream-processor-b의 입력 파싱(Parsing)으로 전파된다"와 같은 변경 영향을 의존 엣지(Dependency Edge)로부터 자동 추출
• 검증 환경으로 일제 배포— 각 노드에 연결된 "검증 환경 배포 절차서" Wiki 링크를 순차적으로 열고, 페이지 내의 MCP 링크를 호출하여 배포
• 프로토타입 동작 확인— 모든 것이 연결된 상태에서 각 노드의 e2e_guide를 따라가며, 서비스 전체의 E2E(End-to-End)를 에이전트 주도로 실행

여기서 핵심이 되는 것은 그래프의 프로퍼티(Property)에 Wiki 링크를 갖게 한다는 소박한 장치입니다. 그래프 자체는 노드와 엣지만 있으면 되고, "어떻게 배포할지", "어떻게 실행할지"에 대한 절차는 Wiki에 맡깁니다. AI는 그래프를 따라가 절차서에 도달하고, 절차서에서 MCP에 도달하여 실행합니다. 「그래프 → Wiki → MCP」로 이어지는 3단계 추적이 지금까지 언급한 세 가지 기둥을 관통하며 작동하는 구조입니다.

검증 환경에서의 프로토타입 동작 확인까지 자동으로 돌아가게 된다면, 에픽 단위의 개발 리드 타임(Lead Time)을 크게 단축할 가능성이 있습니다. 이 외에도 장애 발생 시의 파급 효과 추정이나 관련 온콜(On-call) 팀의 즉시 열거 등, 그래프가 효과를 발휘할 시나리오는 다양하게 기대할 수 있습니다.

여기까지는 애플리케이션 간의 의존 관계를 중심으로 이야기했지만, 본래 지식 그래프(Knowledge Graph)는 훨씬 더 다양한 대상을 표현할 수 있습니다. 여기서부터의 확장성에 대해 가능성만 언급해 두겠습니다.

예를 들어, 개발 팀을 노드로 다루는 케이스를 생각해 보겠습니다.

이 엣지 하나가 있는 것만으로도, "스트림 처리 B에 문제가 있는 것 같다"라고 인지한 사람(인간이든 AI든)이 어느 팀에 연락해야 하는지를 즉시 역추적(Reverse Lookup)할 수 있는 상태가 됩니다. Slack 채널이나 온콜 로테이션(On-call Rotation)으로의 링크를 팀 노드의 프로퍼티에 올려두면, 연락 경로까지 포함하여 자동화할 수 있을 것으로 보입니다.

같은 발상으로 확장할 수 있는 대상은 여러 가지가 있습니다.

• 과거의 장애 이벤트를 노드로 남기고 관련 컴포넌트에 엣지를 연결 — "이 토픽, 과거에 문제가 있었나?"를 추적 가능
• 노드에 비용(Cost) 프로퍼티를 부여 — Redis 클러스터의 월간 비용이나 Kafka의 보관 용량으로부터 점검 대상을 기계적으로 추출

다만, 처음부터 이 모든 것을 할 필요는 없다고 생각합니다. 애플리케이션·로그·DB의 의존 관계에 집중하여 시작하고, 효과를 보면서 노드 종류를 늘려가는 것이 현실적인 진행 방식일 것입니다. 그래프의 강점은 **"나중에 엣지나 프로퍼티를 추가해도 기존 이용 방식이 망가지지 않는다"**는 점이며, 이는 시작 장벽이 낮다는 점과 동전의 양면과 같습니다.

거버넌스는 크게 두 층으로 생각하고 있습니다. 연결할 수 있는 MCP를 조직 차원에서 제한하는 것(Remote MCP 허용 리스트)과, 셸(Shell) 실행 경로를 제약하는 것(shell-mcp를 통한 경로 정책)입니다.

먼저, AI 클라이언트가 연결할 수 있는 MCP 서버 자체를 조직에서 승인한 것으로 한정합니다. Wiki 섹션에서 "Wiki에 실려 있는 MCP = 조직의 화이트리스트"를 제안했지만, 이를 AI 클라이언트 측에서도 강제하는 메커니즘입니다. GitHub Copilot Enterprise / Business에서는 Configure MCP server access를 사용하여, 조직으로서 등록한 MCP 레지스트리의 서버 이외로의 연결을 차단할 수 있습니다(Registry only 정책).

이를 통해 Wiki에 실려 있지 않은 정체불명의 MCP나, 문서 외에서 얻은 MCP 연결 정보를 멋대로 사용해 버리는 리스크를 억제할 수 있습니다.

허가된 MCP 중에서도 특히 셸 실행은 위험하므로 별도의 대책을 세웁니다. 여기서 사용하는 것이 shell-mcp입니다(MCP 서버를 통해 셸 실행을 허용하면서도, 목적지나 경로를 정책으로 제약한다는 컨셉을 구현한 것입니다). 자세한 내용은 README에 적혀 있지만, 정책의 골자는 한 줄로 표현할 수 있습니다.

나쁜 의도를 갖지 않는 한, 운영 환경이 망가지거나 외부로 유출되지 않도록 한다. 단, 현실적인 운용이 가능한 범위 내에서.

'엄격함'과 '허술함' 사이에서 현실적인 타협점을 찾는 방침입니다. 이를 AI 클라이언트별로 구체화하겠습니다.

보충: GitHub Copilot의 MCP allowlist의 한계와 Claude Code의 우위성

앞서 언급했듯이, GitHub Copilot의 MCP allowlist는 ID/Name 매칭으로만 작동합니다. 이것이 실제 운용에서 의미하는 바는, stdio 타입의 MCP 대부분은

command: "docker run ..."

으로 실행되기 때문에, allowlist에서 docker를 허용하는 순간 docker로 실행할 수 있는 모든 MCP가 사실상 통과되어 버리는 구조적인 허술함(ガバガバ) 문제에 도달하게 된다는 것입니다.

반면, Claude Code에는 managed-settings.json이나 managed-mcp.json과 같은 MCP 서버 단위의 조직 정책(Organization Policy) 메커니즘이 전용으로 마련되어 있어, 허가 목록(allowlist) 방식으로 "managed가 허가한 MCP 이외에는 실행 불가"하도록 구성할 수 있는 구조입니다. managed scope는 user / project / CLI 플래그 중 그 어느 것으로도 override(재정의)할 수 없으므로, 조직 정책으로서 강력하게 작용합니다.

본고는 GitHub Copilot을 전제로 쓰기 시작했으나, 조사하는 과정에서 현시점에서 진지하게 조직적인 거버넌스(Governance)를 적용하려면 Claude Code를 주축으로 삼는 편이 더 적합하다고 느꼈습니다. shell-mcp 자체는 "운용 경로의 차단"이라는 별도의 축으로서 역할을 하며, 어떤 클라이언트에서도 유효합니다.

VSCode: 조직적으로 chat.tools.terminal.enableAutoApprove를 off - 이를 통해 AI에 의한 자동 터미널 실행을 차단할 수 있습니다.

Copilot CLI: 조직 정책으로 copilot 명령어를 포함한 AI 실행 계열을 통째로 OFF - 개별적인 세밀한 제어(셸 실행만 제한하거나, autopilot만 금지하는 등)는 정책으로 제공되지 않는다는 인상입니다 (2025년 5월 기준. 자세히 아시는 분이 계신다면 알려주시면 감사하겠습니다).

대신 shell-mcp를 통해 셸 실행을 허용하되, 징검다리 서버(bastion)로의 ssh를 차단

구체적인 선 긋기는 인프라 구성에 따라 다르겠지만, 가장 이해하기 쉬운 온프레미스(On-premise) 중심의 조직을 예로 들어 작성해 두겠습니다.

온프레미스에서는 운영 환경(Production)으로 향하는 도달 경로가 대개 징검다리 서버(bastion) 한 점으로 집약되어 있을 것입니다. AI 에이전트가 운영 환경에 해를 끼치려 한다면, 대개 징검다리 서버로의 ssh가 첫 번째 단계가 될 것입니다.

역으로 말하면, shell-mcp로 징검다리 서버로의 ssh만 차단해 버린다면, 그 너머의 운영 호스트 군에 AI가 도달할 수 있는 경로는 사실상 막힌다고 가정할 수 있습니다. 개발자 로컬이나 검증 환경의 host로의 ssh는 그대로 허용한다면, AI 에이전트의 실용성은 충분히 확보할 수 있을 것입니다.

클라우드 중심의 구성에 대해서는 필자의 경험이 적어 깊게 다루지는 않겠지만, "운영 환경으로의 도달 경로 중 초크 포인트(Choke point)를 특정하여 그 부분만 shell-mcp로 차단한다"는 사고방식 자체는 응용이 가능할 것이라 생각합니다.

참고로, 여기서의 선 긋기는 어디까지나 shell-mcp가 제어하는 직접적인 셸 경로에 관한 이야기입니다. Wiki에 승인된 것으로 등록된 업무용 MCP(예: github/deploy가 GitHub Actions를 실행하여 배포하거나, catalog/impact가 의존성 그래프를 참조하는 등)를 통한 원격 실행은 별도의 축으로 다룹니다. 업무용 MCP는 API로서 정비된 안전한 추상화 계층을 경유하기 때문에, 결과적으로 운영 환경에 영향을 주는 것(deploy 계열 등)을 포함하여, Wiki에 기재되어 있는 한 허용한다는 가정입니다. 어디까지나 "직접 셸을 호출하여 운영 환경에 도달하는 경로"만을 shell-mcp로 막는다는 정리입니다.

실행 대상	가부	이유
개발자 로컬	OK	샌드박스(Sandbox)적 취급
검증 환경의 host / 컨테이너	OK	장애가 발생해도 영향이 국소적
징검다리 서버(bastion)	NG	운영 환경으로의 횡적 이동(Lateral Movement)이 용이
클라우드 환경의 운영 host (EC2/GCE 등)	NG	인증 정보 및 운영 데이터에 도달 가능

요컨대 "운영 환경 접속 경로는 금지, 그 외에는 shell-mcp로 실용성을 확보"라는 선 긋기를 자사 조직의 인프라 구성에 대입하는 작업이 됩니다.

이렇게 보면, 본고에서 제시한 세 가지 — (1) AI에 의한 직접 쉘 (Shell) 실행을 조직적으로 금지, (2) MCP allowlist, (3) shell-mcp에 금지 호스트를 각인 — 는 **다층 방어 (Defense in Depth)**로서 조합되었을 때 비로소 효과를 발휘하는 구조입니다. allowlist가 ID 매칭만으로 bypass(우회)되더라도, (1)에 의해 AI 자체가 직접 쉘을 호출할 수 없기 때문에 결과적으로 운영 환경 경로는 차단된다는 발상입니다. 이것이 '지나치게 경직되지 않은' 현실적인 타협점이라고 생각합니다.

세 가지 기둥을 조합하면 디지털 트윈 (Digital Twin)의 세계관이 성립할 것으로 상정합니다.

Wiki가 업무 절차를 투영함 → 인간과 AI가 동일한 절차서를 공유
**지식 그래프 (Knowledge Graph)**가 업무 구조를 투영함 → AI에게 "지도"를 전달
MCP 집약 + CLI 금지 + shell-mcp가 AI 에이전트(AI Agent)가 움직일 수 있는 범위를 제한 → 거버넌스 (Governance)와 실용성을 양립

시뮬레이션 가능한 세계로서 조직 업무의 디지털 트윈이 구축되고, 그 위를 거버넌스가 확보된 AI 에이전트가 달리는 그림을 목표로 하고 있습니다.

구성 자체는 기존 자산의 조합으로, 큰 규모의 신규 도입은 필요하지 않습니다.

기존 Wiki의 계층 구조를 파괴하지 않음 — 페이지에 몇 줄 추가하는 것만으로 시작 가능
그래프 + Wiki + Shell MCP만으로 완결. 신규 SaaS 도입은 거의 제로
1개 업무 단위의 미니 디지털 트윈부터 쌓아 올릴 수 있음

내일부터 페이지 하나에 몇 줄을 더하는 것만으로도 진형 구축을 시작할 수 있을 것으로 상정합니다. 기존 업무 플로우를 파괴하지 않고 도입할 수 있다는 점이 현장 관점에서 가장 효과적인 포인트라고 생각합니다.

AI 시대의 플랫폼 엔지니어링 (Platform Engineering)은 사내 업무의 디지털 트윈을 만드는 활동으로 재정의될 수 있지 않을까 하는 것이 본고의 주장입니다.

Wiki로 인간과 AI의 절차를 일체화 (SSoT화)
지식 그래프로 업무의 의존 관계를 구조화 = 디지털 트윈
**MCP 중앙집권 + CLI 금지 + shell-mcp (운영 host 제외)**로 AI 에이전트를 제한

대규모 툴 도입이나 조직 변경도 필요 없이, 다음 주부터라도 Wiki의 페이지 하나부터 착수할 수 있는 구성으로서 하나의 선택지가 되기를 바랍니다.