취향이 경쟁력이다: AI 시대 엔지니어의 3가지 능력

전제: AI가 바꾼 엔지니어링의 정의

불과 2년 전만 해도:

좋은 엔지니어 = 타이핑 빠른 사람
                = 밤새워 코딩하는 사람  
                = 알고리즘 푸는 속도가 빠른 사람

2026년 현재:

좋은 엔지니어 = 어떤 문제를 풀 가치가 있는지 아는 사람
              = 10가지 해결책 중 최선의 아키텍처를 선택하는 사람
              = 시장이 원할 것을 미리 아는 사람

Claude, GPT-4, Cursor, Windsurf 같은 AI 도구들이 기본 코딩을 자동화하면서, "무엇을 만들 것인가"의 판단이 모든 가치의 중심이 되었다.

왜 이런 변화가 일어났나?

과거 (코딩이 병목)

아이디어 → 기술 아키텍처 선택 → [시간 소비] 코딩 → [시간 소비] 테스트 → 배포

지난 10년간의 엔지니어 교육은 [시간 소비] 부분을 줄이기에 집중했다:

• 더 빠른 프레임워크
• 더 효율적인 알고리즘
• 더 자동화된 배포

현재 (판단이 병목)

아이디어 → [중요] 기술 아키텍처 선택 ← 취향이 결정함
         ↓
      AI가 자동 코딩 (1시간)
         ↓
      [중요] 품질 판단 & 개선 ← 취향이 결정함

이제 "30분 만에 코딩하는 것"이 아니라 **"어떤 것을 1시간 들여 만들 가치가 있는지"**을 아는 것이 진정한 경쟁력이다.

취향이란 무엇인가?

취향은 단순한 "선호도"가 아니다. 체계화된 3가지 능력의 통합이다.

1. 인식(Recognition): "이게 더 낫다"를 직관적으로 판단

두 개의 구현을 놓고 비교하는 능력.

예시 1: 아키텍처 인식

# 방식 A: Monolithic
class UserService:
    def get_user(self, id):
        ...
    def validate_email(self):
        ...
    def send_notification(self):
        ...

vs

# 방식 B: Microservices
UserService(get_user)
EmailService(validate_email)
NotificationService(send_notification)

인식을 갖춘 엔지니어:

"우리 회사가 초기 스타트업이면 A, 
 수천만 사용자면 B야. 
 지금은 A인데 미리 B로 가면 낭비야."

인식이 없는 엔지니어:

"마이크로서비스는 최신 기술이니까 B를 써야 해."

예시 2: UI 인식

<!-- 이 두 버튼 중 어느 것이 더 나은 UX? -->
 
<!-- A: 명확한 레이블 -->
<button>지금 구매하기 (5분 남음)</button>
 
<!-- B: 미니멀 디자인 -->
<button>구매 →</button>

인식을 갖춘 엔지니어:

• 사용자 데이터를 보고 어느 것이 더 클릭을 많이 받는지 안다
• 맥락에 따라 A 또는 B를 선택한다
• 왜 그 선택이 낫다고 생각하는지 말할 수 있다

2. 나침반(Compass): "다음에 뭐 할까"를 아는 능력

현재 상황에서 다음으로 최적의 액션이 무엇인지 아는 것.

예시 1: 기술 스택 선택

상황: 날씨 API 프로젝트, 3명, 6개월, 모바일 중심

가능한 선택지:
1. React Native (웹+모바일 동시 지원)
2. Flutter (성능 최고)
3. 네이티브 (iOS + Android 각각)

나침반이 있는 엔지니어:

"데이터 보니까 우리 사용자 대부분 iOS야. 
 6개월이면 네이티브로 완성도 높은 앱을 만들 수 있어. 
 지금 선택해야 할 일은 1번이 아니라 
 'iOS 네이티브 학습 + 기초 구현'이야."

나침반이 없는 엔지니어:

"요즘 트렌드는 React Native니까 1번을 하자."

예시 2: 성능 최적화 우선순위

병목이 3개 발견됨:
1. 데이터베이스 쿼리 (0.5초 × 1000회 = 500초)
2. 이미지 로딩 (각 100ms × 10개 = 1초)  
3. 자바스크립트 번들 크기 (2MB, 로딩 500ms)

나침반:

"가장 큰 개선 효과는 1번. 
 N+1 쿼리 수정이면 500ms 절약. 
 그 다음은 3번 (번들 최적화).
 2번은 나중에 봐도 된다."

3. 비전(Vision): "2년 뒤 중요할 것"을 아는 능력

미래를 정확하게 예측할 순 없지만, 통계적으로 중요할 패턴을 찾는 능력.

예시 1: 기술 선택의 미래성

2024년 기준:

선택 A: 점유율 5% (마이너 프레임워크)
선택 B: 점유율 40% (메이저 프레임워크)

보수적 선택: B

비전을 가진 선택:
- 만약 A가 2% 성장률 vs B가 -3% 감소 추세라면?
- 3년 뒤엔 A가 10%, B가 30%가 될 것
- A를 선택해도 비용 대비 효율이 좋다

예시 2: 시장의 미래 니즈

2025년 초:

현재 문제: 기업들이 "AI 에이전트"를 원한다고 주장
실제 문제: 대부분은 "AI 에이전트 관리"를 못한다

비전을 가진 엔지니어의 판단:
"지금 AI 에이전트 프레임워크를 만들기보다, 
 18개월 뒤 필수 기술은 
 '에이전트 메모리 관리' + '멀티 에이전트 협동'이야. 
 지금 그 기술을 연구해야 한다."

취향 개발: 90일 실천 계획

1개월: 우수 사례 분석으로 패턴 인식

목표: 각 분야에서 "최고 수준"과 "평범한 수준"의 차이를 직관적으로 파악

주간 계획

1주차: 아키텍처

분석 대상: 10개 회사의 기술 아키텍처
- Airbnb (스케일: 수백만 동시 사용자)
- Figma (협업 시스템)
- Netflix (스트리밍 플랫폼)
- Stripe (결제 시스템)
- ...

각각 분석:
- 왜 이런 기술 스택을 선택했는가?
- 초기에는 다를 수 있으니까, 
  현재 아키텍처의 진화 과정을 본다
- 공통 패턴: 스케일링 시점별로 기술 전환

2주차: 코드 스타일

분석 대상: 10개 유명 오픈소스 프로젝트
- CPython (성능 최우선)
- Flask (단순성 최우선)
- Django (개발 속도 최우선)
- Kubernetes (복잡도 관리)
- ...

각각 분석:
- 변수명, 함수명 규칙이 어떻게 다른가?
- 에러 처리 방식이 어떻게 다른가?
- 테스트 전략이 어떻게 다른가?

3주차: UX/디자인

분석 대상: 경쟁 제품 쌍 10개
- Slack vs Microsoft Teams
- Figma vs Adobe XD
- Vercel vs Netlify
- ...

각각 분석:
- 온보딩 과정은 어떤 철학인가?
- 에러 메시지는 어떻게 다른가?
- 가격 페이지는 어떤 심리 전략인가?

4주차: 사업 전략

분석 대상: 성공과 실패 케이스 각 5개
- 성공: Airbnb 초기 그로스 전략
       Stripe의 개발자 경험 전략
       Notion의 커뮤니티 전략
- 실패: 좋은 제품인데 죽은 회사들
       
각각 분석:
- "좋은 결정"은 어떤 제약 조건에서 나왔는가?
- 왜 다른 길을 선택하지 않았는가?
- 내 회사의 상황과 다른 점은?

2개월: 비교 분석으로 판단 능력 개발

목표: 유사한 상황에서 여러 선택지를 두고 최선을 판단

주간 계획

1주차: 아키텍처 선택 비교

시나리오: "검색 엔진 만들기"

선택지:
A. Elasticsearch (완성도)
B. Meilisearch (단순성)
C. PostgreSQL Full-text (비용)
D. 자체 구현 (커스텀)

분석:
- 각 선택의 트레이드오프?
- 회사 규모별 최적 선택?
- 3년 뒤 마이그레이션 비용?

연습: 자신의 회사라면? 다른 회사라면?

2주차: 기술 스택 선택 비교

시나리오: "실시간 협업 도구 만들기"

선택지:
A. Node.js + Socket.io (친숙함)
B. Rust + Tokio (성능)
C. Go + gRPC (균형)
D. Erlang (신뢰성)

분석:
- 각 팀의 스킬셋이 다르면?
- 예상 사용자 규모가 다르면?
- 출시 기한이 긴급하면?

3주차: 코드 리팩토링 판단

상황: "3년된 레거시 코드가 있다"

선택지:
A. 유지보수만 (비용 최소)
B. 부분 리팩토링 (균형)
C. 완전 재작성 (근본 해결)

분석:
- 기술 부채가 얼마나 큰가?
- 팀의 모랄은?
- 비즈니스 긴급도는?
- 각 선택의 예상 결과?

4주차: 인력 배분 판단

상황: "팀 5명, 3개 프로젝트"

선택지:
A. 1명, 2명, 2명 배분
B. 2명, 2명, 1명 배분
C. 외부 개발사에 1개 아웃소싱
D. 1개 프로젝트 미룸

분석:
- 각 프로젝트의 우선도?
- 팀원의 성장 기회?
- 리스크는?
- 장기 팀 구성은?

3개월: 취향을 시스템에 적용하고 공유

목표: 자신의 판단 능력을 체계화하고, 팀과 공유

주간 계획

1주차: 자신의 판단 기준 문서화

# 아키텍처 선택 프레임워크
 
## 상황별 최적 선택
 
### 스타트업 초기 (< 1M DAU)
- 웹프레임워크: Django / Rails / Next.js
  이유: 개발 속도 최우선
  
### 성장 단계 (1M ~ 10M DAU)
- 데이터베이스: PostgreSQL + Cache Layer
  이유: 성능과 관리의 균형
 
### 대규모 (> 10M DAU)
- 마이크로서비스 고려
  이유: 팀 확장, 독립적 배포 필요

2주차: 팀 내 논의 주도

주간 기술 회의:
"다음 프로젝트의 기술 스택을 선택하자"

당신의 역할:
1. 선택지별 트레이드오프 명확히
2. 다른 의견의 논리적 배경 이해
3. 최종 판단 기준 제시
4. "왜 이 선택이 최선인가" 설명

결과: 팀의 취향 수준 상향평준화

3주차: 문화 변화 주도

당신이 만드는 문화:
"우리는 항상 '최고의' 기술을 쓰지 않는다.
 우리는 항상 '최적의' 기술을 선택한다.
 그리고 그 이유를 설명할 수 있다."

팀의 변화:
- 의사결정이 빨라짐
- 기술 선택의 후회가 줄어듦
- 주니어들의 학습 속도 증가

4주차: 자신의 비전 공유

다음 분기/연간 계획:
"지금의 기술 부채, 
 조직 규모, 
 시장 상황을 고려할 때,
 18개월 뒤 우리 회사에 필요한 
 기술 역량은 이것이다. 
 지금부터 이렇게 준비하자."

효과:
- 팀의 로드맵이 명확해짐
- 주니어들이 학습할 방향이 명확해짐
- 경영진의 신뢰 증가

취향의 실제 영향: 30배 효율

코드 라인 수로 측정할 수 없는 차이

평범한 엔지니어:
- "완성"에만 집중 → 100% 기능 구현
- 시간: 10일 + 불안감 + 버그 + 유지보수 비용

취향 있는 엔지니어:
- "필요충분"에 집중 → 80% 기능 (나머지 20%는 불필요)
- 시간: 3일 + 확신 + 버그 적음 + 유지보수 쉬움
- 추가 효과: "뭘 안 할 것인가" 결정으로 
            팀의 다른 프로젝트 지원 가능

실제 영향:
1명이 평범한 수준으로 10일 걸린 일을
3일에 끝내고, 추가로 다른 팀원 2명을 도울 수 있다면?

수식: 3/10 = 0.3 (기간), 
      1 + (2명 × 0.5 도움) = 2명의 가치
      → 약 2 ~ 3배 효율

그런데 좀 더 복잡한 조직에서는:
- 기술 선택으로 6개월 마이그레이션 비용 절약
- "무엇을 안 할 것인가"의 판단으로 팀 몰입도 증가
- 비전으로 인한 사전 준비로 위기 대응 시간 50% 단축

누적 효과 = 30배

실제 사례

사례 1: 아키텍처 선택
평범: "마이크로서비스가 유행이니까" → 구현 3개월
취향: "우린 아직 모놀리식이 낫지" → 구현 1개월 + 
      다른 기능 2개월 = 더 많이 만듦

사례 2: 기능 선택
평범: 모든 기능 구현 (사용률 30%)
취향: 핵심 기능만 구현 (사용률 80%)
      → 만족도 높음 + 유지보수 쉬움

사례 3: 팀 리드십
평난: "엔지니어니까 코딩만" → 기술 부채 증가
취향: "팀의 미래 역량" 투자 → 
      2년 뒤 자동화율 3배 증가

결론: 취향은 후천적이다

AI가 코딩을 자동화하면서, 엔지니어의 경쟁력은 **"얼마나 빠르게 타이핑하는가"**에서 **"무엇을 만들 가치가 있는가를 아는가"**로 완전히 이동했다.

이 능력을 "취향"이라 부르고, 취향은:

1. 인식: 두 구현을 보고 어느 것이 더 나은지 판단
2. 나침반: 현재 상황에서 다음 액션을 최적으로 선택
3. 비전: 2년 뒤 중요할 것을 미리 준비

이 3가지를 체계적으로 단련할 수 있다.

시작하는 방법

이번 주:
- 당신의 분야에서 "최고 수준"의 사례 5개 읽기
- 각각에서 "왜 이 선택인가?" 기록하기

다음 주:
- 자신의 현재 프로젝트에서 한 선택을 재평가
- "더 나은 선택이 있었나?" 묻기
- 그 답을 문서화하기

그 다음 달:
- 팀에게 공유
- 함께 "최적 선택"의 문화 만들기

30배의 엔지니어는 하늘에서 떨어지지 않는다.

취향을 키우는 엔지니어가 될 수 있다.

참고 자료

• GeekNews: "취향(taste)을 갖춘 30배 AI 엔지니어가 되는 법"
• Paul Graham의 "Taste for Makers" 에세이
• Stripe의 개발자 경험 철학