# 로드맵 작업을 멈추고 버그 수정에 집중한 일주일 > Clean Markdown view of GeekNews topic #24587. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24587](https://news.hada.io/topic?id=24587) - GeekNews Markdown: [https://news.hada.io/topic/24587.md](https://news.hada.io/topic/24587.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-11-25T08:33:40+09:00 - Updated: 2025-11-25T08:33:40+09:00 - Original source: [lalitm.com](https://lalitm.com/fixits-are-good-for-the-soul/) - Points: 20 - Comments: 2 ## Summary 약 45명의 엔지니어가 분기마다 일주일간 로드맵과 회의를 멈추고 오직 **버그 수정과 생산성 개선**에 몰입하는 ‘Fixit 주간’을 수행한 경험을 공유하는 글인데요. **2일 이내 해결 규칙**, **포인트·리더보드 시스템**, 그리고 **AI 도구의 코드 탐색 지원** 덕분에 189개의 버그가 빠르게 수정되며 팀 전체가 즉각적인 성취감을 느끼게 했다고 합니다. 단순히 기술 부채를 줄이는 행사가 아니라, “무언가를 고치는 즐거움”을 되살려 **제품 완성도와 팀 결속**을 동시에 높이는 문화적 장치인 것 같습니다. 이런 리듬을 주기적으로 도입하는 건, 바쁜 스타트업에도 꽤 유효한 리셋 버튼이 될 듯합니다. ## Topic Body - 약 **45명의 엔지니어 조직**이 분기마다 일주일간 로드맵·디자인·회의를 중단하고 **‘Fixit 주간’** 을 운영, 사소한 버그와 생산성 문제 해결에 집중 - 이번 Fixit에서 **189개의 버그가 수정**, 40명이 참여했으며 1인당 중앙값 4건, 최대 12건의 버그를 닫음 - **2일 이내 해결 규칙**, **포인트·리더보드 시스템**, **티셔츠 보상** 등으로 동기 부여와 팀 사기 고양 - **AI 도구 활용**으로 코드 탐색과 수정 제안 속도 향상, 맥락 전환 부담 감소 - Fixit은 제품 완성도 향상과 팀 결속 강화에 기여하며, **작은 문제 해결의 즐거움**을 되살리는 문화로 평가됨 --- ### Fixit의 개념과 운영 방식 - Fixit은 분기마다 일주일간 진행되는 집중 버그 수정 주간으로, **정규 로드맵 작업·디자인·회의를 전면 중단** - 엔지니어들은 사용자와 개발자가 불편해하던 **작은 오류나 생산성 저하 요인**을 해결 - 예시: 2년간 불명확했던 오류 메시지, 스크롤·줌 동시 사용 시 발생하는 글리치, 느린 테스트로 인한 CI 지연 - 규칙은 두 가지 - 어떤 버그도 **2일 이상 소요되지 않아야 함** - 작업은 **엔드유저 개선 또는 개발자 생산성 향상**에 집중 - **포인트 시스템과 리더보드**를 운영해 참여도를 시각화하고, ‘첫 버그 수정’, ‘가장 짜증나는 버그 수정’ 등 다양한 부문에 **티셔츠 보상** 제공 ### Fixit 성과 - 이번 Fixit 결과 - **189개 버그 수정**, **40명 참여**, **1인당 중앙값 4건**, **최대 12건** - 주요 사례 - 2021년 등록된 Perfetto의 [기능 요청](https://github.com/google/perfetto/issues/154)을 하루 만에 구현, 사용자 경험 개선 - [GitHub Action 수정](https://github.com/google/perfetto/pull/3736)을 통해 UI 개발자의 빌드 접근 클릭 수 절감 - [SDK 통합 버전 제공](https://github.com/google/perfetto/issues/713)으로 프로젝트 통합 용이성 향상, 약 1시간 내 구현 ### Fixit의 효과 - ## 제품 측면: 세밀함과 완성도 - 좋은 제품의 특징은 **세부 사항에 대한 주의와 일관성** - Fixit은 사용자가 직접 인식하지 못할 수 있는 **작은 불편 요소를 제거**해 제품 품질을 한 단계 높이는 기회 - ## 개인 측면: 실행 중심의 만족감 - 경력 초기에 느꼈던 “문제 발견 → 수정 → 배포”의 즉각적 성취감을 되찾는 경험 - Fixit 기간에는 **‘무엇을 만들까’보다 ‘어떻게 개선할까’** 에 집중, 짧은 주기로 성취감 누적 - ## 팀 측면: 사기와 협업 강화 - 두 개 시간대의 40명이 동시에 버그를 수정하며 **조직 전체의 에너지 상승** - 채팅방에서 실시간 수정 공유, 스크린샷 게시, 데모 시연 등 활발한 교류 - 매일 아침 **수정 건수·참여 인원·리더보드 순위**를 공유해 동기 부여 강화 ### 성공적인 Fixit 운영 요건 - ## 사전 준비 - 연중 버그를 “good fixit candidate”로 태깅, Fixit 전 주에 **소형·중형·대형(0.5·1·2일)** 으로 분류 - 각 크기에 따라 **1·2·4 포인트** 부여, 우선순위 버그 목록 작성 - 이 준비 과정이 **첫날 혼란 방지의 핵심 요소** - ## 2일 제한 규칙 - 과거 한 버그가 예상보다 복잡해 Fixit 주간 전체를 소모한 사례 발생 - 이후 **2일 초과 시 중단·백로그 이동** 원칙 도입, **지속적 성취감 유지** 목적 - ## 참여 인원 규모 - 초기 7명 규모에서는 성과는 있었으나 조직 전체의 공감 부족 - 약 **40명 수준에서 임계 질량 형성**, **집단 에너지와 몰입감 극대화** - ## 게이미피케이션 - 포인트는 **정확성보다 재미 중심(1/2/4점)** - **성과 폭넓게 인정**: 첫 수정, 가장 짜증나는 버그 등 다양한 부문 - **성과평가와 분리**, 순수한 참여 동기 유지 - 사회적 규범과 팀 규모 덕분에 **시스템 악용 사례 거의 없음** ### AI 도구의 역할 - Fixit의 핵심 과제인 **맥락 전환 부담**을 AI가 완화 - 관련 파일 탐색·요약을 빠르게 수행해 **인지 부하 감소** - 예시 - [문서 수정 PR](https://github.com/google/perfetto/pull/3774): AI가 단번에 수정안 제시 - [Record 페이지 개선](https://github.com/google/perfetto/pull/3780): AI가 코드 프로토타입 제공, UX 수정은 수작업으로 보완 - 결과적으로 **시작점 도달 속도 향상**, 일부 경우 **즉시 수정 가능** ### Fixit에 대한 비판과 대응 - ## “버그를 평소에 무시한다는 뜻 아닌가?” - 일정 부분 사실이지만, **작은 불편함(papercut bugs)** 이 우선순위에서 밀리는 현실을 보완 - Fixit은 “사소하지만 중요한 문제”를 해결할 **명시적 시간 확보 수단** - ## “로드맵 작업을 멈추는 건 낭비 아닌가?” - 40인·1주 규모의 인력 투입은 크지만, **제품 완성도 향상과 사용자 만족도 증가**로 상쇄 - **테스트 속도 개선·오류 메시지 명확화·워크플로우 단축** 등 생산성 향상 효과가 장기적으로 지속 - ## “대기업만 가능한 방식 아닌가?” - 소규모 팀도 **‘Fixit Friday’** 나 **2일 미니 Fixit** 등으로 변형 가능 - 핵심은 **집중적·보호된 시간 확보**와 **공동 개선 활동** ### Fixit의 본질적 가치 - 공식 목적은 **제품 품질과 개발자 생산성 향상** - 비공식적 이유는 **“무언가를 고치는 즐거움”** - 단순한 시절의 만족감을 되살리고, **세심한 제품 제작 문화**를 유지하는 데 필수적 요소로 평가됨 ## Comments ### Comment 46762 - Author: t7vonn - Created: 2025-11-25T11:22:51+09:00 - Points: 1 배민 피트스탑 문화가 생각나네요. 지금은 없어졌다고 들었습니다 ### Comment 46744 - Author: neo - Created: 2025-11-25T08:33:41+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=46024541) - 아이디어는 마음에 들지만, “**버그는 2일 이상 걸리지 않아야 한다**”는 문장은 이상하게 느껴짐 실제로 버그를 고치기 전에는 얼마나 걸릴지 예측하기 거의 불가능함 다만 큰 리팩터링이 필요하지 않다면 하루 이상 걸릴 일은 거의 없다고 생각함 나는 보통 **심각도나 우선순위**에 따라 버그를 처리함. 심각한 버그일수록 의외로 쉽게 찾을 때가 많음 원인을 찾으면 해결은 금방임 - 예전에 **MS SQL Server**를 많이 쓰던 회사에서 일했는데, 몇 달마다 서버 클러스터를 멈추게 하는 **Heisenbug**가 발생했음 로그를 수년간 분석했지만 원인을 못 찾다가, 특정 상태의 DB와 커밋 조합에서 100% 재현되는 걸 발견함 NDA를 맺고 최소 재현 바이너리를 만들어 PowerShell 스크립트로 자동화했더니, 한 달 만에 MS가 수정했음 내부적으로는 **버퍼 오버플로우** 느낌이었지만 확실하진 않음 - 내가 일했던 대부분의 버그 많은 프로젝트에도 이런 규칙이 암묵적으로 있었음 일주일 내내 버그만 잡고 Jira에 **스토리 포인트**를 못 쌓으면, 여러 매니저들이 몰려와 왜 속도가 느린지 묻곤 했음 그래서 배운 교훈은, 어려운 버그는 피하고 포인트 안 나오는 일은 일찍 포기하는 게 낫다는 것임 - 하드웨어 쪽에서 일하다 보면 **재현 어려운 버그**는 몇 달씩 걸릴 때도 있음 코드, 컴파일러, 하드웨어 중 어디가 문제인지 알 수 없고, 여러 요소가 동시에 꼬여서 생기는 **복합 버그**는 단독으로 재현조차 불가능함 - 게임처럼 **얽힌 아키텍처**에서는 이벤트 A가 B를 트리거하지만 C의 상태에 따라 달라지는 식의 복잡한 구조가 많음 이런 경우 빠른 임시방편이 쌓이면, 나중에 제대로 된 버그 수정이 **대규모 리워크**로 이어짐 - 버그가 고쳐지지 않는 경우는 두 가지임 1) 원인이 명확하지 않아 찾는 데 대부분의 시간이 드는 경우 2) 원인은 명확하지만 **아키텍처적 실수**라 수정이 대공사인 경우 또, **저신뢰 환경**에서는 Jira 절차 때문에 사소한 버그조차 바로 못 고치는 경우도 있음 - Meta에서 일할 때 **Fix-it Week**를 분기마다 했음 처음엔 리더십이 품질을 신경 쓴다고 생각했지만, 실제로는 **기술 부채를 쌓는 면허 기간**이었음 일주일 동안 버그를 고치려 했지만, 이미 쌓인 부채 때문에 거의 아무것도 해결하지 못했음 - id Software의 정책이 떠오름 — “**버그를 보면 즉시 고쳐라**” 그렇지 않으면 새 코드가 버그 위에 쌓여 **불안정한 기반**이 된다는 내용임 [John Romero의 강연 영상](https://www.youtube.com/watch?v=IzqdZAYcwfY&t=982s)에서도 같은 철학을 강조함 - Meta에서의 Fix-it Week는 실제로는 **리팩터링 주간**이었음 개발자들이 예전에 남겨둔 TODO를 처리하며 LOC를 늘리는 식이었고, 일부는 일부러 잘못된 코드를 작성해 나중에 “수정”하는 식으로 **diff 수를 늘리는 꼼수**도 있었음 - 원문에서 말하듯, Fix-it Week는 **작은 버그나 개발자 경험 개선**에 초점을 맞춘 주간임 즉, 긴급하지 않지만 거슬리는 문제들을 다루는 시간임 - 이런 주간은 오히려 “지금은 안 고쳐도 돼, Fix-it Week에 하자”는 **정신적 면죄부**가 됨 리더십이 솔직하게 **비즈니스 우선순위**를 설명하고, 버그의 사용자 영향도를 명확히 보여주는 게 더 중요함 - 진짜로 품질을 신경 쓴다면, **기능 개발 속에 자연스럽게 버그 수정**을 녹여 넣는 게 가장 현실적임 - 기능 개발 중에 **긴급 대응과 우선순위 변경**이 반복되는 악순환을 겪은 적 있음 결국 시스템은 **워크어라운드 투성이**가 되고, 고객도 개발자도 모두 불만족스러워짐 이런 상황에서는 차라리 처음부터 멈추고 **근본적인 버그 수정**을 했어야 한다는 생각이 듦 - 이런 패턴은 **조직 붕괴의 전형적인 증상**임 의사소통이 끊기고, 리더들이 **닭처럼 우왕좌왕**하며 명령만 내림 개발자는 모든 문제의 소방수로 전락하고, 결국 탈출하는 게 유일한 해법임 - 이는 명백한 **리더십 실패**임 속도가 느려질수록 리더가 더 공황 상태에 빠져 프로젝트를 마구 재배치하면서 **혼란과 독성 문화**를 키움 - 이런 상황을 피하려면 고객을 무조건 만족시키려 하기보다, **기대치를 관리하는 기술**이 필요함 - 다만 회사가 아직 **PMF(Product-Market Fit)** 를 찾는 단계라면, 완벽한 엔지니어링에 시간 쓰는 건 비효율적일 수도 있음 - 결론적으로, 문제는 개인이 아니라 **유독한 조직 문화**임. 가능한 빨리 떠나는 게 답임 - 나는 항상 “**버그 수정이 우선**”이라는 철학으로 일해왔음 기존 기능이 제대로 작동하지 않으면 새로운 기능을 만들지 않음 이렇게 하면 **버그 없는 코드베이스**를 유지할 수 있고, 팀 생산성도 높아짐 - 하지만 팀 규모가 커질수록, 버그보다 **새 기능 개발**을 우선시하는 경향이 강함 - 어디서 이런 문화가 가능했는지 궁금하다는 질문을 자주 받음 특히 프론트엔드는 다양한 환경 문제로 **완전한 무버그 상태**가 거의 불가능함 또, “버그” 정의가 모호해 매니저가 원하는 기능을 버그로 분류하는 경우도 생김 - 버그에도 **우선순위**가 있음 예를 들어 거의 사용되지 않는 API 페이지 오류는 새 기능보다 덜 중요할 수 있음 - 사용자 규모가 큰 시스템은 수천 개의 버그가 존재함 대부분은 경미한 문제라, 리더십은 **새 기능**을 더 선호함 - 실제로 완전한 **버그 제로 코드베이스**는 존재하지 않음. 버그가 없다고 믿는 건 인식 부족일 뿐임 - 나는 작은 **SaaS 제품**을 운영하며 “** 버그 우선 수정**” 원칙을 지키고 있음 새 기능보다 고객이 보고한 버그를 먼저 해결함 이렇게 하면 새로 발견되는 버그가 점점 줄고, 수정도 쉬워짐 비즈니스적으로는 비효율적일 수 있지만, **품질과 고객 신뢰** 측면에서는 최고의 전략임 고객이 제보한 버그가 몇 시간 내에 고쳐지면 정말 좋아함 - 하지만 15년 된 **레거시 코드베이스**에서는 이 원칙을 적용하기 어렵다는 동료의 공감도 있음 - 관련해 내가 쓴 글이 있음 — [Fix Bugs or Add New Features](https://killthehippo.com/posts/fix-bugs-or-add-new-features) - Fix-it Week 같은 제도는 오히려 **버그 수정 지연**을 부추김 “나중에 Fix-it Week에 하자”는 핑계가 생김 대신 분기나 스프린트 계획에 **유지보수 시간**을 명시적으로 포함시키는 게 낫다고 생각함 이렇게 하면 개발자가 즉시 버그를 고칠 명분이 생기고, **지속적 개선 문화**가 자리잡음 Fix-it Week는 차라리 **작은 개선이나 POC**를 포함한 미니 해커톤처럼 운영하는 게 좋음 - 예전 회사는 항상 같은 사이클을 반복했음 1) 기능 개발에 올인 → 2) 대형 고객 사고 발생 → 3) 모든 개발 중단 후 **버그 수정 주간** 이런 패턴은 **조직 문화가 잘못됐다는 신호**였음. 버그 수정 시간을 평소에 확보하지 않으면 절대 바뀌지 않음 - 예전에 Joel Spolsky가 제시한 **Joel Test**가 떠오름 그중 다섯 번째 질문이 “**새 코드를 쓰기 전에 버그를 고치는가?** ”였음 25년이 지난 지금도 여전히 유효한 기준임 [원문 링크](https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/) - 버그에 **점수나 크기 추정**을 매기지 말자는 입장임 굳이 점수가 필요하다면 전부 2로 두면 평균적으로 맞음 버그 수정은 **Kanban 방식**으로, 중요도 순서대로 처리하고 시간 내에 끝내면 됨 - 글쓴이임. 활발한 토론이 생겨 기쁨 1) 버그 복잡도는 예측이 어렵기 때문에, 몇 시간 조사 후 **범위가 커지면 다른 이슈로 전환**하도록 권장함 2) “버그”라는 단어를 전통적 오류뿐 아니라 **기능 개선 요청**까지 포함하는 사내 용어로 사용했음 3) Fix-it Week가 “그때까지 미루자”로 변질될 위험이 있지만, 우리는 **작은 버그 전용**으로 운영함 기술 위생이나 대형 이슈 해결의 대체 수단은 아님 - 흥미로운 글이었다는 피드백과 함께, **버그 수정으로 인한 회귀나 신규 오류**가 얼마나 발생했는지 궁금하다는 질문이 있었음