kwakseongjae 한 줄. 1000줄로 할 일을 100줄로 끝낼 수 있다면, 그렇게 한다.
Why this mindset
어떻게 하면 최적의 코드량으로 아웃풋을 낼 수 있을지 고민해야 합니다. AI와 함께라면 하루에 1만 줄의 코드도 거뜬하게 작성할 수 있습니다. 하지만 너무 많은 코드량은 대부분의 경우 병목으로 작용합니다. 10만 줄이 넘어가면 AI에게도 병목이 됩니다. 1000줄의 코드로 만들어낼 수 있는 경험을 100줄의 코드로 만들어낼 수 있다면, 최대한 적은 코드로 아웃풋을 만들어내세요. 이미 있는 코드를 재활용하고, 반복되는 패턴은 모듈화하세요.
Instructions
코드를 더하기 전에 빼는 길을 먼저 본다. "쉽게 많이 쓸 수 있다"는 말이 "많이 써야 한다"는 말은 아니다.
있는 걸 먼저 본다. 새 코드를 짜기 전에 프로젝트 안에 같은 일을 하는 함수·유틸·컴포넌트·헬퍼가 이미 있는지 찾는다 (Grep, Glob). 80%만 맞아도 그쪽을 살짝 늘리는 게, 새로 만드는 것보다 거의 항상 가볍다.
반복되면 묶는다, 한 번뿐이면 안 묶는다. 같은 패턴이 3번 이상 반복되면 모듈화 후보. 하지만 1~2번 등장하는 코드를 미리 추상화하지 않는다 — 가짜 추상화는 줄 수만 늘리고 진짜 줄여주지 않는다.
줄 수 견적을 미리 말한다. 기능을 붙이기 전에 "이건 대략 N줄 정도로 끝날 거야"라고 먼저 말한다. 견적이 100줄을 넘기 시작하면 멈추고 "더 작은 길이 있는지" 한 번 더 본다. 200줄, 500줄을 넘기 시작하면 "정말 이만큼 필요한지" 사용자와 다시 짚는다.
삭제도 결과물이다. 요청이 "추가"여도, 추가하면서 기존 코드 일부를 줄일 기회가 보이면 같이 정리한다. 새로 50줄 넣고 기존 80줄을 지웠다면 그게 더 좋은 변경이다.
언어·프레임워크의 기본기를 먼저 쓴다. 직접 짜기 전에 표준 라이브러리, 프레임워크 내장 기능, 이미 설치된 의존성으로 끝낼 수 있는지 확인한다. 새 의존성을 추가하는 건 "줄 수는 줄지만 무게는 늘어나는" 거래라 신중하게.
Examples
작게 가는 흐름:
- 사용자: "유저 검색 기능 만들어줘."
- Claude: "기존에
useUsers훅이 이미 목록을 가져오고 있네. 거기에 클라이언트 측 필터 한 줄 추가하면 끝나. 새 API·새 컴포넌트 안 만들고 ~10줄 추가로 충분해."
견적 말하고 시작:
- 사용자: "결제 연동해줘."
- Claude: "이건 대략 150~250줄 사이로 보여. 핵심은 SDK 초기화·체크아웃 호출·웹훅 검증 세 군데야. 더 줄일 여지는 SDK가 제공하는 헬퍼를 그대로 쓰는 거고. 그 방향으로 갈까?"
멈추는 흐름:
- 사용자: "이 컴포넌트마다 props validation 헬퍼 만들어서 다 통일하자."
- Claude: "지금 컴포넌트가 두 개라 헬퍼를 만들면 헬퍼 정의 + 두 컴포넌트 수정으로 오히려 줄 수가 늘어나. 세 번째 컴포넌트가 등장할 때 만드는 게 어때?"
Pitfalls
- "어차피 AI가 짜주니까" 하는 무게 없는 코드 폭주
- 한 번밖에 안 쓰는 추상화 / 한 번밖에 안 쓰는 헬퍼 함수
- 기존 코드 안 보고 비슷한 걸 또 만드는 일
- "혹시 모르니까" 미리 깔아두는 옵션·플래그·설정
- 보일러플레이트가 본문보다 긴 모듈
적은 코드는 게으름이 아니다. 읽는 사람·고치는 사람·미래의 본인을 위한 배려다. 줄이는 데 든 시간만큼, 그들의 시간이 돌아온다.