SI에 'A'를 더하다 — DCS의 하네스, 그리고 유지보수팀에게 보내는 전령 헤르메스
1편은 문서의 정원, 3편은 기획의 정원, 4편은 디자인과 프론트의 정원이었습니다. 이번엔 가장 늦게, 가장 조심스럽게 문을 연 정원 — 엔터프라이즈 구축형 사업의 정원입니다.
혹시 "우리 같은 보안 빡빡한 SI-SM 환경에서 AI가 되겠어?" 를 한 번이라도 떠올려 본 적 있으신가요. 이 글은 바로 그 질문을 안고 일하는 분들 — 무언가를 고객에게 납품하고, 또 오래 유지보수해야 하는 사람들 — 을 위한 글입니다. SI/SM 개발자, 구축형 프로젝트의 PM·테크리드, 그리고 보수적인 환경 탓에 AI 도입을 미뤄 온 모든 분이요.
저는 블룸AI에서 DCS 테크팀을 이끄는 테크리드(이름은 익명)입니다. 같은 벽 앞에 서 봤기에, 저희가 그 벽을 어떻게 넘었는지를 블룸AI 하네스 시리즈의 다섯 번째 편으로 정리했습니다 — 제 무용담이 아니라, 같은 고민을 가진 분들을 위한 현장 안내서로 읽히길 바라며.
이 글에는 두 개의 축이 있습니다. 하나는 본방 개발팀이 하네스로 플랫폼 품질을 끌어올린 이야기, 다른 하나는 그 본방의 지식을 유지보수팀에게 안전하게 나르는 전령 '헤르메스' — OpenRouter 1위에 오른 오픈소스 자율 에이전트 위에 세운 — 의 이야기입니다. 두 축을 관통하는 질문은 하나였습니다 — SI에서 글자 'A' 하나만 더하면 AI가 되는데, 그 A를 어떻게 보안을 깨지 않고 더할 것인가.
1. DCS란 무엇인가 — 한국형 SI-SM, 그리고 '전진 배치'라는 다른 길
먼저 DCS가 무엇인지부터 풀겠습니다.
저희 해피톡은 두 갈래로 제공됩니다.
| 갈래 | 무엇인가 | 주 사용자 |
|---|---|---|
| 해피톡 SaaS | 고객사가 그대로 가져다 쓰는 표준 제품 (Software as a Service) | 대부분의 고객 |
| 해피톡 PaaS | 고객 업무 흐름에 맞춰 새로 구축해 파생되는 맞춤형 (Platform as a Service) | 엔터프라이즈 고객 |
DCS(Digital Communication Suite, 디지털 커뮤니케이션 슈트) 가 책임지는 영역은 이 중 오른쪽 — 고객 맞춤형 구축형(PaaS) 입니다. 그대로 쓰는 SaaS가 아니라, 대형 고객사의 고객이 필요로 하는 모든 디지털 소통을 고객 환경에 맞춰 구축·납품하는 일이죠. 그 '모든 디지털 소통'은 이렇게 한 벌로 묶입니다.
| DCS가 한 벌로 묶는 디지털 소통 | 무엇인가 |
|---|---|
| 💬 채팅 상담 | 웹·앱에서의 실시간 채팅 고객 응대 |
| ☎️ 콜 상담 | 전화 기반 상담·콜센터 연동 |
| 🤖 맞춤 AI 챗봇 | 고객사 도메인에 맞춘 AI 자동 응대 |
| 📨 CRM 메시지 발송 | 알림·마케팅 등 고객 대상 메시지 발송 |
이 맞춤 구축형(PaaS)을 짓고, 또 오래 지키는 일 — 저희가 'DCS 사업'이라 부르는 그것이, 이 글의 무대입니다.
국내에서는 이걸 SI(System Integration, 시스템 통합) 라고 하면 거의 한 단어로 통합니다. 그런데 막상 해외 엔지니어에게 "We do SI"라고 하면 갸웃합니다. 한국에서 말하는 SI는 "개발 인력을 투입해 고객 시스템을 구축하는 사업" 이라는 의미가 강한데, 영어권에서 "System Integration"은 그렇게 인력 중심으로 쓰이지 않기 때문입니다 (JobKorea — SI와 SM 업무의 차이). 한국형 SI의 진짜 특징은 인력 투입(man-month) 단가와, 구축이 끝나면 같은 사람들이 SM(System Maintenance, 시스템 유지보수) 으로 이어 받는 구조입니다.
구축(SI) → 유지보수(SM) 로 이어지는 흐름. 짓는 사람이 그대로 지키는 사람이 됩니다. 도메인 지식과 코드 맥락이 사람의 머릿속에 실려 SM으로 넘어갑니다.
1-1. 팔란티어가 택한 다른 길 — FDE
비슷한 문제를 전혀 다르게 푼 회사가 있습니다. 팔란티어(Palantir) 입니다. 이들은 엔지니어를 사무실에 앉혀 두고 요구사항 문서를 기다리지 않았습니다. 고객의 현장 한복판에 엔지니어를 직접 배치했습니다. 이 역할의 이름이 FDE(Forward Deployed Engineer, 전진 배치 엔지니어) 입니다 — 팔란티어 내부에서는 "Delta"라고 부릅니다 (Palantir, Dev versus Delta).
FDE의 철학은 조언하고 빠지는 컨설턴트와 정반대입니다. 고객이 요구사항을 명확히 말로 못 하는 환경(정보기관·국방)에서 시작됐기 때문에, FDE는 현장에서 관찰하고, 실험하고, 직접 프로덕션을 짓습니다 (Palantir, A Day in the Life of a Forward Deployed Software Engineer). 여기까지는 한국형 SI와 닮았습니다 — 고객 안으로 들어간다.
결정적 차이는 그 다음입니다.
| 한국형 SI-SM | 팔란티어 FDE | |
|---|---|---|
| 고객 안으로 들어가는가 | ✅ 들어간다 | ✅ 들어간다 |
| 수익이 인력 수에 묶이는가 | 인월 단가 — 사람 수에 비례 | 제품 라이선스 — 사람 수와 분리 |
| 현장에서 배운 것이 어디로 가는가 | 그 프로젝트 안에 머문다 | 핵심 제품으로 환류된다 |
| 다음 고객은 더 빨라지는가 | 매번 처음부터 | 자갈길이 포장도로가 된다 |
FDE의 진짜 일은 한 고객의 커스텀이 아니라, 여러 배치에서 반복되는 패턴을 추출해 핵심 플랫폼으로 되먹이는 것입니다 — 이른바 "자갈길을 포장도로로(gravel road to paved highway)" (Marty Cagan(SVPG), Forward Deployed Engineers). 그래서 FDE는 로드맵의 상류에서 일하고, 컨설턴트는 계약의 하류에서 일합니다.
이 모델은 2025년 들어 AI 업계의 "가장 뜨거운 직무" 가 됐습니다. a16z는 FDE를 두고 "기업이 AI를 사는 건 할머니가 아이폰을 사는 것과 같다 — 쓰고는 싶은데 누가 세팅해 줘야 한다" 고 표현했습니다 (Pragmatic Engineer, Forward Deployed Engineers, 2025-08). 실제로 OpenAI는 2026년 40억 달러 규모의 배치 전담 회사를 세워 FDE를 제도화했고 (OpenAI, Deployment Company), Anthropic·Google·Salesforce도 앞다투어 FDE를 채용했습니다 (Semafor, The new hot job in AI).
저는 여기서 우리 자신을 봤습니다.
우리는 이미 현장으로 들어가는 SI를 하고 있었습니다. 부족했던 것은 FDE의 나머지 절반 — 현장에서 배운 것을 환류시켜, 다음 고객을 더 빠르게 만드는 장치였습니다.
그래서 우리는 이 여정에서 만든 장치를 두 이름으로 또렷이 나눠 못 박았습니다.
- DCS-하네스 — 현장의 지식을 환류시켜 본방 플랫폼의 품질을 끌어올리는 장치 (3장에서 설명)
- DCS-헤르메스 — 그 지식을 이용해 현장 지원 개발자를 서포트하는 장치 (5장 이후에 설명)
SI에 글자 하나, A. 그것이 AI였고, 동시에 환류(feedback)의 A 이기도 했습니다. 이 글의 두 축이 바로 이 둘 — DCS-하네스와 DCS-헤르메스 — 이며, 둘 다 보안 경계를 깨지 않고 그 A를 실현했습니다.
2. 보수적일 수밖에 없었던 이유 — 보안이 세운 벽
SI-SM이 AI 앞에서 망설인 데에는 이유가 있었습니다. 플랫폼 회사와 출발선이 다르기 때문입니다.
순수 SaaS 플랫폼 조직은 자기 코드, 자기 인프라 위에서 움직입니다. 새 AI 도구가 나오면 일단 붙여 보면 됩니다. 그런데 SI-SM은 다릅니다 — 고객의 코드, 고객의 인프라, 고객의 보안 규정 위에서 일합니다. 금융·공공·대기업 고객일수록 규정은 단단합니다.
| 플랫폼 조직 | SI-SM 조직 |
|---|---|
| 내 코드 / 내 인프라 | 고객 코드 / 고객 인프라 |
| AI에 코드 보내도 내 책임 | 고객 코드를 외부로? 계약 위반 |
| 빠르게 실험 | 보안 검토 먼저 — 보수적일 수밖에 |
그래서 SI-SM 현장에서 "AI 써 보자" 는 말은 종종 "고객 코드를 클라우드 AI에 보내자" 로 들렸고, 그 순간 대화가 끝났습니다. 망설임은 게으름이 아니라 거버넌스(governance) 였습니다.
우리가 풀려던 문제는 단순히 "DCS팀이 AI를 어떻게 쓸까" 가 아니었습니다. "가장 보수적인 SI-SM 환경에서, 보안을 한 치도 양보하지 않으면서 어떻게 AI의 이득을 가져올까" 였습니다.
이 제약은 나중에 보면 선물이었습니다. 보안을 전제로 설계하니, 무엇을 정원 안에 두고 무엇을 정원 밖으로 내보낼지의 경계가 처음부터 또렷했기 때문입니다. 그 경계 위에서 두 개의 정원이 자랐습니다 — 하나는 본방의 하네스, 다른 하나는 그 지식을 나르는 헤르메스.
3. 본방 개발팀 — 엔터프라이즈 하네스로 품질을 끌어올리다
먼저 본방 이야기입니다. 여기서 본방(本-) 은 저희가 플랫폼 본체 — 고객 맞춤 구축의 뿌리가 되는 코어 솔루션을 부르는 말입니다. 이 본방의 품질이 곧 모든 납품물의 품질이 됩니다.
본방 개발팀은 이 시리즈를 읽은 분에게 익숙한 것을 만들었습니다 — 또 하나의 하네스 정원입니다. 1편의 문서 정원, 4편의 디자인 정원과 같은 흙, 같은 3층 구조입니다.
| 하네스 3층 | 비유 | 본방 엔터프라이즈 하네스 |
|---|---|---|
| ☀️ 햇빛 (knowledge) | 무엇이 옳은지의 기준 | 도메인 지식 · 휴리스틱 · 컨벤션 |
| 🌱 꽃 (agents) | 실제 검수·분석의 주체 | 7명의 전문가 에이전트 |
| 💧 줄기/물길 (engine) | 일이 흐르는 순서 | 분석 → 산출 워크플로우 |
여기에 열매(미션), 일지(로그), 도서(버전 일지) 가 더해집니다. 1편에서 본 정원의 문법 그대로입니다. 다만 이 정원이 키우는 꽃은 엔터프라이즈 SI에 특화된 전문가들이었습니다.
3-1. 정원에 핀 일곱 송이 — SI 특화 전문가들
제가 특히 아끼는 세 송이를 소개합니다. 셋 다 이 시리즈가 앞에서 다룬 개념과 정확히 이어집니다.
도메인 분석가 (domain-analyst) — 3편의 현자가 SI 현장에 내려오다
SI에서 가장 먼저 부딪히는 벽은 "이 코드가 대체 무슨 도메인인가" 입니다. 고객이 5년, 10년 굴린 시스템을 인수하면, 그 안의 업무 규칙은 코드·DB·이슈 트래커에 흩어진 채 아무도 전체를 모르는 상태입니다.
도메인 분석가는 이걸 DDD(Domain-Driven Design, 도메인 주도 설계) 관점으로 추출합니다 — 코드와 DB와 문서에서 경계된 컨텍스트(Bounded Context), 유비쿼터스 언어(Ubiquitous Language), 애그리거트(Aggregate) 를 카드로 뽑아냅니다.
3편에서 기획자가 에반스의 유비쿼터스 언어로 도메인의 언어를 잡았던 것 기억하시나요 (3편 참고). 그 현자가 이번엔 남이 짠 레거시 코드 한복판으로 내려왔습니다. 같은 사상, 다른 전장(戰場)입니다.
아키텍트 (architect) — 추정이 아니라 결정으로
분석만으로는 부족합니다. 인수한 시스템을 어떻게 다시 세울지는 설계의 영역입니다. 아키텍트 에이전트는 IDDD(Implementing Domain-Driven Design) 패턴과 ADR(Architecture Decision Record, 아키텍처 결정 기록) 로, "왜 이렇게 설계했는가" 를 글로 남깁니다. 추정이 아니라 추적 가능한 결정으로요.
코드 코치 (code-coach) — 그리고 검증은 추정을 거부한다
가장 중요한 원칙은 이것이었습니다 — 코드 검증 없는 추정 분석을 금지한다. 분석가가 "아마 이럴 것이다" 라고 말하면, 그 주장은 실제 코드로 검증되어야 했습니다. 그래서 분석에 L1 / L2 / L3 깊이 단계를 두고, 깊은 단계일수록 외부 검증 채널을 거치게 했습니다.
여기서 2편의 CodeScan 이 등장합니다 (2편 참고). 코드를 SQLite + 그래프 별자리로 인덱싱해 두면, "이 클래스를 진짜로 쓰는 곳이 어디인가" 가 추정이 아니라 한 줄 쿼리의 사실이 됩니다. 코드 코치의 검증 단계는 이 별자리 위에서 움직입니다.
3-2. 정원에 사는 것은 지식, 정원 밖으로 나가는 것은 산출물
이 정원이 처음부터 못 박은 규칙 하나가 제 마음에 가장 오래 남았습니다.
정원에 사는 것은 지식이고, 정원 밖으로 나가는 것은 산출물이다.
분석으로 쌓인 재사용 가능한 지식(휴리스틱, 도메인 매트릭스)은 정원 안(knowledge)에 누적됩니다. 반면 고객에게 건넬 산출물(분석 보고서, 설계 문서)은 정원 밖의 산출 트리로 나갑니다. 이 분리가 FDE의 핵심 — "현장에서 배운 것을 핵심으로 환류" — 를 그대로 구현합니다.
| 자산 | 어디에 | 왜 |
|---|---|---|
| 도메인 지식 · 휴리스틱 | 정원 안 (knowledge) | 다음 프로젝트가 재사용 — 자갈길이 포장도로로 |
| 분석/설계 산출물 | 정원 밖 (산출 트리) | 이 고객을 위한 결과물 — 환류 대상 아님 |
한 프로젝트가 끝날 때마다 정원의 흙이 비옥해집니다. 다음 고객의 분석은 더 빨라집니다. 인력 수에 묶여 매번 처음부터 시작하던 SI가, 처음으로 축적을 갖게 된 순간이었습니다.
솔직히 고백하면, 우리는 이걸 그냥 분석 자동화라고 생각하며 시작했습니다. 그런데 1편의 정원 비유를 다시 읽고서야 깨달았습니다 — 우리가 만든 건 SI 활동 자체를 표준화하는 정원이었고, FDE의 환류 루프를 보안 경계 안에서 재현한 것이었습니다.
이 절은 사내 위키 「Blumn Enterprise Harness」의 공개 가능한 골격만 옮긴 것입니다. 고객 고유 도메인·프로젝트 식별자는 의도적으로 비웠습니다.
4. 유지보수의 진짜 비용 — 코드를 '읽는' 시간
이제 두 번째 축, 유지보수(SM) 로 넘어갑니다. 본방을 잘 지어 놓아도, 그것을 오래 지키는 일은 전혀 다른 난이도였습니다.
소프트웨어 비용에 대한 오해가 하나 있습니다 — "개발이 끝나면 비용도 끝난다" 는 착각입니다. 1970~80년대에 Lientz와 Swanson이 487개 조직을 조사한 고전적 연구는 정반대를 보여 줬습니다. 유지보수가 소프트웨어 생애 비용의 대부분을 차지하고, 그중 절반 이상은 버그 수정이 아니라 기능 개선(perfective) 이다 (Lientz, Swanson & Tompkins, Problems in application software maintenance, CACM 1978). 흔히 인용되는 "생애 비용의 60~80%가 유지보수" 라는 업계 통설의 뿌리가 여기입니다.
그런데 AI 시대에 더 아픈 진실은 따로 있었습니다.
레거시·인수 코드를 다룰 때 개발자는 코드를 쓰는 시간보다 읽는 시간에 압도적으로 많이 씁니다. 병목은 생성이 아니라 이해입니다 (arXiv:2504.04553, Understanding Codebase like a Professional).
이게 왜 아픈가 하면 — AI 코딩 도구의 첫 세대는 코드를 빠르게 써 주는 데 강했기 때문입니다. 정작 SM 개발자가 막힌 곳은 "이 코드가 왜 이렇게 짜여 있고, 어디를 건드리면 무엇이 깨지는가" — 이해였습니다. 새 도구가 코드를 아무리 빨리 뱉어도, 인수한 시스템을 이해하지 못하면 그 코드는 위험할 뿐이었습니다.
4-1. 그리고 지식은 사람과 함께 떠난다 — 버스 팩터
여기에 한국형 SI-SM 특유의 문제가 겹칩니다. 짓던 사람이 떠나면, 지식도 함께 떠납니다.
이걸 부르는 이름이 있습니다 — 부족 지식(tribal knowledge) 과 버스 팩터(bus factor). 특정 개인만 아는 정보가 너무 많으면, 그 사람이 버스에 치이면(=팀을 떠나면) 팀 전체가 마비됩니다 (Wikipedia — Tribal knowledge; arXiv:2401.03303, Bus Factor Analysis).
전통적으로 이 지식은 인수인계 문서로 넘깁니다. 그런데 문서는 늘 낡고, 늘 부족합니다. DORA의 2024년 연구조차 문서 품질이 팀 성과의 핵심 변수임을 거듭 확인했지만 (DORA 2024 State of DevOps Report), 현실의 인수인계 문서는 "코드를 보세요" 한 줄로 끝나기 일쑤였습니다.
유지보수를 처음 맡은 개발자가 마주하는 건, 친절한 문서가 아니라 거대한 침묵의 코드 산이었습니다. 물어볼 사람은 이미 다른 프로젝트로 떠났고요.
바로 이 지점에서, 우리는 전령 하나를 띄우기로 했습니다.
5. 헤르메스 — 본방의 지식을 유지보수팀에게 나르는 전령
그리스 신화에서 헤르메스(Hermes) 는 신들의 전령입니다. 경계를 넘나들고, 여행자를 지키며, 메시지를 한 세계에서 다른 세계로 나르는 신이죠. 그런데 이 이름은 은유만이 아니었습니다 — 헤르메스는 실재하는 오픈소스 에이전트의 이름이기도 합니다.
5-0. 먼저, 헤르메스 에이전트란 — OpenRouter 1위의 자율 에이전트
Hermes Agent 는 Nous Research가 공개한 오픈소스 자율 에이전트 프레임워크입니다. 2026년 5월, OpenRouter(여러 AI 모델·앱의 토큰 사용량을 집계하는 라우팅 마켓플레이스)의 글로벌 토큰 랭킹 전체 1위에 올랐습니다 (Hermes Agent — OpenRouter; Nous Research 발표). 챗봇도, 코딩 코파일럿도 아닙니다 — 자기 인프라에서 상주 실행되고, 세션을 넘어 기억하며, 경험에서 재사용 가능한 스킬을 스스로 만들어 가는 닫힌 학습 루프형 에이전트입니다 (MarkTechPost, 2026-05).
이 한 줄에 우리가 헤르메스를 고른 이유가 다 들어 있습니다.
"자기 인프라에서 상주 실행된다" — MIT 라이선스의 오픈소스이고, 클라우드 API에 의존하지 않고 우리가 통제하는 환경에서 돌릴 수 있다는 뜻입니다. 2장의 보안 벽을 넘을 수 있는, 거의 유일한 형태였습니다.
여기에 우리가 더한 것이 위 카드의 Hermes Agent v0.7.0 — Hermes × BlumnAI 입니다. 오픈소스 헤르메스 위에, 우리 정원의 도구와 스킬을 꽃처럼 피웠습니다 — "헤르메스에 꽃이 피다(Intelligence, in full bloom)."
| 헤르메스가 가져온 것 (오픈소스 토대) | 우리가 피운 꽃 (BlumnAI 빌드) |
|---|---|
| 자기 인프라 상주 실행 · 닫힌 학습 루프 | 격리 환경 배치 + 보안 거버넌스 (6장) |
| Plan · Reason · Tool Use · Memory · Reflection 스킬 | CodeScan(코드 분석) · delegate_task · file · image_gen 도구 |
| 경험에서 재사용 스킬 생성 | 본방 하네스의 지식 누적(3장)과 맞물림 |
4편에서 "하네스는 특정 도구에 종속되지 않는다" 고 했습니다 (4편 참고). 헤르메스는 그 명제의 또 다른 증명입니다 — 도구(에이전트)는 오픈소스로 가져오되, 그 위에 피우는 꽃(우리의 지식과 검수)은 우리 것. 토대가 바뀌어도 꽃은 옮겨 심으면 됩니다.
그리고 한 가지가 더 중요합니다. 헤르메스가 코드를 새로 짜 주는 도구가 아니라는 점입니다. 4장에서 봤듯 SM의 병목은 이해였습니다. 그래서 우리 빌드에서 헤르메스의 핵심 능력은 코드를 분석해 설명하는 것 — 생성이 아니라 해독입니다.
5-1. 전령의 손에 들린 망원경 — CodeScan
헤르메스가 코드를 해독하는 눈은 CodeScan(2편)입니다. 2편에서 소개한 그 도구 — 코드를 SQLite + FTS5 + 그래프 별자리로 인덱싱하는 단일 바이너리 — 가 바로 헤르메스의 분석 엔진입니다.
이 조합이 SM 환경에 맞은 이유는 2편의 설계 결정과 정확히 맞물립니다.
| CodeScan의 성질 (2편) | SM/보안 환경에서의 의미 |
|---|---|
| 단일 바이너리, 런타임 의존 0 | 노트북에서도, 격리망 안에서도 그대로 작동 |
| 빌드 없이 정규식 우선 분석 | 인수한 레거시가 빌드 안 돼도 일단 별자리를 그린다 |
| MCP 상주 아님 — 스킬+CLI 호출 | 필요할 때만 부르고 끝 — 상시 외부 연결 없음 |
| 결과가 텍스트 메타로도 표현 | 사람과 AI가 같은 것을 본다 — 검증 가능 |
2편에서 "코드는 점점 설명하기 어려워지지만, 코드를 보는 도구는 설명 가능해야 한다" 고 했습니다. 헤르메스는 그 문장을 SM 현장에서 실현합니다. 처음 보는 코드 앞에서, 전령이 먼저 별자리를 펼쳐 보여 줍니다.
CodeScan은 사전 구축된 AI CLI 도구로 노트북에서도 돌고, 헤르메스 에이전트에 탑재되어 작동합니다. 고객이 요구하는 보안 제약 수위에 따라 — 완전 격리부터 사내 통제망까지 — 대응 형태를 바꿀 수 있게 설계했습니다.
6. 격리된 정원 — 납품 전에, 우리 비용으로, 안전하게
여기서 2장의 보안 벽으로 돌아옵니다. 헤르메스가 고객 코드를 이해하려면 그 코드를 봐야 하는데, 고객 코드는 함부로 외부로 나갈 수 없습니다. 모순처럼 보이는 이 지점을, 우리는 장소와 시점과 비용을 바꿔서 풀었습니다.
헤르메스는 고객에게 납품된 인프라에서 돌지 않습니다. 납품되기 전, 우리의 격리된 공간에서, 우리의 AI 비용으로 지식을 빚습니다.
이게 핵심입니다. 보안이 중요한 고객의 운영 인프라를 건드리는 대신, 납품 전 단계의 격리된 환경에서 — 우리가 책임지는 비용으로 — 코드를 분석해 유지보수 매뉴얼과 아이디어를 미리 빚어 둡니다. 그렇게 빚어진 지식이 나중에 고객의 새로운 기능 요구가 들어왔을 때 더 빠른 대응으로 이어집니다. 이것이 우리가 적용한 보안 거버넌스였습니다.
이게 가능했던 건 5장에서 본 헤르메스의 성질 덕이었습니다. 헤르메스 에이전트는 자기 인프라에서 도는 오픈소스 라, 코드를 외부 API로 내보내지 않고 격리망 안에 통째로 들여놓을 수 있었습니다. 만약 헤르메스가 클라우드 전용 SaaS였다면, 2장의 보안 벽 앞에서 첫걸음도 못 뗐을 겁니다.
6-1. 격리에는 등급이 있다
"AI에 코드를 보낸다"는 한 문장 안에는 사실 전혀 다른 위험 등급이 숨어 있습니다. 우리는 이걸 또렷이 나눴습니다.
| 등급 | 형태 | 코드가 어디까지 나가나 |
|---|---|---|
| ① 호스티드 API 직접 호출 | 외부 모델 API로 코드 전송 | 외부로 — SI 고객에겐 대개 불가 |
| ② VPC 격리 관리형 | 내 클라우드 계정 경계 안에서 추론 | 내 경계 안 — 외부 제공자 접근 차단 |
| ③ 완전 격리(에어갭) | 망 자체가 봉인된 환경 | 망 밖으로 전혀 안 나감 |
이 구분이 막연한 불안을 설계 가능한 선택으로 바꿔 줍니다. 예컨대 ②번 — 관리형 VPC(Virtual Private Cloud, 가상 사설 클라우드) — 만 해도, 주요 클라우드의 기반 모델 서비스는 고객 입력·출력을 모델 제공자와 공유하지 않고, 기반 모델 학습에 쓰지 않으며, 프라이빗 엔드포인트로 트래픽이 공개 인터넷을 타지 않게 할 수 있습니다 (AWS Bedrock — Security, privacy & responsible AI). 모델 제공자 측 약관도 마찬가지로 상업 제품의 입출력을 학습에 쓰지 않음을 명시합니다 (Anthropic — Is my data used for model training?). 가장 단단한 고객에게는 ③번 — 코드가 망 밖으로 한 바이트도 나가지 않는 에어갭(air-gapped) 배치 — 까지 갑니다 (TrueFoundry — Air-gapped AI).
보안은 "AI를 쓰느냐 마느냐" 의 0/1 스위치가 아니었습니다. 어느 등급의 격리 위에서 쓰느냐의 다이얼이었습니다. SI-SM이 망설인 건 스위치를 1로 못 올려서가 아니라, 다이얼이 있다는 걸 아무도 명시해 주지 않아서였습니다.
납품 전 격리 환경에서 우리 비용으로 지식을 빚는 헤르메스는, 이 다이얼을 고객 보안 등급에 맞춰 돌릴 수 있는 전령이었습니다.
7. SI 개발자에게 보내는 복지 — 과거 vs AI 이후
저는 헤르메스를 기술 장치로만 보지 않습니다. 저에게 이건 SI 개발자를 위한 복지입니다. 이유는 과거를 떠올리면 분명합니다.
| 과거 (AI 활용 불가) | AI 이후 (헤르메스) | |
|---|---|---|
| 사소한 문의 한 건 | 중간 PM 경유 → 게시판 → 별도 DM 라인 | 헤르메스에게 직접 질문 |
| 처음 맡은 유지보수 | "코드 보세요" 한 줄 | 코드 분석 기반 기본 지식·개발 방법 제공 |
| 답이 오기까지 | 며칠, 때론 끝내 못 받음 | 즉시, 그리고 근거(코드)와 함께 |
과거에는 작은 질문 하나를 해결하려고 개발자가 너무 많은 사람을 거쳐야 했습니다. PM을 붙잡고, 게시판에 글을 올리고, 누군가의 DM을 기다리고. 그 사이 개발은 멈췄고, 묻는 사람도 답하는 사람도 지쳤습니다.
헤르메스가 바꾼 건 답의 정확도만이 아니었습니다. 묻는 데 드는 사회적 비용을 없앴습니다. 신입이 "이런 걸 물어봐도 되나" 를 고민하지 않게 됐습니다. 코드에게 직접 물으면, 코드가 근거와 함께 답하니까요.
이건 막연한 기대가 아닙니다. AI 코딩 도구가 새 개발자의 온보딩을 며칠씩 단축한다는 보고는 여럿 있습니다 — 한 대규모 사내 연구(400+ 개발자)는 코딩 도구의 제안 수용률 33%, 개발자 만족도 72%를 보고했고 (arXiv:2501.13282, Copilot at ZoomInfo), 통제 실험에서는 특정 과제를 55% 빠르게 끝냈다는 결과도 있습니다 (GitHub Research). 우리의 헤르메스는 이 효과를 처음 코드를 인수한 SM 개발자에게 정확히 겨눴습니다.
유지보수팀이 행복하면, 그 팀이 만지는 플랫폼의 품질이 올라가고, 그 플랫폼을 쓰는 최종 고객도 행복해집니다. 헤르메스는 이 행복의 사슬에 놓인 첫 번째 도미노였습니다.
8. 초청받은 채널 — 슬랙·디스코드에서 함께 일하는 AI
헤르메스가 사는 곳은 IDE 안이 아니라, 팀이 이미 모여 있는 곳 — 채팅 채널이었습니다.
우리는 보안 인증된 슬랙·디스코드 채널에 초청 권한 방식으로 헤르메스를 들였습니다. 아무 채널에서나 부를 수 있는 게 아니라, 초청된 채널 안에서만 작동합니다. 그 채널 안에서는 —
- 분석한 코드를 집단이 함께 공유합니다. 한 사람의 질문과 답이 채널 전체의 자산이 됩니다.
- 막히면 헤르메스를 호출해 묻습니다. AI가 코드 근거와 함께 답합니다.
- AI가 완전히 못 푸는 문제는 테크팀으로 에스컬레이션됩니다. AI가 1차 방어선, 사람이 최종 방어선입니다.
이 그림이 익숙하게 들린다면, 그럴 만합니다. 최근 클로드 코드가 슬랙에 출시한 기능과 거의 같은 모양이기 때문입니다.
Anthropic은 2025년 12월 8일 Claude Code in Slack을 리서치 프리뷰로 공개했습니다 — 채널에서 Claude를 @멘션하면 최근 메시지(버그 리포트·기능 요청)를 읽고, 알맞은 저장소를 찾아, 코드를 쓰고, 진행 상황을 스레드에 올립니다 (TechCrunch, 2025-12-08; Anthropic — Claude and Slack). 그리고 2026년 6월에는 슬랙 앱을 대체하는 상주형 AI 동료 Claude Tag까지 나왔습니다 (Anthropic — Introducing Claude Tag).
우리가 자랑하고 싶은 건 "우리가 더 먼저 했다" 는 선후가 아닙니다. 핵심은 이겁니다 —
업계가 "AI를 IDE 밖, 팀이 모인 채팅으로" 옮겨 가기 전에, 우리는 보안 제약이 가장 빡빡한 SI-SM 현장에서 그 협업 형태를 이미 준비하고 있었습니다. 대세가 옳았다는 걸, 우리는 가장 보수적인 땅에서 먼저 확인한 셈입니다.
이건 4편에서 디자이너 제나가 "규칙서를 Claude·Codex·Gemini 모두에게 통과시켰다" 고 한 것과 같은 신념입니다 (4편 참고) — 하네스는 특정 도구에 종속되지 않는다. 헤르메스의 협업 형태도 특정 벤더의 기능이 아니라 우리가 설계한 일하는 방식이었기에, 슬랙이든 디스코드든, 클로드든 코덱스든 그 위에 얹힐 수 있었습니다. 벤더가 같은 기능을 내놓으면? 우리는 갈아타면 됩니다. 형태는 우리 것이니까요.
9. 스레드에서 함께 캐는 지식 — 헤르메스에게 묻는 법
8장이 "AI를 어디에 두는가(채널)" 였다면, 이 장은 "그래서 실제로 어떻게 쓰는가" 입니다. 헤르메스는 여러 채널에서 코드 분석가로 일합니다. 그 방식은 단순하면서도, 한 가지 중요한 설계를 품고 있습니다 — 스레드.
9-1. 한 번의 호출이 스레드를 연다
채널에서 헤르메스를 호출하면, 헤르메스는 그 자리(채널 본류)에 답을 쏟지 않습니다. 대신 전용 스레드를 엽니다.
스레드는 한 주제만을 위한 격리된 작업 공간입니다. 채널 본류는 깨끗하게 두고, 한 질문을 깊게 팝니다. 6장의 격리가 보안의 경계였다면, 스레드는 대화의 경계입니다.
이 작은 결정이 큰 차이를 만듭니다. 질문이 곁가지로 번져도 채널 전체를 어지럽히지 않고, 나중에 "그 주제 어디서 얘기했지?" 를 찾을 때 스레드 제목 하나로 도달합니다.
9-2. 묻는 것은 "일반적인 기술" — 실제 질문 예시
중요한 전제가 있습니다. 헤르메스에게 묻는 것은 고객 고유의 비밀이 아니라, 일반적인 기술 구조와 개선 지점입니다. (민감한 도메인은 애초에 묻지도, 답하지도 않도록 경계를 둡니다 — 6장.)
실제로 오가는 질문은 이런 결입니다.
| 현업 개발자의 질문 | 헤르메스가 답하는 방식 |
|---|---|
| "이 플랫폼은 어떻게 구성되어 있나요?" | CodeScan 별자리로 모듈·의존 구조를 펼쳐, 어디가 허브이고 어디가 경계인지 설명 |
| "상담 분배 로직을 개선하려면 어디를 손대야 하나요?" | 관련 코드 경로와 변경 영향 범위를 짚어, 손댈 후보 지점을 좁혀 줌 |
| "이 모듈을 바꾸면 무엇이 깨지나요?" | 그래프를 따라 호출자·의존을 추적해 파급 범위를 미리 보여 줌 |
답의 형태가 핵심입니다. 헤르메스는 "이렇게 고치세요" 라는 정답을 내려 주지 않습니다. "여기를 보세요, 이것과 엮여 있어요" 라는 지도를 펼칩니다. 결정은 사람이, 길 안내는 전령이.
9-3. 혼자 묻지 않는다 — 협업 지식 탐사
스레드의 진짜 힘은 1:1 대화가 아니라는 점에 있습니다. 스레드는 초청된 동료들이 함께 들여다보는 공간입니다.
A가 묻는다 → 헤르메스가 코드로 답한다 → B가 자기 경험으로 보강한다
→ 테크팀이 검증·정정한다 → 스레드 하나가 '살아있는 지식 조각'이 된다
한 사람의 막힘이 모두의 지식으로 바뀝니다. 5장에서 본 Hermes Agent의 성질 — "경험에서 재사용 가능한 스킬을 만든다" — 이, 사람과 AI가 함께 채우는 형태로 실현됩니다.
9-4. 스레드에서 지식을 갱신하는 법 — 장점과 주의
이 방식은 만능이 아닙니다. 장점과 주의할 점을 함께 적습니다 — 솔직한 것이 오래 갑니다.
| 기법 | 장점 | 주의할 점 |
|---|---|---|
| 주제별 스레드 격리 | 맥락 유지, 나중 검색이 쉬움 | 주제가 번지면 스레드가 비대 — 새 스레드로 분기 |
| 집단 열람·보강 | 한 답이 모두의 자산, 빠른 보강 | 잘못된 답도 같이 퍼짐 → 테크팀 검증이 안전판 |
| 점진적 갱신 | 지식이 낡지 않고 살아 있음 | 최신/낡음 구분 표식 필요 — 오래된 스레드는 날짜로 신뢰 조정 |
| AI 1차 + 사람 최종 | 초안이 즉시, 근거(코드)와 함께 | 과신 금지 — 헤르메스의 답은 출발점이지 결론이 아님 |
가장 위험한 실패는 "헤르메스가 그랬어요" 로 검증을 건너뛰는 것입니다. 그래서 규칙 하나를 둡니다 — 헤르메스의 답은 항상 코드라는 근거를 동반하고, 그 근거를 사람이 한 번은 눈으로 확인한다. (3장의 "코드 검증 없는 추정 금지" 가 여기서도 작동합니다.)
9-5. 현업 개발자가 '고급 개발 지식'을 묻는다는 것
마지막으로, 이 장이 닿으려는 진짜 지점입니다. 헤르메스를 통해 현업 개발자가 우리 DCS형 솔루션(본방)에게 직접 고급 개발 지식을 물을 수 있게 됐다는 것.
예전에는 "이 구조가 왜 이런지" 를 아는 사람이 떠나면 그 지식도 떠났습니다(4장의 버스 팩터). 이제는 본방 자체에게 묻습니다 — "왜 이렇게 설계됐나요?", "여기를 개선하려면?". 그리고 그 답이 다음 개선의 기초 지식이 됩니다.
헤르메스의 답은 끝이 아니라 시작입니다. 한 번의 질문이 연 스레드가, 다음 개선 작업의 출발점이 됩니다. 1장에서 본 FDE의 환류 루프 — 현장에서 배운 것이 다음을 빠르게 한다 — 가, 유지보수 개발자의 질문 하나하나로 돌기 시작합니다.
현업의 질문이 지식이 되고, 그 지식이 개선의 씨앗이 되고, 개선이 다시 본방의 품질을 올립니다. 7장에서 말한 행복의 사슬이, 바로 이 스레드 안에서 한 칸씩 이어집니다.
10. 마치며 — 유지보수팀이 행복하면, 고객도 행복하다
이 글을 두 문장으로 줄이면 이렇습니다.
본방은 하네스로 품질을 쌓고, 그 지식은 헤르메스가 유지보수팀에게 나른다. 둘 다 보안 경계를 깨지 않고 일어난다.
가장 보수적이라던 SI-SM 환경이, 알고 보니 AI를 가장 또렷하게 설계할 수 있는 땅이었습니다. 경계가 분명했기 때문입니다 — 무엇이 정원 안에 남고(지식), 무엇이 밖으로 나가며(산출물), 코드가 어느 격리 등급까지 움직이는가. 막연한 "AI 되네 안 되네" 가 아니라, 다이얼을 어디에 맞출지의 문제였습니다.
그리고 그 끝에는 사람이 있었습니다.
SI에 글자 'A' 하나를 더하면 AI가 됩니다. 하지만 그 A는 자동화(Automation) 의 A이기 이전에, 환류(feedback)의 A이자, 사람을 위한 배려(care)의 A였습니다. 유지보수팀이 침묵의 코드 산 앞에서 덜 외롭도록, 신입이 "이런 걸 물어도 되나" 를 고민하지 않도록.
팔란티어의 FDE가 현장에서 배운 것을 제품으로 환류시켜 다음 고객을 빠르게 만들었듯, 우리의 하네스는 한 프로젝트의 지식을 정원에 누적시켜 다음 유지보수를 빠르게 만들었습니다. 다른 점이 있다면, 우리는 그 모든 걸 고객의 보안을 한 치도 양보하지 않는 격리된 정원 안에서 해냈다는 것입니다.
이건 우리 시리즈에서 처음으로 정원이 '납품'과 '유지보수'라는 시간 축으로 확장된 기록입니다. 1편은 문서를, 3편은 기획을, 4편은 디자인과 프론트를 다뤘지만, 모두 만드는 순간의 이야기였습니다. 이번엔 처음으로 — 짓고 나서 오래 지키는 일, 그리고 그 일을 하는 사람을 위한 전령까지 정원이 품었습니다.
혹시 지금 "우리 같은 SI/SM 환경에선 AI가 안 돼" 라고 느끼고 있다면, 먼저 격리 등급 다이얼부터 그려 보길 권합니다. AI를 쓸지 말지를 묻기 전에, 어느 경계 위에서 쓸지를 그리면 — 닫혀 있던 문이 의외로 한 칸씩 열립니다.
그리고 그 문을 열 때, 혼자 열지 마세요. 본방 개발자와 유지보수 엔지니어가 같은 배에 타야 합니다. 본방이 지식을 쌓고, 헤르메스가 그것을 나르고, 유지보수팀이 그것으로 고객을 행복하게 합니다. 그 행복의 사슬이 끊기지 않을 때, 비로소 SI에 더한 A가 제값을 합니다.
Festina lente. — 천천히 서둘러라. 보안은 천천히, 그러나 AI의 이득은 서둘러. 헤르메스의 날개는 그 둘을 동시에 신을 때 비로소 펴집니다.
하네스의 이야기는 계속됩니다. 감사합니다. 💙
참고
- 시리즈 본거지:
- 블룸AI 하네스 시리즈
- BlumnAI-Studio/harness-kakashi — 하네스 카카시 배포팩
- 팔란티어 FDE · 전진 배치 모델:
- Palantir, Dev versus Delta: Demystifying engineering roles at Palantir
- Palantir, A Day in the Life of a Palantir Forward Deployed Software Engineer
- Marty Cagan (SVPG), Forward Deployed Engineers
- Gergely Orosz (Pragmatic Engineer), Forward Deployed Engineers, and why they are in demand (2025-08)
- PostHog, WTF is a forward deployed engineer?
- Semafor, The new hot job in AI: forward-deployed engineers (2025-07)
- OpenAI, OpenAI launches the Deployment Company (2026-05)
- Wikipedia, Forward Deployed Engineer
- 한국형 SI-SM:
- JobKorea, [IT 취업 가이드] SI와 SM 업무의 차이
- 유지보수 비용 · 코드 이해 · 지식 전수:
- Lientz, Swanson & Tompkins, Problems in application software maintenance (Communications of the ACM, 1978)
- Understanding Codebase like a Professional — Human–AI Collaboration for Code Comprehension (arXiv, 2025)
- Experience with GitHub Copilot for Developer Productivity at Zoominfo (arXiv:2501.13282, 2025)
- GitHub Research — Copilot's impact on productivity & happiness
- Wikipedia, Tribal knowledge · Bus Factor Analysis (arXiv:2401.03303, 2024)
- DORA, 2024 Accelerate State of DevOps Report
- 헤르메스 에이전트 (Hermes Agent · Nous Research):
- AI 협업 채널 (슬랙/디스코드) · 보안 격리:
- TechCrunch, Claude Code is coming to Slack (2025-12-08)
- Anthropic, Claude and Slack · Introducing Claude Tag (2026-06)
- Anthropic, Is my data used for model training?
- AWS, Security, privacy, and responsible AI — Amazon Bedrock
- TrueFoundry, Air-gapped AI: deploying enterprise LLMs in highly regulated industries
- 자매 글:
- 원본 소재:
- 블룸AI DCS팀, 사내 위키 「Blumn Enterprise Harness」 (엔터프라이즈 SI 활동 표준화 정원 — 공개 가능한 골격만 인용, 고객 고유 도메인·식별자는 비공개) — 이 글은 그 기록과 DCS 현장 경험을 하네스 시리즈 5편으로 재구성한 1인칭 판본이다.