AI 도구를 쓴다는 것은 이제 선택이 아니다. 문제는 '어떻게 쓰느냐'다. 그런데 이 질문은 생각보다 훨씬 정밀하게 쪼개진다. 코드 생성을 맡길 것인가, 아키텍처 판단을 위임할 것인가, 모델 추론 자체를 어디서 실행할 것인가. 최근 세 가지 현장 이야기가 이 질문에 각각 다른 각도로 답하고 있다.
컨텍스트가 없으면 AI는 그냥 자동완성이다
dev.to에 올라온 한 글은 Cursor와 Claude Code를 수개월 사용한 뒤 내린 솔직한 결론으로 시작한다. 도구는 빨라졌고 모델은 똑똑해졌는데, 정작 본인의 산출물 품질은 그 속도를 따라가지 못했다는 것이다. 원인은 모델이 아니었다. 입력이 부실했다.
해결책은 뜻밖에 아날로그적이다. Cursor를 열기 전에 먼저 문서를 쓴다. Mermaid 다이어그램, 테이블 레이아웃, 엔드포인트 계약서—보통이라면 아무도 안 읽는 README에 묻힐 것들이다. 그런데 이걸 Cursor의 composer에 던져 넣으면 모델이 단어를 패턴 매칭하는 게 아니라 관계를 유지하면서 코드를 생성한다는 걸 체감했다고 한다. 반대로 채팅으로만 대화하면 아름다운 모델을 만들어 놓고 이전 턴에서 언급한 컬럼을 잊어버려 외래 키가 허공을 가리키는 상황이 반복됐다.
이 이야기에서 진짜 인사이트는 '문서를 쓰라'는 방법론이 아니다. AI는 컨텍스트 윈도우 안에 있는 것만 추론한다는 원리다. 프롬프트 엔지니어링이 결국 '내가 알고 있는 것을 AI가 알 수 있는 형태로 구조화하는 작업'임을 다시 확인시켜 준다. 모델을 탓하기 전에 내가 제공한 컨텍스트의 밀도를 먼저 점검해야 한다.
서버를 없애는 설계, 그 자체가 프로덕트 판단이다
두 번째 이야기는 방향이 완전히 다르다. 브라우저 안에서 Whisper를 돌려 서버 없이 자막을 생성하는 Captionly 프로젝트다. WebGPU, WebCodecs, transformers.js를 조합한 클라이언트 사이드 아키텍처인데, 이 선택이 단순한 기술 실험이 아니라는 점이 흥미롭다.
기존 자막 도구들은 영상을 서버로 업로드한다. 200MB MP4라면 처리 시작 전에 이미 30초 이상이 날아간다. 거기다 개인 영상이 누군가의 S3에 올라가고, GPU 비용은 프리미엄 요금제로 돌아온다. 이 프로젝트의 아키텍처는 그 세 가지 문제를 한 번에 뒤집는다. 파일이 기기를 떠나지 않고, 대기 없이 즉시 처리가 시작되며, 서버 비용이 제로다.
기술 스택은 '최근 18개월 사이 브라우저에 생긴 것들'의 조합이다. Chrome 113+와 Safari 18에서 실제 GPU 연산이 가능해진 WebGPU, 서버 없이 하드웨어 가속 비디오 디코딩·인코딩을 처리하는 WebCodecs, 그리고 ONNX Runtime Web 위에서 Whisper와 Llama를 포팅한 transformers.js. 이것들이 맞물리면 파이프라인 전체가 브라우저 안에서 완결된다.
물론 함정도 명확하다. WebGPU가 없으면 WASM 폴백으로 떨어지고 성능이 10배 차이 난다. Safari 18은 WebGPU를 지원하지만 transformers.js가 쓰는 f16 연산은 18.4부터다. 안드로이드 일부 기기는 WebGPU가 있다고 보고하지만 첫 커널에서 크래시가 난다. 개발자는 이 모든 경우에 무음 실패를 허용하지 않고 사용자에게 명시적으로 알린다고 했다. 10배 성능 차이를 조용히 숨기는 건 UX가 아니라 기만이라는 판단이다.
이 아키텍처 결정에서 중요한 것은 '브라우저에서 AI를 돌릴 수 있다'는 기술적 가능성이 아니다. '서버를 없애는 것'이 곧 프라이버시 보장이고, UX 개선이며, 비용 구조의 재설계라는 점이다. 기술 선택이 프로덕트 결정이 되는 순간이다.
8배 빠르다는 말이 가리는 것
세 번째 목소리는 40년 경력의 시니어 아키텍트에서 나온다. Anthropic이 발표한 내용 중 "엔지니어들이 분기당 8배 더 많은 코드를 배포한다"는 수치, 그리고 병합된 코드의 80% 이상이 Claude가 작성했다는 사실을 두고 그는 "매니저에겐 꿈이지만, 시니어 아키텍트에겐 기술 부채의 악몽처럼 보인다"고 말한다.
그가 짚는 핵심은 예리하다. Anthropic 스스로 인정했듯, AI는 코드 최적화에서 최대 52배 빠를 수 있지만 "목표를 선택하는 판단"에서는 여전히 큰 격차가 있다. 그리고 그 40년 경험이 말해주는 것은 "목표를 고르는 것이 진짜 일이고, 문법을 쓰는 건 사무 작업" 이라는 사실이다. 사무 작업을 8배 빠르게 자동화했는데 판단을 잃었다면, 그건 생산성이 아니라 복잡도를 8배 빠르게 쌓은 것이다.
그가 드는 사례는 섬뜩하다. 2026년 2월, AI가 생성한 스마트 컨트랙트의 계산 오류로 4분 만에 170만 달러가 증발했다. Vibe Coding—AI와 대화하고 출력을 믿고 빌드하는 방식—은 "통계적으로 그럴듯한 답"을 생성할 뿐, 시스템 다운타임의 무게를 느끼지 못한다.
그의 철학은 "Code is Craft"다. LLM 시대에 개발자의 역할은 C++이나 Python 문법을 아는 것이 아니라—AI가 이미 그 벤치마크를 포화시켰으니—의도의 아키텍처(Architecture of Intent)를 설계하는 것이다. AI는 손이고, 방향과 의미는 여전히 사람이 정한다.
세 이야기가 모이는 지점
얼핏 다른 이야기처럼 보이지만, 세 사례는 같은 질문을 향해 수렴한다. AI에게 무엇을 위임하고, 어디서 내가 직접 판단해야 하는가.
첫 번째 이야기는 실행 레이어의 위임 방식을 다룬다. 코드 생성은 AI에게 맡기되, 컨텍스트 구조화—관계를 정의하고 계약을 명문화하는 일—는 개발자가 먼저 해야 한다. AI가 잘 동작하려면 내가 먼저 잘 생각해야 한다.
두 번째 이야기는 아키텍처 레이어의 위임 경계를 다룬다. AI 모델의 실행 자체를 어디서 할 것인지—서버냐 클라이언트냐—는 성능이나 비용만의 문제가 아니라 프라이버시, UX, 비즈니스 모델을 동시에 결정하는 선택이다. 이 결정은 위임할 수 없다.
세 번째 이야기는 판단 레이어의 소유권을 다룬다. 속도 지표가 좋아 보일수록, 내가 이해하지 못한 코드가 쌓이고 있을 가능성이 높다. '왜 이렇게 설계했는가'를 1년 뒤에도 설명할 수 있어야 진짜 내 코드다.
결국 AI 도구를 잘 쓴다는 것은 더 많은 걸 위임하는 게 아니다. 위임 가능한 것과 위임해선 안 되는 것의 경계를 점점 더 정밀하게 그려가는 것이다. 그 경계를 설계하는 능력이야말로 AI 시대 프론트엔드 개발자의 핵심 역량이 되고 있다.