분기마다 일주일을 떼어내 로드맵 작업을 멈추고, 제품의 자잘한 버그와 개발자 생산성을 떨어뜨리는 문제들을 집중적으로 해결한 경험과 그 효과, 그리고 잘 운영하는 방법을 공유한다.
_ Hacker News, lobste.rs 그리고 r/programming 에서도 논의되었습니다._
금요일 오후 4시. 방금 이번 주 들어 12번째 버그를 닫았다. 머리는 완전히 지끈거리고, 버그 리더보드를 바라보면서 월요일이 되면 다시 평소의 일을 해야 한다는 사실에 진심으로 슬퍼하고 있다. 이상한 일이다. 왜냐하면 나는 평소의 일도 정말 좋아하기 때문이다. 하지만 fixit 주간은 내 마음속에서 특별한 자리를 차지하고 있다.
분기마다 한 번쯤, 내가 속한 조직(소프트웨어 엔지니어 약 45명)은 일주일 동안 모든 정규 작업을 멈춘다. 즉, 로드맵 작업도, 설계 작업도, 회의나 스탠드업도 없다.
그 대신, 우리와 사용자들을 계속 성가시게 만들던 자잘한 것들을 고친다.
룰은 간단하다. 1) 어떤 버그도 이틀을 넘기지 말 것. 2) 모든 작업은 작은 사용자 버그/기능이거나 개발자 생산성에 초점을 둘 것.
우리는 버그에 "포인트 시스템"도 두고, 사람들이 쌓은 포인트를 보여주는 리더보드가 있다. 그리고 여러 업적(첫 버그 픽스, 최다 포인트, 가장 짜증나는 버그 등)에 대해 티셔츠를 주겠다는 약속도 있다. 구조는 단순하지만 놀라울 만큼 잘 작동한다.
이번 fixit에서 나온 통계는 다음과 같다.
Q4'25 Fixit의 버그 번다운 차트
하이라이트 몇 가지를 소개한다(아쉽게도 우리 조직 사람들 상당수는 내부 시스템을 하고 있어서 그들의 작업은 공유하지 못한다!).
단순한 변경이지만 팀이 정말 좋아했다!
나는 내가 일하는 어떤 제품이든 깊이 아낀다. 그것은 "무엇을 만들어야 할까?", "이걸 어떻게 빠르게 만들지?" 같은 큰 질문을 던지는 것을 의미한다. 하지만 작은 질문도 던진다는 뜻이다. "이 에러 메시지는 실제로 도움이 되나?", "내가 이걸 쓰면 짜증 나지 않을까?"
좋은 제품의 상징은 디테일에 대한 집착이다. 누군가가 모든 것을 꼼꼼히 생각했고, 각 요소들이 맞물려 일관된 전체를 이룬다는 느낌. 반대로, 마감이 거친 제품은 대체제가 없다면 어쩔 수 없이 쓰겠지만, 늘 약간의 짜증과 "다른 걸 쓸 수만 있다면"이라는 생각을 품게 만든다.
Fixit은 그런 디테일들, 즉 좋은 제품과 훌륭한 제품을 가르는 요소들을 다루기에 딱 좋은 기회다. 일반 사용자라면 의식적으로 인지하지 못할 수도 있지만, 틀렸을 때는 분명하게 느껴지는 바로 그 자잘한 것들 말이다.
가끔은, 커리어 초기에 가졌던 "그냥 고치기만 하면 됐던" 그 감정이 그립다. 고장 난 걸 보면 고치고, 그날 바로 배포하는 느낌.
큰 회사에서 직급이 올라갈수록 그런 일을 할 일이 줄어든다. 대부분의 시간은 다음에 뭘 만들지 고민하고, 분기를 내다보며 계획하고, 트레이드오프를 탐색하고, 정렬(alignment)을 맞추는 데 쓰인다.
Fixit은 그 초기 커리어의 느낌을 되찾게 해준다. 버그를 보고, 고치고, 배포하고, 이슈를 닫고, 다음으로 넘어간다. "우리가 뭘 해야 하나?"가 아니라 "이걸 더 좋게 만들 수 있을까?"가 질문이 되는 일에는 뭔가 깊은 만족감이 있다. 그리고 일주일 동안 그 질문에 여러 번 답해 볼 수 있다.
Fixit 채팅방에서 실시간 업데이트를 공유하는 사람들
두 개의 타임존에 걸쳐 40명이 함께 버그를 고치고 있으면 전혀 다른 차원의 일이 된다.
오피스의 분위기 자체가 달라진다. 평소에는 각자 다른 프로젝트를 향해 고개를 숙이고 있지만, fixit 기간에는 팀 정신이 강하게 드러난다. 사람들은 버그 픽스를 채팅방에 공유하고, 전후(before/after) 스크린샷을 올리고, 새로운 기능을 데모하거나 지금 씨름하는 악질 버그에 대해 불평하려고 모니터 주변에 모여든다.
금요일의 일일 업데이트
리더보드는 이런 에너지를 증폭시킨다. 사람들은 빠른 성과(quick win)와, 나중에 이야기거리가 될 만한 묵직한 버그 사이에서 균형을 잡으려 하면서, 친근한 경쟁심을 느낀다.
매일 아침에는 전날이 어땠는지를 짧게 정리한 업데이트도 올라온다.
이 모든 것이 진짜 모멘텀을 만들어내고, 사람들은 이 노력에 자기 발로 끌려 들어오는 느낌을 받는다.
나는 수년간 6번의 fixit에 참여했고, 무엇이 fixit의 성공을 좌우하는지에 대해 많은 걸 배웠다. 의외로 중요했던 것들을 몇 가지 공유한다.
Fixit이 잘 돌아가게 만드는 요소 대부분은 사실 그 주가 시작되기 전에 이미 결정된다.
우리는 연중 내내, 누구든 버그를 발견하면 그게 좋은 fixit 후보라고 생각될 때 태그하도록 권장한다. 그리고 fixit 전주에 각 서브팀이 이 버그들을 훑으면서 사이징을 한다.
그리고 각각에 1, 2, 4 포인트를 할당한다.
또 꼭 고치고 싶은 고우선순위 버그의 단축 리스트(shortlist)를 만든다. 사람들은 여기서 시작하고, 그게 끝나면 전체 리스트로 넘어간다. 이 사전 작업이 매우 중요하다. 첫날을 "고칠 버그를 찾느라" 허비하지 않게 해주기 때문이다.
초기 fixit 중 하나에서, 누군가가 겉보기엔 단순해 보이는 버그를 집어 들었다. 몇 시간, 길어도 반나절이면 끝날 것 같았다. 하지만 그건 토끼굴(rabbit hole)이었다. 다른 시스템에 대한 의존성, 예상치 못한 엣지 케이스, 수년간 손대지 않은 코드…
그 사람은 fixit 주 전체를 그 버그에 썼다. 그리고 fixit이 끝난 다음 주 내내 그걸 마무리하려고 매달렸다. 버그 픽스로 시작했던 게 작은 프로젝트가 되어버렸다. 일이 가치 없었던 건 아니다! 하지만 fixit의 핵심을 완전히 놓친 꼴이었다. 주 내내 닫힌 버그는 하나뿐. 모멘텀도 없고, 픽스를 배포하면서 느끼는 도파민 히트도 없다. 그냥 길고 지루한 고난의 행군이었을 뿐이다.
그래서 지금은 이틀 제한을 강하게 두고 있다. 일이 크게 불어나기 시작하면, 미련을 버려라. 제대로 된 버그를 남기고, 백로그로 옮기고, 다른 걸 집어 들어라. 이 한계는 그 작업이 쓸모없어서가 아니라, fixit 특유의 느낌을 유지하기 위해 존재한다.
우리가 항상 40명이서 fixit을 했던 것은 아니다. 초기에는 조직 전체가 아니라, 내 서브팀 7명만 참여했다. 그때도 나쁘지 않았다. 버그도 고쳐지고, 제품을 더 좋게 만들었다는 뿌듯함도 있었다. 하지만 어딘가 좀 공허했다. 조직의 더 큰 그림 속에서는 아무도 주목하지도, 신경 쓰지도 않는 느낌이었다.
약 40명 규모가 되니, 이게 임계 질량에 도달한 것처럼 확실히 다른 느낌이 났다. 마법의 숫자는 아마 7과 40 사이 어디쯤일 것이다. 팀에 따라 다를 수도 있다. 하지만 숫자가 무엇이든, 집단적인 에너지가 중요하다. 5명으로 이걸 시도한다면 여전히 할 가치는 있겠지만, 이 글에서 묘사한 느낌과는 사뭇 다를 가능성이 크다.
포인트와 리더보드는 단순한 장난이 아니다. 하지만 잘 다루어야 한다.
우리에게 효과적이었던 것들:
실제로는 "게임"하는 사례가 거의 없었다. 사회적 규범이 사람들을 충분히 솔직하게 유지시켜 주고, 인원 40명 정도면 여전히 서로에 대한 "공동의 목적에 대한 충성심" 같은 게 작동한다.
Fixit의 큰 도전 과제는 컨텍스트 스위칭이다. 계속해서 작업 대상을 바꾼다는 건, 계속해서 코드베이스의 다른 부분을 파악하고, 다른 문제를 생각해야 한다는 뜻이다.
AI 도구들은 이 문제를 크게 완화했다. AI가 작성하는 코드 자체보다, 관련된 파일을 빠르게 찾아보고 무엇을 바꿔야 할지 요약해 주는 능력이 더 중요하다. 그게 맞을 수도, 틀릴 수도 있지만, 그런 출발점이 주는 인지 부하 감소는 상당하다. 그리고 가끔(아주 드물게) AI가 한 방에 픽스를 성공시키기도 한다.
이 문서 변경은 위에서 말한 것의 완벽한 예다. 신규 컨트리뷰터들을 자주 헷갈리게 하는 문서를 고치는 작업이었는데, AI가 한 번에 맞는 수정을 제안해 줬다.
반면에, 내가 했던 record 페이지 변경에서는, AI가 내게 코드가 대략 어떻게 생겨야 할지 프로토타입을 제시해 주는 용도로 더 유용했다. 나쁜 UX를 고치고, AI가 "과하게 코드를 생성"하려는 성향을 바로잡느라 상당한 노력이 필요했다. 그럼에도, 출발선까지 가는 속도를 확실히 높여줬다.
Fixit이 정말로 좋은 아이디어인지 의문을 제기하는 사람들을 여러 번 만났다. 비판들 중 일부는 타당하지만, 전체적으로 봤을 때 나는 여전히 fixit이 할 만한 가치가 있다고 본다.
어느 정도는 맞다. 이것은 관리자는 물론 엔지니어들까지 "페이퍼컷(papercut) 같은 자잘한 버그"의 중요성을 과소평가하고 있다는 인정이기도 하다. 큰 프로젝트가 성공하도록 챙기는 데 터널 비전을 갖기 쉽고, 사용자와 팀에 자잘한 짜증을 주는 문제들은 무시하기 더 쉽다.
Fixit은 이를 어느 정도 상쇄하기 위한 시도이기도 하다. "사실 이런 버그들도 중요하다"라고 말하는 셈이다. 그렇다고 우리가 평소에 중요한 버그를 안 고치는 건 아니다. 물론 고친다. 다만 fixit은 "조금 짜증 나지만 절대 긴급해지지는 않는" 부류의 문제에도 별도의 자리를 마련해야 한다는 사실을 인정하는 것이다.
우리가 처음 fixit을 시작한 이유 자체가, 이런 버그들이 실제로는 절대 처리되지 않는다는 걸 관찰했기 때문이다. 그런 상황에서, 이를 위해 명시적으로 시간을 떼어 내는 건 좋은 일이라고 생각한다.
확실히 트레이드오프다. 엔지니어 40명의 일주일은 엄청난 인력이기 때문에, 그걸 로드맵 문제 해결에 쓰는 게 맞다는 주장도 가능하다.
하지만 나는 이것이 사용자에게 있어 제품의 "폴리시(polish)"가 갖는 중요성을 과소평가한다고 본다. 우리는 fixit 이후 제품이 눈에 띄게 더 좋아졌다고 일관되게 느껴 왔다(사용자들이 눈에 보이는 변화에 대해 긍정적인 피드백을 주기도 한다!). 그리고 제품이 잘 돌아간다는 자부심 역시 만들어 준다.
Perfetto UI의 "record" 페이지를 개선한 내 PR에 대한 한 사용자의 반응
게다가 팀 생산성을 위한 많은 개선은(더 빠른 테스트, 더 명확한 에러, 더 매끄러운 워크플로 등) 복리처럼 쌓인다. 그 이득은 fixit 주간을 훨씬 넘어 지속된다.
아주 작은 팀이나 스타트업에게는 일주일이 과할 수 있다는 데엔 나도 동의한다. 하지만 아이디어를 더 작은 단위로도 얼마든지 빌려 쓸 수 있다. 예를 들어, 한 달에 한 번 "Fixit Friday"를 한다든지, 분기마다 2일짜리 미니 fixit을 한다든지. 핵심 아이디어는 같다. 사람들이 늘 불평하지만 아무도 일정에 잡지 않는 것들을 고치기 위한, 보호된(protected) 집단적 시간.
Fixit의 공식적인 명분은 제품 품질과 개발자 생산성을 높이기 위해서다. 물론 실제로도 그렇다.
하지만 내가 이걸 좋아하는 비공식적인 이유는 더 단순하다. 그냥, 뭔가를 고치는 일이 기분이 좋기 때문이다. 나를 좀 더 단순했던 시절로 데려다주고, 멋진 제품을 만들기 위해 생각과 관심을 기울이는 것은 소프트웨어 엔지니어링이 어떻게 수행되어야 하는지에 대한 내 가치관의 큰 부분을 차지한다. 나는 항상 이렇게만 일하고 싶지는 않다. 하지만 동시에, 이런 일을 위한 시간을 전혀 만들지 않는 곳에서 역시 일하고 싶지 않다.
이 글이 마음에 들었다면, 최근 글을 모아 주간으로 보내는 뉴스레터를 구독하거나, RSS로 팔로우할 수 있습니다.
