보스턴 311 ‘심장수술’급 교체, 2008년 레거시 벗어난다: 노코드·AI CRM(Creatio)와 자산관리(Cartegraph) 결합
보스턴시가 비긴급 민원 창구 ‘보스턴 311’의 핵심 시스템을 단계적으로 교체하고 있다. 2008년에 도입된 기존(레거시) 플랫폼의 한계를 넘기 위해, 클라우드 기반의 민원 CRM과 도로·가로등 등 물리 자산(Asset) 관리 시스템을 결합해 처리 속도, 추적성, 부서 간 협업을 함께 끌어올리는 것이 목표다.
InformationWeek가 인용한 산티아고 가르세스(Santiago Garces) 보스턴시 CIO 발언에 따르면 311은 하루 1,000건 이상 요청을 처리하는 도시 운영의 ‘중심선’에 가깝다. 다만 오래된 구조는 유지보수와 확장성 측면에서 한계가 누적되기 쉽고, 실제로 보스턴시는 ‘한 번에 갈아엎는’ 방식 대신 기능을 ‘마일스톤’ 단위로 옮겨 운영 중단을 최소화하는 전략을 택했다. 시민 입장에서는 화면이나 접수 방식이 크게 달라 보이지 않더라도, 내부적으로는 레거시에서 신규 플랫폼으로 업무 흐름을 재배선하는 작업이 병행되는 구조다.
보스턴시 공개 자료에 따르면 새 311의 중심 플랫폼으로는 CRM·워크플로우 플랫폼 ‘Creatio’가, 물리 자산 관리 쪽에는 ‘Cartegraph’가 채택됐다. Creatio는 311 콜센터와 현장 부서가 민원을 접수·분류·라우팅·상태 업데이트하는 ‘케이스 허브’ 역할을 맡고, Cartegraph는 가로등·표지판·도로 표시 등 자산 작업 지시와 진행 상황을 관리한다. 두 시스템을 연동해 “민원 접수 → 담당 부서 작업 지시 → 처리 완료/공지” 과정에서 생기기 쉬운 단절을 줄이겠다는 구상이다. 보스턴시는 전체 전환 완료 목표 시점을 2026년 중반(mid-2026)으로 안내하고 있다.
보스턴권 테크·비즈 관점에서의 의미
이번 프로젝트는 ‘도시 운영’이라는 큰 워크플로우가 노코드/로우코드와 AI 기능을 포함한 CRM 중심으로 재설계된다는 점에서 상징성이 크다. 기능 전환이 진행될수록 내부 인력뿐 아니라 구현 파트너, 시스템 통합(Integration), 데이터 품질, 보안, 운영(Ops) 영역의 수요가 더 구체적인 형태로 나타날 가능성이 있다. 다만 공공 서비스 특성상 개인정보·민감정보 처리와 감사(로그) 요건이 강해질수록, “기능을 빨리 붙이는 것”보다 “운영 안전장치(예외 처리·감사·롤백)”가 성패를 좌우할 수 있다.
전환기 체감 포인트: ‘좋아지는 방향’과 ‘흔들릴 수 있는 구간’
- 상태 추적이 촘촘해지는 방향: 제설, 가로등 고장, 쓰레기 수거 누락처럼 생활형 이슈를 311로 넣고도 “지금 어디까지 왔는지”가 불명확했던 경험이 있다면, 새 CRM 체계는 상태 업데이트와 부서 간 핸드오프 기록이 더 구조화되는 방향이다.
- 초기 품질은 들쭉날쭉할 여지: 단계적 전환에서는 케이스 유형이 새/구 시스템에 혼재될 수 있다. 특히 계절성 수요(예: 제설)나 부서별 준비도에 따라, 체감 응답 속도나 처리 품질이 일정 기간 흔들릴 가능성은 열어두는 편이 안전하다.
노코드·AI 도입이 바꾸는 역할: ‘개발 감소’보다 ‘기반 체계 강화’
노코드가 들어오면 화면/폼을 빠르게 바꾸는 속도는 올라가지만, 그만큼 통합(GIS·자산관리·알림·콜센터), 데이터 표준화, 권한/감사로그, 운영 자동화 같은 ‘기반 체계’의 중요도가 커진다. 코딩량이 줄어드는 구간이 생기더라도, 시스템 설계·운영·거버넌스의 비중이 커지는 흐름에 가깝다.
AI 기능도 마찬가지다. 다국어 문의 분류, 민원 유형 추천, 자동 라우팅 같은 기능을 붙일수록 오분류·편향·민감정보 처리 리스크가 따라온다. 공공서비스는 한 번의 오분류가 누락으로 이어질 수 있어, 모델 성능뿐 아니라 예외처리·감사·되돌리기(롤백) 설계를 함께 보는 관점이 실무적으로 유효하다.
유학생·취업 준비 관점: 지금 할 수 있는 단계별 실행(포트폴리오용)
아래는 “GovTech+CRM(케이스 관리)” 감각을 빠르게 보여주는 방식이다. 법률·규정 해석이 아니라 데이터 기반 분석/제안에 초점을 맞춘다.
- Analyze Boston에서 주제 1개를 고른다
- 추천 주제: 제설, 도로(포트홀), 쓰레기, 소음, 가로등 등
- 311 오픈데이터(서비스 요청 데이터셋): https://data.boston.gov/dataset/311-service-requests
2 ) 리드타임(접수→종결) 지표를 2~3개로 단순화한다
- 예: 평균 처리시간, 재오픈 비율(또는 반복 민원), 동네별 편차
- 전환기에는 분류 체계/상태값이 바뀔 수 있으니, 분석 문서에 “전환에 따른 정의 변화 가능성”을 한 줄로 명시한다.
- 대시보드 1장 + 개선 제안 3개로 끝낸다
- 예시 개선 제안(문장형으로 3개만):
- 분류 체계 단순화(사용자 입력 부담 감소)
- 알림 문구 표준화(‘접수/배정/진행/완료’ 단계별 문구 정리)
- 재오픈 케이스 처리 기준 정리(현장 부서의 마감 정의 통일)
- 공개 공유 시 주의점(실무형 체크)
- 개인정보가 포함될 수 있는 필드는 제거하고, 데이터 출처와 가정(한계)을 명확히 적는다.
- “정답”을 주장하기보다, ‘가정→지표→관찰→제안’ 순서로 정리하면 면접에서 방어가 쉽다.
채용·계약 접근성: ‘원칙’보다 ‘공고/프로젝트별 조건 확인’이 안전
공공부문 프로젝트는 역할과 데이터 접근 범위에 따라 신원조회, 보안 교육, 접근 통제 등 요건이 달라질 수 있다. 또한 일부 직무는 연방 보안인가(클리어런스)처럼 시민권 요건이 명시되는 경우가 있다. 다만 이 요건은 모든 공공 IT 역할에 일괄 적용되는 것이 아니라, ‘어떤 데이터/시스템에 접근하느냐’와 ‘계약 구조가 어떻게 구성되느냐’에 따라 달라질 수 있다.
현실적으로는 지원 단계에서 아래 두 가지를 먼저 확인하는 방식이 리스크를 줄인다.
- 업무 범위: 운영 환경(프로덕션) 접근, 민감 데이터 접근, 현장 출입이 필요한지
- 프로젝트 조건: 고객사(기관) 요구 백그라운드 체크 범위, 접근 권한 발급 절차
보스턴권에서 관련 키워드를 정리할 때는 CRM(Constituent CRM), case management, workflow, integration, data governance, ITSM(운영 프로세스) 중심으로 묶고, 공공 경험이 없더라도 학교 행정/연구실 운영/고객지원 인턴 등의 ‘티켓·케이스 기반 운영 경험’을 같은 언어로 번역해 넣는 편이 실무적으로 유리하다.
보스턴 311 전환은 “클라우드 CRM+자산관리+AI 보조”로 도시 운영의 민원·작업 지시 체계를 재구성하는 흐름을 보여준다. 전환이 진행되는 동안 체감 품질은 구간별로 다를 수 있으나, 기술·운영 관점에서 ‘도시 규모의 케이스 관리’를 다루는 수요가 더 또렷해지는 쪽으로 무게가 실린다.