AI는 한국 SI를 구할까, 무너뜨릴까

— 네 주체가 각자의 논리로 AI를 도입할 때 벌어지는 일

---

1편에서 한국 SI 산업의 구조적 정체를 분석했습니다. 검증 체계, 발주처, SI사, 개발자 — 네 주체가 각자의 위치에서 합리적으로 행동한 결과, 전체로는 비합리적인 균형이 20년 넘게 유지되어 왔다는 이야기였습니다.

 

이 균형은 외부 충격 없이는 깨지지 않는 구조였습니다.

 

지금, 그 외부 충격이 도착했습니다. AI 코딩 도구의 확산입니다. Cursor, GitHub Copilot, Claude Code — 이름은 다양하지만, 공통된 약속은 같습니다. "개발 생산성을 획기적으로 높여준다."

 

문제는 이 도구가 도입되는 환경입니다. 1편에서 살펴본 바로 그 구조 — MM 기반 과금, 문서 중심 검증, 떠넘기기의 먹이사슬 — 위에 AI가 얹어집니다. 그리고 네 주체는 각자의 오래된 논리로 AI를 해석합니다.

---

발주처의 AI — "싸게 해라"

발주처에게 AI 코딩 도구의 등장은 단가 인하의 근거가 됩니다.

 

논리는 단순합니다. AI가 코드를 생성해주니 개발자가 덜 필요하다. 개발자가 덜 필요하면 투입 인원을 줄일 수 있다. 투입 인원이 줄면 사업비가 낮아져야 한다. "AI 시대에 왜 예전이랑 같은 금액이냐"는 질문이 이미 발주처의 회의실에서 나오고 있습니다.

 

이 논리에는 보이지 않는 전제가 있습니다. "개발의 가치는 코드 작성량에 비례한다"는 전제입니다. AI가 코드를 빠르게 생성할 수 있다는 것은 사실입니다. 그러나 무엇을 만들어야 하는지 결정하고, AI가 생성한 코드가 시스템 전체와 정합성을 가지는지 검증하고, 장애 발생 시 원인을 추적하는 일은 여전히 사람의 영역입니다. 오히려 AI가 빠르게 코드를 생산할수록, 이 판단과 검증의 비중은 더 커집니다.

 

그러나 MM 기반 계약 구조에서 이 구분은 반영되지 않습니다. "설계와 판단"에 별도의 가치를 부여하는 과금 체계가 없기 때문입니다. 결과적으로 AI 도입은 전체 사업비를 낮추는 압력으로만 작용하고, 정작 AI 시대에 더 중요해지는 역량 — 아키텍처 설계, 품질 검증, 기술 판단 — 에 대한 투자는 줄어들게 됩니다.

---

SI 경영진의 AI — "단가를 깎아라"

SI사 경영진에게 AI는 인력 효율화의 도구입니다.

 

개발자 한 명이 AI의 도움으로 두 명 몫을 해낸다면, 같은 프로젝트에 필요한 인원은 절반이 됩니다. 먼저 외주 물량이 줄어듭니다. 대형 SI사의 실제 개발 인력 상당수는 협력사와 프리랜서입니다. 자사 정규직을 감축하기 전에 외주부터 줄이는 것은 경영적으로 자연스러운 판단이며, 중소 SI사와 프리랜서 시장이 먼저 타격을 받습니다.

 

그렇다면 단가가 비싼 시니어부터 줄이지 않겠느냐고 생각할 수 있습니다. 그러나 현장의 현실은 그보다 교묘합니다. 계약서에 "고급 기술자"라고 명시되어 있으면 감리가 이를 확인합니다. 등급 자체를 낮추면 감리 지적 사항이 됩니다. 그래서 등급은 건드리지 않고, 단가를 깎습니다. "AI를 활용하니 같은 등급이라도 단가를 낮출 수 있지 않느냐"는 논리입니다.

 

발주처의 논리는 명쾌합니다. "생산성이 올라간 건 개발자의 역량이 아니라 AI 도구 덕이다. AI 사용료는 저렴하다. 그러면 고급 기술자에게 지금과 같은 단가를 지불할 이유가 없다."

 

이 논리에는 보이지 않는 전제가 있습니다. AI가 누구에게나 같은 결과를 내준다는 전제입니다. 현실은 다릅니다. 같은 AI 도구를 사용하더라도, 시스템 전체를 이해하는 사람이 사용하면 정합성 있는 아키텍처가 나오고, 그렇지 않은 사람이 사용하면 개별적으로는 동작하지만 통합하면 문제가 드러나는 코드가 나옵니다. AI의 성능을 끌어내는 것 자체가 역량이며, 그 차이는 결과물의 품질에 직접 반영됩니다. 그러나 MM 기반의 과금 체계에서는 이 차이가 가격에 반영될 구조가 없습니다.

 

고급 단가가 낮아지면, 실력 있는 경력자부터 SI를 떠납니다. 남는 것은 경력 연차는 고급 기준을 충족하지만 기술적 판단 역량은 그에 미치지 못하는 인력입니다. 한국의 기술자 등급 체계가 역량이 아닌 연차 기반으로 운영되기 때문에, 이 괴리는 서류상으로 드러나지 않습니다. 계약서에는 "고급 기술자 투입", 감리도 통과. 그러나 실제로 기술적 의사결정을 내릴 수 있는 사람은 빠져있는 상태가 됩니다.

 

잘할수록 손해보는 구조. 이것이 20년간 한국 SI가 발전하지 못한 이유 중 하나이며, AI가 그 구조를 바꾸기는커녕 같은 패턴을 반복시키고 있는 대목입니다.

---

PM의 AI — "더 빠르게 채워라"

PM에게 AI는 RFP 체크리스트를 더 빠르게 충족시키는 수단입니다.

 

1편에서 살펴보았듯이, 현행 검증 체계에서 PM의 최적 전략은 "RFP 항목을 빠짐없이 충족시키는 것"입니다. AI가 코드 생성을 가속한다면, 같은 기간에 더 많은 항목을 처리할 수 있습니다. 또는 같은 항목을 더 짧은 기간에 처리할 수 있습니다. 어느 쪽이든 PM에게는 유리합니다.

 

그러나 이 가속에는 전제 조건이 있습니다. AI가 생성한 코드의 품질을 누군가 검증해야 한다는 것입니다. AI는 "돌아가는 코드"를 빠르게 만들어내지만, 그 코드가 시스템 전체의 맥락에서 적절한지, 보안 취약점은 없는지, 향후 유지보수가 가능한 구조인지는 판단하지 못합니다.

AI 도입 이전에는 코드를 작성하는 속도가 병목이었습니다. AI 도입 이후에는 코드를 검증하는 속도가 병목이 됩니다. 그런데 검증과 기술적 판단을 수행할 수 있는 경험 있는 인력은, 앞서 말한 비용 효율화 과정에서 줄어들고 있습니다.

 

리뷰 없이 프로덕션에 올라가는 AI 생성 코드가 늘어납니다. 지금 당장은 문제가 보이지 않습니다. RFP 항목은 충족되고, 감리 문서는 갖춰지고, 일정은 단축됩니다. 모든 지표가 개선된 것처럼 보입니다.

---

개발자의 AI — "야근을 줄여라"

개발자에게 AI 코딩 도구는 실질적인 부담 경감입니다. 반복적인 CRUD 코드, 보일러플레이트, 테스트 코드 — AI가 이것들을 처리해주면 좀 더 인간적인 시간에 퇴근할 수 있습니다.

 

그러나 AI 도구를 활용하는 능력과, AI가 만든 결과물이 적정한지 판단하는 능력은 별개입니다. 후자는 직접 코드를 작성하고, 오류를 만나고, 구조를 고민하는 과정에서 축적됩니다. AI가 반복 작업을 대신하는 환경에서, 이 판단 역량이 축적될 경로는 줄어듭니다. 이것은 개인의 능력 문제가 아니라 환경의 문제입니다.

 

그리고 AI가 생성한 코드에는 독특한 문제가 있습니다. "동작은 하지만 왜 이렇게 작성되었는지 아무도 설명할 수 없는" 코드가 축적됩니다. 장애가 발생했을 때 원인 파악이 늦어지고, 수정의 영향 범위를 예측하기 어렵습니다.

---

현장에서 벌어지는 일 — 병렬 고립

네 주체의 논리가 현장에서 합쳐지면 어떤 상황이 만들어지는지를 볼 필요가 있습니다.

 

발주처가 AI 도입을 근거로 일정을 단축합니다. 개발자들이 각자 AI 코딩 도구로 자기 담당 모듈의 코드를 생성합니다. 여기서 간과되기 쉬운 산술이 있습니다. AI가 개발자 한 명의 생산성을 3배에서 5배 높인다면, 5명의 팀이 만들어내는 코드의 양은 15명에서 25명 분량입니다. 그러나 그 코드를 리뷰하고 조율할 시간은 일정 단축으로 오히려 줄어듭니다.

 

AI는 지시를 받은 개발자의 맥락 안에서만 코드를 생성합니다. 각 개발자가 각자의 AI에 각자의 맥락을 넣으면, 같은 시스템의 부품이지만 네이밍 규칙이 다르고, 설계 패턴이 다르고, 에러 처리 방식이 다른 코드가 만들어집니다. 이것은 협업이 아닙니다. 병렬 고립입니다.

 

각 모듈은 개별적으로 "완료"입니다. RFP 항목도 충족됩니다. 그러나 통합 단계에서 문제가 드러납니다. 모듈 간 인터페이스가 맞지 않고, 데이터 흐름의 전제가 어긋나 있습니다. 이 조율은 시스템 전체의 맥락에서 기술적 의사결정을 내릴 수 있는 경험에서 나옵니다. 그러나 일정이 단축된 환경에서 "코드를 생산하지 않는" 조율 활동에 공수가 배정되는 경우는 드뭅니다.

 

그리고 이 통합 실패는 감리에서 보이지 않습니다. 감리는 항목별 충족 여부를 확인하지, 항목 간의 정합성을 검증하지는 않기 때문입니다.

---

보안이라는 공통 과제

AI 코딩 도구를 도입하는 모든 조직이 마주하는 질문이 있습니다. "우리 코드가 외부로 나가는 것을 어떻게 통제할 것인가."

 

클라우드 API를 허용하되 민감 데이터를 분리하는 조직, 승인된 API만 사용하는 조직, 외부 연결을 완전히 차단하고 로컬 모델만 운영하는 조직 — 방식은 다양하지만, 공통된 트레이드오프가 있습니다. 보안 통제의 수준이 높아질수록 AI 도구의 효용은 낮아집니다. 그리고 통제 수준과 관계없이, 개별 개발자가 비공식적으로 외부 서비스를 사용하는 것까지 완벽히 통제하기는 현실적으로 어렵습니다.

 

자체 모델을 운영하려면 GPU 서버의 구매·운영, 모델 선정과 업데이트, 품질 모니터링 등 상당한 전문 인력과 비용이 필요합니다. 대부분의 조직이 이 운영 역량을 갖추지 못한 채 도입을 결정합니다. "로컬에 설치하면 된다"는 이해와 실제 운영 사이의 간극은 큽니다.

 

그리고 핵심적인 질문 — 이 비용을 누가 부담하는가. AI 인프라는 프로젝트가 끝나면 발주처에게 필요 없습니다. 클라우드 API든 자체 GPU 서버든, AI 도구의 운용 비용은 SI사의 몫이 됩니다. 발주처는 "AI로 효율적으로 하라"며 단가를 깎고, 그 AI의 운용 비용은 SI사가 부담합니다. 매출은 줄어드는데 비용은 늘어나는 구조입니다.

 

대형 SI사는 이 투자를 감당할 체력이 있을 수 있습니다. 중소 SI사는 어렵습니다. AI 도입이 산업의 효율화가 아니라 대형사로의 집중을 가속시키는 요인이 될 수 있는 대목입니다.

---

모든 지표가 개선되는 시기

AI 도입 초기에는 모든 것이 좋아진 것처럼 보입니다.

 

코드 생성 속도가 빨라집니다. 일정 준수율이 올라갑니다. RFP 충족률이 높아집니다. 투입 인원은 줄었는데 산출물은 줄지 않습니다. 경영진의 보고서에는 긍정적인 지표가 나열됩니다.

 

이 시기에 보이지 않는 것들이 있습니다.

 

AI가 생성한 코드 중 리뷰를 거치지 않은 비율이 얼마인지. 그 코드의 기술 부채가 어떤 속도로 축적되고 있는지. 시니어 개발자의 이탈 이후 코드의 구조를 전체적으로 이해하는 사람이 조직 내에 몇 명이 남아있는지. 주니어 개발자의 독립적 문제 해결 역량이 어떤 궤도를 그리고 있는지.

 

이 지표들은 당장의 프로젝트 보고서에 나타나지 않습니다. 감리에서 점검하는 항목에도 포함되지 않습니다. 그래서 아무도 주의를 기울이지 않습니다.

 

여기서 감리의 역할을 다시 볼 필요가 있습니다. 1편에서 감리가 실질적으로 문서 기반 검증에 머물러 있다는 점을 분석했습니다. AI 시대에 이 한계는 단순한 비효율이 아니라, 사고를 증폭시키는 구조적 요인이 됩니다.

 

AI가 코드를 빠르게 생성하고, 그에 맞춰 산출물 문서가 갖춰지면, 감리는 이전보다 오히려 더 수월하게 통과됩니다. RFP 항목은 충족되어 있고, 문서는 빠짐없이 존재하고, 일정은 단축되었습니다. 감리 결과는 양호입니다.

 

이 "양호"가 만들어내는 것은 거짓된 안전감입니다. 감리를 통과했다는 사실이 발주처에게, 경영진에게, PM에게 "품질에 문제가 없다"는 시그널로 작동합니다. 누구도 더 깊이 들여다볼 이유가 사라집니다. 검증되지 않은 AI 생성 코드 위에 "감리 통과"라는 공식적 승인이 찍히면, 기술 부채가 축적되고 있다는 경고음은 완전히 소거됩니다.

 

감리가 품질의 방파제가 아니라, 문제의 은폐를 공식화하는 절차가 되는 것입니다. 그리고 이 공식적 승인이 있었기 때문에, 사고가 발생했을 때의 충격은 더 커집니다.

---

사고는 어떻게 발생하는가

충분한 시간이 지난 뒤 — 아마도 AI 본격 도입 후 2~3년 — 사고가 발생합니다.

 

장애의 직접적 원인은 다양할 수 있습니다. 그러나 수습 과정에서 공통된 상황이 드러납니다. 코드의 구조를 전체적으로 파악할 수 있는 사람이 없습니다. AI가 생성한 코드는 "동작하지만 의도를 알 수 없는" 상태이기 때문에, 장애 원인의 추적이 극도로 어렵습니다. 이 판단을 할 수 있는 경험 있는 개발자는 단가 인하를 견디지 못하고 이미 시장을 떠난 뒤입니다. 외부에서 긴급 투입하려 해도, 공급은 줄고 수요는 급증한 상태이므로 비용은 평시의 몇 배가 됩니다.

 

이 시점에서 1편의 구조적 문제가 다시 나타납니다. 발주처는 "품질 관리는 SI사의 책임"이라 하고, 경영진은 "현장의 판단을 따랐을 뿐"이라 하고, PM은 "감리도 통과했다"고 하고, 개발자는 "시키는 대로 했을 뿐"이라 합니다. 그리고 "감리까지 통과한 프로젝트에서 왜 이런 사고가 나느냐"는 질문이 뒤따릅니다. 감리가 방파제가 아니라 사고의 규모를 키우는 증폭기가 되는 순간입니다.

---

다음 이야기

AI는 새로운 문제를 만든 것이 아닙니다. 이미 있던 구조적 결함을 더 이상 무시할 수 없는 수준으로 드러내는 것입니다.

 

구조가 문제라면, 구조를 바꿔야 합니다. 그러나 네 주체가 서로를 붙잡고 있는 균형 상태에서 누가 먼저 움직일 수 있을까요. 3편에서 그 질문에 대한 솔직한 답을 이야기하겠습니다.

---

필자는 1997년부터 개발자로 일해왔습니다. SI의 구조적 문제에 회의를 느끼고 게임 업계로 옮긴 경험이 있으며, 현재는 결과물 기반의 직계약 구조로 SI 프로젝트에 참여하고 있습니다.