Skip to content
Published on

30배 AI 엔지니어의 조건은 속도가 아니라 취향이다

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

들어가며 — 왜 지금 이 글이 화제인가

2026년 상반기, 개발자 커뮤니티에서 가장 많이 회자된 글 중 하나는 서브스택에 올라온 "How to be a 30x AI engineer with taste"입니다. Hacker News 프론트페이지에 올랐고, GeekNews에서도 활발한 토론이 벌어졌습니다.

이 글이 특별히 화제가 된 배경에는 시점의 절묘함이 있습니다. 2026년 현재 Claude Code, Codex, Copilot 같은 AI 코딩 에이전트는 더 이상 신기한 도구가 아니라 보편적인 작업 환경이 되었습니다. 수 시간 동안 자율적으로 작업을 수행하는 frontier 모델 세대가 등장했고, OpenAI 모델과 Codex가 AWS에서도 제공되며, Microsoft는 MAI-Code-1 같은 코딩 특화 모델로 경쟁에 뛰어들었습니다.

코드를 생산하는 속도 자체는 이제 누구에게나 거의 공짜입니다. 그런데도 어떤 엔지니어는 AI 도구로 팀 전체의 성과를 끌어올리고, 어떤 엔지니어는 똑같은 도구로 기술 부채를 양산합니다. 이 차이를 만드는 것이 무엇인가에 대해, 원문 저자는 한 단어로 답합니다. 바로 취향(taste)입니다.

이 글에서는 원문의 논지를 정리하고, 취향이라는 다소 모호한 단어를 구체적인 기술과 훈련법으로 분해해 보겠습니다.

핵심 논지 — 10x에서 30x로, 그리고 숫자의 함정

먼저 원문의 핵심 주장을 요약하면 다음과 같습니다.

  1. AI는 코드 생산(production)을 커머디티화했다. 코드를 빨리 쓰는 능력의 희소성은 급격히 떨어지고 있다.
  2. 병목은 생산에서 평가(evaluation)로 이동했다. 무엇을 만들지, 만들어진 것이 좋은지 나쁜지 판단하는 능력이 새로운 희소 자원이다.
  3. 이 평가 능력의 총체가 곧 취향이며, 취향 있는 엔지니어와 없는 엔지니어의 격차는 도구가 강력해질수록 오히려 벌어진다.
  4. 따라서 30x라는 숫자는 타이핑 속도 30배가 아니라, 좋은 판단이 누적되어 만들어내는 결과물 가치의 차이를 의미한다.

10x 엔지니어 담론이 한 사람의 코딩 생산성에 대한 이야기였다면, 30x 담론은 레버리지에 대한 이야기입니다. AI 에이전트라는 거대한 지렛대가 주어졌을 때, 지렛대를 어디에 받칠지 아는 사람과 모르는 사람의 차이는 지렛대가 길어질수록 커집니다.

  과거: 생산이 병목                 현재: 평가가 병목

  아이디어 ──> [코딩: 느림] ──> 결과    아이디어 ──> [코딩: AI, 빠름] ──> 결과
                  ^                                      ^
              여기가 비쌌다                        이제 여기는 싸다
                                                         |
                                          [무엇을 만들지 / 이게 좋은지 판단]
                                                         ^
                                                  여기가 새로운 병목

물론 30x라는 숫자 자체를 너무 진지하게 받아들일 필요는 없습니다. 측정된 값이 아니라 수사적 장치에 가깝습니다. 이 점은 마지막 비판 섹션에서 다시 다루겠습니다.

코드가 커머디티가 될 때 — 무엇이 비싸지는가

경제학의 오래된 패턴이 있습니다. 어떤 재화가 커머디티화되면, 그 재화를 보완하는 것의 가치가 올라갑니다. 사진 촬영이 공짜가 되자 무엇을 찍을지 아는 눈이 비싸졌고, 글쓰기 도구가 흔해지자 무엇을 쓸지 아는 편집자적 감각이 비싸졌습니다.

코드도 같은 길을 가고 있습니다. 2026년의 개발 현장에서 실제로 비싸진 것들을 나열해 보면 다음과 같습니다.

커머디티화된 것가치가 올라간 것
보일러플레이트 작성시스템 경계 설계
API 연동 코드어떤 API를 쓸지에 대한 판단
테스트 코드 생성무엇을 테스트해야 하는지 아는 것
리팩토링 실행리팩토링할 가치가 있는지 판단
문서 초안 작성독자에게 진짜 필요한 정보 선별
프로토타입 구현프로토타입으로 검증할 가설 설계

왼쪽 열은 AI 에이전트에게 위임할 수 있는 일이고, 오른쪽 열은 위임하면 사고가 나는 일입니다. 오른쪽 열의 공통점이 바로 평가와 판단, 즉 취향의 영역입니다.

여기서 중요한 뉘앙스가 있습니다. 왼쪽을 못 해도 된다는 뜻이 아닙니다. 왼쪽을 직접 해 본 경험이 없으면 오른쪽 판단의 근거가 사라집니다. 커머디티화는 그 일을 할 줄 아는 것의 가치를 없애는 것이 아니라, 그 일을 직접 하는 시간의 가치를 없애는 것입니다.

취향의 해부 — 세 가지 구성 요소

취향이라는 단어는 멋있지만 모호합니다. 실무적으로 분해하면 적어도 세 가지 능력의 합성입니다.

1. 제품 감각 (Product Sense)

무엇을 만들어야 사용자와 비즈니스에 가치가 생기는지에 대한 직관입니다. 구체적으로는 다음 질문에 빠르고 정확하게 답하는 능력입니다.

  • 이 기능을 만들면 누가, 언제, 왜 쓰는가
  • 이 문제를 코드 없이 해결할 방법은 없는가
  • 80퍼센트 가치를 내는 20퍼센트 범위는 어디인가
  • 지금 만들지 않으면 어떤 일이 벌어지는가 (아무 일도 안 벌어진다면 만들지 않는다)

AI 에이전트는 시키는 것을 만들어 줄 뿐, 시킬 가치가 있는지는 묻지 않습니다. 제품 감각이 없는 사람이 강력한 에이전트를 쥐면, 만들 필요가 없던 것들이 엄청난 속도로 만들어집니다.

2. 코드 품질 직관 (Quality Intuition)

생성된 코드를 보고 몇 초 안에 이상한 냄새를 감지하는 능력입니다. AI가 만든 코드는 대체로 그럴듯하게 생겼기 때문에, 표면적 그럴듯함을 뚫고 보는 직관이 필요합니다. 예를 들어 다음과 같은 코드를 봤을 때를 생각해 봅시다.

def get_user_orders(user_id: int) -> list[dict]:
    orders = []
    all_orders = db.query("SELECT * FROM orders")  # 전체 테이블 로드
    for order in all_orders:
        if order["user_id"] == user_id:            # 앱 레벨 필터링
            user = db.query(
                f"SELECT * FROM users WHERE id = {order['user_id']}"
            )                                       # 루프 안 쿼리 + 인젝션
            order["user_name"] = user[0]["name"]
            orders.append(order)
    return orders

이 코드는 동작합니다. 테스트도 통과할 수 있습니다. 하지만 숙련된 눈에는 세 가지 문제가 즉시 보입니다. 전체 테이블 스캔, 루프 내부의 N+1 쿼리, 그리고 문자열 포매팅으로 인한 SQL 인젝션 가능성입니다. 취향 있는 리뷰어라면 다음과 같은 코드를 기대했을 것입니다.

def get_user_orders(user_id: int) -> list[dict]:
    return db.query(
        """
        SELECT o.*, u.name AS user_name
        FROM orders o
        JOIN users u ON u.id = o.user_id
        WHERE o.user_id = %s
        """,
        (user_id,),
    )

품질 직관은 동작 여부가 아니라 비용 구조를 봅니다. 이 코드가 데이터 100만 건에서 어떻게 되는가, 동시 요청 1000개에서 어떻게 되는가, 6개월 뒤 이 코드를 고치는 사람은 무엇에 걸려 넘어지는가를 묻습니다.

3. 트레이드오프 판단 (Tradeoff Judgment)

모든 엔지니어링 결정은 트레이드오프입니다. 취향의 세 번째 요소는 지금 이 상황에서 어떤 트레이드오프가 옳은지 아는 능력입니다.

  • 이 프로토타입에 테스트를 얼마나 써야 하는가 (정답: 거의 안 써도 됨)
  • 이 결제 모듈에 테스트를 얼마나 써야 하는가 (정답: 집요하게)
  • 추상화를 지금 도입할 것인가, 세 번째 중복이 나올 때까지 기다릴 것인가
  • 라이브러리를 쓸 것인가, 200줄짜리 직접 구현으로 의존성을 피할 것인가

AI는 베스트 프랙티스의 평균값을 출력하는 경향이 있습니다. 그러나 베스트 프랙티스는 맥락 위에서만 베스트입니다. 맥락을 쥐고 있는 것은 언제나 인간 쪽입니다.

취향을 기르는 구체적 훈련법

취향은 타고나는 것이 아니라 의도적 노출과 반복 평가로 길러지는 것입니다. 원문의 제안을 확장해 네 가지 훈련 루틴으로 정리했습니다.

훈련 1 — 좋은 코드를 정독한다

좋은 글을 많이 읽은 사람이 좋은 문장을 알아보듯, 좋은 코드를 많이 읽은 사람이 좋은 코드를 알아봅니다. 추천하는 방식은 다음과 같습니다.

  • 잘 만들어진 오픈소스 한 개를 정해서 핵심 모듈을 처음부터 끝까지 읽습니다. SQLite, Redis, Flask, Tailwind CSS 코드베이스가 자주 추천됩니다.
  • 읽으면서 왜 이렇게 했을까를 메모합니다. 이상해 보이는 결정일수록 이유가 있을 확률이 높습니다.
  • 같은 문제를 푸는 두 라이브러리의 소스를 비교합니다. 예를 들어 requests와 httpx의 커넥션 처리 방식 비교는 훌륭한 교재입니다.

주 2시간이면 충분합니다. 핵심은 양이 아니라 왜라는 질문의 밀도입니다.

훈련 2 — 리뷰를 평가 훈련으로 삼는다

코드 리뷰는 평가 능력을 기르는 가장 좋은 반복 훈련입니다. 단, 그냥 하는 리뷰가 아니라 구조화된 리뷰여야 합니다. 다음 체크리스트를 추천합니다.

리뷰 체크리스트 (우선순위 순)
1. 이 변경은 풀려는 문제를 실제로 푸는가? (제품 감각)
2. 더 작게 풀 수 있었는가? 지운 코드는 없는가?
3. 실패 경로: 이 코드는 어떻게 죽는가? 죽을 때 무슨 일이 벌어지는가?
4. 데이터 10배, 트래픽 10배에서 무엇이 부러지는가?
5. 6개월 뒤의 동료가 이 코드에서 무엇에 놀라는가?
6. 스타일/네이밍 (가장 마지막, 도구에 맡길 수 있으면 맡긴다)

AI가 생성한 PR을 리뷰할 때는 한 가지를 추가합니다. 이 코드가 그럴듯해 보이는 이유와 실제로 옳은 이유를 구분해서 적어 보는 것입니다. 이 구분 훈련이 AI 시대 리뷰의 핵심 근육입니다.

훈련 3 — 포스트모템을 교재로 쓴다

장애 포스트모템은 트레이드오프 판단을 기르는 압축 교재입니다. 잘못된 판단의 결과를 가장 생생하게 보여주기 때문입니다.

  • 자사 포스트모템을 읽을 때는 어느 시점의 어떤 결정이 이 장애의 씨앗이었나를 추적합니다.
  • 공개 포스트모템 모음(GitHub의 danluu/post-mortems 저장소가 유명합니다)에서 매주 한 편을 읽고, 내가 그 자리에 있었다면 같은 결정을 했을까를 자문합니다.
  • 장애가 아니어도 됩니다. 폐기된 프로젝트, 갈아엎은 아키텍처도 같은 가치를 갖습니다.

훈련 4 — 데모와 제품을 많이 본다

제품 감각은 좋은 제품과 나쁜 제품을 대량으로 관찰해야 길러집니다.

  • 매주 신규 제품 데모를 몇 개씩 봅니다. 해커톤 데모, 쇼케이스 영상, Product Hunt 런칭이 좋은 소스입니다.
  • 볼 때마다 세 가지를 평가합니다. 어떤 문제를 푸는가, 왜 지금인가, 내가 만든다면 무엇을 빼겠는가.
  • 특히 마지막 질문이 중요합니다. 취향의 절반은 빼는 능력입니다.

스펙 작성이 새로운 코딩이다

AI 에이전트 시대의 실질적인 프로그래밍 인터페이스는 자연어 스펙입니다. 2026년 들어 CLAUDE.md나 AGENTS.md를 작성해 에이전트에게 컨텍스트를 공급하는 것이 새로운 관행으로 자리잡았고, 프롬프트 엔지니어링이라는 말은 컨텍스트 엔지니어링과 루프 엔지니어링이라는 말로 대체되고 있습니다.

나쁜 스펙과 좋은 스펙의 차이를 봅시다.

나쁜 스펙:
"주문 취소 기능 만들어 줘"

좋은 스펙:
## 목표
사용자가 배송 시작 전 주문을 취소할 수 있다.

## 범위
- 포함: 단건 취소, 전액 환불, 취소 사유 수집(선택)
- 제외: 부분 취소, 교환, 배송 중 취소 (다음 분기)

## 불변 조건
- 환불은 멱등해야 한다. 같은 취소 요청이 두 번 와도 환불은 한 번.
- 주문 상태 전이는 PAID 에서 CANCELLED 로만 허용. SHIPPED 이후 불가.
- 취소와 환불은 하나의 트랜잭션 경계가 아니다. 환불 실패 시
  주문은 CANCEL_PENDING 상태로 두고 재시도 큐에 넣는다.

## 완료 기준
- 동시 취소 요청 테스트 통과
- 환불 API 타임아웃 시나리오 테스트 통과
- 기존 주문 조회 API 응답 스키마 변경 없음

좋은 스펙의 특징을 보면, 코드 한 줄 없이도 시스템의 어려운 결정이 전부 들어 있습니다. 멱등성, 상태 전이 규칙, 트랜잭션 경계, 실패 시 동작. 이것들이 바로 AI에게 위임할 수 없는 판단이고, 스펙 작성이 새로운 코딩이라고 말하는 이유입니다.

스펙을 잘 쓰는 능력은 곧 문제를 정확히 이해하는 능력이므로, 취향 훈련과 같은 뿌리를 공유합니다.

평가(evals)를 작성하는 능력

스펙이 입력 쪽 판단이라면, evals는 출력 쪽 판단을 코드로 고정하는 기술입니다. AI 산출물을 매번 눈으로 검사하는 대신, 좋음의 기준을 실행 가능한 형태로 작성해 두는 것입니다.

가장 단순한 형태는 익숙한 테스트와 다르지 않습니다.

# AI가 생성한 SQL 마이그레이션을 검증하는 간단한 eval
def eval_migration(migration_sql: str) -> list[str]:
    violations = []
    lowered = migration_sql.lower()

    if "drop table" in lowered or "drop column" in lowered:
        violations.append("파괴적 변경 포함 - 수동 승인 필요")
    if "alter table" in lowered and "concurrently" not in lowered:
        if "create index" in lowered:
            violations.append("인덱스 생성 시 CONCURRENTLY 누락 - 락 위험")
    if "not null" in lowered and "default" not in lowered:
        violations.append("기본값 없는 NOT NULL 추가 - 기존 행에서 실패 가능")

    return violations

LLM 산출물 자체를 채점하는 eval은 보통 채점 기준(rubric)과 채점기를 분리합니다.

RUBRIC = """
생성된 API 에러 메시지를 1-5점으로 채점하라.
5점: 원인, 해결 방법, 문서 링크가 모두 있고 내부 정보 노출 없음
3점: 원인은 있으나 해결 방법이 모호함
1점: 스택트레이스 노출 또는 의미 없는 메시지
"""

def eval_error_messages(samples: list[str]) -> float:
    scores = [grade_with_llm(RUBRIC, s) for s in samples]
    return sum(scores) / len(scores)

여기서 흥미로운 순환이 생깁니다. 채점 기준을 쓰려면 좋은 에러 메시지란 무엇인가에 대한 견해가 있어야 합니다. 즉 evals 작성 능력은 취향을 명문화하는 능력이고, 취향이 없으면 evals도 쓸 수 없습니다. 원문이 평가 능력을 새로운 핵심 역량으로 꼽는 이유가 여기에 있습니다.

주니어 개발자에게 — 기본기와 도구 활용의 균형

이 담론에서 가장 곤란한 위치에 있는 것은 주니어입니다. 취향은 경험에서 나오는데, 경험을 쌓을 기회였던 단순 작업을 AI가 가져가고 있기 때문입니다.

제 생각에 균형점은 다음과 같습니다.

시기AI에게 맡길 것직접 할 것
1-2년차환경 설정, 반복 보일러플레이트디버깅 전 과정, 코드 정독, 작은 기능의 처음부터 끝까지
3-5년차초안 생성, 테스트 스캐폴딩설계 결정, 리뷰, 장애 대응 주도
6년차 이상구현 대부분스펙, 아키텍처, evals, 멘토링

주니어 시기에 특히 권하는 원칙이 두 가지 있습니다.

  1. 디버깅만은 직접 합니다. 디버깅은 시스템의 실제 동작을 배우는 거의 유일한 강제 장치입니다. AI에게 고쳐 달라고 하기 전에, 최소한 가설을 세우고 검증하는 과정까지는 스스로 합니다.
  2. AI 산출물을 읽지 않고 머지하지 않습니다. 한 줄 한 줄 설명할 수 있을 때만 머지합니다. 설명할 수 없는 코드를 머지하는 습관은 취향이 자랄 토양 자체를 없앱니다.

기본기를 건너뛰고 도구 활용만 배운 주니어는, 도구가 틀렸을 때 틀렸다는 사실조차 알 수 없게 됩니다. 반대로 도구를 거부하는 주니어는 도구를 전제로 재편된 팀의 작업 흐름에서 고립됩니다. 둘 다 피해야 합니다.

안티패턴 — 이렇게 되지 말 것

안티패턴 1: 도구 수집가

새 AI 도구가 나올 때마다 갈아타며, 도구 비교에는 해박하지만 정작 깊이 있는 결과물이 없는 유형입니다. 도구 전환 비용은 생각보다 크고, 취향은 한 도구를 깊게 쓰며 한계까지 밀어붙일 때 길러집니다. 도구 변경은 분기에 한 번 정도 의식적으로 평가해서 결정하는 것으로 충분합니다.

안티패턴 2: 무비판 수용자

AI가 내놓은 첫 답을 그대로 쓰는 유형입니다. 단기적으로는 빠르지만, 두 가지 복리 비용이 쌓입니다. 첫째, 코드베이스에 평균적인 코드가 누적되어 시스템의 일관성이 무너집니다. 둘째, 본인의 평가 근육이 퇴화합니다. AI 출력에 대해 최소 한 번은 다른 방법은 없었나를 묻는 습관이 방어선입니다.

안티패턴 3: 취향 과시자

모든 PR에 주관적 스타일 지적을 쏟아내며 취향을 권력으로 쓰는 유형입니다. 진짜 취향은 중요한 것과 중요하지 않은 것을 구분하는 데서 드러납니다. 네이밍 논쟁에 30분을 쓰면서 트랜잭션 경계 문제를 놓치는 리뷰는 취향이 아니라 소음입니다.

비판적 시각 — 취향 담론의 한계

이 글의 논지에 공감하더라도, 몇 가지 한계는 짚어야 공정합니다.

첫째, 측정 불가능성입니다. 취향은 정의상 정량화가 어렵습니다. 측정할 수 없는 역량이 핵심 역량이라는 주장은 반증도 불가능하며, 채용과 평가에서 그럴듯한 사람이 취향 있는 사람으로 둔갑하는 통로가 될 수 있습니다.

둘째, 생존자 편향입니다. 취향으로 성공했다는 서사는 대부분 사후 해석입니다. 같은 취향으로 실패한 사람들은 글을 쓰지 않습니다.

셋째, 30x라는 숫자의 마케팅성입니다. 10x 담론이 그랬듯 30x도 측정된 값이 아니라 주목을 끌기 위한 수사입니다. HN 댓글란에서도 이 숫자에 대한 냉소가 가장 많은 추천을 받았습니다. 숫자는 버리고 방향만 취하는 것이 건강한 독해입니다.

넷째, 취향에도 유통기한이 있습니다. 평가 능력 역시 학습 가능한 패턴이라면, 장기적으로는 AI가 평가까지 잘하게 될 가능성을 배제할 수 없습니다. 실제로 evals 자동 생성 연구는 빠르게 발전하고 있습니다. 취향이 영원한 해자라는 보장은 어디에도 없습니다.

그럼에도 불구하고, 적어도 지금 시점에서 평가 능력이 생산 능력보다 희소해졌다는 관찰 자체는 현장 감각과 일치합니다. 한계를 인지한 채로 방향을 취하면 됩니다.

사례 연구 — 같은 도구, 다른 결과

추상적인 이야기를 구체화하기 위해, 같은 과제를 받은 두 명의 가상 엔지니어를 비교해 봅시다. 과제는 사내 어드민에 CSV 내보내기 기능 추가입니다. 둘 다 동일한 AI 코딩 에이전트를 사용합니다.

엔지니어 A (속도 중심)                  엔지니어 B (취향 중심)

09:00 에이전트에게 "CSV 내보내기      09:00 요구사항 확인: 누가 쓰나?
      만들어줘" 지시                        -> 정산팀, 월 1회, 최대 50만 행
09:20 생성된 코드 확인, 동작함        09:20 판단: 50만 행이면 동기 응답 불가
09:30 머지, 완료 보고                       스트리밍 또는 비동기 잡 필요
                                      09:40 한 페이지 스펙 작성
  -- 2주 후 --                              (인코딩, 구분자, 개인정보 컬럼
                                             마스킹, 타임아웃 정책 포함)
정산팀이 45만 행 내보내기 실행       10:00 에이전트에게 스펙 전달, 구현 위임
-> 요청 타임아웃, 메모리 스파이크    10:40 생성 코드 리뷰: 스트리밍 확인,
-> 장애 티켓, 핫픽스, 신뢰 하락             마스킹 누락 발견 -> 수정 지시
                                      11:30 머지, 완료
총 소요: 30분 + 장애 대응 2일
                                      총 소요: 2시간 30분, 장애 없음

엔지니어 A가 게을렀던 것이 아닙니다. A는 도구를 빠르게 썼고, 결과물은 데모 환경에서 완벽하게 동작했습니다. 차이는 단 하나, 누가 어떤 데이터로 쓰는가라는 질문을 먼저 던졌는지 여부입니다. 이것이 제품 감각이고, 50만 행이라는 답을 듣고 동기 응답은 안 된다고 판단한 것이 품질 직관이며, 완벽한 비동기 파이프라인 대신 스트리밍으로 충분하다고 선을 그은 것이 트레이드오프 판단입니다.

주목할 점은 B의 우위가 코딩 실력에서 나오지 않았다는 것입니다. 코딩은 둘 다 에이전트가 했습니다. 격차는 전부 코드 바깥에서 만들어졌습니다.

팀에 취향을 이식하기 — 개인기를 시스템으로

취향이 개인의 머릿속에만 있으면 그 사람이 휴가를 가는 순간 팀의 품질이 떨어집니다. 시니어의 역할은 자신의 취향을 팀의 시스템으로 옮기는 것입니다. 2026년 현재 효과가 검증된 방법은 세 가지입니다.

첫째, 에이전트 컨텍스트 파일에 취향을 인코딩합니다. CLAUDE.md나 AGENTS.md는 단순한 설정 파일이 아니라 팀의 취향을 모델에게 주입하는 통로입니다.

# CLAUDE.md 예시 (팀 취향의 명문화)

## 우리 팀의 코드 규칙
- 새 추상화는 동일 패턴이 3회 반복된 후에만 도입한다
- 모든 외부 API 호출에는 타임아웃과 재시도 정책을 명시한다
- 에러 메시지에는 원인과 다음 행동을 반드시 포함한다
- 마이그레이션에서 파괴적 변경은 별도 PR로 분리한다

## 하지 말 것
- 사용처가 하나뿐인 유틸 함수 만들기
- 테스트를 위한 테스트 (커버리지 숫자 목적의 의미 없는 테스트)
- 주석으로 코드 설명하기 (코드를 읽기 쉽게 고칠 것)

둘째, 리뷰 코멘트를 재사용 가능한 형태로 축적합니다. 같은 지적을 세 번 했다면 그것은 린트 규칙, eval, 또는 컨텍스트 파일의 한 줄이 되어야 합니다. 지적의 자동화율이 곧 시니어의 레버리지입니다.

셋째, 결정 기록(ADR)을 가볍게 운영합니다. 무엇을 만들지 말지 결정한 이유, 기술 선택에서 기각된 대안을 다섯 줄이라도 남깁니다. 취향의 절반은 기각의 기록이기 때문입니다.

12주 취향 훈련 커리큘럼

훈련법을 시간표로 묶으면 다음과 같습니다. 주당 투자 시간은 3시간 이내로 설계했습니다.

주차집중 영역구체적 활동
1-2주품질 직관오픈소스 핵심 모듈 정독, 결정 이유 메모 10개
3-4주평가 훈련체크리스트 기반 리뷰 4건, 그럴듯함과 옳음 구분 메모
5-6주실패 학습공개 포스트모템 4편 분석, 결정 분기점 추적
7-8주제품 감각데모 12개 시청, 무엇을 빼겠는가 메모
9-10주스펙 작성실제 업무 2건을 스펙 먼저 작성 후 에이전트에 위임
11-12주evals반복 작업 2개에 대한 eval 스크립트 작성, 팀 공유

12주 후에는 1주차로 돌아가는 것이 아니라, 각 영역에서 가장 효과가 컸던 활동만 남겨 개인 루틴으로 압축합니다. 핵심은 모든 활동에 산출물(메모, 스크립트, 스펙)이 있다는 점입니다. 산출물 없는 훈련은 측정도 회고도 불가능합니다.

실무 적용 — 이번 주에 시작할 수 있는 것

거창한 계획 대신, 바로 시작할 수 있는 작은 루틴을 제안합니다.

  1. 이번 주 리뷰 하나를 위의 체크리스트로 수행하고, 항목별로 한 줄씩 적어 봅니다.
  2. AI에게 시킨 작업 하나를 골라, 머지 전에 다르게 풀 방법 하나를 의무적으로 떠올려 봅니다.
  3. 공개 포스트모템 한 편을 읽고 결정의 분기점을 찾아 메모합니다.
  4. 자주 시키는 작업 하나에 대해 5줄짜리 eval 스크립트를 작성합니다.
  5. 다음 기능 요청을 받으면, 코드를 만들기 전에 위 형식의 한 페이지 스펙을 먼저 씁니다.

이 다섯 가지는 모두 합쳐 주당 3시간이 안 됩니다. 그러나 1년 누적되면, 같은 도구를 쓰는 동료와의 차이는 도구가 만들어 주지 않습니다.

자주 나오는 질문

Q. 취향과 그냥 고집은 어떻게 구분하나요?

근거의 갱신 가능성으로 구분합니다. 취향은 새로운 증거(벤치마크, 장애, 사용자 반응) 앞에서 갱신되는 판단이고, 고집은 증거와 무관하게 유지되는 선호입니다. 자신의 판단이 마지막으로 바뀐 것이 언제인지 떠올려 보면 됩니다. 기억나지 않는다면 위험 신호입니다.

Q. 취향을 면접에서 어떻게 보여주나요?

말로 주장하는 대신 산출물로 보여줍니다. 리뷰 코멘트 모음, 직접 작성한 스펙, eval 스크립트, 기각한 설계와 그 이유를 적은 ADR이 가장 강력한 증거입니다. 12주 커리큘럼의 산출물이 그대로 포트폴리오가 되도록 설계한 이유이기도 합니다.

Q. 팀 전체의 취향이 나쁜 방향으로 굳어 있으면요?

컨텍스트 파일과 evals는 양날의 검입니다. 나쁜 기준도 똑같이 자동화되어 증폭됩니다. 그래서 기준 문서에는 반드시 갱신 절차(분기 리뷰, 이의 제기 경로)를 함께 넣어야 합니다. 취향의 명문화는 한 번의 작업이 아니라 운영입니다.

마치며

AI 코딩 도구의 시대에 개발자의 가치가 사라진다는 불안과, 도구만 잘 쓰면 슈퍼 개발자가 된다는 낙관은 둘 다 절반만 맞습니다. 도구는 생산을 민주화했지만, 그 결과 판단의 가치를 극적으로 끌어올렸습니다.

취향은 신비로운 재능이 아닙니다. 좋은 코드를 읽고, 구조화된 리뷰를 하고, 실패 사례를 분석하고, 많은 제품을 평가해 본 시간의 누적입니다. 그리고 그 취향은 스펙과 evals라는 형태로 명문화될 때 팀의 자산이 됩니다.

속도는 이제 모두에게 주어졌습니다. 남은 질문은 하나입니다. 그 속도로 어디에 갈 것인가. 그 답을 가진 사람이 30x라고 불리게 될 것입니다.

참고 자료

Discuss on Twitter • View on GitHub