[이승환의 AI 시그널] 코드를 읽지도, 쓰지도 않는 개발팀이 실제로 존재한다 [이승환 기자] 미국의 보안 스타트업 StrongDM은 최근 업계에서 화제가 되고 있다. 이 회사가 내건 두 가지 원칙 때문이다. "사람은 코드를 직접 쓰지 않는다." 그리고 "사람은 코드를 직접 읽지 않는다." 말만 들으면 황당하게 들릴 수 있다. 하지만 이들은 실제 고객이 쓰는 보안 소프트웨어를 이 방식으로 만들고 있다. '코드(code)'란 컴퓨터가 이해할 수 있는 언어로 쓰인 명령문이다. 스마트폰 앱이든, 기업 시스템이든, 모든 소프트웨어는 코드로 이루어져 있다. 지금까지는 이 코드를 사람이 직접 작성하고 검토하는 것이 당연한 일이었다. Django 프레임워크(웹사이트를 빠르게 만들 수 있도록 도와주는 개발 도구)의 공동 창시자이자 개발자 커뮤니티에서 영향력 있는 목소리로 통하는 사이먼 윌리슨은 이 방식을 '다크 팩토리(Dark Factory)'라고 불렀다. 불이 꺼진 공장에서 기계들이 알아서 돌아가듯, AI 에이전트들이 서로 코드를 짜고 서로 테스트하는 소프트웨어 공장이다. 여기서 '에이전트'란 사람이 일일이 지시하지 않아도 스스로 판단하고 행동하는 AI를 말한다. 사람은 그 공장의 '설계자'이지, '작업자'가 아니다. ▲  StrongDM의 운영원칙 ⓒ 이승환 가상의 직원 수백 명이 24시간 테스트를 돌린다 StrongDM이 만드는 제품은 기업 보안 솔루션이다. 쉽게 말하면, 직원이 입사하거나 퇴사할 때 Slack(사내 메신저), Jira(업무 관리 도구), Okta(로그인 보안 서비스) 같은 도구들의 접근 권한을 자동으로 부여하거나 회수하는 소프트웨어다. 권한 하나를 잘못 설정하면 바로 보안 사고로 이어질 수 있는 민감한 영역이다. 이 회사의 테스트 방식은 독특하다. 수백 명의 가상 직원을 AI로 만들어, 가짜로 구성된 사내 메신저 채널 안에서 24시간 내내 권한 요청을 쏟아내게 한다. "새 팀원 온보딩 처리해줘", "이 사람 업무 도구 접근 권한 열어줘" 같은 실제 업무 요청을 끝없이 보내는 것이다. 이 가상 직원들은 모두 AI가 만든 존재지만, 행동 방식은 실제 고객과 동일하다. "코드를 짜는 것도 AI, 그 코드를 두들겨 보는 것도 AI다. 사람은 무엇을 만들고 어떻게 시험할지를 결정한다." 실제 Slack이나 Jira 서버에 이 정도 부하를 걸면 속도 제한에 막히기 때문에, StrongDM은 이들 서비스를 흉내 내는 가짜 서버도 AI에게 만들게 했다. 공개된 연동 문서를 AI에게 주면서 "이걸 그대로 흉내 내는 가짜 Slack 서버를 만들어달라"고 시켰고, 실제로 그 결과물을 테스트 환경으로 사용하고 있다. 코드가 싸질수록, 검증은 더 중요해진다 사이먼 윌리슨은 공개 인터뷰에서 "지금 내가 만드는 코드의 90% 이상은 내가 직접 타이핑하지 않은 것"이라고 밝혔다. Claude Code, GPT 계열 등 고성능 AI 코딩 도구의 등장으로, 사람이 말로 설명만 해도 복잡한 프로그램 초안이 뚝딱 나오는 시대가 된 것이다. 그런데 이 흐름이 만들어낸 역설이 있다. 코드를 만드는 비용은 내려갔는데, 그 코드를 믿어도 되는지 확인하는 비용은 오히려 올라가고 있다는 점이다. 2026년 3월, AI 기업 엔트로픽과 브라우저 기업 Mozilla의 협업이 이를 잘 보여준다. 엔트로픽의 AI 모델 Claude가 2주 동안 Firefox(파이어폭스) 브라우저의 코드를 분석해 22건의 보안 취약점을 찾아냈다. 보안 취약점이란 해커가 파고들 수 있는 프로그램의 허점을 말한다. 숫자만 보면 인상적이다. 하지만 Mozilla가 강조한 것은 숫자가 아니었다. 엔트로픽의 보안팀과 Mozilla 엔지니어들이 AI가 찾아낸 취약점 하나하나를 직접 재현하고 검증하고 우선순위를 매기는 과정을 거쳤다는 점이 핵심이었다. AI가 찾은 것을 그대로 공개하지 않고, 사람이 책임 있게 확인한 것만 수정하고 공개했다. AI가 짜고 AI가 테스트한다면, 신뢰는 누가 만드는가 스탠퍼드 법대 산하 CodeX 연구소는 StrongDM 사례를 이렇게 요약했다. "에이전트가 만들고, 에이전트가 테스트한다면, 신뢰는 누가 책임지는가?" 사람이 직접 쓰지도 읽지도 않은 코드가 실제 서비스에 들어간다면, 뭔가 문제가 생겼을 때 책임의 주체가 누구인지 불분명해진다는 경고다. 이 질문에 대한 StrongDM의 답은 구조로 말한다. 코드를 만드는 AI와 코드를 평가하는 AI를 철저히 분리하고, 평가에 쓰이는 테스트 시나리오와 기준은 개발 AI가 볼 수 없도록 격리한다. 마치 외부 감사인이 회사 내부 보고서와는 별도로 독립된 방법으로 감사하는 구조와 닮아 있다. AI 시스템이 스스로를 속이지 못하도록 설계하는 것이다. 개발자의 일이 바뀌고 있다 윌리슨은 이 흐름을 '에이전틱 엔지니어링'이라고 부른다. 개발자의 핵심 역할이 "코드를 직접 쓰는 일"에서 "AI 에이전트를 설계하고, 조합하고, 검증하는 일"로 이동하고 있다는 뜻이다. 구체적으로 세 가지 변화가 눈에 띈다.첫째, 시제품을 만드는 비용이 거의 사라졌다. 어떤 기능이 더 좋을지 판단하기 어려울 때, 세 가지 버전을 만들어 직접 비교해보는 것이 가능해졌다. 예전에는 하나를 만드는 데도 며칠이 걸렸다면, 이제는 몇 시간 안에 여러 버전을 비교할 수 있다. 둘째, 과거의 실험들을 쌓아두는 전략이 중요해졌다. 수백 개의 작은 도구 조각들을 모아두고, 새로운 문제를 만날 때 AI가 그 조각들을 재조합해 해법을 찾게 하는 방식이다. 셋째, 테스트의 위상이 달라졌다. AI가 코드를 빠르게 만들어주다 보니 "이제 검증은 생략해도 되지 않나"라는 생각이 잠깐 퍼졌지만, StrongDM과 Mozilla 사례는 정반대의 결론을 가리킨다. 빠른 코드일수록 더 촘촘한 검증이 필요하다. AI가 코드를 만드는 시대에, 우리가 사람의 역할로 남겨둘 것은 무엇인가. StrongDM은 그 답으로 "무엇을 만들지 정의하고, 어떻게 시험할지 설계하고, 최종 승인의 책임을 지는 것"을 제시했다. Mozilla는 AI가 발견한 것을 사람이 검증하고 우선순위를 매기는 절차를 통해 신뢰를 확보했다. "어떤 AI 도구를 쓸 것인가"보다, "AI가 만든 것을 믿어도 되는 상태를 어떻게 설계할 것인가"가 더 중요한 질문이 되고 있다. 코드의 저자가 AI로 바뀌어도, 책임의 설계자는 여전히 사람이어야 한다. Copyright © 오마이뉴스. 무단전재 및 재배포 금지.