[AI] 에이전트 코딩 시대에 front-end 개발자로서의 역할에 대한 고찰

2026. 4. 6. 20:04ㆍ개발로그

1. 들어가며

 

한창 웹 브라우저용 멀티미디어 에디터 제작에 집중하던 중, 어느 날 단체 챗방에 이런 문서가 올라왔다.

 

"생존을 위한 개발부 전환 - AI Agent 활용 Micro SaaS 이원화 전략"

 

 

상세하게 밝힐 순 없지만, 내용은 대략 이랬다.

현재 개발부의 매출 기여가 없다. AI Agent를 활용해 Micro SaaS를 빠르게 찍어내서 매출을 만들자. 핵심 프로젝트는 기존 방식대로, Micro SaaS는 바이브코딩으로 24시간 내 런칭을 목표로 하자. 그리고 마지막에 이런 질문이 있었다.

"프론트엔드 역할 변화: AI가 페이지를 생성하는 시대에 FE 개발자의 핵심 역할은?"

 

 

각자 생각을 정리한 후 논의하는 시간을 가져야 했다. 솔직히 말하면, 사실상 "회사에서 나를 왜 고용해야 하는가"를 증명해야 한다는 얘기다.

 

2. Micro SaaS란?

Micro SaaS는 소규모 인원(보통 1~3명)이 특정 니치 시장을 겨냥해 빠르게 만들고, 빠르게 검증하는 초소형 SaaS 제품이다.

 

최근 AI 코딩 도구의 발전으로 "아이디어만 있으면 하루 만에 런칭할 수 있다"는 사례들이 속속 등장하고 있고, 실제로 v0.dev, Bolt.new, Lovable 같은 도구를 쓰면 랜딩 페이지 + CRUD 정도는 정말 빠르게 나온다. 문서에서 제시한 전략의 핵심은 이거였다. 핵심 제품은 기존 방식으로 유지하되, Micro SaaS는 AI로 빠르게 찍어내서 시장에 던져보자. 이걸 "이원화 전략"이라고 불렀다. 좋은 방향성인것 같았다. 이러한 문제들을 직접적으로 부딪게 되는 시점이 오니, AI Agent 코딩 시대에, fe 개발자로서 어떤 전략을 갖고 나아가야할까에 대해 생각해보는 기회가 되었다. 

 

3. AI 코딩 도구

모든 개발자들이 그러하듯, 나 또한 AI 코딩 도구를 꽤 적극적으로 쓰는 편이다. Claude, Cursor, 각종 AI 어시스턴트를 일상적으로 활용하고 있다. 자료 조사, 타입 정의, 리팩토링 패턴 제안 같은 데서는 확실히 시간이 줄었다.

그런데 최근 20일간 멀티미디어 에디터를 만들면서 느낀 건, AI가 빠르게 해주는 것과 빠르게 할 수 없는 것의 경계가 생각보다 뚜렷하다는 점이었다. 다음은 체감상 시간이 절약된 부분과 한계가 있던 부분이다.

3-1. 확실히 빨라진 것

  • 보일러플레이트, 타입 정의: 체감 70~80% 절약. 인터페이스 잡고 기본 구조 세우는 건 진짜 빨라졌다.
  • 리팩토링: 50~60% 절약. "이 코드를 이 패턴으로 바꿔줘"가 잘 먹힌다.
  • 문서 초안: 60~70% 절약. 구조만 잡아주면 내용 채우는 건 금방이다.
  • 코드 리뷰 초안: 과거 PR당 2~4시간에서 AI 보조로 30분~1시간으로. 체감 50% 단축.

과장 없이, 편해졌다. 예전에 반나절 걸리던 게 30분이면 끝난다. AI 없이 했으면 2달은 걸렸을 작업을 20일에 끝냈다. 60~70% 단축. 유의미한 차이다.

3-2. 그러면 뭐가 남는가

코드를 타이핑하는 시간이 줄어드니까, 나머지 시간에 뭘 하고 있는지가 선명해졌다. "이 구조가 맞나?" 고민하는 시간, "왜 안 되지?" 추적하는 시간, "다른 브라우저에서도 되나?" 확인하는 시간. 이런 게 전체의 70%쯤이다. AI가 코드 생산을 가속하면서, 오히려 이 70%의 비중이 더 도드라지게 된 셈이다.

이건 불만이 아니라 관찰이다. 개발이라는 작업의 무게중심이 "쓰는 것"에서 "판단하는 것"으로 옮겨가고 있다.

 

4. 개발의 무게중심이 바뀌고 있다

4-1. 코드를 쓰는 시간 → 코드를 검증하는 시간

타임라인 컴포넌트를 8번 이터레이션했다. AI한테 시키면 1차 버전은 빠르게 나온다. 줌 해보니까 세그먼트가 어긋나서 고쳤다. 고치니까 스크롤 동기화가 안 됐다. 고치니까 트랙 분리가 필요했다. 분리하니까 duration이 안 맞았다. 고치니까 36,000px 캔버스 한계에 걸렸다.

각 문제는 이전 걸 고친 다음에야 드러났다. AI가 1차 코드를 빠르게 써준 덕분에, 이 이터레이션 사이클 자체는 예전보다 빨라졌다. 하지만 "실제로 써보고 문제를 발견하는" 과정 자체는 줄어들지 않는다. 앞으로 개발자의 시간은 점점 더 이쪽에 쓰이게 될 것 같다.

4-2. 구현하는 시간 → 설계하는 시간

3월 20일 하루 동안 비디오 내보내기를 3번 갈아엎었다. ffmpeg.wasm으로 만들었더니 번들이 15MB. WebCodecs로 바꿨더니 Firefox에서 안 됨. FFmpeg를 폴백으로 남기고 코덱 자동감지를 넣었다.

AI가 코드를 빨리 써주니까 "일단 만들어보고 판단"하는 사이클이 가능해졌다. 예전이었으면 한 가지 방식에 며칠을 걸었을 텐데, 하루에 세 가지를 시도할 수 있었다. 대신 "어떤 방식을 선택할지" 판단하는 능력이 더 중요해졌다. 코드를 쓰는 속도가 아니라 방향을 정하는 속도가 병목이 된다.

4-3. 혼자 코딩하는 시간 → 다른 사람과 맥락을 맞추는 시간

코드 생산이 빨라지면서 의외로 늘어난 게 있다. 디자인 확정 대기, API 스펙 합의, 기획 결정 대기. 컴포넌트는 30분이면 만드는데 디자인 피드백이 5일 뒤에 온다. 수정은 30분인데 대기가 5일이다.

AI가 코딩을 빠르게 해줄수록, 코딩 이외의 병목이 더 두드러진다. 앞으로 FE 개발자에게는 "빨리 만드는 능력"보다 "빨리 결정하고, 결정을 끌어내는 능력"이 더 필요해질 수 있다.

 

5. 바이브코딩의 속도와 그 조건

 

바이브코딩이 빠른 경우가 있다. 랜딩 페이지, CRUD, 대시보드. 이건 진짜 빠르다. AI가 디자인까지 알아서 하기 때문이다.

디자인 시안이 정해진 상태에서 구현하는 건 다르다. Figma를 분석하고, 의도를 파악하고, 맞춰야 한다. AI한테 시키면 80%쯤 나오는데, 20%를 맞추는 데 직접 짜는 것만큼 걸리기도 한다.

 

여기서 느낀 건, AI의 속도를 최대로 끌어내려면 AI가 따를 수 있는 규칙을 먼저 만들어야 한다는 것이다. 디자인 시스템이 있으면 "이 토큰 규칙대로 만들어줘"가 통한다. 없으면 매번 시안을 분석하는 수작업이 반복된다. 바이브코딩의 효율은 AI의 성능이 아니라 AI에게 줄 수 있는 규칙의 품질에 달려 있다.

 

6. AI를 효율적으로 사용하기위해 개발중인 내용들

 

위 경험들을 거쳐오면서, 개선이 필요하다고 느껴서 요즘 힘쓰고 있는 부분들에 대해 공유해보려고한다.

6-1. AI가 따를 규칙 만들기

TypeScript 엄격 모드로 타입 안전성을 확보하고, 5-store Zustand 아키텍처로 데이터 흐름을 명시적으로 관리하고 있다. AI가 엉뚱한 스토어를 참조하면 컴파일에서 잡힌다. Strategy+Registry 패턴으로 렌더러를 확장 가능하게, Command 패턴으로 Undo/Redo를 원자적으로 관리한다.

이런 구조가 있으면 "이 패턴 따라서 새 렌더러 만들어줘"가 통한다. AI의 성능을 높이는 가장 확실한 방법은, AI 자체를 개선하는 게 아니라 AI가 따를 수 있는 좋은 규칙을 설계하는 것이다.

6-2. 디자인 시스템 구축 기획

디자인팀과 협업해서 공통 컴포넌트를 토큰 기반으로 표준화하는 디자인 시스템을 기획하고 있다. Figma 디자인 토큰과 코드 토큰을 동기화하면, "이 규칙대로 만들어줘" 한마디로 일관된 결과가 나온다. 디자인 시안 분석에 드는 시간을 구조적으로 줄이는 방법이다.

6-3. 코드 리뷰 프로세스 개선

AI로 초안 리뷰를 자동화하면서 리뷰 시간을 절반으로 줄였다. 다만 아키텍처 정합성, 보안, 성능 검증은 여전히 사람이 본다. 리뷰에서 반복적으로 나오는 지적 사항은 커스텀 린트 규칙으로 만들어서 도구에 넘기고 있다. 사람이 반복하던 판단을 하나씩 도구로 옮기는 작업이다.

6-4. 테스트 자동화

유닛 테스트는 AI로 생성하고 있다. 비즈니스 로직의 테스트를 AI가 쓰고, 사람이 엣지 케이스를 보강하는 흐름. E2E 테스트도 AI 자동화를 검토·진행 중이다. 시각적 결함, 크로스 브라우저 호환성 같은 수동 QA 영역을 AI가 보조하도록 전환하려는 시도다.

빌드·린트·타입 체크는 이미 CI/CD 파이프라인에서 자동화되어 있고, 이 위에 AI 기반 검증 레이어를 쌓아가고 있다.

6-5. 기록

이 글도 그 일부다. 타임라인을 왜 8번 만들었는지, 비디오 내보내기를 왜 3번 갈아엎었는지, 그때 어떤 판단을 했는지 적어두는 것. AI가 대신 못 하는 건 "이 맥락에서 왜 이 선택을 했는가"다. 이걸 구조화하는 연습이 결국 AI에게 더 정확한 지시를 내리는 능력으로 이어진다.

 

7. 앞으로의 방향성

 

다른 개발자분들의 생각이 궁금해 여러 블로그들을 찾아보았다. yceffort 님은 "없어지는 건 개발자가 아니라, 개발자가 하던 일의 형태다"라고 했고, teo 님은 "바뀌는 건 컴포넌트를 만드는 방법이지, 좋은 사용자 경험을 만드는 데 필요한 것이 아니다"라고 했다. 나의 생각을 정리하자면, 현재로써는 아래 내용들이 가장 중요하게 와닿는다.

7-1. 명세를 잘 쓰기

AI한테 좋은 결과를 받으려면 좋은 입력을 줘야 한다. 엣지 케이스까지 기술하는 것. 도메인을 깊이 아는 만큼 잘 쓸 수 있다. 이건 곧 "기획자·디자이너와 소통하는 능력"이기도 하다.

7-2. 시스템 전체를 보는 시야

AI는 함수 하나를 잘 만든다. 5개 스토어의 상호작용, 오디오 엔진과 Canvas 루프의 동기화는 전체가 머릿속에 있어야 판단 가능하다. 코드 생성이 쉬워질수록, 이 시야의 가치가 올라간다.

7-3. 빠르게 시도하고 빠르게 판단하기

AI 덕분에 "일단 만들어보는" 비용이 줄었다. 그러면 중요한 건 만드는 속도가 아니라 "이게 맞는지 틀린지" 판단하는 속도다. 하루에 세 가지 방식을 시도할 수 있는 시대에는, 어떤 걸 선택할지 정하는 감각이 핵심이 된다.

7-4. 인지 부채 관리하기

기술 부채는 코드에 쌓인다. 리팩토링하면 갚을 수 있다. 인지 부채는 팀의 머릿속에 쌓인다. 시스템의 복잡도와 팀이 그 시스템을 이해하는 정도 사이의 격차다.

AI가 코드를 빠르게 만들어주면 코드는 늘어나는데, 그 코드를 이해하는 사람은 그대로다. "AI가 짠 코드인데 왜 이렇게 동작하는지 모르겠다"가 반복되면 시스템을 건드리기가 점점 무서워진다. 빠르게 만드는 것만큼 빠르게 이해하는 것, 코드의 의도를 문서화하고, 아키텍처 결정의 이유를 남기는 습관이 필요하다.

7-5. 판단의 이유를 명확히 하기

"왜 ffmpeg 대신 WebCodecs를 선택했는가?" "왜 스토어를 5개로 나눴는가?" 이런 질문에 답할 수 있어야 한다. AI가 코드를 대신 짜주는 시대에는, 코드 자체보다 그 코드를 선택한 이유가 개발자의 고유한 가치가 된다.

결정의 근거를 기록하고, 트레이드오프를 설명할 수 있는 능력. teo 님 말처럼 "기술적 기반 위에서 자신의 맥락을 담아 구체적인 이야기를 구조적으로 할 수 있는 능력"이 점점 더 중요해질 거라 생각한다.

 

8. 마치며

 

처음 질문으로 돌아가면.

"AI가 페이지를 생성하는 시대에 FE 개발자의 핵심 역할은?"

 

AI 덕분에 많은 게 빨라졌다. 이건 사실이고, 적극적으로 쓰는 게 맞다고 생각한다. 빨라진 만큼, 개발이라는 작업의 무게중심이 옮겨가고 있다. 코드를 쓰는 것에서 판단하는 것으로, 구현하는 것에서 설계하는 것으로, 혼자 만드는 것에서 맥락을 맞추는 것으로.

 

이 변화를 위협으로 볼 수도 있고, 기회로 볼 수도 있다. 나는 기회 쪽에 걸어보려고 한다. AI를 도구로 쓰면서, AI가 더 잘 작동하는 환경을 설계하고, AI 결과를 판단하는 감각을 키우는 것. 그게 지금 내가 생각하는 방향이다.

 

 

9. 참고 자료

 

AI 시대 개발자 역할 변화

AI 코드 품질·신뢰도 데이터

AI 코딩 채택률·생산성 통계

 

'개발로그' 카테고리의 다른 글

[Part 2.] 웹브라우저 멀티에디터 만들기 - 프레임 좌표계를 이용한 멀티미디어 타임라인 동기화  (0) 2026.04.13
[Part 1] 브라우저에서 멀티미디어 export하기- 문제 정의와 아키텍처 설계  (0) 2026.04.13
[Part 2.] 웹브라우저 멀티에디터 만들기 - 아키텍쳐 설계 변화  (0) 2026.03.26
[Part 1.] 웹브라우저 멀티에디터 만들기 - 아키텍쳐 설계  (0) 2026.03.25
오디오 파형 로딩 지연 해결기: 동적 stride를 이용한 Peak 연산 최적화  (0) 2026.02.04

관련글

티스토리툴바