한국 SI는 왜 발전하지 않는가
— 네 주체의 합리적 선택이 만든 비합리적 구조
한국 SI 산업에는 오래된 수수께끼가 있습니다.
기술은 매년 바뀝니다. 자바에서 파이썬으로, 온프레미스에서 클라우드로, 그리고 이제 AI로. 하지만 일하는 방식은 20년째 크게 달라지지 않았습니다. 10년 전 프로젝트의 진행 구조와 오늘의 프로젝트 진행 구조를 놓고 보면, 도구만 바뀌었을 뿐 사람을 투입하고, 기간을 산정하고, 결과물을 납품하는 방식은 거의 같습니다.
삼성은 반도체를 만들 때 이전 세대 기술 위에 다음 세대를 쌓습니다. SI에는 이 축적이 없습니다. 프로젝트가 끝나면 팀이 해산되고, 다음 프로젝트는 다시 처음부터 시작합니다.
왜 그럴까요. 누군가 무능해서가 아닙니다. 이 산업을 구성하는 네 주체 — 검증 체계(감리), 발주처, SI사, 개발자 — 가 각자의 위치에서 합리적으로 행동한 결과, 전체로는 비합리적인 균형 상태가 만들어졌기 때문입니다.
건설업에서 물려받은 설계도
한국 SI의 구조적 원형은 소프트웨어 산업이 아닌 건설업에 있습니다.
일제강점기에 형성된 건설업의 하도급 구조 — 원청 수주, 하청 시공, 재하청 노동 — 는 해방 이후 한국 건설업의 표준이 되었고, 1980~90년대 전산화 시기에 SI 산업이 태어날 때 이 뼈대가 그대로 이식되었습니다. "설계", "감리", "시공", "공수 산정"이라는 용어 자체가 건설 현장에서 온 것은 우연이 아닙니다.
건설에서 이 방식은 일정한 합리성을 가집니다. 벽돌을 쌓는 일은 투입량과 결과물이 비례합니다. 10명이 10일 작업하면 예측 가능한 양의 결과가 나옵니다.
소프트웨어는 다릅니다. 뛰어난 설계자 한 명이 2개월에 만들 시스템을, 10명이 10개월을 투입해도 완성하지 못하는 경우가 빈번합니다. 그럼에도 Man-Month라는 건설업의 측정 단위가 지배하면서, 소프트웨어 개발은 "사고하는 행위"가 아닌 "시공하는 행위"로 취급되기 시작했습니다.
이 프레임이 한국 SI 산업의 모든 문제의 출발점입니다.
검증 체계 — 진화한 것처럼 보이지만
과거에는 감사가 투입 인력과 단가 중심으로 이루어졌습니다. "계약서대로 사람이 투입되었는가"가 핵심이었습니다. 이제는 다릅니다. 대형 프로젝트에는 감리가 붙고, 감리는 RFP에 명시된 기능이 구현되었는지, 일정이 준수되었는지, 지연이 발생했다면 원인이 무엇인지를 따집니다. 형식적으로는 산출물 중심의 검증으로 이행한 것입니다.
그러나 현장의 실체는 조금 다릅니다. 감리가 시스템의 코드를 뜯어보거나 아키텍처의 적정성을 기술적으로 평가하는 경우는 드뭅니다. 실질적으로 검증되는 것은 산출물 문서입니다. 테스트 결과서가 있는가. 요구사항 추적표가 채워져 있는가. 산출물 목록에 누락이 없는가.
문서가 갖추어져 있으면 통과합니다.
검증의 형태가 "투입 증빙"에서 "문서 증빙"으로 바뀌었을 뿐, "결과물의 실질적 품질을 평가한다"는 단계에는 이르지 못한 것입니다. 그리고 이 구조는 현장에 역설적인 부담을 만들어냅니다. 감리 대응을 위한 문서 작성에 상당한 공수가 소요되면서, 정작 개발에 투입할 시간이 줄어드는 것입니다.
결과적으로 발주처 담당자의 최적 전략은 바뀌지 않았습니다. "좋은 시스템을 만드는 것"이 아니라, "감리에서 지적받지 않는 사업을 운영하는 것"입니다. 이것은 담당자의 도덕성과 무관한, 검증 구조가 만들어내는 행동 유인입니다.
네 주체의 합리적 선택
이 산업의 정체를 한 주체의 탓으로 돌리는 것은 정확한 진단이 아닙니다. 네 주체가 각자의 위치에서 합리적으로 행동한 결과가 모여 현재의 균형을 만들었습니다.
발주처의 논리.
발주처에게 가장 중요한 것은 사업의 안정적 수행과 감사 대응입니다. 그 과정에서 요구사항 변경이 빈번하게 발생하지만, 계약 범위와 일정의 재조정은 잘 이루어지지 않습니다. 범위는 늘어나되 기간과 금액은 고정되는 구조가 반복됩니다.
이것은 발주처 내부의 의사결정 구조와 관련이 있습니다. 실무진의 요구는 수시로 바뀌지만, 계약 변경은 행정적 부담이 크기 때문입니다. 결과적으로 변경된 요구는 구두로 전달되고, 공식 문서에는 반영되지 않는 경우가 많습니다.
이 과정에서 최종 사용자 — 시스템을 실제로 이용하는 공무원이나 국민 — 의 편의는 후순위로 밀립니다. 발주의 목적이 "좋은 시스템의 구축"에서 "안전한 사업의 완료"로 치환되기 때문입니다.
SI사 경영진의 논리.
SI사에게 가장 중요한 것은 수주입니다. 수주 경쟁에서 "안 됩니다"는 곧 기회의 상실을 의미합니다. 따라서 현장의 수용 가능성과 무관하게 발주처의 요구를 수용하는 것이 영업적으로 합리적인 선택이 됩니다.
이 과정에서 SI사의 핵심 역량이 변질됩니다. "좋은 시스템을 설계하고 구축하는 능력"이 아니라, "필요한 인력을 빠르게 동원하는 능력"이 경쟁력의 본질이 됩니다. 진단하고 설계하는 전문 기관이 아닌, 인력을 공급하는 파견 조직에 가까워지는 것입니다.
구조적으로 더 깊은 모순이 있습니다. MM 기반 과금 체계에서는 효율적으로 일할수록 매출이 줄어듭니다. 적은 인력으로 좋은 결과를 내면 수익이 감소하는 역설. 이 구조는 비효율을 수익화하는 유인을 만들어내며, 이는 개별 기업의 의지와 무관하게 산업 전체의 기술 발전을 저해합니다.
PM의 논리.
PM은 경영진과 현장 사이에서 양방향 압력을 받습니다. 위로는 "잘 되고 있다"고 보고해야 하고, 아래로는 현실적으로 불가능한 일정을 실행해야 합니다. 범위 변경에 대해 공식적으로 이의를 제기할 수 있는 조직적 뒷받침이 부족한 경우가 대부분입니다.
이 구조 안에서 PM의 행동 원리는 명확합니다. 필자가 참여했던 한 프로젝트 — 규모 60~70억 원 — 에서 PM은 이렇게 말했습니다.
"RFP만 충족하면 돼요."
이 말을 그 PM의 자질 문제로 볼 수도 있습니다. 그러나 구조적으로 보면, 이것은 지극히 합리적인 판단입니다. 감리는 RFP 기준으로 검증합니다. RFP에 없는 항목은 아무리 잘 만들어도 평가에 반영되지 않습니다. 반대로 RFP에 있는 항목이 누락되면 즉시 지적 사항이 됩니다. 그렇다면 한정된 자원을 어디에 집중하겠습니까. 사용자 경험의 개선이 아니라, RFP 체크리스트의 충족입니다.
결과적으로 PM은 위험 관리가 아닌 위험 전가의 역할을 하게 됩니다. 무리한 일정의 압력은 개발팀으로 내려가고, 품질 관리의 여유는 일정 안에서 사라집니다. "RFP만 충족하면 된다"는 말은 체념이 아닙니다. 이 구조 안에서의 생존 전략입니다.
개발자의 논리.
개발자에게도 이 구조를 고착시킨 측면이 있습니다. 다만 이것은 다른 세 주체와 마찬가지로, 개인의 자질이 아닌 구조적 유인의 결과로 이해해야 합니다.
현장의 개발자가 요구사항에 의문을 제기하면 어떤 일이 벌어지는지를 먼저 볼 필요가 있습니다. "이 요구사항은 기술적으로 불합리합니다"라고 말하면, 돌아오는 반응은 대개 "그걸 고객한테 말하냐", "다른 데선 다 하던데"입니다. 말해봤자 바뀌지 않고, 오히려 "까다로운 사람"으로 인식됩니다. 이 경험이 반복되면 합리적인 선택은 명확해집니다. 소통을 시도하는 것보다, 야근으로 흡수하는 것이 개인에게 더 안전합니다.
문제는 이 선택이 장기적으로 만들어내는 결과입니다. 야근으로 불합리한 요구를 수용하는 것이 반복되면, 의사결정권자들에게 "개발이란 시간을 투입하면 해결되는 일"이라는 인식이 형성됩니다. 개발자가 의도한 것은 아니지만, 결과적으로 자기 일의 가치를 노동 시간으로 증명하는 구조에 편입된 것입니다.
기술적 소통의 문제도 같은 맥락입니다. 기술적 판단의 근거를 비전문가에게 전달하는 것은 쉬운 일이 아닙니다. 그리고 그 노력이 보상받는 구조가 아닙니다. 설계를 잘 설명해서 프로젝트 방향을 바꾼 개발자보다, 묵묵히 야근해서 일정을 맞춘 개발자가 더 좋은 평가를 받는 환경에서, 소통 역량에 투자할 유인은 낮습니다.
지식 전수의 부재도 마찬가지입니다. 체계적 교육과 코드 리뷰에 시간을 쓰려면 여유가 있어야 합니다. 그러나 감리 문서를 만들고 야근으로 일정을 맞추는 데 공수가 소진된 환경에서, 후배를 체계적으로 가르칠 여력이 남아있기를 기대하기는 어렵습니다. "각자 알아서 성장하라"는 문화는 냉정함이 아니라, 여유 없는 현장이 만들어낸 관성입니다.
그 결과, 기술 역량이 개인에게 귀속되고 조직에 축적되지 않습니다. 핵심 인력의 이탈이 곧 시스템의 위기로 직결되는 구조가 고착됩니다.
균형은 왜 깨지지 않았는가
이 네 주체의 행동이 서로를 강화하는 균형 상태를 이루고 있기 때문입니다.
감리는 문서 기준으로 검증합니다. 발주처는 감리에서 지적받지 않는 방식으로 발주합니다. SI사는 MM 기반으로 수익을 만듭니다. 개발자는 야근으로 문제를 흡수합니다. 어느 한쪽이 먼저 바꾸려 해도, 나머지 세 주체의 관성에 부딪혀 원래 자리로 돌아옵니다.
이것이 20년 넘게 한국 SI가 변하지 않은 구조적 이유입니다. 기술이 아무리 발전해도, 그 기술을 운용하는 산업의 틀이 바뀌지 않으면 결과도 바뀌지 않습니다.
그런데 지금, 이 균형 상태에 외부 충격이 가해지고 있습니다.
AI 코딩 도구의 확산입니다.
"개발자를 절반으로 줄이자", "기간을 반으로 깎자" — 이미 경영진의 회의실에서 오가는 이야기입니다. 그러나 지금까지 살펴본 이 구조 위에 AI를 얹으면, 기대하는 효율 향상이 아니라 예상치 못한 종류의 위기가 찾아올 수 있습니다.
2편에서 그 구체적인 시나리오를 분석하겠습니다.
필자는 1997년부터 개발자로 일해왔습니다. SI 현장에서 개발, PM, 기술 설계를 두루 경험했고, 이 글에서 다룬 구조에 진절머리가 나서 게임 업계로 자리를 옮긴 적이 있습니다. 다시 SI 쪽 프로젝트를 하면서 느낀 것은, 떠나 있던 사이에 거의 아무것도 변하지 않았다는 것이었습니다.