STEP 07. 애자일 스프린트 — 스프린트 없이 애자일한 이야기

 

이전 글에서 코드만 올리는 게 퍼블리싱이 아니라,

서비스로 나가기 위한 조건을 갖추는 것까지가 퍼블리싱이라고 했다.

 

배포가 끝나면 서비스가 시작이 되는데 서비스가 시작되면 고칠 게 쏟아진다.

정석적인 애자일은 이렇다. 1주 단위로 스프린트를 돌린다.

백로그에 할 일을 쌓고, 이번 주에 할 것을 정하고, 일주일 뒤에 회고하고,

다음 스프린트를 계획한다.

팀이 있으면 스탠드업 미팅을 하고, 진행 상황을 공유하고, 블로커*를 해소한다.

블로커(blocker)는 작업을 진행 못 하게 막는 장애물이다

예를 들면 "카카오 로그인을 연동해야 하는데 개발자 콘솔 권한이 없어서 못 하고 있다" 같은

내가 아무리 코드를 짜도 권한이 없으면 진행이 안 되는걸 블로커라 함

찐망고 사주는 혼자 만든 서비스다. 스프린트를 돌리지 않았다. 시간 나는 대로 고쳤다.

 

런칭 후 고친 것들을 정리하면 이렇다.

엔진을 고도화했다. 억부용신을 조후용신으로 교차검증하는 로직을 만들었고,

대운과 용신의 관계를 분석하는 레이어를 추가했다

같은 일주인데 시주가 다른 사람 네 명의 실제 인생이 전부 다르다는 걸 확인하고,

천간합과 지지합 로직이 필요하다는 결론을 내렸다.

이걸 스프레드시트에 테스트 케이스로 기록하면서 엔진을 검증했다.

UX를 개선했다. 결과 페이지를 매거진 스타일로 리디자인했고, 로딩바 속도를 조정했고,

현재 상황 입력 UI를 추가했다.

카카오 로그인을 연동하고 마이페이지를 만들었다. 계정 탈퇴 기능도 넣었다.

버그를 잡았다. 섹션 번호가 01이 아니라 11부터 시작하는 버그가 있었는데,

모듈 레벨 변수가 렌더링마다 누적되는 게 원인이었다.

카카오 공유 도메인 설정도 수정했다. 버튼 넓이가 깨지는 문제도 잡았다.

이걸 1주 단위로 나눠서 한 게 아니다.

하루에 엔진 고도화랑 디자인 리뉴얼을 동시에 한 적도 있다.

시간이 나면 할 수 있는 만큼 했다.

 

형식적인 스프린트는 안 돌렸지만, 실제로 한 걸 보면 애자일의 핵심은 다 들어가 있다.

백로그가 있었다. 머릿속에.

피드백에서 나온 것들, 직접 써보면서 불편한 것들, 엔진에서 틀리는 케이스들.

이게 할 일 목록이었다.

우선순위를 정했다. 엔진 정확도가 떨어지면 서비스 자체가 흔들리니까 엔진부터 고쳤다.

그 다음이 UX, 그 다음이 부가 기능이었다.

배포하고 확인하고 다시 고쳤다. Vercel이 push하면 바로 배포되니까,

수정하고 결과 보고 다시 수정하는 사이클이 빨랐다.

회고도 했다. 혼자니까 회의는 없었지만, 블로그에 제작노트를 쓰면서 "왜 이렇게 했는지"를 정리했다.

형식이 애자일인 게 아니라, 만들고 확인하고 고치는 사이클을 반복하는 게 애자일이다.

1주 스프린트는 팀에서 그 사이클을 구조화하는 방법일 뿐이다.

 

학생 프로젝트도 GitHub Pages에 올리는 순간 달라지는 것들이 있다.

로컬에서 돌릴 때는 "일단 되니까"로 넘기던 것들이, URL이 생기면 갑자기 신경 쓰인다.

폰트가 안 맞는 게 보이고, 모바일에서 깨지는 게 보이고, 로딩이 느린 게 보인다.

이게 실배포의 힘이다. "누군가 진짜 볼 수 있다"는 상황이 되면 기준이 올라간다.

수업 과제와 포트폴리오의 차이가 여기서 생긴다.

찐망고 사주도 마찬가지였다. 런칭 전에는 "일단 돌아가면 되지" 했던 것들이,

실제 사용자가 쓰기 시작하면 전부 고쳐야 할 것으로 바뀌었다.

매거진 리디자인도, 현재 상황 입력도 전부 런칭 후에 한 작업이다.

 

수업에서도 정식 스프린트를 돌리지 않았다.

학생들이 작업물을 계속 올리고, 내가 지적하고, 학생이 수정한다. 이걸 반복한다.

이게 사실 애자일의 가장 원초적인 형태다. 만들고, 피드백 받고, 고치고, 다시 올린다.

스프린트 보드가 있고 스탠드업 미팅을 하는 게 중요한 게 아니라, 이 사이클이 빠르게 도는 게 중요하다.

다만 실무에 가면 혼자가 아니니까 형식이 필요해진다.

누가 뭘 하고 있는지, 이번 주에 뭐가 끝나야 하는지, 어디서 막혀 있는지를 공유해야 하니까.

그래서 스프린트 보드가 생기고, 회고가 생기고, 데일리 스크럼이 생기는 거다.

수업에서는 이 개념을 설명하고, 실제로는 "올리고 피드백 받고 고치기"를 빠르게 반복시킨다.

형식보다 사이클을 체감하게 하는 게 먼저다.

 

찐망고 사주는 시간 나는 대로 고쳤다.

하지만 만들고 확인하고 고치는 사이클은 계속 돌았다. 이게 애자일의 본질이다.

형식은 팀 규모에 맞게 붙이면 되고, 혼자일 때는 빠르게 배포하고 빠르게 고치는 게 전부다.

수업에서도 마찬가지다. 스프린트 보드를 가르치는 게 아니라, 올리고 피드백 받고 고치는 사이클을 체감하게 한다.

실배포를 하면 기준이 올라가고, 기준이 올라가면 결과물이 달라진다.

 

서비스를 만들고 운영하고 개선한 경험은 그 자체로 포트폴리오다.

마지막 글에서는 이 과정을 어떻게 정리하고, 어떻게 보여주고, 어떻게 커리어로 연결하는지를 다룰 예정

 

 

찐망고 사주풀이 | 달콤한 운명 리포트

 

이 시리즈는 실제 운영 중인 서비스 찐망고 사주를 사례로 AI 서비스 기획부터 배포까지를 다루는 강의 노트입니다.

📌출강 및 커리큘럼 문의: spacejh72@gmail.com