도구는 바뀌었다. 그런데 주도권은 어디 있나?
Claude Code가 터미널에서 프로젝트 전체를 읽고, 멀티 파일을 수정하고, git commit까지 날리는 시대가 됐다. 브런치에 올라온 한 개발자의 사용기는 이 경험을 이렇게 표현한다. "옆자리에 시니어 개발자가 앉아서 직접 코딩해주는 느낌." 단순한 자동완성이 아니라, 프로젝트 맥락을 이해하고 능동적으로 움직이는 에이전트다.
그런데 이 장면에서 정작 중요한 질문이 하나 빠져 있다. 시니어가 코딩을 해준다면, 나는 무엇을 하고 있어야 하나?
심리의 균열: 두 종류의 상실감
GeekNews에 공유된 한 개발자의 글은 AI 코딩 도구의 확산이 개발자 사이에 오래 잠들어 있던 분열을 수면 위로 끌어올렸다고 진단한다. 분열의 축은 단순하지 않다. '저항파 vs 수용파'가 아니라, 상실의 종류가 다르다는 것이 핵심이다.
한쪽은 코드를 손으로 빚던 장인적 만족감을 잃는 것을 슬퍼한다. 새벽 2시에 디버거로 버그를 잡던 그 감각, "내가 만들었다"는 자부심. 다른 한쪽은 코드 작성 행위 자체가 아니라 코드를 둘러싼 생태계와 커리어 지형이 바뀌는 것을 슬퍼한다. 30년 넘게 해온 웹 개발이 더 이상 뜨거운 분야가 아닌 현실, AI 엔지니어링이 중심을 차지하는 구조적 변화.
이 두 슬픔은 처방이 다르다. 장인적 상실을 겪고 있다면 "그냥 적응해"라는 말은 아무 도움이 안 된다. 반면 맥락적 상실을 겪고 있다면, 새 도구를 익히고 역할을 재정의하는 실행 가능한 대응이 있다. 자신이 어느 쪽 슬픔을 느끼는지 먼저 인식하는 것, 그게 출발점이다.
추상화의 사다리: 프론트엔드는 어디로 올라가나
흥미롭게도, 이 글의 필자는 결국 공포가 아닌 적응을 선택했다. C64 BASIC에서 어셈블리로, 함수에서 시스템 설계로 이어졌던 커리어의 모든 전환이 같은 패턴이었다는 것. AI 코딩은 불연속이 아니라 추상화 사다리의 다음 칸이다.
퍼즐은 사라지지 않았다. 한 단계 위로 이동했을 뿐이다. 이제 퍼즐은 아키텍처, 구성, 에이전트를 지휘하는 영역에 있다. 수십 년간 코드를 읽고 리뷰하며 쌓은 감각은 AI가 생성한 코드의 품질을 판단하는 눈으로 여전히 유효하다. 무언가 잘못됐을 때 알아채는 것, 그 안목은 증발하지 않는다.
프론트엔드 개발자에게 이 전환은 더 구체적인 질문을 던진다. 코드를 AI에게 넘겼을 때, 설계 결정권은 누가 가져가는가?
UI 설계 주도권: 서버가 빼앗으려는 것
Velog에 올라온 한 글은 이 질문에 날카롭게 응답한다. Server-Driven UI 논의가 재점화되면서, UI 노출 로직을 서버가 통제해야 한다는 주장이 힘을 얻고 있다. A/B 테스트를 앱 배포 없이 실시간으로 바꾸고, 날짜·통화 포맷을 전사적으로 통일하고, 정책 변경을 즉시 반영한다는 논리다. 유연성과 일관성의 관점에서 설득력 있는 주장이다.
그런데 이 논리를 끝까지 밀면, 클라이언트는 서버의 렌더링 엔진으로 전락한다. API가 "15,000"이라는 숫자 대신 "15k+"라는 표현을 내려보내는 순간, 프론트엔드는 데이터를 해석하고 표현하는 주체가 아니라 서버의 결정을 출력하는 터미널이 된다.
물론 서버가 다뤄야 할 영역은 분명히 있다. 사용자가 조작해선 안 되는 비즈니스 판단, 보안 정책, 권한 제어. 하지만 인터랙션의 흐름, 피드백의 타이밍, 상태 전환의 감각 같은 것들은 클라이언트가 온전히 소유해야 할 영역이다. 이것이 프레젠테이션 레이어(Presentation Layer)의 존재 이유다. 서버는 데이터와 정책을 주고, 클라이언트는 그것을 어떻게 경험으로 만들지를 결정한다.
CLAUDE.md가 상징하는 것
Claude Code의 CLAUDE.md 기능은 이 맥락에서 다시 읽힌다. 프로젝트 루트에 기술 스택, 코딩 컨벤션, 주의사항을 적어두면 에이전트가 세션마다 읽는다. 한마디로, 개발자가 에이전트에게 맥락을 주입하는 구조다.
이것은 역할 역전이 아니다. 오히려 역할의 명확화다. AI는 구현을 맡는다. 개발자는 맥락을 설계하고, 결과를 판단하고, 다음 방향을 결정한다. 코드를 직접 타이핑하지 않더라도, 무엇을 만들지·어떤 원칙으로 만들지·어디까지 허용할지를 정의하는 사람은 여전히 개발자다.
Server-Driven UI 논쟁도 같은 구도로 읽힌다. 서버가 UI 결정을 가져가는 것이 효율적으로 보일 수 있지만, 그 결정의 품질과 사용자 경험의 일관성을 책임질 주체는 결국 프론트엔드다. 설계 주도권을 내주는 것은 책임을 내주는 것과 다르지 않다.
시사점: '무엇을 결정하는가'가 새 직무 기술서
AI 코딩 도구가 성숙할수록, 프론트엔드 개발자의 가치는 타이핑 속도가 아닌 판단의 품질로 재편된다. 몇 가지 방향이 눈에 들어온다.
첫째, 컨텍스트 설계 능력이 핵심 스킬이 된다. CLAUDE.md처럼 에이전트에게 좋은 맥락을 주는 것, 즉 프로젝트의 의도와 원칙을 구조화하는 능력이 코드 생성 능력만큼 중요해진다.
둘째, 설계 경계선을 지키는 감각이 필요하다. Server-Driven UI가 편의를 제공하는 영역과, 클라이언트가 주권을 가져야 하는 영역을 구분하는 것. 이 경계를 흐릿하게 두면 사용자 경험의 일관성과 인터랙션의 품질이 서서히 무너진다.
셋째, AI가 생성한 코드를 읽는 눈은 여전히 경험에서 나온다. 수십 년간 코드를 리뷰하며 쌓은 감각이 AI 시대에도 유효하다는 것, 이것이 시니어 개발자들이 쉽게 대체되지 않는 이유다.
전망: 사다리 위에서 보이는 것
AI가 코드를 짜는 세상에서 개발자가 잃는 것은 분명히 있다. 손으로 코드를 빚던 감각, 특정 생태계에서의 커리어 안정감. 이 상실을 부정할 이유는 없다.
그러나 얻는 것도 있다. 아키텍처를 고민할 시간, 사용자 경험을 더 깊이 설계할 여유, 구현이 아닌 의도에 집중할 공간. 추상화 사다리를 한 칸 올라간 자리에서 보이는 풍경이다.
결국 AI 코딩 시대의 프론트엔드 개발자는 더 많이 코딩하는 사람이 아니라, 더 잘 결정하는 사람이 되어야 한다. 무엇을 만들지, 어떤 원칙으로 만들지, 어디서 서버와 경계를 그을지. 설계 주도권은 도구가 가져가는 것이 아니다. 놓아버리는 사람에게서 빠져나갈 뿐이다.