카카오엔터테인먼트 FE 개발자가 ChatGPT 만으로 간단한 웹툰 서비스를 만들어보며 어디까지 대체 가능한지 확인한 실험기다. Next.js, Tailwind, redux-toolkit, react-query 로 배너와 작품 컴포넌트, 반응형 페이지, API 연동까지 약 5시간에 만들었다. 코드 스니펫 생성은 훌륭했지만 최신 라이브러리 환경설정처럼 학습 데이터 밖의 영역에서는 틀린 가이드를 줬다.
핵심 포인트- 결과물은 Next.js, TypeScript, Tailwind, react-query 기반 웹툰 서비스 데모이고 코드는 공개 저장소에 있다. 뽀모도로로 계산한 개발 시간은 10 뽀모도로, 약 5시간이다.
- 프로젝트 환경설정은 답변이 매번 달라졌고 tailwind init 단계 누락과 jest, TypeScript 설정 미비로 오류가 났다. gpt-3.5 는 2021년 이전 데이터로 학습돼 최신 버전 가이드에 약하다.
- 질문이 구체적일수록 결과가 좋아졌다. "배너 만들어줘" 는 부실했지만 캐러셀 동작과 좌우 이미지 노출 방식, 루프까지 적어주자 React 컴포넌트 구조로 답했다.
- 스스로 못 고치는 문제는 라이브러리를 지목해 우회했다. 자체 구현 캐러셀이 모바일에서 깨지자 swiper.js 로 바꿔달라고 하니 요청하지 않은 페이지네이션까지 붙여줬다.
- 명세가 고정된 API 연동에 특히 강했다. TMDB 응답 JSON 을 주자 26개 필드의 타입 정의와 react-query 호출 코드가 순식간에 나왔다.
상세 정리- 실험 설계: gpt 설명 대신 실제 문답으로 코드를 만들어가는 과정을 그대로 싣는다. 기획 단계에서도 인기 장르와 작품명을 gpt 에게 받았고, 이미지는 stable diffusion webui 의 txt2img 로 생성했다.
- 비교 기준으로 FE 개발자의 일을 환경설정, html 작성, css 작성, 상태 관리, 서버 데이터 연동, 반응형 대응으로 먼저 나열하고 각각을 gpt 로 시도한다.
- 환경설정: create-next-app 경로와 npm init 경로를 번갈아 답한다. 생성된 프로젝트에는 이미 eslint 와 prettier 가 설정돼 있는데 gpt 는 설정 파일을 따로 만들라고 안내했다. 공식 문서를 보는 편이 낫다는 결론이다.
- 배너 1차: opacity 와 rotate 조합으로 이미지를 교체하는 코드가 나왔지만 모바일에서 이미지가 잘리고 동작이 어색했다.
- 배너 2차: swiper.js 로 바꿔달라고 하자 Navigation 과 Pagination 모듈까지 붙인 코드를 주며 모바일 이미지 잘림 문제를 피할 수 있다고 스스로 설명했다. 이전 답의 결함을 알고 있었던 셈이다.
- 컴포넌트 명명: 웹툰 작품 컴포넌트를 Work 로 지어와 이름이 부적절하다고 지적하자 Episode 로 바꾼 코드를 다시 냈다. 대화 맥락이 이어지는 게 강점으로 꼽힌다.
- 가로 스크롤 섹션: overflow-x-auto 로 만들어줬지만 PC 에서 스와이프가 안 됐고, gpt 는 shift 와 휠 조합을 대안으로 제시했다. react-swipeable 도 PC 에서 동작하지 않아 좌우 버튼 스크롤로 요구사항을 바꿔 해결했다.
- 반응형: md 768px 기준으로 PC 는 좌우 배치, 모바일은 상하 배치하도록 요청하니 분기 코드가 한 번에 나왔다.
- 상태 관리: 좋아요를 useState 로 두면 페이지 unmount 시 값이 사라지므로 redux-toolkit 으로 바꿔달라고 요청했다. useState 를 useSelector 와 useDispatch 로 바꾸는 변환은 잘했지만 store 생성과 _app 의 Provider 연결이 빠져 직접 채웠다.
- API 연동: TMDB 응답 예시 JSON 을 붙여 react-query 와 TypeScript 코드를 요청하니 타입과 훅이 만들어졌다. 직접 했다면 26개 필드를 읽고 타입을 만드는 데 한참 걸릴 작업이다.
- mock 데이터 생성에도 유용해 ChapterList 의 더미 데이터는 전부 gpt 가 만든 것이다.
- 한계: hallucination 때문에 잘못된 코드가 섞이므로 답변 검증이 필요하다. 다만 검증 가능한 작은 조각을 잘 이어 붙이면 큰 프로젝트도 가능하다고 본다. 프론트엔드는 눈으로 결과를 확인할 수 있어 신뢰성 판단이 빨라 활용도가 높다는 게 저자의 판단이다.
- 결론: FE 개발자는 명세를 화면으로 옮기는 사람이 아니라 기획, 디자인과 협의하고 변하는 요구사항에 맞춰 구조를 설계하는 역할이다. 미래에도 바뀌지 않는 명세서가 있는 세계가 아니면 gpt 만으로 개발할 수는 없다고 정리한다.
왜 읽나LLM 을 실제 프론트엔드 작업에 붙여보려는 개발자에게 어디서 잘 먹히고 어디서 손이 가는지를 구체적인 문답 단위로 보여주는 실험 기록.