AI Native Engineer — 원리 위의 감각

1. 들어가며

AI 네이티브 시대. 사람들은 새로운 시대가 왔다고 공포를 느낀다. 개발자 집단 우울증이라는 말이 과장이 아닌 듯하다. 직업 상실의 공포, 심지어는 러다이트 운동을 언급하는 사람도 있다. 러다이트 운동이 그랬듯 AI 서버를 파괴하러 가야 할까? AI 혁명으로 모든 개인 지식 노동자들은 일자리를 잃고 일부 대기업만이 모든 지식 생산을 독식하는 세상이 올까? 알 수 없다.

이전 글들에서도 언급했듯이 AI는 결국 본인의 거울이기 때문에 잘하는 사람은 더 잘하게, 게으른 사람은 더 게으르게 만들 거라고 생각한다. 이제 AI 없이는 어떻게 일을 할까 싶은 시대가 되었지만 글쎄, 내가 본 주위의 풍경은 의외로 그 사람의 역량에 따라 결과물의 퀄리티가 크게 달라진다는 것이다. 지금은 모두가 FOMO에 휩쓸려 너도나도 이런저런 도구를 도입하고 사용하고 그걸 퍼나르고 공유하는 데 여념이 없지만, 정말로 성과를 내는 사람들은 여전히 소수다.

개발자로, 리드로 현업에서 다양한 롤을 수행하며 많은 사람을 만났다. 그 경험에서 내가 느끼는 관점은 의외로 낙관적이다. 불안이 먼저 보이지만, 이 글은 그 불안 너머를 이야기하려고 한다. 곧 기업들이 다시 주니어를 채용할 것이고, AI 시대에 성공한 기업들도 채용을 진행할 거라고 본다. 나의 일상생활과 업무를 지탱하며 24시간 돌아가는, 12개가 넘는 에이전트를 매일 사용하고, 온갖 스킬들과 케이스 스터디를 업무에 적용해가며 시도하고 있지만, 모든 걸 멈추고 내가 백지에 적은 내 생각 노트 하나가 그 모든 걸 뛰어넘는다. 물론 에이전트들이 내 생각 노트들을 잘게 씹고 뜯고 실제 구현체까지 만드는 속도는 전에는 감히 상상할 수 없었지만 애초에 “나의” 생각 노트 없이 무슨 일을 시작할 수 있겠나?

0을 아무리 제곱해봐야 0이다. AI 네이티브 엔지니어는 0이 아닌 사람이다.

에이전틱 엔지니어링 9가지 스킬에서 How를 다뤘고, AX 조직 전환에서 Where를 다뤘다. 이번에는 Who — AI Native Engineer란 대체 어떤 사람인가. 이 글이 가장 어려운 건, 결국 나 자신을 들여다봐야 하기 때문이다.

How에 대한 답은 이미 충분하다. OpenAI는 AI에게 위임하고, 검토하고, 소유하라(Delegate — Review — Own)는 모델을 제시했고, Mike Mason은 프롬프트 엔지니어링의 다음 단계로 컨텍스트 엔지니어링(Context Engineering)을 이야기한다. Karpathy는 이미 에이전트를 스핀업하고 태스크를 부여하고 병렬로 검토·관리하는 것이 엔지니어의 일상이 됐다고 했고, Steve Yegge는 20~30개 병렬 에이전트를 오케스트레이션하며 1년간 백만 라인을 생성했다. 어떻게 AI를 쓸 것인가에 대한 방법론은 넘쳐난다.

하지만 Who가 빠져있다. 도구를 잘 다루는 것은 조건이지 정체성이 아니다. 칼을 잘 다룬다고 요리사인 건 아니고, AI를 잘 다룬다고 AI Native Engineer인 것도 아니다.

원리 없는 감각은 추측이다.

2. 드러난 것들 — 이전 시대 엔지니어와 다른 점

나는 15년간 개발을 해왔다. 그 시간 대부분을 도구와 씨름하면서 보냈다. 언어 문법을 외우고, 프레임워크 컨벤션을 익히고, 빌드 시스템을 설정하고, 배포 파이프라인을 구축하고. Drew Hoskins의 The Product-Minded Engineer 서문에 이런 문장이 있다.

도구와 언어가 너무 어려워서, 이를 익히고 사용하는 것 자체가 풀타임 직업이었다.

이 문장을 읽었을 때, 마지막 퍼즐 한조각이 드디어 맞춰지는 느낌이었다.

Swift를 잘 쓰면 iOS 개발자, React를 잘 쓰면 프론트엔드 개발자, Kubernetes를 잘 다루면 DevOps 엔지니어. 도구가 정체성이었다. “무엇을 만드는가”보다 “무엇으로 만드는가”가 중요했던 시대.

AI가 이 풀타임 직업을 대신하기 시작했다.

문법? AI가 안다. 프레임워크? AI가 안다. 빌드 설정? AI가 해준다. 배포 파이프라인? AI가 짜준다. 물론 아직 완벽하지 않다. 복잡한 레거시 코드베이스에서는 여전히 삽질이 필요하다. 하지만 방향은 명확하다.

그리고 그 풀타임 직업이 사라지기 시작하자, 원래 해야 했지만 도구에 가려져 있던 것들이 전면에 드러나기 시작했다.

사용자 이해. 제품 사고. 비즈니스 책임.

데이터가 이걸 뒷받침한다.

DORA 2025 리포트에 따르면, AI 도구 도입 이후 PR 생성량은 98% 증가했다. 거의 두 배다. 그런데 소프트웨어 딜리버리 성과는? Flat. 변화 없음.

이게 좀 씁쓸한 숫자인데, Nicole Forsgren이 정확히 짚었다. 코딩 내부 루프(Inner Loop) — 코드 작성, 테스트, 로컬 빌드 — 는 빨라졌다. 반면 외부 루프(Outer Loop) — 리뷰, 승인, 통합, 배포, 보안, 피드백 — 의 병목은 여전하다. 결국 진짜 병목은 코딩이 아니었던 셈이다. 우리가 “코딩 생산성”이라고 불렀던 것은 전체 가치 사슬의 아주 작은 일부에 불과했다.

더 냉정한 데이터도 있다. 하버드 경영대학원 렘 코닝(Rem Koning) 교수가 케냐 소기업 창업자들에게 ChatGPT를 제공한 실험에서, 기존에 성과가 낮던 그룹은 AI를 쓴 뒤 오히려 수익이 10% 하락했다. AI의 조언을 많이 받았지만, 좋은 조언과 나쁜 조언을 구분할 판단력이 없었기 때문이다. 반면 이미 판단력을 갖춘 그룹은 나쁜 조언을 걸러내고 성과를 올렸다. 코닝 교수의 결론: AI는 평등화가 아니라 증폭기다. 직접 겪어서 쌓은 통찰(Earned Insight)이 없으면, AI는 슬롭(slop)으로 이끌 뿐이다.

코딩만 잘하면 됐던 시대가 끝난 것이 아니다. 끝난 것은 오히려 ‘코딩만 잘하면 된다’는 착각이다. 도구가 쉬워질수록, 그 도구 뒤에 숨을 수는 없게 된다.

그렇다면 구체적으로 무엇이 달라졌을까. 이전 시대 엔지니어와 비교하면 세 가지가 눈에 띈다.

책임의 확대

이전에 개발 팀을 이끌면서 우리 팀의 책임 범위는 어디까지나 전달(delivery)에 있었다. 정확하고 빠르게 배포하는 것이 우리의 책임이었다. 판매와 영업, 운영은 애초에 다른 팀의 몫이었으니까. 하지만 지금 뼈저리게 느끼는 건 하나다. 전달보다 중요한 건 발견(discovery)이고, 100개의 전달보다 1개의 제대로 된 발견을 구현해내는 게 실력이라고 생각한다. 만드는 것 자체가 이전보다 훨씬 빨라진 세상에서, 발견을 책임지지 못하는 엔지니어는 0인 엔지니어라고 생각한다.

예전에는 “왜 이걸 만들어야 하지?”라는 질문을 PM이 대신 해줬다. 엔지니어는 스펙을 받아서 구현하면 됐다. 그 구조가 나쁘다는 게 아니다. 그게 합리적이었다. 도구가 너무 어려웠으니까. 하지만 AI가 구현의 상당 부분을 가져간 지금, 엔지니어가 “왜”를 모르면 대체 뭘 하는 사람인가? 스펙을 AI에게 넘기는 사람? 그건 엔지니어가 아니라 전달자다.

사용자가 진짜 원하는 게 뭔지, 이 기능이 비즈니스에 어떤 임팩트를 주는지, 우선순위가 왜 이렇게 정해졌는지 — 이런 맥락을 이해하는 엔지니어와 그렇지 않은 엔지니어의 격차가 AI 시대에 극적으로 벌어지고 있다. AI가 “어떻게”를 대신 해주니까, “왜”를 모르는 엔지니어에게 남는 역할이 없다. 사용자를 모르는 엔지니어는 도태될 뿐이다.

10배 빠른 학습 능력

AI가 생성하는 코드의 양이 10배가 됐으면, 그 코드를 이해하고 판단하는 속도도 10배여야 한다. AI가 30초 만에 만들어낸 200줄의 코드를 읽고, “이건 맞다, 저건 틀리다, 여기는 성능 이슈가 있다”를 판단하려면 — 기초가 탄탄해야 한다.

기초는 죽지 않는다(Basic Never Die). CS 기초뿐 아니라, 자신이 사용하는 도구 — 언어든 프레임워크든 — 에 대한 깊은 이해도 마찬가지다. 표면만 긁어서는 AI가 뱉어내는 코드의 옳고 그름을 판별할 수 없다. 판별하지 못하면 AI를 쓰는 사람이 아니라 AI에 끌려가는 사람이 된다. 그건 AI Native가 아니라 AI Dependent다.

이전 시대에는 한 가지 기술을 깊이 파면 10년은 먹고살 수 있었다. Java를 잘하면 Java 개발자로, Golang을 잘하면 백엔드 개발자로. 그 깊이가 경쟁력이었다. 지금은 다르다. AI가 언어 간 장벽을 무너뜨리고 있다. iOS를 모르는 사람이 AI 도움으로 iOS 앱을 만들 수 있다 (내가 그 예다). 하지만 그게 “iOS 엔지니어”가 됐다는 의미는 아니다. 표면적으로 돌아가는 코드와, 프로덕션에서 견디는 코드 사이의 간극은 여전히 크다.

그래서 학습 방식 자체가 달라져야 한다. 예전처럼 문법부터 차근차근 쌓아올리는 게 아니라, AI가 만든 코드를 읽으면서 원리를 역추적하는 방식. “이 코드가 왜 이렇게 동작하지?”를 파고들다 보면, 자연스럽게 깊은 이해로 연결된다. AI가 만들어준 코드가 교재가 되는 셈이다. 다만, 그 교재를 읽을 눈이 있어야 한다.

판단의 속도

Forsgren이 짚은 건데, AI와 함께 일하면 30분 안에 수십 번 멘탈 모델을 재구성해야 한다. 예전에는 하루에 한두 번 설계 결정을 내리면 됐다. 이제는 30분 안에 수십 번이다.

AI가 3개의 접근법을 제시하면, 그중 어떤 게 맞는지 판단해야 한다. AI가 “캐시를 추가하세요”라고 하면, 진짜 캐시가 정답인지 아니면 쿼리 자체가 문제인지 판단해야 한다. AI가 리팩토링 제안을 하면, 그게 정말 나은 설계인지 아니면 겉만 다른 같은 복잡도인지 판단해야 한다. 이 모든 게 빠르게, 연속적으로 일어난다.

빠른 판단은 깊은 이해에서 나온다. 원리를 이해하는 사람은 직관적으로 판단할 수 있다. “이건 O(n²)이니까 데이터가 커지면 문제가 생길 거다”, “이 구조는 분산 환경에서 일관성 문제가 생긴다”, “이 API 설계는 클라이언트에 너무 많은 책임을 떠넘긴다” — 이런 판단이 0.5초 만에 나와야 하는 시대다.

예전에는 모르면 찾아보면 됐다. 시간이 있었으니까. 지금은 AI가 코드를 쏟아내는 속도를 따라잡으려면, 찾아보기 전에 감이 와야 한다. 그 감은 허공에서 오지 않는다. 수년간 쌓은 원리의 토대에서 온다.

본질이 달라진 게 아니라 적나라하게 드러난 것이다. 이전에도 좋은 엔지니어는 이 세 가지를 갖추고 있었다. 다만 도구가 너무 어려워서 가려져 있었을 뿐이다.

나는 15년간 도구 뒤에 숨어 있었는지도 모른다. 프레임워크를 잘 쓰고, 서버를 잘 구축하고, 아키텍처를 잘 설계하는 것. 그게 나의 전문성이라고 믿었다. 완전히 틀린 말은 아니지만 그게 전부인 양 행동한 적이 있었다. 사용자가 불편하다고 해도 “기술적으로는 맞다”고 버틴 적도 있었다.

그 도구를 AI가 대신 쓸 수 있게 되니, 그 뒤에 숨어 있던 내가 드러난 것이다.

(이게 참 불편한 깨달음이다.)

3. Maker의 역풍

이전 AX 글에서 Maker와 Closer를 구분했다. Maker는 산출하는 사람, Closer는 성과를 완결하는 사람. 여기서 좀 더 깊이 들어가 보자 — 조직 레벨이 아니라, 개인 레벨에서.

기존 Maker들은 자기 KPI가 Make 방향으로 정렬되어 있다고 믿었다. 코드를 짜고, 기능을 배포하고, PR을 올리고, 스프린트를 마감하는 것. 새벽까지 코딩하고, 주말에도 배포하고, 장애가 나면 달려가는 사람들. 실제로 열심히 하는 사람들이었다.

하지만 IT 조직 대부분의 Maker가 비즈니스 KPI에 직접 기여하지 않는다고 판단되는 순간이 온다. 그 순간 구조조정이 일어난다. 빅테크들이 수만 명을 내보냈고, 그들 중 대다수는 열심히 일하던 사람들이었다.

안타깝지만, 이건 대부분 개인의 잘못이 아니다. 조직이 고민 없이 채용한 인력들이, 주어진 일을 열심히 하다가 맞는 역풍이다.

AI가 이 역풍을 가속하고 있다. Maker의 일 — 코드를 짜고, 기능을 구현하는 것 — 을 AI가 상당 부분 대체할 수 있다는 게 증명되면서, 역풍은 우리 생각보다 훨씬 빠르게 덮치고 있다.

물론 그 와중에도 “이게 정말 조직에 기여하는 일인가?”를 고민하던 사람들이 있었을 거다. 자기가 만든 기능의 데이터를 직접 확인하고, 지표가 안 나오면 “이거 접자”고 먼저 말하던 사람들. 그들은 나가든가, 살아남든가 했을 것이다. 어느 쪽이든 고민한 만큼 다음 행보가 명확했을 거라고 본다. (물론 모두가 이런 기회를 얻은 것은 아니다.)

예전에는 “Maker가 Closer 마인드를 가지면 훌륭한 Maker”라고 칭찬받았다. “개발자인데 비즈니스도 이해하네, 대단해.” 지금은? Closer가 되지 않으면 생존할 수 없는 환경이 됐다. 칭찬이 아니라 생존을 위한 필수 조건이 된 것이다.

내가 딸깍하는 만큼 — AI와 함께 코드를 뚝딱 만들어내는 만큼 — 남들도 딸깍한다. 만드는 것 자체가 점점 범용화(commodity)되고 있다. 누구나 만들 수 있는 시대에, “나는 잘 만든다”는 차별화가 안 된다. 딸깍은 더 이상 경쟁력이 아니다.

만드는 것 자체를 사랑하는 마음이 문제가 아니다. 그 사랑의 방향이 달라져야 한다는 거다.

이건 Maker를 비하하는 게 아니다. 나도 Maker다. 만드는 것을 사랑한다. 코드를 짜고, 아키텍처를 설계하고, 깔끔한 PR을 올리는 순간의 쾌감. 그건 여전히 좋다.

하지만 사랑한다고 해서 현실이 바뀌지는 않는다. 만드는 것 자체로는 가치가 완성되지 않는 시대가 왔다. 만들고, 전달하고, 검증하고, 개선해서, 비로소 가치가 된다. 그 전체를 책임지는 사람이 필요하다.

이 부분이 가장 씁쓸하다. 나도 Maker로서 자부심이 있었으니까. 잘 만드는 것이 가치 있다고 믿었으니까. 하지만 현실은 냉정하다.

그렇다고 기술이 필요 없다는 이야기가 아니다. 오히려 그 반대다. 기술은 더 중요해졌다. 다만 어떤 기술이냐가 달라졌을 뿐이다.

이걸 몸으로 깨달은 경험이 있다.

4. 마법사의 오류 — 기술이 더 중요해지는 역설

나는 지금 Golang으로 백엔드를 구현 중이고, iOS로 클라이언트를 개발 중이다.

Golang으로 백엔드를 구현하면 코드 로직 버그로 헤매는 경우는 종종 있지만, 기술 자체를 몰라서 막히는 경우는 거의 없다. 그래서 핵심 로직에 곧바로 집중하고, 수정도 빠르고, AI가 만든 코드도 금방 파악이 된다.

하지만, iOS는 이야기가 다르다. 나는 올해 처음 iOS 네이티브 개발을 시작했고 많은 부분 AI에게 기대고 있다. WidgetKit에서 변수가 제대로 렌더링이 안 될 때, 레이아웃이 내가 원하는 대로 구현이 안 될 때 내가 iOS 네이티브 기술 역량이 부족하니 2~3일을 끝없이 수정해도 AI도 나도 제대로 문제를 수정하지 못하고 무한 루프에 빠지는 경우가 많았다. 특히 자연스러운 화면 트랜지션이나 코드 로그로 테스트가 쉽게 되지 않는 레이아웃 이슈들이 대부분이었다. Navigation Stack의 동작 원리부터 Liquid Glass까지 기본을 모르고 덤벼들었다가 처참하게 깨졌다.

AI는 그럴듯한 결과물을 바이브하게 만들어준다. 해피패스에서는 모든 게 정상으로 보인다. 뒤로 갔더니 헤더가 깨진다. 로딩이 끊긴다. 트랜지션이 자연스럽지 않다. AI는 모든 걸 구현해주었지만 모든 걸 구현하지 않은 상태와 동일했다. 온갖 스킬, 하네스 엔지니어링을 가져다줘도 결국은 한땀한땀이었다. AI와 대화하며 문제를 수정하고, 직접 손으로 재현하고, AI가 같은 문제를 빙빙 돌면 상위 레이아웃이나 앱 전체 콘텍스트를 제공하려고 노력했다. 결국 이런 생각이 든다. ‘iOS 엔지니어라면 훨씬 쉽게 했을 텐데.’

WidgetKit, 화면 트랜지션 등 이해 없이 사용한 기술로 며칠을 삽질했다. 내가 iOS 엔지니어였다면 5분이면 고쳤을 거라고 확신한다. 할 수 있게 되었다고 훌륭하게 잘할 수 있는 건 아니다.

프로덕트 엔지니어는 엔드 유저를 생각하는 엔지니어다. AI가 만들어주는 결과물은 그 시작점이지, 그걸 엔드 유저가 정말 만족할지 고민하며 깎아내는 건 결국 엔지니어의 몫이다. 원리와 감각은 대치가 아니다. 감각을 살리고 싶을수록 원리에 대한 이해 없이는 절대 퀄리티를 만들어낼 수 없을 것이다.

내 경험만이 아니다.

Carson Gross(HTMX 개발자, Montana State 교수)가 “마법사의 제자 함정(Sorcerer’s Apprentice Trap)“이라고 부르는데, 딱 내 상황이었다. 디즈니 판타지아에서 마법사의 제자가 빗자루에 마법을 걸어 물을 길어오게 했다가 통제불능에 빠지는 장면. (최애 미키 마우스 애니메이션인데, Ellie는 잘 모른다고 한다. 일요일마다 디즈니 만화동산 보신 분?) AI와 코딩의 관계가 딱 그렇다.

주니어가 코드를 쓸 줄 모르면 코드를 읽을 줄도 모르게 된다. 읽을 줄 모르면 LLM에 휘둘린다.

정확히 내가 iOS 개발에서 겪은 문제였다. 코드는 보통 쓰는 것보다 읽히는 경우가 더 많다. AI가 코드를 써주니까 쓰기 능력이 덜 중요해졌다고? 읽기 능력은 오히려 더 중요해졌다. 내가 쓰지 않은 코드를 읽고, 이해하고, 판단해야 하니까.

더 무서운 건 피드백 루프의 단절이다. 원래는 코드가 복잡해질수록 몸이 먼저 신호를 보낸다. 손이 멈추고, 머리가 아프고.. “이건 너무 어렵다”는 신호가 온다. 그 신호는 설계를 단순화하도록 만든다. 하지만 AI로 생성하면 이 과정은 사라진다. AI는 200줄이든 2,000줄이든 아무렇지 않게 내놓는다. 복잡성은 보이지 않는 채 누적되고, 결국 한꺼번에 폭발한다.

LLM은 본질적 복잡성(essential complexity)을 줄이지 않는다. 우연적 복잡성(accidental complexity)을 쉽게 생성할 뿐이다. Fred Brooks가 1986년에 “No Silver Bullet”에서 구분한 바로 그 개념이다.

Steve Krouse(Val Town CEO)도 비슷한 걸 다른 각도에서 짚었는데, 이것도 내 경험과 정확히 겹친다.

바이브 코딩은 자신의 바이브가 정밀한 추상화라는 환상을 준다.

처음엔 잘 돌아간다. 데모는 완벽하다. 해커톤에서 상도 탄다. 하지만 기능을 추가하거나 규모가 커지면, 이해하지 못한 더 낮은 추상화 레벨에서 버그가 몰래 들어온다. 내가 iOS에서 겪은 것과 똑같다. 네트워크 타임아웃, 메모리 릭, 동시성 이슈 — 프로덕션에서, 사용자가 예상치 못한 방식으로 쓸 때, 이해하지 못한 레이어에서 문제가 터진다.

그리고 그 문제를 디버깅하려면 — 결국 원리를 알아야 한다.

Krouse가 던진 질문 하나가 계속 머릿속에 남는다. “아무도 ‘바이브 라이팅(vibe writing)‘을 말하지 않는다.” 글쓰기에서는 “느낌대로 쓰면 된다”를 진지하게 받아들이는 사람이 없다. 좋은 글을 쓰려면 문법을 알아야 하고, 구조를 이해해야 하고, 수많은 글을 읽어야 한다. 그런데 왜 코딩에서는 “바이브대로 하면 된다”를 진지하게 말하는가?

생각해보면 이건 도구 지식과 원리 지식 의 구분으로 귀결된다.

도구 지식 — Swift 문법, React 패턴, Kubernetes YAML, 특정 프레임워크의 API. 이건 AI가 대체할 수 있다. 이미 대체하고 있다. 나도 요즘 Swift 문법을 외우지 않는다. Claude가 알고 있으니까.

원리 지식 — 네트워크, 컴퓨터 구조, 운영체제, 분산 시스템, 자료구조, 알고리즘. 이건 AI 시대에 오히려 더 빛난다. AI가 만든 코드가 “왜 느린지”, “왜 동시성 문제가 생기는지”를 판단하려면 원리를 알아야 하니까.

AI에게 “이 코드 왜 느려?”라고 물어볼 수 있다. AI가 답을 줄 수도 있다. 하지만 그 답이 맞는지 판단하는 건 — 원리를 아는 사람의 몫이다. AI가 “캐시를 추가하세요”라고 했는데, 진짜 문제가 캐시가 아니라 N+1 쿼리라면? 네트워크와 DB를 이해하는 사람만이 그 차이를 짚을 수 있다.

엔지니어링 마인드는 엔지니어링 이론 위에서 발현되는 것이지, 마인드만으로 만들어질 수 없다. (프로덕트 엔지니어도 결국 엔지니어다.)

네트워크를 모르면서 “이 API가 느린 것 같다”고 말하는 건 감각이 아니라 추측이다. TCP 핸드셰이크를 이해하는 사람이 “여기서 레이턴시가 발생하고 있다”고 말할 때, 그게 감각이다. 운영체제를 모르면서 “앱이 무거운 것 같다”고 말하는 건 인상이다. 메모리 관리 원리를 아는 사람이 “여기서 메모리 릭이 생기고 있다”고 짚을 때, 그게 진단이다.

CS 기초 위에 제품 감각이 올라가야 한다. 순서가 중요하다. 기초 없이 감각만 키우려는 건, 기초 체력 없이 기술 축구를 하겠다는 것과 같다.

마법사의 오류는 여기에 있다. AI가 도구 지식을 대체하니 ‘기술의 중요성이 줄어든다’고 착각한다. 하지만 실제로는 원리 지식이 더 중요해졌다. 도구 지식이 빠진 자리는 결국 원리 지식이 채워야 한다.

5. 원리 위의 감각 — Eval

그렇다면 원리만으로 충분할까?

아니다. 감각 없는 원리는 학자를 만들 수는 있어도, 좋은 엔지니어를 만들지는 못한다. CS 박사라고 좋은 엔지니어가 되는 것도 아니고, 논문을 잘 쓴다고 제품을 잘 만드는 것도 아니다. 원리를 아는 건 필요조건이지, 충분조건은 아니다.

Hoskins의 The Product-Minded Engineer 에 나오는 “밥(Bob)” 이야기가 이 점을 잘 보여준다. 밥은 실력 있는 엔지니어다. 원리도 알고, 코드도 깔끔하며, 리뷰도 꼼꼼하다.

하지만 밥은 시나리오 없이 구현한다.

스펙에 적힌 대로 만들 뿐, “사용자가 이 기능을 실제로 어떤 상황에서 쓸까?”를 생각하지 않는다. 밥이 만든 기능은 잘 동작하고 테스트도 통과한다. 그런데 사용자는 그 기능을 쓰지 않는다.

“기술적으로 완벽한 기능인데 아무도 안 쓴다” — 나도 여러 번 겪었다 (어쩌면 지금도.)

Hoskins은 엔지니어를 편집자 에 비유했다. 좋은 문장을 쓰는 사람이 아니라 불필요한 문장을 잘라내는 사람. “이건 안 넣어도 된다”를 판단하는 사람. 이것이 제품 아키텍처(Product Architecture)의 핵심이다.

AI는 코드를 잘 짜줄 수 있다. 하지만 “이 기능이 정말 사용자에게 필요한가?”를 판단하는 건 여전히 인간의 영역이다.

이 판단 능력 — Anthropic은 이걸 “taste”라고 불렀다. AI를 가장 잘 만드는 사람들이, AI에 가장 마지막까지 맡기지 않는 것.

그런데 taste라는 단어가 좀 신비롭게 들린다. “taste는 타고나는 거 아닌가? 없는 사람은 어쩌라고?” 나도 처음엔 그렇게 느꼈다. 특히 주변에 taste가 뛰어난 엔지니어를 보면 더 그렇게 느낀다.

그런데 Linear CTO Thomas가 정확히 답했다.

Taste is not mystical. It’s a craft.

감각은 신비로운 게 아니다. 크래프트다. 갈고닦을 수 있다.

Linear 팀이 이걸 증명했다. Quality Wednesday — 매주 수요일, 팀 전체가 제품의 결함을 찾아 수정한다. 스크롤이 미세하게 끊기는 것, 버튼 간격이 3px 어긋난 것 같은 사소한 결함들까지 집요하게 다룬다. 그렇게 2년간 2,500개의 defect를 수정했다. 이 과정을 매주 반복하면 ‘항상 다음 수정할 것을 찾는 마인드셋’이 자동으로 형성된다. Taste는 그렇게 근육처럼 몸에 붙는다.

좋은 글을 많이 읽으면 나쁜 글이 눈에 들어오는 것처럼. 좋은 UX를 많이 경험하면 나쁜 UX가 거슬리는 것처럼. 겉으로 보이는 직관은 안으로 쌓인 경험의 결과물이다.

Taste는 경험의 축적이지, 천부적 재능이 아니다.

이전 글에서 에이전틱 엔지니어링 9가지 스킬을 다뤘다. 이번 글을 쓰면서 하나를 더 추가해야 한다는 확신이 들었다.

Eval. AI가 만든 결과물을 평가하는 판단력.

9가지 스킬이 “AI와 함께 일하는 법”이라면, Eval은 “AI의 결과물을 판단하는 법”이다. Taste가 “이건 좀 아닌데”라는 감각이라면, Eval은 “왜 아닌지 구체적으로 짚고 수정 방향을 제시하는 것”이다.

AI에게 UI 레이아웃을 맡긴다. 코드를 생성하고, 테스트를 돌린다. All Pass. CI도 녹색이다.

“오, 잘 되네.”

그런데 실제 디바이스에서 만져보면 전혀 다르다.

좁은 화면에서 레이아웃이 찌그러진다. 스크롤이 어색하다. 터치 영역이 너무 작아서 손가락이 두꺼운 사람은 누르기 어렵다. 텍스트가 잘려 보인다. 애니메이션이 의도와 다르게 동작한다.

AI는 테스트 케이스에 맞게 최적화하지, 사용자 경험에 맞게 최적화하지 않는다. AI가 만든 코드가 기능적으로 동작하는 것과, 그 코드가 사용자에게 좋은 경험을 주는 것은 완전히 다른 차원의 이야기다. 전자는 AI가 할 수 있다. 후자는 아직, 그리고 당분간은, 인간의 몫이다.

더 문제인 건, AI가 레이아웃의 좁은 범위만 수정하면서 전체적인 일관성을 깨뜨리거나, 아예 잘못된 방향으로 개발이 진행될 때다. 테스트는 계속 All Pass인데, 제품은 점점 이상한 곳으로 가고 있다. AI는 당신만큼만 똑똑하다 — 이전에 쓴 글 제목 그대로다. AI의 판단은 내 판단을 넘지 않는다.

“AI의 All Pass가 나에게도 All Pass인가?”

이 질문을 던질 수 있는 사람이 AI Native Engineer다. 테스트가 통과했다고 안심하는 게 아니라, 직접 눈으로 보고, 손으로 만져보고, 사용자의 입장에서 판단하는 사람. 그게 Eval이다.

그리고 이 Eval은 — 네트워크가 어떻게 동작하는지, 메모리가 어떻게 관리되는지, 렌더링 파이프라인이 어떻게 흘러가는지 아는 사람이 더 잘한다. 원리 위에서 감각을 발휘하는 것. 그게 진짜 Eval이다.

예전에는 E2E 책임 — 기획부터 배포, 사용자 피드백까지 — 이 PO나 CEO의 몫이었다. 개발자는 “시키는 대로 잘 만들면 됐다.” 이제 그 경계가 무너지고 있다. AI가 “잘 만드는 것”을 대신하니까, 남은 인간의 역할은 “뭘 만들어야 하는가”와 “그게 정말 가치가 있는가”를 판단하는 것이다.

그리고 이건 개인의 의지만으로는 안 된다. 그 역할과 책임이 주어지지 않는 환경이라면, AI Native Engineer로 성장하기 좋은 환경이 아니다. “너는 이 기능을 스펙대로 구현하면 돼” — 이런 조직에서는 Eval 능력이 자랄 수 없다. 사용자를 만날 기회도, 지표를 볼 권한도, “이걸 왜 만들지?”라고 물을 공간도 없다.

6. 그래서 나는

여기까지 읽었으면 궁금할 거다. 그래서 어떻게 해야 하는가.

나도 다 겪어봤다. 그 함정을 하나하나 밟아봤다.

“먼저 공부하고 시작해야지.” 나도 그랬다. 합리적으로 들리지만, 사실은 시작하지 않겠다는 선언이었다. 게다가 AI 도구는 매달 바뀐다. 준비가 끝나기만 기다려서는 영원히 시작할 수 없다. 수영을 배우려면 물에 들어가야 하듯, 수영 이론 책을 아무리 읽어도 수영은 배울 수 없다. 1년 뒤에도 여전히 같은 말을 하고 있는 나를 발견했을 때, 비로소 깨달았다.

나도 트위터를 열고 “나도 해야 하는데…”를 중얼거리다가 닫은 적이 있다. 불안은 행동의 연료가 될 수 있지만, 불안 자체가 행동을 대체하지는 않는다.

“강의부터 들어볼까.” 나도 처음에 그 생각을 했다. 그런데 깨달았다. AI는 내 질문에 직접 답해준다. 강의를 듣고 있을 시간에 직접 부딪히는 게 열 배 빠르다. 엔지니어가 도구를 강의로 배운다는 게 좀 이상하지 않은가 (이 말이 좀 꼰대같은 건 안다. 좋은 강의들도 분명 있다.)

그리고 코드로만 소통하던 시절이 있었다. AI가 코딩을 대신할수록, 사람과 대화하고 사용자를 이해하는 능력이 차별화 요인이 되는데, 나도 “이 기능이 왜 필요한지 설명해주세요”라는 질문 앞에서 말문이 막힌 적이 있었다.

전환점은 직접 부딪히기 시작하면서 찾아왔다.

막히면 AI에게 물어봤다. 에러가 나면 에러 메시지를 복붙하고, 설계가 막히면 아키텍처를 물어보고, 테스트가 실패하면 왜 실패하는지 같이 분석했다. 이 과정 자체가 학습이었다. 강의 열 개보다 삽질 한 번이 낫다는 걸 몸으로 배웠다.

본인이 원하는 걸 직접 만들어봤다. “언젠가 만들어야지”가 아니라 지금 시작했다. AI가 있으니까 예전보다 훨씬 빨리 만들 수 있었다. 빠르게 만들 수 있으니, 빠르게 실패할 수도 있었다. 그게 오히려 기회였다.

그리고 결정적으로, 실제 사용자가 있는 프로덕트까지 끌고 갔다. 혼자 쓰는 사이드 프로젝트와 다른 사람이 실제로 쓰는 제품은 천지 차이다. 사용자가 “이거 불편해요”라고 말하는 순간, 밀려오는 불쾌감과 배움의 혼합. 그걸 겪어봐야 제품 감각이 생긴다. 그 감각은 AI가 대신 길러주지 않는다.

나는 기술과 Maker에 대한 동경이 있다. 여전히. 새로운 프레임워크가 나오면 만져보고 싶고, 깔끔한 아키텍처를 설계하면 뿌듯하고, 코드가 아름답게 동작하면 행복하다. (고퍼콘에서 Golang의 동시성을 극대화한 프로젝트 발표들을 들으며 스스로 좌절을 느낀 건 덤이다.) 뛰어난 Maker를 보면 존경한다.

하지만 진짜 가치를 만들어내는 건 그게 아니었다. 아무리 아름다운 코드를 짜도, 그게 사용자에게 가치를 전달하지 못하면 자기만족일 뿐이다. 우리 모두는 비즈니스가 실제 가치를 발현할 때만 유의미하다. 이걸 인정하는 데 오래 걸렸다.

사용자를 무시하는 개발자들을 가끔 봤다. “사용자가 뭘 아나”, “기획이 잘못된 거지”, “기술적으로 이렇게 해야 맞아.” 나도 그런 적이 있었다 (지금 생각하면 민망하다).

돌이켜보면 그건 방어기제였다. 사용자를 진지하게 고려하면 훨씬 더 높은 퀄리티가 요구된다. 매끄러운 UX, 끊김없는 서버 인프라, 자연스러운 AI 기능 — 진짜 사용자를 생각하면 모든 분야에서 챌린지가 있다. 자신 없으니까 외면하는 거다. “기술적으로 올바른 것”에 숨으면 편하니까.

여러 제품을 만들어봤다. 사업 실패도 겪었다. 조직을 승리로 이끌지 못했을 때 어떻게 무너지는지도 직접 겪었다. 능력 있는 사람들이 방향을 잃고 흩어지는 걸 봤다. 기술적으로는 훌륭한 팀이었다. 하지만 “우리가 만드는 것이 사용자에게 가치를 주고 있는가?”라는 질문에 명확히 답하지 못했다.

그 경험이 — 기술에 대한 동경보다 훨씬 깊은 곳에서 — 나를 여기까지 데려왔다.

기술을 사랑하는 것과 기술로 가치를 만드는 것은 다르다. 하지만 대립이 아니다. 기술을 사랑하기 때문에 원리를 파고들고, 원리를 알기 때문에 AI 시대에 더 빛난다. 사랑이 없으면 원리는 그냥 교과서일 뿐이다.

나는 둘 다 하고 싶다. 하지만 우선순위가 바뀌었다. 예전에는 기술이 먼저였다. 이제는 가치가 먼저다.

나는 AI Native Engineer인가? 모르겠다. 아직 되어가는 중이라고 말하는 게 솔직할 거다. 다만, 방향은 알고 있다. 기술이 아니라 가치. Make가 아니라 Close. 코드가 아니라 사용자. 원리를 쌓으면서 감각을 갈고닦는 것.

지금은 Ellie와 함께 앱을 만들면서, AI를 쓰고, 피드백 받고, 지표를 보고, 다시 고친다. 어제 만든 걸 오늘 부수고, 오늘 만든 걸 내일 다시 고친다. 렌더링 파이프라인을 이해하면서 사용자 경험을 판단하고, 시스템 아키텍처를 알면서 “이건 안 만들어도 된다”를 말하려고 노력한다.

가치를 만들어내기 위해 오늘도 고군분투한다. 그게 내가 할 수 있는 전부다.

화려하지 않다. 하지만 이게 진짜다.

7. 나가며 — 가속기 위의 나침반

“당신이 만드는 것은 정말 가치를 발생시키고 있는가?”

에이전트 수십 개 동원해서 n차 에이전트 피드백을 통해 기획안을 내도 Ellie는 부족한 점을 지적한다. 이 글도 마찬가지다. AI가 그럴듯하게 초안을 제시했지만 결국은 내가 대부분의 내용을 다시 작성하고, AI workflow에서는 어느 정도의 퇴고만 하는 것이다. 여러분도 알 것이다. AI로만 자동화한 글이 얼마나 허접한 느낌이 나는지.

아무리 테스트 자동화를 해도 결국은 내가 사용해보는 행위 자체를 생략할 수는 없다. 그리고 AI에게 100번 테스트를 시키는 것보다 내가 빠르게 사용해보고 정리하는 게 훨씬 빠를 때가 많다.

테리 위노그라드 — 1971년 SHRDLU부터 반세기 넘게 AI를 봐온 스탠포드 1세대 연구자 — 의 말이 있다.

AI는 문제의 원인이 아니다. AI는 가속기(Accelerant)다.

과거의 AI 겨울을 직접 통과한 사람이 하는 말이니 무게가 다르다. 이전에도 존재하던 문제들이 AI에 의해 가속되고 있을 뿐이다. 좋은 방향으로 달리던 사람은 더 빨리 좋은 곳에 도착한다. 잘못된 방향으로 달리던 사람은 더 빨리 벽에 부딪힌다. 달라진 건 속도지, 방향이 아니다.

가속기에는 나침반이 필요하다.

그 나침반은 원리 위에 세워진 감각이다.

원리 없는 감각은 추측에 머물고, 감각 없는 원리는 학문에 머문다.

AI Native Engineer는 원리 위에서 감각을 발휘하는 사람이다.

네트워크를 이해하면서도 사용자 경험을 판단할 수 있는 사람. 시스템 아키텍처를 알면서도 “이건 안 만들어도 된다”를 말할 수 있는 사람. 코드를 읽을 줄 알면서도 “이 코드가 풀고 있는 문제가 맞는가?”를 물을 수 있는 사람.

How(에이전틱 스킬)를 갖추고, Where(AX 조직)에서 일하더라도, Who(나 자신)가 원리 위에서 감각을 발휘하는 사람이 아니면 아무 의미가 없다.

원리 위의 감각. 그게 AI Native Engineer다.

E2E로 책임지는 엔지니어가 원래 좋은 엔지니어였다. AI 이전에도 그랬고, AI 이후에도 그럴 것이다. 다만 이제는, 그 사실을 모른 척하기가 어려워졌을 뿐이다.

References

1. Andrej Karpathy, X post on AI Builders vs Coders
2. Mike Mason / ThoughtWorks, “AI-First Software Engineering — Context Engineering”
3. Steve Yegge, “Revenge of the Junior Developer”
4. OpenAI, “Building an AI-Native Engineering Team”
5. Drew Hoskins, The Product-Minded Engineer (O’Reilly, 2025)
6. DORA, “Accelerate State of DevOps Report 2025”
7. Rem Koning / Harvard Business School, “하버드에서 가르치는 AI Native 강의” — EO Korea
8. Nicole Forsgren / Faros AI, “Key Takeaways from the DORA Report 2025”
9. Terry Winograd, Stanford Interview on AI as Accelerant
10. Carson Gross, “Yes, and… The Sorcerer’s Apprentice Trap”
11. Steve Krouse, “The Death of Code is Greatly Exaggerated”
12. Anthropic, “How AI Is Transforming Work at Anthropic”
13. Pragmatic Engineer, Product-Minded Engineer Panel — Linear CTO Thomas: “Taste is not mystical. It’s a craft.”
14. Linear, Quality Wednesday
15. flowkater, “에이전틱 엔지니어링 9가지 스킬”
16. flowkater, “AX 조직 전환”
17. flowkater, “AI는 당신만큼만 똑똑하다”
18. flowkater, “승리 없는 미래”
19. flowkater, “2025 고퍼콘 코리아 후기”