쇼츠생성기

오직 AI만으로 끝까지 밀어붙인 첫 프로젝트

이 프로젝트는 내가 ‘혼자’ 개발했다기보다, AI와 끝없는 대화를 하면서 완성한 결과물에 가깝다. 리액트(React) 기반의 쇼츠 생성기 저작도구를 만들면서, 레이아웃부터 컴포넌트 구조, 상태 관리, 기능 구현까지 대부분의 과정을 챗(대화) 중심으로 진행했다.

지금 돌이켜보면 이건 “AI가 코드를 대신 써줬다” 같은 단순한 이야기가 아니라, AI와 함께 개발하는 방식 자체를 몸으로 익힌 기록이었다.

2024년 9월 1일의 GPT: 가능성은 컸고, 맥락은 얇았다

당시 GPT는 이미 코드 생성과 리팩터링에 꽤 쓸만했지만, 동시에 분명한 특징이 있었다.

• 짧은 요청엔 강하지만, 긴 맥락을 한 번에 완벽하게 잡기 어렵다

• “전체 프로젝트” 관점보다는 “지금 붙여넣은 코드”에 강하게 반응한다

• 작은 수정 요청이 의도치 않게 다른 기능을 깨는 일이 생각보다 자주 생긴다

• 결과적으로, 개발 흐름은 대화 → 코드 생성 → 복사/붙여넣기 → 에러 → 재대화의 반복이 된다

그래서 이 프로젝트는 처음부터 끝까지 “AI가 다 해줌”이 아니라, 사람이 방향을 잡고, AI가 힘을 보태고, 다시 사람이 정리하는 협업으로 진행될 수밖에 없었다.

개발 순서: PPT → HTML → React → 끝없는 챗

이 프로젝트의 시작은 IDE가 아니라 PPT였다. 먼저 PPT에서 화면을 구성하며, 내가 만들고 싶은 저작도구의 구조를 “눈으로 보이게” 만들었다.

### 1) PPT로 레이아웃 만들기

• 좌측: 소재/리스트 영역

• 중앙: 프리뷰 영역

• 우측: 편집 패널(텍스트/타이밍/스타일)

• 상단: 저장/내보내기/프리셋 등 액션 영역

이 단계에서 중요한 건 “예쁘게”가 아니라, 사용 흐름이 자연스럽게 이어지는 화면 구조를 잡는 것이었다.

### 2) GPT 챗으로 HTML 변환 요청 PPT 레이아웃을 바탕으로 GPT에게 화면 구조를 설명하고, 그걸 HTML 마크업 구조로 변환해달라고 요청했다.

아래는 그때 레이아웃을 HTML로 옮겨가던 흔적이다.

### 3) 리액트 코드로 변환 요청 HTML이 어느 정도 잡히면, 그 다음은 React로 옮기는 단계였다.

• 컴포넌트로 분리

• 상태(state) 설계

• 이벤트 핸들링 연결

• 편집 데이터 구조 정의

이때부터는 “화면이 보이는 것”보다 기능이 일관되게 동작하는 것이 목표가 됐다.

### 4) 계속 챗으로 개발 이후는 말 그대로 계속 챗이었다.

• GPT에게 코드를 받는다

• 붙여넣는다

• 에러가 난다 (혹은 의도와 다르게 동작한다)

• 에러 로그/증상/의도를 다시 설명한다

• 수정된 코드를 다시 받는다

• 다시 붙여넣는다

이 과정이 “한두 번”이 아니라, 체감상 끝이 보이지 않을 정도로 반복됐다. 하지만 그 반복 덕분에, 나는 단순히 기능을 구현한 게 아니라 AI와 함께 개발이 굴러가게 만드는 감각을 점점 더 확실히 갖게 됐다.

100줄이 넘어가면 무조건 쪼갰다: AI 협업에서 컴포넌트화는 생존 전략

AI가 코드를 잘 뽑아줄수록 욕심이 생긴다. 한 파일에 기능을 계속 붙이다 보면 금방 100줄, 200줄을 넘는다.

그런데 어느 순간부터 확실히 느꼈다.

• 소스가 길어질수록 GPT의 수정 정확도가 떨어진다

• “부분 수정”을 부탁했는데 “전체 구조”를 흔들어버리는 일이 늘어난다

• 내가 의도한 아키텍처가 대화 중에 흐려진다

그래서 원칙을 만들었다.

한 파일이 100줄을 넘으면 쪼갠다. > UI / 로직 / 유틸을 분리하고, 컴포넌트 단위로 작은 승리를 반복한다.

결과적으로 이 습관이 프로젝트를 살렸다. (그리고 이건 지금 시점에서도 여전히 유효한 방식이다.)

zip 업로드 + README.md + GPT.md: “AI가 프로젝트를 이해하게 만들고 싶었다”

반복 대화에서 가장 힘든 순간은 매번 맥락을 다시 설명하는 일이었다.

• “이 컴포넌트는 왜 존재해?”

• “이 상태는 어디서 오고 어디로 가?”

• “이 기능은 어떤 순서로 동작해야 해?”

AI는 기본적으로 내가 지금 보여준 정보에 강하게 반응하니까, 전체 맥락을 ‘문서’로 고정해두는 장치가 필요했다.

그래서 시도한 게:

• 프로젝트를 zip으로 묶어서 업로드

• README.md로 프로젝트 개요 제공

• GPT.md로 “AI에게 주는 개발 가이드”를 제공

GPT.md에는 예를 들면 이런 걸 적어두었다.

• 프로젝트 목표 / 주요 화면 구조

• 데이터 흐름(상태/스토어/props) 규칙

• 코딩 스타일 / 파일 분리 기준

• 수정 시 “절대 건드리면 안 되는 부분”

이건 결국 AI를 위한 문서이기도 했지만, 동시에 나 자신을 위한 설계 문서가 되기도 했다.

결과 화면: “작동하는 편집기”까지 도달했다

여러 시행착오 끝에, 실제로 편집기가 돌아가는 형태까지 만들 수 있었다. 아래 스크린샷이 그 결과다.

완성도의 높고 낮음을 떠나서, 이 화면은 내게 꽤 상징적이었다.

• AI가 만든 코드를 내가 조립했고

• 내가 만든 제약과 규칙이 AI의 출력을 안정시켰고

• 결국 “작동하는 도구”로 수렴했다

수많은 AI와 수많은 챗이 남긴 것: 개발 감각과 ‘방향 잡는 법’

가장 큰 수확은 기능 자체가 아니라, AI와 개발하는 감각이었다.

그때 나는 수많은 AI와 수많은 챗을 반복하면서 이런 것들을 몸으로 익혔다.

• 요구사항을 “기능”이 아니라 상태 변화와 이벤트 흐름으로 설명하기

• 에러를 “에러 메시지”만 던지는 게 아니라 재현 조건 + 기대 동작까지 전달하기

• 한 번에 크게 고치지 않고, 작은 단위로 안정적으로 전진하기

• AI가 생성한 코드를 그대로 믿지 않고, 테스트/검증 루프를 습관화하기

• 긴 코드보다 작은 컴포넌트/유틸 단위가 훨씬 잘 맞는다는 것

그리고 무엇보다 확실히 알게 된 건 이거였다.

AI는 누구에게나 비슷한 기능이 주어지지만, 결과는 비슷하지 않다. > 결국 차이는, 같은 도구를 쓰더라도 > 목적을 잃지 않고 같은 방향을 보게 만들 수 있느냐에서 생긴다.

AI는 아주 똑똑하지만, 스스로 “왜 이걸 만드는지”를 끝까지 붙잡아주진 않는다. 중간에 흔들리고, 옆길로 새고, 그럴듯한 답을 내놓기도 한다.

그래서 사람 쪽에서 해야 하는 일이 있다.

• 목표를 계속 확인하고

• 지금 수정이 목표에 부합하는지 점검하고

• 중요한 기준(구조/규칙/흐름)을 문서와 코드로 고정해두고

• 끝까지 목적을 향해 방향을 잡아주는 것

이건 코드 스킬이라기보다, 개발을 끌고 가는 운영 능력에 가까웠다.

지금 시기의 AI 개발도 크게 다르지 않다: 그래서 더 도움이 됐다

시간이 지나 지금은 모델도 도구도 훨씬 좋아졌지만, 아이러니하게도 AI로 개발하는 핵심 패턴은 많이 비슷하다.

• 맥락은 여전히 관리해야 하고

• 복잡한 기능일수록 작은 단위로 쪼개야 하고

• 문서(가이드)로 의도를 고정해두면 정확도가 올라가고

• 결국 사람의 역할은 “코딩”보다 설계/검증/정리에 가깝다

그래서 이때 얻은 경험이 지금도 계속 도움이 된다. AI가 좋아질수록 더 빨리 만들 수는 있지만, 좋게 만드는 건 여전히 ‘사용법’의 영역이다.

마무리

쇼츠 생성기 저작도구는 내게 단순한 개인 프로젝트가 아니라,

• AI와 함께 개발하는 방식의 실험이었고

• 대화 기반 개발의 한계를 체험한 기록이었고

• 무엇보다 보이지 않는 노하우를 축적한 시간이었다

2024년 9월 1일의 나는 이 프로젝트를 통해 AI와 함께 개발할 때 결국 중요한 것은 기술 자체보다도, 끝까지 같은 목표를 바라보게 만드는 ‘방향 잡기’라는 걸 배웠다.

그리고 그 감각은 지금도 여전히 유효하다.