엔지니어로서 2년 차를 맞이했습니다.

평소에는 Java나 Kotlin을 사용하여 Android 앱 개발을 담당하고 있습니다.

최근 제가 참여하고 있는 프로젝트에서도 AI 활용이 진행되고 있으며, 평가 축에 「AI 활용도」가 포함되는 등 업무 방식이 크게 변하고 있음을 느낍니다.

하지만 실제로 업무에서 AI를 사용하려고 하면, 보안이나 권한 문제로 인해 사용할 수 있는 도구나 입력할 수 있는 정보에 제한이 있습니다.

「좀 더 자유롭게 사용해 보고 싶지만, 업무에서는 좀처럼 어렵네……」

그런 답답함이 있었습니다.

그래서,

개인 개발이라면 제한을 신경 쓰지 않고 원하는 만큼 AI를 사용할 수 있지 않을까?

라는 생각이 들어, 개인 개발로 시도해 보기로 했습니다.

이번에 도전한 것은 브라우저에서 동작하는 동영상 편집 사이트의 설계, 구현, 테스트, 공개입니다.

직접 코드를 처음부터 쓰는 것이 아니라, AI와의 대화를 중심으로 진행했을 때 어디까지 실제로 쓸 수 있는 것을 만들 수 있는지 검증했습니다.

⚠️ 본 기사의 스코프(Scope)에 대하여

이 기사에서는 IDE로의 AI 플러그인 도입이나, MCP 서버 구축과 같은 AI 개발 환경 그 자체에 대해서는 다루지 않습니다.

기본적으로는 AI에게 질문하거나, 요구사항 및 수정 내용을 전달하여 코드를 작성하게 하는 단순한 대화 형식으로 개발을 진행하고 있습니다.

「AI에게 지시를 내리면서 어디까지 설계·구현·테스트·공개를 진행할 수 있는가」를 시험한 기록입니다.

이번에 만들고자 한 것은 간단하게 동영상을 편집할 수 있는 Web 사이트입니다.

제작물: https://capca-web.pages.dev/

장래에는 Web 버전을 바탕으로 Flutter를 사용하여 Android·iOS 앱도 만들고 싶다고 생각하고 있습니다.

동영상 편집 소프트웨어는 다양하지만, 개인적으로는 학습 비용(Learning Cost)이 다소 높다고 느끼고 있었습니다.

예를 들어, 영상에 자막(Telop)을 넣고, 불필요한 부분을 트리밍(Trimming)하고, 효과음을 추가하는 작업.

하고 싶은 일은 그것뿐이라도 동영상 편집 소프트웨어의 조작법을 익히거나, 프로젝트를 생성하거나, 내보내기(Export) 설정을 확인하는 등 나름대로 시간이 걸립니다.

좀 더 간단하게,

• 동영상을 불러오기
• 필요한 부분만 잘라내기
• 자막이나 효과음 추가하기
• MP4로 저장하기

라는 흐름만으로 사용할 수 있는 도구가 필요하다고 생각했습니다.

없다면 직접 만들어 버리겠다는 속셈입니다.

또한, 동영상을 서버로 업로드하는 형식이 아니라, 가능한 한 브라우저 내에서 처리를 완결 짓는 것도 목표로 삼았습니다.

개인의 영상이나 외부로 업로드하고 싶지 않은 영상을 다룰 때도 사용하기 쉽게 만들고 싶었기 때문입니다.

나아가 테스트 자동화는 해보고 싶다고 생각하고 있었습니다.

평소 개발에서는 테스트 주도(Test-Driven) 방식으로 수동 테스트를 하고 있기 때문에, 그 공정을 생략하는 것이 정말 가능한지 흥미가 있었습니다.

사용한 AI는 다음과 같습니다.

• ChatGPT
  • 요구사항 정리
  • 구현 방침 상담
  • 구현 방침 상담
  • 결함 원인 조사
  • 수정 내용 및 테스트 관점 정리
• Codex
  • 코드 구현·수정
  • Playwright를 사용한 E2E 테스트 작성 및 실행
  • 테스트 결과를 바탕으로 한 결함 조사

본래라면 처음에 요구사항을 정리하고, 화면 설계나 기술 선정(Tech Selection)을 수행해야 한다고 생각합니다.

하지만 이번에는 AI를 활용한 개발 검증입니다.

솔직히 말해서,

세세한 설계를 하는 것은 귀찮으니, 대략적인 지시를 내리면 만들어 주지 않을까

라는 마음이 있었습니다.

그래서 우선 AI에게 개발 중인 규칙을 전달했습니다.

앞으로의 대화에서는 다음을 준수할 것
・지시대로 동작할 것
・구현은 사양대로 실시할 것
...

지금 보니 상당히 추상적인 지시입니다.

「우수한 엔지니어 겸 플래너일 것」이라고 쓰면 정말 우수한 설계가 될지는 의문이지만, 이 시점에서는 일단 던져 보았습니다.

이어서 만들고 싶은 앱의 개요와 로드맵을 전달했습니다.

Web, Android, iOS에서 이용할 수 있는 동영상 편집 앱을 작성하고 싶다.
다음 흐름으로 개발을 진행한다.
1. Web 버전의 프로토타입을 작성한다
...

상당히 대략적입니다.

화면 구성이나 사용하는 라이브러리, 데이터 관리 방식 등은 거의 지정하지 않았습니다.

이 상태에서 AI가 어느 정도 보완해 줄 수 있는지 확인하기 위해, 처음에는 일부러 세세하게 정하지 않고 프로토타입을 만들게 했습니다.

처음에 만들어진 것은 HTML, CSS, JavaScript로 동작하는 Web 앱이었습니다.

그 후 기능 추가와 수정을 반복하여, 최종적으로는 다음과 같은 기능을 구현했습니다.

• 동영상 파일 불러오기
• 캔버스 크기 변경
• 동영상 트리밍 (Trimming)
• 동영상 이동, 확대, 축소
• 여러 개의 자막 (Telop) 추가
• 글자 색상, 테두리 색상, 테두리 두께 변경
• BGM, 효과음 추가
• 동영상과 오디오의 볼륨 조절
• 동영상 상하, 좌우 반전
• 편집 내용의 실행 취소 (Undo)
• MP4 형식으로 내보내기

동영상 내보내기에는 브라우저 상에서 FFmpeg를 구동할 수 있는 ffmpeg.wasm을 이용하고 있습니다.

사이트 이름은 capca로 정했습니다.

여기까지 쓰면, AI에게 지시를 내렸더니 순조롭게 완성된 것처럼 보일지도 모릅니다.

물론, 전혀 그렇지 않았습니다.

첫 번째 프로토타입을 실행해 보니 여러 가지 문제가 발생했습니다.

• 동영상을 불러올 수 없음
• JavaScript에서 정의되지 않은 함수(Undefined function) 에러가 발생함
• 자막을 추가해도 캔버스에 표시되지 않음
• 자막 드래그가 도중에 멈춤
• 동영상을 내보내도 재생할 수 없음
• 볼륨 조절 기능을 넣으면 내보낸 동영상의 소리가 사라짐
• 프로젝트를 불러와도 편집 내용이 반영되지 않음
• 로컬에서는 동작하지만, 공개 환경에서는 FFmpeg를 초기화할 수 없음

특히 곤란했던 점은 수정을 요청한 부분과는 다른 기능이 고장 나는 것이었습니다.

하나의 버그를 고치기 위해 AI에게 코드 수정을 시켰더니, 이전에는 잘 작동하던 기능이 작동하지 않는 경우가 있었습니다.

AI는 지시한 부분의 코드를 작성하는 데는 능숙하지만, 프로젝트 전체의 의도나 지금까지의 경위를 항상 완벽하게 이해하고 있는 것 같지는 않았습니다.

"고쳐졌다"라고 답변을 받아도, 실제로 실행해 보면 고쳐져 있지 않은 경우도 있었습니다.

이 시점부터 단순히 "수정해 줘"라고 요청하는 것만으로는 어렵다는 것을 느끼기 시작했습니다.

개발을 계속하면서 AI에게 요청하는 방법도 조금씩 바뀌었습니다.

최종적으로는 다음과 같은 규칙을 명시하도록 했습니다.

・수정 의도가 명확한 경우에만 구현할 것
・의도가 불분명한 경우, 임의로 사양을 변경하지 말 것
・기존 기능에 미치는 영향을 확인할 것
...

처음의 "우수한 엔지니어가 되어라"라는 지시보다, 이 방법이 훨씬 효과적이었습니다.

AI 입장에서도 완료 조건이 구체적인 편이 움직이기 쉬운 듯합니다.

또한, 에러를 전달할 때도 에러 메시지만 붙여넣는 것이 아니라, 다음 정보를 세트로 전달하도록 했습니다.

발생 환경:
Cloudflare Pages Preview
실제 결과:
...

AI를 사용할 때는 프롬프트의 숙련도라기보다, 문제를 정리하고 완료 조건을 언어화하는 능력이 중요하다는 것을 느꼈습니다.

Web 버전은 GitHub와 Cloudflare Pages를 연동하여 공개했습니다.

GitHub로 Push하면 Cloudflare Pages로 자동 배포되는 구성입니다.

하지만 로컬에서는 잘 작동하던 동영상 내보내기가 Cloudflare Pages 상에서는 작동하지 않았습니다.

원인을 추적해 보니 ffmpeg.wasm 주변에는 여러 가지 요소가 관계되어 있었습니다.

• Web Worker의 로드 출처
• FFmpeg Core JavaScript의 오리진 (Origin)
• WASM 파일의 배포 출처
• MIME Type
• 콘텐츠 보안 정책 (Content Security Policy, CSP)
• 라이브러리 버전 차이

최종적으로는 다음과 같은 구성으로 정리했습니다.

• @ffmpeg/ffmpeg를 0.12.15로 고정
• @ffmpeg/core를 0.12.10으로 고정
• FFmpeg Core JavaScript를 동일 오리진(Same-origin)에서 배포
• WASM 파일은 고정 버전의 jsDelivr에서 가져오기
• CSP의 script-src에 'wasm-unsafe-eval' 추가
• WASM이 application/wasm으로 배포되는 것을 확인

이 부분은 Android 개발만 해왔던 저에게는 그리 익숙하지 않은 분야였습니다.

AI에게 질문하며 Worker, CSP, MIME Type, 동일 오리진 같은 개념을 하나씩 확인해 나갔습니다.

AI가 없었다면 에러 문구를 본 시점에서 꽤 오랫동안 멈춰 있었을 것입니다.

한편으로는 AI가 제시한 수정안을 그대로 적용해도 고쳐지지 않는 경우가 있었습니다.

결국 브라우저의 Console, Network, 배포된 응답 헤더(Response Header)를 확인하며 원인을 분리해낼 필요가 있었습니다.

첫 번째 프롬프트에는 "유닛 테스트 (Unit Test)를 실시할 것"이라고 적었습니다.

다만, 이번 동영상 편집 사이트에서는 유닛 테스트만으로는 확인할 수 없는 부분이 많습니다.

예를 들어, 다음과 같은 케이스입니다.

• 실제로 브라우저에서 동영상을 불러올 수 있는지
• FFmpeg Worker가 공개 환경에서 초기화될 수 있는지
• WASM 파일이 올바른 MIME Type으로 가져와지는지
• MP4를 내보낼(export) 수 있는지
• 브라우저에서 파일을 다운로드할 수 있는지
• 다운로드한 MP4를 재생할 수 있는지

버튼을 눌렀을 때 함수가 호출되는 것을 확인하는 것만으로는, 동영상 편집 사이트로서 제대로 작동한다고 말할 수 없습니다.

그래서 브라우저를 실제로 조작하는 E2E 테스트를 추가했습니다.

이번 E2E 테스트에는 Playwright를 사용했습니다.

이 부분은 조금 혼동될 수 있는데, Playwright 자체가 AI인 것은 아닙니다.

• Playwright: 브라우저 조작을 자동화하기 위한 테스트 프레임워크 (Test Framework)
• Codex: 테스트 코드 작성 및 실행을 의뢰한 AI

라는 관계입니다.

Codex에 Cloudflare Pages의 Preview URL과 테스트 동영상을 전달하고, 다음 내용을 확인하도록 의뢰했습니다.

capca의 Cloudflare Preview를 E2E 테스트해 주세요.
확인 내용:
1. 동영상 로드
...

테스트에서는 대략 다음과 같은 흐름을 자동화하고 있습니다.

Preview URL 접속
↓
테스트 동영상 선택
...

동영상을 내보내는 데는 시간이 걸리기 때문에, 단순히 몇 초를 기다리는 것이 아니라 화면 상태나 다운로드 이벤트를 기준으로 대기합니다.

예를 들어 Playwright에서는 다음과 같이 파일을 선택할 수 있습니다.

const videoPath = path.resolve("tests/assets/sample.mp4");
await page
.locator('input[type="file"]')
...

다운로드도 이벤트로서 대기할 수 있습니다.

const downloadPromise = page.waitForEvent("download", {
timeout: 120_000,
});
...

나아가 파일이 존재하는 것뿐만 아니라, 브라우저에서 동영상으로 불러올 수 있는지도 확인합니다.

내보내기 완료 메시지가 뜨더라도, 생성된 MP4 파일이 손상되었을 가능성이 있기 때문입니다.

최종적인 테스트 결과는 다음과 같았습니다.

결과: 성공
테스트: 1 passed
실행 시간: 약 1.4분
...

Network상에서는 Blob 동영상 URL에 대한 net::ERR_ABORTED가 1건 있었으나, 확인 결과 이번에 문제로 삼았던 CSP, MIME, WebAssembly, FFmpeg Worker 관련 에러에는 해당하지 않는다고 판단했습니다.

또한, 내보낸 MP4를 실제로 다운로드하여 재생할 수 있는지까지 확인했습니다.

이를 통해 적어도 다음의 일련의 처리는 공개 환경상에서 동작하고 있음을 확인할 수 있었습니다.

• 동영상을 불러오기
• FFmpeg를 초기화하기
• MP4를 내보내기
• 파일을 다운로드하기
• 출력된 MP4를 재생하기

수동으로 한 번 확인하는 것만으로는 다음 수정 시 다시 망가질 가능성이 있습니다.

E2E 테스트로 남겨두면 동일한 조작을 반복해서 확인할 수 있습니다.

공개 플로우는 다음과 같이 구성했습니다.

수정 브랜치 생성
↓
GitHub로 Push
...

로컬에서 테스트한 뒤 본선에 반영하는 것만으로는 Cloudflare Pages 고유의 CSP나 배포 설정 문제를 놓칠 가능성이 있습니다.

따라서 본선에 가까운 Preview 환경을 테스트 대상으로 삼은 것이 큰 도움이 되었습니다.

앞으로는 Pull Request 생성 시 Preview URL을 가져와서 자동으로 E2E 테스트를 실행하는 단계까지 연결하고 싶습니다.

여기까지 읽으면 AI에게 지시만 내리면 설계부터 공개까지 전부 자동으로 끝난 것처럼 보일지도 모릅니다.

하지만 그렇게 간단하지 않았습니다.

코드 작성 작업의 상당 부분은 AI에게 맡겼지만, 다음 작업들은 스스로 판단해야 했습니다.

• 무엇을 만들지 결정하기
• 필요한 기능 정리하기
• AI에게 전달할 조건 결정하기
• 실제로 구동하며 결함(bug) 찾기
• 에러 발생 조건 정리하기
• AI의 수정 내용이 올바른지 확인하기
• 기존 기능이 망가지지 않았는지 확인하기
• 어디까지 확인되면 완료로 할지 결정하기
• 본선에 반영해도 될지 판단하기

또한, AI가 생성한 코드에는 다음과 같은 문제도 있었습니다.

• 존재하지 않는 함수를 호출
• 서로 다른 버전의 API를 혼용
• 수정 대상이 아닌 기능까지 변경
• 로컬 환경에서만 동작하는 구성을 제안
• "대응했습니다"라고 답변하지만, 실제로는 동작하지 않음

AI는 매우 편리하지만, 출력된 코드를 그대로 신뢰할 수는 없습니다.

오히려 AI로 구현 속도가 올라갈수록, 리뷰와 테스트의 중요성도 높아진다고 느꼈습니다.

AI에게 구현을 맡기는 것과, AI에게 판단을 맡기는 것은 별개의 문제였습니다.

구현 속도는 AI로 높일 수 있지만, 사양(Specification), 품질, 완료 조건에 대한 판단은 개발자 측에서 담보해야 했습니다.

이번 개인 개발에서는 평소 Android 개발만으로는 접할 기회가 적은 분야도 경험할 수 있었습니다.

• Web 프론트엔드 (Web Frontend)
• 영상, 음성 처리
• WebAssembly
• Web Worker
• 콘텐츠 보안 정책 (Content Security Policy)
• MIME Type
• GitHub을 통한 소스 관리
• Cloudflare Pages로의 배포
• 프리뷰 (Preview) 환경에서의 검증
• Playwright를 이용한 E2E 테스트

처음부터 이 모든 것을 공부하고 만들려고 했다면, 도중에 멈춰버렸을 것입니다.

모르는 것이 생기는 타이밍에 AI에게 질문하고, 필요한 부분을 조사하며 진행할 수 있었기에 완성까지 가져올 수 있었습니다.

한편, AI를 활용한다고 해서 엔지니어로서 생각할 필요가 없어지는 것은 아니었습니다.

오히려 다음과 같은 역량이 더욱 중요해졌다고 느낍니다.

• 요구사항을 구체화하는 능력
• 문제를 분리하는 능력
• 변경의 영향 범위를 생각하는 능력
• 생성된 코드를 리뷰하는 능력
• 테스트 관점을 도출하는 능력
• 완료 조건을 정의하는 능력

특히 이번에 처음에는 "유닛 테스트 (Unit Test)를 해줘"라고만 적었던 것이, 최종적으로는 "공개 환경에서 영상을 불러오고, 내보낸 MP4를 재생할 수 있는 단계까지 확인한다"라는 조건으로 바뀌었습니다.

테스트의 종류를 아는 것뿐만 아니라, 무엇을 확인해야 품질을 담보할 수 있는지 생각하는 것이 중요했습니다.

Web 버전은 Cloudflare Pages에 공개했습니다.

하지만 공개하는 것만으로는 아무도 찾아주지 않습니다.

앞으로는 개발뿐만 아니라 다음과 같은 부분에도 도전할 예정입니다.

• Cloudflare Web Analytics를 통한 접속 측정
• Google Search Console 등록
• 사용법 페이지, FAQ 작성
• "영상을 업로드하지 않고 편집할 수 있다"라는 특징의 명확화
• Qiita나 SNS를 통한 발신
• GitHub Actions와 E2E 테스트의 연동
• 여러 브라우저에서의 테스트
• Flutter를 이용한 Android·iOS 앱 개발

처음에는 웹사이트를 만드는 것만을 생각하고 있었습니다.

실제로 공개해 보니 테스트, 유지보수, 접속 분석, 이용자에 대한 설명, 홍보 등 코드 이외에도 해야 할 일이 많다는 것을 깨달았습니다.

이 점을 포함해서 개인 개발의 재미라고 생각합니다.

AI를 활용하여 브라우저상에서 동작하는 영상 편집 사이트를 설계, 구현, 테스트하고 Cloudflare Pages에 공개했습니다.

처음에는 상당히 거친 프롬프트(Prompt)로 시작했지만, 개발을 계속하면서 AI에게 전달하는 조건이나 테스트 방법을 조금씩 구체화해 나갔습니다.

특히 인상 깊었던 것은, AI를 사용하면 테스트가 불필요해지는 것이 아니라, AI를 사용하기 때문에 오히려 테스트가 필요해진다는 점입니다.

이번에 Playwright를 사용하여 다음과 같은 일련의 조작을 E2E 테스트로 자동화했습니다.

• 영상 불러오기
• FFmpeg Worker 초기화
• MP4 내보내기
• MP4 다운로드
• 다운로드한 MP4 재생 확인
• Console, Page, Network 에러 확인

AI는 미경험 분야에 도전하는 허들을 크게 낮춰주었습니다.

다만, AI가 만든 것을 실제로 사용할 수 있는 상태로 가져가기 위해서는 인간 측에서 사양을 결정하고, 결과를 의심하고, 테스트하며, 완료를 판단해야 합니다.

엔지니어 2년 차임에도 AI를 잘 활용함으로써, 평소 업무만으로는 경험하기 어려운 설계, 구현, 테스트, 공개까지 한 차례 모두 경험할 수 있었습니다.

아직 개선하고 싶은 부분은 많지만, 우선 실제로 공개할 수 있는 단계까지 진행한 것을 하나의 성과로 삼아 앞으로도 개발을 계속해 나가겠습니다.