현업에서 기획 역할을 처음 맡으면 — 도구를 찾기 전에 정해야 할 업무 R&R 세 가지

현업팀에서 기획 역할을 새로 맡아 개발팀과 협업하게 된 분에게서 질문 일곱 개를 받았습니다. 업무 히스토리는 어떤 형식으로 남기는지, 진척은 무슨 툴로 보는지, 부서별 요청은 어떻게 정리하는지, 개발팀에 넘길 때 양식은 어떻게 하는지, 역할 경계는 어디까지인지, 회신이 안 오면 어떻게 하는지. 마지막엔 "가감 없는 조언도 듣고 싶다"고 적혀 있었습니다.

하나하나는 다 다른 질문처럼 보이는데, 모아 놓고 읽으니 결국 같은 걸 묻고 있더군요. 어디까지가 내가 정해도 되는 일인가.

업무 R&R 을 정한다고 하면 보통 조직도에 선을 긋는 일을 떠올립니다. 그런데 요청이 모이는 자리에 앉은 사람에게는 그것보다, 내가 무엇을 책임지는 사람인지를 스스로 정하고 그걸 주변이 알게 하는 쪽이 훨씬 급합니다. 순서는 접수, 판단, 근거 세 가지입니다. 도구는 그다음에 골라도 늦지 않습니다.

질문 일곱 개가 묻는 것은 결국 하나다

받은 질문을 옆 칸에 다시 적어 보면 금방 보입니다.

적힌 질문	실제로 궁금한 것
애매한 요청은 누가 판단하나	이걸 내가 정해도 되나, 위에 올려야 하나
기한 내 미회신 시 처리 방안	상대가 답을 안 줄 때 그냥 진행해도 되나
우선순위 충돌 시 조율 방법	누군가의 순서를 미루는 결정을 내가 해도 되나
기획 히스토리 관리 형식	나중에 "왜 그랬냐"고 물으면 뭘 보여주나
부서별 요청 접수·정리	들어온 걸 놓치지 않으려면 어떻게 하나

일곱 개 중에 도구를 묻는 건 하나뿐입니다. 나머지는 전부 사람과 권한과 합의에 관한 이야기입니다. 그런데 이 자리에 처음 앉으면 대개 협업 툴부터 찾아보게 되거든요. 저도 그랬습니다. 순서가 뒤집히면 결국 도구가 가진 기능이 우리 팀의 R&R 을 대신 정해 버립니다.

1. 접수 — 놓치는 순간이 제일 아프다

이 자리에서 제일 빨리 잃는 건 "일 잘한다"는 평가가 아니라, 저 사람한테 말하면 적어도 없어지지는 않는다는 믿음입니다. 야속하게도 잘 처리한 서른 건은 아무도 기억 못 하고, 흘린 한 건은 오래 기억됩니다. 그래서 접수를 제일 앞에 둡니다.

들어오는 길은 여럿이어도, 쌓이는 곳은 하나로

요청은 메일로도 오고 메신저로도 오고 복도에서 마주쳤을 때도 들어옵니다. "앞으로는 메일로만 주세요"라고 해 봐야 잘 지켜지지 않습니다. 상대 입장에서는 굳이 그럴 이유가 없으니까요. (저도 되도록 메일로 주십사 부탁드리는 편입니다만, 거래처나 상급자분들께 그렇게 요청드리기가 난해할 때가 많잖아요.)

그래서 창구를 통일하려고 애쓰는 대신, 받는 쪽에서 한 곳에 모읍니다. 복도에서 들은 이야기도 자리에 돌아와 같은 목록에 적어 두는 겁니다. 들어오는 통로는 여럿이어도 쌓이는 자리는 하나면 됩니다.

적을 때는 네 가지만 챙기면 충분합니다. 누가 요청했는지, 언제 받았는지, 요청 내용 한 줄, 지금 상태. 처음부터 항목을 열 개쯤 만들어 두면 대개 사흘쯤 쓰다가 손이 안 가게 되더라고요.

받았다는 말은 하루 안에

처리가 늦어지는 건 대부분 이해받습니다. 그런데 받았다는 말이 없으면 기다리는 쪽은 "오고 있는 건가, 잊힌 건가, 다른 데 알아봐야 하나"를 혼자 판단해야 합니다. 그 불안이 결국 재촉 연락으로 돌아옵니다.

한 줄이면 됩니다. "받았습니다. 이번 주는 어렵고 다음 주 화요일까지 회신드리겠습니다." 같은 이야기를 업무 이메일 에티켓에서도 다뤘는데, 요지는 하나입니다. 처리는 늦어져도 괜찮지만 접수 확인만큼은 하루 안에, 날짜를 적어서 보냅니다.

2. 판단 — 요청을 세 칸으로 나눈다

"애매한 요청은 누가 판단하느냐"가 제일 자주 나오는 질문입니다. 여기에 바로 답하기는 어렵고, 대신 판단 자체를 세 종류로 나눠 두면 애매한 게 많이 줄어듭니다.

칸	어떤 요청인가	내가 하는 일
내가 정한다	이미 정해진 기준 안에서 답이 나오는 것	바로 답하고 기록만 남긴다
올린다	비용·일정·우선순위가 달라지는 것	선택지 두세 개로 정리해서 올린다
돌려보낸다	요청한 쪽이 정했어야 할 것이 비어 있는 것	무엇이 비었는지 짚어서 돌려보낸다

세 번째 칸이 제일 어렵습니다. 요청자가 정하지 않고 넘긴 걸 가운데 있는 사람이 대신 정해 주면 그 자리는 매끄럽게 넘어갑니다. 고마워하기도 하고요. 그런데 나중에 결과가 기대와 다르면, 그 결정을 누가 했는지 아무도 모르는 상태가 됩니다. 돌려보내는 건 일을 미루는 게 아니라 결정을 원래 주인에게 돌려놓는 일이라고 생각하면 마음이 좀 편해집니다.

기준은 내가 정하고, 먼저 알려 둔다

여기서 중요한 건 기준을 어떻게 짜느냐보다 언제 알리느냐입니다.

요청이 들어온 다음에 "이건 제가 정할 수 있는 게 아니라서요"라고 하면, 듣는 쪽에서는 빠져나가려는 걸로 받아들이기 쉽습니다. 그런데 몇 주 전에 미리 공유해 둔 기준을 함께 보면서 같은 말을 하면 그냥 절차가 됩니다. 문장은 똑같은데 시점 하나로 전혀 다르게 들립니다.

그래서 기준은 가능한 한 일찍 알려 둡니다. 알려 두는 순간부터 그건 권한처럼 작동합니다. 누가 따로 임명해 주지 않아도 말이죠.

3. 근거 — 두 달 뒤의 나를 위해 남긴다

"기획 히스토리를 어떤 형식으로 남기느냐"는 질문에는 작은 함정이 하나 있습니다. 형식부터 정하면 대개 문서를 만들게 되는데, 문서는 바빠지는 순간 멈추거든요. 두 달쯤 지나서 열어 보면 마지막 수정일이 한참 전인 경우가 많습니다.

남겨야 하는 건 문서라기보다 결정입니다. 한 줄이면 충분합니다.

10/14 · 목록에서 상태 변경은 담당자와 관리자만 — 영업팀 요청, 개발 수용. 담당자가 아닌 사람에게는 칸 자체를 숨기기로 함.

진행 상황은 두 달 뒤에 아무도 안 봅니다. 대신 두 달 뒤에 꼭 한 번은 나오는 질문이 "이거 왜 이렇게 됐죠"인데, 그때 필요한 게 결정 한 줄과 날짜와 누가 요청했는지입니다. 이걸 쌓는 방법은 의사결정 기록 쓰는 법에 따로 정리해 뒀습니다.

개발팀에 넘기는 요청의 형식도 비슷한 맥락입니다. 어디까지 적어야 하는지, 무엇은 안 적어도 되는지는 현업의 기획과 개발의 기획이 어떻게 다른지에서 다뤘고, 그 글에 현업에서 바로 쓸 수 있는 작성 지침을 내려받을 수 있게 붙여 뒀습니다.

도구는 세 번째에 고른다

트래킹 툴을 먼저 고르면, 그 도구가 가진 상태값이 그대로 우리 팀의 일하는 방식이 됩니다. 예를 들어 도구에 "검토 중"이라는 칸이 있으면 애매한 건들이 전부 거기 쌓입니다. 그리고 몇 주 지나면 그 칸에 들어 있는 건의 주인이 누구인지 아무도 모르게 됩니다.

접수와 판단과 근거, 이 세 가지가 먼저 정해져 있으면 도구는 그걸 담는 그릇일 뿐이라 스프레드시트 한 장으로도 돌아갑니다. 반대로 세 가지가 흐릿한 상태에서는 아무리 좋은 도구를 써도 같은 질문이 반복됩니다. 도구를 바꿔서 해결된 R&R 문제는 저는 아직 못 봤습니다.

그러니 시작은 작게 하는 걸 권합니다. 한 장짜리 표에 요청자, 받은 날, 요청 내용, 상태, 다음에 할 일 다섯 칸. 이게 두 달을 버티면 그때 도구를 고르면 됩니다. 두 달을 못 버티면 도구를 바꿔도 비슷합니다.

진척은 묻기 전에 먼저 알린다

"진행 상태를 어떻게 트래킹하느냐"는 질문 뒤에는 대개 "요청자들이 자꾸 물어본다"가 붙어 있습니다. 그런데 자꾸 묻는 이유는 진행이 느려서가 아니라 보이지 않아서인 경우가 많습니다. 보이면 덜 묻습니다.

주 1회, 요청자별로 한 줄이면 충분합니다. 길게 쓰면 다음 주에 안 쓰게 되니까요.

지난주 요청하신 3건 — 2건은 개발 검토 중이고 10/20까지 회신 예정입니다. 1건은 확인 요청드린 상태입니다.

여기서 하나만 더 보태면, 막힌 건을 미뤄 두지 않는 게 좋습니다. 이 자리에서 제일 비싸게 치르는 실수는 늦는 것 자체가 아니라 늦는다는 사실을 늦게 말하는 쪽이더라고요. 늦는다는 소식도 일찍 전하면 일정 조정으로 끝나는데, 늦게 전하면 수습할 일이 생깁니다.

반대 방향도 비슷합니다. 개발팀에 확인을 요청해 놓고 답이 올 때까지 조용히 기다리면, 요청자 눈에는 아무 일도 안 일어나는 것으로 보입니다. 대기 중이라는 것도 하나의 상태니까, 목록에 적고 같이 알려 주면 좋습니다.

정한 업무 R&R 은 알려야 작동한다

여기까지 정해 놓고 혼자만 알고 있으면 사실 별 효과가 없습니다. 이 자리의 권한은 임명장에서 나오기보다 예측 가능성에서 나옵니다. 저 사람한테 요청하면 대략 어떻게 흘러가는지를 주변이 알게 되는 순간부터 작동하기 시작합니다.

한 장이면 됩니다. 요청은 어디로 보내면 되는지, 접수 확인은 언제쯤 오는지, 어떤 건은 바로 답을 받고 어떤 건은 위로 올라가는지, 회신이 없으면 어떻게 되는지. 이 네 가지를 적어서 공유해 두고, 요청을 받을 때마다 그 링크를 같이 붙여 보냅니다.

그리고 석 달쯤 지나면 한 번 고칩니다. 처음 그어 둔 세 칸은 거의 틀립니다. "내가 정한다"에 넣었던 것 중 몇 개는 올렸어야 했고, "올린다"에 넣었던 것 중 몇 개는 그냥 내가 정해도 되는 일이었을 겁니다. 그 조정이 이 역할에서 실제로 배우는 부분입니다. 한 번 긋고 끝나는 선이 아니라 몇 번 고쳐 가면서 자리를 잡는 쪽에 가깝습니다.

회신이 없을 때, 우선순위가 부딪칠 때

이 자리에 늘 따라다니는 두 가지 상황인데, 해법이 비슷합니다. 일이 벌어진 다음에 통보하는 대신, 벌어지기 전에 규칙을 알려 두는 겁니다.

• 회신이 없을 때 — 요청을 보낼 때 "○일까지 회신이 없으면 ○○로 보고 진행하겠습니다"를 같이 적어 둡니다. 나중에 "답을 안 주셔서 그냥 진행했습니다"라고 하면 통보처럼 들리지만, 미리 적어 둔 대로 하면 서로 합의한 셈이 됩니다. 다만 되돌리기 어려운 일에는 이 규칙을 쓰지 않는 게 안전합니다.
• 우선순위가 부딪칠 때 — 순서를 내가 정하지 않습니다. 지금 목록을 그대로 보여주고 요청한 분들이 고르게 합니다. "A를 먼저 하면 B가 다음 주로 밀립니다. 어느 쪽으로 할까요?" 대신 정해 주면 밀린 쪽의 아쉬움이 이쪽으로 오는데, 보여주고 고르게 하면 그 결정은 요청한 쪽의 것이 됩니다.

그런데 기한이 다가오는데 조용할 때, 미리 적어 둔 규칙을 바로 꺼내는 건 조금 서늘합니다. 그 사이에 한 단계를 두면 훨씬 부드럽습니다. 같은 메일에 Gentle reminder 한 줄을 붙여서 한 번 더 보내는 방법입니다.

Gentle reminder — 아래 건 확인 부탁드립니다. ○일까지 회신 주시면 일정에 맞출 수 있습니다.

말 그대로 "부드러운 알림"인데, 재촉이라기보다 "혹시 묻혔을까 싶어 다시 올립니다"에 가깝게 읽힙니다. 앞에서 말씀드린 것처럼 거래처나 상급자분들께는 재촉이 어려운데, 이 한 줄이 그 어색함을 꽤 덜어 줍니다. 보낸 기록이 남는 것도 도움이 됩니다. 나중에 미리 알려 둔 규칙대로 진행하게 되더라도 "말씀드렸는데 회신이 없어서"가 아니라 "두 번 안내드렸는데 회신이 없어서"가 되니까요.

못 하는 일을 미루다 보면 결국 수습이 더 커집니다. 그 말을 어떻게 꺼내면 좋은지는 데드라인 협상에 정리해 뒀습니다.

묻지 않으셨지만 — 제가 겪어 본 함정 둘

질문 마지막에 "가감 없는 조언"이라고 적혀 있어서, 그 자리에 두 가지를 놓겠습니다.

첫째, 모르는 걸 아는 것처럼 답하지 않는 겁니다. 개발팀과 요청자 사이에 있다 보면 양쪽 질문이 다 이쪽으로 옵니다. "이거 되나요?"라는 물음에 감으로 "아마 될 것 같은데요"라고 답하는 순간, 그 한마디가 요건처럼 돌아다니기 시작합니다. 몇 주 뒤에 "된다고 하셨잖아요"로 돌아오고요. 그 자리에서 할 수 있는 답은 "확인해서 오늘 중으로 회신드리겠습니다" 정도면 충분합니다. 모른다고 말해서 신뢰가 깎이는 경우는 생각보다 드물고, 틀린 답을 줘서 깎이는 경우가 훨씬 많습니다.

둘째, 다 받아 주는 사람이 되지 않는 겁니다. 앞의 세 칸 중에서 "돌려보낸다"가 계속 비어 있으면, 가운데서 조율하는 자리가 아니라 그냥 지나가는 통로가 됩니다. 통로에는 권한이 안 생기고 일만 쌓이고요. 요청한 쪽이 정했어야 할 걸 대신 정해 주는 친절이 반년쯤 쌓이면, 그 결정들의 책임이 전부 이쪽 앞으로 옵니다. 돌려보내는 건 불친절이라기보다 이 역할에 원래 포함된 일입니다.

정리

• 접수 — 들어오는 통로는 여럿이어도 쌓이는 곳은 하나로. 처리가 늦어지는 건 괜찮지만 받았다는 말은 하루 안에 합니다.
• 판단 — 요청을 내가 정할 것, 올릴 것, 돌려보낼 것 세 칸으로 나눠 두고 기준을 먼저 알립니다. 같은 말도 일이 생긴 다음에 하면 회피로 들리고, 미리 정해 두면 절차로 들립니다.
• 근거 — 진행 상황보다 결정을 남깁니다. 두 달 뒤에 돌아오는 질문은 "이거 왜 이렇게 됐죠" 하나입니다.

이번 주에 딱 하나만 해 본다면, 판단의 세 칸을 종이에 그려 놓고 지난달 요청 열 건을 나눠 넣어 보시길 권합니다. 내가 이미 정하고 있던 결정이 뭐였는지, 그중에 정하지 말았어야 할 게 뭐였는지가 꽤 선명하게 보입니다. 업무 R&R 은 거창한 문서가 아니라 보통 그 한 장에서 시작합니다.