AI가 코드를 짜준다고요? 진짜 지옥은 그 다음에 열립니다

"이거 왜 이러죠?" 3일 밤낮으로 범인을 찾다

최근 사내 문서 검색용으로 간단한 챗봇을 하나 만들었습니다. 요즘 유행하는 기술이죠. 질문을 던지면 AI가 내부 자료를 뒤져서 답을 찾아주는 방식입니다. 개발은 쉬웠습니다. 오픈AI가 제공하는 API(Application Programming Interface, 프로그램끼리 소통하는 창구나 규칙)를 쓰고, 요즘 잘 나가는 개발 도구를 몇 개 붙이니 그럴싸한 물건이 뚝딱 나왔습니다. 딱 반나절 걸렸습니다.

문제는 그 다음부터였습니다. 잘 되던 챗봇이 어느 날부터 특정 질문에만 이상한 답변을 내놓기 시작했습니다. "지난 분기 마케팅 예산 보고서 요약해줘"라고 물으면, 엉뚱하게 3년 전 영업팀 자료를 가져와서 떠드는 식이었습니다. 처음엔 AI 모델, 즉 LLM(Large Language Model, 사람 말처럼 문장을 만들어내는 거대 인공지능)의 문제라고 생각했습니다. 프롬프트(AI에게 주는 명령어)를 바꿔보고, 모델 버전도 바꿔봤습니다. 소용이 없었습니다.

이틀쯤 지났을까, 범인은 의외의 곳에 있었습니다. AI가 문서를 검색할 때 참고하는 사내 데이터베이스 시스템이었습니다. 오래된 이 시스템은 특정 조건에서 검색어 일부를 멋대로 잘라버리는 버릇이 있었고, 하필 그 조건이 '마케팅'과 '예산'이라는 단어가 함께 들어올 때 발동됐던 겁니다. AI는 잘못된 재료(잘려나간 검색어)를 받아들고도 천연덕스럽게 그럴싸한 요리(엉뚱한 답변)를 내놓고 있었던 셈입니다. 범인을 잡는 데 꼬박 3일이 걸렸습니다. AI 코드는 단 한 줄도 고치지 않았습니다.

요즘 업계의 고민이 바로 이 지점에 있습니다. 모두가 AI 모델 자체의 신비로운 '블랙박스'를 걱정하지만, 정작 현장에선 AI와 그를 둘러싼 복잡한 시스템 전체가 거대한 블랙박스가 되어가고 있습니다. AI라는 새롭고 강력한 부품이 들어오면서, 기존 시스템의 낡은 문제점과 맞물려 예측 불가능성이 폭발적으로 증가하는 것입니다.

AI는 셰프일 뿐, 레스토랑 전체가 문제다

많은 분들이 AI 시스템을 생각할 때, 두뇌 역할을 하는 AI 모델만 떠올립니다. 하지만 현실의 AI 서비스는 훨씬 복잡합니다. 이건 마치 근사한 레스토랑을 여는 것과 같습니다.

스타 셰프(AI 모델) 한 명 영입했다고 끝이 아닙니다. 훌륭한 요리가 나오려면 수많은 요소가 맞물려 돌아가야 합니다.

• 신선한 재료 조달 (데이터): 셰프에게 줄 재료의 품질이 엉망이면 어떤 요리도 망칩니다. AI에게 주어지는 데이터가 지저분하거나 편향되어 있으면, 결과물 역시 엉망이 됩니다.
• 주방 보조와 식기 (외부 API 및 인프라): 셰프가 요리하는 동안 필요한 도구를 제때 가져다주고, 그릇을 셔틀처럼 날라주는 동료들이 필요합니다. 외부 날씨 정보를 가져오거나, 결제를 처리하는 등 다른 서비스와 데이터를 주고받는 API들이 바로 이 역할입니다. 이들의 속도가 느리거나 갑자기 파업하면 주방 전체가 마비됩니다.
• 홀 서빙 직원 (사용자 인터페이스): 아무리 맛있는 요리도 차갑게 식어서 나가거나, 엉뚱한 테이블에 배달되면 손님은 화를 냅니다. 사용자가 AI와 만나는 화면(UI)이 불편하거나 반응이 느리면, AI의 성능을 체감할 수 없습니다.
• 주방과 홀의 전체 설계 (시스템 아키텍처): 가장 중요한 것은 이 모든 요소가 유기적으로 움직이도록 하는 레스토랑의 전체 구조, 즉 '시스템 아키텍처'입니다. 재료 창고는 어디에 둘지, 조리대와 홀의 동선은 어떻게 짤지, 주문은 어떤 방식으로 전달할지 같은 설계 말입니다.

제가 겪었던 문제도 마찬가지입니다. 스타 셰프(AI 모델)는 죄가 없었습니다. 재료 창고(데이터베이스) 관리인이 멋대로 재료 이름을 바꿔치기한 게 문제였습니다. 하지만 손님 입장에서는 그냥 '음식이 이상하다'고 느낄 뿐입니다. 이 복잡한 과정 속에서 어디가 문제인지 짚어내는 것, 이것이 오늘날 AI 시대를 살아가는 엔지니어의 진짜 숙제입니다.

문제가 생겼을 때 원인을 찾는 과정은 과거와 비교할 수 없이 복잡해졌습니다. 과거에는 코드를 한 줄 한 줄 따라가면 범인을 잡을 수 있었습니다. 하지만 지금은 AI 모델, 데이터, 외부 서비스, 네트워크, 기존 시스템 등 용의선상이 너무 넓습니다. 'AI 시스템 디버깅'은 단순한 코드 수리가 아니라, 복잡하게 얽힌 관계를 추적하는 탐정의 일에 가까워졌습니다.

4세대 언어와 CASE 도구의 망령

사실 이런 현상이 처음은 아닙니다. 기술의 역사는 '개발을 쉽게 해주겠다'는 약속과 그 약속의 배신으로 가득 차 있습니다. 1980년대와 90년대, 'CASE(Computer-Aided Software Engineering) 도구'라는 것이 있었습니다. 마치 파워포인트로 그림을 그리듯 시스템 설계도를 그리면, 컴퓨터가 알아서 코드를 만들어준다는 꿈의 기술이었습니다. '4세대 언어'라 불리던 것들도 비슷한 약속을 했습니다. 복잡한 명령 대신 사람 말에 가까운 언어로 요구사항을 말하면 프로그램이 뚝딱 나온다고 했죠.

결과는 어땠을까요? 처참한 실패였습니다. 왜 그랬을까요? 이 도구들은 소프트웨어 개발에서 가장 '쉬운' 부분, 즉 정형화된 코드를 찍어내는 일만 자동화했기 때문입니다. 진짜 어려운 문제는 따로 있었습니다.

1. 세상의 복잡함을 다 담지 못했습니다: 현실의 비즈니스 규칙은 설계도처럼 깔끔하지 않습니다. "A이면 B이다. 단, 부장님 기분 안 좋을 땐 C이다" 같은 예외와 맥락이 넘쳐납니다. CASE 도구는 이런 미묘함을 담지 못했습니다.
2. '접착제' 역할이 더 힘들었습니다: 그렇게 자동 생성된 코드 덩어리를 기존의 낡은 회계 시스템이나 인사 시스템에 '붙이는' 작업이 진짜 고역이었습니다. 이 '접착제 코드(glue code)'를 짜는 데 전체 개발 시간의 대부분이 들어갔습니다.
3. 유지보수가 불가능했습니다: 도구가 만들어준 코드는 사람이 읽고 이해하기 어려웠습니다. 결국 작은 수정 하나 하려고 해도, 도구를 다시 열어 처음부터 그림을 고쳐야 했습니다. 차라리 처음부터 사람이 짜는 게 빨랐습니다.

요즘 AI 기반 코딩 도구들이 하는 약속이 꼭 이와 같습니다. "개발의 종말이 온다", "이제 말만 하면 앱이 만들어진다"고들 합니다. 맞습니다. 단순하고 독립적인 코드 조각을 만드는 일은 놀라울 만큼 잘합니다. 하지만 문제는 그 다음입니다. 그렇게 만들어진 '싱싱한 AI 코드'를 우리 회사의 20년 된 '삭은 인사 시스템'에 연결하는 순간, 진짜 엔지니어링이 시작됩니다. CASE 도구가 실패했던 바로 그 지점, '시스템 통합'이라는 장벽에 다시 부딪히는 것입니다.

AI는 복잡한 시스템의 한가운데 떨어진, 강력하지만 예측 불가능한 부품입니다. 이 부품의 성능이 좋을수록, 그 주변을 둘러싼 다른 부품들과의 상호작용은 더 미묘하고 복잡해집니다. 결국 '전체를 보는 눈', 즉 아키텍처를 설계하고 문제의 근원을 파악하는 능력의 가치는 떨어지는 게 아니라 오히려 치솟고 있습니다.

눈에 보이지 않는 비용: '디버깅 세금'과 '통합 부채'

AI를 도입한 시스템은 눈에 보이지 않는 비용을 청구하기 시작합니다. 저는 이걸 '디버깅 세금(Debugging Tax)'과 '통합 부채(Integration Debt)'라고 부릅니다.

'디버깅 세금'은 말 그대로 버그를 잡는 데 들어가는 추가 비용입니다. 과거에는 명확한 원인과 결과가 있었습니다. 코드를 잘못 짜면 프로그램이 죽거나, 계산이 틀립니다. 하지만 AI 시스템의 버그는 다릅니다. 프로그램이 죽는 대신, '그럴싸하지만 교묘하게 틀린 말'을 지어냅니다. 이런 문제를 '환각(Hallucination)'이라고 부르기도 합니다. 이 버그는 나타났다 사라지기를 반복하고, 원인을 특정하기가 극도로 어렵습니다.

표에서 보듯, AI 시스템의 디버깅은 차원이 다른 문제입니다. 문제의 원인이 될 수 있는 변수가 너무 많기 때문입니다. 제가 겪었던 3일간의 사투는 결코 특별한 사례가 아닙니다.

'통합 부채'는 더 심각합니다. 일단 돌아가게 만드는 데 급급해 AI 모듈을 기존 시스템에 욱여넣으면, 당장은 괜찮아 보입니다. 하지만 시스템의 복잡성은 기하급수적으로 늘어납니다. 시스템의 설계 원칙이나 데이터 흐름에 대한 명확한 이해 없이 덕지덕지 기능을 붙이면, 나중에는 누구도 그 시스템의 전체 그림을 이해하지 못하게 됩니다. 이것이 기술 부채, 그중에서도 가장 악성인 '통합 부채'입니다. 새 개발자가 들어와 시스템을 파악하는 데 6개월이 걸린다면, 그건 전부 이 부채를 갚는 이자인 셈입니다.

엔비디아나 오픈AI 같은 회사들의 최근 행보도 이런 맥락에서 봐야 합니다. 그들은 단순히 더 똑똑한 AI 모델을 만드는 데서 벗어나, 이 야생마 같은 AI를 어떻게 '안전하게 우리에 넣어' 기존 시스템과 연결할지에 더 집중하고 있습니다. AI 에이전트의 이상 행동을 제어하는 플랫폼을 만들고, 외부 도구를 안정적으로 호출하는 규칙을 정교하게 다듬는 일이 그것입니다. AI의 지능 자체보다, 그 지능을 제어하고 통합하는 기술의 가치를 더 높게 보기 시작한 것입니다.

흔한 오해: 'AI 투명성'과 '개발자 종말론'을 넘어서

이런 상황에서 흔히 두 가지 오해가 나타납니다. 하나는 기술에 대한 맹신이고, 다른 하나는 공포입니다.

첫 번째 오해는 "AI 모델의 내부를 들여다볼 수 있게 되면(설명가능 AI, XAI) 모든 문제가 해결될 것이다"라는 믿음입니다. AI가 왜 그런 답변을 내놓았는지 그 논리적 근거를 보여주는 기술은 물론 중요합니다. 자동차 엔진의 내부를 투명하게 만들어 실린더의 움직임을 직접 볼 수 있게 되는 것과 같습니다. 하지만 엔진이 왜 덜덜거리는지 알려면, 엔진뿐만 아니라 연료 공급 장치, 변속기, 배기 시스템까지 모두 점검해야 합니다. AI 모델의 투명성을 확보하는 것은 필요조건일 뿐, 충분조건이 아닙니다. 그 모델이 어떤 데이터를 받아 어떤 제약 조건 속에서 작동하는지, 전체 시스템의 맥락을 모르면 반쪽짜리 해결책에 불과합니다.

두 번째 오해는 "AI가 코딩을 다 해주니 이제 개발자는 필요 없다"는 '개발자 종말론'입니다. 이것은 소프트웨어 개발을 단순히 키보드로 코드를 입력하는 행위로 착각하기 때문에 생기는 오해입니다. 앞서 말했듯, AI는 개발의 쉬운 부분, 즉 반복적인 코드 작성을 자동화합니다. 타자수의 일은 위협할 수 있겠지만, 건축가의 일은 오히려 더 중요하게 만듭니다.

이제 개발자의 핵심 역량은 '코드를 얼마나 빨리 짜느냐'가 아닙니다.

• 문제 정의: 풀고자 하는 진짜 문제가 무엇인지 명확히 정의하는 능력.
• 시스템 설계: 어떤 기술 부품들을 가져와 어떻게 조합해야 가장 효율적이고 안정적인 구조를 만들 수 있을지 그리는 능력.
• 트레이드오프 판단: 비용, 속도, 안정성 사이에서 무엇을 우선하고 무엇을 포기할지 결정하는 능력. 예를 들어, 최신 AI 모델을 써서 정확도를 1% 높이는 대신 비용이 10배 늘어난다면, 그 선택을 할 것인가?
• 디버깅 및 문제 해결: 복잡하게 얽힌 시스템에서 문제의 진짜 원인을 꿰뚫어 보고 해결책을 찾는 능력.

이 모든 것은 결국 '판단'의 영역입니다. AI는 수많은 선택지를 제시해줄 수는 있지만, 최종적인 판단과 그에 대한 책임은 사람의 몫으로 남습니다. AI는 훌륭한 부사수는 될 수 있어도, 결코 책임자가 될 수는 없습니다.

그래서, 우리는 무엇을 봐야 하는가

결론은 명확합니다. AI 혁명은 개발자의 종말이 아니라, '코더(Coder)'의 시대가 가고 '아키텍트(Architect)'의 시대가 온다는 신호입니다. 단순히 주어진 명세서대로 코드를 찍어내던 역할은 AI가 대체할 것입니다. 하지만 비즈니스 요구사항을 이해하고, 여러 기술적 제약을 고려해 최적의 시스템 구조를 설계하고, 예상치 못한 문제의 근원을 파고드는 종합적인 문제 해결사로서의 엔지니어의 가치는 오히려 폭등할 것입니다.

앞으로 우리는 몇 가지 신호를 유심히 봐야 합니다.

• 'AI 시스템 엔지니어' 직군의 부상: 단순히 AI 모델을 연구하는 '리서처'나 '데이터 사이언티스트'가 아니라, AI를 포함한 전체 시스템의 안정성과 확장성을 책임지는 역할이 더 많은 주목과 대우를 받게 될 것입니다.
• '관측 가능성(Observability)' 도구의 성장: 복잡한 AI 시스템의 상태를 한눈에 파악하고 문제의 원인을 쉽게 추적할 수 있도록 돕는 서비스들이 중요해집니다. 이는 마치 병원의 CT나 MRI 장비처럼, 시스템의 내부를 속속들이 들여다볼 수 있게 해주는 기술입니다.
• 교육의 변화: 코딩 문법을 가르치는 것에서 나아가, 시스템적 사고와 설계 원칙, 트레이드오프를 판단하는 법을 가르치는 교육의 중요성이 커질 것입니다.

AI가 생성한 코드 몇 줄에 열광할 때가 아닙니다. 그 코드가 우리 회사의 낡은 시스템과 만나 어떤 거대한 혼돈을 만들어낼지, 그리고 그 혼돈 속에서 질서를 찾아낼 사람은 결국 '판단의 값'을 지불받는 우리 자신이라는 사실을 직시해야 합니다. AI는 문제를 푸는 도구이기도 하지만, 동시에 지금까지 없던 새로운 차원의 문제를 만들어내는 원인이기도 합니다. 그 새로운 문제의 난이도가, 바로 미래 엔지니어의 몸값을 결정할 것입니다.

Q. 그럼 이제 코딩 공부는 필요 없나요? 아키텍처만 공부하면 되나요? A. 아닙니다. 오히려 그 반대입니다. 훌륭한 건축가가 벽돌의 특성을 알아야 하듯, 훌륭한 아키텍트가 되려면 코드 수준의 깊은 이해가 필수적입니다. 코드를 직접 짜지 않더라도, 어떤 코드가 좋은 코드인지, 특정 기술이 어떤 한계를 갖는지 모르면 사상누각 같은 설계만 하게 됩니다. 코딩 능력은 기본기가 되고, 그 위에 시스템 전체를 보는 눈을 더해야 하는 시대입니다.

Q. 작은 회사나 개인 개발자도 이런 복잡한 시스템 아키텍처를 고려해야 하나요? A. 물론입니다. 오히려 더 중요할 수 있습니다. 대기업은 자원으로 문제를 해결할 수 있지만, 자원이 부족한 작은 조직일수록 처음부터 좋은 구조를 만드는 것이 장기적인 생존에 결정적입니다. 간단한 토이 프로젝트라면 무시해도 되겠지만, 실제 사용자를 만나는 서비스를 만든다면 처음부터 데이터 흐름, 장애 지점, 확장 계획을 염두에 두고 설계하는 습관을 들여야 합니다. '나중에 고치지'라는 생각은 거의 항상 더 큰 비용으로 돌아옵니다.

Q. 결국 AI 기술의 한계라는 말 아닌가요? A. 한계라기보다는 '성숙통'에 가깝습니다. 어떤 강력한 기술이든 처음에는 그 자체의 성능에만 집중하다가, 점차 그것을 둘러싼 생태계와 안정적으로 통합되는 단계로 넘어갑니다. 자동차가 처음 나왔을 때 사람들은 속도에만 열광했지만, 곧이어 신호등, 차선, 교통법규, 보험 같은 '시스템'이 더 중요해졌습니다. AI도 마찬가지입니다. 모델의 지능을 높이는 단계를 지나, 그 지능을 사회와 기존 시스템 안에 안전하게 편입시키는 성숙의 단계로 접어들고 있는 것입니다. 진짜 혁신은 종종 이 지점에서 시작됩니다.