회의 없는 화요일을 1년 운영해봤다

결제·정산 코드에서 집중 흐름이 끊기면 버그가 돈이 된다

작은 팀일수록 회의 비용을 "우리는 빠르게 결정하니까 오히려 효율적"이라고 착각하기 쉽다. 세 명이 한 시간 모이면 세 시간이 날아간다고 생각하지만 실제 손실은 그 두 배에 가깝다. UC 어바인 글로리아 마크(Gloria Mark) 교수 연구에 따르면, 깊은 집중 상태에서 이탈한 뒤 완전히 복귀하는 데 평균 23분이 걸린다. 회의 전후 맥락 이탈 시간까지 더하면 한 번의 회의는 인당 두 시간 가까이를 실질적으로 잠식한다.

그런데 우리 팀처럼 결제·정산·자동화 파이프라인을 직접 운영하는 경우, 이 비용은 일반 제품 팀보다 구조적으로 더 높다. 결제 처리 로직에는 엣지 케이스가 촘촘하고, 정산 배치는 순서와 타이밍에 민감하며, 자동화 스크립트 하나가 잘못되면 중복 송금이나 누락 정산으로 직결된다. 일반 SaaS의 버그는 롤백하면 UX 문제로 끝나지만, 결제 버그는 이미 이동한 돈을 다시 맞추는 수작업 정산, 고객 환불, 경우에 따라 법적 리스크까지 따라온다. '집중의 가치'가 여기서는 문자 그대로 금전적 손실 방지와 직결된다. 우리가 2024년 초 이 제도를 도입하게 된 직접적 계기도 정산 배치 로직 리팩터링 작업을 3주째 완료하지 못하고 있었기 때문이었다. 매일 회의와 슬랙이 쪼개놓은 시간 속에서는 전체 맥락을 머릿속에 담아두고 작업할 수가 없었다.

규칙은 모호하면 첫 달에 무너진다

우리가 정한 규칙은 하나다. 화요일에는 어떤 형태의 동기 커뮤니케이션도 없다. 슬랙은 열어두고 메시지를 보내는 것도 허용하되, 즉각 응답을 기대하지 않는다. '긴급'의 예외 기준은 처음부터 명시적으로 문서화했다. 서비스 다운, 데이터 손실 위험, 결제 처리 중단 — 이 세 가지가 아니면 수요일까지 기다린다. "이거 빨리 봐야 할 것 같은데요"는 긴급이 아니다.

규칙이 단순한 것이 핵심이다. "중요한 경우엔 예외"처럼 모호하게 두면 결국 모든 것이 예외가 된다. 우리가 첫 달에 경험한 것이 딱 그랬다. "이건 중요한 것 같으니까"로 시작한 화요일 슬랙 스레드가 어느새 30분짜리 의사결정 세션이 되어 있었다. 이후 '긴급의 정의'를 Notion 문서에 명시적으로 적어두고, 예외를 요청하는 사람이 해당 기준에 해당하는지 먼저 그 문서를 확인하는 루틴을 만들었다. 그 이후로 화요일에 실제 동기 커뮤니케이션이 발생한 날은 1년 52주 중 여섯 번이었다.

1년 후 수치로 본 변화

주관적인 "더 생산적인 것 같다"보다 데이터로 이야기하는 편이 낫다. 우리 팀은 GitHub 커밋 로그와 Notion 작업 완료 기록을 기준으로 요일별 생산성을 4주 단위로 비교했다.

• 화요일 커밋 수: 다른 요일 평균 대비 약 1.8배
• 화요일 완료 작업의 난이도 비중(팀 내 자체 평가): 다른 요일 대비 복잡한 작업 비중 약 2.1배
• 화요일 작성 코드의 PR 리뷰 지적 건수: 다른 요일 코드 대비 약 30% 적음

가장 의미 있는 숫자는 세 번째다. 결제 로직이나 정산 파이프라인 관련 PR에서 "이 케이스는 어떻게 처리하냐"는 리뷰 코멘트가 눈에 띄게 줄었다. 집중한 상태로 작성한 코드는 엣지 케이스를 스스로 더 많이 잡아낸다. 방해가 없을 때 사람은 자신이 어디까지 생각했는지를 잃어버리지 않기 때문이다. 또 한 가지 예상치 못한 효과는 월요일·목요일 회의의 질이 높아졌다는 점이다. 화요일에 각자 생각을 정리하는 시간이 생기면서, 수요일부터 목요일 사이에 나오는 논의가 더 준비된 상태로 진행됐다. 즉흥적으로 결정하고 나중에 되돌리는 일이 확연히 줄었다.

정산 버그가 알려준 것: 미팅 직후는 가장 위험한 코딩 타이밍이다

2024년 3월, 정산 자동화 스크립트를 수정하던 중 특정 조건에서 정산 금액을 두 번 집계하는 버그가 발생했다. 당일 오후에 발견해 수동 정산으로 수습했지만, 이 버그가 포함된 코드의 작성 시간대를 GitHub 로그로 확인해보니 월요일 오전이었다 — 주간 킥오프 미팅이 끝난 직후 30분 만에 작성된 코드였다. 미팅 직후는 머릿속이 여러 논의로 가득 찬 상태다. 우선순위, 일정, 각자가 던진 아이디어들이 아직 가라앉지 않은 채로 복잡한 배치 로직을 건드린 것이 화근이었다.

같은 수정을 화요일 오전에 했더라면 스스로 잡아냈을 가능성이 높다고 팀 내에서 평가했다. 실제로 그 이후 유사한 수준의 수정을 화요일 오전에 진행했을 때, 작업 도중 스스로 "이 조건에서 중복 집계 가능성이 있다"고 판단해 로직을 고친 경우가 두 번 있었다. 이건 단순한 개인 역량 차이가 아니다. 집중 상태의 질이 다르면 같은 사람이 다른 코드를 쓴다. 결제·정산 코드처럼 실수의 결과가 직접적인 금전 손실로 이어지는 영역에서, 이 차이는 팀 전체의 운영 리스크 수준을 바꾼다.

솔직한 실패와 트레이드오프

1년을 운영했다고 완벽하게 지켜진 건 아니다. 화요일에 동기 커뮤니케이션이 실제로 발생한 여섯 번 중 세 번은 서버 이슈(정당한 예외), 두 번은 외부 클라이언트가 화요일에 콜을 잡아온 경우, 한 번은 팀원이 막힌 문제를 결국 슬랙으로 물어본 경우였다. 외부 미팅은 완전히 막을 수 없다. 클라이언트 일정이 내부 규칙보다 우선순위가 높을 때가 있다는 건 현실로 받아들이는 편이 낫다.

진짜 트레이드오프는 따로 있다. 화요일에 막힌 문제를 혼자 씨름하다 보면, 다음날 이야기했을 때 "아, 그건 이렇게 하면 됐는데"로 30초 만에 끝나는 경우가 종종 있다. 3시간을 혼자 쓴 셈이다. 우리 팀은 그 3시간 동안 문제를 더 깊이 이해하게 된 경우가 많아서 전반적으로 긍정적으로 평가하지만, 데드라인이 촉박한 스프린트 상황이라면 이 비용이 실질적 손실이 될 수 있다. 비동기 문서화가 자연스러워진 것도 처음엔 귀찮음이었다. 화요일에 답을 기다릴 수 없으니 질문을 문서로 남기는 것이 기본이 됐는데, 1년이 지나고 보면 그 기록이 반복 질문을 줄이고 온보딩 자료가 되는 경우가 많았다. 귀찮음이 자산이 되는 구조다.

당장 써먹을 실행 기준 4가지

결제·정산·자동화를 운영하는 소규모 팀이 같은 제도를 도입하려 한다면, 순서와 기준을 다음처럼 권한다.

1. '긴급'의 정의를 팀 문서에 문장으로 박아둔다. 추상적인 합의는 첫 달에 무너진다. "서비스 다운, 데이터 손실 위험, 결제 처리 중단"처럼 구체적인 문장으로 Notion이나 Confluence에 고정하고, 예외를 요청하는 사람이 먼저 그 문서 링크를 확인하게 만든다. 링크가 없으면 기억이 기준이 되고, 기억은 매번 다르게 해석된다.

2. 월요일 마지막 30분에 화요일 작업을 명시적으로 정한다. 방해받지 않을 것을 미리 알면 더 어려운 문제를 가져다 놓게 된다. 우리 팀은 월요일 오후에 각자 다음날 할 작업을 Notion 카드에 적어두는 루틴을 만들었다. 이 습관이 자리 잡으면 화요일이 자동으로 고난이도 작업 집중 블록이 된다.

3. 첫 한 달은 성과보다 규칙 유지에 집중한다. 생산성 효과는 두 달 이후부터 체감된다. 첫 달에는 불편함이 더 크다. 그 불편함을 이유로 제도를 포기하면 아무것도 얻지 못한다. 한 달 운영 후 팀 회고를 짧게 진행해보면 "생각보다 괜찮았다"는 반응이 나온다. 그 반응을 기록해두면 다음 달을 이어가는 근거가 된다.

4. GitHub Insights와 작업 완료 기록으로 요일별 데이터를 4주 단위로 비교한다. 주관적 느낌이 아니라 숫자로 이야기할 수 있어야 팀 내에서 제도가 정당성을 유지한다. 커밋 수, PR 리뷰 지적 건수, 완료된 작업 난이도 중 하나라도 추적하면 충분하다. 우리 팀에서 이 데이터가 제도를 1년 동안 지속시킨 가장 강력한 근거가 됐다.

내년에는 금요일 오후도 같은 방식으로 보호할 계획이다. 주간 정리, 다음 주 준비, 자동화 파이프라인 점검을 방해 없이 할 수 있는 블록을 구조적으로 확보하는 것이 목표다. 집중 시간은 저절로 생기지 않는다. 달력에 명시적으로 못 박아야 한다.

— by slecs