한국 솔루션의 진짜 해자 — 기술이 아닌 제도·관계·도메인의 구조 분석

앞선 두 편에서 같은 결론에 도달했다. 웹스퀘어도, OZ Report도, Claude Code로 "기술적으로 비슷한 것"은 만들 수 있다. 그러나 실제 제품을 대체하는 길은 거의 닫혀 있다. 이유는 기술이 아니라 다른 층위에 있기 때문이다.
그 다른 층위가 정확히 무엇인지 이번 글에서 본격적으로 분해한다. 기술적 해자와 제도적 해자가 어떻게 다르게 작동하는가. 왜 한국  솔루션 시장은 글로벌 표준과 다른 방식으로 잠겨 있는가. 그리고 AI 시대에 이 구조는 어떻게 변하거나 유지될 것인가.
이 글은 두 가지 용도로 읽힐 수 있다. 첫째, 개발자가 자기 커리어의 판을 이해하는 지도. 둘째, 스타트업이나 해외 솔루션 진출 기획자가 한국 시장 진입 전략을 짜기 위한 분석.

---

1. "해자"라는 단어의 정확한 의미

워런 버핏이 대중화한 "economic moat"는 원래 중세 성 주변의 해자(垓字)에서 온 비유다. 성을 직접 공격하는 것보다 해자 때문에 접근 자체가 불가능해진다. 경제적 맥락에서도 같다. 경쟁자가 "제품 품질"로 싸우기 전에 "시장에 진입하는 것 자체"가 막혀 있는 구조가 해자다.
해자의 유형은 일반적으로 다섯 가지로 분류된다.

1. 규모의 경제 — 크기가 커질수록 단위 비용이 내려감
2. 네트워크 효과 — 사용자가 많아질수록 제품 가치가 올라감
3. 전환 비용(Switching Cost) — 바꾸는 데 드는 돈·시간·리스크가 큼
4. 무형 자산 — 브랜드, 특허, 규제 라이선스
5. 비용 우위 — 독점적 자원 접근, 지리적 이점

한국 SI 솔루션의 해자는 이 중 3번 전환 비용과 **4번 무형 자산(특히 규제·관계)**에 압도적으로 치우쳐 있다. 그런데 이게 해외 엔터프라이즈 SaaS의 해자와 질적으로 다른 구조라는 점이 핵심이다.

---

2. 글로벌 SaaS의 해자 vs 한국 SI의 해자

2.1 글로벌 SaaS의 해자는 "기술 + 네트워크"

Salesforce, ServiceNow, Snowflake, Datadog 같은 글로벌 엔터프라이즈 SaaS의 해자는 주로 기술과 네트워크 효과 위에 서 있다.

• 플랫폼 확장성: AppExchange, ServiceNow Store 같은 서드파티 마켓플레이스
• 데이터 중력: 한 번 모인 데이터가 이동하기 어렵다는 물리적 제약
• API 생태계: 수많은 통합(integration) 파트너가 제품 가치를 확장
• 지속적 R&D 투자: 매출의 20~30%를 제품에 재투자하는 규모의 힘

이 해자는 측정 가능하고, 벤치마크 가능하며, 시간이 지나면 복제도 가능하다. 실제로 지난 10년간 수많은 "Salesforce 킬러"들이 등장해서 일부 영역을 뺏어갔다. 해자가 있지만 "공격받을 수 있는 해자"다.

2.2 한국  솔루션의 해자는 "제도 + 관계 + 도메인"

반면 한국 엔터프라이즈 소프트웨어의 해자는 다른 세 층으로 구성된다.
1층 — 제도적 해자 (Institutional Moat)

• 정부·공공·금융 RFP의 레퍼런스 요구사항
• 한국인터넷진흥원(KISA), 국가정보원, 금융감독원, 개인정보보호위원회의 규제·인증 체계
• GS인증, CC인증, K-ISMS, ISMS-P 같은 국내 전용 인증
• 조달청 나라장터 등록 자격
• 전자금융거래법, 전자문서법, 개인정보보호법의 업계별 시행령

2층 — 관계적 해자 (Relational Moat)

• 대형 SI(삼성SDS, LG CNS, SK C&C, 포스코DX, 현대오토에버)와 솔루션 벤더의 오랜 파트너십
• 금융·공공 IT 기획 담당자와 벤더 영업의 10년 단위 네트워크
• 장애 발생 시 한국어로 즉시 연결되는 기술지원 체계
• 차세대 프로젝트 제안 참여 경험 자체가 다음 프로젝트의 자격 요건이 되는 구조

3층 — 도메인 해자 (Domain Moat)

• 한국식 행정 양식 (직인 영역, 한글 금액 표기, 주민번호·사업자번호 마스킹 규칙)
• 한국 금융권 특화 처리 (예수금 계산 규칙, 금리 적용 방식, 세무 원천징수)
• 공공 업무 특화 워크플로우 (결재선, 감사 대응, 민원 응대)
• 한국어 IME·폰트·검색 엣지 케이스 수만 가지
• 20년간 프로젝트 장애 대응으로 축적된 암묵지

이 3층 해자가 서로를 강화한다는 점이 결정적이다. 제도가 관계를 만들고, 관계가 도메인 축적을 가능하게 하고, 도메인 축적이 다시 제도 대응의 근거가 된다. 이 사이클을 바깥에서 뚫고 들어가는 것은 거의 불가능에 가깝다.

---

3. 사례 분석 — 이 해자가 실제로 어떻게 작동하는가

3.1 티맥스소프트의 코어뱅킹 독주

2007년 국민은행 차세대 프로젝트 당시 디지털데일리 보도에 이미 핵심 구절이 나온다. "현재 코어뱅킹 솔루션 시장을 독주하고 있는 티맥스소프트와 경쟁할 코어뱅킹 솔루션업체는 딱히 없는 상황이다."
2026년 현재도 이 구조는 크게 달라지지 않았다. 시중은행의 차세대 프로젝트에 글로벌 코어뱅킹 솔루션(Temenos, FIS, Oracle FLEXCUBE)이 들어오려 해도 — 심지어 한국IBM이 Temenos를 가지고 복수 제안을 해도 — 최종 선정에서 국내 솔루션이 이기는 일이 반복된다.
이 구조를 기술로 설명할 수 있을까? 어렵다. Temenos T24는 전 세계 150개국 이상의 은행에서 쓰이는 검증된 제품이다. 그런데도 한국 시중은행 코어뱅킹에서 이기지 못한다.
이유는 3층 해자가 모두 작동하기 때문이다.

• 제도: 금융감독원 검사 대응, 전자금융거래법 해석, 한국은행 금통위 결정 반영 같은 국내 규제 대응이 필수.
• 관계: 은행 IT 기획팀과 10년 넘게 쌓인 신뢰 네트워크.
• 도메인: 한국 금융상품의 복잡성(적금·예금 해지 이자 계산, 주택청약저축 규정, 연금저축 세제 혜택) 전수 내장.

Claude Code로 코어뱅킹 시스템을 "만드는" 것은 기술적으로 가능하다. 그러나 위 3층을 뚫고 신한·국민·하나은행에 납품하는 것은 완전히 다른 게임이다.

3.2 인스웨이브 웹스퀘어의 지속성

웹스퀘어가 수년간 "곧 React로 대체될 것"이라는 예측을 듣고도 국내 금융·공공 UI 시장에서 지위를 유지하는 이유도 같은 구조다.

• 제도: 웹 접근성 인증(KWCAG), 국가정보원 보안 적합성 검증 통과.
• 관계: 대형 SI의 공통 컴포넌트로 자리 잡아 프로젝트 관리 표준화에 기여.
• 도메인: 한글 IME 처리, 공인인증서 연동, 한국식 폼 검증 로직 전부 내장.

React는 기술적으로 우월할 수 있어도, 이 3층 중 어느 하나도 자동으로 해결해주지 않는다. 오히려 React로 프로젝트를 하면 위 3층을 각 SI 업체가 매번 새로 구축해야 한다. 그게 리스크다.

3.3 포시에스 OZ Report의 4천여 고객사

OZ Report 공식 자료에 따르면 "대법원, 행정안전부, 국토교통부 등 국내 주요 정부부처와 공공기관의 대국민 서비스는 물론 금융, 제조, 유통, 통신, 교육 등에서 4천여 개 이상의 고객사를 확보"했다.
이 숫자가 갖는 의미는 단순 시장 점유율이 아니다. 4천여 고객사 각각이 OZ Report 기반으로 수십~수백 개의 리포트 템플릿을 축적하고 있다. 한 번 쌓인 템플릿 자산은 솔루션을 바꾸는 순간 재작성해야 한다. 공공기관 한 곳에서만 수백 개, 전국 단위로는 수만 개다. 이 전환 비용이 해자의 거대한 폭을 만든다.

---

4. AI 시대의 해자 — 무엇이 흔들리고 무엇이 굳어지는가

이제 본격적인 질문. Claude Code, Cursor, Copilot 같은 AI 도구가 일반화된 2026년 이후, 이 3층 해자는 어떻게 변할까.

4.1 흔들리는 것 — 도메인 해자의 일부

세 층 중 가장 먼저 침식되는 쪽은 도메인 해자의 표층이다.
한국식 양식 구현, 한글 IME 엣지 케이스, 공인인증서 연동 같은 패턴은 이미 충분한 공개 정보가 축적되어 있다. Claude Code가 학습 데이터에서 이 패턴들을 상당 부분 내재화하고 있고, 앞으로 더 많이 흡수할 것이다.
그 결과:

• "한국식 행정 양식을 지원하는 오픈소스 리포트 엔진"을 만드는 비용이 급격히 낮아진다.
• "한글 IME를 올바르게 처리하는 Grid 컴포넌트"가 React 생태계에 빠르게 등장한다.
• SI 업체가 차세대 프로젝트에서 상용 솔루션을 선택하지 않고 자체 구현 + AI 가속을 택할 여지가 확대된다.

즉, 표층의 도메인 지식은 공공재화된다.

4.2 흔들리지 않는 것 — 심층 도메인과 제도 해자

그러나 도메인 해자의 심층부는 흔들리지 않는다.

• 특정 은행의 특정 금융상품이 30년 동안 겪은 법령 변경 이력
• 공공기관 A의 민원 응대 워크플로우가 B에게는 없는 이유
• 2018년 개인정보보호법 개정 시 각 산업이 대응한 패턴의 차이
• 금융감독원 검사 지적 사항에 대한 업계별 대응 문서들

이 지식은 공개된 적이 없고 앞으로도 공개되지 않는다. 각 SI 업체의 프로젝트 방법론 문서, 솔루션 벤더의 대응 매뉴얼, 현업 담당자의 머릿속에만 있다. Claude Code가 학습할 데이터가 애초에 존재하지 않는다.
제도 해자는 더 확고해진다.

• AI 시대에 규제 기관은 "AI로 만든 시스템의 검증"을 새로 요구할 것이다.
• 그 새 규제를 최초로 통과시킨 벤더가 다음 10년의 시장을 잡는다.
• 이는 AI 도구로 기술을 복제해도 시장에 진입할 수 없는 새로운 제도 해자의 등장이다.

4.3 강화되는 것 — 관계 해자의 역설적 확대

이게 가장 반직관적인 지점이다. AI가 기술을 상향 평준화할수록 관계 해자는 더 중요해진다.
이유는 간단하다. AI로 누구나 비슷한 수준의 기술 역량을 갖출 수 있으면, 구매자 입장에서 의사결정 기준은 "누구를 믿을 수 있는가" 로 이동한다. 제품이 대동소이하면 관계가 결정적 차이가 된다.
실제로 금융·공공 RFP에서 점점 더 많이 등장하는 조항들:

• "해당 솔루션을 3년 이상 유지보수한 경험이 있는 파트너사"
• "본 기관 유사 규모 프로젝트 수행 이력"
• "솔루션 벤더의 국내 법인 및 24시간 기술지원 체계"

AI 시대에 기술 차별화가 어려워질수록 이런 조항의 무게가 커진다. 이것이 "관계 해자의 역설적 확대" 다.

---

5. 그래서 무엇을 해야 하는가 — 세 가지 포지셔닝 전략

이 해자 분석을 바탕으로 한국 SI 업계 개발자·기획자가 취할 수 있는 전략은 크게 세 가지다.

5.1 전략 A — "해자 안쪽"에서 AI 레버리지

기존 대형 SI나 솔루션 벤더에 속해 있다면, 가장 합리적인 포지셔닝은 3층 해자를 받침점으로 두고 AI를 지렛대로 삼는 것이다.

• 제도·관계·심층 도메인은 회사가 20년간 쌓은 자산.
• 자신은 그 자산 위에서 AI로 개발·운영 생산성을 2~5배 올린다.
• 결과: 같은 자원으로 더 많은 프로젝트, 더 높은 마진.

이게 티맥스·인스웨이브·포시에스 같은 국내 벤더들이 자사 제품에 AI를 내장하는 이유다. 그리고 그 제품을 쓰는 SI 개발자 입장에서도, "AI를 활용해 같은 솔루션으로 더 빠르게 프로젝트를 종료시키는 사람" 이 가장 경쟁력 있다.

5.2 전략 B — "해자 주변부"에서 틈새 제품

솔루션 벤더가 직접 만들기엔 우선순위가 낮은 주변부 도구는 여전히 공백이 많다.

• 웹스퀘어 XML → React JSX 마이그레이션 도구
• OZ Report 템플릿 자동 생성기
• JasperReports → 상용 리포트 툴 변환기
• 특정 벤더 솔루션의 QA 자동화 SaaS
• 차세대 프로젝트 RFP 자동 분석 도구

이 영역은 솔루션 벤더가 만들면 "자기 제품을 대체하는" 것이라 만들지 않고, 순수 오픈소스는 한국 도메인을 충분히 이해하지 못해서 만들기 어렵다. 그 사이의 작은 틈에 1~3인 팀이 만들 수 있는 B2B 도구들이 숨어 있다.
개발자가 도메인 이해 + AI 구현 역량을 조합할 수 있다면 이 전략이 가장 유리하다. 프리모아 청각재활 프로그램 외주나 ASAT 프로젝트가 본질적으로 이 구조에 해당한다.

5.3 전략 C — "새 해자"를 만드는 신규 도메인

기존 솔루션이 장악하지 못한 신규 도메인에서는 한국 특화 제도·도메인 해자를 처음부터 구축할 수 있다.
최근 10년간 이런 영역이 몇 개 있었다.

• 모바일 간편결제 (카카오페이, 토스)
• 클라우드 기반 회계·세무 (이파이낸셜그룹, 삼쩜삼)
• 전자계약 (모두싸인, 이싸인온)
• AI 기반 법률·의료 (로앤굿, 코어라인소프트)

이들 중 성공한 곳들은 공통적으로 "기술"이 아니라 "제도 적응 + 업계 관계 + 특화 UX" 로 해자를 만들었다. Claude Code 같은 AI 도구는 이 해자 구축의 속도를 끌어올리지만, 해자 자체를 만들지는 않는다.

---

6. 개발자 개인 관점 — 이 해자 구조가 커리어에 의미하는 것

지금까지 이야기한 구조는 개발자 개인 커리어에도 직접적 함의를 가진다. 세 가지로 정리한다.

6.1 "기술 스택 지상주의"의 한계

"React가 웹스퀘어보다 나은가" "Spring Boot가 코어뱅킹 솔루션보다 우월한가" 같은 논쟁은 기술적으로는 의미 있지만 산업 현실에서는 핵심을 비껴간다. 기술만 놓고 보면 오픈소스가 더 나은 경우가 많다. 그런데 시장은 3층 해자 위에서 움직인다.
이 지점을 이해하는 것과 못 하는 것 사이에는 큰 차이가 있다. 이해하면 "기술 스택"과 "솔루션"의 차이를 구분할 수 있고, 둘 중 어느 쪽에 자신의 커리어를 배팅할지 결정할 수 있다.

6.2 "깊이 있는 도메인 경험"의 희소성

해자 분석이 알려주는 가장 실용적인 교훈은 이것이다. 한국 엔터프라이즈 소프트웨어에서 가장 희소한 자원은 "한국어로 도메인을 이해하는 개발자" 다.
글로벌 수준의 코딩 능력을 가진 개발자는 점점 많아진다. AI로 더 많아진다. 그러나 "금융감독원 검사 대응 경험이 있으면서 Spring Boot로 코드를 잘 짜는 사람"은 여전히 드물다. 리포트 툴 개발 경험과 Next.js를 동시에 다룰 수 있는 사람은 더 드물다.
이 교집합이 AI 시대 개발자의 진짜 경쟁력이다.

6.3 "해자 안쪽에서 밖으로 vs 밖에서 안쪽으로"

커리어 궤적을 생각할 때, 해자를 넘나드는 방향성이 중요하다.

• 해자 안쪽에서 밖으로: SI에서 시작해 해자 바깥의 스타트업·해외 기업으로 이동. 해자 안쪽의 지식을 외부 가치로 전환. 포지셔닝 난이도 높지만 성공 시 희소 가치 큼.
• 해자 밖에서 안쪽으로: 스타트업·해외 경험을 가지고 SI 솔루션 벤더에 합류. 관계 해자 진입이 어려우나, AI 활용·제품 기획에서 차별화 가능.
• 해자 내부 이동: SI 내부에서 도메인·관계 자산을 누적. 안정적이지만 산업 전체가 구조 변화를 겪을 때 리스크 분산이 어려움.

정답은 없다. 다만 자기가 어느 방향으로 움직이고 있는지를 의식하는 것 자체가 중요하다.

---

7. 시리즈를 닫으며 —  2026년에 서 있는 자리

3편에 걸친 이 시리즈의 공통 결론은 이것이다.

Claude Code가 한국 생태계를 "대체"하지 않는다. 그러나 Claude Code를 어떻게 쓰느냐에 따라 한국 생태계 안에서 각 참여자의 위치가 재편된다.

웹스퀘어를 대체하는 UI 플랫폼을 만드는 것도, OZ Report를 대체하는 리포트 툴을 만드는 것도 AI 시대에 현실적인 목표가 아니다. 그 이유는 기술의 문제가 아니라 제도·관계·도메인 해자의 구조 때문이다.
그러나 같은 해자가 AI를 활용하는 개발자에게는 오히려 기회를 연다. 해자 안쪽에 있는 개발자는 AI를 지렛대로 생산성을 몇 배 끌어올릴 수 있고, 해자 주변부를 공략하는 개발자는 기존 벤더가 만들지 않는 틈새 제품을 만들 수 있으며, 해자 바깥에서 새 영역을 여는 개발자는 한국 도메인 특화 제품으로 새로운 해자를 구축할 수 있다.
어느 쪽을 선택하든, 핵심은 해자가 작동하는 원리를 정확히 이해하는 것이다. 기술 스택의 우열만 보는 사람에게는 한국 SI 시장이 비합리적으로 보이고, 제도·관계·도메인을 함께 보는 사람에게는 그 안의 논리가 보인다. 그 차이가 앞으로 10년의 커리어를 가르는 분기점이 될 것이라고 본다.
Claude Code는 우리에게 더 긴 지렛대를 쥐여줬다. 그 지렛대를 어느 받침점 위에 놓을지는 여전히 우리가 결정한다. 그 결정이 곧 커리어의 방향이다.

---

참고 자료

• 대한금융신문 — 기업은행 차세대 프로젝트 RFP
• 디지털데일리 — 국민은행 차세대 프로젝트 보도
• CIO Korea — 노코드의 4가지 락인 유형
• ITPE JackerLab — RFI vs RFP 구분
• FORCS — OZ Report 4천여 고객사 레퍼런스
• Inswave — WebSquare5 AI 혁신의 물결
• 시리즈 1편 — Claude Code로 웹스퀘어를 만들 수 있을까
• 시리즈 2편 — Claude Code로 OZ Report 같은 리포트 툴을 만들 수 있을까