앞붙이

사례 배경: 가람시(가상)

이 책의 장마다 등장하는 가상 기초자치단체 가람시를 소개한다. 연혁, 정보시스템과 망 구성, 부서별 AX 요구, 목표와 장애 요인, 그리고 이 책에서 가람시가 밟아 갈 여정을 정리한다.

이 장에서 얻을 것

가람시의 망 구성과 환경 조건을 E1~E5 축으로 말할 수 있다
부서별 AX 요구와 그것이 떠올리게 하는 주 부품 후보를 안다
가람시 AX팀의 목표와 장애 요인을 안다
장마다 가람시 이야기가 어디까지 진행되는지 안다

Erl의 SOA 책들은 가상 기업 몇 곳의 이야기를 책 전체에 깔아 둔다. 2장에서 배경을 세우고 장마다 그 기업이 다음 결정을 내린 뒤, 마지막 부록에서 처음 목표를 다시 평가한다. 이 책은 같은 장치를 공공기관에 맞게 쓴다. 주인공은 기초자치단체 하나다. 기관이 공식으로 추진하는 사업과 공직 개인의 자생 도구가 한 조직 안에서 함께 자라는 곳이 기초자치단체이기 때문이다.

연혁

사례 연구 · 가람시(가상)

인구 40만 도시의 행정 전산 이력

가람시는 인구 약 40만의 가상 기초자치단체다. 도심 주거지와 하천을 낀 외곽 농촌이 섞여 있고, 여름이면 하천 수위가 시정의 큰 관심사가 된다. 본청 직원은 1,500명 남짓이고, 민원 창구와 콜센터, 재난안전상황실을 직접 운영한다.

시의 전산 이력은 다른 자치단체와 크게 다르지 않다. 업무망과 인터넷망을 나눈 뒤로 직원 대부분은 책상에 두 대의 PC를 두거나 망 전환 프로그램을 쓴다. 문서는 전자결재와 문서관리 시스템에서 HWPX로 만들어지고, 예산·복지·민원은 각각 중앙에서 내려온 표준 업무시스템을 쓴다. 생성형 AI가 시청에 들어온 경로는 공식 사업이 아니었다. 인터넷망 PC에서 개인적으로 상용 챗봇을 써 보던 직원들이 먼저였고, 그 가운데 몇 명은 AI 코딩 도구로 엑셀 취합기나 변환기를 만들어 옆자리 동료와 나눠 쓰기 시작했다.

시는 2025년 정보통신과 안에 세 명짜리 AX팀을 만들었다. 같은 해 행정망 안에 로컬 오픈웨이트 모델을 돌리는 서버 한 대를 들였고, 상용 LLM API를 행정망에서 쓸 수 있도록 내부망 프록시를 시범 운영하기 시작했다. 이 책의 이야기는 그 이듬해 가을, 부서들의 AX 요구가 한꺼번에 AX팀으로 몰려드는 데서 시작한다.

표 K.1은 이 이력을 연표로 정리하고, 사건마다 이어지는 장을 붙인 것이다.

**표 K.1** 가람시(가상) 연표(모두 이 책의 설정)
시기	사건	이후 장과의 연결
2010년대 중반	업무망·인터넷망 분리 완료. 망연계 장치로 파일만 주고받는다.	E1 배포망 조건(4장)
2021년	콜센터 상담 이력과 민원 FAQ를 전산으로 쌓기 시작	민원 상담의 코퍼스(A1, 7장)
2023년	재난안전상황실 통합, 하천 수위 센서와 CCTV를 한 관제 화면으로	감지·경보(B5, 5장)
2024년	일부 직원이 인터넷망 PC에서 상용 챗봇과 AI 코딩 도구를 개인적으로 쓰기 시작	자생 도구(B0·A7, 5·7장)
2025년	정보통신과 AX팀(3명) 신설, 로컬 모델 서버 1대 도입, 내부망 프록시 시범 운영	모델 서빙(A2.2·A2.4, 7장)
2026년 가을	네 부서가 각자 챗봇 구축을 요청. AX팀이 패턴 카탈로그를 펼친다.	1장의 출발점

정보시스템 현황

가람시의 정보시스템은 망 하나로 설명되지 않는다(그림 K.1). 행정망에는 업무 PC, 표준 업무시스템, 업무 데이터, 로컬 모델 서버, 내부망 프록시가 있다. 재난안전상황실은 행정망 안의 별도 구역에서 CCTV와 하천 수위 센서를 받는다. 인터넷망에는 인터넷 PC와 시 홈페이지, 시민 상담 게시판이 있다. 두 망 사이는 망연계 장치가 파일 단위로만 잇는다. 상용 LLM API는 행정망에서 내부망 프록시를 거칠 때만 부를 수 있다.

그림 K.1 가람시(가상)의 망 구성. 행정망 안에 로컬 모델 서버와 내부망 프록시가 있고, 상용 LLM API는 프록시를 거쳐서만 부른다. 재난안전상황실은 별도 구역이며, 직원들이 만든 개인 도구는 관리 체계 밖에 흩어져 있다.

표 K.2는 이 망 구성을 카탈로그의 환경 조건 다섯 축으로 옮긴 것이다. 가람시의 과제는 대부분 이 조건을 기본값으로 시작한다. 4장에서 첫 패턴 서명을 쓸 때 AX팀이 채우는 E 칸이 이 표에서 나온다.

**표 K.2** 가람시(가상)의 환경 조건 기본값
축	가람시의 값	뜻하는 것
E1 배포망	행정망(폐쇄), 일부 업무는 인터넷망 PC	외부 서비스는 망연계나 프록시를 거쳐야 한다.
E2 모델 의존	로컬 오픈웨이트 모델 1대 + 상용 LLM API(프록시 경유)	상용 API 직접 호출은 금지. 모델이 멈출 때의 대체 경로를 따로 정해야 한다.
E3 실행 형태	브라우저, 설치형 도구, 일부 MCP·CLI 설정	개인 도구는 설치형과 MCP가 섞여 있다.
E4 권한 범위	대부분 P0~P1, 업무시스템 쓰기는 아직 없음	P2 이상으로 올라가는 과제는 위험도 분기·롤백·권한 경계를 먼저 갖춘다.
E5 데이터 등급	대부분 S(민감)	S 이상이면 상용 API는 내부망 프록시 없이 쓸 수 없다.

부서별 AX 요구

2026년 가을 AX팀에 들어온 요구는 다섯 갈래다. 네 부서의 공식 요청과, 공식 요청은 아니지만 시청 안에서 이미 돌고 있는 개인 개발 도구다. 그림 K.2는 각 요구가 카탈로그의 어떤 서비스 유형에 닿고, 어떤 주 부품을 떠올리게 하는지를 AX팀의 첫 메모 수준에서 보여 준다. 이 대응은 가설이다. 주 부품은 4장과 2부를 지나며 정해진다.

그림 K.2 가람시(가상)의 다섯 요구와 AX팀의 첫 대응 메모. 왼쪽은 요구 주체, 가운데는 서비스 유형, 오른쪽은 떠오르는 주 부품과 함께 필요해 보이는 부품이다. 개인 개발 도구는 공식 사업 바깥이라 점선으로 이었다.

사례 연구 · 가람시(가상)

다섯 갈래의 요구

민원여권과는 여권·전입·각종 증명 발급 문의가 몰리는 창구다. 콜센터 상담 이력이 몇 년 치 쌓여 있지만, 같은 질문에 상담원마다 다른 답을 하는 일이 잦다. 요구는 "시민이 밤에도 물어볼 수 있는 챗봇"이다. 시민에게 나가는 답변이 산출물이므로, 답마다 근거 규정을 붙이고 답하지 말아야 할 질문은 사람에게 넘겨야 한다.

재난안전과는 여름마다 하천 수위를 지켜본다. 센서 값과 CCTV는 한 화면에 모였지만, 기준을 넘었는지 판단하고 알리는 일은 여전히 관제 요원의 눈에 달려 있다. 요구는 "상황실 질의응답 챗봇"으로 들어왔지만, 이야기를 들어 보면 필요한 것은 감지와 통지다.

기획예산과는 부서 보고서를 모아 요약하고, 기안문을 쓰고, 예산 요구서를 취합한다. 엑셀 서식이 부서마다 달라 취합에 매번 며칠이 걸린다. 요구는 "보고서 작성 챗봇"이다.

복지정책과는 위기가구를 일찍 찾아내고 싶어 한다. 공과금 체납, 상담 기록, 각종 신청 이력에서 신호를 모으면 방문 우선순위가 잡힌다고 복지정책과는 본다. 요구는 "상담 기록 요약 챗봇"이었지만, 더 큰 그림은 예측과 선별이다. 선별이 틀리면 도움이 필요한 가구가 빠지거나 그렇지 않은 가구가 불필요한 방문을 받는다.

개인 개발 공무원들은 공식 요청을 낸 적이 없다. 그런데도 시청에서 AI를 가장 먼저 업무에 들인 사람은 이들이다. AI 코딩 도구로 만든 엑셀 취합기, HWPX 변환기, 공공데이터 조회 MCP 서버, 보도자료 문체 스킬이 부서를 건너 퍼지고 있다. 대부분은 실행할 때 모델을 부르지 않는다.

표 K.3은 다섯 갈래의 요구마다 처음 들어온 말, 들여다본 실제 필요, 먼저 보이는 걸림돌을 적은 것이다.

**표 K.3** 부서별 요구와 걸림돌(가람시 가상 설정)
요구 주체	처음 들어온 요구	들여다본 실제 필요	먼저 보이는 걸림돌
민원여권과	민원 안내 챗봇	근거를 붙인 답변, 사람에게 넘기는 경로	상담 이력에 개인정보(S등급), 상용 API는 프록시 경유만
재난안전과	상황실 질의응답 챗봇	수위 초과 감지와 현장 통지	관제 구역이 별도, 오경보 책임 소재
기획예산과	보고서 작성 챗봇	초안 작성과 서식이 다른 엑셀·HWPX 취합	문서 형식(HWPX), 부서별 서식 제각각
복지정책과	상담 기록 요약 챗봇	위기가구 예측과 방문 우선순위 선별	민감 정보 결합, 선별 근거 설명, 누락의 비용
개인 개발 공무원	(공식 요구 없음)	이미 퍼진 도구의 공유·인수인계	개인 PC에만 있음, 라이선스·문서 없음

목표와 장애 요인

Erl의 사례 배경이 그렇듯, 가람시 이야기도 목표와 장애 요인을 먼저 적어 두고 시작한다. 16장에서 이 목록을 다시 펼쳐 무엇을 이루었고 무엇이 남았는지 확인한다.

사례 연구 · 가람시(가상)

AX팀이 세운 목표

부서마다 따로 챗봇을 만드는 대신, 부서별 주 부품과 시 공통 부품을 구분해 조립한다.
모델 호출을 한 진입점으로 모아 비용·권한·기록을 한곳에서 통제한다.
AI 산출물이 시민이나 공문으로 나가기 전에 누가 어디서 확인하는지 과제마다 명시한다.
모델이나 API가 멈춰도 민원 접수와 재난 통지가 끊기지 않게 한다.
개인 개발 도구를 공용 저장소로 옮기고, 잘 만든 것은 시의 참조 구현으로 등재한다.
과제마다 패턴 서명을 남겨, 다음 해 사업 계획과 외부 평가에 같은 언어로 쓴다.

AX팀이 마주한 장애 요인

인력. AX팀은 세 명이다. 팀장 한 명, 데이터와 업무시스템 연계를 맡은 주무관 한 명, 개발과 모델 서버를 맡은 주무관 한 명이다.
망. 행정망과 인터넷망이 나뉘어 있고, 외부 서비스는 프록시나 망연계를 거쳐야 한다.
데이터 등급. 다루는 데이터 대부분이 S(민감)다. 민원 상담 이력과 복지 정보는 특히 그렇다.
모델. 로컬 모델 서버는 한 대뿐이다. 상용 API는 프록시를 거쳐야만 쓸 수 있는데, 그 프록시도 아직 시범 운영 중이다.
예산. AX 관련 예산은 부서별 사업비에 흩어져 있다. AX팀 고유 예산은 연 수억 원 규모(설정)라 공통 부품을 크게 새로 만들 여력이 없다.
운영 기록의 습관. 검토 건수, 수정률, 장애 전환 이력을 남기는 습관이 없다. 시범 사업이 끝나면 "잘 됐다"는 보고서만 남는다.
자생 도구의 그늘. 개인 도구는 빠르고 현장에 맞지만, 만든 사람이 자리를 옮기면 멈춘다.

이 목록은 PAX 564건에서 반복해 관찰된 빈칸과 겹친다. PAX 사례에는 기반 부품이 많고 실행 환경도 다양하지만, 운영 부품(C)이 구현 이상으로 확인된 사례는 133건(23.6%)이고, 보안 부품(S)은 48건(8.5%)에 그친다. 전이 단계로 보면 만든 사람 혼자 쓰는 개인 사용이 361건(64.0%)으로 가장 많다. 가람시에는 이 빈칸을 두 갈래로 심어 두었다. 시범 사업은 운영 기록 없이 끝나고, 공무원이 만든 도구는 만든 사람의 PC를 떠나지 못한다.

가람시가 밟아 갈 여정

가람시 이야기는 장마다 한 걸음씩 나아간다(그림 K.3). AX팀은 1장에서 부서마다 챗봇을 따로 만들려는 흐름이 문제라는 것을 알아차리고, 4장에서 첫 패턴 서명을 쓴다. 2부의 각 패턴 프로필에서는 부서 하나가 그 패턴이 필요한 상황을 만나 부품을 들인다. 3부에서는 부품을 모아 서비스 유형별로 조립하고 안티패턴을 점검한 뒤, 과제를 태깅해 레지스트리에 올린다. 마지막 16장에서는 처음 세운 목표를 다시 평가한다.

그림 K.3 가람시(가상)의 여정. 1부에서 문제를 발견하고 첫 서명을 쓰며, 2부에서 부서별로 부품을 들이고, 3부에서 조립·점검·등재를 거쳐 16장에서 처음 목표를 다시 평가한다.

핵심 정리

가람시는 이 책을 위해 지어낸 가상 기초자치단체이고, 장마다 같은 기관이 AX를 한 걸음씩 밟는다.
환경 조건 기본값은 행정망(폐쇄), 로컬 오픈웨이트 모델 1대와 프록시 경유 상용 API, P0~P1 권한, 데이터 대부분 S 등급이다.
요구는 민원여권과(유형 1·2), 재난안전과(유형 3), 기획예산과(유형 4·8), 복지정책과(유형 10), 개인 개발 공무원(B0·A8·A9) 다섯 갈래다.
처음 들어온 요구는 모두 "챗봇"이었지만, 실제 필요는 상담·감지·초안·예측·공유로 서로 다르다.
AX팀의 장애 요인은 인력 3명, 망분리, 민감 데이터, 단일 모델 서버, 흩어진 예산, 운영 기록 부재, 개인 도구의 인수인계 공백이다.
여정은 1장 문제 발견 → 4장 첫 서명 → 5~11장 부품 도입 → 12~13장 조립 → 14장 점검 → 15장 등재 → 16장 회고로 이어진다.