견적의 문법

한국 SI가 갇혀 있던 한 가지 언어

 

1. 소프트웨어는 건물과 같은 가치를 지닐까

 
이 질문을 한동안 진지하게 여기고 있었습니다. 한국 SI 안에서 꽤 오래 일해 온 필자에게 이 질문은, 산업 전체의 설계도를 들여다보는 열쇠처럼 느껴질 때가 있었기 때문입니다. 왜냐하면 한국 SI는 지난 30년 동안 이 질문에 "예"라고 답한 것처럼 움직여 왔기 때문입니다.
그런데 요즘은 이 질문을 조금 다르게 듣게 됩니다. 이것은 진지한 이론적 질문이라기보다, 어떤 면에서는 조금 비아냥 섞인 질문에 가깝지 않을까 하고요.
건물의 가치는 어디서 올까요. 위치, 자재, 시공 품질, 용도와 면적. 건물은 고정되고 복제되지 않습니다. 반면 소프트웨어의 가치는 용법에 묶여 있고, 만들고 나면 한 명이 쓰든 천만 명이 쓰든 추가 비용이 거의 없습니다. 두 자산의 가치는 전혀 다른 법칙을 따릅니다. 이걸 몰라서 한국 SI가 소프트웨어를 건물처럼 값 매겨 온 것은 아닙니다.
이 사실을 받아들이고 나면, 질문이 다르게 서게 됩니다.
소프트웨어가 건물인 척 굴러간 30년은 누구의 선택이었을까. 그리고 그 선택의 진짜 목적은 무엇이었을까. 이 글은 그 질문을 늦게나마 풀어보려는 시도입니다.
다만 먼저 밝혀두고 싶은 것이 있습니다. 이 글에서 필자가 말하는 "개발자"는 한국 SI 산업 안에서 일해 온 개발자들입니다. 게임 회사, 솔루션 회사, 플랫폼 회사, 스타트업, 시스템·연구 분야에서 일해 온 분들은 이 글의 묘사와 겹치지 않을 수 있습니다. 그분들은 애초에 시공 프레임 바깥에서 일해왔고, 각자 자기 산업의 고유한 구조 안에 있습니다. 이 글은 SI라는 한국적으로 특수한 틀 안에 들어간 개발자들이 어떻게 그 안에서 재계급화되었는가에 관한 이야기입니다.

2. 사라진 공식 — 건물의 언어로 쓰인 소프트웨어의 가격

한국소프트웨어산업협회의 "SW사업 대가산정 가이드"라는 문서가 있습니다. 오래 전에 만들어진 공식이고, 지금도 매년 갱신됩니다.

• 직접인건비
• 제경비 (직접인건비의 140~150%)
• 기술료 (인건비와 제경비를 더한 금액의 20~40%)

구조를 잠깐 들여다보면, 이것은 누가 봐도 건설업의 공사원가 계산 방식과 쌍둥이처럼 닮았습니다. 직접노무비, 간접비, 이윤 — 건축 공사비를 산정할 때 쓰는 바로 그 뼈대입니다. 이름만 "인건비·제경비·기술료"로 바꾸어 소프트웨어에 그대로 옮겨 놓은 것에 가깝습니다.
 
공식이 건설업에서 왔다는 것은 현장에서 일해본 분들은 느낌으로 알고 계실 겁니다. 감리 제도가 건설업에서 왔다는 것, 착수·중간·완료의 단계 납품이 그렇다는 것, 심지어 "현장", "공수", "투입", "철수" 같은 일상 용어가 모두 그렇다는 것도요. 그런데 필자가 최근 다시 생각해보며 놀라게 된 지점은, 공식만 수입된 것이 아니라 공식이 전제하는 세계관 자체가 수입되었다는 점이었습니다.
 
이 세계관이 무엇이냐 하면, "결과물의 가치는 투입된 사람의 양으로 근사할 수 있다"는 명제입니다. 건설에서는 이 명제가 어느 정도 작동합니다. 자재와 인력이 건물의 최종 가치에 꽤 큰 비중을 차지하고, 시공 과정의 품질이 건물의 수명을 결정하기 때문입니다. 그런데 소프트웨어에서는 이 명제가 거의 작동하지 않는 것 같습니다. 짧은 시간에 만든 서비스가 큰 가치를 만들기도 하고, 많은 사람이 오래 투입된 시스템이 몇 년 뒤 폐기되기도 합니다. 결과물의 가치와 투입량 사이의 연관이 너무 약합니다.
그런데 우리는 이 느슨한 연관에 기반한 공식을 유일한 가격 언어로 써 왔습니다.

Image generated by Gemini

3. 절반만 수입된 언어

건설업의 세계는 사실 두 개의 언어로 돌아갑니다.
 
하나는 공정 관리의 언어입니다. MM 산정, 공수, 감리, WBS, 착수·중간·준공 — 이것은 건물을 짓는 과정을 관리하는 도구들입니다. 사람 몇 명이 어떤 순서로 움직이는가를 정량화하는 언어입니다.
 
다른 하나는 결과물 가치 평가의 언어입니다. 감정평가사, 공시지가, 시장 거래가, 매매 사례, 임대 수익 환산 — 이것은 완공된 건물이 얼마의 값을 하는가를 외부에서 판정하는 도구들입니다. 공정 관리와는 분리된, 독립적인 평가 체계입니다.
 
건설업이 그래도 안정적으로 돌아갈 수 있었던 것은 이 두 언어가 모두 작동하기 때문이라고 필자는 생각합니다. 건설사는 공정 원가로 계산하고, 시장은 결과물 가치로 계산하며, 양쪽 사이의 거리가 곧 건설사의 이윤이 됩니다. 두 언어가 서로를 견제하기 때문에 어느 한쪽이 일방적으로 가격을 정하지 못합니다.
 
한국 SI에 수입된 것은 이 두 언어 중 앞의 절반뿐이었습니다. 공정 관리의 언어는 고스란히 넘어왔습니다. 그런데 결과물의 가치를 외부에서 평가하는 언어는 들어오지 않았습니다. 들어올 수가 없었습니다. 소프트웨어에는 감정평가사가 없고 공시지가가 없기 때문입니다.
결과물의 가치를 측정할 언어가 없으니, 공정 관리의 언어가 그 빈자리까지 떠맡게 되었습니다. MM은 원가 계산의 도구이자 동시에 가격 결정의 도구가 되었습니다. 이것은 건설업에서도 있을 수 없는 일입니다. 건설에서는 공사원가와 시장 가격이 다른 층위에 있지만, SI에서는 공사원가가 곧 시장 가격이 되어버린 겁니다.
 
이 구조가 고착되면 어떤 일이 벌어지냐 하면, 발주처도 SI도 "이 시스템이 얼마의 가치를 만드는가"라는 질문을 할 수 없게 됩니다. 물어볼 언어가 없기 때문입니다. 그래서 양쪽 모두 "몇 MM 들어가는가"로만 대화하게 됩니다. 이것이 지난 30년 한국 SI의 가격 협상 풍경이었고, 지금도 대체로 그렇습니다.
 
그런데 한 번 더 물어보고 싶습니다. 왜 우리는 처음부터 건물의 언어를 썼을까. 다른 선택지가 정말 없었을까요.

4. 골드칼라의 짧은 계절

이 지점에서 필자는 90년대 말로 잠깐 시선을 돌리고 싶습니다. 필자도 그 시기의 끝자락에 있었던 세대라 기억이 비교적 선명합니다.
 

Image generated by Gemini

 
그 시절 프로그래머는 골드칼라라고 불렸습니다. WWW가 처음 등장하고 닷컴 붐이 막 피어오르던 때였습니다. 화이트칼라도 블루칼라도 아닌, 새로 등장한 어떤 계급. 당시의 자기 인식은 꽤 당당했습니다. 코엑스 근처를 반바지에 티셔츠, 슬리퍼 차림으로 오가는 개발자들이 있었습니다. 같은 건물의 양복 입은 컨설턴트들은 그 모습을 못마땅하게 바라보았지만, 개발자들은 개의치 않았습니다. 자기들이 파는 것이 옷차림으로 매겨지지 않는다는 것을 알고 있었기 때문입니다.
 
이 짧은 계절의 프로그래머에게는 몇 가지 특이한 성질이 있었습니다.
 
기성 문법을 공유하지 않았습니다. 전문직의 공통 자본이라고 할 수 있는 학벌, 의전, 복장 코드, 업무 관행을 따르지 않았습니다. 이건 단순한 자유분방함이 아니라 "너희의 문법을 내 직업의 평가 기준으로 받아들이지 않는다"는 선언에 가까웠던 것 같습니다.
 
학벌 위계가 제대로 작동하지 않는 구역이었습니다. 지방대 출신이 명문대 출신보다 기술적으로 인정받는 일이 흔했고, 정규 교육 바깥에서 온 창업자가 큰 성공을 거두기도 했습니다. 기성 한국 사회의 서열이 이 구역 안에서는 힘을 잃었습니다.
 
돈의 속도가 달랐습니다. 넥슨의 김정주 창업자가 재계 10위 안쪽으로 진입했을 때, 오래된 재벌 회장들은 오랜 시간 그를 "진짜" 재계의 일원으로 인정하지 않는 분위기가 있었습니다. 필자가 보기에 그건 단순한 텃세가 아닙니다. 재벌이 3대에 걸쳐 축적한 것을 게임 회사 창업자가 한 세대에 만들어 버렸을 때, 기성 질서는 그 새 자본이 자기 범주 안에 들어오는 것을 쉽게 허용하지 않았습니다. 공식 카테고리에 넣어주지 않으면, 아무리 돈이 많아도 "그들 중 하나"가 되지 못합니다.
 
자체 권위 체계를 만들어냈습니다. 오픈소스 커뮤니티, 해커 문화, 기술 블로그, 학회 바깥의 개발자 모임. 기성 권위와 무관하게 "누가 존경받는 엔지니어인가"를 자기들끼리 정하는 체계가 자라고 있었습니다. 기성 질서 입장에서 보면 통제권 바깥의 신분 체계가 생기고 있었던 셈입니다.
 
이 네 가지가 겹쳐 있으면, 이 계급은 기성 질서에게 대단히 불편한 존재가 됩니다. 불편하면 대응이 따라옵니다.
한 가지만 미리 덧붙여 두고 싶습니다. 이 세대 안에서도 나중에 가는 길은 꽤 갈렸습니다. 솔루션 회사나 게임 회사를 만들어 자기 결과물로 승부하려 한 사람들, 연구소나 해외로 간 사람들, 그리고 SI 현장으로 흘러 들어간 사람들이 있었습니다. 이 글에서 앞으로 다룰 이야기는, 이 중에서 SI 현장으로 간 경로에 해당합니다. 다른 길을 간 분들은 이어지는 묘사와 겹치지 않을 수 있습니다.
 

5. 화가 났던 이유도 있었을 것 입니다

여기까지만 쓰면 마치 기성 질서가 이유 없이 화를 낸 것처럼 보일 수 있는데, 필자는 그것이 정확한 기술이 아니라고 생각합니다. 자본과 관리자들에게도 화낼 이유는 있었습니다.
 
그 시절 현장을 돌이켜 보면, 골드칼라의 당당함 안에는 방종도 섞여 있었습니다. 필자 자신이 그 현장에 있었던 사람으로서 조심스럽게 말씀드리면, 관리자가 기술을 모른다는 사실이 종종 방패가 되곤 했습니다. 납기가 늦어질 때 "기술적으로 어렵다"는 말이 실제 어려움을 가리키는지, 아니면 그저 하고 싶지 않거나 재미있는 다른 걸 먼저 만들고 있다는 뜻인지, 외부에서는 구분할 방법이 거의 없었습니다.
 
필요한 기능보다 만들고 싶은 기능을 먼저 만들고, 당위 없이 기술 스택을 갈아치우면서 일정을 끌고, 수십억이 들어간 프로젝트가 결국 "재미있는 조각들"만 남기고 끝나는 경우도 적지 않았습니다. 별 쓸데없는 사이트에 수십억이 꽂히던 시절이었고, 그 돈이 어떻게 쓰이고 있었는지도 이제는 솔직하게 이야기할 수 있을 것 같습니다. 이게 특별한 예외가 아니라 그 시절의 꽤 일상적인 풍경이었다고, 필자는 이제 인정해야 할 것 같습니다.
 
자본 입장에서 보면 이것은 단순한 취향의 문제가 아니라 실제 손실이었습니다. 돈을 넣었는데 관리가 안 되고, 관리가 안 되는 이유가 무엇인지조차 외부에서 알 수 없었습니다. 이런 상황에서 "관리의 틀을 씌우자"는 결론이 나오는 것은, 자본주의 논리 안에서는 지극히 당연한 반응이었습니다.
 
그래서 필자가 앞으로 시공 프레임에 대해 말하려는 것은 "관리가 필요 없었다"가 아닙니다. 관리는 필요했습니다. 골드칼라의 방종은 실제로 있었고, 거기에 대응해야 할 경영적 요구는 정당했습니다. 문제는 다른 데 있습니다.
 

6. 시공 프레임이라는 우리

문제는 그 시정이 지나치게 멀리 갔다는 점에 있었습니다. 그리고 그 지나침에는, 사실 개발자 쪽의 책임도 함께 있었던 것 같습니다.
 
관리의 틀이 꼭 건설업의 시공 프레임이어야 했던 것은 아닙니다. 그 시기에도 창의성과 관리를 함께 끌고 가려는 시도들은 있었습니다. 애자일, 익스트림 프로그래밍(XP), 페어 프로그래밍, 코드 리뷰 문화 — 이런 틀들이 2000년대 초반부터 해외에서 국내로 소개되었고, 권해졌고, 일부 조직에서는 실험되기도 했습니다. 이 틀들이 공통적으로 요구하는 것은 개발자 자신의 적극적 참여였습니다. 문서를 쓰고, 자기 일을 설명하고, 동료와 소통하고, 관리자와 대화하는 일이 그 안에 포함되어 있었습니다.
 
그런데 필자가 기억하는 한, SI 현장으로 들어간 개발자들의 상당수는 이런 요구를 반기지 않았습니다. 문서 쓰기는 귀찮은 일이었고, 관리자와의 소통은 성가신 일이었고, 자기가 뭘 만들고 있는지 정리해서 설명하는 것은 자존심이 상하는 일이었습니다. "나 혼자 할 테니 나를 내버려 두라"는 정서가 꽤 뿌리 깊었습니다. 히키코모리형 오타쿠 문화가 방구석에서 직업 현장으로 넘어왔는데 그 성질까지 함께 들고 나온 측면이 있었다고, 필자는 이제 생각합니다. 본인이 재미있어하는 기술 이야기는 어린아이처럼 신나게 하면서도, 그 일을 남이 이해할 수 있게 정리하는 일에는 끝까지 인색했던 것입니다.
 
그러면서 개발자들이 실제로 원했던 것은 가장 덜 귀찮은 프로세스였습니다. "이거 언제까지 돼요?" "다음 주까지요." — 이 두 줄짜리 대화 정도가 개발자 쪽에서 받아들일 수 있는 관계의 최소 형태였습니다. 질문은 짧고 답도 짧고, 그 사이에 자기가 뭘 어떻게 만들지에 대한 설명은 들어가지 않습니다. 회고도, 문서도, 리뷰도, 페어링도 — 이 모든 것은 이 최소 프로세스를 복잡하게 만드는 성가신 요구로 느껴졌습니다. 그래서 권유되면 피하고, 도입되면 형식적으로 흉내만 내는 일이 반복되었습니다.
 
자본과 관리자들이 연성 틀을 포기한 것은 이 지점이었던 것 같습니다. 말로 되지 않는 상대에게는 강제력이 있는 틀을 씌울 수밖에 없다는 결론이 내려졌고, 그 자리에 한국 사회가 꺼내든 것이 이미 완성되어 있던 통제 체계 — 건설업의 시공 프레임이었습니다.
 
돌아보면 이것은 양쪽이 맞물려 들어간 거래였던 것 같습니다. 자본은 통제를 얻었고, 개발자는 "언제까지 돼요? 다음 주까지요"의 최소 프로세스를 얻었습니다. 창의성 대신 간섭받지 않을 시간을, 자율 대신 납기 앞에서의 면피를 얻은 것입니다. 그리고 시간이 흐르면서 양쪽 다, 자기가 무엇을 내주고 무엇을 얻었는지 서서히 잊어버리게 된 것 같습니다.
 
그렇게 자리 잡은 시공 프레임이 어떤 구조였는지 잠깐 들여다보려고 합니다. 그 안에는 발주처가 있고, 원청과 하청과 재하청이 있고, 공정이 있고, 감리가 있고, 인부와 일용직과 십장이 있고, 공수와 MM이 있고, 현장 상주라는 물리적 배치가 있고, 마감 앞에서 밤을 새는 문화가 있었습니다. 이 체계를 소프트웨어에 그대로 씌우면 어떤 일이 벌어지는지 상상해 봅니다.
 
자기 회사 사무실에서 반바지 차림으로 코드를 짜던 프로그래머가, 출입증을 걸고 발주처 건물에 상주하게 됩니다. 일일 출근부를 쓰고, 주간 보고를 올리고, 월말에 몇 MM을 소진했는지 정산을 받게 됩니다. 자기 회사의 자산을 쌓을 기회는 거의 사라집니다. 코드도 도메인 지식도 고객사 안에 남고, 프로젝트가 끝나면 빈손으로 나옵니다. 같은 일을 하고 있는데 계급이 바뀌어 있습니다.
 
그리고 이 과정에서 관리와 함께 잘려 나간 것이 있습니다. 창의성(Creativity)입니다.
 
시공 프레임은 정해진 설계도를 정해진 순서로 정해진 품질로 구현하는 체계입니다. 거기에는 "이걸 이렇게 한번 해볼 수 있지 않을까"라는 질문이 끼어들 자리가 없습니다. 설계도는 이미 있고, 인부는 그것을 따라갈 뿐입니다. 관리가 필요하다는 명분 아래, 관리만 남기고 창의성은 덤으로 함께 잘라낸 것입니다. 고삐를 채우고 재갈을 물리는 수준에서 멈춘 게 아니라, 벽돌을 쌓는 일만 남게 만든 것. 필자가 보기에는 이것이 진짜 비극입니다.
 
이 선택을 한 사람들은 대체로, 양복 입고 코엑스에서 눈살을 찌푸리던 그분들이었던 것 같습니다. 정부 부처, 공공기관, 대기업 전산실, 대형 컨설팅 펌에 있던 분들. 그분들이 자기에게 익숙한 통제 틀(건설업)을 꺼내 들고 이 낯선 직업군 위에 얹었습니다. 이게 회의실에 모여 계획한 음모였는가 하면 꼭 그렇지는 않을 것 같습니다. 각자의 자리에서 각자가 이해하는 방식으로 움직였을 뿐입니다. 그런데 그 개별 행위자들의 움직임이 모이면 결과적으로는 한 직업군을 재계급화하는 집합적 작업이 됩니다. 그리고 그 저변에는, 필자가 보기에는, "게으르고 제멋대로였던 애들은 혼이 나야 한다"는 정서도 조금은 섞여 있었던 것 같습니다.
 

7. 관리자가 된 사람들

이 프레임이 얼마나 깊이 뿌리내렸는지 드러나는 한 지점이 있습니다. 관리자 승진 구조입니다.
 
시공 프레임 안에서 조직의 사다리를 올라간 분들은, 대체로 개발을 잘해서가 아니라 관리를 잘해서 올라간 분들이었습니다. 공수를 관리하고, 납기를 맞추고, 인력을 배분하고, 위아래로 보고를 올리는 능력 — 이것은 개발 역량과는 완전히 다른 근육입니다. 프레임이 통제를 요구했기 때문에, 통제할 수 있는 사람이 그 자리에 가는 것은 조직의 자연스러운 대응이었습니다. 문제는 그 자연스러운 대응이 악순환을 만들었다는 점에 있습니다.
 
관리 중심의 관리자가 위에 자리 잡으면, 조직의 평가 기준도 자연스럽게 그쪽으로 기울어집니다. 개발을 잘하는 부하보다 관리에 협조적인 부하가 더 높은 평가를 받게 됩니다. 몇 차례 이런 승진이 반복되면 조직의 상층부는 거의 전부 관리 중심의 사람들로 채워집니다. 그들이 내리는 의사결정은 관리의 논리를 따릅니다. 그러면 현장의 개발자들은 시키는 대로 벽돌을 쌓는 편이 자기 안위에 유리해집니다. 창의적으로 움직이는 것은 통제를 어렵게 만들기 때문에, 평가에서도 불리하게 작용하기 때문입니다.
 
이렇게 되면 "골드칼라의 방종"이 발생할 토양 자체가 사라집니다. 관리자가 원하는 것은 창의성이 아니라 순응이고, 개발자도 그에 맞춰 순응합니다. 크리에이티비티가 조직 내부에서 재생산될 통로가 끊깁니다. 한국 SI의 현재 모습이 이런 것 같습니다. 방종은 사라졌지만, 만들고 싶은 것도 함께 사라졌습니다.
 
시공 프레임 씌우기는 이 단계에 와서 완성됩니다. 외부에서 틀을 씌우는 것으로 시작해서, 조직 내부가 그 틀에 맞는 사람들로 재편되고, 결국 시스템이 스스로 자기를 재생산합니다. 한번 여기까지 오면 외부의 힘 없이는 바뀌지 않습니다.
 
게임 산업도 크게 다르지 않은 것 같습니다. 크런치 문화, 확률형 아이템 강제, 기획 없는 양산 — 이런 것들은 자본의 요구만으로 만들어진 게 아니라, 자본의 요구에 응답할 수 있는 관리자들이 산업의 상층부를 차지했기 때문에 가능해진 현상들로 보입니다. 크리에이티비티가 중심이었다면 일어나기 어려운 선택들이, 관리가 중심이 된 조직에서는 자연스럽게 일어납니다.
 
이 프레임화가 실제로 자리 잡는 데는 두 번의 결정적 계기가 있었습니다. 2000년 전후의 대량 공급으로 개발자 희소성의 상단이 무너졌고, 뒤이은 닷컴 버블의 붕괴로 기대가 떠받치던 가격이 갈 곳을 잃었습니다. 그 공백을 시공 언어가 통째로 메웠습니다. 그 이후의 20년은 이 프레임 안에서 개발자들이 각자의 방식으로 자기 자리를 버텨 온 시간이었고, 개별 영웅담은 많았지만 산업 전체의 가격 언어는 끝내 바뀌지 않았습니다. 개인의 탈출은 가능했지만 직능의 자기 정의는 회복되지 않았습니다.
 

8. AI 앞에서 — 포크레인과 삽질꾼

여기까지 오면, 지금 현장에서 벌어지는 일들이 조금 다르게 보이기 시작합니다.

 
발주처가 AI를 이유로 MM을 깎자고 할 때, 그것은 새로운 논리가 아닙니다. 30년 전에 세워둔 시공 프레임이 AI 앞에서도 그대로 작동하고 있는 것뿐입니다. 건설업에서 포크레인이 도입되면 삽질 인부의 수를 줄이는 것이 지극히 자연스럽듯이, 시공 프레임 안에서 AI가 도입되면 MM을 줄이는 것이 자연스럽게 느껴지는 것입니다. 오히려 줄이지 않는 것이 이상하게 보이는 구조입니다.
 
필자가 최근 참여한 한 회의에서 발주처는 AI를 근거로 들며 UI/UX 업체의 공수를 7 MM에서 3 MM으로 조정했습니다. 담당자는 당혹스러워했습니다. "AI로 해봤지만 결국 사람이 다 해야 한다"고 말했고, "MM이 이렇게 깎인 것은 처음"이라고 했습니다. 필자가 그 자리에서 느낀 것은, 그분이 항의할 언어를 가지고 있지 않다는 점이었습니다. "판단의 값은 따로 매겨져야 한다"고 말하려면, 판단의 값을 매기는 언어가 시장에 있어야 합니다. 그런데 그 언어는 30년 전 시공 프레임이 씌워지던 순간에 이미 산업에서 제거되었습니다.
 
SI 프레임 안의 개발자들이 AI 앞에서 저항할 언어를 찾지 못하는 것도 같은 이유라고 필자는 생각합니다. 시간을 파는 사람으로 30년을 살아온 직업군은, 시간을 깎는 도구 앞에서 "내가 파는 건 시간이 아니다"라고 말할 근거를 갖고 있지 않습니다. 그 근거는 30년 전에 이미 빼앗겼습니다.
 
이 언어가 일상에서 어떻게 작동하느냐 하면, "이건 몇 개월에 얼마, 저건 몇 주에 얼마"라는 대화 이외의 방식으로는 가격을 말할 수 없게 된다는 것입니다. 필자는 이것을 견적의 문법이라고 부르고 싶습니다. 이 문법 안에서는 결과물의 가치를 말할 자리도, 판단의 값을 주장할 자리도 없습니다. 오직 투입만이 거래됩니다. 개별 개발자가 아무리 "내가 파는 것은 시간이 아니다"라고 생각해도, 견적 자리에 앉는 순간 이 문법으로 대화해야 합니다. 이건 개인의 사고방식이 아니라 관계를 지배하는 문법이기 때문입니다.
 
그리고 여기서 한 가지가 더 슬픈 것 같습니다. 그 저항할 언어를 내부에서 만들어낼 수 있는 사람들도 이제는 거의 남아 있지 않다는 것입니다. 창의성이 잘려 나간 자리에는 순응만 남았고, 관리자로 올라간 분들은 이 언어를 만드는 일에 관심이 없습니다. 그들의 일은 관리이지 직능의 자기 정의가 아니기 때문입니다. 그러니 AI 앞에서도 산업은 그저 MM을 깎이는 것 외에는 다른 대응을 떠올리지 못하는 상태가 된 것 같습니다.
 

9. 소프트웨어는 건물이 아니었습니다

처음 질문으로 돌아가 보려고 합니다.
 
소프트웨어는 건물과 같은 가치를 지닐까요. 답은 이미 정해져 있습니다. 아닙니다. 소프트웨어의 가치는 투입량이 아니라 용법에 있고, 물질이 아니라 가능성에 있습니다. 건물의 언어로는 소프트웨어의 가치를 제대로 매길 수 없습니다.
 
그런데도 한국 SI는 30년 동안 건물의 언어로 소프트웨어를 팔았습니다. 이 글에서 필자가 말하고 싶었던 것은 그 30년이 순진한 선택의 결과가 아니었다는 점입니다. 소프트웨어를 건물이라고 믿어서 그 언어를 쓴 게 아닙니다. 소프트웨어 자체가 아니라, 그것을 만드는 사람을 어떻게 다룰 것인가 — 그리고 그 사람에게 들어가는 돈을 어떻게 증빙할 것인가가 실제 관심사였고, 그 관심사에 맞는 도구를 꺼내든 결과가 시공 프레임이었습니다. 감리도, 등급제도, 대가산정 가이드도 — 모두 이 두 목적을 동시에 해결하는 도구였습니다. 방종한 사람들을 통제 가능한 형태로 만드는 동시에, 공공 예산이 감사받을 수 있는 형태로 집행되게 하는 것. 이 두 목적이 같은 도구 위에서 만났기 때문에 프레임은 그토록 강했고, 지금까지도 잘 바뀌지 않고 있습니다.
 
그 선택의 방아쇠가 된 것은 한편으로는 골드칼라의 방종이었고, 다른 한편으로는 낯선 계급을 익숙한 구조에 집어넣어 통제하려는 힘이었습니다. 두 가지가 서로를 강화하며 맞물려서, 결과적으로 이 산업에서 창의성은 잘려 나가고 벽돌 쌓기만 남았습니다.
 
AI는 이 프레임의 한계를 드러내고 있습니다. 건물이었다면 AI 한 줄이 MM을 반토막 낼 수 없습니다. 건물은 자재와 노동을 그만큼 줄일 수 없습니다. AI가 MM을 흔드는 지금의 현상은, 소프트웨어가 처음부터 건물이 아니었다는 증거에 가깝습니다. 단지 다른 가격 언어가 없었기 때문에 건물의 언어를 빌려 써 왔을 뿐이라는 사실이, 새삼 드러나고 있는 것 같습니다.
 
그럼 이제 어떻게 해야 할까요.
 
이 글이 끝날 때쯤 남는 것은 해법이 아니라 한 가지 사실입니다. 우리가 30년 동안 살아온 세계는 소프트웨어의 세계가 아니라 건물의 세계였다는 것. 우리가 벽돌을 쌓는 사람으로 일해왔다는 것. 그리고 AI는 그 세계의 한계를 드러내면서, 다른 세계가 존재한다는 사실을 우리 앞에 흘려놓고 있다는 것.
 
그 다른 세계가 어떤 모습인지, 어떻게 그 세계로 비켜설 수 있는지는 이 글의 범위가 아닙니다. 다만 한 가지는 확실해 보입니다. 이 프레임이 자연스러운 것도, 필연적인 것도 아니었다는 사실을 아는 것이 첫걸음이라는 점입니다. 오래 갇혀 있던 사람일수록 자기 감옥이 감옥이라는 사실을 인식하는 데 가장 긴 시간이 걸립니다. 이 글이 그 시간을 조금이라도 줄일 수 있기를 바랍니다.

---

필자 바슬러는 28년차 SI 개발자이자 프리랜서로, 발주처·SI 본부·1인 개발 세 자리에서 바이브 코딩이 만든 변화를 관찰하고 기록하고 있습니다.