프롤로그 — AI가 코드를 만드는 시대, 개발자는 무엇을 해야 할까
지난 토요일, 개발 업무로 다시 복귀하기 위해 취업과 기술 동향을 살펴보던 중 함께 활동하는 카카오톡 오픈채팅방에서 인천 송도에서 열리는 바이브코딩 세미나 소식을 접했습니다.
Stack Overflow와 검색 엔진이 사실상 전부였던 시기를 지나, 지금은 Claude Code, Codex와 같은 AI 에이전트가 코드 작성은 물론 문서 정리, 테스트, 브라우저 조작까지 대신하는 시대가 되었습니다.
저 역시 여러 AI 도구를 사용하고 있지만, 도구가 빠르게 발전할수록 새로운 고민도 생겼습니다.
AI가 구현을 대신한다면 개발자는 무엇을 잘해야 할까?
단순히 더 좋은 프롬프트를 작성하는 방법이 아니라, 기존 코드베이스에 AI를 어떻게 도입하고 결과물을 어떤 기준으로 검증해야 하는지가 궁금했습니다.
혼자 빠르게 만드는 것과 팀이 지속해서 운영할 수 있는 제품을 만드는 것 사이에는 어떤 차이가 있는지도 들어보고 싶었습니다.
그런 기대를 안고 2026년 7월 25일, 인천 송도에서 열린 Vibe, Dive! 7월 미니 컨퍼런스에 다녀왔습니다.
Vibe, Dive!는 어떤 행사였나
행사 안내 페이지에는 이번 모임을 다음과 같이 소개하고 있었습니다.
바이브로 빠르게 만들고, 다이브로 깊이 있게 검증하는 사람들의 작은 모임.
행사는 오후 1시부터 저녁 7시 30분까지 이어졌고, 총 여덟 개의 발표와 Q&A, 네트워킹으로 구성되었습니다.
| 구분 | 내용 |
|---|---|
| 일시 | 2026년 7월 25일 토요일, 13:00~19:30 |
| 장소 | 인천 송도 에이피텍 7층 |
| VIBE | AI로 아이디어를 구체화하고 혼자 빠르게 제품을 만드는 방법 |
| DIVE | 스펙, 문서, 리뷰, 검증을 통해 AI 결과물을 실제 업무에 안착시키는 방법 |
여덟 개 세션의 주제와 제가 받아들인 핵심 내용을 먼저 정리하면 다음과 같습니다.
| 발표자 | 발표 주제 | 핵심 내용 |
|---|---|---|
| 민혁 | 바이브 시대의 출판 에디터의 워크플로우 | 반복 업무가 자동화될수록 결과를 판단하는 편집자의 기준이 중요해집니다. |
| 저스틴 | Agentic AI와 온톨로지 | 업무 데이터를 검색하는 것을 넘어 개념과 관계를 구조화해야 합니다. |
| Andy | SDD 프로세스 개발 및 적용 | 코드를 수정할 방향타로 스펙과 기술적 의사결정, 변경 이력을 관리합니다. |
| 김병용 | RunyourAgent 서비스 개발기 | 코딩만 빨라지고 기획과 리뷰가 따라오지 못하면 팀 전체는 오히려 느려질 수 있습니다. |
| 다니엘 | AgentCat 개발기 | 여러 에이전트의 사용량과 작업 상태를 파악할 수 있는 관측성이 필요합니다. |
| 유병욱 | AI Agent가 가져다주는 거 막 먹지 마세요 | 동작하는 코드와 실제로 배포할 수 있는 제품은 다른 상태입니다. |
| 권태환 | 에이전틱의 도입 | 기존 코드베이스에는 문서, 공통 스킬과 완료 게이트가 필요합니다. |
| 이승민 | 바이브코딩으로 꾸준히 돈 벌기 | 개인 개발에서는 복잡한 체계보다 제품과 도메인에 집중하는 전략도 유효합니다. |
행사 제목만 보았을 때는 바이브코딩 도구와 프롬프트 활용법이 중심일 것이라고 생각했습니다.
하지만 실제 발표를 관통한 주제는 조금 달랐습니다.
코드를 생성하는 속도보다 무엇을 만들지 결정하고, 만들어진 결과를 검증하고, 지속할 수 있는 구조로 남기는 일이 더 중요해졌다는 것이었습니다.
바이브 시대, 출판 에디터의 업무는 어떻게 달라졌을까
첫 발표는 한빛미디어 에디터 민혁님의 「바이브 시대의 출판 에디터의 워크플로우」였습니다.
개발자가 아닌 출판 에디터가 AI 에이전트를 실제 업무에 어떻게 활용하는지 볼 수 있어 흥미로웠습니다.
원고의 오탈자와 용어를 확인하는 수준을 넘어, Word 문서를 Markdown으로 변환하고 출판사 내부 스타일을 적용하거나 HWP로 전달받은 수정 목록을 PDF 주석으로 옮기고, 수정 전후 문서를 비교하는 작업까지 자동화하고 있었습니다.
이런 작업은 규칙이 분명하지만 사람이 직접 하면 많은 시간이 필요합니다.
발표에서 소개한 사례에서는 검수해야 할 수정 주석이 처음에는 500여 개에 달했고, 후속 수정 과정에서 100여 개, 다시 50여 개 수준으로 줄었습니다.
이처럼 많은 수정 요청을 원고에 옮기고 제대로 반영되었는지 매번 확인하는 일은 전형적인 반복 업무입니다.
AI를 이용하면 사람은 모든 항목을 직접 옮기는 대신, 변환 결과와 누락된 항목을 검토하는 쪽에 집중할 수 있습니다.
그렇다고 편집자의 일이 사라진 것은 아니었습니다.
AI로 글을 만드는 일이 쉬워지면서 투고 원고의 양이 늘었고, 오탈자는 줄었지만 비슷한 비유와 문장 구조, 번역투처럼 AI가 자주 만드는 표현도 함께 늘었다고 합니다.
결국 편집자의 업무는 단순 교정에서 무엇이 좋은 원고인지 판단하고, 출판사의 기준에 맞게 고치는 일로 이동하고 있었습니다.
개발도 비슷하다고 느꼈습니다.
코드 생성 비용이 낮아지면 코드의 양은 늘어납니다.
이때 필요한 것은 더 많은 생성이 아니라, 좋은 코드와 나쁜 코드를 구별할 수 있는 기준입니다.
RAG만으로 부족한 이유, Agentic AI와 온톨로지
저스틴님의 「Agentic AI와 온톨로지」 발표는 기업에서 실제 업무를 수행하는 에이전트를 만들 때 무엇이 필요한지 다뤘습니다.
일반적인 RAG는 문서를 작은 단위로 나누고, 질문과 의미가 비슷한 내용을 찾아 LLM에 전달합니다.
사내 규정이나 문서에서 특정 정보를 찾는 용도로는 유용하지만, 업무의 전체 구조와 항목 사이의 관계까지 이해하지는 못합니다.
예를 들어 보험 상품을 검색할 때 단순 RAG는 질문과 가까운 특약 문서를 찾을 수 있습니다.
그러나 계약, 특약, 보장, 면책 조건이 어떻게 연결되는지 구조를 모르면 어떤 항목이 빠졌는지, 추가로 무엇을 확인해야 하는지 판단하기 어렵습니다.
온톨로지는 이때 업무에 등장하는 개념과 관계를 구조화합니다. 흩어진 문서를 검색하는 데서 그치지 않고, 무엇이 존재하며 서로 어떻게 연결되는지 보여주는 업무 지도를 만드는 셈입니다.
| 구분 | RAG | 온톨로지 |
|---|---|---|
| 기본 단위 | 문서를 나눈 텍스트 조각 | 업무의 개념, 속성과 개념 사이의 관계 |
| 정보를 찾는 방법 | 질문과 의미가 비슷한 문서를 검색 | 관계와 규칙을 따라 연결된 정보를 탐색 |
| 잘하는 일 | 비정형 문서에서 관련 내용을 빠르게 찾고 답변 | 구조를 이해하고 연관 항목과 누락된 조건을 확인 |
| 한계 | 검색된 조각 밖의 관계나 전체 구조를 놓칠 수 있음 | 초기 설계와 데이터 정제, 지속적인 관리 비용이 큼 |
| 적합한 사례 | 사내 문서 검색, 규정과 매뉴얼 질의응답 | 보험 상품 구성, 조직과 시스템 의존성처럼 관계가 중요한 업무 |
둘 중 하나만 선택해야 하는 것은 아닙니다.
RAG로 관련 문서를 찾고, 온톨로지로 개념 사이의 관계를 보완하는 방식처럼 함께 사용할 수 있습니다.
발표에서 더 중요하게 느껴진 부분은 기술 자체보다 도입 순서였습니다.
- 현업 담당자가 어떤 용어를 사용하고 실제로 어떻게 일하는지 파악합니다. (FDE - Forward Deployed Engineer)
- 업무에 필요한 데이터가 어디에 있고 어떻게 이동하는지 확인합니다. (데이터 발굴 및 분석)
- 개념과 관계를 온톨로지로 구조화합니다.
- 에이전트 설계.
무언가 일을 시작하기 전과 마찬가지로, 에이전트 제작의 시작점은 현장의 파악이라는 점을 알 수 있었습니다.
코드가 항상 진실은 아니다 — SDD와 변경 이력
Andy님의 「SDD 프로세스 개발 및 적용」 발표는 문서가 부족한 기존 코드베이스에 AI 에이전트를 도입하면서 겪은 문제에서 시작했습니다.
요구사항은 메신저로 전달되고, 기획 문서와 실제 구현이 다르며, 코드 품질도 일정하지 않은 상황에서 LLM에 리팩터링을 맡기면 어떤 일이 생길까요?
AI는 현재 코드를 기준으로 열심히 작업하지만, 그 코드가 애초에 잘못된 의사결정의 결과라면 잘못된 방향을 더 빠르게 확장할 수 있습니다.
이 과정에서 나온 문장이 인상 깊었습니다.
코드가 있다고 해서 그 코드가 곧 진실은 아니다.
Andy님은 제품 요구사항, UX, 기술적 의사결정, 작업 단위를 서로 다른 형태로 분리했습니다.
- 제품이 무엇을 해야 하는지는 스펙으로 관리합니다.
- UX의 기준은 Figma에 둡니다.
- 기술적 의사결정은 ADR(Architecture Decision Record)에 남깁니다.
- 실제 구현 작업은 티켓으로 관리합니다.
특히 Immutable PRD와 Append-only 방식이 흥미로웠습니다.
기존 문서를 계속 덮어쓰는 대신, 새로운 결정이 생기면 이전 문서를 대체하는 새 버전을 만들고 그 관계를 남깁니다. 최신 문서만 보면 현재 기준을 알 수 있고, 과거 문서를 따라가면 왜 결정이 바뀌었는지도 확인할 수 있습니다.
스펙을 만드는 과정에도 검증 장치가 있었습니다.
한 번에 하나씩 질문하고, 모호한 내용은 AI가 임의로 채우지 않으며, 여러 관점의 적대적 리뷰와 정해진 승인 기준을 통과해야 다음 단계로 넘어가게 했습니다.
모든 변경에 무거운 스펙을 요구한 것은 아닙니다.
제품 요구사항이 달라지는 작업에는 스펙을 사용하고, 단순 버그 수정처럼 기존 스펙을 바로잡는 작업은 더 가볍게 처리했습니다.
중요한 것은 특정 도구를 그대로 따르는 것이 아니라, 조직 상황에 맞는 크기의 절차를 만드는 일이었습니다.
코딩은 빨라졌는데 팀은 왜 느려졌을까
김병용님의 「RunyourAgent 서비스 개발기」 는 AI가 개발팀에 빠르게 퍼졌을 때 발생한 문제와, 기업용 에이전트 서비스의 메모리를 개선한 경험을 다뤘습니다.
처음에는 한 사람이 AI로 많은 코드를 작성하면서 놀라운 생산성을 보여줬습니다.
곧 팀원 모두가 AI를 사용하기 시작했고, 프론트엔드 개발자가 백엔드까지 수정하는 등 개인의 작업 범위도 넓어졌습니다.
그러나 개발 속도가 기획 속도를 앞지르면서 문제가 생겼습니다.
여러 개발자가 각자 기획을 해석했고, 다른 사람이 만든 코드를 다시 AI에게 물어보며 수정했습니다.
구현량은 늘었지만 코드의 의도와 책임은 흐려졌고, 사이드 이펙트와 리뷰 비용이 증가했습니다.
발표에서는 코딩이 전체 제품 개발 업무의 일부에 불과하다고 설명했습니다.
코딩 구간만 빨라져도 기획, 합의, 리뷰, 테스트, 운영이 함께 개선되지 않으면 팀 전체의 속도는 오히려 느려질 수 있습니다.
메모리 개선 과정에서도 비슷한 교훈을 볼 수 있었습니다.
- 최근 대화만 유지하는 방식은 구현이 쉽지만 오래된 맥락을 잃습니다.
- 문서를 임베딩해 검색하는 시맨틱 메모리는 지식 베이스를 만들 수 있지만, OCR과 파싱 같은 전처리 비용이 생깁니다.
- 첨부파일과 대화에서 얻은 경험까지 활용하는 Semantic Experience Memory를 추가하면, 여러 정보원 사이의 검색 가중치와 우선순위를 정해야 합니다.
- 기업용 서비스에서는 사용자와 조직의 데이터가 섞이지 않도록 테넌트 격리(Tanant Isolation)도 고려해야 합니다.
기능 하나를 추가하면 속도, 정확도, 보안, 운영이라는 다음 문제가 따라옵니다.
고객의 피드백을 받고 제약을 발견할 때마다 이슈를 해결하고 구조를 개선하는 과정이 인상 깊게 느껴졌습니다.
툴의 홍수 속에서 AgentCat이 필요했던 이유
다니엘님의 「AgentCat 만들며 툴의 홍수 시대에, 우린 어떻게 하죠?」 발표는 빠르게 늘어나는 AI 도구와 개인 개발 경험을 다뤘습니다.
과거에는 하나의 IDE와 개발 도구를 오랫동안 사용했습니다.
지금은 Claude Code, Codex, Gemini CLI를 비롯한 에이전트와 터미널, IDE, 오케스트레이션 도구가 계속 등장합니다.
이제는 도구를 고르는 일 자체가 일이 될 정도입니다.
발표에서 제안한 기준은 단순했습니다.
남들이 좋다고 하는 도구보다 직접 사용했을 때 손에 맞는 도구를 선택하고, 부족한 기능은 오픈소스에 기여하거나 자신에게 맞게 고쳐 쓰는 것입니다.
AI 덕분에 기존 도구가 기능을 추가해 주기만 기다리지 않고, 사용자가 도구의 일부를 직접 만들 수 있게 되었기 때문입니다.
AgentCat 역시 개인적인 불편에서 시작했습니다.
여러 에이전트를 함께 사용하면 도구별 사용량, 토큰, 세션, 프로젝트와 시스템 자원 상태를 한눈에 파악하기 어렵습니다.
AgentCat은 이 정보를 귀여운 고양이 메뉴바 앱으로 보여주는 관측 도구입니다.
에이전트 사용이 많아질수록 관측성이 중요해진다는 점에 공감했습니다.
에이전트가 보이지 않는 곳에서 병렬로 일하는 환경에서는 단순히 결과 파일만 보는 것으로 부족합니다.
어느 프로젝트에서 얼마나 사용했는지, 어떤 작업이 실행 중인지, 비용과 자원이 어디에서 소비되는지 확인할 수 있어야 합니다.
또한 발표에서는 코딩부터 시작하지 말고 요구사항, 설계, 테스트 방법을 먼저 정리하라고 강조했습니다.
코드를 덜 보게 되는 시대일수록 개발자의 가치는 사라지는 것이 아니라 비즈니스와 사용자를 이해하고, 에이전트가 만든 선택에 책임지는 방향으로 이동하고 있었습니다.
AI가 가져다준 결과를 그대로 먹으면 안 되는 이유
유병욱님의 「AI Agent가 가져다주는 거 막 먹지 마세요」는 이번 행사에서 가장 직접적으로 검증과 책임을 다룬 발표였습니다.
AI가 만든 코드는 빌드에 성공하고 기본 동작까지 할 수 있습니다. 하지만 그것만으로 실제 서비스에 배포할 수 있는 것은 아닙니다.
- 개인정보가 암호화되지 않았을 수 있습니다.
- 로컬 주소나 개발 환경의 IP가 코드에 남아 있을 수 있습니다.
- 변경 단위가 너무 커서 일부 기능만 되돌리기 어려울 수 있습니다.
- 실제 기기, 조명, 네트워크, 브라우저에서는 동작하지 않을 수 있습니다.
- 라이선스와 저작권, 운영 비용이 검토되지 않았을 수 있습니다.
AI는 결과물을 만들지만 승인하지는 않습니다.
코드가 저장소에 들어가고 서비스에 배포되는 순간, 그 결정의 책임은 결국 사람에게 돌아옵니다.
특히 개인 게임 프로젝트의 사례가 기억에 남았습니다.
AI가 완성도를 95%라고 평가했지만, 실제 출시를 위해 남은 5%에는 UI, 게임 밸런스, 사운드와 이미지의 상업적 이용 조건, 개인정보처리, 모니터링과 문의 대응 같은 일이 포함되어 있었습니다.
오히려 마지막 5%에 앞선 구현보다 훨씬 많은 시간이 들어갔다고 합니다.
이 발표를 들으며 동작하는 코드와 배포 가능한 제품은 전혀 다른 상태라는 점을 다시 생각하게 되었습니다.
배포 전에는 최소한 다음 항목을 확인해야 합니다.
| 요구사항 | 기획 의도와 완료 조건을 충족했는가? | 기능은 동작하지만 사용자의 문제를 해결하지 못함 |
| 코드 | 변경 이유와 구조를 사람이 설명할 수 있는가? | 유지보수와 장애 대응이 어려워짐 |
| 테스트 | 실패 경로와 엣지 케이스까지 검증했는가? | 테스트는 통과하지만 실제 오류가 남음 |
| 실제 환경 | 실제 기기, 브라우저와 네트워크에서 확인했는가? | 로컬에서는 동작하지만 현장에서는 실패함 |
| 보안·개인정보 | 권한, 비밀값, 암호화와 수집 범위를 점검했는가? | 정보 유출과 법적 문제가 발생할 수 있음 |
| 라이선스·비용 | 코드와 생성 자산의 이용 조건, 운영 비용을 확인했는가? | 배포 후 저작권 문제나 예상하지 못한 비용이 발생함 |
| 운영 | 로그와 모니터링, 기능 중단과 롤백 방법이 있는가? | 장애 원인을 찾거나 신속하게 복구하기 어려움 |
기존 코드베이스에 에이전트를 도입하는 방법
권태환님의 「에이전틱의 도입」 발표는 개인 프로젝트가 아니라 기존 팀과 코드베이스에 AI를 넣을 때 필요한 과정을 다뤘습니다.
개인 프로젝트에서는 AI에게 전체 코드를 제공하고 빠르게 결과를 만들 수 있습니다.
반면 오래된 모바일 프로젝트에는 이미 수많은 규칙과 예외, 과거의 의사결정이 쌓여 있습니다.
이런 맥락 없이 AI에게 작업을 맡기면 하나의 파일에 모든 코드를 몰아넣거나, 기존 계약과 다른 API를 만드는 등 유지하기 어려운 결과가 나올 수 있습니다.
이를 막기 위해서는 코드와 함께 PRD, 개발 문서, 디자인, 팀의 스킬과 워크플로우를 연결해야 합니다.
하나의 거대한 문서에 모든 내용을 넣기보다 상위 개념과 세부 문서를 나누고, 필요한 맥락을 찾을 수 있게 만들어야 합니다.
발표에서 소개한 방식은 프롬프트 하나를 잘 쓰는 데서 끝나지 않았습니다.
- 요청을 작은 작업으로 분해합니다.
- 작업에 필요한 스킬과 워크플로우를 선택합니다.
- 실행 과정과 확인한 근거를 기록합니다.
- 완료 게이트에서 처음 요청이 실제로 충족되었는지 검사합니다.
- 작업 중 발견한 문제를 다시 스킬과 문서에 반영합니다.
Claude Code나 Codex처럼 사용하는 도구가 달라져도 팀의 기준은 같아야 합니다.
그래서 도구마다 지침을 따로 관리하기보다 공통 스킬과 규칙을 한곳에서 관리하는 접근도 소개되었습니다.
핵심은 AI로 사람을 줄이는 것이 아니라, 반복되는 재작업을 줄이고 같은 인원으로 더 나은 결과를 만드는 데 있었습니다.
결국 에이전틱 도입은 모델 선택보다 팀이 일하는 방법을 코드와 문서로 표현하는 작업에 가까워 보였습니다.
바이브코딩으로 꾸준히 돈을 번다는 것
마지막 발표는 이승민님의 「바이브코딩으로 꾸준히 돈 벌기」였습니다.
이번 행사 등록에 사용한 TicketTaco를 혼자 개발하고 운영한 경험을 들을 수 있었습니다.
발표 당시 기준으로 TicketTaco는 1년 이상 운영되었고, 기술 커뮤니티를 중심으로 100개가 넘는 행사를 진행했으며 누적 거래액은 약 2억 원에 달했다고 합니다.
AI를 이용해 서비스를 빠르게 만든 이야기뿐 아니라, 고객을 모으고 서비스를 계속 운영한 현실적인 과정이 함께 소개되었습니다.
개발할 때는 하나의 기능을 한 번에 맡기지 않고 단계별로 대화를 나눈다고 했습니다.
데이터베이스 설계와 UX처럼 의사결정이 필요한 부분에는 많은 시간을 사용하고, 마이그레이션이나 API처럼 방향이 정해진 작업은 AI에게 맡겼습니다.
AI가 없던 시절에는 가짜 데이터와 여러 예외 상황을 준비하는 비용이 컸지만, 지금은 그 비용이 낮아져 작은 단계로 나누어 검증하기 쉬워졌습니다.
흥미로운 점은 복잡한 하네스를 따로 만들지 않았다는 것입니다.
혼자 운영하는 규모에서는 모노레포 전체와 대화 자체를 컨텍스트로 사용하고, 모든 결과를 직접 확인하는 방식을 선택했습니다.
팀이 커지면 바뀌어야 할 방법이지만, 현재 규모에서는 하네스를 관리하는 시간보다 제품에 시간을 쓰는 것이 더 합리적이라는 판단이었습니다.
수익화의 핵심도 AI가 아니었습니다.
오랫동안 기술 커뮤니티에서 발표하고 행사를 운영하며 쌓은 도메인 지식과 관계 덕분에, 어떤 기능이 필요한지 알고 초기 고객에게 직접 다가갈 수 있었습니다.
자신이 원래 하던 일, 좋아하는 일, 잘 아는 일에 AI를 얹어 문제를 해결한다.
AI는 행동 비용을 낮춰 주었지만 어떤 문제를 풀지, 누구에게 판매할지, 힘든 시기를 어떻게 버틸지는 알려주지 않았습니다.
서비스를 오래 유지할 수 있었던 이유 역시 유행을 따라 새로운 아이템을 찾았기 때문이 아니라, 자신이 좋아하고 잘 아는 분야의 문제를 선택했기 때문이었습니다.
내가 마지막 세션에 특히 공감한 이유
제가 마지막 세션에 특히 공감한 이유는 AI가 개인 개발의 구현 장벽을 크게 낮췄다는 점 때문입니다.
예전에는 필요한 기술이 부족하거나 혼자 감당하기에는 범위가 커서, 혹은 함께할 사람을 구하지 못해 아이디어를 실현하지 못하는 경우가 많았습니다.
이제 AI 모델 서비스와 에이전트 도구가 그 빈틈을 상당 부분 채워 주고 있습니다.
저 역시 Notion에 작성한 개발 문서를 MCP로 Claude Code에 연결해 활용했습니다. 기획 의도와 목적, 설계 방향, 테스트 사항을 문서로 정리했습니다.
AI는 이를 바탕으로 계획을 세우고 작업을 나눈 뒤 코드 작성과 기초 검증을 수행했습니다.
다만 Android의 UI와 UX처럼 실제 사용 흐름을 판단해야 하는 부분은 사람이 마지막으로 확인했습니다.
혼자 개발할 때는 프로젝트의 맥락을 이미 알고 있으므로 복잡한 워크플로우를 먼저 구축할 필요가 적습니다.
AI 모델과 범용 에이전트 환경의 발전은 서비스 제공자에게 맡기고, 반복해서 사용하는 규칙과 검증 기준만 가벼운 스킬로 정리하는 편이 효율적일 수 있습니다.
당시에는 이 과정을 별도의 스킬로 만들지 않았지만, 지금이라면 재사용할 부분을 추려 정리했을 것 같습니다.
제가 직접 만든 스킬보다 공식 에이전트 환경에서 제공하는 스킬이 더 안정적으로 동작했던 경험도, 도구 계층을 계속 관리하는 데 드는 비용을 생각하게 했습니다.
수요 검증이 목적인 토이 프로젝트라면 자동화와 복잡한 프로세스를 구축하는 비용이 더 클 수 있습니다.
그렇더라도 Git 커밋 전에는 변경된 코드를 직접 읽어야 한다고 생각합니다.
AI가 요구사항이나 엣지 케이스를 놓칠 수 있고, 현재 구현에 맞춰 테스트 조건을 느슨하게 바꾸는 경우도 있었기 때문입니다.
테스트 통과만으로 작업이 끝났다고 판단해서는 안 됩니다.
프로세스의 무게를 높여야 하는 전환점은 실제 사용자가 생기거나 다른 사람과 협업하기 시작할 때입니다.
이때부터는 개인이 알고 있던 맥락을 문서와 스킬로 옮기고, 배포 전 검수와 운영 절차를 갖춰야 합니다.
| 우선 목표 | 아이디어와 수요를 빠르게 검증 | 안정성과 반복 가능한 개발 |
| 맥락 관리 | 개인이 문서와 코드 흐름을 직접 파악 | 문서, 스킬, ADR 등으로 공유 |
| AI 활용 | 대화 중심의 빠른 계획·구현 | 공통 워크플로우와 검증 게이트 적용 |
| 검증 | 커밋 전 직접 검토와 핵심 테스트 | 리뷰, 자동화 테스트, 배포 전 점검과 모니터링 |
AI가 기술과 인력의 빈틈을 메워 주면서 아이디어를 시도할 기회는 분명히 늘었습니다.
만들고 싶은 것이 있다면 작게 구현하고 사용자 반응을 확인한 뒤, 필요한 만큼 프로세스를 보강하면 됩니다.
이제 더 중요한 변수는 아이디어를 실제 행동으로 옮기는 실천력이라고 느꼈습니다.
세미나 내용을 실제 개발에 적용한다면
이번 발표를 들은 뒤, AI 에이전트를 이용한 제 작업 흐름도 다음과 같이 정리해 볼 수 있었습니다.
아래 절차를 모든 토이 프로젝트에 같은 무게로 적용할 필요는 없습니다.
수요를 확인하는 단계라면 핵심 문서와 커밋 전 검토만으로 가볍게 시작할 수 있습니다.
실제 사용자가 생기거나 협업을 시작했다면 그때부터 테스트, 문서와 운영 게이트를 강화하는 편이 현실적입니다.
1단계: 코드를 요청하기 전에 문제를 정의합니다
- 누가 어떤 상황에서 겪는 문제인지 적습니다.
- 이번 작업에서 바꾸지 않을 범위를 정합니다.
- 기능, 성능, 보안 관점의 완료 조건을 작성합니다.
- 모호한 부분은 AI가 추측하지 않고 질문하게 합니다.
2단계: 에이전트가 읽을 수 있는 기준을 준비합니다
- 제품 요구사항과 화면 기준
- 데이터 구조와 API 계약
- 아키텍처 결정과 그 이유
- 기존 코드의 제약과 팀 규칙
- 테스트 및 배포 방법
문서는 길게 하나로 만들기보다, 필요한 정보를 쉽게 찾을 수 있도록 주제별로 나누는 편이 좋습니다.
3단계: 작업을 작게 나눠 구현합니다
설계, 데이터 변경, 비즈니스 로직, UI, 테스트를 한 번에 맡기지 않습니다. 위험도가 낮고 검증 가능한 단위로 나누고, 각 단계의 결과를 확인한 뒤 다음 작업으로 넘어갑니다.
4단계: 자동 검증과 실제 환경 검증을 분리합니다
- 빌드, 정적 분석, 단위 테스트와 통합 테스트
- 보안 및 개인정보 검사
- Android와 iOS 실제 기기 확인
- 느린 네트워크와 권한 거부 같은 실패 경로 확인
- 기존 기능의 회귀 테스트
자동화 테스트가 통과했더라도 사용자가 실제로 겪을 환경에서는 별도로 확인해야 합니다.
5단계: 사람이 승인하고 되돌릴 수 있게 만듭니다
배포 전에는 변경 이유와 영향 범위를 사람이 설명할 수 있어야 합니다. 로그와 모니터링을 준비하고, 문제가 생기면 기능을 끄거나 이전 버전으로 돌아갈 방법도 마련해야 합니다.
6단계: 실패를 다음 작업의 컨텍스트로 남깁니다
AI가 틀린 이유가 단순 실수인지, 문서가 없었기 때문인지, 완료 기준이 모호했기 때문인지 회고합니다. 반복될 가능성이 있다면 팀의 스킬, 규칙, ADR과 체크리스트에 반영합니다.
이 마지막 단계가 있어야 에이전트가 매번 처음부터 같은 실수를 반복하지 않고, 팀의 방식도 조금씩 개선될 수 있습니다.
마치며 — 빠르게 만들고, 깊이 검증하기
이번 세미나에서 새로운 도구 이름도 많이 들었지만, 가장 오래 남은 것은 도구보다 개발자의 역할에 대한 이야기였습니다.
AI가 코드를 대신 작성한다고 해서 개발자가 필요 없어지는 것은 아니었습니다.
오히려 무엇을 만들지 정의하고, 서로 다른 선택지의 장단점을 판단하고, 결과물을 실제 환경에서 검증하며, 최종 결정에 책임지는 역할이 더 선명해지고 있었습니다.
과거에는 코드를 직접 작성하는 능력이 개발자의 생산성을 크게 좌우했다면, 앞으로는 좋은 기준을 만들고 그 기준을 팀과 AI가 함께 사용할 수 있게 하는 능력이 중요해질 것 같습니다.
동시에 개인 개발에서는 프로세스를 만드는 일 자체가 목적이 되지 않도록 경계하고, AI 모델 서비스의 발전을 활용해 제품과 사용자에게 더 많은 시간을 쓰는 판단도 필요합니다.
저 역시 AI가 만들어준 코드가 동작한다는 이유만으로 작업을 끝내지 않고, 왜 이렇게 만들었는지 설명할 수 있는지, 운영 중 문제가 생겼을 때 되돌릴 수 있는지까지 살펴보려 합니다.
댓글