AI 시대, 프론트엔드 엔지니어로 살아남는 법 : 검증·명세·판단력 새 역량

이번 포스팅에서는 AI와 엔지니어가 어떻게 성장하고 살아남을 수 있을까에 대한 이야기를 개인의 관점에서 해보려고 한다.

필자가 주니어 시절 가장 인상 깊게 읽었던 글 중 하나로 배휘동 님의 '프론트엔드 엔지니어 커리어 로드맵, 주니어를 위한 3가지 전문성 트랙'이 있다. 프론트엔드 엔지니어의 커리어를 웹 특화(Software Engineer) / 제품 특화(Product Engineer) / 운영 특화(Full-Stack Engineer) 세 가지 트랙으로 나누어 정리하고, '탁월한 엔지니어의 5가지 기본 역량' 과 '시니어가 되기 위한 3가지 포인트' 까지 짚어주는 글이다. 그 때만 해도 트랙별로 어떤 역량을 쌓을지 고민하는 게 가장 큰 화두였다. 그런데 그 글을 읽은 지 채 2년도 지나지 않아 화두 자체가 완전히 바뀌어버렸다.

요즘 동료 엔지니어들과 이야기를 나누다 보면, 최근 몇년간 듣던 고민과는 결이 좀 다르다는 걸 느낀다.

"회사에서 AI 도입했는데, 디자인 시안 던지면 거의 다 만들어줍니다. 편리하긴한데..."
"채용시장이 엄청 차갑네요"
"AI가 짜준 코드를 그냥 머지하기는 무섭고, 일일이 검토하자니 효율성이 떨어져서 고민이네요"

필자도 비슷한 시기를 겪었고 지금도 겪고 있다. 1~2년 전만 해도 'AI는 좋은 보조 도구' 정도로 생각했는데, 지금은 AI 없이 개발하는 모습 자체가 상상이 안 가는 환경이 되어버렸다(필자도 이 글을 쓰면서 Claude한테 리서치를 부탁하고 있다). 이번 글은 배휘동 님의 글에 대한 후속편 격으로, 그 사이에 풍경이 어떻게 바뀌었는지, 그리고 그 바뀐 풍경 위에서 프론트엔드 엔지니어로서 어떤 역량을 더 쌓아야 하는지를 필자 나름의 관점으로 정리해보려 한다.

이번에도 자료를 가능한 한 많이 찾아 검증해보려 노력했지만, 워낙 빠르게 변하는 분야인 만큼 이 글이 나간 시점에 이미 일부 내용이 낡아 있을 수 있음을 미리 양해 바란다. 반박이나 토론할 거리가 있다면 언제든 댓글로 알려주시길.

"이제 AI가 다 해주는 거 아니에요?"

먼저 짚고 가야 할 게 있다. "AI가 다 해준다" 라는 문장은 사실인가? 어디까지 사실이고, 어디서부터는 환상인가?

2025년 2월, OpenAI 공동창업자이자 테슬라 AI 디렉터를 지낸 Andrej Karpathy는 자신의 트위터에 이런 문장을 남겼다.

There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. (바이브 코딩이라는 새로운 방식이 있다. 바이브에 완전히 몸을 맡기고, 지수적 성장을 받아들이며, 코드 자체가 존재한다는 것을 잊는 것이다.)

바이브 코딩(Vibe Coding) 이란 한마디로 "AI에게 키보드를 넘기고 원하는 걸 자연어로 묘사하기만 하는 코딩 방식" 이다. 아키텍처 문서도, 보일러플레이트도, 세미콜론 검색도 없다. 그저 바이브로 코드가 굴러간다. 이 용어는 1년도 안 되어 영어권 개발자 커뮤니티 표준 어휘로 자리잡았다.

그런데 정확히 1년 후인 2026년 2월, 같은 Karpathy가 한 발 물러섰다. 그는 vibe coding이라는 단어를 "agentic engineering" 으로 대체하자고 제안한다. 둘의 차이는 분명하다.

Vibe coding: 원하는 걸 묘사하고 결과물을 받아들이는 것
Agentic engineering: 시스템을 설계하고, 제약을 명세하고, 이미 머릿속에서 추론을 마친 구현을 AI로 가속화하는 것

1년 전엔 "그냥 시키면 다 만들어줍니다"가 기본 베이스였다면, 지금은 "AI에게 무엇을 어떻게 시킬지를 설계하는 능력" 자체가 엔지니어링 역량으로 자리잡고 있다. 이 흐름은 단순히 한 사람의 트윗이 아니다. 같은 시기 구글의 엔지니어 Addy Osmani는 Beyond Vibe Coding: From Coder to AI-Era Developer라는 책을 출간하며 "AI는 비서일 뿐 자율적으로 신뢰할 수 있는 코더가 아니다. 당신이 시니어 개발자고, LLM은 당신의 판단을 가속화하기 위해 존재한다" 라고 못박았다.

도구는 폭주하고 있다

도구 진영도 이 흐름에 맞춰 빠르게 진화 중이다. 2026년 5월 기준 가장 많이 언급되는 코딩 도구는 Cursor, Claude Code, GitHub Copliot, Windsurf, v0 by Vercel, Bolt.new, Devin이 정도다.

특히 v0의 변화가 상징적이다. Vercel은 "90% problem"이라는 표현을 쓰는데, 현실 개발의 90%는 기존 코드베이스와 기존 인프라 안에서 일어난다 는 뜻이다. 처음엔 그린필드 프로토타입만 잘 만들면 됐던 v0가, 이제는 GitHub 저장소를 직접 가져와 작업하고, 디자인 시스템을 강제하며, 배포 환경 변수를 자동으로 끌어다 쓴다. "AI는 장난감 같은 데모만 잘 만들지 않냐" 라는 시니어들의 반론에 도구 진영이 직접 답하고 있는 셈이다.

빅테크의 코드베이스가 이 변화를 가장 잘 보여준다.

Google Sundar Pichai가 2024년 10월 Q3 어닝콜에서 "새로운 코드의 25% 이상이 AI 생성 후 엔지니어가 리뷰·승인한 것" 이라고 발표했고, 2025년 4월에는 30%+ 로 늘었다고 했다. Microsoft Satya Nadella가 2025년 4월 LlamaCon에서 "우리 코드의 최대 30%가 AI가 짠 코드" 라고 공개했다. Meta 사내 목표가 "2026년 상반기까지 65%의 엔지니어가 커밋의 75% 이상을 AI로 생성" 한다는 수준까지 올라왔다.

국내에서도 흐름은 다르지 않다. 토스는 개발자가 더 이상 문서를 찾지 않고 DX를 높이기 위해 AI 기반 문서 시스템을 구축했고, 한 발 더 나가 "AI 시대, 디자이너를 없앴더니 생긴 일" 같은 주제를 다루기도 했다. 당근은 매주 화요일 AI Show & Tell로 팀별 실험을 공유하고, "엔지니어를 넘어 빌더로" 라는 채용 슬로건을 내걸기 시작했다. 우아한형제들은 "AI가 코드 짜는 시대, 그래도 개발자가 되시겠습니까?" 같은 글을 통해 "개발자의 본질은 코드가 아니라 문제를 정의하고 해결하는 능력에 있다" 라는 메시지를 내놓고 있다.

그런데 숫자는 좀 다른 이야기를 한다

여기까지만 보면 "이제 그냥 시키면 다 되는구나" 라는 결론으로 향하기 쉽다. 그런데 실제 데이터를 들여다보면 이야기가 조금 다르다.

소프트웨어 개발 현황을 종합적으로 분석한 2025 Stack Overflow Developer Survey의 숫자를 먼저 보자.

84%의 개발자가 AI 도구를 사용하거나 사용 예정이라고 답했다. (2024년 76% 대비 상승)
전문 개발자 중 51%가 매일 AI 도구를 쓴다.
그런데 AI 도구에 대한 호감도(positive sentiment)는 오히려 떨어졌다. 2023, 2024년 70% 이상이었던 호감도가 2025년에는 60%까지 내려왔다.
10년 이상 경력 시니어 개발자들이 AI 출력물에 대한 신뢰도가 가장 낮다.

요약하면 "쓰긴 다 쓰는데, 시간이 갈수록 더 못 미덥다" 는 거다.

METR이라는 비영리 연구소에서 2025년에 진행한 실험은 이 인식과 현실의 간극을 더 극적으로 보여준다. 평균 5년 경력 + 평균 1,500커밋의 숙련된 오픈소스 개발자 16명에게 246개 작업을 시키고, 무작위로 AI 사용 여부를 배정한 통제 실험이었다. 결과는 다음과 같다.

시작 전 개발자들은 "AI를 쓰면 24% 빨라질 것" 이라고 예측했다.
작업을 마친 직후에도 "20% 정도 빨라진 것 같다" 고 자평했다.
그런데 실제 측정값은 19% 더 느려졌다.

연구진이 짚은 원인은 흥미롭다. AI가 생성한 코드의 수용률이 44% 이하 였고, 거절된 코드도 검토와 테스트엔 시간이 들었으며, 수용된 코드조차 리뷰와 수정에 상당한 시간 이 들었다는 것이다. 느려졌는데 빨라진 것 같은 착각, 이 간극이 시니어 개발자들이 AI를 점점 더 회의적으로 보는 이유 중 하나다.

여기에 "AI가 짜는 코드의 품질" 자체도 매끈하지 않다. Veracode가 100개 이상의 AI 모델에게 코드를 짜게 시킨 실험을 보자.

AI 생성 코드의 45%가 OWASP Top 10 보안 취약점을 포함했다.
XSS(크로스 사이트 스크립팅) 방어에 실패한 비율은 86%.
로그 인젝션(Log Injection) 방어 실패율은 88%.
다른 연구에서는 AI 코드의 취약점 밀도가 인간 코드 대비 2.7배 높다고 보고됐다.

특히 프론트엔드와 직결된 XSS 86% 실패는 좀 더 무겁게 받아들일 만하다. AI가 짜준 form input을 그대로 머지하는 행위 가 어떤 의미인지, 이 숫자가 잘 보여준다. (프론트엔드 보안감사에 대한 경험이 있는 개발자라면 dangerouslySetInnerHTML을 본인이 직접 작성할때도 어색함을 느끼고 걱정되는데, AI가 슬쩍 끼워넣은 건 더 무서운 것 같다.)

품질 면에서도 신호는 비슷하다. GitClear가 2020~2024년 사이 2억 1,100만 줄의 코드 변경을 분석한 결과는 이렇다.

작성 후 2주 안에 되돌려진(reverted) 코드 비율(Code Churn): 2020년 5.5% → 2024년 7.9%
리팩토링이 차지하는 비율: 2021년 25% → 2024년 10% 미만
복사·붙여넣기(클론) 비율: 2021년 8.3% → 2024년 12.3% (2025년에는 무려 4배 증가)

해석은 그리 어렵지 않다. 코드를 빠르게 찍어내는 능력은 늘었는데, 다시 손볼 만한 코드를 짜는 능력은 줄었다 는 뜻이다. Fortune 50 기업들을 분석한 Apiiro의 데이터는 더 강하게 나온다. AI 보조 개발자들은 동료 대비 커밋은 3~4배 찍어내지만, 보안 finding은 10배 더 만든다. 권한 상승 경로(privilege escalation)는 +322%, 아키텍처 설계 결함은 +153% 로 폭증했다.

AI는 무엇을 대체했고, 무엇은 대체하지 못했는가

도구는 폭주하지만 숫자는 미묘하다. 그렇다면 AI는 정확히 무엇을 대체했고, 무엇은 아직 대체하지 못했는가? 이 구분이 명확해야 우리가 어디에 시간을 투자해야 할지가 보인다.

대체된 것은 개발자들이 직접 타이핑하는 비중이 줄었다. 보일러플레이트/반복 코드 작성하는 상황이 줄고 디자인 시안만 있으면 컨밴션에 맞는 수준의 화면이 몇분안에 나오며, 문법과 API에 대한 검색 시간과 러닝 커브 속도도 급격하게 줄었다. 요컨대 AI는 '생산의 속도'를 평탄화했다.

하지만 "판단"의 영역에서는 아직 대체하지 못했다. (정확히는 "아직 기대하는 바를 충족하지 못했다" 에 가깝다. 사람마다 AI 활용 능력의 간극이 있겠지만, 여기서는 평균적인 사용 경험을 기준으로 이야기를 풀어본다.)

가장 먼저 걸리는 건 요구사항을 명세로 번역하는 일이다. 모호한 비즈니스 요구를 정확한 엣지 케이스와 상태 머신으로 옮기는 작업은 여전히 사람의 손이 더 깊게 필요하다. 시스템 차원의 영향 파악 도 마찬가지인데, 이 컴포넌트가 번들에 어떤 영향을 미치는지, 의존성이 트리쉐이킹 가능한지, 데이터 페칭 패턴이 Core Web Vitals의 INP(Interaction to Next Paint) 점수에 어떻게 영향을 주는지 같은 질문에는 AI가 그럴듯한 답을 내놓더라도 결국 사람이 한 번 더 들여다봐야 안심이 된다.

위에서 본 45% OWASP 취약점 문제처럼 보안과 위험 평가 도 빼놓을 수 없고, 새 컴포넌트가 기존 시스템의 토큰·접근성 규칙·인터랙션 패턴과 정렬되는지를 살피는 디자인 시스템과 일관성 유지, 왜 이 기능이 필요한지 어떤 유저 플로우에 끼워넣어야 하는지를 따지는 고객/시장 맥락 이해 같은 영역도 그렇다.

마지막으로 yceffort 님의 글에 나오는 표현을 빌리면 "시스템의 복잡도와 팀이 그 시스템을 이해하는 정도 사이의 격차" 라고 하면 인지 부채(Cognitive Debt) 관리 는 오히려 AI 도입 이후 더 빠르게 벌어지는 영역이라, 이 격차를 좁히는 일 자체가 사람의 몫으로 남아 있다.

없어지는 건 개발자가 아니라, 개발자가 하던 일의 형태다. 병목이 '만드는 속도'에서 '결정하는 속도'로 옮겨갔다.

같은 맥락에서, 토스의 "개발자는 AI에게 대체될 것인가"는 좀 더 묵직한 진단을 내놓는다. 글의 요지는 이렇다. AI는 모든 인력을 대체하는 게 아니라 견습 사다리(apprenticeship ladder)를 제거하고 있다. 지금 시니어들이 은퇴할 10~20년 후에는 복잡한 시스템을 설계할 차세대 인력이 부족해질 것이다. 이건 "우리 회사 내년 채용 어떡할까" 차원이 아니라 업계 전체의 시간차 폭탄 같은 문제다. (고민이 많은 시기에 정말 잘 작성된 글이라고 생각한다.)

AI가 만들어주는 "동작은 하는 첫 버전" 은 70%다. "실제 사용자에게 서비스해도 되는 버전" 까지 가는 30%가 사람의 영역이다. 그리고 그 30%를 채우는 능력은 하루아침에 생기지 않는다. 이게 견습 사다리 문제의 본질이다. 보일러플레이트와 단순 컴포넌트를 짜며 "손을 더럽히는 시간" 이 사라지면, 그 30%를 채울 사람도 같이 사라진다.

배휘동 님의 원글은 '탁월한 엔지니어의 5가지 기본 역량' 으로 좋은 코드 작성, 현재 가치 극대화(빠른 출시와 장기 유지보수성의 균형), 데이터 기반 의사결정, 동료의 효과적 의사결정 지원, 꾸준한 학습 을 꼽았다. 다섯 가지 모두 AI 시대에도 유효하지만, 그 중에서도 마지막 항목이 가장 위태로운 위치에 있다. 학습 자체가 사라진 건 아니고, 학습의 대상이 바뀌었다. 예전엔 "이 도구를 어떻게 쓰지" 를 배웠다면, 이제는 "이 시스템 전체가 어떻게 굴러가는지" 를 배우는 데 시간을 써야 한다. 더 무서운 건 Evan Moon 님이 짚은 "AI가 코드 작성을 대신하는 순간 뇌의 인지적 부하가 급격히 줄어드는 문제" 다. 인지적 부하가 줄어든다는 건 듣기엔 좋지만, 그 부하가 곧 학습의 재료 였다는 점에서 위험하다. 편해질수록 안 자란다.

여기서 자연스럽게 떠오르는 질문이 하나 있다. 그러면 배휘동 님 글의 세 가지 트랙(웹 특화/제품 특화/운영 특화)은 이제 의미가 없는 걸까?

필자의 생각은 다르다. 트랙 자체는 여전히 유효하다. 다만 각 트랙이 AI 시대에 맞춰 한 단계씩 진화 했다고 보는 게 맞다. 트랙별로 어떻게 풍경이 바뀌었는지 정리해보자.

생산자에서 '검증자'로

배휘동 님의 원글에서 웹 특화 트랙은 Software Engineer 라는 이름으로 묶여 있었다. "인터넷·웹브라우저·HTML/CSS/JS에 대한 깊이 있는 이해와 활용", 웹 생태계 도구의 장단점 파악과 트러블슈팅 경험, 새로운 기술에 민감한 태도가 핵심이고, 시니어로 가는 길로는 웹 생태계 도구 개발사 엔지니어 / 프론트엔드 교육자 / 복잡한 제품 조직의 테크 리드 가 제시됐다. 한마디로 "브라우저와 HTML/CSS/JS의 동작 원리를 깊이 파는 사람들" 이고, 1~2년 전까지 이들의 가장 큰 무기는 "그 누구보다 정확하게 코드를 짤 수 있다" 였다.

AI 시대에 이들의 가치는 어떻게 바뀌었을까? 코드 짜는 속도 만 놓고 보면 AI가 따라잡았다. 그러나 'AI가 짜준 코드를 정확히 평가할 수 있는 능력' 은 오히려 이들이 거의 독점하다시피 한다.

AI 활용하는 일반인 : 내가 원하는 요구사항으로 구현이 되었고, 동작이 정상적이네.
AI 활용하는 개발자 : 동작은 하지만 이 의존성으로 어떤 문제를 발생할 수 있고, 이런 패턴은 이렇게 개선해보는게 컨밴션에 적합해. 연관된 부분 다시 살펴보자.

앞서 다룬 Veracode 연구에서 XSS 86%, 로그 인젝션 88% 실패라는 숫자가 있었다. 이 숫자를 발견하고 잡아낼 수 있는 사람 이 바로 우리와 같은 전문가다. 이들은 AI 생산물의 품질 관리(QA) 시니어 역할로 자연스럽게 진화한다.

또 한 가지, 전문가들의 영역에 완전히 새로운 토픽 이 추가됐다. 생성형 UI(Generative UI) 와 AI 인터페이스 디자인 이다. LLM 응답을 스트리밍으로 그려주는 채팅 UI, 도중에 멈출 수 있는 abort 컨트롤, 마크다운/코드 블록 점진적 렌더링, 도구 호출 결과를 inline으로 표시하는 UX, Vercel AI SDK나 MCP(Model Context Protocol)를 활용한 어시스턴트 통합 등이 그 예다. 이 영역에서 "웹의 동작 원리를 정확히 알면서 동시에 LLM 동작 특성도 이해하고 응용/활용하는 사람" 의 수요가 폭발하고 있다.

Product Engineer로의 자연스러운 진화

제품 특화 트랙은 가장 큰 수혜를 받은 트랙이다. 시장과 고객에 대한 이해가 높고, 외부 이해관계자와 자주 소통하는 사람은 AI를 끼얹은 순간 훨씬 강력한 무기가 됐다. 시니어 경로로 그로스 엔지니어·컨설턴트 / PM·PO·CPO 전환 같은 다른 직군으로의 확장이 함께 제시되었던 것도 이 트랙의 특징이다.

흥미로운 변화는 이 트랙의 이름이 글로벌 표준으로 자리잡기 시작했다는 점이다. 원글에서도 이미 이 트랙을 'Product Engineer' 로 부르고 있었지만, 글을 읽었던 시점 필자에겐 다소 생소했던 표현이었다. 1년이 지난 지금은 Vercel이 직무 기술서의 'Fullstack Engineer'를 'Product Engineer'로 일괄 변경하는 수준으로 자리잡았다.

Lee Robinson이 정의하는 Product Engineer의 핵심 자질로 세 가지를 꼽는다.

반복(Iteration) 주의: 배포 → 피드백 → 조정의 사이클을 빠르게 돈다.
고객 중심성: 고객과 직접 대화하며 제품을 개선한다.
실용성: "기술 선택은 모두 수단일 뿐" 이다. 제품 목표에 기여하지 않는 도구는 과감히 버린다.

여기서 한 가지 함정은 제품 특화 엔지니어는 "빠르게 만드는 사람" 으로만 인식되면 위험하다. AI가 등장한 지금은 그 위험이 더 커졌다. "기능 빠르게 박는 일" 은 이제 다른 어떤 직군이라도 AI 도구로 할 수 있기 때문이다. Product Engineer의 차별점은 "고객 문제를 정확히 정의하고, 가장 작은 솔루션으로 빠르게 검증하는 능력" 에 있지, "손이 빠른 것" 에 있지 않다.

이 흐름에서 Design Engineer 라는 직군이 정식 포지션으로 격상되기 시작했다. Vercel은 디자인 엔지니어를 연봉 $200K+의 정식 트랙으로 채용 중이고, Linear, Stripe도 비슷한 방향으로 움직인다. 프론트엔드와 디자인 사이의 핸드오프 자체를 없애는 직군이다. AI가 그림은 빠르게 그려주니, "무엇을 그릴지 + 그려진 결과가 일관된 디자인 시스템에 맞는지" 를 동시에 다루는 역량이 더 희소해진 결과다.

AI 오케스트레이터

운영 특화 트랙은 가장 극적으로 변하고 있는 트랙이다. 배휘동 님의 원글에서는 이 트랙을 Full-Stack Engineer 로 분류하며 "프로젝트 구조·통합·테스트·배포에 높은 관심을 가지고, 간단한 API와 인프라를 직접 다루며 조직의 빈틈을 메우고 프로세스를 개선하는 사람" 으로 정의했다. 그 위에 1~2년 사이 AI 에이전트 자체를 운영하는 역할 이 새로 얹히면서, 트랙의 외연이 빠르게 확장되고 있다.

2026년 트렌드를 정리하면서 "오케스트레이팅 코딩 에이전트(Orchestrating Coding Agents)" 라는 개념을 핵심으로 꼽았다. 이는 하나의 AI에게 시키는 것 을 넘어 여러 AI 에이전트를 동시에 협업시키는 시스템 을 설계하고 운영한다는 의미다. 같은 맥락에서 그는 "agent-skills"라는 프레임워크를 제안하며, 프로페셔널 워크플로우와 품질 게이트, 산업 베스트 프랙티스를 에이전트의 동작 로직에 직접 인코딩하자는 의견도 나오고있다.

관련된 자료들을 취합해보니 필자가 생각하는 운영 트랙 엔지니어가 새로 다뤄야 할 키워드를 나열해보면 이렇다.

MCP(Model Context Protocol) : Anthropic이 제안한 LLM과 외부 도구 연결 표준
AI 거버넌스 : 누가 어떤 컨텍스트로 AI를 쓸 수 있는지, 시크릿이 새지 않는지 관리
에이전트 평가(Evaluation) : 에이전트가 만들어낸 결과물을 자동으로 채점하는 파이프라인
AI 게이트 : PR 머지 전 자동 보안/품질 검증, AI 코드 라벨링

원글에서는 운영 트랙의 시니어 경로로 대규모 조직의 플랫폼 팀 엔지니어 / 테크 리드 / 애자일 코치 / 테크니컬 프로그램 매니저(TPM) / CTO 같은 자리를 꼽았다. 이 경로는 지금도 유효하지만, 거기에 'AI 개발 인프라 리드', '개발자 생산성(DevProd) 엔지니어' 같은 새 자리가 추가됐다고 보면 된다.

세 트랙이 각자 진화하는 한편, 모든 트랙에서 공통으로 더 중요해진 역량 이 있다. 원래는 5년 뒤를 기준으로 생각해보고 싶었지만, 요즘 발전 속도를 보면 1년이라는 단위도 너무 크게 느껴진다. 그래서 일단 '내년' 정도로 시야를 좁혀, 필자가 보기에 더 중요해질 역량들을 짚어본다.

5가지 역량

첫 번째는 명세(Specification) 작성 능력이다. AI 시대의 "코딩의 시작점" 은 키보드가 아니라 명세 다. AI에게 무엇을 시킬지 를 정확히 적어내는 능력이 코드 그 자체보다 중요해졌다. 여기서 명세란 거창한 RFC 문서가 아니다. 비즈니스 로직의 기대 동작을 코드로 적은 테스트, UI 컴포넌트의 시나리오와 시각적 계약을 정리한 스토리북(Storybook) 스토리, 데이터 흐름의 계약을 명시하는 타입 정의 같은 것들이다. 결국 AI가 만든 결과물을 자동으로 검증할 기준 을 미리 깔아두는 작업이고, 이게 빠진 상태에서 AI 코딩을 진행하면 문제점이 누적된다.

두 번째는 검증과 판단력이다. AI는 그럴듯하지만 틀린 코드 를 자신있게 만들어낸다. 그래서 "AI 코드를 빠르고 정확히 검토하는 능력" 자체가 핵심이라고 생각한다. 보안 헤더·인풋 sanitization·CSRF 토큰을 빠뜨리진 않았는지, 접근성(ARIA·키보드 내비게이션·포커스 트랩)이 살아있는지, 렌더 비용·메모리·번들 사이즈 같은 성능 영향에 문제가 있는지 파악하는 것이다. 검토 없이 AI slop을 PR에 던지는 것은 엔지니어로서의 직무유기다. 머지 버튼을 누르는 사람은 여전히 사람이고, 그 책임은 AI에게 떠넘길 수 없다. Stack Overflow 설문에서 시니어들의 AI 신뢰도가 가장 낮은 것도, 결국 이런 디테일을 잡아내는 눈을 가지고 있기 때문 일 가능성이 높다.

세 번째는 시스템 이해와 아키텍처 사고다. AI는 한 번에 한 파일을 잘 다루고, 흐름과 연관에 대해 인지능력이 뛰어나다. AI는 증상을 빠르게 고치지만, 역량이 뛰어난 개발자는 근본 원인을 찾는다. 이 역량을 키우는 방법에 Architecture Retrospective 같은 의식적 활동을 하는 것이다. 코드의 변화 속도가 빨라진 만큼, 팀의 시스템 이해도 도 의식적으로 끌어올리지 않으면 빠르게 인지 부채가 누적된다.

네 번째는 AI 오케스트레이션 능력이다. AI 자체를 다루는 역량도 별도의 스킬셋으로 분리되고 있다. 단순히 프롬프트를 잘 쓴다 의 차원이 아니라, 작업을 작은 티켓으로 잘게 쪼개는 능력, 같은 작업에 어떤 모델을 쓸지 고르는 능력, 에이전트 평가/검증 파이프라인 설계 능력, 에이전트 실패 시 회복(rollback) 전략까지 한 묶음으로 다뤄야 하는 영역이 됐다. Steve Yegge는 이 흐름을 6개의 wave(traditional → completions → chat → coding agents → agent clusters → agent fleets) 로 정리한다.

다섯 번째는 Context Engineering이다. 2025년 중반부터 Karpathy와 Shopify CEO인 Tobi Lütke가 함께 밀기 시작한 개념으로, 한마디로 "AI에게 어떤 컨텍스트를 어떤 형태로, 얼마나 보여줄지를 설계하는 능력" 이다. 구체적으로는 프로젝트 컨벤션·아키텍처 원칙·금기 사항을 AI 손이 닿는 곳 에 정리해두는 CLAUDE.md / rules 파일 작업, 모든 파일을 컨텍스트에 넣지 않고 관련 모듈만 선별해 보여주는 컨텍스트의 의도적 축소와 계획 → 구현 → 검증 을 별도 세션으로 분리해 컨텍스트 오염을 막는 명시적 단계 분리, 디자인 시스템·API 스키마·모니터링 데이터 같은 외부 컨텍스트를 표준 인터페이스로 연결하는 MCP를 통한 외부 컨텍스트 같은 모양으로 나타난다. Anthropic의 공식 문서는 이를 "the new prompt engineering" 이라 부르며, 단일 프롬프트로는 시스템의 아키텍처 지식·패턴·tribal wisdom을 절대 담을 수 없다고 못박았다. 다시 말해, "한 번에 좋은 프롬프트를 짜는 것" 보다 "AI가 항상 좋은 컨텍스트를 받게 환경을 설계하는 것" 이 훨씬 더 중요해졌다.

여기까지 읽었다면 자연스러운 질문이 나온다. 그러면 구체적으로 어떻게 공부하면 되는데? 필자가 하고있는 방법은 대략 네 가지다.

공부법

원글에서 짚은 "꾸준한 학습" 항목은 여전히 유효하지만, 학습 시간의 배분 이 달라져야 한다.

전엔 시간을 많이 썼지만 이제 줄여도 되는 영역이 존재한다. 그에 반해 전에 어려워서 하지 않았거나, 시간이 오래걸리는 복잡한 영역도 존재한다. 후자인 경우에는 테스트 명세 작성, 성능 측정 도구 활용(Lighthouse, WebPageTest, Chrome DevTools Performance), 접근성(WCAG), 보안(특히 OWASP Top 10) 등이 있다. 그리고 Vercel AI SDK, LangChain.js, MCP, 스트리밍 UI 패턴, 에이전트 평가 파이프라인 같이 완전히 새롭게 익혀야 하는 영역도 존재한다. 나에게 필요한 역량이 무엇인지 인지하고 시간을 배분하는게 중요하다.

AI가 만들어내는 코드는 크기가 커지기 쉽다. 1분에 몇백줄을 뽑아낸다. 그래서 PR 사이즈와 머지 주기를 의식적으로 관리 하지 않으면 코드 리뷰 자체가 무너진다. 사내에서 AI 도입 이후 평균 PR 크기 +18%, PR당 인시던트 +24%, 변경 실패율 +30% 되었다. 앞서 이야기 나눈 데이터와 함께보면 크게 짜고 한 번에 머지하면 흐름을 파악하고 의도를 반영하기 어렵기때문에 작업 단위를 세분화하는게 중요하다.

Evan Moon 님의 글에서 짚은 인지적 부하 감소 문제와 직결되는 이야기가 있다. 하루에 한두 시간은 AI 없이 코드를 짜는 시간 을 따로 확보하는 게 좋다. 아키텍처를 손으로 그려보거나, 익숙하지 않은 영역의 코드를 직접 한 줄씩 읽어보는 활동이 그 예다. (필자도 매일 점심 식사 이후 나른한 시간엔 AI 없이 코드를 짜본다. 옛 익숙함에서 멀어지지 않게 붙들어두는 시간이다.)

이게 단순히 "옛 방식을 잊지 않기 위해" 가 아니다. AI가 대신 해주는 시간만큼 본인의 깊이도 자라지 않기 때문이다. 검증과 판단력, 시스템 이해 같은 역량은 직접 부딪쳐 본 시간의 함수다.

그래서 우리는

여기까지 길게 적었지만, 사실 AI 시대에 살아남는 프론트엔드 엔지니어 의 모습은 원글이 내놓은 결론과 그렇게 다르지 않다. 원글에서 꼽았던 좋은 시니어 엔지니어의 세 가지 포인트 는 이랬다.

기본에 충실 하고자 노력한다. (5가지 기본 역량을 지속적으로 유지·강화)
명시적 리더가 아니더라도 모범적 행동으로 자연스러운 영향력을 발휘한다.
주어진 일을 잘 끝마치는 것에 만족하지 않고, 전후 맥락을 살피며 큰 영향력을 만든다.

이걸 AI 시대 관점으로 적용하면 이렇게 된다.

AI가 만들어주는 코드 너머의 기본기(웹, 시스템, 도메인)에 충실하다.
AI가 아니라 자신이 방향을 정한다. 명시적 책임자가 아닐 때조차 "어디로 가야 하는지" 를 결정한다.
AI를 개인 생산성 도구로만 쓰지 않고, 팀과 시스템의 병목을 푸는 데 쓴다.

Open AI의 권위자인 Andrej Karpathy의 글을 살펴보면, 그가 지금 강조하는 "agentic engineering" 의 핵심도 결국 같다. 시스템을 설계하고, 제약을 명세하고, 이미 머릿속에서 추론을 마친 구현을 AI로 가속화하는 것. 도구가 바뀌어도, 방향키는 여전히 사람 손에 있다 는 이야기다.

원글이 마지막에 던지는 메시지도 결국 "주어진 일을 잘 끝마치는 데에 만족하지 않고, 전후 맥락을 살피며 큰 영향력을 만드는 사람" 이 시니어가 된다는 것이었다. AI 시대에는 그 "임팩트" 의 정의가 달라졌을 뿐이다. AI가 1시간 만에 만들어낸 화면 하나를 "동작하니까 됐다" 로 머지하는 사람과, 그 화면이 접근성·보안·성능·시스템 정합성 면에서 어디까지 합리적인지를 30분 더 살피는 사람이 있다. 1년 뒤 시니어로 인정받는 건 후자다. 70%(동작)와 30%(응용과 활용)의 경계 위에서, 30% 쪽에 서 있는 사람 이 살아남는다.

이 글을 읽는 프론트엔드 엔지니어 분들도 "이제 뭘 더 공부해야 하지?" 라는 질문에 본인만의 답을 가지고 가셨으면 한다. 정답은 아무도 모르지만, AI가 코드를 짜는 시대일수록 더 "코드 너머의 것" 을 보는 사람이 살아남으리라는 점만큼은 필자는 꽤 확신하는 편이다. 1년 뒤 또 한 번 이 풍경이 어떻게 바뀌었을지, 그때 다시 글로 정리해볼 수 있길 바라며 마친다.

(혹시 이 글이 1년 뒤에는 너무 뻔하거나 낡은 이야기로 보인다면, 그만큼 우리가 잘 대응했다는 뜻이 아닐까싶다)

AI 프론트엔드 엔지니어

"이제 AI가 다 해주는 거 아니에요?"

도구는 폭주하고 있다

그런데 숫자는 좀 다른 이야기를 한다

AI는 무엇을 대체했고, 무엇은 대체하지 못했는가

생산자에서 '검증자'로

Product Engineer로의 자연스러운 진화

AI 오케스트레이터

5가지 역량

공부법

그래서 우리는

참고 자료

📚함께 읽으면 좋은 글

상태 관리

도메인 모델

Toss Frontend Fundamentals 모의고사 2회차 리팩토링 후기

댓글