orbithall 개발기를 마치며
앞으로 만들 것과 에이전트와 일하는 법
2026/09/29 18:50orbithall 개발기를 마치며
orbithall 개발기의 마지막 글이다. 1편에서 6편까지 댓글 서비스를 어떻게 만들고 운영했는지 다뤘다. 이번에는 앞으로 무엇을 만들지, 그리고 코딩 에이전트인 Claude Code와 일하는 방식이 처음과 지금 어떻게 달라졌는지 돌아본다. 1편에서 궁금하다고 했던 Go 이야기의 결론도 함께 정리한다.
앞으로 만들 기능
우선순위를 정하는 기준
만들 것이 쌓이면 순서가 필요하다. 기준은 네 단계로 둔다.
- 서비스를 쓰는 데 치명적인 것
- 이미 있는 기능에 꼭 필요한 개선
- 서비스의 색깔이 되는 기능
- 자잘한 최적화와 개선
먼저 채울 것
| 기능 | 왜 필요한가 |
|---|---|
| 신고 | 익명 댓글의 문턱을 낮춘 대신, 부적절한 글을 독자가 알릴 수 있어야 한다(1편) |
| 봇 대응 강화 | 공개 키 구조에서는 레이트리밋만으로 봇을 막기 어렵다. CAPTCHA나 스팸 필터 같은 장치가 필요하다(3편) |
| API 키 재발급 | 키가 새어 나갔을 때 바꿀 방법이 있어야 한다 |
| 도메인 소유권 확인 | 지금은 같은 도메인을 먼저 등록한 사람이 차지할 수 있다(5편) |
| 댓글 조회 성능 | 답글을 댓글마다 따로 불러오는 구조를 한 번에 불러오도록 바꾼다 |
| 사이트 매니저 역할 | 사이트 주인 말고도 관리를 맡길 사람을 둘 수 있게 한다 |
신고와 봇 대응 강화는 1편과 3편에서 숙제로 남겨 둔 것들이다. 문턱 없는 댓글을 지키려면 결국 이 두 가지가 받쳐 줘야 한다.
orbithall의 색깔이 될 기능
서비스로 내놓으려면 기본 기능에 더해 이 서비스만의 특색이 있어야 한다고 1편에서 말했다. 그 후보가 리액션 기능이다. 댓글뿐 아니라 포스트 자체에도 리액션을 남길 수 있게 하고, 여기에 조회수 같은 정보까지 더하면, 블로그의 활동을 한곳에서 보여 주는 통합 솔루션이 될 수 있다. 댓글 서비스를 넘어 블로그 활동성을 다루는 서비스라면, 그게 orbithall의 정체성이 될 수도 있겠다.
물론 이런 기능이 기존 서비스에 없다고 생각하는 건 순진한 생각이다. 실제로 Disqus에는 글에 리액션을 남기는 기능이 있고, giscus도 글 자체에 대한 리액션을 보여 줄 수 있다. 결국 특색은 기능 하나가 아니라, 리액션과 조회수, 댓글을 어떻게 묶어 보여 주느냐에서 나올 것이다.
에이전트와 일하는 방식은 어떻게 달라졌나
orbithall은 2025년 가을에 대부분 만들고, 10개월을 쉰 뒤 2026년 9월에 다시 손을 댔다. 두 시기의 작업 방식은 꽤 달랐다.
2025년: 문서를 먼저 쓰고 구현
1편에서 말한 것처럼, 처음에는 작업 문서를 먼저 쓰고 그 문서를 기준으로 에이전트가 구현했다. 문서는 사람이 읽기 쉬웠다. 무엇을 왜 만드는지가 문장으로 정리돼 있었다.
대신 코드의 세부까지는 단단하게 잡아 주지 못했다. 당시에는 문서와 코드 사이에도 책임의 경계가 있다고 생각해서, 문서에 코드가 들어가는 걸 싫어했다. 문서는 의도를 말하고 코드는 구현을 말해야 한다고 봤다. 그 결과 구현이 바뀌어도 문서는 그대로 남기 일쑤였다. 어드민 계획 문서의 체크리스트는 기능이 다 만들어진 뒤에도 하나도 체크되지 않았고, 레이트리밋 문서는 코드와 다른 정책을 적은 채 남았다.
2026년: spec, plan, 그리고 리뷰
다시 시작할 때는 직접 한국어로 옮겨 쓰는 워크플로 플러그인인 suberpower를 썼다. 무엇을 만들지 정리한 spec, 그걸 어떻게 만들지 쪼갠 plan을 쓰고, 서브에이전트가 작업 단위마다 구현한 뒤, 다른 에이전트가 spec에 맞는지와 코드 품질을 차례로 리뷰한다.
plan에는 코드 조각과 실행할 명령, 기대하는 결과까지 들어간다. 그래서 코드 쪽으로는 확실히 나아졌다. 에이전트가 plan대로 움직이면 원하는 결과가 나오도록 짜여 있고, 리뷰가 한 번 더 걸러 준다. 실제로 어드민에 댓글 조회를 붙일 때, 리뷰가 plan 단계에서 놓친 빈틈 세 가지를 잡았다. 작업 범위 밖이었던 보안 문제 네 가지도 찾아냈는데, 1편에서 말한 IPv6 주소 노출도 그중 하나였다.
대신 문서를 읽기가 꽤 어려워졌다. 850줄 가까운 plan은 사람이 읽는 문서라기보다 에이전트가 실행하는 문서에 가깝다. 예전 방식이 사람이 읽기 좋은 대신 코드가 느슨했다면, 지금 방식은 코드가 단단한 대신 사람이 읽기 어렵다.
| 2025년 | 2026년 | |
|---|---|---|
| 문서 | 작업 문서 하나 | spec과 plan으로 나눔 |
| 문서의 독자 | 사람 | 사람보다는 에이전트 |
| 코드 세부 | 문서에 넣지 않음 | 코드와 명령까지 plan에 넣음 |
| 검증 | 사람이 직접 리뷰 | 에이전트가 단계마다 리뷰하고 사람이 최종 확인 |
| 아쉬운 점 | 문서와 코드가 어긋남 | 문서의 가독성이 떨어짐 |
1편에서 문서와 테스트는 있다는 것만으로 코드를 지켜 주지 않았다고 정리했다. 2026년의 방식은 여기에 리뷰라는 확인 단계를 붙인 셈이다. 문서가 있다는 것에서 멈추지 않고, 문서대로 됐는지 다른 눈이 한 번 더 본다.
사람이 쥐고 있어야 할 것
에이전트가 많은 일을 맡아 줄수록, 사람에게 남는 일은 오히려 선명해진다. 가장 중요한 건 비판적인 시각과, 상자 밖을 떠올리는 통찰력이다. 그리고 지금 문맥에서 벗어나 크게 보는 시각이다.
에이전트는 A, B, C까지 오면 D를 떠올린다. 흐름을 이어 가는 데는 탁월하다. 하지만 정말 필요한 답은 D가 아니라 1일 수도 있고, 어쩌면 알파벳이라는 틀 자체를 다시 봐야 하는 문제일 수도 있다. 에이전트가 이어 가는 흐름 밖에서, 그 흐름이 맞는지 묻는 게 사람의 몫이다.
2026년 작업에서 내 입력은 대부분 "ㅇㅇ"나 "1" 같은 짧은 답이었다. 에이전트가 선택지를 내밀면 대개 추천안을 골랐다. 그래도 몇 번은 추천안과 다른 쪽을 골랐다. 보안 문제 네 가지가 드러났을 때, 에이전트는 급한 두 가지만 먼저 고치고 나머지는 따로 하자고 권했다. 나는 네 가지 모두 배포 전에 처리하기로 했다. 작은 결정처럼 보여도, 흐름 밖에서 판단해야 하는 순간은 이런 식으로 온다.
Go를 골랐던 이유, 그 결과
1편에서 타입이 엄격하고 틀이 정해진 언어라면 에이전트와 함께 코딩할 때 더 빠르고 안정적이지 않을까 궁금하다고 했다. 결론부터 말하면 장점은 확실히 체감했다. 2편에서 말한 것처럼 컴파일 과정이 에이전트의 실수를 한 번 걸러 줬고, 반복되는 코드도 내가 직접 쓰지 않으니 부담이 덜했다.
다만 제대로 비교해 본 건 아니다. 유일하게 비교할 만한 경험은 예전에 Next.js와 Supabase로 만들면서 API까지 Next.js에서 돌렸던 프로젝트인데, 그건 정말 별로였다. 그것보다는 확실히 낫다.
다음 백엔드도 아마 Go를 고를 것 같다. 다른 걸 골라 본다면, 개발 속도를 볼 때는 Django, 학습 목적으로는 Rust가 떠오른다. 정말 야망을 갖고 안정성에 투자해야 하는 서비스라면 Java도 괜찮은 선택이다.
이 시리즈를 쓴 방식
마지막으로 작은 고백을 하나 해야겠다. 일곱 편 내내 에이전트와 일한 이야기를 했는데, 사실 이 글들도 에이전트와 함께 썼다. 끝까지 눈치채지 못하셨다면, 에이전트가 제 몫을 꽤 잘해 준 셈이다.
세 저장소(API 서버, 어드민, 블로그)를 에이전트 세 개가 나눠 조사해 사실 문서를 만들고, 편마다 그 사실을 근거로 나를 인터뷰한 뒤 초안을 쓰고, 내가 첨삭해서 발행했다. 그 과정에서 따로 요청한 것들이 있다.
| 요청 | 이유 |
|---|---|
| 기억이 흐린 부분은 근거부터 찾아 달라 | 기억에만 기대면 사실이 틀어질 수 있어서, 근거를 보며 기억을 선명하게 한 뒤 답하려고 |
| "버그가 아니었어도 언급됐을까?"로 비중을 판단한다 | 조사하다 찾은 문제에 끌려 글의 초점이 흐려지지 않게 |
| 글을 쓰다 찾아서 고친 것은 원래 그렇게 설계한 것으로 쓴다 | 고친 과정이 글의 주제를 강화하지는 않아서 |
| "LLM" 대신 "에이전트", "바이브 코딩" 대신 "에이전틱 코딩" | 실제로는 파일을 읽고 빌드를 돌리는 에이전트와, 코드를 읽고 확인하며 일했으니까 |
| 블로그 글은 "글", DB의 데이터는 "포스트"로 구분한다 | 데이터로 다룬다는 맥락이 흐려지지 않게 |
| 중제목은 평이하게, 굵은 글씨는 큰 흐름에만 | 비유보다 읽기 쉬운 쪽이 좋아서 |
| 다른 저장소의 일은 그 저장소의 에이전트에게 넘긴다 | 5편에서 말한 것처럼, 맥락이 섞여 잘못된 판단이 번지지 않게 |
에이전트는 저장소를 뒤지고 초안을 쓰는 일을 빠르게 해냈다. 무엇을 쓰고 무엇을 뺄지, 어떤 말투로 쓸지는 결국 내가 정했다. 이 글에서 말한 "사람이 쥐고 있어야 할 것"은 글을 쓸 때도 다르지 않았다.
마치며
작은 블로그에 댓글을 달겠다고 시작한 일이 일곱 편의 글이 됐다. orbithall은 여전히 기본에 충실한 댓글 서비스이고, 앞으로 만들 것도 많다. 이 블로그 글 아래의 댓글창이 그 결과물이니, 읽고 떠오른 이야기가 있다면 편하게 남겨 주시면 좋겠다.
저장소
- API 서버와 위젯: june20516/orbithall
- 어드민: june20516/orbithall-admin