"이거 언제쯤 되는 건데?"
"또 기획 바뀌었어요?"
"이건 제 일이 아닌데요?"
전면 리브랜딩을 앞두고 매일 듣던 말들이었습니다. 종합 중고거래에서 중고 패션 전문 서비스로 전환하는 과정에서, 우리는 냉정한 결론에 도달했습니다.
"지금의 일하는 방식으로는 이 변화를 감당할 수 없다."
3개월 후, 우리 팀은 완전히 달라져 있었습니다. 어떻게 가능했는지, 그 생생한 이야기를 공유합니다.
우리가 마주한 현실
전사 미팅(All-Hands)에서 세 가지 문제가 명확히 드러났어요.
1. "우리, 같은 목표를 보고 있는 거 맞아?"
각자 열심히는 했지만 단절되어 있었어요. 기획자는 기획, 디자이너는 디자인, 개발자는 개발...
내가 하는 일이 회사 목표와 어떻게 연결되는지 모른 채 일했습니다.
2. "이거 언제쯤 되는 건데?"
Before: "경험상 이 정도면 되겠지?" → 막상 해보니 2배 걸림
Why? 작업 속도를 측정할 기준도, 공수를 산정할 근거도 없었거든요.
3. "또 바뀌었어요?"
워터폴 방식으로 일하던 우리에게, 리브랜딩은 큰 도전이었어요.
요구사항이 수시로 바뀔 게 뻔한 상황에서, 한 방향으로만 흐르는 워터폴 방식으로는 감당하기 어려웠죠. 새로운 요구사항을 반영하려면 기존 단계를 다시 수정해야 했고, 이는 전체를 흔들 수밖에 없었으니까요.
그래서 우리가 선택한 답: OKR과 애자일
OKR: "아, 우리가 이걸 하고 있었구나"
간단히 말하면
- Objective (목표): 궁극적으로 달성하고 싶은 것
- Key Results (핵심 결과): 목표 달성을 증명할 숫자
- Initiative (이니셔티브): 당장 실행할 구체적 행동
첫 OKR 회의, 뭔가 달랐어요
"이번 분기 우리 스쿼드의 OKR입니다."
- 목표(O): 신규 셀러 확보를 통해 서비스 성장
- 핵심 결과(KR): 신규 셀러 전월 대비 30% 증가
- 이니셔티브(I): 셀러 온보딩 프로세스 간소화, 상품 등록 UI 개선
명확한 목표가 정해지자 신기한 일이 벌어졌어요.
개발자: "이탈률을 줄이려면 UI를 이렇게 바꾸면 어때요?"
디자이너: "로딩 속도가 느려서 가입을 안 하는 것 같아요."
기획자: "그럼 온보딩 플로우를 3단계로 줄여볼까요?"
직군의 경계가 허물어지는 순간이었죠.
하지만 첫 스프린트는 완벽하지 않았어요. "이거 3일이면 되겠는데요?"라고 자신 있게 말했다가 일주일이 걸렸습니다. 공수 산정을 계속 틀리면서 배웠어요.
숫자가 주는 명확함
"신규 셀러 전월 대비 30% 증가" 같은 구체적인 수치가 있으니, 매주 우리가 잘하고 있는지 확인할 수 있었어요.
가장 큰 변화:
"이건 누가 해요?" → 각자 자기 OKR이 있으니 자연스럽게 책임감 생김
"이건 제 일 아닌데요?" → "그럼 제가 이렇게 처리해둘까요?"로 변화
실제 사례: OKR이 작동하는 방식
당시의 논리 구조를 기반으로 한 가상의 예시입니다.
정렬(Alignment) 과정
1단계 - 전사 목표:
"중고 패션 전문 플랫폼으로의 성공적인 시장 안착"
2단계 - 스쿼드가 자율적으로 정의:
"그렇다면 우리는 '압도적인 패션 의류 물량 확보'를 목표로 삼겠습니다"
3단계 - 측정 가능한 지표 설정:
- 전문 셀러 500팀 영입
- 패션 상품 등록 비중 70% 달성
4단계 - 구체적 실행 과제:
- 사업자(전문 셀러) 전용 계정 및 인증 시스템 구축
→ 전문 셀러가 들어올 수 있는 '문'을 먼저 만들어야 하니까 - 패션 특화 상품 등록 프로세스(UI/UX) 개편
→ 브랜드, 사이즈 등을 쉽게 입력할 수 있어야 패션 상품 비중이 늘어나니까
핵심은 이거였어요:
위에서 시키는 대로 하는 게 아니라, "회사의 성공을 위해 우리 팀이 할 수 있는 최선이 뭘까?"를 스스로 정의하는 과정.
애자일: 숨 쉴 공간이 생기다
2주 스프린트, 왜 좋았나?
처음엔 "2주마다 뭘 만들어? 너무 짧은 거 아니야?" 했는데:
실제로 해보니:
- 2주 동안 집중해서 일하고
- 스프린트 끝나면 회고하며 개선점 찾고
- 긴 호흡으로 방향 잃는 대신, 자주 점검하며 빠르게 수정
매일 아침 15분, 스크럼 미팅
처음엔 부담스러웠던 매일 아침 미팅. 그런데:
"아, 나도 그거 고민했는데!"
"그거 내가 도와줄 수 있어요."
"그 부분은 이렇게 하면 어때요?"
혼자 끙끙대던 문제들이 15분 만에 풀렸어요.
실패 사례: 처음엔 스크럼이 30분, 1시간으로 늘어났어요. 기술 논의로 빠지면서요. "이 이야기는 별도 미팅으로 잡을까요?"라고 브레이크 거는 법을 배웠습니다.
회고는 솔직 타임
Keep-Problem-Try 방식으로 정리했어요:
Keep (계속할 것):
"코드 리뷰가 꼼꼼해서 버그가 줄었어요"
Problem (문제였던 것):
"공수 산정을 잘못해서 야근했네요"
Try (다음에 시도할 것):
"다음엔 공수를 좀 더 여유롭게 잡아야겠어요"
완벽하진 않았지만, 계속 나아지고 있다는 느낌이 좋았어요.
JIRA로 투명하게 관리
이 모든 과정을 JIRA 칸반보드로 관리했어요:
✅ "지금 뭐 하고 있어요?" 질문 사라짐
✅ 작업을 쪼개니 예측 가능해짐 (전체 10개 중 7개 완료, 내일 배포 가능)
✅ 우선순위 명확 → 불필요한 회의 감소
스쿼드로 일하기: 부서를 넘어 하나가 되다
사업팀, 개발팀, 마케팅팀으로 나뉘어 있던 구조를 서비스 목적에 맞는 스쿼드 조직으로 재편했어요.
처음엔 낯설었지만
기획자, 디자이너, 개발자가 한 목표를 향해 매일 얼굴 맞대고 일하니:
"이거 개발 가능해요?"
"네, 근데 이렇게 하면 더 좋을 것 같은데요?"
"오, 그거 좋네요! 디자인에 반영할게요."
부서 간 벽이 허물어지고 의사결정이 정말 빨라졌어요.
문제도 있었어요: 각 스쿼드가 독립적으로 달리다 보니, 서로 뭘 하는지 잘 몰랐어요. 코드 충돌이나 중복 작업도 발생했죠. 코드 리뷰와 기획 리뷰에 스쿼드 간 교차 참여를 늘리면서 개선했습니다.
3개월, 그리고 매일의 사이클
분기(3개월) 단위로 움직이기
왜 3개월이었을까?
리브랜딩처럼 불확실성이 큰 상황에서는 짧은 주기가 강점이었어요:
- 시장 상황 바뀌면? → 다음 분기 OKR에 반영
- 더 중요한 기회 발견? → 분기 중간에도 목표 조정 가능
1년 계획을 세웠다가 6개월 뒤 "이거 이미 의미 없는데..."하는 것보다, 3개월마다 방향을 점검하고 조정하는 게 훨씬 현실적이었어요.
2주 스프린트의 실제 흐름
OKR의 이니셔티브(실행 과제)를 2주 단위로 쪼개서 실행했어요.
스프린트 플래닝 핵심 질문:
"이번 2주 동안 어떤 기능을 배포해야 KR 숫자를 움직일 수 있을까?"
실제 작업 흐름:
- 기획자가 세부 계획 정리 → 팀 전체가 피드백하며 구체화
- 디자이너 공수 산정하고 디자인 착수
- 개발자는 이전 스프린트 백로그 처리 or 리팩토링
- 디자인 나오면 개발 착수 → QA → 배포
여기서 중요했던 것:
기획자가 요구사항을 가져오면 무조건 만드는 게 아니라,
"개발 공수가 너무 큰데, 핵심 기능만 먼저 배포해서 반응을 보는 건 어때요?"
개발자와 디자이너가 함께 범위를 조정했어요. 기획→디자인→개발 순서로 일을 넘기는 게 아니라, 하나의 목표를 위해 3직군이 동시에 붙어서 동작하는 서비스를 만드는 데 집중했죠.
Before / After: 구체적으로 뭐가 달라졌나?
1. 병목이 생기면
Before:
"API가 아직 안 나와서 작업 못 해요" → 그냥 기다림
After:
"그럼 제가 API 명세서 먼저 확정해 드릴게요. Mock 데이터로 먼저 작업하시겠어요?"
"이 애니메이션 구현이 오래 걸려요" → "그럼 기본 트랜지션으로 가고 다음 스프린트로 넘길까요?"
변화의 핵심: 내 일만 끝내는 게 아니라, 동료가 막힌 부분을 내 직무에서 어떻게 뚫어줄지를 고민하게 됨
2. 책임 소재가 애매할 때
Before:
"이건 기획서에 없는데요?" / "디자인 가이드 주셔야 하는데요?" → 서로 기다림
After:
"그럼 그 부분은 안드로이드에서 예외 처리로 막아둘까요?"
"개발 일정 맞추기 힘들면 디자인을 이렇게 단순화할까요?"
변화의 핵심: 서로 미루는 게 아니라, '되는 방법'을 각자의 영역에서 먼저 제시
3. 주니어의 목소리
Before:
시키는 일만 함. 의견 내기 부담스러움
After:
OKR 회의에서 주니어 개발자가 제안한 아이디어가 채택되고, 결국 핵심 기능이 됨
변화의 핵심: 시니어든 주니어든 좋은 아이디어는 환영받는 문화
실패하고 배운 것들
기술 부채가 쌓였어요
"일단 빨리 만들어야 해!" 하다 보니, 테스트 코드를 못 쓰거나 리팩토링을 미루는 경우가 있었어요.
해결: 스프린트 계획할 때 리팩토링 시간을 미리 확보하는 걸로 개선
기획자, 디자이너와 말이 안 통했어요
"이건 레이턴시가 너무 커서 최적화가 필요해요" → 기획자 "...?"
배운 것: 기술 용어를 쉽게 풀어 설명하는 연습을 하면서, 오히려 제가 맡은 업무를 더 깊이 이해하게 됨. 문서화 습관도 이때 생겼어요.
오버엔지니어링의 유혹
"이거 3일이면 되겠는데요?" → 완벽하게 만들려다 일주일 걸림
배운 것: 작업을 더 작게 쪼개고, "정말 이 기능이 지금 필요한가?"를 자주 물어보기
마무리: 가장 큰 변화는 사람이었어요
방법론이나 프로세스보다, 사람들이 변한 게 제일 컸어요.
- 시키는 일만 하던 사람들이 → 능동적으로 제안하기 시작
- 부서 간 벽이 있던 사람들이 → 자연스럽게 협업
- 혼자 끙끙대던 사람들이 → 서로 도우며 성장
리브랜딩을 통해 우리가 얻은 건 단순히 일하는 방법이 아니었어요. 함께 성장하는 법을 배운 거였죠.
여러분 팀은 어떤가요?
"우리 팀도 바뀌어야 하는데...", "어떻게 시작해야 하지?" 고민하고 계신가요?
완벽한 답은 없어요. 저희도 처음엔 헤맸고, 시행착오도 많았어요.
그래도 한 가지는 확실해요.
변화를 시작하는 데 완벽한 준비는 필요 없어요. 작게라도 시작하고, 함께 배워가면 돼요.
여러분 팀은 어떤 방식으로 일하시나요?
댓글로 공유해주시면, 제 경험으로 답변 드릴게요!
셀러 스쿼드 여러분, 함께했던 그 시간 정말 즐거웠어요!
