목차

• 모든 것을 바꾼 순간
• 그것의 실체
• 누구도 믿지 못할 만큼 간단한 설정 방법
• 집중 세션 — 하나의 에이전트, 하나의 미션
• 특정 기술 스택을 가진 서브 에이전트 (Sub-Agents)
• 자신만의 스택을 위한 MCP 구축하기
• 우리가 실제로 달성한 것들
• 이것이 어떻게 장애 대응 (Incident Response)의 승수 효과 (Force Multiplier)가 되었나
• OpenCode에서 FRIDAY로 — 장애를 자율적으로 조사하는 에이전트
• FRIDAY에서 JARVIS로 — 쓰기 경로 자율성 (Write-Path Autonomy)에 대한 고민
• 코드 작성 없이 130,000개의 계정 삭제하기
• 대화를 통해 제품 전체를 학습하기
• 이것이 ChatGPT와 다른 이유
• 불편한 진실
• 다음 단계

모든 것을 바꾼 순간

화요일 밤 11시였습니다. 운영 환경 (Production Environment)에서의 캐시 마이그레이션 (Cache Migration)으로 인해 당사의 가장 큰 엔터프라이즈 고객사 두 곳에서 수천 건의 인증 실패가 발생했습니다. 제품 부사장 (VP of Product)은 답변을 원했습니다. 지원 팀은 에스컬레이션 (Escalations)을 처리하고 있었습니다. 그리고 엔지니어들은 무슨 일이 일어났는지 파악하기 위해 AWS 콘솔, Datadog, GitHub, Azure DevOps, 그리고 PagerDuty 사이를 Alt-Tab으로 오가며 분투하고 있었습니다.

3주 후, 동일한 변경 사항을 다시 시도해야 했을 때, 한 엔지니어가 터미널에 다음과 같이 입력했습니다:

"ADO 변경 티켓을 검토하고, MOP를 운영 지역의 실제 ElastiCache 설정과 비교해줘. Green 클러스터에서 Redis 환경 변수가 어떻게 연결되어 있는지 K8s 설정 리포지토리를 확인하고, 이 접근 방식이 이전 고객 영향의 원인이 되었던 토큰 검증 실패를 방지할 수 있는지 알려줘."

14초 후, 시스템은 작업 항목 (Work Item)을 가져오고, 4개 지역에 걸쳐 AWS ElastiCache를 쿼리하며, GitHub에서 Kubernetes 설정을 읽고, 배포 패치를 교차 참조했습니다. 그리고 팀이 문서화하지 못했던 위험 요소, 즉 30~60초의 Global Accelerator 전파 시간 동안 발생하는 인플라이트 토큰 (In-flight tokens) 문제를 포함한 정확한 기술적 평가를 전달했습니다.

그 시스템은 바로 OpenCode입니다. 이는 MCP (Model Context Protocol)를 통해 우리의 전체 운영 스택에 연결된 AI 기반 CLI 어시스턴트입니다. 그리고 이 시스템은 수천 명의 엔터프라이즈 테넌트(Enterprise tenants)에게 서비스를 제공하고 매일 수백만 건의 인증 요청을 처리하는 20명 규모의 플랫폼 엔지니어링 팀이 인프라를 관리하는 방식을 근본적으로 변화시켰습니다.

실제 정체는 무엇인가

OpenCode의 개념은 기만적일 정도로 단순합니다. 엔지니어의 노트북에서 실행되는 터미널 애플리케이션입니다. 사용자가 평이한 영어로 질문이나 작업을 입력하면, 시스템은 **라이브 프로덕션 시스템 (Live production systems)**에서 가져온 답변으로 응답합니다.

  엔지니어 (터미널)
        │
        ▼
...

마법은 바로 그 MCP 서버들에 있습니다. 각 서버는 백엔드 플랫폼에 연결되는 경량 커넥터입니다. 질문을 던지면 AI는 추측하지 않습니다. 대신 실제 시스템에 대해 **실제 API 호출 (Real API calls)**을 수행하고 **실제 데이터 (Real data)**를 가지고 작업합니다.

_"이번 달 우리 AWS 지출액은 얼마인가요?"_라고 물으면, Cost Explorer를 쿼리합니다. _"어떤 테넌트가 가장 많은 프로비저닝 트래픽을 생성하나요?"_라고 물으면, Datadog 로그를 집계합니다. _"K8s 설정 리포지토리의 해당 PR이 무엇을 변경했나요?"_라고 물으면, GitHub에서 실제 파일 차이(diff)를 읽어옵니다. 이 세 가지를 한 문장으로 물어보면 AI는 이를 병렬로 처리합니다.

미리 만들어진 대시보드도, 저장된 쿼리도, 따라야 할 런북(Runbooks)도 필요 없습니다. 그저 질문하기만 하면 됩니다.

아무도 믿지 못할 만큼 간단한 설정 방식

전체 설정은 단 하나의 JSON 파일로 이루어집니다. 각 MCP 서버는 하나의 블록을 할당받습니다. 서버 바이너리 위치, 자격 증명(Credentials), 연결 정보 등을 작성하면 됩니다.

{
  "mcpServers": {
    "aws-prod": {
...

AI 모델은 자격 증명을 절대 직접 보지 않습니다. 모델은 "Datadog에서 로그 검색" 또는 _"EKS 클러스터 설명"_과 같이 도구의 이름으로 호출하며, MCP 서버가 인증, 페이지네이션 (Pagination), 에러 핸들링 (Error handling), 응답 포맷팅 (Response formatting)을 처리합니다.

새로운 시스템을 추가하는 데는 약 10분 정도밖에 걸리지 않습니다. 설정 블록을 작성하고, 자격 증명을 제공한 뒤, 재시작하면 끝입니다.

집중 세션 — 하나의 에이전트, 하나의 미션

AI 어시스턴트에 대한 여러분의 생각을 바꿔놓을 지점이 여기 있습니다. 단일 목적을 가진 집중 세션 (Focused sessions)을 생성할 수 있다는 점입니다.

이 글을 쓰고 있는 지금 이 순간에도, 저는 **문서화 어드바이저 (documentation advisor)**로서 며칠째 실행 중인 OpenCode 세션을 가지고 있습니다. 이 세션은 저의 아키텍처 문서(architecture docs)를 검토하고, 기술 기사를 초안하고, 공식 로드맵 문서를 생성하며, 프로젝트 마일스톤(milestones)을 추적해 왔습니다. 관련 없는 다른 주제로 새로운 대화를 시작할 때, 저는 세션에 이렇게 말할 수 있습니다. "이 세션은 문서화 작업 전용으로 예약되었습니다" — 그러면 세션은 제가 집중력을 유지할 수 있도록 도와줍니다.

이 패턴은 모든 집중 작업 스트림(workstream)에 적용됩니다:

각 세션은 전체 대화에 걸쳐 컨텍스트 (context)를 유지합니다. AI는 당신이 3시간 전에 논의했던 내용을 기억합니다. 이전의 발견 사항을 바탕으로 작업을 이어갑니다. 매번 처음부터 다시 시작하지 않습니다.

이것이 진정한 힘입니다: 모든 것을 어설프게 해내는 단 하나의 어시스턴트가 아니라, 적절한 도구가 연결되고 적절한 컨텍스트가 로드된 상태에서 특정 미션을 위해 맞춤 제작된 여러 개의 집중 세션이 존재하는 것입니다.

특정 기술 세트를 가진 서브 에이전트 (Sub-Agents)

집중 세션을 넘어, 특정 도메인에 대해 훈련된 특화된 구성인 **서브 에이전트 (sub-agents)**를 생성할 수 있습니다:

Doc Agent

공식 문서 — 사후 분석 (postmortems), RCA 보고서, 로드맵, 기술 사양서 (technical specs) 등을 생성합니다. 문서 템플릿, 서식 표준을 알고 있으며, 다듬어진 Word/PDF 파일을 출력합니다.

저는 이를 사용하여 공식 마이그레이션 로드맵, 아키텍처 문서, 실행 플레이북 (execution playbooks)을 생성했습니다. 이 모든 것들은 적절한 서식이 갖춰져 있어 리더십 팀과 즉시 공유할 수 있는 상태였습니다.

ADO Agent

Azure DevOps 워크 아이템 (work items)을 생성, 업데이트 및 조회합니다. 프로젝트 구조, 스프린트 주기 (sprint cadence), 티켓 계층 구조 (Epic → Feature → Task)를 이해합니다.

단 한 번의 프롬프트: "cleanup Epic 아래에 배치당 하나씩 총 8개의 태스크를 가진 Feature를 생성해줘" — 라고 입력하면, 적절한 계층 구조, 설명 및 할당이 포함된 9개의 티켓이 생성됩니다.

AWS Agent

모든 리전(Region)과 모든 서비스에 걸친 쿼리 수행. 비용 분석, 리소스 인벤토리(Inventory), 보안 태세(Security posture) 검토. 운영(Prod)과 비운영(Non-prod) 환경을 위해 별도의 IAM 프로필을 사용하여 읽기 전용(Read-only) 모드로 실행됩니다.

The Incident Agent (장애 대응 에이전트)

PagerDuty + Datadog + GitHub에 연결되어 있습니다. 알람(Alert)이 발생하면 모니터 정의를 가져오고, 로그를 검색하며, 최근 배포 내역을 확인하고, 발견된 사항들을 종합합니다. 이 에이전트가 결국 FRIDAY가 되었지만, 이에 대해서는 나중에 더 자세히 다루겠습니다.

The GitHub Agent (GitHub 에이전트)

코드 리뷰, PR(Pull Request) 분석, 리포지토리(Repository) 검색을 수행합니다. 요약본이 아닌 실제 코드와 설정(Config)을 읽습니다. 누군가 _"지난주 프록시 설정에서 무엇이 바뀌었지?"_라고 물으면, 모든 커밋(Commit)을 읽어냅니다.

Build Your Own (직접 구축하기)

API가 있는 모든 시스템은 MCP 서버가 될 수 있습니다. 패턴은 다음과 같습니다:

1. 해당 플랫폼을 위한 MCP 서버를 찾거나 구축합니다 (AWS, Datadog, GitHub, PagerDuty, Slack, Jira, Confluence 등 이미 많이 존재합니다).
2. 만약 존재하지 않는다면 — 가벼운 서버를 구축합니다. MCP 서버는 단순히 MCP 프로토콜을 통해 도구(Tools)를 노출하는 프로그램일 뿐입니다. 기본적인 서버는 파이썬(Python) 약 100줄 정도로 작성할 수 있습니다.
3. 설정(Config)에 추가합니다 — 명령(Command)과 자격 증명(Credentials)이 포함된 하나의 JSON 블록이면 충분합니다.
4. 재시작합니다 — 이제 AI가 해당 시스템에 쿼리를 보낼 수 있습니다.

# 최소 기능의 커스텀 MCP 서버 (단순화 버전):
@mcp.tool()
def query_my_system(query: str) -> str:
...

원칙: 여러분의 기술 스택(Tech stack)에 API가 있다면, 이를 대화형으로 만들 수 있습니다. DNS 제공업체? MCP 서버입니다. 내부 CMDB? MCP 서버입니다. Terraform 상태(State)? MCP 서버입니다. AI는 여러분이 연결하는 도구만큼 강력해집니다.

우리가 실제로 달성한 것

이것은 개념 증명(Proof of concept) 단계가 아닙니다. OpenCode를 사용한 실제 운영 업무의 모습은 다음과 같습니다:

월 $100,000 이상의 비용 발견

재무팀에서 질문했습니다: "고객 한 명당 비용이 얼마나 드나요?" 단일 프록시 포드(Pod)가 모든 테넌트(Tenant)를 서비스하는 공유 인프라 환경에서, 관습적인 답변은 _"정확히 말씀드리기 어렵습니다"_였습니다.

우리는 OpenCode에게 물었습니다. 단 한 번의 세션으로:

• AWS Cost Explorer에서 월간 청구 내역을 가져옴: 4개 리전 합계 $308,763
• 데이터베이스 스토리지 IO(Storage IO) 비용만 월 $40,985임을 발견
• Datadog으로 전환하여 7일간의 **1억 4,900만 개 프록시 로그 엔트리 (proxy log entries)**를 집계
• 테넌트(tenant)별 분석: 상위 고객이 전체 플랫폼 트래픽의 43% 차지
• 전체 활동의 60%를 소비하는 두 개의 계정 식별
• 월 $100,000 이상의 해결 가능한 낭비 요소 (addressable waste) 발견

결과물: 모든 숫자가 API 응답에 근거하여 추적된 361행 분량의 Word 문서. 추정치가 아닙니다. SWAG(대략적인 수치)도 아닙니다. 실제 운영 텔레메트리 (Production telemetry)입니다.

미사용 리소스 감사 (The Unused Resources Audit)

두 개의 AWS 계정과 네 개의 리전에 걸쳐 다음 항목을 확인했습니다:

• 연결되지 않은 탄력적 IP (unassociated Elastic IPs) (레거시 BYOIP 블록 포함)
• 폐기된 클러스터에 연결된 로드 밸런서 (load balancers)
• 동일한 서브넷 내의 중복된 NAT 게이트웨이 (duplicate NAT gateways)
• 누군가 잊어버린 임시 RDS 인스턴스 (temporary RDS instance)
• 수명이 다한(end-of-life) Node.js 런타임을 사용하는 Lambda 함수 (Lambda functions)

결과물: 소계가 포함된 색상 구분형 Excel 통합 문서. 합산된 낭비 비용: 월 약 $3,200 및 $97,000의 중복 비용.

캐시 마이그레이션 사전 분석 (The Cache Migration Pre-Mortem)

재시도(retry) 계획을 세울 때, 단 하나의 프롬프트가 완전한 기술 평가를 생성했습니다:

• 작업 절차(method of procedure)를 위해 ADO 티켓을 읽음
• 현재 토폴로지(topology)를 확인하기 위해 ElastiCache에 쿼리함
• GitHub에서 20KB 분량의 Kubernetes YAML 파일을 읽음
• 팀이 문서화하지 않았던 리스크 식별: 30~60초의 트래픽 전파 시간 동안 발생하는 인플라이트 토큰 (in-flight tokens)

총 소요 시간: 14초.

장애 대응의 승수 효과 (Force Multiplier)가 된 과정

실제 장애 상황(live incident) 중에 OpenCode를 처음 사용했을 때, 저는 한 가지를 깨달았습니다. AI가 우리 엔지니어들보다 더 빠르고 일관되게 장애 조사 (incident investigation)를 수행하고 있다는 사실이었습니다.

AI가 더 똑똑해서가 아닙니다. 컨텍스트 스위칭 (context-switch)을 하지 않기 때문입니다.

장애를 조사하는 인간은 다음과 같은 것들을 열어둡니다:

1. PagerDuty → 알림(alert) 읽기
2. Datadog → 서비스 검색, 에러 급증(error spike) 확인
3. GitHub → 누군가 무언가를 배포했는지 확인
4. 세 가지 도구 간의 타임스탬프(timestamp) 교차 참조
5. 가설 수립
6. 심층 조사 — 영향을 받은 테넌트(tenant), 에러 경로, 큐 깊이(queue depth) 확인
7. 조사 결과 작성

숙련된 엔지니어에게도 이는 15~45분이 소요되는 작업입니다. 주니어 엔지니어라면 더 오래 걸릴 것입니다. 또한 수면 부족 상태에서 도구들을 전환하며 발생하는 인지적 부하(cognitive overhead)는 신호를 놓치거나 잘못된 결론을 내리는 원인이 됩니다.

OpenCode를 사용하면 동일한 조사가 단 한 번의 대화로 끝납니다:

"EU 지역 프록시 5xx 에러에 대해 PagerDuty 알림이 발생했습니다. 백엔드별 에러율과 영향을 받은 테넌트를 확인하기 위해 Datadog을 체크하세요. 최근 EU 기본 클러스터에 배포된 내용이 있는지 GitHub를 확인하세요. 무엇이 바뀌었나요?"

90초에서 3분. 매번 마찬가지입니다. 컨텍스트 스위칭 (context-switching)도 없고, 신호를 놓치는 일도 없으며, 잘못된 지역을 조사하는 일도 없습니다.

깨달음: 만약 AI가 내 터미널 세션에서 대화형으로 이 작업을 수행할 수 있다면, PagerDuty 웹훅(webhook)에 의해 트리거되었을 때 자율적으로 (autonomously) 수행할 수 있다는 것입니다. 내가 질문을 입력할 필요 없이, AI가 알림 페이로드(payload)로부터 스스로 질문을 구성할 수 있습니다.

그 깨달음이 FRIDAY를 만들었습니다.

OpenCode에서 FRIDAY로 — 장애를 자율적으로 조사하는 에이전트

FRIDAY는 본질적으로 인간이 질문을 입력하지 않아도 실행되는 Lambda로 추출된 OpenCode의 장애 조사 패턴입니다.

진화 과정:

동일한 도구. 동일한 추론 패턴. 동일한 출력 형식. 하지만 조사 단계에서 인간의 개입(human in the loop)이 없습니다. 온콜(on-call) 엔지니어는 가공되지 않은 알림 대신 완료된 분석 결과를 확인하며 깨어납니다.

수개월간 프로덕션 환경에서 운영한 결과:

수개월간 프로덕션 환경에서 운영한 결과:

• MTTR (평균 복구 시간) 65% 감소
• 엔지니어링 팀 전반에 걸쳐 AI 도구 채택률 85% 달성 (기존 대비 20% 증가)
• 오탐(false escalations) 약 80% 감소

FRIDAY에서 JARVIS로 — 쓰기 경로 자율성에 대한 고찰

FRIDAY가 AI 에이전트가 프로덕션 인시던트를 신뢰성 있게 조사할 수 있음(읽기 전용)을 입증한 후, 자연스러운 질문은 다음과 같았습니다. 그것이 실제로 무언가를 수정할 수도 있을까?

인시던트는 아닙니다. 그것들은 순간적인 인간의 판단력을 필요로 합니다. 하지만 **취약점 패치(vulnerability remediation)**는 다릅니다. 이는 예측 가능한 패턴을 따르는 일상적인 보안 수정 작업입니다.

JARVIS는 바로 그 80%를 처리하도록 설계되었습니다. 즉, 수정 과정이 잘 이해되고 검증이 자동화될 수 있는 루틴한 수정 작업들입니다. 모든 단계에서 인간의 승인 게이트가 존재합니다. 문제가 발생하면 자동으로 롤백됩니다.

진행 과정: OpenCode는 AI와 MCP 도구가 여러 시스템에 걸쳐 추론할 수 있음을 보여주었습니다. FRIDAY는 이를 조사(investigation)하는 데 있어 자율적으로 수행할 수 있음을 입증했습니다. JARVIS는 여기에 '가드레일(guardrails)'을 갖추고 자율적인 수정 작업(autonomous remediation)으로 확장합니다. 각 단계는 다음 단계를 위한 신뢰를 구축합니다.

코드를 작성하지 않고 13만 개 계정 삭제하기