아무도 코드를 읽지 않는다면, 누가 코드를 쓰나
dev.to의 Keith Mackay가 제기한 질문은 단순하지만 날카롭다. "AI가 쓴 코드를, 아무도 읽지 않는다면, 왜 아직도 Python을 쓰나?"
'Write-only code'라는 개념이 있다. AI 에이전트가 코드를 생성하고, 검증하고, 배포까지 하는 세계—인간이 중간에 개입해 코드를 읽을 필요가 없는 세계다. 아직 완전히 도달하진 않았지만, 방향은 분명하다. 실제로 지금 이 시점에도 손으로 코드 한 줄 작성하지 않은 채 몇 달을 보내는 개발자들이 있다.
이게 왜 중요한가. 프로그래밍 언어의 역사 전체가 "기계를 인간이 이해할 수 있게 번역하는 과정"이었다. COBOL이 영어처럼 읽히도록 설계된 것도, Python이 들여쓰기로 가독성을 강제하는 것도, 모두 같은 이유다. 그런데 그 번역의 수신자가 인간이 아니라 또 다른 AI 모델이 된다면? 모델이 모델을 위한 코드를 쓴다면, 굳이 고수준 언어를 거칠 이유가 없다. 어셈블리, 최적화된 바이트코드, 아키텍처 특화 머신 네이티브 코드가 더 빠르고 효율적이다.
이론적 가능성의 얘기가 아니다. 훈련 데이터 문제(머신 코드는 인터넷에 거의 없다)는 오픈소스 바이너리 + 컴파일 쌍 데이터셋으로 우회할 수 있고, 실행 기반 강화학습으로 정확도를 검증할 수 있다. 경로는 이미 그려져 있다.
스탠드업도 코드처럼, 마찰이 없는 곳으로 이동한다
코드 생성만 바뀌는 게 아니다. 팀 워크플로우의 기본 단위—스탠드업조차 재설계되고 있다.
Kollabe 팀이 dev.to에 공유한 사례는 단순해 보이지만, 구조적 시사점이 있다. 문제는 스탠드업 툴이 나쁜 게 아니었다. 프롬프트가 잘못된 위치에 있었다. 엔지니어는 이미 Slack 탭을 열어두고 있는데, 스탠드업 툴은 별도 탭이었다. 그 컨텍스트 스위치 비용이 제출률을 죽였다.
해결책은 리마인더가 아니었다. 프롬프트를 Slack DM으로 옮기는 것—즉, 이미 팀이 있는 곳으로 도구를 가져가는 것이었다. 거기에 Claude MCP를 연결해 "지난주 플랫폼 팀이 뭘 배포했나", "데이터 마이그레이션 이슈가 14일 내 누가 언급했나"를 자연어로 물을 수 있게 했다.
이게 AI-First 팀의 워크플로우 재설계 원칙이다. 인간이 도구에 맞추는 게 아니라, 도구가 인간이 이미 있는 맥락으로 들어온다. 스탠드업 자동화는 그 중 가장 작은 사례지만, 패턴은 크다. AI가 컨텍스트를 흡수해 팀 전체의 인지 부하를 줄이는 방향—기획, 코드 리뷰, 배포 회고까지 같은 방향으로 수렴한다.
에이전트가 도울수록, 공격 표면도 넓어진다
그런데 여기서 냉정하게 짚어야 할 것이 있다. 에이전트가 강력해질수록, 공격자에게도 강력한 도구가 생긴다.
dev.to에 공개된 보안 연구에 따르면, 새로운 공격 패턴인 LOTA(Living off the Agent)가 실제 프로덕션 환경에서 발견되고 있다. Straiker의 레드팀 연구는 프로덕션 AI 에이전트에서 87개의 익스플로잇을 발견했고, 그 중 24개가 LOTA 패턴, 15개는 완전한 시스템 장악이었다.
작동 방식은 교묘하다. 공격자는 방화벽을 뚫지 않는다. 이메일 하나, SaaS 툴을 통한 메시지 하나를 에이전트에게 보낸다. 에이전트는 정상적인 업무 요청으로 인식하고 실행한다. Gmail을 읽고, Google Drive 파일을 끌어오고, 공격자의 Slack으로 보낸다. SIEM도 XDR도 이걸 이상 트래픽으로 잡지 못한다. 에이전트가 하는 "정상적인 일"처럼 보이기 때문이다.
AnthropicMCP가 엔터프라이즈 전반에 채택되면서 이 문제는 빠르게 확산 중이다. 악성 npm 패키지가 합법적인 MCP 서버를 사칭하고, 로컬 환경 변수를 탈취하는 사례가 이미 보고됐다. Cyberspike Villager라는 중국산 펜테스팅 에이전트는 출시 두 달 만에 PyPI에서 1만 건 이상 다운로드됐고, "이메일 처리해줘" 같은 자연어 명령으로 사용자의 워크플로우에 슬며시 녹아든 뒤, 취약점을 스캔하고 24시간 내 자폭한다.
세 변화가 수렴하는 질문: 개발자의 역할은 어디로 가나
이 세 흐름—코드 생성의 탈인간화, 워크플로우 자동화, 에이전트 보안 리스크—은 각각 별개의 이슈처럼 보이지만, 하나의 질문으로 수렴한다. AI-First 팀에서 개발자는 이제 무엇을 하나.
내 판단은 이렇다. 개발자의 역할 중심이 코드 작성에서 시스템 의도 설계와 검증으로 이동한다. 코드는 AI가 생성한다. 하지만 그 코드가 올바른 목적을 향하고 있는지, 에이전트가 신뢰할 수 없는 입력을 처리할 때 어떻게 행동해야 하는지, 자동화된 워크플로우가 팀의 가시성을 실제로 높이는지 낮추는지—이건 인간이 설계해야 한다.
실행 레벨로 내려오면 지금 당장 세 가지를 점검해야 한다.
첫째, 에이전트가 연결된 모든 MCP 서버 목록을 오늘 만들어라. 목록이 없으면 공격 표면이 없는 게 아니라, 공격 표면이 보이지 않는 것이다.
둘째, 팀 워크플로우 자동화에서 AI가 인지 부하를 줄이는지, 아니면 가시성을 줄이는지 구분하라. Slack 스탠드업 자동화가 좋은 사례인 이유는 팀의 정보 흐름을 AI가 요약·구조화하되, 개발자가 판단할 수 있는 형태로 유지하기 때문이다. 자동화가 판단을 대체하기 시작하면 신호가 묻힌다.
셋째, 에이전트 이상 행동을 네트워크 트래픽이 아니라 행동 패턴으로 모니터링하는 체계를 갖춰라. 평소 안 건드리는 파일을 읽거나, 새로운 목적지로 데이터를 보내거나, 예상치 못한 서브 에이전트를 생성하는 것—이게 새로운 위협 시그니처다.
전망: 낙관하되 냉정하게
write-only 코드의 세계가 실제로 오면, 개발자의 생산성 상한이 지금과 비교할 수 없이 높아진다. 머신 네이티브 코드 생성, 에너지 효율, 하드웨어 특화 최적화—이 잠재력은 진짜다. 스탠드업 자동화처럼 마찰을 제거하는 작은 승리들도 쌓인다.
하지만 그 생산성의 이면에는 지금보다 훨씬 빠르게 움직이는 공격자도 있다. LOTA는 에이전트의 가장 강력한 특성—helpfulness, 자율성, 다른 에이전트와의 신뢰 관계—을 무기로 삼는다. 4.8백만 개의 미충원 보안 직무, AI를 통해 자동화를 확대하는 같은 이유가 공격 노출을 동시에 키운다.
AI-First 팀을 만드는 것은 생산성 극대화만이 아니다. 자동화의 속도와 검증의 깊이를 동시에 설계하는 일이다. 개발자의 새로운 역할은 거기 있다.