On This Page
Share this post

Share this post
지난해 테오콘에서 들었던 말이 기억에 남았습니다.
"내가 필요로 하는 서비스를 만드세요."
"내가 꾸준히 사용하는 게 뭔가? 아쉬움을 느끼고 있는 것은 뭔가?"라고 되짚어보니 기술 블로그였습니다.
개발을 시작하면서 꾸준히 사용하고 있고, 기존에 사용하던 블로그 서비스에서 여러 아쉬움을 느끼고 있었습니다.
프로젝트에서 구현한 기능을 블로그에서 동작할 수 있게 한다면 좋겠다.
아.. 이런 스타일을 적용하고 싶은데, 왜 됐다가 안됐다가 하지?
숏폼이 인기를 끌고 AI를 사용해 검색하고 요약하는 시대에, 이제까지의 블로그 형식에 사용자들이 흥미를 느낄까?
마침 우테코 동문분이 AI로 웹툰을 만드는 것을 하고 계셨고, AI 햄스터 유튜브 같은 콘텐츠도 즐겨보고 있었습니다. 그때 생각이 들었습니다. "개발 글도 텍스트만 아니라 웹툰이나 동영상처럼 재미있게 표현할 수 있지 않을까?"
그래서 결정했습니다.
"직접 만들어보자." 그리고 "AI 도구가 정말 좋은지 확인해보자."
깔끔한 디자인의 프로젝트를 하고 싶지만 디자인 능력은 없고, 혼자 검토하기엔 놓치는 부분들이 있었으며, 문서화를 좋아하지만 반복적인 문서 작업은 일의 효율성을 낮추고는 합니다.
저는 저의 부족한 점, 해결하고 싶은 점을 세 가지 AI 도구들로 보완했습니다.
처음엔 피그마로 직접 디자인을 만들었습니다. 하지만 시간이 오래 걸렸고, 결과물도 1차원적이었습니다. 이왕 만드는 것 더 좋은 결과물을 원했습니다.
SNS에서 Stitch를 발견하고 시도해보았습니다. 1차 피그마 디자인, 참고 자료(디자인 템플릿 사이트, 원하는 느낌의 이미지 등), 프로젝트 구조를 함께 설명했습니다.
Stitch가 제공해준 것들:
이 과정에서 깨달은 것은 AI 디자이너도 개발 AI와 같은 원리로 동작한다는 점이었습니다.
다음 프로젝트에서도 반드시 사용할 것 같습니다.
혼자 개발하다 보니 놓치는 부분들이 생겼습니다. 예상 못한 엣지 케이스, 웹 접근성 이슈, 성능 최적화 포인트 같은 것들입니다.
CodeRabbit을 도입했습니다. 웹 접근성, 보안, 성능 등 다방면으로 검사하고 꼼꼼하게 리뷰하도록 설정했습니다.
CodeRabbit이 제공해준 것들:
혼자는 못 보는 것들이 있습니다. AI 리뷰어는 일관되게 그 맹점을 메워주었습니다.
혼자 하는 프로젝트라도, 문서화를 꼼꼼하게 하려고 노력하는 편입니다. 팀 프로젝트와 실무에서 문서화가 도메인/레거시에 대해 이해하고 싶을 때 얼마나 큰 도움이 되는지 느꼈기 때문입니다.
이슈 생성, PR 작성, 커밋 메시지 작성 같은 문서화와 컨벤션을 맞추는 반복 작업들이 많았습니다. 퇴근 후, 황금 같은 연휴 때 시간을 내서 하는 프로젝트이다 보니, 반복적인 문서화에 드는 시간을 줄이고 개발에 더 집중하고 싶었습니다.
Claude Code를 사용해 GitHub CLI와 연동한 커맨드 기능을 통해, 이를 해결할 수 있었습니다. (지금도 커맨드로 뚝딱! 나와의 대화와 기존 컨벤션을 기반으로, 문서화가 될 때마다 큰 만족감을 느끼고 있습니다. ☺️)
Claude Code가 제공해준 것들:

Claude Code 채팅창 - 마일스톤 번호를 찾아 이슈 생성

GitHub에 생성된 이슈 - Claude가 자동으로 작성한 이슈 본문
생산성 향상은 확실했습니다. 하지만 이 과정에서 더 중요한 깨달음을 얻었습니다.
SNS에서 "며칠 만에 프로젝트 완성"이라는 글을 자주 봤습니다. 저도 처음엔 그 정도의 속도를 기대했습니다.
하지만 실제로는 그렇지 않았습니다.
전체 개발 사이클을 보니
| 단계 | 예상 | 실제 |
|---|---|---|
| 1️⃣ 설계 문서 작성 | 중간 | ⏰ 오래 |
| 2️⃣ 프롬프트 작성 | 중간 | ✅ 빠름 |
| 3️⃣ AI 코드 작성 | - | ✅ 빠름 |
| 4️⃣ 검토 및 피드백 | 빠름 | ⏰ 오래 |
| 5️⃣ 수정 및 배포 | 빠름 | 중간 |
설계(1)와 검토(4)는 여전히 개발자의 책임이고, 이 두 단계가 전체 개발 시간을 좌우했습니다.
Claude에게 "아티클 리스트 페이지 만들어줄래?"라고 하면 뭔가 만듭니다. 하지만 제가 원하는 대로 만들지는 않았습니다.
명확히 정의해야 했습니다:
머릿속에 있던 것을 말로 구체화하는 작업이 꼭 필요했습니다. 코드를 직접 치던 시간이 이런 설계 작업으로 옮겨갔습니다.
"AI가 코드를 작성하지만, 책임은 내가 진다."
AI와 페어 프로그래밍을 한다는 생각으로 개발을 하고 있습니다. 전통적인 페어 프로그래밍에서 네비게이터와 드라이버가 역할을 나눠서 진행하지만, AI와의 페어 프로그래밍에서는 방향을 설정하고 핸들을 잡는 것 모두 개발자의 책임이라는 점이 다릅니다. 마치 자율 자동차가 알아서 주행하지만, 운전석의 핸들은 여전히 운전자가 잡고 있는 것처럼요.
Claude가 짠 코드를 받을 때:
개발 중에 Claude의 답변을 보며 던진 질문들:
이렇게 구현한 근거는 뭔가? 그 근거가 올바른 지식 기반인가?
현재 구조가 오버 엔지니어링은 아닌가?
확장 가능한가?
오류 처리는 충분한가?
Tailwind를 사용하는 프로젝트에서 블로그 카테고리별 뱃지의 스타일을 상수로 관리하고 싶었습니다.
Claude의 답변:
export const CATEGORY_LABELS_COLOR = {
troubleshooting: { bg: "bg-red-100", text: "text-red-500" },
};
<div className={CATEGORY_LABELS_COLOR[category].bg}>
일부 색상은 작동했습니다. 나머지는 적용되지 않았습니다.
왜일까요?
Tailwind는 빌드 타임에 동작합니다. 정적으로 작성된 클래스명만 감지할 수 있고, 변수를 통해 동적으로 생성되는 클래스명은 감지하지 못합니다.
문제는 Claude의 대답이 그럴듯하다는 것입니다. 그래서 검증하지 않으면 위험합니다. 오류가 스노우볼처럼 커질 수 있습니다.
오류를 지적하니 Claude는 즉시 수긍하고 수정된 코드를 제시했습니다. 로컬 환경에서는 이런 오류를 쉽게 확인할 수 있지만, 복잡한 도메인과 레거시가 가득한 코드에서 Claude의 오류를 발견하지 못한다면 치명적 결과로 이어질 수 있습니다. 실제로 최근에 여러 대형 서비스에서 이와 같은 이슈들이 있었습니다.
이번 블로그 프로젝트를 통해 가장 많이 느낀 것은 AI가 주는 편안함이나 바이브 코딩의 놀라움보다는 서비스를 구현하는 자의 책임감입니다.
AI 도구들이 제 부족한 부분을 채워주었습니다:
그리고 이 모든 과정에서 한 가지 확실해졌습니다.
AI는 도구일 뿐, 개발자가 책임자라는 것입니다.
그리고 그 책임을 다하기 위해서는 탄탄한 프로그래밍 지식이 필수라는 것을요.
요즘 AI 시대에 개발자의 미래를 걱정하는 사람들이 많습니다. 저 또한 그렇습니다.
최근에 읽은 글 중 가장 공감이 가는 내용은 개발자의 책임감과 오류를 감지하는 프로그래밍적 감각과 지식였습니다.
우테코에서 코치님에게 빨리 변하는 기술 스택에 대해 조언을 구한 적이 있습니다. 코치님은 "결국 기본기가 중요하다"고 말씀해주셨습니다. 새로운 기술도 이전 기술의 토대 위에서 발전하고, 탄탄한 기본기는 이를 빠르게 흡수하는 역량이 된다고요.
개발자는 늘 빠르게 발전하는 기술을 흡수하고 나아가는 직업입니다. 이를 알고 개발자의 길을 선택했지만, AI는 정말 빠르고 무섭게 오는 파도라 나도 모르게 휩쓸리고 가라앉지 않을까 두려운 마음이 큰 것 같습니다.
하지만 어떤 AI의 버전과 기능이 나와도, 프로그래밍적 지식이 탄탄하고 서비스에 대한 책임감이 있는 개발자가 된다면, 휩쓸리거나 가라앉지 않을 것 같습니다.
마치 새로운 유행이 계속해도 클래식은 영원한 것처럼요.