취향(taste)을 갖춘 30배 AI 엔지니어가 되는 법
취향(taste)을 갖춘 30배 AI 엔지니어가 되는 법
한 줄 요약
AI가 코드를 대량 생성하는 시대에 엔지니어의 가치는 속도나 지식이 아니라 '취향(taste)', 즉 무엇을 만들지 판단하는 내부 평가 함수의 품질에 의해 결정되며, 좋은 소프트웨어 취향을 가진 사람이 있으면 누구나 10배 엔지니어가 될 수 있다.
핵심 내용
1. 변화된 현실: 코드 생성의 상품화
2025년 11~12월 사이 Opus 4.5, GPT-5.2, Gemini 3 등 모델이 숙련 엔지니어 수준의 코드를 분 단위 내에 생성할 수 있게 되었다. 코드를 직접 작성하는 능력은 더 이상 차별화 요소가 아니다.
주요 인물들의 입장 변화를 보면 상황이 얼마나 빠르게 바뀌었는지 알 수 있다:
- Boris Cherny (Claude Code 제작자): 12월 기준 자신이 커밋한 코드의 100%가 AI 작성이며, IDE를 한 번도 열지 않았다고 보고
- Andrej Karpathy: AI 코딩 도구를 'slop(쓰레기)'라 비판했던 사람이 12월 입장을 완전히 뒤집으며 "프로그래머로서 이렇게 뒤처졌다고 느낀 적이 없으며 직업이 극적으로 재편되고 있음"이라고 인정
- DHH (Ruby on Rails 제작자): 초기 저항이 "모델이 충분히 좋지 않았기 때문"이었고 이제 상황이 뒤집혔다고 인정
- Malte Ubl (Vercel CTO): "소프트웨어 생산 비용이 0으로 수렴 중"이라고 언급
코드 생성이 상품화되면 남는 것은 소프트웨어 엔지니어링 그 자체다. 문제 분해, 무엇을 만들지 결정, 테스트·신뢰성·확장 설계, 트레이드오프 판단 — 곧 취향이다.
2. 취향(Taste)의 세 가지 형태
최고의 엔지니어링 팀이 말하는 취향에는 세 가지 정의가 존재하며, 같은 능력을 다른 각도에서 본 것이다.
인식(Recognition)으로서의 취향
두 구현을 보고 왜인지 설명하기 전에 어느 쪽이 더 나은지 느끼는 능력이다. Emma Tang는 시스템이 정말 깔끔하고 확장 가능하며 중복이 없는지, 이해하기 단순한지가 취향의 문제라고 말한다.
소스를 맛본 셰프가 산미가 빠졌음을 의식적으로 식별하기 전에 아는 것처럼, 패턴 매칭이 의식적 추론보다 빠르게 작동한다.
실제 사례: Codex 팀이 CLI를 TypeScript 대신 Rust로 선택한 결정이다. 둘 다 작동하지만, Rust의 제약(강타입, 명시적 메모리 관리, 최소 의존성)이 기술적 장점을 넘어 엔지니어링 문화 효과를 만든다고 인식했다. "기술적으로 우월한 언어"가 아니라 "팀에서 원하는 행동을 형성하는 언어"라는 판단이다.
나쁜 취향의 예: 유행이라서, 블로그가 빠르다 해서 2차 효과 이해 없이 Rust를 고르는 것이다.
나침반(Compass)으로서의 취향
이미 존재하는 것을 평가하는 게 아니라 다음에 무엇을 만들지 아는 능력이다. 코드 한 줄 작성 전에 "이건 옳은 기능이 아니다"라고 말하는 엔지니어가 갖는 능력이다.
실제 사례: Boris Cherny가 Claude Code의 todo 리스트 기능을 이틀간 약 20개 프로토타입으로 제작한 것이다. 인라인 todo, 드로어 UI, 인터랙티브 pill, 화면 하단 표시 등을 시도하며 임의적이지 않고 필연적으로 느껴지는 형태로 수렴했다. 사후엔 왜 최종안이 더 나은지 설명할 수 있었지만, 중간안에 대한 초기의 불만족 자체가 나침반으로 작동한 취향이다.
비전(Vision)으로서의 취향
지금 좋은 것이 아니라 2년 뒤 중요해질 것을 아는 가장 어려운 형태다.
실제 사례: OpenClaw 제작자 Peter Steinberger는 5~10개 에이전트를 동시에 돌리며 대부분의 시간을 아키텍처·시스템 설계에 투입한다. "대부분의 코드는 지루한 데이터 변환이며, 에너지는 시스템 설계에 집중"하라고 말한다.
통합 정의: 세 형태 모두 하나의 메커니즘으로 수렴한다. 취향은 내부 평가 함수의 품질이다. 인식은 완성된 산출물에, 나침반은 가능성·방향에, 비전은 미래·궤적에 평가 함수가 작동한다. AI가 코드를 생성하는 세계에서 인간의 일은 평가(무엇을 만들지 결정, 산출물이 충분한지 판단, 아키텍처 변경 시점 감지)이며, 평가가 곧 직무다.
3. 가치가 생성되는 5가지 영역 (The 5 Zones)
대부분의 엔지니어는 한두 영역에서만 경쟁하지만, 취향이 있는 엔지니어는 다음 5가지 영역에서 불균형적 가치를 창출한다.
Zone 1: 문제 선택 (Problem Selection)
무엇을 할지 고르는 가장 레버리지가 높은 취향 결정이지만, 대부분 거의 생각하지 않는다. 취향 있는 엔지니어는 "이것을 잘 풀면 다른 다섯 문제가 사라지는가"를 질문한다.
실제 사례: Peter Steinberger는 에이전트와 오래 주고받으며 계획을 다듬고 도전·반박한 후, 만족할 때만 에이전트를 실행한다. 계획이 곧 작업이고 실행은 위임한다. Claude Code 권한 시스템에서 복잡한 RBAC(역할 기반 접근 제어)·세분화 정책 대신 가장 단순한 접근(권한 요청 후 답 기억)을 선택해 빠르고 직관적으로 출시했다.
Zone 2: 시스템 아키텍처 (System Architecture)
조각들이 맞물리는 방식으로, 취향의 반감기가 가장 긴 영역이다. 좋은 결정은 2년 뒤에도 배당을 주지만, 나쁜 결정은 재작성을 요구하는 기술 부채로 누적된다.
실제 사례: Codex의 에이전트 루프를 상태 머신으로 만든 결정, Claude Code의 "가능한 한 비즈니스 로직을 적게" 작성하는 결정, OpenClaw의 모듈식 확장성 집착이 모두 아키텍처 취향 결정이다. Boris Cherny는 "새 모델이 나올 때마다 코드를 잔뜩 삭제하며, 모델 주위에 가능한 한 적은 코드를 둔다"고 말한다. 대부분 팀은 릴리스마다 코드를 추가하지만 Claude Code 팀은 제거한다. 모델이 곧 제품이고 주변은 최대한 얇아야 한다는 철학이다.
Zone 3: 품질 판단 (Quality Judgment)
출시하기에 충분한지, 더 작업이 필요한지 아는 것으로, AI가 도울 수 없는 영역이다(특정 맥락의 "충분함"을 모르기 때문).
실제 사례: Codex의 계층적 코드 리뷰에서 비핵심 코드는 AI 리뷰만, 핵심 에이전트 코드는 인간 리뷰가 필수다. 취향은 어느 코드가 중요한지 아는 데 있다. 권한 시스템엔 인간의 눈이 필요하고 README 갱신엔 불필요하다. Codex 팀은 거의 모든 코드를 프롬프트로 작성하나 사내 다른 부서는 약 70% 수준이며, 손으로 쓰는 30%는 품질 판단이 가장 중요한 부분이다("30/70 규칙").
Zone 4: 사용자 공감 (User Empathy)
상대편 인간이 실제로 무엇을 필요로 하는지 이해하는, AI가 가장 약한 영역이다.
실제 사례: Boris가 만든 Claude Code의 맥락형 로딩 메시지(단순 회전 대신 모델이 무엇을 하는지 표시)는 아무도 요청하지 않았으나, 정보 없는 대기와 있는 대기의 차이를 위해 제작했다. Codex의 샌드박스 기본값도 사용자 공감 결정이다. Tibo는 "채택률에 손해를 보더라도 기본적으로 안전하지 않을 수 있는 것을 권하지 않는다"고 말한다. 많은 사용자가 되돌릴 수 없는 일을 실수로 할 수 있음을 이해하고, 편의보다 안전을 선택했다.
Zone 5: 커뮤니케이션과 스토리텔링 (Communication & Storytelling)
만든 것을 어떻게 프레이밍하는가로, 엔지니어가 일관되게 과소평가하지만 시장이 보상하는 영역이다.
실제 사례: Peter Steinberger의 OpenClaw는 바이럴 주간에 Claude Code와 Codex를 합친 것보다 많은 Google 검색을 기록했다. 명확한 이름, 설득력 있는 데모, "한 사람이 팀 규모의 산출을 만든다"는 서사가 확산을 견인했다. Codex의 AGENTS.md 파일(인간이 아닌 AI 에이전트용 README)은 문서의 독자가 바뀌었음을 인식하고 형식을 적응시킨 커뮤니케이션 취향이다.
4. 취향의 사례 비교 (Do's and Don'ts)
기술 스택 선택: 취향 없는 사람은 "가장 인기 있고 다들 하니까 TypeScript"라고 관습으로 정당화한다. 취향 있는 사람은 Boris처럼 Claude 모델에 "on distribution"(모델이 이미 잘 다루는 언어)이라 TypeScript를 선택하거나, Codex처럼 "설정한 엔지니어링 기준을 생각하게 만드는" Rust를 선택한다. 같은 결정이지만 둘 다 일반 선호가 아닌 구체적 제약에 근거한다.
이해 안 되는 코드 다루기: 취향 없는 사람은 "AI로 생성했고 테스트를 통과하니 출시"라고 테스트 충분성·유지보수성을 고려하지 않는다. 취향 있는 사람은 Peter처럼 읽지 않은 코드를 출시하되 부주의하지 않는다. "컴포넌트 위치와 구조, 전체 시스템 설계를 알며 보통 그것으로 충분"하다. 테스트·린팅·로컬 CI가 검증 계층이며, 한쪽은 도박이고 다른 쪽은 구조적으로 정확성이 보장되는 시스템이다.
기능 요청 대응: 취향 없는 사람은 티켓대로 구현하고 출시 후 다음으로 간다. 취향 있는 사람은 Boris처럼 출시 전 이틀간 20개 프로토타입을 제작한다. 느린 게 아니라 빠른 실험으로 옳은 해법으로 항해하며, 필연성이 취향의 지문이다.
PR 폭주 대응: 취향 없는 사람은 AI 생성 PR이 쏟아지는데 동일 리뷰 프로세스를 유지하며 리뷰어가 과부하에 빠진다. 취향 있는 사람은 Emma Tang 팀처럼 PR에 프롬프트 첨부를 요구한다. 없으면 Slack으로 "프롬프트가 뭐냐"고 질문한다. AI 세계에선 코드보다 의도 리뷰가 유익하다. Peter는 PR을 "prompt requests"라 부르며 코드보다 생성 프롬프트에 더 관심을 둔다. 생성 단위가 바뀌었으므로 리뷰 단위도 변경해야 한다.
5. 취향을 기르는 90일 실행 계획
"경험을 더 쌓아라"는 조언은 "운동을 더 해라"처럼 무용하다. 아래는 세 형태별 구체적인 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를 작성한다. 취향을 시스템·문서에 인코딩하는 능력이 개인 기술과 조직 역량을 가른다.
6. 취향을 빠르게 기르는 5가지 프로젝트
- AI 생성 코드 평가 프레임워크 구축: 린터·테스트 러너가 아니라 "이 AI 코드가 프로덕션에 충분한가"에 답하는 프레임워크를 만든다. 자체 루브릭(정확성, 유지보수성, 효율성, 보안, 스타일)을 정의하고 실제 AI 생성 PR 50개에 적용·채점한다. 놀라운 점수를 기준으로 루브릭을 보정한다(Zone 3).
- 오픈소스 프로젝트 온보딩 재설계: 기술은 존경하나 온보딩이 답답한 도구를 fork(포크)한다. 개발자 경험의 첫 5분을 재설계하고, 신규 기여자가 첫날 PR을 낼 수 있게 구조화한다(Zone 4, 5).
- 팀 "취향 테스트" 구축: 구현 접근 10쌍을 문서화하고, 엔지니어 5명에게 어느 쪽이 나은지와 이유를 질문한다. 정답이 아니라 의견 불일치가 흥미로운 산출이다. 표준이 어긋난 지점이 버그·기술 부채·재작업의 근원이다. 가장 레버리지가 높은 조직 취향을 구축한다.
- 48시간 제약으로 제품 출시: 프로토타입이 아니라 타인이 쓸 작동 제품을 만든다. 시간 제약이 끊임없이 취향 결정을 강제한다(포함할 것과 잘라낼 것 선택). 잘못된 기능에 6시간을 쓰면 4분의 1을 태우므로 나쁜 결정의 결과가 즉각적이다.
- 사고를 바꾸는 기술 블로그 작성: 튜토리얼·하우투가 아니라 익숙한 개념을 재구성해 독자가 이후 다르게 보게 하는 글을 쓴다(Zone 5). 진정한 관점이 모든 취향의 토대다.
7. 경력 최적화 전략
속도 경쟁 중단: AI가 기계 속도로 코드를 쓰면 코딩 속도 경쟁은 지는 게임이다. 시간당 500줄을 생성하는 사람보다 어느 50줄이 실제로 필요한지 30분 고민하는 사람이 가치가 높다. 구현 속도는 상품화되었고, 상품화되지 않은 것은 무엇을 어떻게 구현할지에 대한 판단이다.
취향에 필요한 '인접 기술' 투자: 최고 엔지니어들의 공통점은 단순 코더가 아니라는 것이다. Boris는 스타트업 창업자, Emma는 Stripe에서 4년간 데이터 인프라 리드, Peter는 PSPDFKit를 글로벌 비즈니스로 키웠다. 취향엔 원재료가 필요하다. 제품 사고·디자인 인식·비즈니스 이해·커뮤니케이션 능력이 취향을 가능하게 하는 재료다.
취향이 보상되는 역할 선택: 잘 정의된 명세를 구현하는 역할은 속도를, 무엇을 어떻게 만들고 충분한지 결정하는 역할은 취향을 직접 보상한다. 초기 스타트업 창업 엔지니어, 제품 회사 테크 리드, 플랫폼·인프라 엔지니어, 개발자 경험 엔지니어, staff+ 엔지니어 등.
취향이 담긴 공개 작업물 구축: AI 시대엔 이력서보다 포트폴리오가 중요하다. 증거는 산출물에 있다(잘 설계된 오픈소스, 일관된 관점의 기술 블로그, 사람들이 실제로 쓰는 제품). Peter의 OpenClaw가 어떤 이력서보다 크게 말하고, Boris의 Claude Code 프로토타입이 어떤 행동 면접 답변보다 취향을 잘 입증한다.
8. 불편한 진실
취향은 불균등하게 분포하며 앞으로도 그러하다. 일부는 15년간 수천 번의 결정으로 길러 90일 계획으로 따라잡을 수 없는 출발선 차이를 가진다. Codex 팀은 무제한 토큰 접근에 모델을 만드는 회사에서 일하고, Peter는 20년 경력에 회사를 엑싯한 비전형적 출발점이다.
다만 "취향 없음"과 "약간의 취향" 사이 격차는 경력 영향에서 거대하고 메울 수 있다. 티켓을 받아 구현하던 사람이 사용자 리서치로 무엇을 만들지 제안하고 테스트·아키텍처까지 AI로 구현하는 도약이 곧 취향이다.
Gergely Orosz의 정직한 토로: "가치 있는 무언가가 갑작스레 빼앗기는 느낌, 코딩을 잘하게 되기까지 많은 노력이 들었고, 몰입해 아이디어를 타이핑하던 것이 최고의 기억"이다. 손코딩 기술이 덜 중심적이 되는 상실감은 진짜이나, 어떤 코드가 존재해야 하고 어떻게 구조화되며 충분한지 아는 능력은 언제나 진짜 역량이었다.
다음에 번창할 엔지니어는 이를 깨달은 사람이다. 취향은 늘 직무였고 단지 코드 속에 숨겨져 있었을 뿐이며, AI가 타이핑을 가져가며 그것을 드러냈다.
커뮤니티 반응 (Hacker News)
HN에서 관련 토론 "Taste in the age of AI and LLMs"(265점, 211 댓글)가 활발히 진행되었다.
찬성: 취향은 항상 중요한 역량이었다
drob518은 Paul Graham의 Hackers and Painters를 인용하며 취향이 항상 가장 강력한 해자(moat, 경쟁 우위)였다고 말한다. "우리는 좋은 취향이 무엇인지 정의하기 어렵다. 봤을 때 알 수는 있지만, 일반적인 용어로 설명할 수는 없다. 나는 그가 코드를 작성할 수 있는지 안다. 하지만 취향이 있는가?" — 취향은 AI 시대가 새롭게 만든 게 아니라, AI 시대에 더 선명하게 드러난 오래된 개념이다.
nayuki는 Paul Graham의 고전 에세이 "Taste for Makers"(2002)를 언급하며 취향에 대한 논의는 20년 전부터 이어져 왔다고 지적한다.
yawnxyz는 "좋은 판단과 노력이 항상 진짜 해자였다"며 예술, 음악, 과학, 음식, 제품 등 모든 분야에서 그랬다고 말한다. "중간을 평탄하게 만드는" 방법은 아웃소싱, 사전 포장된 상품, 산업화 등 항상 존재해 왔고, 사람들은 항상 수공예적·정교한 것을 사랑해 왔다.
비판: '유능한 출력은 저렴해졌다'는 전제가 잘못되었다
lostathome은 첫 문장부터 반대한다. "유능한 출력은 저렴하지 않다. 최종 제품으로 정의한다면 말이다. 과학 연구만 생각해보라. 데이터 분석 결과는 저렴하게 얻어지지 않는다. 바이브 코딩(vibe coding, AI 프롬프트로 코딩)도 어렵다. 무엇을 원하는지 매우 열심히 생각해야 한다. 저렴해진 것은 빌딩 블록(구성 요소)일 뿐이다."
roncesvalles는 더 단호하다. "AI와 LLM이 유능한 출력을 빠르게 저렴하게 만들었다는 말은 이미 틀렸다."
acuozzo는 구체적인 반례를 든다. "LLM이 수학에서 아직 증명되지 않은 문제를 도와주는 일을 생각해보라. GPU 코어(CUDA C++)를 작성하는 일도 생각해보라. Gemini 3-DeepThink, GPT-5.4pro, Opus 4.6이 Hopper & Blackwell 아키텍처용 CUDA C++ 코드를 작성하는 성능은 아직 '그저 그렇다'."
비판: 기사의 본질적 문제
meander_water는 "기사가 AI 생성일 뿐만 아니라 수백 명이 복사한 얕은 관점을 재활용하고 있다. 'taste is the new moat'라고 구글에 쳐봐라. 프론트 페이지에 올 자격이 없다"고 비판한다.
heliumtera는 "기사는 유능한 시스템을 쉽게 구현할 수 있다는 것을 설명 없이 절대적 진리로 가정한다. 그 진술에 동의하지 않으면 이 기사에서 추출할 가치가 있는 것이 없다"며 논리적 허점을 지적한다.
흥미로운 관점: 취향 대신 '케어(care)'가 해자
crabsand는 "진짜 해자는 케어(진심)다. 그랬고, 그렇고, 그래질 것이다"라고 단순하지만 강력한 대안을 제시한다.
rickcarlino는 Why the Lucky Stiff의 인용문을 꺼낸다. "당신이 무언가를 만들지 않을 때, 당신은 당신의 능력 대신 취향으로 정의된다." — 취향만 가지고 있는 것과 취향을 실행력으로 전환한 것의 차이를 지적한다.
실용적 관점: 취향의 세 가지 출현 위치
dfxm12는 취향이 세 곳에서 나타난다고 분석한다. "무엇을 주목하는가, 무엇을 거부하는가, 무엇이 잘못된지 얼마나 정확하게 설명할 수 있는가." 그리고 "무엇이 올바른지, 무엇을 수용할지 설명하는 능력도 마찬가지로 중요하다"고 보탠다.
쿼츠 위기(Quartz Crisis) 비유
30minAdayHN은 시계 시장의 Quartz Crisis(1970년대 쿼츠 시계가 스위스 기계 시계를 위협했던 사건)와 비교한다. LLM이 개발자 시장에 큰 영향을 미칠 것이지만, 미래에는 품질·취향·독창성을 중시하는 마이크로 세그먼트가 럭셔리 시계 제조사처럼 틈새 시장을 형성할 것이라고 예측한다. 다만 이 '취향'이 해자가 아니라 틈새 시장이 될 수 있다고 본다.
새로운 시각
취향의 역설: AI가 없었을 때 취향은 숨겨져 있었다
이 기사의 가장 중요한 통찰은 "취향은 늘 직무였고 단지 코드 속에 숨겨져 있었을 뿐"이라는 점이다. AI 이전엔 좋은 엔지니어의 출력을 보면 "이 사람은 실력이 좋구나"라고만 생각했지만, 그 '실력'의 상당 부분은 사실 취향(무엇을 만들고, 어떻게 구조화하고, 언제 충분하다고 판단하는가)이었다. AI가 타이핑을 가져가자 취향이 드러난 것이다.
이는 마치 숨은 변수가 갑자기 관찰 가능해진 것과 같다. AI가 없는 세상은 취향을 측정할 수 없었지만, AI가 있는 세상은 취향이 없는 엔지니어의 한계가 명확하게 드러난다.
30/70 규칙의 함의
Codex 팀의 "30/70 규칙" — 코드의 70%는 AI가 작성하지만 30%는 인간이 직접 작성한다는 것 — 은 단순한 비율이 아니다. 그 30%가 바로 품질 판단이 가장 중요한 핵심 로직이다. 이는 AI 시대의 엔지니어링이 '양'에서 '질'로 이동했음을 의미한다. 30%를 올바르게 선택하는 능력이 70%를 어떻게 처리할지 결정한다.
취향 기르기 vs. 취향 사기
90일 계획은 취향을 '기르는' 방법이지만, 실제로는 취향을 '사는' 방법과도 연결된다. Boris의 스타트업 창업 경험, Emma의 데이터 인프라 리드 경험, Peter의 글로벌 비즈니스 운영 경험 — 이 모두 취향의 '원재료'다. 취향을 기르려면 인접 기술에 투자해야 하고, 이는 곧 경력 선택과 연결된다. 취향은 공짜로 얻는 것이 아니라, 다양한 경험을 통해 '사는' 것이다.
자녀/미래 영향
아인, 석현, 은한에게 주는 시사점
취향은 모든 분야의 핵심 역량이다: 이 기사는 소프트웨어 엔지니어링에 초점을 맞추지만, 취향의 중요성은 모든 분야에 적용된다. 아인이 의사가 된다면 의료 판단의 취향(어떤 진단을 우선시할지, 어떤 치료를 선택할지), 석현과 은한이 어떤 전문가가 되든 '무엇을 해야 하는지 아는 능력'은 AI 시대의 핵심 역량이다.
아이들에게 취향을 기르는 방법:
- 다양한 작품을 접하게 하기 (좋은 디자인, 좋은 글, 좋은 음악)
- "왜 이것이 더 나은지" 설명하게 하기 (단순한 선호가 아닌 이유를 요구하기)
- 실패한 시도도 가치 있게 여기기 (Boris의 20개 프로토타입처럼, 실패는 필연성으로 가는 과정)
- "무엇을 만들지"에 대한 질문을 "어떻게 만들지"보다 먼저 던지기
교육 방향 전환: 현재 교육은 '어떻게 하는지'에 집중하지만, AI 시대에는 '무엇을 해야 하는지'에 대한 판단력이 더 중요하다. 자녀들이 학교에서 배우는 기술적 스킬도 중요하지만, 그보다 더 중요한 것은 문제 선택의 능력, 품질 판단의 능력, 사용자에 대한 공감 능력이다.
의료 AI와의 연결: 의료 분야에서 AI가 진단 보조, 영상 분석, 문서 작성을 담당하게 되면, 의사의 핵심 가치는 '어떤 검사를 시키고, 어떤 치료를 선택하고, 어떤 환자에게 어떤 접근이 적합한지' 판단하는 취향으로 수렴될 것이다. 이는 이 기사가 말하는 Zone 3(품질 판단)과 Zone 4(사용자 공감)에 정확히 해당한다.