🤔 왜 협업은 성과로 기록되지 않을까
마케터의 하루를 떠올려 보세요. 디자이너에게 배너 시안을 요청하고, 개발자에게 랜딩 페이지 트래킹 코드를 부탁하고, 카피 톤을 두고 세 번쯤 핑퐁을 주고받습니다. 캠페인이 나가기까지 들어간 이 모든 조율이, 정작 연말 성과 평가서에는 "○○ 캠페인 집행 (CTR 1.8%)" 한 줄로 압축됩니다.
문제는 여기 있습니다. 그 한 줄에는 당신이 만든 결과만 있고, 당신이 사람을 움직인 과정은 없습니다. 평가자는 결과 숫자만 보고는 "이 사람이 운이 좋았나, 실력이 좋았나"를 구분하지 못합니다. 그리고 직급이 올라갈수록 평가의 무게는 '실행'에서 '리딩'으로 옮겨갑니다.
💡 핵심 문제
협업은 대부분 슬랙·메신저·회의실에서 휘발됩니다. 결과물은 파일로 남지만, "내가 어떻게 그 결과물을 끌어냈는가"는 누구도 기록하지 않습니다. 기록되지 않은 리딩은 평가에서 존재하지 않은 일이 됩니다.
⚖️ '소통'과 '리딩'은 다르다
많은 마케터가 협업 성과를 "커뮤니케이션을 원활하게 했다"고 적습니다. 하지만 '소통'은 누구나 하는 기본값이고, '리딩'은 결과를 바꾼 개입입니다. 평가받는 것은 후자입니다. 둘의 차이를 분명히 보세요.
• "디자인 시안 요청드렸습니다"
• "개발팀에 일정 공유함"
• "회의에 참석해 의견 전달"
• 정보를 전달하는 데서 끝남
• "디자인 우선순위를 재조정해 마감 사수"
• "개발 리소스 충돌을 사전 발견·중재"
• "막힌 의사결정을 데이터로 풀어냄"
• 정보를 움직여 결과를 만듦
📌 리딩의 정의는 직책이 아닙니다. "내가 없었다면 이 협업이 더 느려졌거나, 더 나쁜 결과가 나왔을 것"을 증명할 수 있다면, 그건 직급과 무관하게 리딩입니다.
🧩 협업 기록 프레임워크: CARE
협업 한 건을 끝낼 때마다 5분만 투자해 네 가지를 남기세요. 이 네 글자를 채우면, 휘발될 뻔한 소통이 평가서에 쓸 수 있는 '리딩 사례'로 굳어집니다.
C
Context — 어떤 상황이었나
협업의 배경과 제약을 한 줄로. 예: "출시 D-3, 디자인 시안 2개 중 의사결정 지연으로 일정 위험." 상황의 난이도가 곧 리딩의 가치입니다.
A
Action — 내가 무엇을 했나
'전달'이 아니라 '개입'을 적습니다. 예: "두 시안의 예상 CTR을 과거 데이터로 비교해 A안을 근거로 제시, 30분 만에 결정 확정." 동사가 능동적일수록 좋습니다.
R
Result — 결과가 어떻게 바뀌었나
개입이 만든 차이를 수치나 사실로. 예: "일정 지연 0일, 예정대로 출시." 절감한 시간, 막은 리스크도 훌륭한 결과입니다.
E
Evidence — 무엇으로 증명하나
근거의 위치를 남깁니다. 예: "결정 슬랙 스레드 링크, 시안 비교표 파일명." 평가 시즌에 찾아 헤매지 않으려면 그 자리에서 기록해야 합니다.
💡 팁 — CARE는 캘린더에 협업 이벤트를 기록할 때 그 메모란에 그대로 채우면 됩니다. 협업이 일어난 '날짜'에 붙어 있어야 나중에 시계열로 복기할 수 있습니다.
🔄 Before / After: 기록이 바뀌면 평가가 바뀐다
같은 협업, 같은 사람. 기록 방식만 달라졌을 뿐인데 평가자가 읽는 메시지는 완전히 달라집니다. 세 가지 흔한 상황을 비교해 보세요.
상황 ① 디자인팀과의 시안 조율
❌ BEFORE
디자인팀과 협업하여 배너 제작을 완료함.
✅ AFTER
시안 의사결정이 이틀째 막힌 상황(C)에서, 과거 캠페인의 소재별 CTR 데이터로 A안의 근거를 제시(A). 30분 회의로 결정을 확정해 출시 일정을 사수함(R). — 결정 슬랙 스레드 보관(E)
상황 ② 개발팀과의 트래킹 설정
❌ BEFORE
개발팀에 트래킹 코드 삽입을 요청함.
✅ AFTER
개발 일정과 캠페인 오픈일이 충돌할 위험을 사전에 발견(C). 측정에 꼭 필요한 이벤트 3개로 요구사항을 압축해 개발 부담을 줄이고 일정을 맞추도록 조율(A). 누락 없는 전환 데이터 확보로 캠페인 ROAS 산출이 가능해짐(R).
상황 ③ 부서 간 의견 충돌 중재
❌ BEFORE
회의에서 디자인팀과 개발팀의 의견을 조율함.
✅ AFTER
디자인 완성도와 개발 일정이 대립하던 상황(C)에서, '핵심 화면 우선 완성 → 부가 요소 단계 배포'라는 절충안을 제안(A). 양 팀이 합의해 마감 갈등 없이 출시했고, 이후 같은 방식이 팀 내 표준 프로세스로 채택됨(R).
📌 AFTER 문장의 공통점: 상황의 어려움 → 나의 구체적 판단 → 바뀐 결과가 모두 들어 있습니다. 평가자는 이 흐름에서 '실력'을 읽습니다.
🚫 협업 기록에서 절대 하면 안 되는 것
잘못된 협업 기록은 안 쓰느니만 못합니다. 평가자에게 나쁜 인상을 주거나, 동료와의 관계를 해칠 수 있기 때문입니다. 다음 네 가지는 피하세요.
1
동료의 공을 가로채기
디자이너가 만든 결과물을 "내가 만들었다"고 적는 순간 신뢰를 잃습니다. 당신의 기여는 '끌어낸 것'이지 '만든 것'이 아닙니다. "함께"를 분명히 하되 내 개입을 구체화하세요.
2
갈등을 '누구 탓'으로 적기
"개발팀이 일정을 못 지켜서"는 기록이 아니라 험담입니다. 갈등은 항상 '내가 그 상황을 어떻게 풀었나'의 관점으로만 적습니다. 사람이 아니라 문제를 기록하세요.
3
형용사로 도배하기
"적극적으로", "원활하게", "긴밀하게"는 아무것도 증명하지 못합니다. 형용사 대신 행동과 숫자를 넣으세요. "긴밀하게 협업" → "주 2회 싱크로 일정 리스크 사전 점검".
4
나중에 몰아서 기억으로 쓰기
평가 시즌에 6개월치를 기억으로 복원하면, 가장 강렬했던 사건만 남고 나머지는 사라집니다. 협업은 일어난 그 주에 짧게라도 기록해야 누적됩니다.
⚠️ 특히 주의 — 협업 기록은 언젠가 동료가 볼 수도 있다는 전제로 쓰세요. 내가 떳떳하게 공유할 수 있는 기록만이 진짜 자산이 됩니다.
✅ 제출 전 협업 성과 체크리스트
성과 평가서에 협업 항목을 적기 전, 아래 항목을 통과하는지 확인하세요. 하나라도 'No'라면 그 문장은 아직 '소통'에 머물러 있습니다.
✓
상황(C)이 들어 있나? — 그 협업이 왜 어려웠는지가 한 줄로 보이는가
✓
능동 동사로 시작하나? — '요청', '공유'가 아닌 '조율', '제안', '중재', '결정'으로 쓰였는가
✓
바뀐 결과(R)가 있나? — 절감 시간, 막은 리스크, 사수한 일정 등 차이가 명시됐는가
✓
근거(E)를 찾을 수 있나? — 스레드 링크나 파일이 어디 있는지 적혀 있는가
✓
동료가 봐도 괜찮은가? — 공을 독점하거나 남 탓하는 표현이 없는가
✦ 핵심 정리
-
✦
협업의 '결과'는 파일로 남지만 '리딩 과정'은 기록하지 않으면 사라진다.
-
✦
'소통'은 기본값, '리딩'은 결과를 바꾼 개입. 평가받는 것은 후자다.
-
✦
CARE(상황·행동·결과·근거)를 협업 직후 5분간 기록하면 휘발이 멈춘다.
-
✦
공 가로채기·남 탓·형용사 도배·몰아쓰기는 협업 기록을 망친다.
❓ 자주 묻는 질문
Q
저는 팀장이 아닌데 '리딩'이라고 써도 되나요?
A
됩니다. 리딩은 직책이 아니라 개입의 결과입니다. 의사결정을 끌어내거나, 막힌 협업을 풀었다면 직급과 무관하게 리딩입니다. 오히려 비관리자가 보여주는 리딩은 승진 근거로 더 강력합니다.
Q
협업이 결국 실패했어도 기록할 가치가 있나요?
A
가치가 있습니다. 단 '결과(R)'를 "무엇을 배웠고 다음엔 어떻게 바꿨는가"로 전환해 적으세요. 실패에서 프로세스 개선을 끌어낸 기록은 회복탄력성과 학습 역량의 증거가 됩니다.
Q
매번 CARE를 다 쓰면 너무 번거롭지 않나요?
A
모든 협업이 아니라 '리딩이 있었던 협업'만 적으면 됩니다. 단순 전달 업무는 건너뛰세요. 실제로 기록할 만한 리딩은 한 주에 한두 건이고, 각 5분이면 충분합니다.
마케터 성과 관리 시리즈
다음 글도 함께 읽어보세요