agile

ODW #4: 코파일럿에서 파일럿으로, 에이전틱 코딩으로 구현부터 PR까지 자동화 (새 탭에서 열림)

LY Corporation의 'Orchestration 길드'는 단순한 코드 보조를 넘어 AI가 자율적으로 개발 사이클을 주도하는 '에이전틱 코딩(Agentic Coding)'으로의 전환을 제안합니다. 명세 주도 개발(SDD)과 MCP(Model Context Protocol)를 결합하여 AI 에이전트가 기획 문서를 읽고 구현 계획 수립부터 풀 리퀘스트(PR) 작성까지 수행하도록 하는 것이 핵심입니다. 이를 통해 개발자는 단순 반복 업무에서 벗어나 고차원적인 설계와 검토에 집중함으로써 전체적인 생산성을 비약적으로 높일 수 있습니다. **단순 보조를 넘어선 에이전틱 코딩의 정의** * 기존 AI 도구가 코드 자동 완성 수준에 머물렀다면, 에이전틱 코딩은 고수준의 목표를 스스로 분해하고 자율적으로 실행하며 피드백을 통해 조정하는 방식입니다. * AI 에이전트가 전체 코드베이스와 파일 간 관계를 이해하고, 테스트 실패 시 스스로 수정하며 빌드 성공까지 반복하는 '파일럿' 역할을 수행합니다. * Jira와 Confluence 같은 사내 시스템을 MCP로 연결하여 AI가 최신 요구 사항 명세서를 직접 참조할 수 있는 환경을 구축하는 것이 기술적 토대가 됩니다. **1단계: MCP 기반의 구현 계획 수립과 리뷰** * 에이전틱 코딩의 성패는 초기 구현 계획의 정교함에 달려 있으며, 이를 위해 Jira와 Confluence URL에서 정보를 수집하는 커스텀 슬래시 명령어를 활용합니다. * Claude Code의 'Explore Agent' 기능을 병렬로 사용하여 메인 컨텍스트를 유지하면서도 광범위한 코드 분석과 문서 조사를 동시에 수행합니다. * 분석 결과는 `plan.md`와 같은 독립된 파일로 출력하여 사람이 미리 리뷰할 수 있게 함으로써, AI가 엉뚱한 방향으로 구현을 시작하는 리스크를 방지합니다. **2단계: 자율적 구현과 품질 검증 및 PR 작성** * 확정된 구현 계획서를 바탕으로 AI가 코드를 작성하며, 단순 생성을 넘어 테스트 코드 추가, 린트(Lint), 빌드(Build) 과정을 스스로 반복합니다. * 작업 단계를 명시한 커스텀 명령어를 통해 AI가 할 일 목록(To-do list)을 생성하고 누락 없이 작업을 완수하도록 가이드합니다. * 구현 완료 후에는 미리 정의된 템플릿에 따라 배경, 대응 영역, 테스트 관점 등을 포함한 상세한 PR 설명을 자동으로 작성하여 공유합니다. **3단계: AI 셀프 리뷰와 피드백 대응** * 작성된 PR에 대해 AI가 스스로 스크리닝 리뷰를 수행하고, 잠재적인 오류나 개선 사항에 대해 코멘트를 남깁니다. * AI는 자신의 셀프 코멘트뿐만 아니라 다른 팀원이 남긴 리뷰 내용까지 파악하여 수정안을 제시하고 실제 코드에 반영합니다. * 이 과정에서 사람은 AI가 내린 판단의 적절성만 최종 승인함으로써 리뷰 및 수정에 드는 비용을 획기적으로 줄입니다. **에이전틱 코딩 도입의 성과와 과제** * **장점:** 여러 에이전트를 병렬로 실행하여 코드 생성 속도를 높일 수 있으며, 사전 계획 수립 과정을 통해 잠재적 리스크를 조기에 발견할 수 있습니다. * **주의 사항:** AI가 생성한 대량의 코드를 검토해야 하는 리뷰어의 부담이 커질 수 있으므로, '최종 책임은 사람에게 있다'는 인식과 품질 유지 프로세스가 필수적입니다. * **워크숍 결과:** 약 2,500명의 엔지니어가 참여하여 40% 이상이 실무에 적용하거나 활용할 의사를 밝히는 등 긍정적인 확산 효과를 확인했습니다. 에이전틱 코딩을 성공적으로 도입하기 위해서는 명확한 명세서 작성을 선행하고, AI가 작업 계획을 파일 형태로 기록하게 하여 사람과의 접점을 만드는 것이 중요합니다. 기술 부채를 방지하기 위해 AI가 작성한 코드의 품질을 엄격히 관리하는 체계를 병행할 것을 권장합니다.

기획부터 개발까지 전부 직접 했습니다 – 우테코 7기 크루 서비스 론칭! | 우아한형제들 기술블로그 (새 탭에서 열림)

우아한테크코스 7기 크루들이 기획부터 디자인, 개발 및 운영까지 전 과정을 직접 수행하며 실제 사용자를 위한 서비스를 성공적으로 론칭했습니다. 이번 프로젝트는 단순한 기술 습득을 넘어 개발자가 왜 기획과 디자인에 참여해야 하는지, 그리고 사용자 피드백이 아키텍처와 도메인 설계에 어떤 영향을 미치는지 몸소 체험하는 과정이었습니다. 결과적으로 크루들은 2주 단위의 스프린트와 실시간 모니터링, 배포 환경 구축 등 실무에 근접한 경험을 통해 현장 중심의 문제 해결 역량을 갖춘 개발자로 성장했습니다. **개발자 중심의 기획과 협업 문화의 정착** - 우아한테크코스는 레벨 3, 4 과정을 통해 개발자가 직접 기획과 디자인을 포함한 서비스의 전주기를 책임지는 팀 프로젝트를 진행합니다. - 기술적인 구현뿐만 아니라 말하기, 글쓰기 교육을 병행하여 팀원 간의 의견 조율 및 설득 등 소프트 스킬의 중요성을 강조합니다. - 아키텍처 설계와 같은 기술적 결정이 팀의 목표와 사용자의 가치에 어떻게 부합해야 하는지 고민하며 개발자의 역할을 확장했습니다. **픽잇(Pickeat): 취향과 제약을 반영한 협업형 식사 선택 서비스** - "아무거나"라는 답변 뒤에 숨겨진 기피 음식과 다이어트 등의 제약 사항을 실시간 투표로 해결하여 최적의 식당을 추천합니다. - 위치 정보 기반의 식당 자동 조회 및 템플릿 기능을 도입하여 반복되는 회식이나 미팅 시 의사결정 속도를 높였습니다. - 데모데이와 홍보를 통해 받은 피드백을 바탕으로 UI와 백엔드 도메인 구조를 유연하게 재설계하며 사용자 중심의 반복적인 개선 과정을 거쳤습니다. **보따리(Bottari): 실시간 동기화 기반의 상황별 체크리스트** - 출근, 여행, 이사 등 다양한 상황에 맞춘 템플릿 기반 리스트 생성과 팀 단위의 실시간 협업 체크 기능을 제공합니다. - 단순한 기능 구현을 넘어 사용자가 물건을 잊지 않게 돕는 알림 타이밍과 체크 상태 동기화 등 사용자 경험(UX)의 세부 요소를 정밀하게 다듬었습니다. - '기술은 문제를 해결하는 도구'라는 철학 아래 사용자가 안심하고 기억을 맡길 수 있는 흐름을 구현하는 데 집중했습니다. **커피빵(Coffee Bread): 웹소켓 기반의 실시간 내기 미니게임** - 가위바위보보다 더 큰 재미와 긴장감을 주기 위해 실시간 미니게임과 가중치 적용 룰렛 시스템을 도입한 서비스입니다. - 웹소켓(WebSocket) 기술과 분산 환경이라는 기술적 난제를 극복하며 실시간 상호작용이 끊김 없이 이루어지도록 개발했습니다. - 게임의 공정성과 재미를 위해 룰렛 알고리즘을 수차례 수정하고, 실제 사용자들의 피드백을 반영해 밸런스를 최적화했습니다. 이 서비스들은 단순한 교육용 프로젝트를 넘어 실제 배포와 운영을 거치며 기술적 완성도를 높였습니다. 개발자가 기획 단계부터 깊이 관여할 때 사용자에게 더욱 가치 있는 프로덕트가 탄생한다는 점을 시사하며, 실무적인 문제 해결 역량을 키우고 싶은 주니어 개발자들에게 좋은 협업의 귀감이 됩니다.

AI TOP 100이 우리에게 남긴 것들 (새 탭에서 열림)

카카오의 'AI Native 전략 팀'은 단 2주라는 물리적으로 불가능해 보이는 일정 속에서 AI를 극한으로 활용해 'AI TOP 100' 경진대회 시스템을 성공적으로 구축했습니다. 이번 프로젝트는 단순한 도구 도입을 넘어 기획서를 AI 프로토타입으로 대체하고 개발의 99%를 AI에게 위임하는 등 소프트웨어 개발 패러다임의 근본적인 전환을 증명했습니다. 결국 AI는 개발자를 대체하는 것이 아니라, 개발자가 더 높은 차원의 의사결정과 설계에 집중할 수 있도록 능력을 확장하는 강력한 파트너임을 확인시켜 주었습니다. **전통적 방법론을 탈피한 AI 네이티브 전략** * **물리적 한계 돌파:** 기획부터 배포까지 통상 수개월이 걸리는 공정을 예선과 본선 각각 2주라는 초단기 일정으로 단축하기 위해 AI 정면 돌파를 선택했습니다. * **기획서 없는 개발:** 상세 기획서나 화면 설계서 대신, 멤버 전원이 AI로 실제 작동하는 프로토타입을 제작하여 이를 바탕으로 요구사항을 확정하는 '초고속 프로토타이핑' 방식을 도입했습니다. * **PoC 중심의 애자일:** 추상적인 컨셉을 AI에게 던져 즉시 작동 가능한 PoC(Proof of Concept) 코드를 생성하고, 이를 검증하며 기능을 확정하는 '구현-피드백-전환' 사이클을 극단적으로 짧게 가져갔습니다. **AI와 개발자의 협업 모델 변화** * **99%의 코드 위임:** Cursor와 Claude Code 등을 활용하여 전체 코드의 대부분을 AI가 작성하게 했으며, 개발자는 직접 타이핑하는 대신 AI에게 의도를 설명하고 결과물을 검토하는 역할에 집중했습니다. * **압도적인 생산성:** 한 명의 개발자가 예선과 본선의 모든 프론트엔드 화면을 전담하거나, 하루에 2억 개의 토큰을 소모하며 시스템을 구축하는 등 기존 개발 방식으로는 불가능한 퍼포먼스를 기록했습니다. * **직무 경계의 확장:** 데이터 엔지니어가 백엔드 개발을 수행하고, 비개발자가 AI로 복잡한 알고리즘 문제를 해결하는 등 AI를 통해 개인의 기술적 한계를 넘어선 역할 수행이 가능해졌습니다. **기술적 난제와 인간의 역할(The Last Mile)** * **모델 간 논리 충돌:** AI가 제시하는 논리가 매우 탄탄하여 구성원 간 의견이 대립할 때, 최종적인 유지보수성과 시스템의 방향성을 고려해 최적의 답을 선택하는 것은 결국 시니어 개발자의 '경험'이었습니다. * **최종 의사결정의 주체:** AI는 수많은 해결책과 초안을 제시할 수 있지만, 해당 서비스의 특수성과 미래 가치를 판단하여 방향키를 쥐는 것은 여전히 사람의 몫임을 재확인했습니다. * **새로운 개발 표준의 정립:** AI 페어 프로그래밍이 일상화되면서, 개발자의 사고 흐름이 '선형적 구현'에서 'AI와 실시간 아이디에이션 및 즉각적 검증'으로 재편되었습니다. **실용적인 결론 및 제언** 미래의 개발 경쟁력은 AI를 단순한 보조 도구로 쓰는 것을 넘어, 업무 프로세스 전체를 AI 중심으로 재설계하는 'AI 네이티브' 역량에 달려 있습니다. 이제 개발자는 바닥부터 코드를 짜는 시간보다 AI가 생성한 결과물의 적합성을 판단하고 아키텍처 관점에서 통합하는 능력을 키워야 합니다. 'PoC 중심 개발'을 통해 불확실성을 속도로 돌파하는 경험을 쌓는 것이 새로운 개발 표준에 적응하는 핵심이 될 것입니다.

POPM 과정은 어떻게 하나의 ‘제품’이 되었나 (새 탭에서 열림)

카카오의 POPM 교육은 단순한 지식 전달 과정을 넘어, PO와 PM이 공통의 언어로 협업하고 문제를 해결할 수 있도록 돕는 하나의 '제품'으로 설계되었습니다. 교육 과정을 제품 개발 프로세스와 동일하게 '구조화'와 '반복 실험'의 관점에서 접근했으며, 수강생의 피드백을 데이터로 치환하여 지속적으로 기능을 개선하듯 커리큘럼을 고도화했습니다. 결과적으로 이 과정은 전략이 실제 실행으로 이어지도록 만드는 조직 차원의 구조적 프레임워크를 구축하는 성과를 거두었습니다. **POPM 교육의 탄생 배경과 목적** * PO와 PM의 역할이 모호하고 비가시적인 업무가 많아 발생하는 의사결정의 혼선을 줄이기 위해 시작되었습니다. * 문제 정의, 지표 해석, 실험 설계 등 실무에서 반복되는 질문들에 대해 조직이 공유할 수 있는 공통 언어를 수립하는 것이 핵심 목표입니다. * PO의 전략적 고민과 PM의 실행이 단절되지 않고 하나의 목표로 이어질 수 있는 구조적 기틀을 마련하고자 했습니다. **제품 개발 프로세스를 닮은 교육 설계** * 파일럿 과정(1기)의 8개 세션을 시작으로, 매 기수마다 '사용자 피드백'을 반영하여 구조를 최적화했습니다. * 3기부터는 '전략 → 지표 → 실험 → 디자인 → 실행'의 5개 핵심 세션으로 고정하여 흐름을 단순화하고 몰입도를 높였습니다. * 교육 설계자는 PM의 관점에서 교육을 하나의 제품으로, 각 세션을 기능으로, 각 기수를 소프트웨어 버전으로 정의하여 반복 개선을 수행했습니다. **데이터 기반의 기회 점수 도출과 리디자인** * 수강생 대상의 사전/사후 설문을 통해 각 세션의 '중요도'와 '만족도' 매트릭스를 분석했습니다. * 중요도는 높으나 만족도가 낮은 영역(예: 데이터/지표 세션)을 '기회 영역'으로 정의하고, 이를 제품 기능의 우선순위처럼 취급하여 최우선적으로 개선했습니다. * 단순한 내용 수정을 넘어 슬라이드 재구성, 실습 난이도 조정, 워크시트 포맷 변경 등 구조적인 해결책을 적용하여 기회 점수를 관리했습니다. **설계자가 얻은 구조적 인사이트** * 교육은 사람의 변화보다 '구조의 누적'에 집중해야 하며, 시스템이 바뀌지 않으면 동일한 시행착오가 반복된다는 점을 확인했습니다. * 지식의 전달보다 '질문의 리듬'을 설계하는 것이 중요하며, 슬라이드 하나에도 질문과 예시, 흐름을 유기적으로 배치하여 수강생의 사고를 유도했습니다. * 실습의 목적은 정답 작성이 아니라 '생각의 구조화'에 있으며, 실습 과정이 실제 팀의 업무 루틴으로 자연스럽게 이어지도록 설계했습니다. 조직 내 교육이나 프로세스를 설계할 때 이를 하나의 고정된 커리큘럼이 아닌, 지속적으로 개선 가능한 '제품'으로 바라보는 시각이 필요합니다. 수강생을 사용자로 정의하고 그들의 불편함을 데이터로 측정하여 구조를 개선해 나간다면, 교육은 단순한 학습을 넘어 조직의 실행력을 높이는 강력한 도구가 될 수 있습니다.