칼럼 | AI가 코드 대신 쓰는 시대, 소프트웨어 개발의 새로운 딜레마

내연기관이 보급되던 초기에는 자동차 정비소가 기본적인 도구만으로도 거의 모든 차종과 모델을 수리할 수 있었다. 그러나 기술이 고도화되면서 상황은 달라졌다. 연료 분사식 엔진이 도입되자 자동차의 내부 구조는 점점 복잡해졌고, 이는 피스톤과 점화 플러그, 카뷰레터 같은 비교적 단순한 부품을 대체했다.

연료 분사식 엔진이 일반 사용자는 물론 정비사조차 보닛 안을 들여다보지 않게 만든 것처럼, AI 코딩은 코딩의 존재가 아니라 코딩의 서비스 가능성 자체를 대체해 가고 있다. 이제 웹 애플리케이션 내부를 직접 들여다보고 이해하려는 시도는 점점 줄어들고 있다.

잘못된 코드가 곳곳에 등장할 수 있다는 점은 문제의 한 측면에 불과하다. 더 근본적인 위험은 코드를 수리하고 유지 및 관리하는 기초 역량이 사라지고 있다는 것이다. 모든 것이 즉흥적으로 결합된 소프트웨어 함수와 라이브러리로 구성된 환경에서는, 현장에서 교체하거나 손볼 수 있는 구성 요소라는 개념도 사라진다. 배포 당시에는 정상적으로 작동할 수 있지만, 시간이 지나면 관리와 유지보수가 거의 불가능해진다.

이런 상황에서 애플리케이션이 실행되는 이유나 방식을 진정으로 이해하는 사람은 점점 줄어들고 있다. 작가 로버트 피어시그는 저서 ‘선과 모터사이클 관리술(Zen and the Art of Motorcycle Maintenance)’에서 기계 내부 구조와의 관계가 끊어지는 순간 품질과의 관계도 상실된다고 말한 바 있다. 다시 말해 시스템의 구조를 이해하지 못하게 되는 순간 품질을 판단하는 능력도 사라진다는 것이다. 이처럼 서비스 가능성의 상실은 단순한 불편 사항이 아니라 새로운 리스크에 가깝다.

이론에 그치지 않는 문제

아이키도(Aikido)가 발표한 ‘2026년 AI 보안 및 개발 현황 보고서’에 따르면, 전체 조직의 5곳 중 1곳은 이미 AI 생성 코드로 인해 심각한 사고를 경험한 것으로 나타났다. 또한 약 70%는 AI 어시스턴트가 도입한 취약점을 실제로 발견했다고 답했다.

AI가 결함을 만들어냈을 때, 그 결과에 대한 책임이 누구에게 있는지는 명확하지 않다. AI로 인한 침해 사고의 최종 책임자를 묻는 질문에서는 엔지니어링 조직과 보안 조직, 벤더로 답변이 엇갈렸다. 풀 리퀘스트(PR) 게이팅을 누가 집행해야 하는지를 두고도 의견이 분분했다. 이는 거버넌스 체계가 자동화의 속도를 따라가지 못하고 있음을 보여주는 신호일 수 있다.

저연차 엔지니어는 이제 거의 전적으로 추상화 계층에서만 일하고 있다. 코드 배포 속도는 빨라졌지만, 시스템이나 네트워크, 장애가 발생하는 방식에 대한 경험은 크게 줄었다. 그 결과, AI의 출력물이 배포되기 전에 의심하고 검증할 수 있는 판단력은 약화되고 있다. 모든 대응은 사고 이후에 이뤄지며, 사람은 마치 책임을 떠안기 위해 존재하는 수단처럼 느껴진다.

AI 생성 코드는 그 자체로 조직의 핵심 가치와 보안 문화를 증폭시킨다. 보안에 대한 기본적인 원칙과 규율이 자리 잡은 조직에서는 AI 도구가 그 문화를 강화한다. 반대로 규율과 기초적인 리스크 관리가 부족한 조직에서는 자율적인 소프트웨어 개발이 미성숙한 보안 문화를 그대로 드러낸다.

알고리즘이 실패했을 때 책임은 누구에게 있을까?

자체 투자로 에이전틱 트레이딩 실험을 시작한 사모 트레이딩 기업이 있다고 가정해 본다. 알고리즘이 실패하면 회사는 손실을 입는다. 하지만 실험이었고, 회사 자본을 썼기 때문에 책임 소재를 따지는 일은 별로 없다.

이제 한 단계 더 위험을 높여, 한 헬스케어 기업이 임상의의 판단을 보조하는 방식으로 AI를 활용하는 경우를 가정해 본다. 실제로 많은 기업이 환자 접수 과정에서 의료진의 판단을 보조하기 위해 대규모 언어 모델(LLM)을 마치 NPC(non-player characters)처럼 활용하는 방안을 검토하고 있다. 이런 환경에서 알고리즘의 영향으로 환자에게 예기치 못한 결과가 발생한다면, 책임을 둘러싼 논쟁은 피할 수 없다. 부상이나 생명 손실에 대한 책임은 누가 져야 할까? 알고리즘을 개발한 회사일까, 이를 검증한 QA 팀일까, 아니면 최종 판단을 내린 의료 전문가일까?

이때 서로의 결과를 점검하는 ‘NPC 위원회’도 상상해 볼 수 있다. 각 NPC는 서로 다른 모델을 기반으로 하고, 학습 데이터와 환각 가능성도 제각각이다. 판단이 교착 상태에 빠지지 않으려면 구성원 수는 홀수여야 할 것이다. 실제로 ‘에이전트 아레나’와 같은 사례에서 이런 시도가 모습을 드러내고 있다.

초기 LLM 관련 문서가 정신 건강 프로그램에 사용돼선 안 된다고 경고했다는 점을 잊어서는 안 된다. LLM은 가장 그럴듯한 다음 토큰을 예측하는 방식으로 문제를 해결한다. 우울감이나 심리적 위기가 다뤄질 경우, LLM은 사람의 판단이나 윤리를 고려하지 못한 채 통계적으로 그럴듯해 보이는 위험한 결론을 제시할 수 있다.

잘 알려진 사례로, 한 AI 코딩 에이전트가 프로덕션 데이터베이스를 삭제한 일이 있었다. 해당 에이전트는 코드 변경이 중단된 상황에서도 수개월치 작업을 삭제했고, 이후 자신이 중대한 손실을 초래했다는 사실을 인식하고 사과했다. 이런 사고의 책임은 일반적으로 QA와 테스트 팀에 집중된다. AI 코딩 에이전트를 보안에 취약한 저연차 개발자로 간주한다면, 결국 이는 품질보다 속도를 우선시하기로 결정한 관리자의 판단 문제로 귀결된다.

AI 리스크에 준비되지 않은 보험 업계

에이전틱 AI로 인한 손실을 보장하는 보험은 보험 업계에서 아직 본격적으로 논의되고 있지 않다. 그럼에도 과실, 지식재산권 침해, 규제 책임 등을 포괄하는 보험 상품의 필요성은 충분하다. 사고가 실제로 발생할수록 AI 책임 보험의 필요성은 커질 수밖에 없다. 반대로, 비결정적 시스템의 예측 불가능성을 이유로 기존 보험에서 AI 관련 리스크를 제외하려는 움직임도 동시에 나타나고 있다.

사람들은 이미 자동 응답 시스템이 “상담원 연결은 0번을 누르세요”라고 안내하는 데 이미 익숙하다. 그러나 LLM 기반 시스템에서는 작은 입력이나 판단이 예측하기 어려운 결과로 이어질 수 있다. 이런 환경에서는 리스크의 범위를 전제로 하는 보험 모델이 작동하기 어렵다. 따라서 보험 업계가 안정을 찾기까지는 AI 저작권 침해 소송이 실제로 법정에서 다뤄지는 과정을 거칠 수밖에 없다. LLM은 구조적으로 보면, 저작권 분쟁의 위험을 서비스 형태로 확산시키는 기술에 가깝다.

코딩의 수준 저하

이제 문제의 근원으로 돌아가 보자. 저연차 개발자는 사라지고 있는 것이 아니라, 그들의 업무가 근본적으로 달라지고 있다. 저연차 보안관제(SOC) 분석가는 로그 이벤트가 악성인지 판단하는 알고리즘을 감시하며, 마케팅 인턴은 그래픽 디자이너 없이 슬라이드 자료를 만들어낸다.

LLM 결과물에는 ‘슬롭(slop)’이라는 표현이 자주 붙는다. 이는 AI가 만들어낸 결과물이 그럴듯해 보일 뿐 맥락과 의도, 품질이 부족하다는 비판을 담은 용어로, 예술계에서는 모욕처럼 받아들여질 수 있다. 예술과 디자인은 과거의 흐름과 끊임없이 대화하며, 이전 세대의 작업에 반응하고 취향을 축적하면서 발전해 왔다. 그러나 이제 시각적 결과물은 맥락이나 존중 없이 손쉽게 생성되는 평범한 미학으로 축소되고 있다.

소프트웨어 개발 역시 이와 같은 수준의 단순화 과정을 겪고 있다. 누군가는 사람이 AI로 보강될 수 있다고 말하고, 또 다른 누군가는 AI에 모든 것을 위임할 수 있다고 주장한다. 하지만 ‘위임’이라는 표현은 책임을 지는 자리에 올랐다가 내려온다는 의미를 전제한다. 많은 AI 코딩 사용자가 애초에 그 자리에 도달한 적조차 없다.

문장을 무작위로 이어 붙여도 그럴듯한 글은 나올 수 있다. 하지만 맥락을 이해하고 무엇을 말하려는지 분명히 드러내지 못한다면, 그것을 실력이 좋거나 품질이 높다고 부르기는 어렵다. 창의성과 의도는 결과물의 가치를 가르는 기준이다. 이를 포기한다면, 그 대가는 결코 가볍지 않을 수 있다.

상황을 악화시키는 ‘도구의 무분별한 확산’

아이키도의 연구에 따르면 보안 사고를 겪은 팀은 그렇지 않은 팀보다 더 많은 벤더 도구를 사용한 것으로 나타났다. 그럼에도 같은 패턴이 반복되고 있다. 새로운 보안 문제가 등장하면, 이를 해결하기 위한 또 다른 도구가 만들어진다. 어떤 도구는 문제를 해결하기는커녕 새로운 문제의 원인이 되기도 한다. 어떤 처방은 질병보다 더 큰 부작용을 낳는다. 실제로 문제 발생 시 새로운 도구를 추가하는 대응 방식은 방화벽 등장 이후 보안 산업에서 오랫동안 굳어져 온 관행이다.

필자는 사이버보안 수업에서 학생들에게 보안 인력의 자질을 둘러싼 한 가지 이야기를 전하곤 한다. 보안 전문가가 자격증을 가진 사람과 실제 역량을 갖춘 사람으로 나뉜다는 것이다. 두 집단이 겹치는 영역은 매우 좁은데, 필자는 늘 후자를 선호한다. 자격증은 있지만 인터넷이 어떻게 작동하는지 이해하지 못하는 사례가 적지 않다. 하지만 최초로 박사 학위를 수여한 사람에게는 박사 학위가 없었다는 사실을 떠올려야 한다.

CISO 역시 두 부류로 나눌 수 있다. 침해 이전의 CISO와 침해 이후의 CISO다. 침해 이전의 CISO는 도구와 소프트웨어에 집중한다. 반면 침해를 경험한 이후의 CISO는 모든 도구가 언젠가는 실패한다는 사실을 깨닫는다. 결국 가장 중요한 것은 사람과 프로세스다. 도구가 지나치게 많다는 것 자체가 문제일 수 있다는 이야기다. AI 생성 코드는 이 문제를 더욱 심화시키고 있다.

내부 정책과 실제 운영 사이의 간극

SOC2 감사는 문서로 작성된 내부 정책과 실제 운영 방식의 차이를 확인하는 데 초점을 둔다. 예를 들어 내부 정책에서 고객 데이터를 전 세계에서 접근 가능한 S3 버킷에 저장한다고 기재한 기업이 실제로도 동일하게 운영하고 있다면 감사인은 문제를 제기하지 않는다. SOC2는 인증 제도가 아니라, 기업이 스스로 정한 정책을 제대로 따르고 있는지를 판단하는 회계사의 의견이기 때문이다.

내부 정책과 절차로 인해 문제가 발생하는 경우는 크게 2가지다. 하나는 현실적으로 집행할 수 없는 완벽한 정책을 만들어놓는 경우이고, 다른 하나는 아예 문서화된 정책이 없는 경우다. 많은 기업이 후자의 상태에서 갑자기 전자로 옮겨간 뒤, 왜 지적 사항이 쏟아지는지 이해하지 못한다. 이런 맥락에서 LLM에 정책 작성을 맡기는 일은 특히 주의가 필요하다. 실제 집행 역량이나 기술 수준에 비해 지나치게 정교하고 이상적인 정책이 만들어질 가능성이 크기 때문이다.

따라서 AI 거버넌스 정책과 관련해 이사회가 던져야 할 질문은 보다 구체적이어야 한다.

• 최근 90일 동안 거버넌스 정책에 따라 AI 생성 코드가 실제로 차단된 사례를 하나라도 제시할 수 있는가?
• AI 생성 코드가 사람의 검토 없이 프로덕션 환경에 배포될 수 있는가? 불가능하다면 이를 어떻게 통제하고 있는지 증명할 수 있는가?
• 프로덕션 환경에서 어떤 부분이 AI 생성 코드인지 추적할 수 있는가?
• AI 도구가 접근해서는 안 되는 시스템은 무엇이며, 이를 누가 어떻게 집행하고 있는가?

이런 질문에 답하지 못한다면, 그 정책은 실질적인 통제 수단이 아니라 장식물에 불과할 가능성이 높다. 내부 정책이 실제 차단을 만들어내지 못하고, 코드를 검토하지 못하며, 출처를 추적할 수 없고, 핵심 영역을 명확히 보호하지 않는다면, 이는 거버넌스가 아니라 잘 정리된 문서에 그친다.

디지털 환경에서의 단일화 위험

필자는 위협 행위자가 악성코드를 충분히 검증하지 않은 채 공격에 나서, 최신 운영체제를 사용하는 모든 애플 iOS 기기가 한꺼번에 작동 불능 상태에 빠지는 상황을 가정해 본 적이 있다. iOS 이용자의 상당수가 항상 최신 OS 버전을 유지하고 있는데, 특정 환경에 사용자가 과도하게 집중되는 ‘단일화’ 현상에는 리스크가 있다. AI가 작성한 악성코드는 애플의 공식 지원 채널조차 복구하지 못하는 상황을 초래할 수도 있다. 물론 애플은 대규모 장애가 발생하더라도 전 세계 사용자에게 대체 기기를 판매하는 방식으로 대응할 수 있는 구조를 갖고 있다.

애플과 달리, 안드로이드는 제조사별로 운영체제 버전이 매우 다양하다. 주요 버전만 해도 15개 이상이며, 여기에 각 제조사의 커스터마이징이 더해진다. 이런 다양성은 관리 측면에서는 비효율적일 수 있지만, 특정 결함이 전체 생태계로 동시에 확산되는 위험을 낮추는 완충 장치로 작용한다.

NIST 사이버보안 프레임워크(CSF) 2.0은 ‘통제’를 핵심 요소로 전면에 내세웠지만, 소프트웨어와 보안에 대한 현장 전문성이 계속 약화된다면 이는 제대로 작동하지 못할 가능성이 높다. AI는 좋은 패턴과 나쁜 패턴을 모두 증폭시키며, 잘못된 논리를 빠르게 확산시킨다. 많은 팀이 동일한 AI 생성 구조에 의존할수록 단일화 위험은 더 커진다. 스스로 시스템을 점검하고 수리할 수 있는 능력을 잃는 순간, 품질 역시 잃게 된다.

이사회가 던져야 할 질문

이사회는 현재 프로덕션 환경에서 AI 생성 코드가 정확히 어디에서 실행되고 있으며, 그 동작에 대한 책임자는 누구인지 물어야 한다.

CISO는 이에 대해 명확하게 답할 수 있어야 한다. 모든 AI 생성 코드의 위치를 식별할 수 있고, 누가 이를 승인했는지 추적할 수 있으며, 어떤 방식으로 검토가 이뤄졌는지도 설명할 수 있어야 한다. 또한 고위험 시스템에 접근하지 못하도록 어떤 가드레일이 작동했는지도 입증할 수 있어야 한다.

이 질문에 답하지 못한다면, 그것은 거버넌스가 아닌 잘 정리된 문서에 불과하다.
dl-ciokorea@foundryco.com