로드맵 멈추고 189개 버그를 잡아봤다: 픽싯 주간의 힘

금요일 오후 4시, 이번 주 12번째 버그를 막 닫았습니다. 머리는 이미 녹았는데, 버그 리더보드를 보며 월요일에 다시 "정상 업무"를 해야 한다는 사실이 살짝 아쉽습니다. 아이러니하게도 제 본업을 좋아하지만, 분기마다 찾아오는 이 한 주, 바로 '픽싯(Fixit) 주간'은 제 개발자 인생에서 아주 특별한 시간입니다.

이 글에서는 우리가 분기마다 로드맵을 멈추고 일주일 동안 버그만 잡는 이유, 실제 성과, 팀 분위기의 변화, 운영 노하우, AI 활용법, 그리고 비판에 대한 솔직한 생각까지 한 번에 정리해 보겠습니다.

픽싯(Fixit) 주간이란 무엇인가: 일주일간 오직 "고치기"만 하는 시간

우리 조직(약 45명의 소프트웨어 엔지니어)은 분기에 한 번, 딱 일주일 동안 모든 정규 업무를 멈춥니다. 이때는 로드맵 작업도, 신규 기능 설계도, 정기 회의도, 스탠드업도 없습니다.

그 대신 그동안 우리와 사용자를 괴롭히던 자잘한 문제들을 처리합니다. 예를 들면 이런 것들입니다.

• 2년째 애매하게 써 있던 오류 메시지

• 스크롤과 줌을 동시에 할 때만 나타나는 미묘한 UI 버그

• 괜히 느리게 돌아서 모두의 CI 시간을 갉아먹던 테스트 코드

규칙은 아주 단순합니다.

1. 어떤 버그도 2일 이상 들고 있지 않는다.

2. 작업은 "사용자 경험을 개선하는 작은 기능/버그" 또는 "개발 생산성 향상"에만 쓴다.

여기에 가벼운 게임 요소를 얹습니다. 버그 난이도별로 점수를 부여하고, 리더보드에 누가 몇 점인지 실시간으로 보여줍니다. 첫 버그 해결, 가장 많이 고친 사람, 제일 짜증났던 버그 해결 등 다양한 "업적"을 만들고 티셔츠 같은 작은 리워드를 걸어 둡니다.

단순해 보이지만, 놀라울 정도로 잘 작동합니다. 그리고 이번 분기 픽싯의 결과는 꽤 짜릿했습니다.

189개 버그를 없앤 일주일: 구체적인 성과와 사례들

이번 픽싯 주간의 숫자는 이렇습니다.

• 총 189개의 버그 해결

• 40명 참여

• 1인당 중간값 4개 버그 해결

• 개인 최대 12개 버그 해결

숫자만 보면 "잘했네" 정도일 수 있지만, 진짜 의미는 디테일에 있습니다.

예를 들어, 저는 2021년에 올라온 기능 요청 하나를 드디어 닫았습니다. 네 해 동안 우선순위에서 밀리고 밀리던, 그저 작은 개선 사항이었죠. 그런데 막상 손대니 하루 만에 끝났습니다. 하루면 되는 일을 4년 동안 미뤄둔 셈입니다. 그 기능 하나로 Perfetto 사용자의 경험은 조금이지만 확실히 좋아졌습니다.

동료 한 명은 GitHub Action에 약 25줄짜리 코드를 추가했습니다. UI 개발자들이 CI 빌드를 열 때마다 하던 쓸데없는 클릭 두 번을 없애기 위한 작업이었습니다. 사소해 보이지만 팀의 반응은 폭발적이었습니다. "드디어 이 귀찮은 걸 안 해도 된다니!" 이 정도의 기쁨은 돈으로 환산하기 어렵습니다.

또 다른 작업은 SDK를 하나의 묶음 형태로 제공하는 "통합 버전"을 만드는 것이었습니다. 어떤 팀에게는 "이 SDK를 쓸까 말까"를 결정하는 핵심 포인트가 될 수 있는 요소인데, 실제 구현엔 한 시간 정도밖에 걸리지 않았습니다. AI를 적극 활용해 코드베이스를 빠르게 파악했기에 가능한 속도였습니다.

이런 작은 변화들이 모여 제품의 "느낌"을 완전히 달라지게 만듭니다. 유저들은 꼭 "어제보다 얼마나 좋아졌는지"를 숫자로 말하진 않지만, 확실히 체감합니다.

제품 관점에서의 픽싯: 디테일이 좋은 제품을 만든다

좋은 제품을 만들려면 거대한 비전과 멋진 기능도 중요하지만, 그 못지않게 중요한 것이 있습니다. 바로 "사소한 것들까지 신경 썼다는 느낌"입니다.

에러 메시지가 정확한지, 사용자가 같은 동작을 반복해서 해야 하는지, 모서리에 걸리는 듯한 UX가 있는지. 이런 것들은 대개 Jira 우선순위 상단까지는 잘 올라오지 않습니다. "중요하긴 한데, 지금 급하진 않은 것들" 사이에서 영원히 떠도는 경우가 많죠.

픽싯은 바로 이 구석구석을 정리하는 시간입니다. 사용자는 이 디테일을 명확하게 의식하지 않더라도, "뭔가 이 제품은 신경을 많이 쓴 느낌이야"라고 느낍니다. 반대로 모난 부분이 많은 제품은, 대체제가 없는 한 버티면서 쓰겠지만, 마음 한구석에 늘 "쓸만한 다른 거 없나…"라는 아쉬움이 남게 됩니다.

일주일 동안 로드맵을 멈추고 "마감 안 쫓기는 디테일 작업"에 집중하는 경험은 제품의 완성도를 한 단계 끌어올립니다. 픽싯 직후 실제 유저 피드백에서도 "UI가 훨씬 부드러워졌다", "이거 바꾼 사람 누구냐, 고맙다" 같은 반응이 나옵니다.

개인에게 주는 보상: 다시 '고치는 사람'이 되는 기분

커리어 초반에는 고장 난 걸 발견하면 바로 고치고, 그날 바로 배포하는 일이 많습니다. "봤다 → 고쳤다 → 배포했다 → 끝났다"라는 짧고 경쾌한 사이클이죠.

하지만 회사가 커지고, 본인의 직급이 올라갈수록 일이 달라집니다. 무엇을 만들지 결정하고, 분기 계획을 짜고, 이해관계자를 설득하고, 트레이드오프를 조율하는 시간이 훨씬 길어집니다. 실제로 손을 움직여 무언가를 고치는 시간은 점점 줄어듭니다.

픽싯은 그 균형을 잠깐 다시 되돌립니다. 문제를 보고, 바로 고치고, PR을 올리고, 머지하고, 버그를 닫습니다. 그 과정을 일주일 동안 여러 번 반복할 수 있습니다.

이때의 질문은 "우리가 무엇을 해야 하지?"가 아니라 "이거, 내가 더 좋게 만들 수 있을까?"입니다. 그리고 대부분 "그렇다"라는 답을 행동으로 보여줄 수 있습니다. 이 단순하고 직관적인 만족감은, 생각보다 개발자에게 큰 에너지를 줍니다.

팀의 사기와 문화: 40명이 동시에 같은 방향으로 달릴 때

픽싯 주간에는 사무실과 채팅방의 분위기가 확실히 달라집니다. 평소에는 각자 다른 프로젝트를 붙들고 있지만, 이 한 주만큼은 모두가 같은 목표를 향해 달립니다. "우리 제품의 귀찮은 점들을 싹 정리하자."

사람들은 자신이 고친 버그를 채팅방에 올리고, 수정 전후 화면을 캡처해서 자랑합니다. 특히 지독하게 골치 아프던 버그를 해결하면, 모니터 앞에 동료들이 모여 "그거 드디어 해결했어?"라며 함께 기뻐합니다.

매일 아침 올라오는 짧은 요약도 분위기를 끌어올립니다. 예를 들어:

• 어제 하루 동안 해결된 버그 개수

• 한 개 이상 버그를 해결한 사람 수

• 어떤 제품들에 변화가 있었는지

• 현재 리더보드 상위권에 누가 있는지

리더보드는 여기에 가벼운 경쟁심을 얹어 줍니다. 사람들은 빠르게 처리할 수 있는 버그와, 점수는 적어도 "이야기거리"가 되는 버그를 적절히 섞으며 자신만의 전략으로 일주일을 운영합니다. 이 모든 요소가 맞물리면, 팀 전체가 자연스럽게 "버그 없애기 모드"로 빨려 들어갑니다.

성공적인 픽싯 운영 노하우: 준비, 제한, 규모

6번의 픽싯을 겪으며 깨달은 건, 일주일 전에 승부가 거의 난다는 사실입니다. 준비가 전부라고 해도 과언이 아닙니다.

우리는 평소에도 버그를 보다가 "픽싯용으로 좋겠다" 싶은 것에 태그를 달아 둡니다. 그리고 픽싯 전 주에 각 서브팀이 이 버그들을 훑으며 대략적인 크기를 매깁니다.

• 소: 반나절 이내

• 중: 하루 이내

• 대: 이틀 이내

여기에 1, 2, 4점처럼 단순한 점수를 붙입니다. 또한 "이번 픽싯에서 반드시 처리하고 싶은 우선순위 상위 버그 목록"을 따로 뽑아 둡니다. 참여자들은 이 상위 목록에서 시작해, 이후 전체 리스트로 확장해 나갑니다. 이 과정을 미리 해 두면, 픽싯 첫날에 "뭘 하지?" 하며 시간을 날리는 일이 거의 없습니다.

또 하나 중요한 건 "2일 제한"입니다. 초기 픽싯에서, 한 사람이 겉보기에 간단해 보이는 버그를 집어 들었다가 지옥을 경험한 적이 있습니다. 묵혀 있던 코드, 얽힌 의존성, 대책 없는 엣지 케이스들이 줄줄이 튀어나와 결국 픽싯 한 주 내내, 심지어 그 다음 주까지도 그 버그만 붙들고 있게 됐습니다.

일 자체는 가치 있었지만, 픽싯의 핵심인 "여러 버그를 닫으며 만드는 리듬과 성취감"을 완전히 잃었습니다. 그 경험 이후로 우리는 "2일 넘게 걸릴 것 같으면 바로 내려놓고, 정식 작업으로 옮기고, 픽싯에 맞는 다른 버그로 갈아타라"는 철칙을 세웠습니다.

규모도 중요합니다. 처음에는 7명 정도의 작은 팀으로만 픽싯을 했는데, 괜찮긴 했지만 "조직 전체를 움직였다"는 느낌은 없었습니다. 지금처럼 40명 규모가 되자, 확실히 임계점을 넘긴 듯한 에너지가 생겼습니다. 팀마다 다르겠지만, 대략 7명에서 40명 사이 어딘가에서 "와, 이거 진짜 크다"라는 감각이 살아납니다.

점수와 리더보드: 게임 같지만, 성과 평가는 아니다

픽싯을 이야기하면 "아, 또 KPI화된 경쟁 시스템인가?"라며 걱정하는 분들이 많습니다. 하지만 이걸 제대로 운영하려면 오히려 "정확한 측정"에 집착하면 안 됩니다.

우리가 쓰는 점수 체계는 일부러 거칠게 만들었습니다. 버그는 그냥 1, 2, 4점. 이게 실제 노력과 100% 비례할 필요는 없습니다. 핵심은 "대략 이 정도면 이런 느낌의 크기" 수준에서 재미 요소를 주는 것일 뿐, 정밀한 평가 도구가 아닙니다.

또한 우리는 "양"만 보지 않습니다. 가장 많은 점수를 딴 사람에게만 상을 주는 게 아니라, 첫 버그를 해결한 사람, 가장 짜증 나던 버그를 정리한 사람 등 다양한 관점으로 축하합니다. 그래야 신입이나 경험이 적은 엔지니어도 자연스럽게 참여할 수 있습니다.

그리고 가장 중요한 원칙이 있습니다. 픽싯 점수는 성과 평가와 1도 연결하지 않습니다. 이 순간이 깨지는 순간, 사람들은 게임을 하기 시작하고, 분위기는 삭막해지며, 픽싯의 좋은 에너지는 금세 사라집니다.

우리 조직에서는 아직까지 점수를 악용하는 사례가 거의 없었습니다. 40명 정도 되는 규모에서는 서로를 알고 있고, "우리는 제품을 위해 같이 뛰고 있다"라는 공감대가 유지되기 때문입니다.

AI가 바꾼 픽싯 경험: 컨텍스트 스위칭의 피로를 줄이다

픽싯의 본질적인 어려움 중 하나는 컨텍스트 스위칭입니다. 버그마다 코드베이스의 다른 부분을 파고들어야 하고, 새로운 도메인을 이해해야 합니다. 평소보다 더 많은 "뇌 리셋"이 필요합니다.

여기서 AI 도구들이 꽤 큰 도움을 주고 있습니다. AI가 직접 써 주는 코드보다 더 중요한 건, "관련 파일을 빠르게 찾아주고, 지금 뭘 이해해야 하는지 요약해 주는 능력"입니다. AI의 제안이 100% 맞지 않더라도, 출발점을 제공해 주기 때문에 머리를 써야 하는 양이 확 줄어듭니다.

예를 들어 문서에서 새 기여자를 헷갈리게 만들던 부분을 수정할 때, AI는 거의 한 번에 정답에 가까운 수정안을 내놓았습니다. 반면 어떤 페이지의 UX를 개선하는 작업에서는, AI가 초안을 만들었지만 UX 감각이 부족해 사람이 꽤 많이 손봐야 했습니다. 그래도 "이 정도 구조로 가면 되겠구나"라는 틀을 빠르게 얻을 수 있어, 시작선까지 가는 시간이 크게 줄었습니다.

결론적으로, 픽싯처럼 짧은 시간에 여러 영역을 옮겨 다니는 이벤트와 AI는 꽤 궁합이 좋습니다.

픽싯에 대한 비판들, 그리고 그럼에도 불구하고 좋아하는 이유

픽싯을 이야기하면 이런 질문을 많이 듣습니다.

"그럼 평소에는 버그를 제대로 안 고친다는 뜻 아닌가요?" 어느 정도는 맞는 말입니다. 특히 "조금 불편하지만, 당장 급한 건 아닌" 버그들은 항상 우선순위에서 밀리기 쉽습니다. 큰 프로젝트의 성공에 집중하다 보면, 이런 작은 불편을 의도치 않게 과소평가하게 됩니다.

픽싯은 이 균형을 일부러 되돌리는 장치입니다. "이 작은 불편들도 사실 중요하다"라고 공식적으로 인정하는 순간이죠. 물론 치명적인 버그는 평소에도 바로 처리합니다. 다만 픽싯은 "늘 미뤄지던 에지 케이스와 사소한 귀찮음"을 위한 보호구역 같은 것입니다.

"엔지니어 40명 일주일을 통째로 버그에 쓰는 건 낭비 아닌가요?"라는 질문도 있습니다. 단순히 숫자만 놓고 보면 맞는 말처럼 들립니다. 하지만 우리가 느끼기로는, 이 일주일은 꽤 높은 ROI를 만들어냅니다.

픽싯 이후 제품은 분명히 더 매끄러워지고, 유저들도 그 변화를 느낍니다. 게다가 테스트 속도, 에러 메시지 개선, 개발 플로우 단축 같은 생산성 개선은 이후 수개월, 수년 동안 복리처럼 이득을 쌓아 줍니다.

"이건 큰 회사니까 가능한 거 아닌가요?"라는 지적도 타당합니다. 아주 작은 팀이나 초기 스타트업이 일주일을 통째로 비우는 건 쉽지 않을 수 있습니다. 그래도 아이디어 자체는 조금씩 변형해서 쓸 수 있습니다.

• 한 달에 한 번 "Fixit Friday"

• 분기마다 2일짜리 미니 픽싯

• 스프린트 말미의 반나절 사소한 버그 처리 타임

중요한 건 "여기는 평소에 미뤄둔 귀찮은 문제를 해결하는 보호된 시간이다"라는 메시지를 팀에 분명히 주는 것입니다.

마무리: 픽싯은 제품도, 사람도, 팀도 건강하게 만든다

픽싯의 공식적인 이유는 분명합니다. 제품의 품질을 올리고, 개발자 생산성을 높이기 위해서입니다. 버그 189개를 없애고, 테스트를 빠르게 만들고, UX를 다듬는 건 그 자체로 조직에 큰 이득입니다.

하지만 제가 픽싯을 정말로 좋아하는 이유는 더 단순합니다. "고장 난 것을 고치고, 바로 좋아진 걸 보는 경험"이 너무나 기분 좋기 때문입니다. 개발자로서의 원초적인 즐거움, 그리고 "우리가 만드는 제품을 진심으로 아낀다"는 감각을 다시 확인시켜 줍니다.

매일이 픽싯이어야 한다고 생각하지는 않습니다. 하지만 한 번도 픽싯 같은 시간을 만들지 않는 조직에서 계속 일하고 싶냐고 묻는다면, 저는 아마 "아니요"라고 답할 것 같습니다.

당신의 팀도 한 번쯤, 로드맵을 잠시 멈추고 "고치는 일만 하는 한 주"를 시도해 보면 어떨까요? 아마 예상보다 훨씬 더 많은 버그와 함께, 꽤 괜찮은 팀 분위기까지 덤으로 얻게 될 겁니다.

출처 및 참고 : We stopped roadmap work for a week and fixed 189 bugs - Lalit Maganti