AI가 만든 ‘록스타 개발자’ 코드, 누가 치울 건데?

예전에도 팀을 힘들게 하는 ‘록스타 개발자’는 있었음

• 새 기술, 새 패러다임, 새 아키텍처를 밀어붙이고 회사 핵심 구조를 갈아엎는 타입
• 어려운 일은 다 그 사람한테 가고, 결과물은 빠르게 나오지만 정작 팀원들은 코드를 이해하지 못함
• 문제는 그 사람이 떠난 뒤 시작됨. 간단한 버그 하나 고치려는데 로컬에서 실행하는 데만 일주일이 걸리는 식임

글쓴이가 말하는 록스타 코드의 본질은 ‘똑똑하지만 같이 일하기 어려운 코드’임

• 절반은 팀이 모르는 언어로 쓰여 있고, 나머지 절반은 처음 보는 라이브러리로 굴러감
• 데이터 흐름은 따라가기 어렵고, 아키텍처는 멋져 보이지만 실제 유지보수자는 길을 잃음
• 상사에게 “이거 다시 써야 할 것 같다”고 말해도, 록스타가 만든 코드라는 이유로 설득이 안 됨. 이거 꽤 익숙한 장면임

글쓴이는 이 패턴이 이제 AI 코딩으로 대량 재생산되고 있다고 봄

• 예전엔 록스타 개발자 한 명이 몇 년 동안 남기던 혼란이 있었음
• 지금은 누군가 새 AI 채팅을 열 때마다 비슷한 리스크가 팀에 추가됨
• AI 에이전트는 어제 뭘 했는지 기억하지 못하고, 몇 분 만에 수만 줄의 코드를 기분 좋게 뽑아냄

LLM은 빠르지만, ‘이 코드가 팀의 기존 시스템과 잘 맞는가’에는 관심이 없음

• 모범 사례처럼 보이는 패턴을 들고 오지만, 그게 지금 코드베이스에 맞는지는 별개 문제임
• 필요 이상으로 방어적인 구조를 만들고, 단순한 문제에 복잡한 장치를 붙이는 경우도 생김
• 코드 리뷰를 시키면 긴 개선 목록을 뽑아내지만, 그중 상당수는 팀의 맥락과 맞지 않을 수 있음

글쓴이가 특히 걱정하는 건 ‘AI 록스타 수백 명이 만든 코드베이스’임

• 인간 록스타 개발자는 그래도 자기 머릿속에 어떤 설계 의도는 있었음
• 반면 vibe coding으로 쌓인 코드는 여러 채팅, 여러 컨텍스트, 여러 순간의 지시가 조각조각 만든 결과물임
• 기능 하나, 버그픽스 하나마다 다른 개발자가 작성한 것처럼 결이 달라질 수 있음

그래서 AI 코딩의 해법은 ‘안 쓰기’가 아니라 ‘주도권을 사람이 잡기’에 가까움

• LLM에게 전체 설계를 맡기기보다, 사람이 엔지니어링 방향을 정하고 작은 코드 조각 단위로 생성하게 해야 함
• 팀원 모두가 이해하고 수정할 수 있는 구조인지 계속 확인해야 함
• AI가 뭘 하는지 이해가 안 되는 순간엔 속도를 늦춰야 함. 그건 뒤처지는 게 아니라 품질 관리임

결론은 꽤 현실적임. 장인정신까지 외주 줄 수는 없음

• LLM은 도구함에 들어 있는 강력한 도구일 뿐, 팀의 아키텍트가 되면 곤란함
• 문제 복잡도에 맞게 구조를 단순화하고, 과한 엔지니어링을 걷어내는 판단은 여전히 사람 몫임
• 가끔은 LLM을 내려놓고 직접 코드를 쓰는 게 더 빠르고 더 건강한 선택일 수 있음