예전에 일정이 밀리고 있는 프로젝트를 이끈 적이 있습니다. 아키텍처에 문제가 있다는 것도, 마감을 못 맞추리라는 것도 알고 있었죠. 그런데도 누가 물어볼 때까지 입을 다물고 있었습니다.

3주 뒤에야 질문이 왔습니다. 그때는 이미 손쓰기 어려운 상태였고요.

그때 배운 건 단순합니다. 내가 먼저 상황을 알리지 않으면, 사람들은 문제가 터지기 전까지 다 잘되고 있다고 믿습니다. 그리고 문제가 터지면 “왜 진작 말하지 않았느냐"는 소리를 듣게 되죠.

‘물어보면 답하기’의 함정

#

대부분의 사람은 반응형으로 소통합니다. 메일이 오면 답장하고, 업데이트를 물어보면 알려주고, 버그 제보가 오면 고칩니다.

언뜻 효율적으로 보입니다. 불필요한 정보로 누구의 시간도 뺏지 않으니까요.

하지만 실제로는 “정보가 필요하면 나를 쫓아다니라"고 주변 사람들을 훈련시키는 셈입니다. 매니저는 프로젝트가 어떻게 되어 가는지 일부러 물어봐야 하고, 다른 팀은 내 변경이 자기들에게 영향을 주는지 직접 확인해야 하고, 경영진은 리스크가 있는지 캐물어야 합니다.

실력 있는 엔지니어일수록 여기서 발목을 잡히는 걸 많이 봤습니다. 훌륭한 시스템을 만들어도 뭔가 고장 나기 전까지는 아무도 모릅니다. 어려운 문제를 풀어도, 누군가 불평한 다음에야 알려지고요.

한 시니어 개발자가 핵심 결제 시스템 리팩토링에 2주를 쏟은 적이 있습니다. 아름다운 코드였고, 처리 시간을 절반으로 줄였습니다. 그런데 6개월 뒤 누군가 다른 문제를 디버깅하다가 우연히 발견하기 전까지, 아무도 그 사실을 몰랐습니다. 그 많은 작업이 전부 보이지 않는 곳에 묻혀 있었던 거죠.

같은 팀의 다른 엔지니어는 뭔가 배포할 때마다 짧은 공유 글을 올렸습니다. “API 지연 시간 200ms 줄였습니다. 방법은 이렇습니다.” 다섯 문장, 가끔 차트 하나. 이 사람이 뭘 하는지는 모두가 알고 있었습니다. 승진은 누가 했을까요?

둘의 차이는 실력이 아니라 알리는 타이밍이었습니다.

말하지 않으면 실제로 벌어지는 일

#

“물어볼 때까지 기다리기"가 현장에서 어떤 모습인지 구체적으로 써 보겠습니다.

이틀로 잡은 작업이 사흘째입니다. 사흘은 더 걸릴 게 뻔합니다. 지금 말하시겠습니까, 아니면 내일 스탠드업에서 누가 물어볼 때까지 기다리시겠습니까?

기다리면 이렇게 됩니다. 매니저는 오늘 끝난다는 전제로 계획을 짰고, QA팀은 내일 테스트 일정을 잡았고, PM은 고객에게 금요일 출시라고 말해 뒀습니다. “생각보다 오래 걸리고 있습니다” 한마디에 들어가는 30초를 아낀 대가로, 모두가 허둥지둥 일정을 다시 짜야 합니다.

이런 경우도 있죠. 인증 방식을 바꾸는 중인데, 모바일 앱이 토큰 형식에 의존한다는 걸 알고 있습니다. 지금 모바일팀에 메시지를 보내시겠습니까, 아니면 알아차리는지 두고 보시겠습니까?

가만히 있으면 다음 주에 앱이 배포되고, 프로덕션에서 터집니다. 그쪽 팀은 몇 시간을 디버깅한 끝에야 내 변경을 찾아냅니다. 이렇게 해서 “아무 예고 없이 프로덕션을 깨뜨린 사람"이 완성됩니다.

이런 일은 늘 일어납니다. 그리고 원인은 언제나 같습니다. 누군가 알고 있었는데, 말하지 않았다는 것.

그럼 어떻게 해야 하나

#

묻기 전에 먼저 알리면 됩니다. 전부 다가 아니라, 상대에게 필요한 것만요.

제가 먼저 말하기로 정해 둔 상황은 대략 이렇습니다.

일정이 밀릴 때. 닷새로 잡았는데 사흘이 지났고 진행률은 30% 남짓. 지금 바로 메시지를 보냅니다. “생각보다 오래 걸리고 있습니다. 5일이 아니라 8~10일이 될 것 같습니다. 범위를 줄일까요, 마감을 미룰까요?”

스탠드업을 기다리지 않습니다. 누가 물어볼 때까지 기다리지 않습니다. 아는 순간 알립니다.

기술적인 결정을 내렸을 때. MySQL 대신 Postgres를 골랐다, GraphQL 대신 REST로 갔다, API에 필수 필드를 추가했다.

결정한 사람 눈에는 국지적인 선택으로 보여도, 누군가는 거기에 의존하고 있습니다. 짧은 메모면 충분합니다. “참고로 유저 엔드포인트에 이메일 검증을 필수로 바꿉니다. 목요일 반영 예정입니다. 문제될 것 같으면 알려 주세요.”

리스크가 보일 때. 데이터베이스가 예상보다 빨리 커지고 있다, 부하가 걸리면 API가 느려진다, 새 기능은 돌아가지만 코드가 지저분해서 유지보수가 힘들 것 같다.

문제가 될 때까지 기다리지 말고, 고칠 여유가 있을 때 깃발을 듭니다. “검색 엔드포인트 응답 시간이 조금씩 나빠지고 있습니다. 아직 급하진 않지만, 다음 스프린트에서 캐싱 추가를 검토하면 좋겠습니다.”

정기적인 업데이트. 저는 금요일마다 이해관계자들에게 메일을 보냅니다. 10분이면 씁니다. 이번 주에 나간 것, 다음 주에 할 것, 걱정되는 것. 이 세 가지뿐입니다.

대부분의 주는 지루한 내용입니다. 그게 핵심이에요. 지루하다는 건 서프라이즈가 없다는 뜻이니까요. 그리고 정말 무슨 일이 생겼을 때는, 계속 공유해 온 덕분에 상대가 이미 맥락을 알고 있습니다.

알려야 할 대상이 두셋을 넘는 프로젝트라면, 누가 어떤 업데이트를 얼마나 자주, 누구에게서 받는지를 한 페이지짜리 프로젝트 커뮤니케이션 계획으로 적어 둡니다.

왜 다들 안 하는 걸까

#

변명이라면 다 압니다. 저도 대부분 써 봤거든요.

“귀찮게 하고 싶지 않아서요.” 귀찮게 하는 게 아닙니다. 오히려 상대가 나를 귀찮게 해야 할 수고를 덜어 주는 겁니다. 매니저 입장에서는 상황 파악용 미팅을 잡는 것보다 두 문장짜리 업데이트를 읽는 쪽이 훨씬 낫습니다.

“틀리면 어떡하죠?” 정정하면 됩니다. “지난번에 8일 걸린다고 한 건, 6일 만에 끝났습니다. 다시 일정대로입니다.” 좋은 소식에 화내는 사람은 없습니다.

“일 못하는 사람처럼 보이기 싫어서요.” 실제로는 반대입니다. 예고 없이 마감을 놓치는 쪽이 훨씬 무능해 보입니다. 지연을 미리 알리는 사람은 리스크를 관리하는 사람으로 보이죠.

“너무 바빠서요.” 세 문장짜리 메일을 못 쓸 만큼 바쁜 사람은 없습니다. 정말 그렇게 바쁘다면, 말 안 해서 생긴 사고를 수습할 여유는 더더욱 없을 겁니다.

먼저 말하지 않는 진짜 이유는 어색하고 불편해서입니다. 조용히 있으면서 잘되기를 바라는 쪽이 편하니까요. 하지만 바람은 계획이 아니고, 침묵은 프로다운 태도가 아닙니다.

그냥 반응만 하면 되는 순간

#

모든 걸 미리 알릴 수는 없습니다. 예고보다 즉각 대응이 필요한 상황도 있죠.

장애가 나면 일단 고칩니다. 진행 상황은 공유하되, 완벽한 포스트모템을 쓸 때까지 지혈을 미루면 안 됩니다.

누군가 내 코드 리뷰를 기다리며 막혀 있다면, 그냥 리뷰하면 됩니다. 그 사람에게 필요한 건 주간 업데이트가 아니라 한 시간 안의 언블록입니다.

슬랙에 급한 질문이 올라오면 바로 답합니다. 금요일 요약까지 기다리게 하지 않습니다.

정리하면, 당장 필요한 일에는 반응적으로 답하고, 나머지는 전부 선제적으로 먼저 알리는 겁니다.

실제로 달라진 것들

#

이걸 꾸준히 하면서 바뀐 점들입니다.

우선 회의가 줄었습니다. 무슨 일이 벌어지는지 이미 알고 있으면, 알아내려고 회의를 잡지 않으니까요. 제 캘린더는 주 25시간이 넘던 회의가 15시간 정도로 줄었습니다.

서프라이즈도 줄었습니다. 문제를 미리 알려 두면, 그건 더 이상 ‘문제’가 아니라 ‘관리되고 있는 사안’이 됩니다. 2주 전에 공유해 둔 리스크에 패닉하는 사람은 없습니다.

그리고 가장 큰 변화는 신뢰입니다. 묻지 않아도 꾸준히 상황을 알려 주면, 사람들은 이 사람에게 맡겨도 되겠다고 믿기 시작합니다. 그러면 더 큰 책임과 더 재미있는 일이 돌아옵니다.

앞에서 말한 승진도, 물론 일을 잘한 덕이 컸지만, 그보다는 좋은 결과물을 굳이 캐묻지 않아도 알아야 할 사람들이 알게 만든 덕이 더 컸다고 생각합니다.

어떻게 시작하나

#

이번 주에 하고 있는 일 하나를 골라서, 누가 묻기 전에 짧은 업데이트를 보내 보세요.

매니저에게라면 이렇게요. “API 리팩토링 순조롭습니다. 절반쯤 끝났고, 주말 전 완료 예정입니다.”

다른 팀에게라면. “유저 세션 처리 방식을 바꿨습니다. 영향은 없을 텐데, 인증 쪽에서 이상한 동작이 보이면 알려 주세요.”

우리 팀에게라면. “프로덕션 그 버그 고쳤습니다. 원인은 캐시 레이어의 레이스 컨디션이었고, 재발하지 않게 테스트도 추가했습니다.”

두세 문장 쓰고 전송 버튼을 누르면 끝입니다.

결과는 보통 둘 중 하나입니다.

1. 고맙다는 반응이 오고, 나도 정보를 끌어안고 있던 불안에서 벗어난다
2. 답이 없다. 그래도 상대는 이미 알고 있으니 더 신경 쓸 필요가 없다

몇 번 해 보면 자동이 됩니다. 뭔가 끝내면 관련된 사람들에게 알리고, 문제를 발견하면 깃발을 들고, 결정을 내리면 공유하고.

몇 주 지나면 사람들이 더 이상 상황을 묻지 않습니다. 이미 알고 있으니까요. 그때부터 많은 게 수월해집니다.