취향(taste)을 갖춘 30배 AI 엔지니어가 되는 법

• AI가 코드를 대량 생성하는 시대에 엔지니어의 가치를 가르는 핵심 역량은 속도·지식·경력이 아니라 ‘취향(taste)’, 즉 무엇을 만들지 판단하는 평가 능력
• OpenAI Codex 팀 구성원들이 독립적으로 같은 결론에 도달했으며, 좋은 소프트웨어 취향을 가진 사람이 있으면 누구나 10배 엔지니어가 될 수 있음
• 취향은 인식(recognition)·나침반(compass)·비전(vision) 세 형태로 나뉘며, 모두 내부 평가 함수의 품질이라는 하나의 메커니즘으로 수렴
• 가치는 문제 선택, 시스템 아키텍처, 품질 판단, 사용자 공감, 커뮤니케이션 다섯 영역에서 집중적으로 발생
• 코드 작성이 상품화된 지금, 판단과 사고가 본래의 진짜 역량이며 이를 의도적으로 길러야 함

---

세계는 변했지만 대부분의 엔지니어는 알아채지 못함

• Anthropic CEO Dario Amodei가 2025년 3월 AI가 수개월 내 코드의 90%를 작성할 것이라 예측, 당시엔 터무니없게 들림
• Claude Code 제작자 Boris Cherny는 12월 자신이 커밋한 코드의 100%가 AI 작성이었으며 IDE를 한 번도 열지 않았다고 보고
• AI 코딩 도구를 “slop”이라 불렀던 Andrej Karpathy가 12월 입장을 완전히 뒤집음
  • “프로그래머로서 이렇게 뒤처졌다고 느낀 적이 없으며, 직업이 극적으로 재편되고 있음”
  • Ruby on Rails 제작자 DHH는 저항이 “모델이 충분히 좋지 않았기” 때문이었고 이제 상황이 뒤집혔다고 인정
  • Vercel CTO Malte Ubl은 “소프트웨어 생산 비용이 0으로 수렴 중”이라고 언급
• 2025년 11~12월 사이 Opus 4.5, GPT-5.2, Gemini 3가 보이지 않는 역량 경계를 넘으며, 광범위한 작업에서 AI 코드가 숙련 엔지니어 수준에 도달, 소요 시간은 몇 시간에서 몇 분으로 단축
• 코드 생성이 상품화되면 남는 것은 소프트웨어 엔지니어링(문제 분해, 무엇을 만들지 결정, 테스트·신뢰성·확장 설계, 트레이드오프 판단), 곧 취향

취향이란 실제로 무엇인가

• 최고의 엔지니어링 팀이 말하는 취향에는 세 가지 정의가 존재하며, 같은 능력을 다른 각도에서 본 것

• 인식(Recognition)으로서의 취향

  • 두 구현을 보고 왜인지 설명하기 전에 어느 쪽이 더 나은지 느끼는 능력
  • Emma Tang: 시스템이 정말 깔끔하고 확장 가능하며 중복이 없는지, 이해하기 단순한지가 취향의 문제
  • 소스를 맛본 셰프가 산미가 빠졌음을 의식적으로 식별하기 전에 아는 것처럼, 패턴 매칭이 의식적 추론보다 빠르게 작동
  • Codex 팀이 CLI를 TypeScript 대신 Rust로 선택한 사례
    • 둘 다 작동하지만, Rust의 제약(강타입, 명시적 메모리 관리, 최소 의존성)이 기술적 장점을 넘어 엔지니어링 문화 효과를 만든다고 인식
    • “기술적으로 우월한 언어”가 아니라 “팀에서 원하는 행동을 형성하는 언어”라는 판단
  • 나쁜 취향: 유행이라서, 블로그가 빠르다 해서 2차 효과 이해 없이 Rust를 고르는 것

• 나침반(Compass)으로서의 취향

  • Tibo가 말한 엔지니어가 “자기만의 나침반”을 가져야 한다는 형태로, 이미 존재하는 것을 평가하는 게 아니라 다음에 무엇을 만들지 아는 능력
  • 코드 한 줄 작성 전에 “이건 옳은 기능이 아니다”라고 말하는 엔지니어
  • Boris Cherny가 Claude Code의 todo 리스트 기능을 이틀간 약 20개 프로토타입으로 제작한 사례
    • 인라인 todo, 드로어 UI, 인터랙티브 pill, 화면 하단 표시 등을 시도하며 임의적이지 않고 필연적으로 느껴지는 형태로 수렴
    • 사후엔 왜 최종안이 더 나은지 설명할 수 있었지만, 중간안에 대한 초기의 불만족 자체가 나침반으로 작동한 취향
  • 나침반 취향은 실행보다 상류에서 작동하기에 인식 취향보다 희소

• 비전(Vision)으로서의 취향

  • SQ Mah의 “인간이 진화를 정의한다”는 말로 표현되며, 지금 좋은 것이 아니라 2년 뒤 중요해질 것을 아는 가장 어려운 형태
  • OpenClaw 제작자 Peter Steinberger는 5~10개 에이전트를 동시에 돌리며 대부분의 시간을 아키텍처·시스템 설계에 투입
    • “대부분의 코드는 지루한 데이터 변환이며, 에너지는 시스템 설계에 집중”하라고 언급
  • Codex 팀의 다음 우선순위는 풍부한 맥락 기반 계획 수립으로, 비즈니스 목표·시장 역학·팀 우선순위 등 코드베이스 밖 정보가 필요
    • 더 나은 코드 생성기가 아니라, 모델이 소프트웨어가 왜 존재하는지 이해하는 미래를 향한 제품 전략에 적용된 비전 취향

• 통합 정의

  • 세 형태 모두 하나의 메커니즘으로 수렴, 취향은 내부 평가 함수의 품질
  • 인식은 완성된 산출물에, 나침반은 가능성·방향에, 비전은 미래·궤적에 평가 함수가 작동
  • AI가 코드를 생성하는 세계에서 인간의 일은 평가(무엇을 만들지 결정, 산출물이 충분한지 판단, 아키텍처 변경 시점 감지)이며, 평가가 곧 직무

왜 어떤 엔지니어는 훨씬 더 많이 버는가

• AI 이전 보상 격차는 회사·연차·전문 분야 세 가지로 설명됐으나, AI가 이 세 변수를 모두 뒤섞는 중
• 스타트업의 뛰어난 엔지니어와 평범한 엔지니어의 격차가 3배에서 10배로 벌어짐, 뛰어난 쪽이 AI로 소규모 팀의 산출을 내기 때문
• 연차의 축이 이동, 코드 작성 경력보다 좋은 판단 경력이 중요
  • “React를 안다”는 가치가 줄고, “부하 상황에서 신뢰성 있는 시스템을 설계할 수 있다”는 가치가 상승
• 격차가 큰 엔지니어의 공통점은 복리로 누적되는 결정을 내린다는 것
  • 좋은 아키텍처 결정 하나가 1년간 수개월의 작업을 절약
  • 좋은 제품 결정 하나가 기능의 실제 채택 여부를 가름
• 더 열심히 일해도 취향이 나은 사람보다 절반의 가치를 낼 수 있음, 8개 에이전트를 잘못된 문제에 돌리는 것보다 2개를 정확한 문제에 돌리는 쪽이 더 많은 가치 생산
• OpenAI 사례에서 가장 생산적인 엔지니어들은 코드를 더 많이 생성한 게 아니라 사용자와의 대화, 제품 방향, 공감에 시간을 더 쓰며 초점을 바꿈
  • 일부는 “코드베이스 감각을 잃는다”며 탭 자동완성으로 돌아갔고, 두 반응 모두 유효

가치가 실제로 생성되는 곳

• 취향이 불균형적 가치를 만드는 다섯 영역이 존재, 대부분의 엔지니어는 한두 영역에서만 경쟁

• Zone 1: 문제 선택

  • 무엇을 할지 고르는 가장 레버리지 높은 취향 결정이나 대부분 거의 생각하지 않음
  • 취향 있는 엔지니어는 “이것을 잘 풀면 다른 다섯 문제가 사라지는가”를 질문
  • Peter Steinberger는 에이전트와 오래 주고받으며 계획을 다듬고 도전·반박, 만족할 때만 에이전트 실행, 계획이 곧 작업이고 실행은 위임
  • Claude Code 권한 시스템에서 복잡한 RBAC·세분화 정책 대신 가장 단순한 접근(권한 요청 후 답 기억)을 선택해 빠르고 직관적으로 출시

• Zone 2: 시스템 아키텍처

  • 조각들이 맞물리는 방식으로, 취향의 반감기가 가장 긴 영역, 좋은 결정은 2년 뒤에도 배당, 나쁜 결정은 재작성을 요구하는 기술 부채로 누적
  • Codex의 에이전트 루프를 상태 머신으로 만든 결정, Claude Code의 “가능한 한 비즈니스 로직을 적게” 작성하는 결정, OpenClaw의 모듈식 확장성 집착이 모두 아키텍처 취향 결정
  • Boris Cherny: “새 모델이 나올 때마다 코드를 잔뜩 삭제하며, 모델 주위에 가능한 한 적은 코드를 둔다”
    • 대부분 팀은 릴리스마다 코드를 추가하지만 Claude Code 팀은 제거, 모델이 곧 제품이고 주변은 최대한 얇아야 함

• Zone 3: 품질 판단

  • 출시하기에 충분한지, 더 작업이 필요한지 아는 것으로, AI가 도울 수 없는 영역(특정 맥락의 “충분함”을 모르기 때문)
  • Codex의 계층적 코드 리뷰: 비핵심 코드는 AI 리뷰만, 핵심 에이전트 코드는 인간 리뷰 필수
    • 취향은 어느 코드가 중요한지 아는 데 있음, 권한 시스템엔 인간의 눈이 필요하고 README 갱신엔 불필요
  • Codex 팀은 거의 모든 코드를 프롬프트로 작성하나 사내 다른 부서는 약 70% 수준, 손으로 쓰는 30%는 품질 판단이 가장 중요한 부분(“30/70 규칙”)

• Zone 4: 사용자 공감

  • 상대편 인간이 실제로 무엇을 필요로 하는지 이해하는, AI가 가장 약한 영역
  • Boris가 만든 Claude Code의 맥락형 로딩 메시지(단순 회전 대신 모델이 무엇을 하는지 표시)는 아무도 요청하지 않았으나 정보 없는 대기와 있는 대기의 차이를 위해 제작
  • Codex의 샌드박스 기본값도 사용자 공감 결정, Tibo: “채택률에 손해를 보더라도 기본적으로 안전하지 않을 수 있는 것을 권하지 않는다”
    • 많은 사용자가 “그리 기술적이지 않고” 되돌릴 수 없는 일을 실수로 할 수 있음을 이해, 편의보다 안전을 선택

• Zone 5: 커뮤니케이션과 스토리텔링

  • 만든 것을 어떻게 프레이밍하는가로, 엔지니어가 일관되게 과소평가하지만 시장이 보상하는 영역
  • Peter Steinberger의 OpenClaw는 바이럴 주간에 Claude Code와 Codex를 합친 것보다 많은 Google 검색을 기록
    • 명확한 이름, 설득력 있는 데모, “한 사람이 팀 규모의 산출을 만든다”는 서사가 확산을 견인
  • Codex의 AGENTS.md 파일(인간이 아닌 AI 에이전트용 README)은 문서의 독자가 바뀌었음을 인식하고 형식을 적응시킨 커뮤니케이션 취향

취향의 사례 (그리고 부재)

• 기술 스택 선택

  • 취향 없음: “가장 인기 있고 다들 아니까 TypeScript”, 관습으로 정당화
  • 취향 있음: Boris는 Claude 모델에 “on distribution”(모델이 이미 잘 다룸)이라 TypeScript 선택, 팀의 편안함이 아닌 모델 강점에 최적화
    • Codex는 “설정한 엔지니어링 기준을 생각하게 만들고” 직접 살펴볼 수 있는 최소 의존성을 원해 Rust 선택, 같은 결정이지만 둘 다 일반 선호가 아닌 구체적 제약에 근거

• 완전히 이해하지 못한 코드 다루기

  • 취향 없음: “AI로 생성했고 테스트를 통과하니 출시”, 테스트 충분성·유지보수성 무고려
  • 취향 있음: Peter는 읽지 않은 코드를 출시하되 부주의하지 않음, “컴포넌트 위치와 구조, 전체 시스템 설계를 알며 보통 그것으로 충분”
    • 테스트·린팅·로컬 CI가 검증 계층, 한쪽은 도박이고 다른 쪽은 구조적으로 정확성이 보장되는 시스템

• 기능 요청 대응

  • 취향 없음: 티켓대로 구현하고 출시 후 다음으로
  • 취향 있음: Boris는 출시 전 이틀간 20개 프로토타입 제작, 느린 게 아니라 빠른 실험으로 옳은 해법으로 항해, 필연성이 취향의 지문

• AI 에이전트를 위한 설계

  • 취향 없음: 설정 안내와 API 엔드포인트가 있는 일반 README
  • 취향 있음: Codex는 AI에게 코드베이스 탐색법·테스트 명령·표준 준수법을 알려주는 AGENTS.md 작성, 모델이 성공하도록 필연적으로 코드베이스 구조화

• PR 폭주 대응

  • 취향 없음: AI 생성 PR이 쏟아지는데 동일 리뷰 프로세스 유지, 리뷰어 과부하, 품질 저하
  • 취향 있음: Emma Tang 팀은 PR에 프롬프트 첨부를 요구, 없으면 Slack으로 “프롬프트가 뭐냐” 질문
    • AI 세계에선 코드보다 의도 리뷰가 유익, Peter는 PR을 “prompt requests”라 부르며 코드보다 생성 프롬프트에 더 관심, 생성 단위가 바뀌어 리뷰 단위도 변경

취향을 기르는 계획 (감상이 아닌)

• “경험을 더 쌓아라”는 조언은 “운동을 더 해라”처럼 무용, 아래는 세 형태별 90일 계획

• 1개월차: 구조화된 노출로 인식 취향 구축

  • 메커니즘은 다양한 편차에 대한 대량 노출 후 의도적 성찰
  • 1~2주차: 존경하는 개발자 도구 10개 연구
    • Codex CLI, Claude Code, Linear, Supabase, Stripe 대시보드, Vercel, Tailwind, Railway, Resend 및 소프트웨어가 아닌 제품 1개(잘 설계된 박물관 전시나 식당 메뉴) 설치
    • 각 15분간 작성: 첫 60초에 무엇을 알아챘는가, 무엇이 기뻤는가, 무엇이 혼란스러웠는가, 어떤 결정을 훔치겠는가
    • 좋은 도구는 첫 30초에 과정 설명 전 결과를 보여주고, 나쁜 도구는 왜 신경 써야 하는지 보여주기 전 아키텍처를 설명
  • 3~4주차: 발견이 아닌 방법론을 위해 논문 10편 연구
    • 원조 BLEU 점수 논문, Anthropic의 Constitutional AI 논문, Google의 PageRank 논문, Netflix Prize 기록, Scaling Laws 논문
    • 작성: 방법론을 우아하게 만드는 것, 작동시키는 하나의 통찰, 내 도메인에 어떻게 적용할지
    • 명확한 평가 기준, 정직한 한계 공개, 복잡함보다 단순한 정식화 같은 구조적 원칙이 분야를 넘어 반복됨을 발견

• 2개월차: 능동적 분별로 나침반 취향 구축

  • 주간 연습 “Side-by-Side”: 같은 종류의 두 예시를 찾아 왜 하나가 더 나은지 500단어 작성(두 API 문서, 두 기술 블로그, 두 아키텍처 다이어그램, 두 평가 프레임워크)
    • “선호한다” 금지, 항상 “이것이 더 나은 이유는…”으로 구체적 메커니즘 명시
    • 예: Stripe 문서는 내부 아키텍처가 아니라 개발자가 하려는 일(결제 보내기, 오류 처리) 중심으로 구성되어 더 나음
  • 일간 연습 “Practice Noticing”: 도구·논문·코드를 볼 때마다 제작자의 결정 하나를 골라 “왜 이것이고 명백한 대안이 아닌가” 한 문장 기록, 30일 후 30개 관찰의 패턴이 발달 중인 취향

• 3개월차: 생성적 적용으로 비전 취향 구축

  • 9주차: 내가 소유한 것(팀 온보딩 흐름, 프로젝트 README, 평가 파이프라인 개발자 경험)을 배운 것으로 재설계
  • 10주차: 지금까지 쓴 것 중 가장 정밀한 글 작성, 가장 길거나 포괄적이 아니라 모든 문단이 제 몫을 하고 독자의 사고가 바뀌는 글
  • 11주차: 시스템을 처음부터 설계하고 모든 결정을 관습이 아닌 제1원칙으로 설명(“모범 사례라 마이크로서비스”가 아니라 “팀 4명, 예측 가능한 트래픽, 18개월간 필요 없을 확장 이점보다 배포 단순성이 커서 모놀리스”)
  • 12주차: 취향 공유, 두 접근의 차이를 가르치고 자기 코드베이스용 AGENTS.md 작성, 취향을 시스템·문서에 인코딩하는 능력이 개인 기술과 조직 역량을 가름

취향을 빠르게 기르는 다섯 프로젝트

• 1. AI 생성 코드용 평가 프레임워크 구축

  • 린터·테스트 러너가 아니라 “이 AI 코드가 프로덕션에 충분한가”에 답하는 프레임워크, 자체 루브릭 정의(정확성, 유지보수성, 효율성, 보안, 스타일)
  • 실제 AI 생성 PR 50개에 적용·채점, 놀라운 점수를 기준으로 루브릭 보정, 결과 공개, Zone 3(품질 판단) 취향 구축

• 2. 오픈소스 프로젝트 온보딩 재설계

  • 기술은 존경하나 온보딩이 답답한 도구를 fork, 개발자 경험의 첫 5분 재설계, README·시작 가이드 작성, 신규 기여자가 첫날 PR을 낼 수 있게 구조화
  • Zone 4(사용자 공감) 와 Zone 5(커뮤니케이션) 를 동시 구축

• 3. 팀을 위한 “취향 테스트” 구축

  • 구현 접근 10쌍 문서 작성, 각 쌍에서 한쪽이 더 나은 취향, 엔지니어 5명에게 어느 쪽이 나은지와 이유를 질문
  • 흥미로운 산출은 정답이 아니라 의견 불일치, 표준이 어긋난 지점이 버그·기술 부채·재작업의 근원, 가장 레버리지 높은 조직 취향 구축

• 4. 48시간 제약으로 제품 출시

  • 프로토타입이 아니라 타인이 쓸 작동 제품, 시간 제약이 끊임없이 취향 결정을 강제(포함할 것과 잘라낼 것 선택)
  • 잘못된 기능에 6시간을 쓰면 4분의 1을 태우므로 나쁜 결정의 결과가 즉각적

• 5. 사고를 바꾸는 기술 블로그 작성

  • 튜토리얼·하우투가 아니라 익숙한 개념을 재구성해 독자가 이후 다르게 보게 하는 글(취향이 곧 평가라는 깨달음, 모델 릴리스마다 코드를 삭제하는 것이 관행이 아닌 아키텍처 철학이라는 인식)
  • Zone 5(커뮤니케이션·스토리텔링) 구축, 진정한 관점이 모든 취향의 토대

취향 중심으로 경력 최적화하기

• 속도 경쟁 중단

  • AI가 기계 속도로 코드를 쓰면 코딩 속도 경쟁은 지는 게임, 시간당 500줄 생성하는 사람보다 어느 50줄이 실제로 필요한지 30분 고민하는 사람이 가치 높음
  • 구현 속도는 상품화됐고, 상품화되지 않은 것은 무엇을 어떻게 구현할지에 대한 판단

• 취향에 필요한 ‘인접 기술’ 투자

  • 최고 엔지니어들의 공통점은 단순 코더가 아니라는 것, Boris는 스타트업 창업자, Emma는 Stripe에서 4년간 데이터 인프라 리드, Peter는 PSPDFKit를 글로벌 비즈니스로 키움
  • 취향엔 원재료가 필요, 제품 사고·디자인 인식·비즈니스 이해·커뮤니케이션 능력이 취향을 가능하게 하는 재료

• 취향이 보상되는 역할 선택

  • 잘 정의된 명세를 구현하는 역할은 속도를, 무엇을 어떻게 만들고 충분한지 결정하는 역할은 취향을 직접 보상
  • 취향이 특히 보상되는 역할: 초기 스타트업 창업 엔지니어, 제품 회사 테크 리드, 다른 엔지니어가 올라서는 시스템을 설계하는 플랫폼·인프라 엔지니어, 개발자 경험 엔지니어, 교차 팀 아키텍처 결정을 다루는 staff+ 엔지니어

• 취향이 담긴 공개 작업물 구축

  • AI 시대엔 이력서보다 포트폴리오가 중요, 증거는 산출물에 있음(잘 설계된 오픈소스, 일관된 관점의 기술 블로그, 사람들이 실제로 쓰는 제품)
  • Peter의 OpenClaw가 어떤 이력서보다 크게 말하고, Boris의 Claude Code 프로토타입이 어떤 행동 면접 답변보다 취향을 잘 입증

불편한 진실

• 취향은 불균등하게 분포하며 앞으로도 그러함, 일부는 15년간 수천 번의 결정으로 길러 90일 계획으로 따라잡을 수 없는 출발선 차이를 가짐
  • Codex 팀은 무제한 토큰 접근에 모델을 만드는 회사에서 일하고, Peter는 20년 경력에 회사를 엑싯한 비전형적 출발점
• 다만 “취향 없음”과 “약간의 취향” 사이 격차는 경력 영향에서 거대하고 메울 수 있음, 티켓을 받아 구현하던 사람이 사용자 리서치로 무엇을 만들지 제안하고 테스트·아키텍처까지 AI로 구현하는 도약이 곧 취향
• Gergely Orosz의 정직한 토로: “가치 있는 무언가가 갑작스레 빼앗기는 느낌, 코딩을 잘하게 되기까지 많은 노력이 들었고, 몰입해 아이디어를 타이핑하던 것이 최고의 기억”
  • 손코딩 기술이 덜 중심적이 되는 상실감은 진짜이나, 어떤 코드가 존재해야 하고 어떻게 구조화되며 충분한지 아는 능력은 언제나 진짜 역량이었음
• 다음에 번창할 엔지니어는 이를 깨달은 사람, 취향은 늘 직무였고 단지 코드 속에 숨겨져 있었을 뿐, AI가 타이핑을 가져가며 그것을 드러냄

[clastneo]

야 이젠 10x도 안되고 30x를 고민해야 하는구나 ㅋㅋㅋ

[channprj]

저도 x배 엔지니어 같은 다소 과장된 표현을 그만 보고 싶긴 합니다.. ㅠㅠ
정량적인 척 하지만 사실을 정성적인 표현이기도 하고요.