Skip to content
Published on

AI가 당신의 코드를 유지보수해도, 그래도 사람을 위해 쓴다

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
공유하기
Authors

들어가며 — 에이전트 시대에 다시 쓰인 오래된 격언

"사람이 유지보수할 코드처럼 써라"는 소프트웨어에서 가장 오래된 조언 중 하나입니다. 논리는 늘 단순했습니다. 코드 한 줄은 한 번 쓰지만 수십 번 읽히므로, 쓰는 사람이 아니라 읽는 사람에게 최적화하라는 것입니다.

영리한 한 줄짜리 트릭, 아낀 키 입력, 기계 친화적인 잔재주는 모두, 다음 사람이 한눈에 이해할 수 있는 평범하고 지루하고 뻔한 코드에 집니다. 수십 년 동안 그 "다음 사람"은 두말할 것 없이 사람이었습니다.

2026년 7월 10일, Scott Robinson은 바로 그 제목으로 짧은 글을 발표했고, 이 오래된 문장을 새로운 곳으로 데려갔기 때문에 화제가 되었습니다. 그의 주장은 장인정신에 대한 흔한 향수가 아닙니다.

그 조언이, "다음 유지보수자"가 대규모 언어 모델일 때 어떻게 되는가에 관한 이야기입니다. 그리고 이제 우리 상당수가 출시하는 코드의 대부분을 에이전트에게 쓰고 고치게 맡기기 때문에, 이 질문은 감상적이기보다 절박하게 느껴집니다.

이 글이 실제로 주장하는 것

Robinson은 반어적으로 그럴듯한 자기 합리화를 먼저 꺼냅니다. "LLM의 가장 좋은 점 하나는, 온종일 당신을 위해 코드를 써 준다는 것이다. DRY 따위 누가 신경 쓰나?"

AI가 네 개의 파일에 있는 같은 긴 조건문을 알아서 갱신해 준다면, 굳이 공통 헬퍼를 뽑아낼 이유가 있을까요? 그의 표현으로는, "나중에 뭔가 바꿔야 할 때, 내가 아니라 LLM이 처리한다"는 것입니다.

그의 구체적인 예시는 라우트 핸들러, 백그라운드 잡, API 엔드포인트, 웹훅 네 곳에 모두 들어가야 하는 접근 권한 검사입니다. 하나의 공통 헬퍼를 쓰는 대신, 그는 모델이 거의 똑같은 복사본을 각 자리에 붙여 넣게 두었습니다.

if (user.isActive && user.hasPermission('read') &&
    !user.isSuspended && account.status === 'open') {
    // do a thing
}

그리고 이 글을 읽을 가치가 있게 만드는 반전이 옵니다. LLM은 홀로 동작하지 않습니다. 그것은 당신의 기존 코드를 읽고 그것을 스타일 가이드로 취급합니다. Robinson의 말로는, "당신이 코드베이스에 병합하는 모든 지름길은 여기서는 일을 이렇게 한다는 신호"입니다.

그래서 중복된 조건문은 나중에 갚을 기술 부채에 그치지 않습니다. 그것은 지금 이 순간 당신이 모델에게 먹이고 있는 학습 데이터입니다. 모델은 복사본 네 개를 보고, 중복이 이곳의 관례라고 결론 내린 뒤, 충실하게 다섯 번째와 여섯 번째를 만들어 냅니다.

냄새는 누적되고, 패턴이 한번 굳으면 되돌리기가 더 어려워집니다. 모델이 주변의 예시를 보고 그것을 계속 재생산하기 때문입니다. Robinson의 마지막 문장이 핵심을 찌릅니다. "LLM은 당신이 하는 모든 것을 빨아들여 그대로 되돌려주는 스펀지다. 그러니 좋은 것이 되게 하라."

기계가 코드를 유지보수해도 이 원칙은 유효한가

이것이 솔직한 질문이고, 제 답은 "그렇다"입니다. 다만 "깨끗한 코드는 미덕이다"보다 더 날카로운 이유에서입니다.

유지보수자가 기계뿐인 경우는 결코 없다는 사실에서 출발합시다. 누군가는 여전히 diff를 리뷰해야 하고, 이제는 리뷰가 진짜 병목입니다. 에이전트는 사람이 검토할 수 있는 속도보다 훨씬 빠르게 코드를 쏟아내기 때문입니다.

읽기 좋은 코드가 곧 리뷰하기 좋은 코드입니다. 명확한 이름과 작은 함수는, 리뷰어가 새벽 2시 장애 상황에서 영리함의 벽을 역설계하는 대신, 몇 초 만에 의도를 확인하게 해 줍니다. 읽는 사람에게 최적화하라는 말은 애초에 쓰는 사람의 편안함이 아니라 리뷰어의 편안함에 관한 것이었고, 그 리뷰어는 어디로도 사라지지 않았습니다.

그다음 Robinson 자신의 논점은 DRY보다 한 겹 더 깊이 파고듭니다. AI가 읽은 것을 그대로 반영하기 때문에, 당신의 저장소는 어느새 당신이 끊임없이 쓰고 있는 프롬프트가 되었습니다. 일관되고 잘 나뉜 코드베이스는 다음 세대의 출력을 좋은 쪽으로 이끌고, 엉망인 코드베이스는 자신의 엉망을 기계 규모로 되돌려 줍니다.

이 글을 둘러싼 논의에서 실무자들은 관련된 퇴화를 지적했습니다. 여러 번 반복하는 동안 모델의 코드 파악과 코드 자체의 간결함이 함께 무너지고, 그와 함께 출력 품질도 떨어진다는 것입니다. 실패 양상은 나쁜 함수 하나가 아니라, 모델이 당신의 나쁜 습관을 수백 개 파일에 걸쳐 증폭시키는 것입니다.

"사람을 위해 쓰라"를 게으르게 읽는 데에는 반론을 달고 싶습니다. 그것은 모든 것을 취향껏 손으로 다듬으라는 면허가 아닙니다. 같은 논의에서, 부정형 지시나 장황한 스타일 체크리스트는 오히려 에이전트의 성능을 떨어뜨릴 수 있다는 지적이 분명했습니다.

린터, 포매터, 타입 체커, 정적 분석 같은 결정론적 가드레일은 프롬프트 속 산문보다 훨씬 안정적으로 일관성을 강제합니다. "사람을 위해 쓰라"와 "도구가 강제하게 하라"는 경쟁 관계가 아니라 같은 프로젝트입니다.

여전히 값어치를 하는 습관들

고전들 중 폐기된 것은 하나도 없습니다. 오히려 에이전트 시대는 그 습관들의 수익률을 높입니다. 당신이 남겨 두는 모든 패턴이 앞으로 복제될 패턴이기 때문입니다.

  • 명확한 이름 짓기가 무엇보다 레버리지가 큰 습관입니다. 이름은 코드 블록의 압축된 의도이고, 사람 리뷰어와 모델 모두 무언가가 무엇을 하는지 처음 짐작할 때 가장 먼저 보는 단서입니다.
  • 작고 단일 목적을 가진 함수는 읽기 쉽고, 테스트하기 쉽고, 에이전트가 옆에 살짝 다른 변종을 새로 만드는 대신 재사용하기도 쉽습니다.
  • 무엇이 아니라 왜를 설명하는 주석. 코드는 이미 무엇을 하는지 말합니다. 좋은 주석은 뻔한 방법을 왜 버렸는지를 담습니다. 사람이든 기계든 문법만으로는 복원할 수 없는 맥락 말입니다.
  • 진짜 분기의 원천을 없앨 때만 DRY. Robinson의 예시가 교과서적인 좋은 사례입니다. 하나의 접근 규칙을, 한 곳에서 바꾸면, 어디서나 올바르게.
  • 지루한 일관성은 결정론적 도구에 맡기기. 도구는 지치지 않고, 따지지 않으며, 에이전트에게 맞춰야 할 명확한 목표를 줍니다.

솔직한 단서는, DRY가 공짜가 아니며 "사람을 위해 쓰라"가 기회가 있을 때마다 추상화하라는 뜻은 아니라는 점입니다. 성급한 추상화는 그 자체로 유지보수 부담이고, 서로 무관한 두 코드를 억지로 한 헬퍼에 묶는 것은 약간의 정직한 중복보다 나쁩니다.

이것이 정말 같은 규칙인지, 아니면 오늘 우연히 닮아 보이는 두 규칙인지 판단하는 일 — 그것이야말로 모델이 아니라 우리에게 남은 의도의 작업입니다. 그 판단은 어떤 스펀지도 빨아들일 수 없는, 사람을 위해 쓰는 일의 한 부분입니다.

마치며

사람이 유지보수할 코드처럼 쓰라는 조언은 AI 에이전트의 등장에도 살아남지만, 무게 중심이 옮겨 갑니다. 예전에는 몇 달 뒤 당신의 코드를 들여다보며 눈을 찌푸릴 미래의 사람에 관한 이야기였습니다.

이제는 오늘 오후 당신의 저장소를 읽으며 "여기서 정상은 이런 모습"이라고 판단하는 모델에 관한 이야기이기도 합니다. 두 독자는 같은 것에 보상합니다. 명료함, 일관된 구조, 그리고 디버거 없이도 복원할 수 있는 의도입니다.

기계는 이 격언을 은퇴시키지 않았습니다. 그저 우리가 그 말을 진심으로 지켰는지, 더 빠르고 훨씬 덜 너그러운 방식으로 확인시켜 줄 뿐입니다.

참고 자료

Discuss on Twitter • View on GitHub