고민의 흔적

이 블로그 고민의 흔적 카테고리 글

전체글 보기
#애자일#협업#팀장#조직#성장

애자일, 팀을 키우는 데 가장 도움이 됐던 습관들

팀원이던 시절부터 파트장이 되며, 짧은 주기와 기록으로 팀이 스스로 자라게 만든 애자일 이야기다.

팀을 키우고 싶은 마음은 예전부터 있었다.
다만 처음엔 그 마음이 ‘내가 더 잘하자’에 가까웠고, 나중에야 ‘우리가 같이 자라게 하자’로 바뀌었다.

한때는 팀원이었다. 레거시 전산을 분석하고, 결제 연동을 붙이고, 밤새 배치를 돌리던 사람.
지금은 파트장이다. 같은 일을 하되, 결정·기록·주기를 팀 전체가 공유하도록 만드는 쪽에 더 많은 시간을 쓴다.

그 사이에 애자일을 도입한다는 말을 마주했을 때, 솔직히 부담스러웠다.
스크럼 마스터, 스프린트 세리모니, 스토리 포인트… 이름만 들어도 ‘우리 규모에 과한 것 아닌가’ 싶었다.

그런데 돌이켜보면, 팀이 실제로 빨라진 순간들은 애자일이라는 이름 아래 있었던 것이 아니라, 그 안의 몇 가지 습관에 가까웠다.
그리고 그 습관들은 팀원일 때 혼자 실천하다가, 팀장이 되면서 팀의 기본값으로 옮겨 갔다.

팀원이었을 때 — 혼자서 배운 것 (이유)

  • 레거시 전산·결제·신규 차세대가 동시에 돌아가면서, ‘이번 달 끝나면 알겠지’가 통하지 않았다.
  • 팀장님이 결정만 내리고 끝나면, 현장의 학습이 쌓이지 않았다. 같은 실수가 다음 프로젝트로 이어졌다.
  • 나는 그때 기록을 남기는 사람이 되기로 했다. PR에 한 줄, 분석 메모, 배포 체크리스트. 팀 전체가 아니라, 일단 내가 반복하지 않게.
  • 성장 욕구는 있었지만, 한 번에 크게 바꾸면 운영이 깨질 수 있다는 것도 알고 있었다. 짧은 주기로 되돌릴 수 있는 전진이 필요했다.

팀원 시절의 나에게 애자일은 방법론이 아니라, 이번 주에 끝낼 수 있는 것을 스스로 자르는 연습이었다.

팀장이 되고 — 팀이 함께 쓰게 만든 것 (당시 결론)

교과서 전체를 들이지 않았다. 팀장이 되어 팀에 맞춰 정한 것은 이것이었다.

  1. 짧은 주기로 목표를 자른다 — 분기 계획이 아니라, 1~2주 안에 ‘끝났다고 말할 수 있는 것’을 함께 정한다.
  2. 매주 같은 시간에 맞춘다 — 무엇을 했고, 무엇이 막혔고, 다음에 무엇을 할지. 회의가 길어지면 실패다.
  3. 기록이 회의의 결과물이다 — 말로만 합의한 건 없는 것과 같다. Notion·Jira·릴리즈노트로 남긴다.
  4. 운영 중인 것은 작게 배포한다 — blue & green, 단계적 SSO, ES6 한 화면씩… 애자일의 “인크리먼트”를 인프라·레거시 언어로 번역한다.

팀원일 때 혼자 하던 것과 달라진 점은 하나다.
혼자의 습관이 팀의 루틴이 됐다는 것. ‘태우가 그렇게 하니까’가 아니라, ‘우리 팀은 이렇게 한다’가 되는 순간이 왔을 때, 팀이 키워지기 시작했다.

비슷한 경험 — 개발자센터·협업 도구

개발자센터를 만들 때도 같은 여정이었다. 팀원 때는 ‘나만 아는 지식’이 많았고, 팀장이 되어 보니 같은 질문이 팀원마다 반복되고 있었다. 문서를 한꺼번에 완성하려다 지쳤고, 반복 질문이 오는 것부터 올리는 짧은 주기로 바꾸니 팀 전체가 빨라졌다.

Jira·Confluence·Slack을 들였을 때도 마찬가지였다. 도구 이름이 중요한 게 아니라, 이번 주에 팀이 같은 그림을 보고 있나가 중요했다. 이후 Discord·Notion으로 옮겨도, 습관은 남았다.

  • 이유: 도구는 바뀌어도, 팀 성장에 필요한 건 정렬(alignment)피드백 루프였다.
  • 당시 결론: 애자일은 회의 더하기가 아니라, 의사결정과 기록의 주기를 줄이는 일로 정의했다.
  • 개발자센터·배포 자동화·코드 리뷰 문화가 같은 줄기에서 자란 이유도 여기에 있다.

팀이 자랐다고 느낀 지점

“폭발적”이라는 말은 숫자 하나로 설명되지 않았다. 팀장으로서 체감한 건 이쪽에 가까웠다.

  • 신규 인원이 들어와도 어디서 무엇을 봐야 하는지가 빨라졌다. 온보딩이 나한테만 묶이지 않았다.
  • 장애·배포·연계 이슈가 같은 패턴으로 설명되기 시작했다. 팀원이 스스로 원인을 좁힐 수 있었다.
  • 내가 혼자 끌던 결정이, 기록과 주기 회의로 팀의 기준이 됐다. 팀장 혼자 아는 그림이 줄었다.
  • 레거시·신규·운영이 한 팀 안에서 같은 언어로 논의됐다.
  • 팀원이 “이건 이렇게 하면 될 것 같다”고 먼저 제안하는 순간이 늘었다.

한 번에 완벽한 구조를 만든 게 아니라, 작게 돌리면서 팀의 학습이 누적된 결과에 가깝다.

아직 부족한 것 (개선점)

  • 애자일을 ‘형식’으로만 하는 주간이 여전히 있다. 안건 없이 상태 보고만 하는 회의는 시간 낭비다.
  • 스프린트 목표와 운영 SLA·결제 안정성이 충돌할 때, 우선순위를 말로만 정하고 기록하지 못하는 경우가 있다.
  • 기록은 늘었지만, 회고에서 나온 개선이 다음 주기에 반영됐는지 추적하는 장치가 약하다.
  • 팀장이 되면서 모든 결정이 나에게 모이는 병목이 생기는 날이 있다. 팀이 스스로 판단하는 영역을 더 넓혀야 한다.

앞으로 나가야 할 방향

  1. 주간 회의 안건을 이번 주기에 닫을 항목으로만 제한하고, 안 되면 다음 주기로 넘기는 규칙을 고정한다.
  2. 운영·결제·배치 영역은 결제/정산 체크리스트처럼 비기능 요구를 스프린트 밖이 아니라 안으로 끌어온다.
  3. 회고 결과를 개발자센터·릴리즈노트와 연결해, 왜 이렇게 바꿨는지가 다음 팀원에게도 보이게 한다.
  4. 애자일을 도입 유지 비용이 아니라, 되돌릴 수 있는 실험 주기로 계속 정의한다.
  5. 팀장의 역할을 ‘결정자’에서 기준을 세우고 팀이 판단하게 하는 사람으로 더 옮긴다.

애자일은 우리 팀을 한 번에 바꾼 마법이 아니었다.
팀원일 때 혼자 실천하던 짧은 주기·기록·되돌리기가, 팀장이 되어 팀 전체의 기본값이 된 순간부터, 팀이 스스로 자라는 속도가 달라졌다.

그 여정은 아직 진행 중이다. 팀을 키운다는 건, 결국 내가 덜 필요해지는 구조를 만드는 일에 가깝다고 느낀다.

#애자일#협업#팀장#조직#성장