AI 록스타 개발자들의 뒷정리

• 과거 ‘록스타 개발자’가 남긴 이해하기 어려운 코드베이스 문제가 LLM 생성 코드 확산으로 팀 전체의 유지보수 부담으로 커짐
• 록스타 개발자는 새 기술, 새 패러다임, 새 아키텍처를 빠르게 도입하고 어려운 일을 빠르게 끝냈지만, 다른 사람이 이해하고 함께 작업할 수 있는 코드 작성에는 관심이 낮았음
• LLM 에이전트는 이전 작업을 기억하지 못한 채 짧은 시간에 수만 줄의 코드를 만들고, 시스템 전체와 맞는지나 이해 가능성이 좋아지는지에는 신경 쓰지 않음
• 생성 코드가 많아질수록 시스템 복잡도가 크게 커지고, 이를 이해하기 위해 다시 LLM에 의존하는 흐름이 생길 수 있음
• 오래가는 소프트웨어에는 LLM을 작은 코드 조각 생성에 제한하고, 사람이 설계를 이끌며, 문제 복잡도에 맞게 아키텍처를 단순화하는 태도가 필요함

록스타 개발자가 남긴 구조

• 록스타 개발자는 팀에 합류한 뒤 새 기술, 새 패러다임, 새 아키텍처에 대한 강한 아이디어를 제시함
• 회사 핵심 아키텍처 대부분을 다시 작성하고, 새 빌드 프로세스와 도구와 언어를 도입함
• 많은 풀 리퀘스트를 거절하며 팀원들에게 요구되는 기준을 높였고, 다른 사람들은 그 코드 이해 여부를 드러내지 못함
• 가장 어려운 작업은 록스타 개발자에게 배정됐고, 그는 다른 사람보다 빠르게 끝냄
• 다른 팀원들은 새 라이브러리를 배우고 록스타 개발자의 방식에 맞추느라 더 느리게 움직임
• 몇 년 뒤 록스타 개발자는 더 어렵고 큰 회사의 프로젝트를 원해 팀을 떠남

여파 다루기

• 남은 팀원은 록스타 개발자의 프로젝트를 넘겨받고, 코드 속에서 압도되는 상황을 겪음
• 데이터 흐름은 따라가기 어려웠고, 마치 누군가 살인을 은폐하려는 것처럼 느껴질 정도였음
• 단순한 버그 수정부터 시작했지만, 노트북에서 코드를 실행하는 데만 일주일이 걸림
• 코드 절반은 이해하지 못하는 언어로 작성됐고, 나머지 절반은 들어본 적 없는 라이브러리로 작성됨
• 코드 재작성이 필요하다고 상사에게 말했지만, 록스타 개발자가 작성한 코드라는 이유로 받아들여지지 않음
• 난잡한 코드를 헤매는 동안 구인 공고를 보며 떠나는 상상을 하게 됨

록스타 뒤 정리하기

• 여러 팀과 에이전시는 이런 록스타 개발자가 남긴 코드베이스 정리를 필요로 함
• 복잡한 코드베이스를 이해하고 구하는 과정은 엉킨 전구 줄을 다시 쓸 수 있게 푸는 일에 비유됨
• 록스타 개발자들은 코딩, 학습, 새 패러다임 사용을 좋아하며 자신의 능력 끝까지 밀어붙임
• 가능한 한 영리한 코드를 작성하려 하고, 최대한 빠르게 움직이는 데 집중함
• 다른 사람이 함께 작업할 수 있는 코드를 작성하는 일은 록스타 개발자에게 가장 낮은 우선순위가 됨

인공지능의 등장

• 최근 몇 년 동안 많은 팀은 록스타 개발자 군단에 압도되는 상황을 겪음
• 누군가 새 채팅을 시작할 때마다 팀에 록스타 개발자를 추가하는 위험이 생김
• 에이전트는 어제 한 일을 기억하지 못하고, 몇 분 만에 수만 줄의 코드를 생성함
• 에이전트는 인간적으로 불가능할 만큼 빠른 속도로 작업 완료를 추구함
• 생성된 코드가 시스템의 다른 코드와 맞는지, 시스템이 더 이해하기 쉬워지는지에는 관심을 두지 않음
• AI는 상황에 맞지 않을 수 있는 모범 사례 도구상자를 가지고 있음
• 복잡성이 이익보다 커질 때도 AI는 “벨트와 멜빵” 방식의 과도한 안전장치를 고집함
• 코드 리뷰를 요청하면 동의하기 어려운 항목이 많은 긴 개선 목록을 만들어냄
• LLM을 쓰지 않으면 영원히 뒤처질 것처럼 느끼는 사람이 많아짐
• LLM이 모든 코드를 작성하게 두는 방식은 결국 뒤처지는 결과로 이어진다고 봄

수백 명의 AI 록스타 뒤 정리하기

• 난잡한 생성 코드 더미를 정리하는 일은 록스타 개발자 한 명의 코드를 정리하는 것만큼 즐겁지 않음
• 적어도 록스타 개발자에게는 어떤 설계 의도가 있었고, 최선을 다하려는 시도가 있었음
• 바이브 코딩으로 만들어진 난잡한 코드 더미는 한 명의 인공 개발자가 작성한 것이 아님
• 여러 채팅과 여러 맥락에서 기능 하나 또는 버그 수정 하나씩 생성된 코드베이스가 됨
• 이는 수백 명의 서로 다른 록스타 개발자가 작성한 코드베이스와 비슷함
• 어떤 경우에는 기술 부채가 너무 커져 절대 갚을 수 없는 수준이 됨

오래가는 소프트웨어 만들기

• LLM을 록스타 개발자처럼 행동하지 못하게 사용하는 방법은 여러 가지가 있음
• 사람이 엔지니어링을 이끌고, LLM에는 한 번에 작은 코드 조각만 생성하도록 안내할 수 있음
• 팀원 모두가 쉽게 이해하고 작업할 수 있는 방식으로 소프트웨어가 작성되도록 확인해야 함
• LLM이 무엇을 왜 하는지 이해하지 못한 채 길을 잃었다면 속도를 늦춰야 함
• 생성하는 소프트웨어의 품질을 보장하기 위해 더 천천히 움직이는 것은 괜찮음
• 과잉 엔지니어링을 막고, 아키텍처가 문제의 복잡도와 맞을 때까지 계속 단순화해도 괜찮음
• 때로는 LLM을 도구상자에 그대로 두고 직접 코드를 작성해도 괜찮음
• 장인정신은 항상 사람의 손에 남아 있으며, 기계에 아웃소싱할 수 없는 영역임