복잡성은 적, DRY는 만능이 아니다: AI 코딩 시대에 다시 읽는 '필독 목록'

엔지니어링 리더 칼 콜론(Carl Kolon)은 팀에 좋은 글을 공유하며 이를 농담 삼아 '필독 목록(required reading)'이라 불러왔다. 그동안 사내에서만 돌던 이 목록을 공개하면서, 그는 좋은 소프트웨어를 만드는 원칙에 관한 자신의 관점을 정리했다. 흥미로운 점은 이 목록이 단순한 고전 모음이 아니라, ORM은 나쁘고 프런트엔드는 단순해야 한다는 식의 뚜렷한 주장과 함께 제시된다는 것이다. 그는 독자가 동의하지 않더라도 각 글에서 얻을 것이 있기를 바란다고 덧붙였다. 그리고 이 원칙들의 상당수는 최근 코딩 에이전트가 만들어내는 코드를 비판적으로 검토하는 근거로 다시 읽힌다.

복잡성과 중복 제거의 함정

목록에서 콜론이 신입과 경력 개발자 모두에게 단 하나만 추천한다면 고르겠다고 한 주제는 '복잡성은 나쁘다'는 명제다. 프로젝트가 지나치게 복잡해지면 어느 순간 진척이 뚝 끊기는데, 이 현상을 이해하고 최대한 늦추는 것이 핵심이라는 것이다. 그런데 실무자들이 복잡성을 줄이겠다며 흔히 택하는 방법—중복 코드를 발견하는 즉시 한곳으로 통합하는 것—이 오히려 문제가 될 수 있다고 그는 지적한다. 2014년 객체지향 코드 리팩터링 강연에서 출발한 이 논의는, 성급하게 '단일 진실 공급원(single source of truth)'을 만드는 것이 항상 옳지는 않음을 보여준다. 콜론이 특히 강조하는 대목은, 이 원리를 제대로 이해해야 무엇이든 한곳으로 모으려는 코딩 에이전트에 효과적으로 반론을 제기할 수 있다는 점이다.

비슷한 맥락에서 그는 관심사의 분리(SoC)나 코드 재사용을 위해 헬퍼 함수를 남발하는 관행과, 코드 한 단위만 봐도 동작이 분명히 드러나야 한다는 '행동의 지역성(Locality of Behavior)' 사이의 균형을 언급한다. 미래를 대비한 투기적 기능을 미리 만드는 것은 거의 언제나 나쁜 선택이라는 YAGNI 원칙, 그리고 데이터가 만족해야 할 속성을 타입에 직접 인코딩해 런타임 오류 대신 컴파일 타임 타입 오류로 잡아내라는 타입 주도 설계도 함께 소개된다.

프런트엔드는 단순하게, 상태는 HTML에

콜론이 반복해서 던지는 메시지 중 하나는 프런트엔드를 명령형이 아니라 선언형으로 작성하라는 것이다. 백엔드에서 프런트엔드로 넘어온 개발자들이 가장 흔히 저지르는 실수가, 상태와 부수 효과를 남용하며 컴퓨터에게 한 줄씩 무엇을 하라고 지시하는 방식이라고 그는 본다. 현대 React는 모든 컴포넌트를 함수로 두고 꼭 필요한 곳에서만 훅으로 상태와 부수 효과를 다루는 함수형 스타일을 지향한다. 그가 특히 오용을 지적하는 것은 useMemo와 useCallback으로, 에이전트든 사람이든 이 훅을 아무 데나 집어넣는 경향이 있어 실제로 필요한 위치를 구분하는 안목이 필요하다.

더 나아가 그는 상태를 프런트엔드 마크업이나 백엔드와 분리해 저장하기보다, 사용자에게 제공되는 HTML 자체에 상태와 허용된 동작을 담는 편이 더 합리적인 경우가 많다고 본다. 이는 REST의 본래 개념인 HATEOAS와 맞닿아 있으며, 오늘날 대다수 'REST' API가 실제로는 REST 제약을 따르지 않는다는 비판으로 이어진다. HTML을 마지못해 쓰는 낡은 마크업이 아니라 브라우저 설계의 근간으로 이해할 때 프런트엔드의 완성도가 올라간다는 것이다.

데이터베이스와 비동기, 그리고 견고함

목록에서 가장 강한 주장은 ORM 비판이다. 콜론은 스스로를 'ORM 혐오자'라 칭하며, ORM이 신규 프로젝트에서는 매혹적이지만 곧 성능 문제와 혼란을 부른다고 말한다. 그는 Postgres 확장을 다룬 OpenAI의 사례를 인용하는데, 문제가 되는 쿼리 상당수가 ORM에서 생성되므로 실제 SQL을 꼼꼼히 검토해야 한다는 지적이다. 이런 관점의 연장선에서 그는 데이터베이스가 느려지기 시작할 때를 대비해 EXPLAIN과 EXPLAIN ANALYZE 사용법을 디버거만큼 중요하게 익혀두라고 권한다. 대량 데이터 페이지네이션에서 LIMIT과 OFFSET이 뒷 페이지로 갈수록 느려지는 문제, 지도 기반 시각화를 만들 때 마주하는 PostGIS의 geography 타입 같은 실무 주제도 함께 짚는다.

비동기 프로그래밍에 대해서는, 많은 이들이 원리를 모른 채 실무에 던져져 async 함수 안에서 블로킹 호출을 하는 기초적 실수를 반복한다고 진단한다. 그는 asyncio가 내부에서 무엇을 하는지 이해하면 이런 실수를 피할 수 있으며, 동시에 일부 비동기 시스템의 한계는 실력 부족이 아니라 근본적 결함임을 아는 것도 중요하다고 본다. 인터넷에서 수집한 데이터를 파싱할 때 견고함의 원칙을 미리 알았다면 수백 시간을 아꼈을 것이라는 회고도 인상적이다. 책 목록에서는 사용자의 필요를 예측하는 것이 곧 디자인이라는 《디자인과 인간 심리》, 트랜잭션과 배치 처리를 다룬 《데이터 중심 애플리케이션 설계》, 인터프리터를 직접 구현하는 《Crafting Interpreters》, 그리고 1975년 출간되고도 AI 도구로 무장한 오늘의 개발 조직에 더 잘 들어맞는다는 《맨먼스 미신》이 꼽힌다.

이 목록의 실무적 가치는 개별 기법보다 태도에 있다. 콜론이 거의 모든 항목에서 코딩 에이전트를 언급하는 데서 드러나듯, 이 원칙들은 자동 생성된 코드를 무비판적으로 수용하지 않기 위한 판단 기준으로 기능한다. 다만 ORM 전면 배격이나 프런트엔드 상태를 HTML에 담으라는 주장은 팀 규모와 도메인에 따라 논쟁의 여지가 크며, 그 자신도 독자의 반대를 전제하고 있다는 점은 기억할 만하다. 결국 이 목록은 정답의 모음이라기보다, 복잡성과 추상화를 언제 도입하고 언제 미룰지 스스로 판단하도록 훈련시키는 재료에 가깝다.