개요

올해 1월 새로운 회사에 합류한 이후, 업무에서 Claude와 Codex를 매일 사용하고 있습니다. 지난 글에서 두 서비스의 모델별 차이를 정리했다면, 이번 글에서는 모델이 아니라 그 모델과 함께 일하는 개발자의 이야기를 다룹니다.

AI 모델의 성능이 빠르게 올라가면서 프론트엔드 개발자의 업무도 크게 달라졌습니다. 코드를 직접 작성하는 시간은 줄었고, AI에게 무엇을 어떻게 맡길지, 그 결과물을 어떻게 신뢰할 수 있을지 고민하는 시간이 늘었습니다. 이 글에서는 그 과정에서 계속 붙잡고 있던 세 가지 질문을 정리합니다.

이 글에서 다루는 질문은 다음과 같습니다.
- 바이브 코딩으로 만든 결과물은 어떻게 검증해야 할까?
- 토큰 사용량을 줄이는 것이 왜 개발자의 역량이 되었을까?
- 개발자가 아니어도 개발할 수 있는 시대에 개발자는 어디로 가야 할까?

이제 코드는 AI와 함께 작성한다

현재 업무에서 작성하는 코드의 상당 부분은 AI와 함께 만들고 있습니다. 그러다 보니 코드를 얼마나 빠르게 작성하느냐보다, AI가 프로젝트의 기준을 지키며 일하도록 만드는 것이 훨씬 중요해졌습니다.

규칙과 스킬이란?
규칙은 CLAUDE.md, AGENTS.md 같은 파일에 프로젝트가 지켜야 할 코드 컨벤션과 원칙을 정리해 두고, AI가 작업할 때마다 읽고 따르게 하는 방식입니다. 스킬은 커밋 작성, 코드 리뷰처럼 반복되는 작업의 절차를 문서로 묶어 두고 필요할 때만 불러 쓰는 방식입니다.

저는 가독성, 예측 가능성, 응집도, 결합도 네 가지 기준으로 정리한 프론트엔드 코드 규칙을 전역 규칙 파일에 두고 사용합니다. 토스의 Frontend Fundamentals에서 제시하는 좋은 코드의 네 가지 기준이기도 합니다. 매직 넘버 대신 이름 있는 상수를 쓰고, 중첩 삼항 연산자를 쓰지 않으며, 함수 이름에 드러나지 않는 부수효과를 숨기지 않는 식입니다. 커밋 메시지와 브랜치 이름 규칙도 정해 두고 AI가 그대로 따르게 합니다.

규칙을 세우고, 스킬을 활용하고, 프롬프트를 다듬어 토큰 사용량을 줄이는 일. 예전에는 요령 정도로 여겼던 이 일들이 이제는 개발자의 분명한 강점이 될 것이라고 생각합니다.

가장 큰 고민, 바이브 코딩의 결과물은 어떻게 검증할까

AI로 개발하면서 가장 오래 붙잡고 있던 질문은 "검증은 어떻게 할 것인가?"였습니다.

올해 초에 작성한 바이브 코딩 글에서 저는 "생성된 코드를 반드시 읽어요"라고 적었습니다. 그런데 AI가 만들어 내는 코드의 양이 사람이 읽을 수 있는 속도를 넘어서면서, 이 원칙 하나만으로는 감당하기 어려워졌습니다. 모든 줄을 읽으면 AI를 쓰는 의미가 줄어들고, 읽지 않으면 불안했습니다.

토스 모닥불에서 얻은 힌트

이 고민에 방향을 잡아 준 것은 토스 프론트엔드 챕터의 기술 토크인 "모닥불"이었습니다. 이를 통해 토스 프론트엔드 개발자들이 AI를 실제로 어떻게 활용하는지 알 수 있었습니다.

가장 크게 와닿은 것은 목표를 바라보는 관점이었습니다. 프로젝트를 진행하고 서비스를 만들 때 무엇보다 우선되는 것은 기간 안에 개발을 완료하고, 고객이 아무 문제 없이 서비스를 사용하는 것입니다.

검증의 기준이 바뀌었다
주어진 규칙 안에서라면 코드를 어떻게 작성했는지보다 서비스가 완전히 잘 작동하는지가 더 중요합니다. 코드 한 줄 한 줄이 아니라, 고객이 경험하는 "서비스의 동작"을 검증하는 방향입니다.

토스에서는 구현이 끝나면 테스트도 AI를 통해 진행한다고 합니다. 코드 리뷰, QA, E2E 테스트를 AI에게 맡기고, 특히 단순한 기능 테스트도 E2E 방식으로 진행한다는 점이 인상적이었습니다. 또한 E2E 문서를 별도로 만들어 테스트를 진행하고, AI가 수행하는 테스트와 사람이 직접 수행하는 테스트를 병합해 검증합니다.

단순한 기능도 E2E로 테스트하는 이유

단위 테스트는 함수의 입력과 출력을 확인하지만, 고객은 함수가 아니라 화면을 사용합니다. E2E 테스트는 실제 사용자처럼 화면을 열고, 클릭하고, 결과를 확인하기 때문에 "고객이 문제없이 사용한다"는 목표를 가장 직접적으로 검증합니다.

AI와 함께 개발할 때는 장점이 하나 더 있습니다. AI는 같은 기능이라도 요청할 때마다 내부 구현을 조금씩 다르게 작성합니다. 구현 방식에 의존하는 테스트는 그때마다 깨지지만, 동작을 확인하는 E2E 테스트는 내부 구현이 바뀌어도 그대로 유효합니다.

E2E 문서 작성 예시

E2E 문서에는 사전 조건, 사용자 시나리오, 그리고 각 시나리오를 누가 검증할지를 정리합니다. 최근 작업한 앱 간 테마 공유 기능을 예로 들면 다음과 같습니다.

1// E2E 시나리오 문서 예시 - 앱 간 테마 공유
2
3[사전 조건]
4- 테마 쿠키 없음, OS 설정은 다크 모드
5
6[시나리오]
71. 홈에 처음 접속하면 화면이 그려지기 전에 다크 테마가 적용된다
82. 포트폴리오에서 라이트로 바꾸면 블로그와 이력서에서도 라이트로 보인다
93. 새로고침해도 라이트 테마가 유지된다
10
11[검증 담당]
12- AI: 1~3번을 Playwright로 자동 실행하고 결과를 보고
13- 사람: 실제 휴대폰 브라우저에서 2~3번을 직접 확인

AI는 정해진 시나리오를 빠르고 반복적으로 확인하는 데 강하고, 사람은 실제 기기에서의 체감이나 문서에 없던 어색한 동작을 찾아내는 데 강합니다. 두 테스트를 병합하는 이유가 여기에 있습니다.

AI가 작성한 테스트를 같은 AI가 통과시키는 구조만으로는 부족합니다. 무엇을 검증할지 정하는 E2E 문서는 사람이 작성하거나 반드시 검토하고, AI는 그 시나리오를 실행하고 보고하는 역할로 나누는 것이 안전합니다.

토큰 사용량이 곧 비용이다

두 번째 고민은 토큰입니다. Claude나 Codex의 구독 비용은 기업 입장에서 결코 적지 않습니다. 개발자 한 명이 아니라 팀 전체가 사용한다면 더욱 그렇습니다.

문서 작업이 최적화되어 있지 않거나 프롬프팅 방법이 잘못되었다면 그만큼 토큰이 더 소모됩니다. 구독 요금제라면 사용 한도에 더 빨리 도달하고, API를 사용한다면 그대로 비용으로 청구됩니다.

토큰 절약이 역량인 이유
프로젝트와 서비스의 규칙은 모두 지키면서 원하는 결과물을 얻되, 토큰 사용량은 줄여야 합니다. 같은 결과를 더 적은 비용으로 만들어 내는 능력이 이제 개발자의 역량이 되었습니다.

실무에서 토큰을 줄이기 위해 실천하고 있는 네 가지 방법을 소개합니다.

1. 규칙 파일은 짧고 단단하게

규칙 파일은 작업을 시작할 때마다 함께 읽힙니다. 한 줄이 늘어날 때마다 모든 요청에 비용이 더해지는 셈입니다. 항상 지켜야 하는 원칙만 남기고, 자세한 예시는 별도 문서로 분리해 필요할 때만 참고하게 합니다.

2. 반복 작업은 스킬로

스킬은 평소에는 이름과 설명만 읽히고, 해당 작업을 수행할 때만 본문을 불러옵니다. 매번 같은 설명을 프롬프트에 붙여 넣는 것보다 토큰도 적게 들고 결과도 일정합니다.

3. 프롬프트는 범위를 좁혀서

범위가 넓으면 AI가 저장소 전체를 탐색하느라 토큰을 많이 사용하고, 의도와 다른 곳을 수정하기도 합니다.

1// 범위가 넓은 프롬프트
2"블로그가 느린데 고쳐 줘."
3
4// 범위를 좁힌 프롬프트
5"apps/blog 상세 페이지의 본문 렌더링이 느려.
6PostMarkdown 컴포넌트부터 원인을 확인하고,
7UI/UX는 지금과 똑같이 유지한 채 렌더링 속도만 개선해 줘.
8작업이 끝나면 변경 전후 렌더링 시간을 비교해서 보고해 줘."

4. 모델 선택과 대화 정리

단순한 작업에 최상위 모델을 사용하지 않고, 대화가 길어지면 지금까지의 내용을 요약해 새로 이어갑니다. 대화가 길어질수록 매 요청에 이전 대화가 함께 전달되기 때문입니다. 저 역시 긴 작업을 하나의 대화에서 계속 이어가다가 "Prompt is too long" 메시지와 함께 작업이 중단된 경험이 있습니다.

토큰을 아끼려고 규칙을 빼서는 안 됩니다. 규칙을 지키지 못한 결과물은 다시 수정해야 하고, 그 재작업에 더 많은 토큰이 사용됩니다. 줄여야 하는 것은 규칙이 아니라 중복과 모호함입니다.

개발자가 아니어도 개발할 수 있을까

여기까지 보면 자연스럽게 하나의 질문이 떠오릅니다. "개발을 AI에게 맡긴다면, 개발자가 아닌 사람도 개발할 수 있지 않을까?"

예전이었다면 아니라고 답했을 것입니다. 하지만 지금은 인정하게 되었습니다. 서비스의 목표와 고객이 원하는 니즈를 정확히 도출할 수만 있다면, 개발은 이제 누구나 할 수 있는 영역이 되었습니다.

반대의 경우도 마찬가지입니다. 개발자도 이제는 서비스 기획을 할 수 있고, 다양한 레퍼런스를 바탕으로 디자인까지 할 수 있습니다. 기획, 디자인, 개발 사이에 있던 경계가 양쪽에서 동시에 흐려지고 있습니다.

이제 가장 중요한 것은?
코드를 작성하는 능력보다 "무엇을, 누구를 위해 만들지" 정의하는 능력입니다. 서비스의 목표와 고객의 니즈가 출발점이 되면 기획자도, 디자이너도, 개발자도 같은 결과물에 도달할 수 있습니다.

채용 공고가 먼저 바뀌고 있다

이 변화는 채용 시장에서 가장 먼저 나타났습니다. 올해 1월 취업한 이후에도 AI로 빠르게 변하는 채용 시장을 수시로 확인했습니다. 불과 상반기만 해도 "AI를 활용하여 서비스 개발을 진행하신 분"이라는 문장은 우대사항에 있었습니다. 지금은 이 문장이 필수 자격요건으로 올라왔습니다.

직군의 이름도 바뀌고 있습니다. 프론트엔드 개발자에서 풀스택 개발자로, 그리고 이제는 프로덕트 엔지니어와 빌더라는 직군이 채용 공고에 등장하고 있습니다.

프로덕트 엔지니어, 빌더란?
기획부터 디자인, 개발까지 하나의 프로젝트를 책임지고 진행하는 직군입니다. 최근에는 같은 직군 안에서도 프론트엔드에 강한 빌더, 디자인에 강한 프로덕트 엔지니어처럼 각자의 강점 분야를 함께 요구하는 공고가 늘고 있습니다.

여기서 다룬 채용 시장의 변화는 직접 확인한 채용 공고를 바탕으로 한 개인적인 관찰입니다. 회사와 시기에 따라 다를 수 있습니다.

앞으로 개발자에게 필요한 역량

AI로 인해 빠르게 변화하는 시장에서 명확한 방향은 아직 정해져 있지 않습니다. 다만 회사의 디자이너분과 이 주제로 수시로 토론하면서 한 가지 의견이 모였습니다. 앞으로는 하나의 기술에 치중하지 않고, 여러 영역을 복합적으로 다룰 수 있는 직군을 추구하게 될 것이라는 점입니다.

그만큼 알아야 할 지식은 많아지고, 기업이 찾는 인재상도 달라질 것으로 예상합니다. 이러한 흐름 속에서 강점이 될 네 가지 역량은 다음과 같습니다.

규칙과 스킬을 설계해야 합니다. AI가 프로젝트의 기준을 지키며 일하도록 만드는 힘입니다. 규칙과 스킬이 잘 정리되어 있을수록 AI 협업의 결과물이 안정됩니다.

동작으로 검증해야 합니다. E2E 문서를 기준으로 AI 테스트와 사람 테스트를 병합해, 코드가 아니라 서비스의 품질을 보장합니다.

토큰을 아끼는 감각이 필요합니다. 같은 결과물을 더 적은 비용으로 만들어 내는 문서와 프롬프트가 곧 경쟁력입니다.

기획과 디자인까지 바라봐야 합니다. 서비스 목표와 고객 니즈에서 출발해 개발까지 이어 가는 관점이 프로덕트 엔지니어와 빌더의 핵심입니다.

마무리

퇴사 회고에서 "개발자들의 능력은 어디서 나뉘어질까?"라는 질문을 던졌을 때, 저는 깊이감이라고 답했습니다. 지금은 여기에 하나를 더하고 싶습니다. 깊이를 바탕으로 기획과 디자인, 검증과 비용까지 넓게 바라보는 시야입니다.

AI가 코드를 작성하는 시대에도 서비스를 기간 안에 완성해 고객에게 문제없이 전달하는 책임은 여전히 사람에게 있습니다. 그 책임을 지는 사람을 프론트엔드 개발자라고 부르든, 프로덕트 엔지니어나 빌더라고 부르든 이름은 크게 중요하지 않을지도 모릅니다. 중요한 것은 변화를 두려워하기보다 먼저 사용해 보고, 검증하고, 더 잘 활용하는 방법을 고민하는 태도입니다.

핵심 정리
- AI 시대의 검증은 코드 한 줄이 아니라 서비스의 동작을 기준으로 한다.
- E2E 문서를 별도로 만들고, AI 테스트와 사람 테스트를 병합해 검증한다.
- 규칙은 지키되 중복과 모호함을 줄여 토큰 사용량을 최소화한다.
- 기획, 디자인, 개발의 경계가 흐려지면서 프로덕트 엔지니어와 빌더 같은 복합 직군이 늘고 있다.
- 하나의 기술에 치중하기보다 서비스 전체를 바라보는 시야를 넓혀 간다.