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

> Clean Markdown view of GeekNews topic #30338. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30338](https://news.hada.io/topic?id=30338)
- GeekNews Markdown: [https://news.hada.io/topic/30338.md](https://news.hada.io/topic/30338.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2026-06-10T09:36:02+09:00
- Updated: 2026-06-10T09:36:02+09:00
- Original source: [pakodas.substack.com](https://pakodas.substack.com/p/how-to-be-a-30x-ai-engineer-with-a-taste)
- Points: 20
- Comments: 2

## Topic Body

- 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가 타이핑을 가져가며 그것을 드러냄

## Comments



### Comment 59314

- Author: clastneo
- Created: 2026-06-10T10:43:36+09:00
- Points: 2

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

### Comment 59323

- Author: channprj
- Created: 2026-06-10T11:36:17+09:00
- Points: 2
- Parent comment: 59314
- Depth: 1

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