3줄 요약
- Galileo의 Pratik Bhavsar가 2026년 2월에 쓴 글로, Pragmatic Engineer의 Codex와 Claude Code 심층 기사들에서 반복 등장한 “테이스트(taste)“라는 단어를 구체적인 능력으로 분해한다.
- 테이스트를 “내부 평가 함수의 품질"로 정의하고, 인식(recognition), 나침반(compass), 비전(vision) 세 형태와 가치가 생성되는 다섯 구역으로 구조화한다.
- 막연한 “경험을 쌓아라"를 넘어, 90일 훈련 계획과 다섯 가지 실전 프로젝트, 커리어 포지셔닝 전략까지 제시한다.
세계는 바뀌었는데 엔지니어 대부분은 눈치채지 못했다
글의 출발점은 2025년 말의 변화다. Dario Amodei가 2025년 3월에 “수개월 안에 AI가 코드의 90%를 쓸 것"이라고 예측했을 때는 터무니없게 들렸지만, 12월에 Claude Code를 만든 Boris Cherny는 그달 커밋한 코드의 100%가 AI 작성이었고 IDE를 한 번도 열지 않았다고 보고했다.
- Andrej Karpathy는 2025년 10월 AI 코딩 도구를 “slop"이라 불렀다가 12월에 입장을 완전히 뒤집었다. “프로그래머로서 이렇게 뒤처진 기분은 처음이다. 직업이 극적으로 리팩토링되고 있다.”
- Ruby on Rails를 만든 DHH도 자신의 저항이 “모델이 충분히 좋지 않았기 때문이었는데, 이제 뒤집혔다"고 인정했다.
- Vercel CTO Malte Ubl은 “소프트웨어 생산 비용은 0을 향해 가고 있다"고 단언했다.
저자의 진단은 이렇다. Opus 4.5, GPT-5.2, Gemini 3가 2025년 11~12월 사이 보이지 않는 능력선을 넘었고, 넓은 범위의 프로그래밍 작업에서 AI 코드가 숙련 엔지니어의 손 코드만큼 좋아졌다. 코드 생성이 범용재에 가까워지면 남는 것은 “그 외 전부"다. 문제를 분해하고, 무엇을 만들지 정하고, 테스트 가능성과 신뢰성을 위해 아키텍처를 잡고, 출시 시점을 판단하는 일. 저자는 이것을 테이스트라고 부른다.
OpenAI의 세 사람이 독립적으로 같은 결론에 도달했다는 점이 도입부의 근거다. 데이터 인프라 책임자 Emma Tang은 “좋은 소프트웨어 테이스트를 가진 사람이 있다면 이제 누구나 10x 엔지니어가 될 수 있다"고 말했고, Codex 책임자 Tibo는 성공하는 엔지니어들이 “자신만의 나침반이 필요하다"고 했으며, 연구자 SQ Mah는 “모델은 컨텍스트가 있으면 탁월하지만, 진화를 정의하는 것은 인간"이라고 표현했다.
테이스트의 세 가지 형태
저자는 최고 엔지니어링 팀들이 테이스트를 말하는 방식을 관찰해 세 가지 정의를 추출한다. 서로 다르게 들리지만 같은 능력을 다른 각도에서 본 것이다.
| 형태 | 작동 대상 | 핵심 질문 | 대표 사례 |
|---|---|---|---|
| 인식(recognition) | 완성된 산출물 | 어느 쪽이 더 좋은가 | Codex 팀의 Rust CLI 선택 |
| 나침반(compass) | 가능성과 방향 | 다음에 무엇을 만들까 | Boris Cherny의 todo 리스트 프로토타입 20개 |
| 비전(vision) | 미래와 궤적 | 2년 뒤 무엇이 중요해지나 | Steinberger의 “에너지를 시스템 설계에 집중하라” |
인식 테이스트는 두 구현을 보고 설명하기 전에 어느 쪽이 나은지 느끼는 능력이다. 소스에 산이 부족하다는 것을 의식적 분석 전에 아는 셰프와 같다. Codex 팀이 CLI를 TypeScript 대신 Rust로 만든 결정이 예시다. 기술적 우월성 때문이 아닌, Rust의 제약(강타입, 명시적 메모리 관리, 최소 의존성)이 팀 문화에 만들 2차 효과를 알아본 것이다.
나침반 테이스트는 존재하지 않는 것의 방향을 감지하는 능력이다. Boris Cherny는 Claude Code의 todo 리스트 기능 하나에 이틀간 프로토타입 약 20개를 만들었다. 인라인, 드로어 UI, 인터랙티브 필, 화면 하단 표시. 각 중간 버전에 대한 불만족이 나침반으로 작동했고, 최종 버전이 왜 나은지는 사후에야 설명할 수 있었다. 저자는 나침반 테이스트가 인식 테이스트보다 희귀하다고 본다. 실행보다 상류에서 작동하기 때문이다.
비전 테이스트는 지금 좋은 것이 아닌 앞으로 중요해질 것을 아는 능력이다. OpenClaw를 만든 Peter Steinberger는 에이전트 5~10개를 동시에 돌리면서 자기 시간 대부분을 아키텍처와 시스템 설계에 쓴다. “대부분의 코드는 지루한 데이터 변환이다. 에너지를 시스템 설계에 집중하라.” 가치의 중심이 영구적으로 이동했음을 인지하고 워크플로우 전체를 재편성한 것이다.
통합 정의
세 형태는 하나의 메커니즘으로 수렴한다. 테이스트는 내부 평가 함수의 품질이다. 테이스트를 발휘할 때마다 현재 상태를 내부 기준과 비교해 판단을 내린다. 인식 테이스트는 평가 함수가 완성물에, 나침반 테이스트는 가능성에, 비전 테이스트는 미래에 작동한다는 차이뿐이다. AI가 코드를 생성하는 세계에서 인간의 일은 평가 그 자체가 되었고, 평가를 잘하게 만드는 것이 테이스트라는 논리다.
왜 어떤 엔지니어는 훨씬 많이 버는가
AI 이전의 보상 격차는 회사, 연차, 전문 분야 세 변수로 설명됐다. AI가 셋 다 흔들고 있다.
- 회사는 여전히 중요하지만, 스타트업의 뛰어난 엔지니어와 평범한 엔지니어의 격차가 3x에서 10x로 벌어졌다. 뛰어난 쪽이 AI로 소규모 팀의 산출량을 낸다.
- 연차의 의미가 바뀌었다. 코드를 쓴 햇수보다 좋은 판단을 내린 햇수가 중요해졌다.
- 전문성은 다시 쓰이고 있다. “React를 안다"는 Claude Code가 React를 그만큼 쓸 수 있게 되면서 가치가 떨어졌고, “부하에서 신뢰할 수 있는 시스템을 설계할 수 있다"는 AI가 자율적으로 못 하기에 어느 때보다 가치가 올랐다.
많이 버는 엔지니어들의 공통점은 복리로 작용하는 결정을 내린다는 것이다. 좋은 아키텍처 결정 하나가 이후 1년간 수개월의 작업을 절약하고, 좋은 제품 결정 하나가 기능의 실제 채택을 가른다. 저자의 불편한 함의: 테이스트가 더 좋은 사람보다 두 배 열심히 일해도 절반의 가치만 만들 수 있다. AI 에이전트 8개를 잘못된 문제에 돌리는 엔지니어는, 정확한 문제에 정확한 제약으로 2개를 돌리는 엔지니어보다 덜 생산한다.
Codex 기사의 관찰이 이를 뒷받침한다. AI 도구를 받아들여 생산성이 크게 오른 엔지니어들이 한 일은 코드를 더 많이 생성한 것이 아니었다. 사용자와 더 많이 대화하고, 제품 방향을 더 고민하고, Codex를 쓰는 수백만 개발자에게 공감하는 데 시간을 더 썼다.
가치가 생성되는 다섯 구역
| 구역 | 내용 | 대표 사례 |
|---|---|---|
| 1. 문제 선택 | 무엇을 풀지 고르기. 가장 레버리지가 높은 결정 | Claude Code 권한 시스템: 복잡한 ACL 대신 “물어보고 답을 기억한다"는 최소 해법 선택 |
| 2. 시스템 아키텍처 | 조각들이 맞물리는 방식. 반감기가 가장 긴 테이스트 | “모델 주변에 코드를 최소한으로 둔다. 새 모델이 나올 때마다 코드를 지운다” (Cherny) |
| 3. 품질 판단 | 언제 출시해도 되는지 아는 것 | Codex의 계층화된 코드 리뷰: 핵심 에이전트 코드만 인간 리뷰 필수 |
| 4. 사용자 공감 | 반대편 인간이 실제로 필요한 것 | 스피너에 모델이 실제로 하는 일을 표시한 컨텍스추얼 로딩 메시지 |
| 5. 커뮤니케이션 | 만든 것을 프레이밍하는 방식 | OpenClaw의 바이럴: 명확한 이름, 설득력 있는 데모, “혼자서 팀 전체의 산출량"이라는 서사 |
구역 3에서 저자가 인용하는 수치가 흥미롭다. Codex 팀 엔지니어들은 거의 모든 코드를 프롬프트로 쓰지만, OpenAI의 다른 부서에서는 그 비율이 약 70%다. 손으로 쓰는 30%는 무작위가 아닌, 품질 판단이 가장 중요한 부분이다. 코드베이스와의 연결을 유지하기 위해 30%를 손으로 쓰는 “30/70 규칙” 자체가 테이스트 결정이라고 본다.
구역 4의 사례도 구체적이다. Codex 팀은 샌드박스를 기본값으로 두는 선택에 대해 “일반 채택에는 손해지만, 기본값부터 안전하지 않은 것을 권하고 싶지 않다"고 말했다. 사용자 다수가 “그렇게 기술적이지 않다"는 이해에서 나온 결정이다.
테이스트의 유무를 가르는 사례들
저자는 같은 상황을 테이스트 있게/없게 처리한 짝 사례를 제시한다.
| 상황 | 테이스트 없음 | 테이스트 있음 |
|---|---|---|
| 기술 스택 선택 | “TypeScript가 제일 인기 있으니 쓰자” | Cherny는 모델이 이미 잘 다루는 “on distribution” 언어라서 TypeScript를, Codex 팀은 “엔지니어링 기준을 생각하게 만드는” 언어라서 Rust를 선택. 둘 다 구체적 제약에 근거 |
| 이해 못 한 코드 처리 | “AI가 생성했고 테스트 통과하니 출시” | Steinberger는 코드를 읽지 않고 출시하지만 컴포넌트 위치, 구조, 전체 설계는 파악하며, 테스트, 린트, 로컬 CI가 검증 레이어로 작동 |
| 기능 요청 대응 | 티켓대로 구현하고 다음으로 | 프로토타입 20개로 “당연히 거기 있어야 할 것 같은” 필연성에 도달 |
| AI 에이전트를 위한 설계 | 일반 README 작성 | AGENTS.md로 “모델이 성공하는 것이 필연이 되도록” 환경을 설계 |
| PR 홍수 대응 | 기존 리뷰 프로세스 유지, 리뷰어 과부하 | Emma Tang 팀은 PR에 프롬프트 첨부를 요구. “프롬프트가 없으면 슬랙으로 물어본다.” 생성 단위가 바뀌었으니 리뷰 단위도 바뀌어야 한다는 인식 |
코드를 읽지 않고 출시하는 두 엔지니어의 구분이 핵심이다. 한쪽은 도박을 하고 있고, 다른 쪽은 정확성이 구조적으로 보장되는 시스템을 만들어 두었다.
90일 테이스트 개발 계획
“경험을 더 쌓아라"는 조언은 맞지만 쓸모없다는 것이 저자의 입장이다. 세 형태별로 구체적 훈련을 제시한다.
1개월차: 구조화된 노출로 인식 테이스트 만들기. 1~2주차에는 감탄한 개발자 도구 10개(Codex CLI, Claude Code, Linear, Supabase, Stripe 대시보드, Vercel, Tailwind 등 + 소프트웨어가 아닌 제품 하나)를 도구당 15분씩 분석한다. 첫 60초에 무엇을 알아챘나, 무엇이 기뻤나, 무엇을 훔치고 싶나. 3~4주차에는 연구 논문 10편을 결과가 아닌 방법론 중심으로 읽는다(BLEU, Constitutional AI, PageRank, Netflix Prize, Scaling Laws). 분야를 가로지르는 노출에서 최고의 테이스트가 발달한다는 것이 근거다.
2개월차: 능동적 변별로 나침반 테이스트 만들기. 매주 같은 종류의 산출물 두 개를 놓고 어느 쪽이 왜 나은지 500단어를 쓴다. 규율은 하나다. “이게 더 좋다"고 말하지 않고 “이것이 더 나은 이유는…“이라고 메커니즘을 명시한다. 매일은 도구, 논문, 코드에서 제작자의 결정 하나를 포착해 “왜 명백한 대안 대신 이것인가"를 한 문장으로 기록한다. 30일 뒤 노트를 돌아보면 그 패턴이 자신의 발달 중인 테이스트다.
3개월차: 생성적 적용으로 비전 테이스트 만들기. 9주차에 자기 소유물 하나를 재설계하고, 10주차에 인생 최고로 정밀한 글을 쓰고, 11주차에 관례가 아닌 제1원리로 모든 결정을 설명하는 시스템을 설계하고, 12주차에 자기 테이스트를 남에게 가르친다. 테이스트를 시스템과 문서로 인코딩하는 능력이 개인 기술과 조직 역량을 가른다.
테이스트를 빠르게 단련하는 다섯 프로젝트
- AI 생성 코드 평가 프레임워크 만들기. 린터도 테스트 러너도 아닌, “프로덕션에 충분한가"를 답하는 자기만의 루브릭. 실제 AI 생성 PR 50개에 적용하고 점수가 놀라운 지점에서 루브릭을 보정한다. (구역 3 훈련)
- 오픈소스 프로젝트 온보딩 재설계. 기술은 감탄하지만 온보딩이 답답한 도구를 포크해 첫 5분의 개발자 경험을 다시 만든다. (구역 4, 5 훈련)
- 팀을 위한 테이스트 테스트 만들기. 구현 접근법 10쌍을 놓고 엔지니어 5명에게 고르게 한다. 정답보다 불일치가 산출물이다. 팀의 기준이 안 맞는 곳이 버그, 기술 부채, 재작업의 발원지다.
- 48시간 제약으로 제품 출시. 시간 제약이 테이스트 결정을 강제한다. 잘못된 기능에 6시간을 쓰면 즉시 대가를 치른다.
- 누군가의 사고를 바꾸는 기술 블로그 글 쓰기. 튜토리얼이 아닌, 익숙한 개념을 재프레이밍하는 글. 자기만의 관점을 갖는 것이 모든 테이스트의 토대다.
커리어를 테이스트 중심으로 최적화하기
- 속도 경쟁을 멈춰라. 시간당 500줄을 생성하는 엔지니어보다, 어떤 50줄이 존재해야 하는지 30분 생각하는 엔지니어가 더 가치 있다.
- 인접 기술에 투자하라. Cherny는 스타트업 창업자였고, Tang은 Stripe에서 4년간 데이터 인프라를 이끌었고, Steinberger는 PSPDFKit을 글로벌 비즈니스로 키웠다. 제품 사고, 디자인 감각, 비즈니스 이해가 테이스트의 원재료다.
- 테이스트가 보상받는 역할을 골라라. 명세 구현이 일인 역할은 속도를 보상한다. 초기 스타트업 파운딩 엔지니어, 제품 회사 테크 리드, 플랫폼/인프라 엔지니어, DX 엔지니어, staff+ 역할이 테이스트를 직접 보상한다.
- 공개된 작업물을 쌓아라. 테이스트는 누구나 주장할 수 있다. 증명은 산출물에 있다. OpenClaw는 어떤 이력서보다 크게 말한다.
불편한 진실
저자는 마지막에 솔직해진다. 테이스트는 불균등하게 분포하며 앞으로도 그럴 것이다. 15년간 수천 번의 결정으로 테이스트를 쌓은 사람들의 출발선은 90일 계획으로 따라잡을 수 없다. 그러나 “테이스트 없음"과 “테이스트 있음” 사이의 격차는 거대하고, 그 격차는 좁힐 수 있다. “티켓을 받아 구현하는” 엔지니어가 “사용자 리서치 기반으로 무엇을 만들지 제안하고 AI로 테스트와 아키텍처까지 구현하는” 엔지니어로 도약하는 것, 그것이 테이스트다.
Gergely Orosz의 회고를 인용하며 글을 닫는다. “무언가 가치 있는 것이 갑자기 빼앗기는 느낌이다. 코딩을 잘하게 되기까지 많은 노력이 들었다.” 저자는 그 상실감을 인정하면서 이렇게 답한다. 장인정신은 타이핑에 있던 적이 없다. 생각에 있었다. AI는 타이핑을 가져가면서 그것을 보이게 만들었을 뿐이다. “테이스트는 언제나 일의 본질이었다. 우리가 코드 안에 숨겨 두었을 뿐이다.”
가장 흥미로운 지점
이 글의 가장 큰 기여는 “테이스트 = 내부 평가 함수의 품질"이라는 한 줄 정의다. 인식, 나침반, 비전이라는 세 형태가 평가 함수의 적용 대상(완성물, 가능성, 미래)만 다른 같은 메커니즘이라는 통합이 깔끔하다. 모호한 단어를 훈련 가능한 능력으로 바꾸는 작업으로서 설득력이 있다.
한편 근거 자료의 출처가 거의 전부 Pragmatic Engineer의 기사 세 편(Codex, Claude Code, OpenClaw)이라는 점은 읽을 때 감안할 부분이다. 표본이 모두 AI 코딩 도구를 만드는 최상위 팀이라, 여기서 추출한 패턴이 일반 기업의 평균적 엔지니어링 환경에 그대로 이식되는지는 별도의 검증이 필요하다. 저자 자신도 “Codex 팀은 무제한 토큰을 쓰고 모델을 만드는 회사에서 일한다. 전형적인 출발점이 아니다"라고 인정한다. 그 솔직함이 글의 신뢰도를 오히려 높인다.
출처
Pratik Bhavsar (Galileo AI 리드), 2026-02-19, Substack 뉴스레터. 원문: https://pakodas.substack.com/p/how-to-be-a-30x-ai-engineer-with-a-taste