💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

들어가며 — 같은 주에 올라온 두 개의 글

2026년 5월 말, 개발자 커뮤니티의 타임라인에 흥미로운 우연이 있었습니다. Stack Overflow 블로그에 "Artisans and builders"라는 글이 올라왔고, 거의 같은 시기에 한 개인 블로그의 "LLMs are eroding my software engineering career and I do not know what to do"라는 글이 Hacker News 프론트페이지를 점령하며 GeekNews에서도 뜨겁게 토론되었습니다.

두 글은 같은 현상을 정반대의 온도로 다룹니다. 전자는 AI 시대의 개발을 장인(artisan)과 빌더(builder)라는 두 정체성으로 구분하며 비교적 차분하게 미래를 전망합니다. 후자는 10년 넘게 쌓아온 기술이 LLM에 의해 하루아침에 평가절하되는 것 같다는, 한 시니어 개발자의 절절한 불안 고백입니다.

흥미로운 것은 HN 댓글란의 반응이었습니다. "나도 정확히 같은 기분이다"라는 공감과 "당신의 가치는 코드 타이핑이 아니었다"라는 반박이 수백 개씩 쌓였습니다. 이 글에서는 두 글을 축으로 AI 시대 개발자 정체성을 재정의하고, 불안을 실행 가능한 전략으로 바꾸는 방법을 정리해 보겠습니다.

두 글의 논지 — 차분한 분류와 절박한 고백

Artisans and builders의 논지

Stack Overflow 블로그 글의 핵심 구분은 이렇습니다.

- 빌더(builder)는 결과물을 만드는 것이 목적입니다. 코드는 수단이고, 동작하는 제품이 목표입니다. AI 도구는 빌더에게 역사상 최고의 선물입니다.

- 장인(artisan)은 만드는 과정 자체와 만듦새의 품질에 가치를 둡니다. 시스템을 깊이 이해하고, 우아한 해법을 추구하며, 도구의 내부까지 파고듭니다.

저자의 전망은 양극화입니다. AI는 빌더의 진입 장벽을 사실상 제거했고, 동시에 AI가 만든 방대한 결과물이 고장날 때 그것을 고칠 수 있는 장인의 희소가치를 끌어올렸다는 것입니다. 위험한 곳은 중간 지대입니다. 장인의 깊이도 빌더의 속도도 없는 포지션이 가장 먼저 압박을 받습니다.

LLMs are eroding my career의 논지

반대편의 글은 이론이 아니라 감정에서 출발합니다. 저자는 대략 이렇게 말합니다.

- 나는 코드를 잘 쓰는 것으로 정체성과 자존감을 쌓아온 사람이다.

- 이제 내가 하루 걸려 쓰던 코드를 LLM이 10분 만에 쓴다. 내 차별점이 무엇인지 모르겠다.

- 회사는 AI 도구 사용을 사실상 의무화했고, 나는 내 기술이 녹는 것을 실시간으로 지켜보는 기분이다.

- 더 배우라고들 하지만, 배우는 속도보다 도구가 발전하는 속도가 빠르다. 어디로 도망쳐야 하는지 모르겠다.

이 글이 폭발적으로 공유된 이유는 명확합니다. 많은 개발자가 입 밖에 내지 못하던 감정을 정확히 언어화했기 때문입니다. 2026년 현재 Claude Code나 Codex 같은 에이전트가 수 시간짜리 작업을 자율 수행하는 환경에서, 이 불안은 소수의 것이 아닙니다.

두 글을 나란히 놓고 보면

| 비교 항목 | Artisans and builders | LLMs are eroding my career |

| --- | --- | --- |

| 관점 | 산업 구조의 조감도 | 개인의 1인칭 체험 |

| 온도 | 분석적, 차분함 | 절박함, 상실감 |

| 핵심 주장 | 정체성이 양극화된다 | 기존 정체성이 무너지고 있다 |

| AI에 대한 태도 | 도구이자 구조 변화의 동력 | 자기 가치를 잠식하는 존재 |

| 제시하는 해법 | 장인 또는 빌더로의 정렬 | 해법 없음 (질문으로 끝남) |

| 독자에게 주는 것 | 지도 | 공감 |

흥미로운 점은 두 글이 사실 인식에서는 거의 일치한다는 것입니다. 코드 생산의 가치가 급락하고 있다는 진단은 동일합니다. 갈라지는 곳은 그 다음입니다. 한쪽은 가치가 이동한 곳을 가리키고, 다른 한쪽은 이동을 따라갈 수 있을지를 두려워합니다. 이 글의 나머지는 그 간극, 즉 지도와 공감 사이를 잇는 실행의 문제를 다룹니다.

무엇이 실제로 변했나 — 민주화와 재조명

두 글을 겹쳐 놓으면 변화의 실체가 보입니다. 변한 것은 개발자의 가치가 아니라, 가치의 분포입니다.

AI 이전의 가치 곡선 AI 이후의 가치 곡선

가치 | ____ 가치 | __

| ___/ \___ | / \

| / \ |/ \

| _/ \_ | \____ ___

|/ \ | \______/

+---------------------> +--------------------->

입문 중간 숙련 입문 중간 숙련(장인)

완만한 능력-가치 비례 중간 지대 함몰, 양끝 상승

빌더의 민주화

긍정적인 변화부터 봅시다. 이제 누구나 만들 수 있습니다. 기획자가 사내 도구를 직접 만들고, 디자이너가 프로토타입을 코드로 검증하고, 1인 창업자가 외주 없이 제품을 출시합니다. 2026년의 해커톤 풍경은 상징적입니다. 하드웨어 해커톤이 부활하고, 참가자의 절반이 비전공자이며, 데모의 완성도는 5년 전 시드 스타트업 수준입니다.

이것은 위협이기 이전에 시장의 확장입니다. 소프트웨어가 만들어지는 총량이 폭증하고 있고, 만들어진 소프트웨어는 언젠가 반드시 고장나며, 통합되어야 하고, 확장되어야 합니다.

장인 가치의 재조명

바로 그 지점에서 장인의 가치가 재조명됩니다. AI가 생성한 코드의 양이 늘어날수록 다음 능력의 희소가치가 올라갑니다.

1. 깊은 디버깅 능력. AI는 자신이 만든 코드의 장애를 설명하지 못하는 경우가 많습니다. 분산 시스템의 타이밍 이슈, 메모리 누수, 드라이버 레벨의 문제는 여전히 시스템을 계층 전체로 이해하는 사람이 풉니다.

2. 시스템 수준의 이해. 개별 코드는 AI가 쓰지만, 서비스 경계를 어떻게 자를지, 데이터 일관성을 어디서 보장할지는 시스템 전체를 머리에 넣은 사람의 일입니다.

3. 책임지는 능력. 규제 산업에서 이 코드가 왜 안전한가를 감사 앞에서 설명하고 서명하는 것은 인간의 일로 남아 있습니다. 2026년 6월 npm 공급망 공격이 Red Hat Cloud Services까지 침투한 사건은, 생성 속도가 아니라 검증 깊이가 병목임을 다시 보여줬습니다.

2024-2026, 인식 변화의 타임라인

이 논쟁이 갑자기 나타난 것이 아니라는 점도 짚어 둘 필요가 있습니다. 커뮤니티 정서의 변화를 거칠게 시계열로 그리면 다음과 같습니다.

2024 2025 상반기 2025 하반기 2026 상반기

| | | |

"자동완성이 "에이전트가 "팀 단위 도입, "장시간 자율 작업,

좋아졌다" PR을 보낸다" 직무 재편 시작" 정체성 논쟁 본격화"

| | | |

신기함 -> 생산성 흥분 -> 조직적 갈등 -> 실존적 질문

(리뷰 부채, (장인 vs 빌더,

주니어 채용 축소) 커리어 침식 고백)

2026년의 특징은 논쟁의 층위가 도구에서 정체성으로 내려왔다는 점입니다. 더 이상 어느 도구가 좋은가를 묻지 않습니다. 도구는 전제가 되었고, 질문은 그래서 나는 누구인가로 바뀌었습니다. 두 글이 같은 주에 폭발적으로 읽힌 것은 우연이 아니라, 커뮤니티 전체가 이 질문에 도달했다는 신호로 읽는 것이 맞을 것입니다.

시나리오 — 10년차 결제 백엔드 개발자의 경우

추상론을 피하기 위해 구체적인 인물을 세워 봅시다. 가상의 인물 K는 10년차 백엔드 개발자로, 결제와 정산 시스템을 주로 만들어 왔습니다. K의 불안은 명확합니다. 결제 API 연동 코드, 정산 배치, 웹훅 처리 같은 K의 주특기를 이제 에이전트가 한 시간 만에 만들어 냅니다.

하지만 K의 자산을 분해해 보면 이야기가 달라집니다.

| K의 자산 | AI 대체 가능성 | 이유 |

| --- | --- | --- |

| API 연동 코드 작성 | 높음 | 패턴화된 작업, 문서 기반 생성 가능 |

| 정산 배치 구현 | 높음 | 명세만 정확하면 생성 가능 |

| 이중 지불 엣지 케이스 지식 | 낮음 | 장애를 직접 겪어야 쌓이는 암묵지 |

| PG사별 정산 차이와 함정 | 낮음 | 문서화되지 않은 도메인 지식 |

| 금융 규제 대응 경험 | 낮음 | 책임과 신뢰가 결부된 영역 |

| 장애 시 의사결정 | 매우 낮음 | 맥락, 권한, 책임의 결합 |

K가 위협받는 것은 자산의 위쪽 두 줄뿐입니다. 그런데 K는 지난 10년간 자기 가치를 위쪽 두 줄로 설명해 왔기 때문에 전부를 잃는 기분이 드는 것입니다. 재정의는 이렇게 됩니다. K는 코드를 빨리 쓰는 사람이 아니라, 돈이 새지 않는 시스템이 무엇인지 아는 사람입니다. 그리고 에이전트가 결제 코드를 한 시간에 만들어 내는 세상에서는, 그 코드들이 돈을 새게 만들지 않는지 판별할 수 있는 사람의 가치가 오히려 올라갑니다.

K의 전략은 도망이 아니라 재배치입니다. 도메인 지식을 AI 도구와 결합해, 결제 시스템을 검증하는 evals를 만들고, 에이전트용 컨텍스트 문서로 팀의 결제 코드 품질 기준을 명문화하고, AI가 양산하는 결제 연동 코드의 최종 게이트키퍼가 되는 것입니다.

K의 실제 작업물 — 도메인 지식을 코드로 옮기기

K가 하이브리드 전략을 실행한다면 무엇을 만들게 될까요. 첫 번째 산출물은 결제 도메인의 암묵지를 에이전트가 읽을 수 있는 컨텍스트 문서로 옮기는 것입니다.

PAYMENTS.md — 결제 모듈 작업 시 에이전트 필독 규칙

절대 규칙

- 모든 결제 요청은 멱등 키를 받는다. 멱등 키 없는 결제 API는 작성 금지.

- 금액 계산에 부동소수점 사용 금지. 통화 최소 단위의 정수로만 계산.

- 외부 PG 호출은 타임아웃 5초, 재시도는 멱등 보장 구간에서만.

- 환불은 원거래 상태 검증 후에만. 상태 머신 다이어그램 참조.

자주 발생하는 함정 (실제 장애 이력 기반)

- PG사 A는 웹훅을 최대 3회 중복 발송한다. 수신 측 멱등 처리 필수.

- PG사 B의 정산 금액은 부가세 포함, A는 미포함. 비교 로직 주의.

- 취소 API는 영업일 기준 마감 시각 이후 호출 시 다음날 처리된다.

상태 전이 (이 외의 전이는 모두 버그)

READY -> PAID -> (CANCELLED | REFUND_PENDING -> REFUNDED)

두 번째 산출물은 에이전트가 만든 결제 코드를 기계적으로 검증하는 eval입니다.

payment_evals.py — AI 생성 결제 코드의 자동 검증

CRITICAL_PATTERNS = [

(r"float\(.*(amount|price|fee)", "금액에 float 사용 - 정수 최소단위로"),

(r"requests\.(post|get)\((?![^)]*timeout)", "외부 호출에 timeout 없음"),

(r"def\s+(charge|pay|refund)\w*\((?![^)]*idempotency)",

"결제 함수에 멱등 키 파라미터 없음"),

]

def eval_payment_code(source: str) -> list[str]:

findings = []

for pattern, message in CRITICAL_PATTERNS:

if re.search(pattern, source):

findings.append(message)

return findings

def test_no_critical_findings():

for path in changed_payment_files():

assert eval_payment_code(read(path)) == []

이 두 파일이 상징하는 바가 중요합니다. K의 10년이 K의 머릿속에만 있을 때는 K가 코드를 직접 쓸 때만 가치가 발휘됐습니다. 문서와 eval로 옮겨진 뒤에는, 에이전트가 코드를 100배 생산해도 K의 기준이 모든 코드에 적용됩니다. 이것이 도메인 전문가의 레버리지 전환입니다.

나는 어디에 있나 — 자가 진단 체크리스트

전략을 고르기 전에 현재 위치를 진단해 봅시다. 다음 항목에 예/아니오로 답합니다.

[장인 축]

1. 최근 1년 안에, 남들이 포기한 장애의 근본 원인을 찾아낸 적이 있다

2. 주력 스택의 내부 구현(프레임워크 소스, DB 엔진 동작)을 설명할 수 있다

3. AI가 생성한 코드에서 동작하지만 위험한 부분을 자주 발견한다

4. 성능 문제를 추측이 아니라 계측으로 접근한다

[빌더 축]

5. 아이디어를 일주일 안에 동작하는 데모로 만들 수 있다

6. 기술 선택 시 최신성보다 출시 속도를 우선한 적이 많다

7. 코드 품질보다 사용자 피드백 획득을 먼저 생각한다

8. AI 에이전트에게 작업을 위임하는 나만의 워크플로가 있다

[도메인 축]

9. 특정 산업/도메인의 장애 사례를 문서 없이 열거할 수 있다

10. 그 도메인의 규제나 관행 때문에 기술적 정답이 달라지는 경우를 안다

11. 도메인 전문가(비개발자)와 그들의 언어로 대화할 수 있다

12. 내 도메인 지식을 찾는 사람이 사내외에 존재한다

각 축에서 3개 이상이면 그 축이 강점입니다. 장인 축만 강하면 심화 경로, 빌더 축만 강하면 확장 경로가 자연스럽고, 도메인 축이 3개 이상이라면 하이브리드 경로의 원자재를 이미 보유한 것입니다. 세 축 모두 2개 미만이라면 그것이 바로 두 글이 경고하는 중간 지대이며, 어느 축이든 하나를 정해 의식적으로 투자를 시작해야 한다는 신호입니다.

커리어 무브 옵션 비교 — 세 가지 경로

K 같은 상황에서 선택할 수 있는 경로를 세 가지로 정리하면 다음과 같습니다.

| --- | --- | --- | --- |

세 경로 모두 유효하지만, 2026년 현재 시장에서 공급이 가장 부족한 것은 세 번째입니다. 도메인을 아는 사람은 많고 AI 도구를 쓰는 사람도 많지만, 도메인 기준으로 AI 산출물을 검증하는 체계를 만들 수 있는 사람은 드뭅니다.

피해야 할 것은 선택하지 않는 것입니다. 장인의 깊이도, 빌더의 속도도, 하이브리드의 결합도 없이 어제와 같은 일을 하는 중간 지대가 두 글이 공통으로 지목하는 위험 지역입니다.

분기별 실천 플랜 — 1년 로드맵

방향을 정했다면 실행입니다. 하이브리드 경로를 예시로, 업무 외 주당 4시간 투자를 가정한 4분기 플랜입니다.

1분기 — 진단과 기반

- 자기 자산 인벤토리 작성: 위의 K처럼 자기 기술을 AI 대체 가능성 기준으로 분해한 표를 만듭니다.

- AI 에이전트 워크플로 하나를 업무에 정착: 코드 리뷰 보조, 테스트 생성 등 작은 것부터.

- 자기 도메인의 암묵지 문서화 시작: 장애 사례, 엣지 케이스, 함정을 주 1건씩 기록합니다.

2분기 — 결합 실험

- 도메인 지식을 에이전트 컨텍스트로 변환: 1분기에 기록한 문서를 CLAUDE.md나 AGENTS.md 형식으로 정리해 에이전트에 주입하고 산출물 품질 변화를 관찰합니다.

- 도메인 특화 eval 첫 작성: 자기 분야의 치명적 실수(결제라면 멱등성 위반, 금액 반올림 오류)를 잡는 검증 스크립트를 만듭니다.

- 사내 공유 1회: 작게라도 발표해 하이브리드 포지션을 가시화합니다.

3분기 — 레버리지 확대

- 팀 단위 도입: 개인 워크플로를 팀 표준으로 승격시키는 제안을 합니다.

- 외부 발신 시작: 블로그 글 2편 또는 밋업 발표 1회. 시장에서의 식별 가능성을 만듭니다.

- 깊이 보강: 자기 도메인의 인접 기반 기술(결제라면 분산 트랜잭션, 멱등성 설계) 한 가지를 체계적으로 학습합니다.

4분기 — 포지션 정리

- 성과 정량화: 에이전트 도입 전후의 리뷰 시간, 결함률, 처리량 변화를 숫자로 정리합니다.

- 커리어 문서 갱신: 이력서와 포트폴리오를 코드 작성자가 아니라 시스템 품질 보증자 관점으로 다시 씁니다.

- 다음 해 방향 결정: 1년의 데이터를 근거로 심화, 확장, 이동 중 하나를 선택합니다.

핵심 원칙은 두 가지입니다. 첫째, 모든 분기에 외부에서 확인 가능한 산출물(문서, 발표, 숫자)을 남깁니다. 둘째, 도구 학습 자체를 목표로 삼지 않습니다. 도구는 분기마다 바뀌지만, 도메인 지식과 검증 체계는 누적됩니다.

분기 플랜을 주간 루틴으로 환산하면 다음과 같습니다.

| 요일 | 활동 | 시간 | 누적되는 자산 |

| --- | --- | --- | --- |

| 월 | 도메인 암묵지 1건 문서화 | 30분 | 컨텍스트 문서 |

| 수 | AI 산출물 정밀 리뷰 1건 | 1시간 | 평가 능력, eval 후보 |

| 금 | eval 또는 자동화 스크립트 개선 | 1시간 | 검증 체계 |

| 주말 | 깊이 학습 (기반 기술 1주제) | 1.5시간 | 장인 축 역량 |

주당 4시간이며, 전부 업무와 직결되므로 상당 부분은 업무 시간 안에서 소화할 수 있습니다. 중요한 것은 4시간의 양이 아니라, 매주 네 종류의 자산이 모두 1씩 증가하는 구조입니다.

이력서와 면접 — 재정의된 가치를 증명하는 법

방향을 바꿨다면 시장에 보여주는 언어도 바꿔야 합니다. 2026년 채용 시장에서 실제로 달라진 점을 반영한 작성법입니다.

먼저, 산출량 서술에서 판단 서술로 옮깁니다.

이전 방식 (생산 중심):

- 결제 모듈 신규 개발 및 PG 3사 연동 구현

- 정산 배치 시스템 개발, 일 500만 건 처리

2026년 방식 (판단과 레버리지 중심):

- 결제 도메인 검증 체계(evals 12종, 컨텍스트 문서) 구축으로

AI 생성 코드의 결제 관련 결함 분기당 9건 사전 차단

- 에이전트 협업 워크플로 설계로 팀 결제 기능 리드타임 60% 단축,

동시에 장애율 유지 (도입 전후 데이터 보유)

- PG 정산 불일치 장애 5건의 근본 원인 분석 및 재발 방지 설계

면접에서도 질문의 축이 이동하고 있습니다. 코딩 테스트의 비중이 줄어든 자리에 다음 유형이 들어오고 있습니다.

- AI가 생성한 코드 뭉치를 주고 결함을 찾게 하는 리뷰 면접

- 모호한 요구사항을 스펙으로 정리하게 하는 명세 면접

- 장애 시나리오를 주고 대응을 지휘하게 하는 시뮬레이션 면접

세 유형 모두 위의 주간 루틴이 그대로 연습이 된다는 점에 주목할 필요가 있습니다. 준비와 실무가 분리되지 않는 것이 이 전환기의 그나마 다행스러운 점입니다.

조직 관점 — 시니어 가치의 재평가

개인의 문제만은 아닙니다. 조직도 같은 질문에 직면해 있습니다. 주니어가 에이전트와 함께 시니어 분량의 코드를 생산할 때, 시니어의 연봉은 무엇에 대한 대가인가.

선진적인 조직들이 도달하고 있는 답은 시니어 역할의 재정의입니다.

전통적 시니어 2026년형 시니어

- 가장 어려운 코드를 직접 작성 - 가장 어려운 결정을 내림

- 리뷰로 품질을 지킴 - 품질 기준을 evals와 컨텍스트

- 주니어를 1:1 멘토링 문서로 명문화해 자동화

- 장애의 최종 해결사 - 에이전트 군단의 작업 설계자

- 여전히 장애의 최종 해결사

주목할 점은 마지막 줄입니다. 장애 대응만은 변하지 않았습니다. AI가 만든 시스템이 무너질 때 복구를 지휘할 수 있는 사람의 가치는 오히려 급등했습니다. 조직이 시니어를 평가하는 축은 산출량에서 두 가지로 이동하고 있습니다. 첫째, 이 사람이 없으면 풀리지 않는 장애가 있는가. 둘째, 이 사람의 판단 기준이 팀의 시스템(리뷰 규칙, evals, 컨텍스트 문서)으로 얼마나 이전되어 있는가.

역설적이지만 두 번째 축은 자신을 대체 가능하게 만드는 작업입니다. 그러나 자신의 판단을 시스템화할 수 있는 사람은 다음 단계의 더 어려운 판단으로 올라가게 되고, 그것이 시니어 커리어의 새로운 사다리가 되고 있습니다.

조직이 실제로 도입하고 있는 제도 변화도 참고할 만합니다.

| 제도 | 내용 | 의도 |

| --- | --- | --- |

| 리뷰 게이트 직책 | AI 생성 코드의 머지 승인 권한을 명시적 역할로 | 검증 책임의 명확화 |

| 컨텍스트 문서 오너십 | CLAUDE.md 류 문서를 코드와 동급의 자산으로 관리 | 암묵지의 시스템화 |

| 장애 지휘 로테이션 | 시니어의 인시던트 커맨더 역량을 공식 평가 항목으로 | 대체 불가 역량의 가시화 |

| 에이전트 예산제 | 팀별 AI 사용량을 예산으로 관리, ROI 측정 | 무분별한 생성의 억제 |

이 제도들의 공통점은 생산이 아니라 검증과 책임에 직책과 보상을 붙이고 있다는 점입니다. 개인의 커리어 전략과 조직의 제도 변화가 같은 방향을 가리키고 있는 셈입니다.

멘탈 관리 — 불안과 함께 일하는 법

bearblog 글이 던진 진짜 주제는 기술이 아니라 감정입니다. 몇 가지 실질적인 조언을 정리합니다.

1. 불안의 해상도를 높입니다. 막연한 "대체될 것 같다"를 구체적인 목록으로 바꿉니다. 위 K의 표처럼 적어 보면, 대체되는 것은 대부분 기술의 일부이지 전부가 아닙니다. 불안은 해상도가 낮을 때 가장 큽니다.

2. 비교 대상을 바꿉니다. 에이전트의 생산 속도와 자신을 비교하는 것은 굴착기와 삽질 속도를 겨루는 일입니다. 비교는 같은 도구를 가진 1년 전의 자신과 합니다.

3. 정체성을 행위가 아니라 가치에 둡니다. 나는 코드를 쓰는 사람이 아니라 문제를 풀고 시스템을 책임지는 사람이라는 재정의는 심리적 방어가 아니라 사실에 더 가까운 기술입니다.

4. 손을 완전히 떼지 않습니다. 주기적으로 에이전트 없이 코딩하는 시간을 따로 둡니다. 기술 유지 목적도 있지만, 만드는 즐거움이라는 이 직업의 원천 연료를 지키는 일이기도 합니다.

5. 말할 곳을 만듭니다. bearblog 글에 수천 명이 공감했다는 사실 자체가 메시지입니다. 이 불안은 보편적이며, 입 밖에 내는 순간 절반은 가벼워집니다.

불안이 일상 기능을 침해하는 수준이라면, 직업적 조언의 범위를 넘어선 것이므로 전문가의 도움을 받는 것이 옳습니다. 그 전 단계에서 쓸 수 있는 간단한 주간 점검표를 덧붙입니다.

주간 멘탈 점검 (금요일 5분)

- 이번 주 내가 내린 판단 중 AI가 못 했을 것 하나: ______

- 이번 주 새로 배운 것 하나: ______

- 이번 주 누군가에게 도움이 된 일 하나: ______

- 다음 주에 버릴 일 하나 (에이전트에 위임): ______

네 칸이 매주 채워진다면, 침식되고 있는 것은 커리어가 아니라 오래된 자기 정의일 뿐입니다.

비판적 시각 — 공포 마케팅을 경계하라

마지막으로, 이 담론 전체에 걸어야 할 필터가 있습니다.

첫째, 공포는 잘 팔립니다. 개발자 종말론은 조회수, 강의 판매, 도구 구독으로 직결되는 콘텐츠 장르가 되었습니다. "지금 이 도구를 배우지 않으면 도태된다"는 메시지의 발신자가 무엇을 파는 사람인지 항상 확인해야 합니다.

둘째, 외삽의 오류입니다. 최근 2년의 발전 속도를 직선으로 연장해 5년 뒤를 그리는 예측은 거의 항상 빗나가 왔습니다. 자율주행이 그랬고, 노코드가 그랬습니다. 능력 향상이 계속되더라도 조직의 도입 속도, 규제, 책임 문제는 훨씬 느리게 움직입니다.

셋째, 생산성 통계의 함정입니다. AI 도구로 코드 생산량이 늘었다는 통계와, 그 코드가 만든 장애와 재작업까지 포함한 순생산성은 다른 숫자입니다. 2026년의 여러 현장 보고는 리뷰 부채와 이해하지 못한 코드의 누적이라는 새로운 비용을 지적하고 있습니다.

넷째, 그럼에도 변화 자체를 부정하는 것 역시 또 다른 안락한 거짓말입니다. 방향은 분명합니다. 코드 생산의 가치는 내려가고, 판단과 책임의 가치는 올라갑니다. 공포도 부정도 아닌, 냉정한 재배치가 필요한 시점입니다.

자주 나오는 질문들

이 주제로 사내 스터디나 멘토링을 하다 보면 반복적으로 나오는 질문들이 있습니다. 짧게 정리합니다.

Q1. 결제 같은 도메인이 없는 평범한 웹 개발자는 어떻게 하나요?

도메인은 산업만을 뜻하지 않습니다. 접근성, 국제화, 성능 최적화, 레거시 마이그레이션 같은 횡단 영역도 도메인입니다. 핵심 조건은 두 가지입니다. 실패 사례가 누적되는 영역인가(암묵지가 쌓이는가), 그리고 AI 산출물의 품질을 그 지식으로 판별할 수 있는가. 지금 맡은 업무에서 가장 자주 사고가 나는 영역이 무엇인지부터 살펴보면 됩니다.

Q2. 지금이라도 깊이를 파야 하나요, 도구부터 익혀야 하나요?

순서의 문제가 아니라 비율의 문제입니다. 도구 숙련은 2026년 현재 몇 주면 충분히 따라잡을 수 있는 영역이 되었고, 격차도 빠르게 줄어듭니다. 반면 깊이와 도메인은 따라잡는 데 햇수가 걸립니다. 따라서 시간 배분은 도구 2 대 깊이 8 정도가 합리적입니다. 단, 도구 2를 0으로 만들면 안 됩니다. 도구를 모르면 도구의 산출물을 검증하는 감각도 무뎌집니다.

Q3. 주니어인데 장인이 될 기회 자체가 사라지는 것 아닌가요?

가장 어려운 질문입니다. 단순 작업이라는 전통적 훈련장이 줄어드는 것은 사실입니다. 대안은 의도적 수련입니다. 에이전트가 한 시간에 끝낼 일을 주말에 직접 해 보는 것, 에이전트의 산출물을 라인 단위로 설명해 보는 것, 작은 시스템을 처음부터 끝까지 혼자 만들어 보는 것. 비효율을 알면서 선택하는 비효율은 훈련이고, 모르고 겪는 비효율은 낭비입니다. 훈련의 비효율을 의식적으로 사 와야 하는 첫 세대가 된 것입니다.

Q4. 회사가 AI 도구 도입만 밀어붙이고 검증 체계에는 관심이 없습니다.

흔한 상황이고, 역설적으로 기회입니다. 조직의 관심이 생산에 쏠려 있을 때 검증의 공백은 커지고 있으며, 그 공백은 언젠가 장애나 보안 사고로 청구서가 돌아옵니다. 청구서가 오기 전에 검증 체계를 조용히 만들어 둔 사람은, 사고 이후 조직이 가장 먼저 찾는 사람이 됩니다. 2026년 npm 공급망 공격 이후 많은 조직에서 실제로 벌어진 일입니다.

Q5. 두 글 중 하나만 읽는다면 무엇을 읽어야 하나요?

bearblog의 글을 먼저 읽기를 권합니다. 전략은 감정을 직시한 다음에야 작동하기 때문입니다. 불안을 건너뛴 채 세운 계획은 불안이 돌아오는 순간 무너집니다.

마치며 — 장인이냐 빌더냐는 잘못된 질문일 수 있다

두 글을 다시 겹쳐 봅시다. Stack Overflow의 글은 장인과 빌더를 구분했지만, 실제 현장에서 살아남는 포지션은 그 구분의 어느 한쪽이 아니라 전환 능력에 있는 것 같습니다. 오전에는 빌더로서 에이전트에게 작업을 위임해 속도를 내고, 오후에는 장인으로서 그 산출물의 깊은 곳을 검증하는 사람. 도메인이라는 닻을 내린 채 두 모드를 오가는 사람.

bearblog의 저자가 느낀 상실감은 진짜입니다. 코드를 잘 쓰는 것이 곧 자신이었던 시절은 실제로 저물고 있습니다. 하지만 그 기술이 사라지는 것이 아니라, 더 큰 일(판단, 검증, 책임)의 기반으로 흡수되는 것이라면, 이것은 강등이 아니라 승진에 가깝습니다. 다만 승진이 늘 그렇듯, 어제까지 잘하던 일과 내일부터 잘해야 하는 일이 다를 뿐입니다.

서야 할 곳은 분명해 보입니다. AI가 만드는 것의 옆이 아니라, AI가 만든 것과 세상 사이. 그 자리의 이름이 장인이든 빌더든, 중요한 것은 그 자리에 서 있다는 사실입니다.

마지막으로 실천 요약입니다. 이번 주에 할 일은 세 가지뿐입니다.

1. 자가 진단 체크리스트를 작성해 자신의 축을 확인합니다.

2. 자기 분야의 암묵지 한 건을 문서로 옮깁니다.

3. bearblog의 글을 읽고, 공감되는 문장에 밑줄을 긋되, 마지막에 위 표의 오른쪽 열(지도)을 다시 펼칩니다.

불안은 데이터가 아니라 신호입니다. 신호를 받았으면, 이제 데이터를 만들 차례입니다.

참고 자료

- Artisans and builders (Stack Overflow 블로그): https://stackoverflow.blog/2026/05/28/artisans-and-builders/

- LLMs are eroding my software engineering career (원문): https://human-in-the-loop.bearblog.dev/llms-are-eroding-my-software-engineering-career-and-i-dont-know-what-to-do/

- GeekNews 토론: https://news.hada.io/topic?id=30264

- Hacker News: https://news.ycombinator.com/

- Stack Overflow 개발자 설문: https://survey.stackoverflow.co/

- Anthropic의 효과적인 에이전트 만들기: https://www.anthropic.com/research/building-effective-agents

- Claude Code 베스트 프랙티스: https://www.anthropic.com/engineering/claude-code-best-practices

- DORA 리서치 (소프트웨어 딜리버리 성과 연구): https://dora.dev/

- Will Larson, StaffEng (시니어 커리어 사다리): https://staffeng.com/

- Camille Fournier, The Manager Path 관련 자료: https://www.oreilly.com/library/view/the-managers-path/9781491973882/