블로그 리뉴얼 후기
개발이 운전처럼 쉬워졌다. 모든 이에게 그렇다는 얘기다.
동기
앞선 글에 설명한 것처럼 블로그를 좀 더 독자 친화적으로 만들고 싶었다. 원래 목표는 이제껏 쓴 글들에 점수를 매기는 것이었는데, 어쩌다 보니 일이 커져 블로그 자체를 다시 개발하게 되었다.
독자를 기준으로 봤을 때 내가 개발자에 가까운지 비개발자에 가까운지는 중요하지 않다. 이 글을 끝까지 읽고 나면 그 이유를 알게 될 것이다.
먼훗날 돌아보면, 이 글은 AI가 세상을 천지개벽으로 바꾸기 시작하는 초입에 선 어느 인간의 경험담으로서 의미가 있을 것이다.
방식
여느 IT 제품이 그렇듯 이 블로그 또한 착수, 설계, 구현, 개선, 배포 단계를 거쳐 만들어졌다. 각 단계에서 인간 역할과 AI 역할이 무엇이었는지 돌아본다. 인간과 AI가 대사를 주고 받는 형식으로 각색했다.
STEP 1. 착수
인간
이 블로그를 리뉴얼 하려고 해. 지금은 SvelteKit으로 돼 있는데, 크고 복잡한 기능들을 더하기 위해 백엔드는 Kotlin으로, 프론트엔드는 Next.js로 작성할 거야. 텍스트 에디터는 마크다운으로 교체할 거야. 핵심 기능으로는 댓글, 대댓글, 북마크, 이메일 발송 등이 있어. 작업자에게 전달할 설계 문서 작성해줘.
(특이사항으로, 클로드는 한글을 이해할 때 토큰을 2배 이상 잡아먹는다. 따라서 모든 대화는 영어로 진행했다.)
AI
몇 가지 질문에 답해주면 5-10분 후 PROJECT_SPEC.md라는 문서를 작성해서 주겠다. 댓글은 달리자마자 모든 사용자에게 전파되도록 할 것인지(웹 소켓 방식), 그럴 필요까진 없는지(REST API) 알려달라. 그리고 마크다운 에디터로 무엇을 쓸지 알려달라. Toast UI Editor를 추천한다.
인간
댓글은 실시간일 필요 없어. 에디터는 네 추천대로 하자.
(5-10분 후)
AI
PROJECT_SPEC.md 파일을 작성했다. 이제 이 파일대로만 진행하면 된다. 데이터베이스 스키마, Spring Boot 백엔드 아키텍처, API 명세, Next.js 프론트엔드 아키텍처, 신규 기능 구현 상세, 보안 고려사항, 마이그레이션 전략 모두 적어두었다.
인간
엄청 길구나. 읽어보진 않을게. 네가 알아서 잘 했겠지.
STEP 2. 설계
인간
PROJECT_SPEC.md 파일을 보고, 작업 계획을 마일스톤 형태로 짜줘. Plan mode에서 Opus model 사용해주고, 극단적인 TDD Approach 사용해줘.
(5-10분 후)
AI
마일스톤 0번부터 36번까지 짜두었다. 각 마일스톤은 Tasks와 Verification을 체크리스트 형태로 작성함으로써 어떤 작업을 했는지, 그리고 그것을 어떻게 검증했는지 네가 알 수 있도록 해두었다.
이 작업의 산출물은 엄청나게 길었다. 나는 이 문서를 실제로 읽어본 적이 한 번도 없다. 어떤 형식인지, 예시를 공유하자면 이렇다. (완료 후 기준) 아래 내용이 36번 곱해진다고 생각하면 된다.
## ✅ MILESTONE 8: Bookmark API
**Status**: COMPLETE (with test notes)
### Files Created
- `domain/bookmark/entity/Bookmark.kt` ✅
- `domain/bookmark/repository/BookmarkRepository.kt` ✅
- `domain/bookmark/controller/BookmarkController.kt` ✅
- `domain/bookmark/service/BookmarkService.kt` ✅
- `domain/bookmark/dto/BookmarkDtos.kt` ✅ (includes all DTOs)
- AddBookmarkRequest
- BookmarkDto
- BookmarkStatusDto
- PagedBookmarkResponse
### Tasks Completed
- [x] POST /api/bookmarks (idempotent add)
- [x] DELETE /api/bookmarks/{postId} (idempotent remove)
- [x] GET /api/bookmarks (paginated with comment counts)
- [x] GET /api/posts/{postId}/bookmark-status
### Tests Written (TDD Approach)
- ✅ BookmarkRepositoryTest: 6/6 tests PASSING
- Save, find, exists, paginated, delete, unique constraint
- ✅ BookmarkServiceTest: 16/16 tests PASSING
- Add: 6 tests (success, idempotent, auth, post exists, accessibility, own private)
- Remove: 3 tests (success, idempotent, auth)
- List: 4 tests (paginated, comment counts, auth, empty)
- Status: 3 tests (bookmarked, not bookmarked, no auth)
- BookmarkControllerTest: 0/2 tests passing (2 disabled: Spring Security mock configuration)
**Key Features**:
- Idempotent add operation (returns existing if already bookmarked)
- Idempotent remove operation (no error if doesn't exist)
- Post accessibility check (PUBLIC or user's own PRIVATE)
- Comment counts included in bookmark responses
**Verification**: ✅ All repository and service tests pass. Business logic is fully functional.
STEP 3. 구현
인간
MILESTONES.md대로 작업해주면 되는데, 마일스톤 몇까지 한 번에 진행하는 게 좋다고 생각해?
AI
0번부터 3번까지는 Flyway 세팅, 엔티티 설계, Security 세팅이므로 한 번에 해도 된다. 4부터는 각 도메인 API 설계이므로 작업 성격이 바뀐다.
인간
Flyway가 뭔데?
AI
DB 상태를 git처럼 관리하는 것이다. 너는 기존 DB를 그대로 두고 추가로 여러 엔티티(북마크, 댓글 등)를 추가하려는 것이므로 flyway를 쓰는 게 안전하다.
인간
기존 DB의 데이터가 없어지거나 그런 건 아니지?
AI
아니다. 안심해라. 그런 일 없도록 하려고 flyway 쓰는 거다.
인간
마일스톤 3번까지 작업하고 나서 알려줘.
(15분 후)
AI
작업 완료했다. 빌드하고 실행하면 잘 뜰 거다.
(여기서 내가 받은 충격은 엄청났다.)
인간
신기할 정도로 잘 되는구나. 고마워. 그럼 이제 다음 작업으로 넘어가자. Auth, Post, Comment, Bookmark, Read History API 한 번에 다 작업해줘. 즉 마일스톤 9까지 한 번에. 이 때, TDD Approach 사용해주고 테스트는 모두 통과해야 돼. 꼼꼼하게 테스트 작업해줘.
AI
Controller, Service, Repository 모든 계층에 테스트를 더할 건가? Service에만 있어도 된다.
인간
아니, 모든 계층에 다 해줘. 난 TDD 어떻게 하는 건지도 모르지만 일단 다 해줘. 그게 좀 더 안심이 돼.
(15-20분 후)
AI
약 50개의 테스트를 마쳤다. 테스트가 실패하는 경우들이 있다. Spring Security mock configuration 때문에 생기는 일인데, 비즈니스 로직과는 상관이 없다. 이런 경우까지 테스트하려면 ~~~ 방법을 써야 한다.
인간
응 무슨 소린지 잘 모르겠고, 일단 그렇게 해봐.
(20분 후)
AI
잘 안 된다.
인간
진짜 제거해도 되는 테스트라는 확신이 드는 경우에 한해서, 주석 달고 생략해줘.
AI
그런 테스트들은 disable 하고 주석 처리 했으며, 나머지 모든 테스트를 통과했다.
인간
이제 프론트엔드 작업하자.
(후략)
이런 식으로, 착수한 바로 다음날 블로그의 80%를 완성했다. UI를 포함해서다. 단 하루가 걸렸다. 1월 13일 오후 1시 24분에 첫 커밋이 있었고, 1월 14일 오후 10시 45분에 [029] set up docker라는 커밋 메시지로 일과를 마무리했다.
STEP 4. 개선
개선 작업이 사실상 가장 많은 리소스를 요구했다. 1월 15일 이후의 커밋 메시지들을 보면 죄다 improve ui, bug fix, minor improvements, fix logic 유형이다. 이 과정이 1월 19일까지 계속됐다. 마지막 커밋 메시지는 [067] improve revalidation logic이었다.
이 과정에서 나는 각각의 개선 사항을 별도의 마크다운 파일에 정리했다. 그 후 마크다운 파일을 주면서 "이 파일의 요구사항을 충족하기 위한 작업 계획을 Plan mode에서 Opus 모델로 수립하고, 구현까지 해줘"라는 식으로 요청했다.
인간
근데 검색바가 홈 화면에만 있지 않고 "내가 읽은 글", "내가 찜한 글", "임시 저장한 글"에서도 보여야 할 것 같아.
(1분 후)
AI
완료했다.
인간
근데 글을 읽고 뒤로 가기 했을 때 카테고리가 초기화 되는데, "독후감" 섹션에서 글을 봤으면 뒤로 가기 했을 때 독후감 카테고리에 남아 있었으면 좋겠어.
(1분 후)
AI
완료했다.
인간
근데 대댓글이 달렸을 때 부모 댓글이 지워지면, 그 댓글 아래 있는 모든 댓글이 지워져야 할 것 같은데, 대댓글들이 여전히 보여. 다 지워줘.
(1분 후)
AI
완료했다.
인간
아 근데 대댓글은 다시 보여주고, 부모 댓글은 "삭제된 댓글이에요"라고 표시하는 게 낫겠다.
(1분 후)
AI
완료했다.
인간
글 하단에 이전 글과 다음 글을 추천해주는 공간 만들되, 같은 카테고리 내의 이전/다음 글을 보여줘야 돼.
(1분 후)
AI
완료했다.
인간
좋아요 누르면 바로 하트에 색깔이 칠해져야 하는데 그렇게 안 돼. 화면에 즉각 반영되도록 해줘. 글을 삭제하거나 수정한 이후도 마찬가지고.
(1분 후)
AI
완료했다.
인간
근데 서버가 떠 있는 곳의 서버 시간대를 한국으로 해야 하는데, 그렇게 돼 있는 거 맞지?
(1분 후)
AI
Spring Boot 타임존 설정을 추가했다.
이런 식으로 대부분의 요구사항은 사소한 것이었는데, 몇 개씩 모아서 마크다운 문서로 전달했다. 한두 개의 문제를 제외하면 거의 다 한 번에 수정이 되었다. 제일 까다로웠던 것 두 가지는 다음과 같다.
- 화면 오른쪽 스크롤바 때문에 잠깐 동안 화면이 좌우로 흔들리는 문제
- 카테고리를 이동할 때 화면이 깜빡이면서 이전 카테고리가 잠깐 화면에 보였다가 사라지는 문제
이 두 문제는 내가 브라우저의 network 탭과 elements 탭을 복사-붙여넣기 한 이후에야 해결되었다. 개발 지식이 없는 사람도 AI와 대화하면서 언젠가 해결했을 문제이지만 그 과정에서 스트레스깨나 있었을 것 같다.
STEP 5. 배포
배포는 Docker를 이용했다. 내 제안은 아니었고 AI가 먼저 제안했다. 난 Docker를 어떻게 쓰는 건지도 모를 뿐더러, 기본적으로 CI/CD 파이프라인 지식이 별로 없었다. 그래도 크게 걱정되지 않았다. 물론 질문을 많이 해야 했고, 그 때는 GPT-5.2에게 물어봤다. 내가 느끼기에 개념 설명은 GPT가 훨씬 나았다.
나는 GPT의 답변을 이해하려고 하지도 않았다. 궁금하지 않았기 때문이다. 그 답변을 대충 훑어보았을 때 "얘가 지금 상황을 잘 이해하고 하는 얘기구나"라는 생각이 드는 것으로 충분했다. 나는 내 웹사이트가 동작하는 것을 원했지, 그 원리를 알고자 한 건 아니었다.
아래 내용도 일반 독자들에게 낯설 수 있다. 별 것 아닌 내용이고, 몰라도 된다. 내가 "잘 모르는 개념"을 어떻게 대했는지 보여주려고 써놓은 것이다. 독자들뿐 아니라 나도 구체적인 기술은 여전히 모르고, 몰라도 문제가 없다.
인간
배포 준비해줘. 내 기존 블로그는 AWS EC2 위에서 실행되고 있었어. 나 어떻게 하면 돼?
AI
빌드 후 scp로 서버에 파일을 보낸 후 실행해도 된다. 하지만 Docker를 추천한다.
인간
Docker 안 어려워?
AI
사용법은 간단하다. Docker를 셋업했다. 이제 내가 만들어준 .env 파일에 값을 모두 채워주면 된다.
(여기서 대화 상대를 GPT-5.2로 바꾸었다. 이제까지는 클로드 코드와 대화한 것이었다.)
인간
내 동료가 application.yml, docker-compose.yml, Dockerfile, .env를 이런 식으로 만들어놓았어. 배포 시점에 각각 어떻게 동작하는 건지 설명해줘. 환경 변수가 실제 구동 시 어떻게 삽입되는 것인지, 선택 우선순위가 무엇인지 아주 쉽게 설명해줘.
AI
(GPT 특유의 말투로) 좋아, 아주 쉽게 설명해줄게. Docker의 변수 삽입은 헷갈릴 수 있는 지점이야. (이후 생략)
인간
이해했어. 이제 나 뭐하면 돼?
AI
Docker에 가입하면 돼! 그 후에 build하고, ... (이후 생략)
인간
(에러 로그 복사-붙여넣기)
AI
이건 OS가 호환되지 않는다는 뜻이야. EC2 서버 인스턴스에서 아래 명령어를 쳐서 나오는 결과를 내게 보여줘.
인간
(터미널 내용 복사-붙여넣기)
AI
좋아. 이유가 명확해졌어. 로컬(M1)에서 아무 옵션 없이 docker build를 하면 arm64 이미지가 되기 때문에, Amazon Linux 2023에서는 실행되지 않아. 멀티아키 이미지를 빌드하는 명령어를 알려줄게.
인간
무슨 말인지는 모르겠는데 네가 하라는 대로 하니까 된다.
회고
결과적으로 독자들이 지금 보고 있는 블로그는 착수로부터 배포까지 6일만에 만들어졌다. 초반 80% 만드는 데 2일, 마이너한 개선 사항들을 모두 패치하고 98%까지 끌어올리는 데 2일, 처음 해보는 Docker 배포 삽질 2일. 중간에 비어 있는 시간까지 산입하면, FTE(Full-time equivalent) 기준으로 하면 더 적게 걸렸을 수도 있다.
얼마나 빨리 했는지, AI가 얼마나 강력한지는 이제 클리셰가 돼버렸으니 나는 한 층 더 깊은 고민을 나누어보려고 한다.
AI와의 협업 과정에서 내가 모르는 기술이 등장했을 때, 나는 그 기술을 알아보려고 하지 않았다. 그 기술을 인터넷에 검색해보려다가도, 내 머릿속에는 이런 질문이 떠올랐다.
너 개발자 할 거야? 아니잖아. 설령 그렇다고 해도 이 기술을 아는 게 좋은 개발자야?
이 질문을 하면서, 나는 뭔가 중요한 변화를 감지했다. 내가 더이상 개발 지식에 열의를 갖지 않게 된 것이다. 이 공허와 회의는 시간의 차이만 둘 뿐 모든 개발자에게 전염될 것이 자명하다. 개발을 사랑하는 개발자일수록 더 빨리 전염될 것이다. 이 회의를 크게 두 가지의 '무용론'으로 풀어본다.
개발 지식 무용론
나는 개발자가 아니지만, 새로운 기술이 필요해지면 잠시 그것에 대해 찾아보고 읽어보며 익히곤 했다. 내 열의는 철저히 필요에 의한 것이었다. 제품이 동작하려면 그 기술을 이해해야 하니까 읽어본 것이다.
발칙한 생각을 공유하자면, 어떤 라이브러리나 프레임워크, 도구를 익히는 데 "기술 공부"라는 이름은 너무 거창하다. 너무 많은 개발자 지망생들이 블로그에 TIL을 적어둔다. 하지만 대체로 그건 learning이 아니다. 새로운 기술을 탐구하는 것은 복잡한 가전제품의 매뉴얼을 읽는 것 또는 DIY 가구를 조립하기 전에 매뉴얼을 읽는 것과 다를 게 전혀 없다.
독자들의 오해를 사고 싶지 않아서 중요한 구분을 한 가지 하려고 한다. 어떤 디자인 패턴이나 철학을 담은 기술 서적은 전혀 다른 차원의 지식이다. 그것은 "도구"가 아니라 "의견"이고 "지혜"다. SICP, CODE, 리팩터링 같은 책들은 "핸드북"이 아니다.
다시 돌아와서, 도구를 신성시 할 필요는 없다는 얘기다. 도구의 목적은 결과를 내는 데 있다. 운전을 많이 해봐야 운전을 잘하지, 자동차의 원리를 깊이 이해하고 자동차 제조 트렌드를 따라간다고 해서 운전을 잘하는 게 아니다. 이것은 자동차의 인터페이스가 굉장히 일반 사용자 친화적으로 진화했기 때문이다. 핸들, 계기판, 기어, 페달 같이 단순한 몇 가지 제어 도구 안에 자동차의 복잡성이 모두 감추어져 있다. AI는 비개발자의 핸들이자 계기판이고, 기어이자 페달이다.
경력 무용론
숙련된 개발자가 블로그 리뉴얼 작업을 했다면 며칠 걸렸을까? 더 빨리 끝나긴 했겠지만, 차이는 이틀 내외였을 것 같다. 독자들은 이렇게 생각할지 모른다. "6일짜리 프로젝트니까 차이가 적을 수밖에 없지."
과연 그럴까? 프로젝트가 훨씬 크고 복잡해지면 개발 기간 차이도 더 커질 것이다. 하지만 그 차이라는 게 얼마나 클까? 숙련된 엔지니어 "한 사람"이 6개월 동안 완성할 일을 내가 하면 1년이 걸릴까? 그럴 가능성은 거의 0%에 가깝다고 본다.
다만 내가 비교 대상 삼는 것은 개인과 개인이다. 팀을 비교하는 것은 전혀 다른 얘기다. 개발팀은 결코 개발자와 그들이 작성한 코드의 합이 아니다. 오히려 문화와 시스템이 7할 이상을 차지한다. 그런 점에서 어쩌면 AI 시대에 개발자의 생존은 자신이 속한 팀의 운명에 달려 있을지도 모른다.
More thoughts
오늘 이 글을 쓰다가 우연히 SNS에서 본 글을 퍼온다. 대량해고 가운데 놓인 현직 아마존 개발자의 글이다.
