들어가면서 — 같은 채널의 32 시간

같은 채널에서 32 시간 안에 다음 세 메시지가 차례로 떨어졌다.

27일 오전 09:24 — PM “넵넵 이벤트 로깅은 후순위로 봐주셔도 됩니다.”

27일 저녁 19:29 — 같은 PM “오늘 사이에 새로운 이슈들이 많이 튀어나왔는데… 우선순위 정리해 둡니다. P0 — 띠지 / P0 — 가격 영역 / P0 — 적립금 라인 P1 — 등록 배너 / P1 — 즉시 할인 / P2 — … / P3 — …”

28일 오후 16:42 — 디자이너 “메뉴 옆에 New 뱃지 부착 — 오늘 안에 가능할까요?”

세 메시지 사이의 시차는 각각 10 시간, 20 시간이다. 첫 메시지가 후순위 로 분류한 일은 두 번째 메시지의 우선순위 표 안에 보이지 않는다. 그리고 세 번째 메시지의 일은 두 번째 메시지의 우선순위 표 안에 없던 일이다.

이걸 한 줄로 적으면 이렇다.

우선순위가 매일 새로 정해지면, 그건 우선순위가 없다는 뜻이다.

이번 글은 이 한 줄을 풀어 적어 둔다. 같은 한 달 동안 어떤 일이 있었는지 — 그리고 그 끝에서 손해를 보는 자리는 어디인지 를 정리해 두려고 한다.

첫 번째 자국 — 후순위 는 영영 오지 않는다

한 달 전 어느 시점에 데이터팀에서 “이벤트 로깅 정의서가 완성됐다” 는 메시지가 왔다. “미팅 한 번 잡고 싶다” 와 함께. 그때 나는 이주에 개발을 마무리해서 도그푸딩을 해야 해요 라고 답했다. 차주(=다음 주)부터 일정이 잡혔다.

그 다음 한 달 동안의 풍경은 단순하다.

  • 나는 이벤트 로깅을 매주 한 칸씩 진행한다. 1~7번을 한 주에, 13~14번을 다음 주에, 8~12번을 그 다음 주에.
  • 각 칸은 운영 배포에 같이 끼워 보낸다. 기능 배포 옆에 한 칸씩 붙이는 식이다.
  • 남은 칸은 점점 줄어든다.

그런데 어느 날 오전 09:24 에 PM 의 한 메시지가 떨어진다.

“넵넵 이벤트는 후순위로 봐주셔도 됩니다.”

이 한 줄이 그 자리의 모든 사람에게 같은 것을 가리키지 않는다. PM 의 자리에서 이건 “오늘 굵직한 다른 일이 있으니, 이건 그 다음에” 다. 그런데 이벤트 로깅을 한 달 동안 매주 한 칸씩 짊어지고 있던 나의 자리에서는 다른 의미다.

이건 내 한 달의 진척을 누군가 다시 0 으로 보고 있다 는 신호다.

후순위의 정의는 “다른 일이 끝나면 그 다음에 한다” 다. 그런데 다른 일 이라는 단어는 보통 끝나지 않는다. 어제의 일이 오늘로 미뤄지고, 오늘의 일이 내일로 미뤄지고, 그러면서 후순위로 분류된 일 은 영영 자기 차례가 오지 않는다.

이걸 알아챈 나는 “문구 수정 한 번 하고 진행해 볼 수 있지 않을까요?” 라고 답을 보냈다. 사실은 그 자리에서 후순위 분류를 묵묵히 거부한 한 줄이었다.

이게 첫 번째 자국이다. “후순위” 라는 라벨은 그 일을 시작하지 않은 사람에게는 가벼운 단어지만, 한 달 동안 매주 한 칸씩 짊어진 사람에게는 한 달의 무게를 0 으로 누르는 단어다. 받는 사람에 따라 무게가 다른 라벨을, 같은 단어로 같이 쓴다.

두 번째 자국 — 우선순위 정리 다음 날, 정리에 없던 일이 위로 치고 온다

같은 PM 이 그날 저녁 19:29 에 우선순위 표 를 정리해 보낸다. P0 셋, P1 셋, P2 하나, P3 둘. 8 칸 짜리 표 안에 그날 발견된 모든 이슈가 정리된다.

이때 표의 의미는 분명해 보인다.

“내일은 이 8 칸 안에서 움직인다.”

그런데 다음 날 오후 16:42, 그 8 칸 어디에도 없던 한 메시지가 같은 채널에 떨어진다.

“메뉴 옆에 New 뱃지 부착 — 오늘 안에 가능할까요?”

뱃지 한 칸짜리 작업이다. 그래서 이런 작업은 늘 “하루면 되잖아” 의 자리에 놓인다. 받는 사람의 자리에서는 그게 우선순위 표 위에 한 줄을 위로 끼워 넣는 일 인데, 보내는 사람의 자리에서는 그게 그저 한 줄짜리 부탁 으로 보인다.

이때 받는 사람이 할 수 있는 답은 보통 둘 중 하나다.

  1. “네, 일단 해 볼게요” — 어제 정리한 우선순위 표가 이 한 줄로 흔들린다.
  2. “엄청 중요하고 빨리 처리해야 하는 작업일까요?” — 자리를 한 번 멈춰 묻는다.

이번에 나는 두 번째 답을 보냈다. “지금 나간 기능 수정이 있을 것 같은데요. 저는 일단 이벤트 로깅을 다 못 끝내서 이주에는 이벤트 로깅 진행을 하고 있고요. 동료 FE 분은 오늘 발생한 장애 후속 작업을 하고 계세요. 바로 시작은 어려워 보이는데요. 엄청 중요하고 빨리 처리해야 하는 작업일까요?”

길게 쓰면 한 줄이다.

“이건 어제의 우선순위 표 위로 가는 일인가요?”

이 질문이 서로의 자리에서 한 번씩 던져졌다면 — 받는 자리의 한 줄과 보내는 자리의 한 줄이 한 번씩 — 그 일은 우선순위 표 위로 갈 수도 있고, 표 안의 한 자리로 들어갈 수도 있다. 답이 어떻든 자리를 한 번 멈춘 게 자국이다.

이게 두 번째 자국이다. “우선순위 정리”는 정리한 그 시점에만 의미가 있고, 다음 날 한 줄이 그 표 위로 끼어들기 시작하면 표 자체가 무의미해진다.

세 번째 자국 — 한 달 박은 정책이 24 시간 안에 두 번 바뀐다

이건 어제 글 에서 자세히 적어 둔 자리다. 한 정책으로 한 달 넘게 일했다 — “기능 X 가 첫 진입 시 기본 선택되어야 한다.” 어느 날 외부에서 강한 클레임이 한꺼번에 올라왔다. 그날 밤 10 시에 트래픽 집중 시간대인 걸 알면서도 블랙리스트 → 화이트리스트 → 하드코딩 패치가 운영에 나갔다. 다음 날 아침 같은 채널에 같은 사람들이 다시 모였다.

“정확한 정책은 오늘 10:30 디자인팀과 논의 후 말씀드릴 예정이지만…”

24 시간 안에 같은 자리에 같은 코드가 두 번 박히고, 두 번 빠진다.

이걸 한 줄로 적으면 이렇다.

정책이 24 시간 안에 두 번 바뀌면, 그건 정책이 없다는 뜻이다.

코드 어딘가에 “정책이 이러하니, 코드는 이러해야 한다” 라는 의도가 박혀 있다는 건 그 정책이 어제와 오늘과 내일 같은 답을 낸다 는 가정 위에 서 있다. 그 가정이 24 시간 안에 두 번 깨지면, 코드는 지금 보이는 모양 으로만 박히는 게 아니라, 이전 모양과 그 다음 모양의 자취까지 같이 박힌다. 이걸 기술 부채 라고 부르기엔 너무 작은 표현이다.

이건 기억의 부채 다. 1 년 뒤 그 코드를 보는 사람은, 그게 왜 그렇게 되어 있는지 모른다. 보는 사람이 그때의 PM 이어도 모른다. 그때 의사결정한 사람조차 한 달이 지나면 자기가 왜 그랬는지 잘 기억하지 못한다.

세 자국이 한 채널에서 맞물리면

이 세 자국이 따로따로 일어나면 각자 한 자리의 일이다. 한 달 동안 한 자국 정도는 누구에게나 일어난다. 그런데 이번에는 셋이 같은 한 달 안에 같은 채널에서 차곡차곡 쌓였다.

  • 첫 자국: 한 달짜리 이벤트 로깅이 후순위 라벨로 한 칸 미뤄짐.
  • 둘째 자국: 우선순위 표를 정리한 다음 날, 표에 없던 작은 부탁 한 줄이 표 위로 끼어듦.
  • 셋째 자국: 한 달 박은 정책이 24 시간 안에 두 번 바뀜.

이 셋이 한 자리에서 만나면 받는 자리의 사람은 한 가지를 알게 된다.

우선순위정책 은, 보내는 자리에서는 라벨이고, 받는 자리에서는 한 달의 무게다.

라벨은 한 줄에 바뀐다. 한 달의 무게는 한 줄로 안 바뀐다. 그래서 같은 한 줄이 두 자리에서 다른 무게로 작동한다. 보내는 자리는 “네 가벼운 한 줄을 보냈어” 인데, 받는 자리는 “네 한 줄에 내 한 달이 0 이 됐다” 가 된다.

이게 “개발자가 결국 손해를 본다” 의 정체다. 손해의 형태는 다양하다.

  1. 이벤트 로깅 한 달 미뤄짐 — 다음 분기 데이터 분석에서 “한 달 동안 이 이벤트가 비어 있다” 가 발견된다. 그때 누구도 이 한 달의 를 기억하지 못한다.
  2. 트래픽 집중 시간대에 호출당함 — 22 시 너머의 화이트리스트 패치 배포 자리에 호출이 간다. 다음 날 09:08 다른 PM 의 한 줄이 더해진다 — “개발 환경에서 수정 후 테스트 한다고 말씀드렸어요.” 이 한 줄이 그래서 너희가 무엇을 못 했냐 의 결로 들리는 자리도 있다.
  3. 다음 날 아침 다시 뒤집힘 — 어제 박은 화이트리스트가 다시 빠져야 한다는 통보가, 병원 가는 길의 사람에게 한 번 더 도달한다.

이 셋이 한 사람에게 같은 주에 모이면, 그 사람은 “이번 주는 좀 그랬다” 가 아니라 “이런 패턴이면 매주 그렇게 된다” 를 보게 된다. 패턴이 보이는 순간, 거기서 무언가를 한 번 적어 두지 않으면 그 패턴은 다음 달에 한 번 더 돈다.

“가볍게 결정한 게 아닙니다” — 라는 말이 받는 자리에서 어떻게 들리는가

이 사이클의 마무리에는 거의 항상 한 사람이 마무리 메시지를 보낸다.

“리더십에서 빠르게 진행해 달라는 이야기가 있었기 때문에 작업 담당자께 연락드린 것입니다.” “한 달간 작업한 내용에 대해 의사결정이 변경된 부분에 고됨을 토로하시는 건 이해합니다. 그 부분을 모르는 게 아닙니다.” “프로덕트가 잘못되라고 정책을 가볍게 고민하거나 의사결정하는 부분이 있는 것도 아님을 알아주셨으면 좋겠습니다.”

이 문장 자체는 진심이다. 가볍게 결정하지 않으려고 한다는 말도, 우선순위가 높았다는 말도, 다 진심이다. 나는 그 진심을 의심하지 않는다.

다만 — 받는 자리의 정직한 한 줄을 같이 적어 두면 이렇다.

“가볍게 결정하지 않았다는 말은, 그 자리에서 가볍게 보이지 않는 절차 가 같이 있을 때 가볍게 들리지 않는다.”

가볍게 보이지 않는 절차란, 어떤 거창한 게 아니다. 다음 같은 한 줄짜리 자리들이다.

  • “어제의 우선순위 표 위로 가는 일인가요?” 라고 묻는 한 줄.
  • “이 변경이 24 시간 안에 다시 바뀔 가능성이 있나요?” 라고 의사결정 시점에 묻는 한 줄.
  • “이 라벨이 받는 사람에게는 한 달의 무게라는 걸 알고 보냅니다” 라고 라벨 옆에 한 줄.

이 한 줄들이 의사결정 자리에 한 번씩 있으면, “가볍게 결정하지 않았다” 라는 마무리 문장이 받는 자리에서도 가볍게 들리지 않는다.

이 한 줄들 없이 마무리 문장만 오면 — 진심이라도 가볍게 들린다. 이게 진심이 받아들여지지 않는 메커니즘 이고, 그 메커니즘에서 빠질 수 있는 가장 작은 도구가 그 한 줄짜리 자리 다.

마치며 — 한 줄

오늘 적어 두고 싶은 한 줄.

우선순위가 매일 새로 정해지면, 그건 우선순위가 없다는 뜻이다. 정책이 24 시간 안에 두 번 바뀌면, 그건 정책이 없다는 뜻이다.

이 둘이 한 달 동안 같이 일어나면, 1 년 뒤 그 코드를 보는 사람은 그게 왜 그렇게 되어 있는지 모른다. 그때의 PM 도 모른다. 그래서 손해를 가장 길게 보는 사람은, 결국 그 코드를 다시 만질 다음 사람이다.

이 글은 그 다음 사람 에게 한 줄을 남기려는 글이기도 하다. 그때 그렇게 박은 이유 를 코드 위에 못 적어 둘 때, 적어도 그렇게 박히는 패턴이 어떻게 생기는지 만이라도 어딘가에 남겨 두고 싶었다.

그리고 한 가지 더. 이 글이 보내는 자리에 닿으면, 한 줄만 가져가도 좋겠다.

“이 라벨이 받는 사람에게는 한 달의 무게입니다.”

이 한 줄을 의사결정 자리에 한 번씩 끼워 두는 일이, 의외로 가장 큰 협업의 일이었다.