최근 내가 다니는 회사에서는 모두가 거의 같은 시기에 2주 휴가를 받는 상반기 휴식 기간이 있었다. 매니저로서 나는 지금까지 AI 도구를 본격적인 코딩보다는 코드 리뷰나 기술적 탐색에 주로 써 왔는데, 이번에는 그걸 바꿔보고 싶었다.

그래서 휴가 동안 사이드 프로젝트인 Gifty Weddings를 만지작거렸다. 이전에 2016년에는 Go 백엔드로, 2019년에는 Elm 프론트엔드로 옮겨 놓은 바 있다. 하지만 이번에는 두 가지 목표가 있었다:

1. 단순한 결혼 선물 레지스트리에서 결혼식 웹사이트 빌더로 업그레이드하기.
2. AI 도구로 고품질 코드를 작성하는 법 배우기.

동료들의 추천으로 대부분의 코딩에는 Opus 5를 탑재한 Claude Code를 사용했다. 비교적 가벼운 작업에는 오픈 웨이트 GLM 5.2 모델을 얹은 Pi를 썼다. 그리고 내 두뇌도 썼다.

농담이지만, 머리를 쓰는 것이야말로 그저 쓰레기를 찍어내는 것과 자랑스러운 제품을 만드는 것을 가르는 큰 차이라고 생각한다. 우리는 여전히 엔지니어다.

이 글에서는 AI에 대한 나의 회의감을 이야기하면서, 동시에 이번 프로젝트가 성공할 수 있었던 요인은 무엇이었는지, 그리고 왜 이 과정이 즐거웠는지도 이야기하려 한다.

회의적인 시각

나는 한동안 AI에 대해 꽤 회의적이었다. 처음에는 AI 챗봇이 뉴욕타임스 기자와 사랑에 빠졌을 때였고, 그다음에는 “기여자”들이 쏟아내는 엄청난 양의 AI 쓰레기를 상대해야 하면서 회의감은 더 커졌다.

2024년에 코딩에 한 번 써 봤을 때도 별 감흥이 없었다. 그때는 AI가 해 놓은 것을 고치는 데 직접 하는 것보다 더 많은 시간이 들었다.

좀 더 최근에는 아내의 인테리어 디자인 웹사이트를 거의 한 번에 만들면서, 그리고 GoAWK의 여러 버그를 고치면서 다시 시도해 봤다(Opus 4.6이 상당히 우유부단했던 경우도 포함해서).

두 경우 모두 인상적이었다. 웹사이트 쪽은 내가 CSS 작성을 그다지 좋아하지 않기 때문이었고, 버그 수정 쪽은 과정 자체를 크게 앞당겨 주고 좋은 아이디어를 줬기 때문이다.

나의 접근 방식

우선 나는 꽤 경험 많은 웹 개발자라는 점을 전제로 한다. 덕분에 프로세스를 이끌고 에이전트가 내놓은 결과를 효과적으로 검토할 수 있다. 덧붙이자면, AI와 관련해 내가 가장 우려하는 점 중 하나는 새로 시작하는 개발자들이 어렵게 쌓아야 할 이런 경험을 지름길로 건너뛰려 할 수도 있다는 것이다.

또한 나는 기존 작업이라는 토대 위에서 구축하고 있었다. 예전 사이트의 CSS 스타일시트(그 자체가 Skeleton을 기반으로 한 것), SQL 데이터베이스 스키마의 대부분, 그리고 만들고 싶은 것에 대한 계획에서 시작했다. 거기에 더해, 예전 Gifty 코드베이스를 많이 참고해 초기 Go 서버와 여러 패키지를 직접 손으로 작성했다. 내가 원하는 스타일의 코드를 미리 심어 둔 셈이다.

그 다음부터는 한 번에 끝내려 하기보다 점진적 개발로 전환했다. 모든 단계에서 기술적·창의적 통제권을 내가 쥐고 있었다. 각 코드 변경마다 보통 몇 문장짜리 프롬프트로 기능을 제안한 뒤, 생성된 코드를 검토하고 브라우저에서 직접 기능을 테스트했다.

나는 적당한 수준의 코드 리뷰를 했다. 코드에 대한 장인정신 중 일부는 포기해야 했다. AI의 코드 스타일이 완벽하지 않았고, 적어도 많은 경우 내가 했을 방식과는 달랐기 때문이다. 물론 버그를 짚어내고 구조적인 문제는 따져 물었지만, 대체로 AI가 작성한 코드에 꽤 만족했다.

다만 테스트는 꼼꼼히 검토하지 않았다. AI 에이전트는 엄청나게 많은 테스트를 작성하는 것 같다. 때로는 너무 과해서, 굳이 유지할 가치가 없다고 생각한 테스트는 몇 개 지우기도 했다. 처음에는 세부 내용을 좀 살펴봤지만, 끝으로 갈수록 테스트는 대충 훑어보는 수준이었다.

그 과정에서 여러 가지를 배웠다:

• LLM은 주석을 정말 장황하게 쓴다. 간결하게 쓰거나 한 줄 요약을 쓰라고 계속 지시해야 했다. “주석 간결화” 커밋 한 번에서는 주석 약 2500줄을 1500줄로 줄이기도 했다.
• Claude가 HTML과 CSS를 작성하는 능력은 헤드리스 브라우저를 설치해 스스로 스크린샷을 찍게 했을 때 훨씬 좋아졌다. 그전에는 내가 직접 스크린샷을 찍어 업로드해야 했다. 이제는 초능력이 생긴 셈이었다. Claude는 서버를 실행하고, 앱의 실제 폼을 이용해 가짜 데이터를 넣은 뒤, Chromium으로 PNG 스크린샷을 저장하고 직접 “살펴봤다”.
• 그렇다고 해도 매 변경마다 스크린샷을 찍고 처리하는 데는 토큰이 많이 들었다. 결국 중요한 프론트엔드 변경을 할 때만 그렇게 하도록 했다.
• 컨테이너에 샌드박싱해 놓았는데도(Canonical의 Workshop을 사용한다) Claude는 성가신 짓을 하곤 했다. 여러 번 rm -rf $SOMEVAR/*.png 같은 명령을 실행했는데, SOMEVAR가 설정되어 있지 않아 내가 테스트에 쓰던 사진들을 지워 버렸다. 이를 막기 위해 메모리에 몇 가지 규칙을 추가했지만, 어쨌든 LLM은 항상 컨테이너나 VM 안에서 실행해야 한다.
• 모든 작업을 한 세션에서 하지 마라. 나도 처음에는 그렇게 했는데, 컨텍스트가 엄청 길어져서 금방 Claude Pro의 여러 제한에 걸렸다. 그래서 compaction에 대해 알게 됐고, 이후로는 정기적으로 새 세션을 시작했다.

이제 내가 만든 기능들을 살펴보자.

기능

Gifty를 이용하면 커플이 사진, 글, 선물 레지스트리가 포함된 간단한 다중 페이지 결혼식 웹사이트를 만들 수 있다.(예전 Gifty는 레지스트리 기능만 지원했다.)

커플은 Markdown 섹션에 글을 쓰고, 사진을 업로드하며(사진은 크기가 축소되어 Tigris에 저장된다), 페이지를 추가하고 순서를 바꾸는 등의 작업을 할 수 있다. 물론 약간의 이용료를 받고 있으며, 결제는 Stripe로 처리된다.

하객은 커플의 웹사이트를 보고 레지스트리에서 선물을 체크해 표시할 수 있다.

하지만 예전 Gifty에서 그대로 가져온, 내가 가장 좋아하는 기능은 커플이 클릭 한 번으로 바로 체험해 볼 수 있다는 점이다.

기술 스택

나는 단순함을 유지하는 걸 좋아해서 다음과 같은 기술을 사용했다:

• 가능한 한 비표준 라이브러리 의존성을 최소화한 Go 백엔드: 업로드를 위한 AWS SDK, Stripe SDK, 이미지 리사이징 라이브러리, Markdown 렌더러, modernc.org/sqlite 모듈, 그리고 “거의 표준 라이브러리”라 할 수 있는 golang.org/x/crypto 모듈.
• 멋진 SQLite 데이터베이스.
• 좀 더 동적인 부분, 즉 선물 레지스트리와 페이지 편집 기능을 위한 Htmx.
• 그리고 필요한 곳에 약간의 바닐라 JavaScript.

호스팅은 Fly.io에서 하고 있는데, 이런 용도에는 정말 추천할 만한 서비스다. fly deploy 한 번이면 배포가 너무 쉽고 비용도 저렴하다.

그저 감사할 따름이다

새 웹사이트를 완성하는 데 꼬박 10일 정도가 걸렸다. AI 도구, 특히 이번에는 Claude에게 정말 고맙게 생각한다. 아내에게는 AI가 없었다면 세 배는 더 걸렸을 것이라고 말했다.

가장 인상적이었던 것 중 하나는 Claude가 예전 선물 레지스트리 시스템, 즉 Go JSON API와 Elm 프론트엔드로 된 것을 새 버전인 Go HTML 엔드포인트와 완전히 다른 htmx 프론트엔드로 포팅한 일이었다. 거의 한 번에 완벽하게 해내서 나에게는 뜻밖의 놀라움이었고 많은 시간을 아껴 줬다.

또 거의 한 번에 해낸 것(몇 가지 후속 버그 수정은 있었지만) 중 하나는 예전 Gifty 데이터베이스를 새로운 데이터베이스로 옮기는 마이그레이션 도구를 만든 것이었다. 데이터베이스가 비슷해서 로켓 과학은 아니지만 구조적으로 다른 부분이 몇 가지 있어 더 많은 반복이 필요할 거라 예상했었다.

그런데 전반적으로 AI에 대해 회의적이었는데도 왜 이렇게 즐거웠을까? 이유는 두 가지라고 생각한다:

첫째, 나는 만드는 걸 좋아한다. 약 10일 만에 유용하고 보기에도 근사한 웹사이트를 완성했다.

둘째, 나는 프로그래밍이라는 장인 정신을 즐기는데, 이번에도 그 즐거움을 느낄 수 있었다. 다음 기능을 구상하고, AI에게 코딩을 시키고, 코드를 검토하고, 버그를 고치고, 커밋하는 과정을 반복했다. 이를 275번 씻고 헹구고 반복했다. 작은 기능은 10~15분, 큰 기능은 한두 시간이 걸렸지만, 목표를 향해 꾸준히 나아가는 느낌이 정말 좋았다.

여전히 우려되는 점은 많고, 우리가 이 도구들로 하늘에 닿는 탑을 쌓다가 신이 우리 콧대를 꺾어야 하는 일이 없기를 바란다. 하지만 새로운 도구들에게는 감사한 마음이다.

마지막으로 한 가지: 곧 결혼을 앞두고 있거나 결혼을 앞둔 사람을 안다면, 새로운 GiftyWeddings.com을 알려 주시면 정말 감사하겠다. 결혼은 하고 싶은데 아직 상대가 없다면 — 죄송하지만 그건 다른 웹사이트에서 찾아보셔야 할 것 같다!