가는 길엔 치프 오브 스태프 옆자리에 앉아 취미 찾기에 대한 이야기를 나눴습니다. 요즘처럼 바쁜 생활 속에서 혼자서도 즐길 수 있는 취미를 찾기가 생각보다 어렵다는 얘기가 나왔고, 자연스럽게 대학 시절 이야기로 흘러갔습니다. 알고 보니 그분은 원래 3D 아트를 즐겨 만들던 아티스트였다고 하더군요. 다만 계속 작품을 만들어내야 한다는 부담이 본인의 생활과는 잘 맞지 않았다고 합니다. 그래서 저는 “그럼 우리 좀 삭막한 사무실에 작품 하나 만들어주시죠"라고 농담을 던졌습니다. 하하

카페에 도착하자마자 우리 모두가 앉을 만큼 큰 테이블을 바로 찾았습니다. 서로에게 중요한 것들을 터놓고 이야기할 수 있어서 좋았습니다.

다들 서로의 의견을 존중해줬고, CEO와 진행자분이 매끄럽게 이끌어준 덕분에 다음 일정에 늦지 않게 마칠 수 있었습니다.

다음 일정은 위스키 증류소 방문이었습니다! 위스키를 꽤 좋아하는 저로서는, 평균보다 조금 더 아는 위스키 제조와 시음 지식을 뽐낼 완벽한 기회였죠. 투어 가이드분은 영어와 한국어를 오가며 설명하느라 애써 주셨습니다. 먼저 밀을 통에 넣고 불려서 당분을 뽑아내는 과정을 봤고, 이어서 며칠 정도 발효된 상태도 볼 수 있었습니다. 마지막은 증류기였는데, 커다란 물방울 모양 초콜릿처럼 생겼다는 설명이 딱 맞았습니다. 내부가 30도 가까이 돼서, 가이드분이 밖에 있는 저장고를 보러 가자고 했을 때 다들 살았다 싶었습니다.

저장고에는 다양한 나무로 만든 배럴이 천장까지 쌓여 있었습니다. 배럴 끝에 ‘고추장’이라고 적힌 것도 있었는데, 한국다운 퓨전이죠. 배럴에서 바로 뽑은 위스키를 맛볼 기회도 있었는데, 도수가 무려 60% 정도! 다들 목이 타들어갔습니다.

마무리로는 서로 다른 배럴에서 숙성된 위스키들, 그러니까 최종 제품들을 시음했습니다. 진도 마셔봤는데, 이건 좀 아쉬운 선택이었습니다. 버섯 비슷한 향이 꽤 강했거든요.

하루를 마치고 밴을 타고 서울로 돌아와 바에 들러 조용히 한잔하고 각자 집으로 향했습니다. 하루에 참 많은 걸 했는데, 함께 즐기면서 서로에 대해서도 많이 알게 된 것 같습니다!

혹시 한국에서 일할 곳을 찾고 계신다면 저에게 연락 주세요!

이번 달부터 엔지니어링 팀의 매니저를 맡게 됐습니다. 소프트웨어 엔지니어에서 엔지니어링 매니저가 되면 무엇이 달라지는지에 대한 글을 쓰고 몇 주 만이네요. 아무도 미리 말해주지 않았던 건, 모든 일이 다 급해 보인다는 점입니다. 새로운 팀, 새로운 회사, 그리고 제가 오기 전부터 쌓여 있던 할 일 목록까지. 한꺼번에 다 할 수는 없으니, 먼저 세 가지부터 제대로 하기로 했습니다.

팀원 알아가기

#

모든 팀원과 1:1을 잡고 있습니다. 스프린트 얘기가 아니라 그 사람 자체에 대한 시간으로 만들려고 합니다. 커리어에서 뭘 원하는지, 요즘 뭐가 답답한지, 내일 당장 바꿀 수 있다면 뭘 바꾸고 싶은지. 이 자리에서 제 역할은 대부분 입 다물고 듣는 겁니다. 신뢰는 첫 주에 쌓이지 않지만, 첫 주에 잃을 수는 있거든요.

일하는 방식도 사람마다 다릅니다. 구체적인 방향을 원하는 사람이 있고, 맡겨둘 때 제일 잘하는 사람도 있죠. 이걸 반대로 대하면 서로 힘들어집니다. Camille Fournier의 “The Manager’s Path"가 이 부분을 잘 다룹니다. 결국 공감하고 제대로 듣는 게 매니지먼트의 대부분이더군요.

왜 지금 이런 모습인지 이해하기

#

프로세스든 좀 이상해 보이는 아키텍처든, 다 과거 의사결정의 흔적입니다. 뭔가를 바꾸기 전에, 그동안 뭘 시도했고 뭐가 실패했고 회사가 진짜로 중요하게 여기는 게 뭔지 알고 싶습니다.

어느 회사나 의사결정이 실제로 어떻게 굴러가는지에 대한 암묵적인 규칙이 있습니다. 이걸 빨리 파악할수록 팀을 위해 해줄 수 있는 일이 많아집니다. Andrew Grove가 “High Output Management"에서 말하듯, 큰 그림을 스스로 이해하지 못하면 팀의 일을 거기에 맞출 수도 없습니다.

코드 읽기

#

이제 팀에서 코딩을 제일 잘할 필요는 없지만, 아키텍처와 아픈 부분, 기술 부채가 어디 묻혀 있는지는 알아야 합니다. 그래서 코드를 읽고, 배포 파이프라인을 들여다보고, “일주일이 통째로 생기면 뭘 고치고 싶어요?“라고 팀원들에게 물어보고 다닙니다. 이 질문의 답이 보통 가장 솔직한 로드맵입니다.

부수적인 효과도 있습니다. 프로세스만이 아니라 일 자체에 관심이 있다는 게 팀에 전해집니다.

그다음엔 비켜서기

#

기반이 잡히면 할 일은 단순합니다. 맥락을 만들어주고, 목표를 공유하고, 기술적인 판단은 팀에 맡기는 것. 매니저의 일은 모든 PR을 승인하는 게 아니라, 팀이 필요한 걸 갖추고 올바른 방향을 보고 있는지 확인하는 겁니다. Gene Kim의 “The Phoenix Project"도 같은 얘기를 합니다. 스스로 결정하는 팀이 위의 승인을 기다리는 팀보다 빠르게 움직이고 더 좋은 소프트웨어를 만듭니다.

신임 엔지니어링 매니저에게 도움이 되는 책

#

본문에서 언급한 세 권을 한곳에 모아 둡니다.

그 밖에 신임 엔지니어링 매니저가 읽을 책을 물으면 자주 언급되는 책으로 Will Larson의 “An Elegant Puzzle"과 Lara Hogan의 “Resilient Management"가 있습니다. 앞의 책은 팀 규모, 계획, 조직 설계 같은 시스템 쪽을 다루고, 뒤의 책은 팀원 알아가기, 기대치 분명히 하기, 잘 소통하기 같은 사람 쪽을 짧고 실용적으로 다룹니다.

여섯 달 뒤에 어떻게 됐는지 다시 써보겠습니다.

요즘 이 생각을 자주 하는 이유는 제가 직접 프로젝트를 리드하는 입장이 되면서 얼버무리고 싶은 유혹이 뭔지 몸으로 느끼고 있기 때문입니다. 회의에서 질문을 받고 다섯 명이 답을 기다리고 있을 때 “모르겠습니다"라고 하면 지는 기분이 들죠. 그런데 사실은 반대입니다. 대부분의 경우 그게 가장 강한 수입니다. 다만 다음에 뭘 할지, 그러니까 누구에게 물어볼지, 언제 답을 가져올지를 붙인다는 조건이 있습니다.

아는 척은 반드시 들킨다

#

소프트웨어는 변화가 너무 빨라서 모든 걸 머릿속에 담아둘 수 있는 사람이 없습니다. 그리고 엔지니어들은 아는 척을 놀라울 만큼 잘 알아챕니다. 한 번이라도 아는 척하다 들키면, 팀은 그다음부터 진짜 답까지 깎아서 듣기 시작합니다. 반대로 모르는 걸 인정하고 그 구멍을 직접 메우러 가는 매니저의 말은 신뢰를 얻습니다. 진짜 답인지 아닌지, 다들 듣고 구분할 줄 알거든요.

“모르겠습니다"는 답이 아니라 출발점

#

중요한 건 그다음입니다. “모르겠습니다"에서 끝나면 그냥 떠넘기기죠. 좋은 매니저는 거기서부터 더 나은 질문을 만들어 갑니다. “지금 쓰는 것과 비교하면 어떤가”, “이 전제가 틀리면 뭐가 깨지는가.” 그리고 그 질문을 맞는 사람에게 던집니다. 어느 팀에나 데이터베이스에 사는 것 같은 사람, 프론트엔드의 골치 아픈 엣지 케이스를 다 꿰고 있는 사람이 있기 마련입니다. 모든 걸 직접 알 필요는 없습니다. 누가 아는지 파악하고, 실제로 물어보러 가면 됩니다.

일할 때 “모르겠습니다"를 잘 말하는 법

#

제가 지키려는 원칙은 하나입니다. “모르겠습니다"로 문장을 끝내지 않는 것. 실제로 입 밖에 내서 쓸 수 있는 표현을 몇 가지 적어 봅니다.

• “지금은 잘 모르겠습니다. 목요일까지 확인해서 말씀드릴게요.”
• “그 부분은 민수 님이 저보다 훨씬 잘 아세요. 같이 여쭤보죠.”
• “확실하진 않은데, 제 추측으로는 X입니다. 결정 전에 Y는 한번 확인해 보고 싶어요.”
• “지금 숫자가 손에 없어서요. 회의 끝나고 채널에 공유드리겠습니다.”
• “제가 정확히 알지 못하는 부분이라, 담당자에게 확인 후 회신드리겠습니다.” (고객이나 외부 미팅에서)

“모르겠습니다"라고 하면 무례해 보이지 않을까 걱정하는 분도 있는데, 다음 행동이 붙어 있으면 무례하지 않습니다. 정말 곤란한 건 아무것도 진전시키지 못하는 “글쎄요"나, 자신 있게 답했는데 나중에 지어낸 것으로 드러나는 답입니다. 면접에서도 마찬가지입니다. 모르면 모른다고 하고, 어떻게 알아볼지를 이야기하세요. 찍어서 맞히려는 답보다 훨씬 많은 걸 보여 줍니다.

의사결정의 질이 올라간다

#

소프트웨어에서 내린 결정은 오래 남습니다. 그래서 “여기는 확신이 있고, 여기는 추측이다"를 솔직하게 구분하는 게 값어치를 합니다. 모르는 부분을 미리 인정해 두면 결정한 뒤가 아니라 결정하기 전에 부족한 정보를 모을 수 있고, 반대 의견이 있는 사람도 목소리를 내기 쉬워집니다. 그게 사실 가장 들어야 하는 목소리고요. 결정했으면 이유를 설명하고, 틀렸으면 그것도 인정합니다. 매니저가 자기 실수를 인정 못 하는 팀만큼 솔직함이 빨리 죽는 곳도 없습니다.

어려운 얘기가 아닙니다. 질문하고, 나보다 잘 아는 사람 말을 듣고(나보다 잘 아는 사람은 언제나 있습니다), 추측으로 말할 때는 추측이라고 말하는 것. 그게 전부입니다. “모르겠지만 알아보겠습니다"라는 한마디가, 얼버무리며 넘긴 그 어떤 답변보다 제 신용을 더 많이 쌓아 줬습니다.

그래도 기본값은 공개인 이유

#

투명성을 옹호하는 뻔한 논리들은 전부 사실이고, 저는 그게 실제로 작동하는 걸 여러 번 봤습니다. 결정 뒤에 있는 이유를 이해하면, 사람들은 그 결정이 마음에 들지 않아도 신뢰합니다. 저와 같은 정보를 갖고 있으면, 팀원들은 저를 기다리지 않고도 좋은 판단을 내립니다. 그리고 자기에게 영향을 주는 일이 자기만 모르는 채 진행됐다는 걸 나중에 알고 기분 좋을 사람은 없습니다.

날것 그대로의 투명성이 망가지는 지점

#

주로 세 가지입니다.

양. 설익은 업데이트까지 전부 전달하면 정작 중요한 이야기가 묻힙니다. 사람들은 곧 흘려듣는 법을 배우고요.

맥락. 배경 설명 없는 날것의 정보는 혼란을 낳습니다. “로드맵을 재검토 중입니다"라는 문장은 설명이 붙으면 평범한 소식이지만, 설명이 없으면 훨씬 무섭게 들립니다.

타이밍. 아직 결정되지 않은 걸 공유하면, 팀은 애초에 검토 대상도 아니었던 시나리오를 놓고 일주일을 추측하며 보냅니다. 반쯤 결정된 소식이 최종 결정보다 더 많은 에너지를 잡아먹는 일은 흔합니다.

기다리는 것과 숨기는 것은 다르다

#

공유 시점을 고른다고 하면 조작처럼 들립니다. 하지만 정직하게 하면 오히려 반대입니다. 소식이 이해에 필요한 맥락과 함께 도착하도록 만드는 일이니까요. 나쁜 소식은 대응 계획과 같이 전하면 충격이 덜합니다. 좋은 소식은 금요일 오후의 공지 더미에 파묻히지 않아야 제대로 전달되고요.

다만 기다림에는 비용이 있고, 그 비용은 불어납니다. 정보를 너무 오래 쥐고 있으면 사람들은 낌새를 챕니다. 공백은 소문이 채우는데, 소문은 어김없이 현실보다 나쁩니다. 그리고 늘 마지막에 알게 되는 사람은 그걸 자신의 가치에 대한 평가로 받아들입니다. 사실 틀린 해석도 아니죠. 보통은 정말 그렇거든요.

지금의 판단 기준

#

민감한 걸 공유하기 전에(혹은 보류하기 전에) 몇 가지를 자문합니다. 이게 팀이 일하는 데 필요한 정보인가, 아니면 그냥 내 속이 편해지고 싶은 건가. 맥락을 제대로 설명할 수 있는 단계인가, 아니면 파편만 던지게 되는가. 어떻게 받아들여질 것 같은가, 뻔히 나올 질문들에 답할 준비는 됐는가.

그리고 어느 쪽으로 결정하든 똑같이 합니다. 정보에는 맥락을 붙이고, 나중에 편하게 질문할 수 있는 분위기를 만들고, 어떻게 전달됐는지 지켜보면서 다음번 판단을 보정합니다. 원하는 정보의 양은 사람마다 다르고, 그건 지켜보고 물어봐야만 알 수 있습니다.

기본은 공개, 맥락은 필수, 그리고 전송 버튼을 누르기 전에 어떻게 받아들여질지 1분만 생각하기. 지금까지 겪은 상황은 이걸로 대부분 커버가 됐습니다.

저는 그 선을 몸으로 부딪히며 찾는 중입니다. 매니지먼트 교육을 받은 사람이 아니라, 개발하다 보니 프로젝트 팀을 이끌게 된 케이스라서요. 아래 내용은 대부분 한 번씩 살짝 틀려 본 다음에 배운 것들입니다.

리더십에서 공감이란

#

리더십에서 공감이란 구성원들이 실제로 어떤 상태인지 이해하고, 의사 결정을 하거나, 피드백을 주거나, 팀의 일하는 방식을 정할 때 그걸 진짜 변수로 반영하는 것입니다. 모두에게 맞춰 주는 것도, 회의에서 상냥하게 구는 것도 아닙니다. 상대의 사정을 충분히 이해하면서도 거절할 수 있죠. 자기 사정이 고려되고 있다는 걸 느끼면 사람들은 긴장을 풀고, 더 일찍 목소리를 내고, 일도 눈에 띄게 잘 굴러갑니다. 이 부분만큼은 흔한 조언이 맞습니다.

모자라도 문제, 넘쳐도 문제

#

다들 경고하는 실패는 사람을 리소스로만 보는 차가운 매니저입니다. 실제로 있는 일이죠. 구성원의 삶에서 벌어지는 일을 무시하면 사람들은 입을 닫고, 사기는 떨어지고, 문제는 몇 달 뒤에나 드러납니다.

아무도 경고하지 않는 실패는 그 반대편에 있습니다. 모든 걸 다 받아주면 경계가 흐려집니다. 마감은 권고 사항이 되고요. 그리고 묵묵히 기준을 지키던 사람들이, 기준을 요구받지 않는 사람들 몫까지 떠안으면서 조용히 억울해지기 시작합니다. 저도 그 순간에는 배려라고 생각하며 너무 많이 양보한 적이 있는데, 나머지 팀원들에게는 전혀 배려가 아니었습니다.

공감 리더십, 잘한 예와 과한 예

#

나란히 놓고 보면 차이가 잘 보입니다. 규칙이라기보다는 제가 지향하는 모양 정도로 봐 주세요.

과한 예들에는 공통점이 있습니다. 그 순간에는 배려처럼 느껴지지만, 실제로는 비용을 나중으로 미루거나 다른 사람에게 넘긴다는 거죠.

대부분의 일은 1:1 미팅이 해 준다

#

제가 그나마 균형 근처에 머무는 건 어떤 철학 덕분이 아니라, 캘린더에 박아 둔 반복 일정 덕분입니다. 정기적인 1:1이 있으면 작은 문제가 작을 때 드러납니다. 어느 날 사직서 한 장으로 한꺼번에 도착하는 게 아니라요.

제 1:1은 매번 대체로 같은 걸 묻습니다. 지금 뭐에 막혀 있는지, 최근에 잘된 건 뭔지, 팀 협업은 어떤지, 앞으로 어떻게 성장하고 싶은지, 그리고 제가 다르게 해야 할 건 없는지.

가장 쓸모 있었던 질문은 아주 평범한 문장입니다. “일 진행하는 데 저나 팀한테서 필요한 거 있으세요?” 시시하게 들리지만 그렇지 않습니다. 이 질문은 나도 해결의 일부가 될 생각이라는 신호이고, 돌아오는 답은 거의 언제나 실제로 처리해 줄 수 있는 구체적인 것들입니다. 누구와 연결해 달라든가, 붕 떠 있는 결정을 내려 달라든가, 한 시간만 페어링을 해 달라든가.

거절할 때야말로 솔직하게

#

1:1을 하다 보면 요청이 쌓입니다. 전부 들어줄 수는 없죠. 못 들어주는 요청을 어떻게 다루느냐에서 신뢰가 쌓이기도 하고 무너지기도 합니다.

제 방식은 이렇습니다. 요청을 진지하게 받아들이고, 그렇다고 말해 주기. 지금 안 되는 이유를 설명하기. 부분적인 대안이 있으면 제시하기. 언제 다시 검토할지 말하기. 그리고 결론이 그대로더라도 반드시 그 이야기로 돌아오기.

이렇게 한다고 거절이 즐거워지지는 않습니다. 다만 이유가 붙은 솔직한 “안 됩니다"는, 두 번 다시 언급되지 않는 애매한 “한번 볼게요"보다 훨씬 잘 받아들여집니다.

제가 찾은 공식은 결국 이 정도입니다. 사람들의 상태를 진심으로 신경 쓰고, 일에 필요한 건 솔직하게 말하고, 어느 한쪽으로 너무 쏠렸을 때 알아차릴 수 있을 만큼 자주 대화하는 것.

지금까지 참여한 프로젝트에서 가장 느렸던 건 코드가 아니었습니다. 대기열이었죠. 매니저 한 명의 캘린더 앞에 의사 결정이 줄줄이 쌓여서, 사흘 뒤에야 도착하는 “오케이"를 기다리는 것. 비동기 커뮤니케이션과 자율적인 팀이 정석적인 해법이고 저도 지지하는 쪽이지만, 이 전환의 정체는 툴 문제의 탈을 쓴 신뢰 문제입니다.

애초에 왜 모든 일에 결재가 필요해졌나

#

승인 문화가 어디서 오는지는 공정하게 봐 둘 필요가 있습니다. 통제는 정밀함처럼 느껴집니다. 모든 결정이 매니저 책상을 거치면 아무것도 옆길로 새지 않을 것 같으니까요. 잘못된 판단은 프로젝트만 망가뜨리는 게 아니라 매니저 본인의 평판도 깎기 때문에, 상당 부분은 두려움이 움직입니다. 팀에 판단할 만한 경험이 있는지 진심으로 의심하는 경우도 있고요. 그리고 순전히 관성인 경우도 있습니다. 조직도가 원래 그렇게 돌아갔으니 오늘도 그렇게 돌아가는 것뿐인 거죠.

이 네 가지 이유 중에 실제로 팀에 관한 건 하나뿐입니다. 나머지는 전부 매니저에 관한 이야기입니다.

자율에 정말 필요한 것

#

방향 정렬 없는 자율은 사기만 높은 혼돈입니다. 구성원이 목표를 진짜로 이해하고 있으면, 각자의 독립적인 결정은 대체로 같은 방향을 가리킵니다. 사실상 이게 비법의 전부예요. 교육도 중요합니다. 제대로 준비된 사람은 열정만 있는 사람보다 믿기 쉬우니까요. 그리고 경계는 남겨 두세요. 경영진에게 남아야 할 결정은 실제로 있고, 어떤 결정이 그런지 소리 내어 말해 두면 최악의 서프라이즈를 막을 수 있습니다. 그다음엔 피드백 루프를 돌리면서, 피할 수 없는 실수를 “증거"가 아니라 “수업료"로 취급하면 됩니다.

신뢰가 이미 상해 있다면 — 승인 문화에서 빠져나오는 팀은 대개 양방향으로 상해 있습니다 — 지름길은 없습니다. 열린 대화에서 문제에 이름을 붙이고, 경영진이 자기 몫의 실수를 먼저 인정하고, 그다음 몇 달 동안 지루할 만큼 일관되게 행동하는 것. 역할을 명확히 하고 정기적으로 대화하는 쪽이 거창한 이벤트보다 복구에 훨씬 효과적입니다.

비동기 쪽이 오히려 쉽습니다

#

툴 이야기는 짧게. Slack이든 Microsoft Teams든 충분합니다. 진짜 일은 문서화입니다. 아무도 같은 방, 같은 시간대에 있지 않으니, 글로 남긴 결정이 팀의 기억이 됩니다. 응답 기준도 정해 두세요. 비동기가 슬그머니 무응답이 되지 않도록요. “하루 안에"가 “언젠가"보다 낫고, 이 기준은 누가 어떤 업데이트를 받는지와 함께 팀의 커뮤니케이션 계획에 적어 두면 됩니다. 그리고 좋은 비동기 업데이트 쓰는 법은 따로 가르쳐야 합니다. 판단에 충분한 맥락, 필요한 결정, 기한. 타고나는 기술이 아니거든요. 예를 들면 이런 식입니다.

목요일까지 결정 필요: 결제 재시도
지금은 카드 결제가 실패하면 24시간 뒤에 한 번만 재시도하고, “주문 어떻게 됐나요?“가 요즘 가장 많은 고객 문의입니다.
A안: 24시간 안에 세 번 재시도(작업량은 반나절 정도). B안: 재시도는 그대로 두고 고객에게 메일로 안내.
저는 A안을 추천합니다. 자세한 내용과 수치는 링크한 문서에 있습니다.
목요일 오후 5시까지 반대 의견이 없으면 A안으로 진행하겠습니다.

이런 글은 아침 7시에 읽든 밤 11시에 읽든, 어느 시간대에 있든 회의 없이 답할 수 있습니다.

Slack 도입은 오후 한나절이면 끝납니다. 신뢰는 몇 달이 걸리고, 이 전체가 성공할지 실패할지를 가르는 건 그쪽입니다. 목표를 명확히 하고, 실수의 대가가 커리어가 아니라 교훈이 되게 만드세요. 거기까지 하면 비동기 부분은 대체로 알아서 굴러갑니다.

여기까지가 짧은 버전입니다. 긴 버전은 아래에 적었습니다. 피드백 대화가 똑같은 식으로 틀어진 적이 인정하기 싫을 만큼 많았거든요. 제가 뭔가를 꺼내면 상대의 어깨에 힘이 들어가고, 그 순간부터 둘 다 상대방 말을 제대로 안 듣게 됩니다.

사람은 애초에 왜 방어적이 될까

#

방어적인 태도는 고집이 아닙니다. 적어도 고집에서 시작하는 경우는 드뭅니다. 위협을 느꼈을 때 사람이 보이는 반응이고, 피드백은 우리가 생각하는 것보다 훨씬 많은 걸 위협합니다. 겉으로는 풀 리퀘스트나 놓친 마감 얘기를 하고 있죠. 하지만 상대에게는 ‘내가 일을 잘하는 사람인가, 이 팀에 있어도 되는 사람인가, 이 사람이 몇 달째 속으로 이렇게 생각해 온 건 아닐까’ 하는 질문으로 들립니다.

그렇게 느끼는 순간 상대의 신경은 제가 하려는 말이 아니라 자기를 지키는 쪽으로 갑니다. 더 세게 주장할수록 그 위협이 진짜라는 걸 확인시켜 줄 뿐입니다. 그래서 아래에 적은 방법 대부분은 먼저 부담을 낮추고, 그다음에야 본론으로 들어가는 이야기입니다.

어떤 사람들은 이미 상처를 안고 이런 대화에 들어온다는 것도 기억해 두면 좋습니다. 입을 열 때마다 비판만 하던 예전 매니저, 실수하면 밀려나던 조직 문화 같은 것들이요. 그 과거를 면담 한 번으로 바꿀 수는 없지만, 가벼운 한마디에 가끔 훨씬 큰 반응이 돌아오는 이유는 이걸로 설명이 됩니다.

대화 전에

#

피드백 대화는 대부분 시작하기 전에 결과가 정해집니다. 예전엔 안 했는데 지금은 하는 것들이 몇 가지 있습니다.

한 가지만 고릅니다. 다섯 가지를 쌓아 뒀다가 꺼내면 상대에게는 피드백이 아니라 죄목을 줄줄이 읽어 내려가는 것처럼 들립니다. 나머지 넷은 기다려도 되고, 알고 보면 첫 번째 문제의 증상인 경우도 많습니다.

빨리 합니다. 6주 전 일에 대한 피드백은 “왜 이제 와서 얘기하세요?“로 받아들여집니다. 타당한 질문인데 마땅한 답이 없죠. 일이 있고 하루 이틀 뒤가 적당합니다. 기억이 생생할 만큼 이르고, 둘 다 감정이 가라앉았을 만큼은 늦은 시점입니다.

따로 만나서 하고, 피할 수 있으면 채팅으로는 하지 않습니다. 글로 된 피드백은 어조가 빠지고, 방어적인 사람은 그 빈자리를 가장 나쁜 버전으로 채워서 읽습니다. 팀이 원격이거나 시간대가 달라서 꼭 글로 해야 한다면 짧게 쓰고 통화를 제안합니다.

그리고 제 상태를 점검합니다. 제가 짜증이 나 있으면 어떤 단어를 고르든 상대는 첫 문장에서 알아챕니다. 제가 했던 피드백 중에는 짜증이 가라앉을 때까지 기다렸다면 훨씬 잘 풀렸을 것들이 있습니다.

실제로 무슨 말을 할까

#

제가 결국 계속 돌아가는 구조는 흔히 상황-행동-영향(SBI)이라고 부르는 방식입니다. 언제 있었던 일인지, 상대가 무엇을 했는지, 그게 어떤 결과를 낳았는지. 핵심은 각 부분이 눈으로 확인할 수 있는 것이라는 점입니다. 상대가 어떤 사람인지는 하나도 들어가지 않고, 무슨 일이 있었는지만 들어갑니다.

실제로 어떻게 다른지 보죠. 어떤 개발자가 금요일 오후에 리뷰를 기다리지 않고 변경을 머지했고, 그 때문에 주말 동안 결제 기능이 깨졌다고 해 봅시다.

벽을 세우게 만드는 버전: “항상 일을 급하게 내보내시네요. 좀 더 신중하셔야 해요.”

그나마 가능성이 있는 버전: “금요일에 결제 관련 변경이 리뷰 없이 들어갔고, 토요일에 몇 시간 동안 결제가 안 됐습니다. 무슨 일이 있었는지 알고 싶어요. 부주의해서 그랬다고는 생각하지 않거든요.”

두 번째는 사건 하나를 짚고, 그 대가가 뭐였는지 담백하게 말하고, 선의를 전제하며 끝납니다. 가장 큰 상처를 내는 말은 “항상"과 “절대"입니다. 한 번의 일을 성격에 대한 판단으로 바꿔 버리고, 상대는 곧바로 제가 틀렸다는 걸 증명할 반례를 떠올립니다.

관찰의 주어를 저로 두려고도 합니다. “제가 보기에는”, “조금 걱정이 돼서요” 같은 말은 이게 어디까지나 제 쪽에서 본 시각이라는 걸 솔직하게 드러내고, 제가 놓친 게 있을 여지도 남겨 줍니다. 실제로 놓친 경우가 많고요.

그다음엔 말을 멈추고 묻습니다. “그쪽에서는 어떻게 보였어요?” 다른 사람이 정한 마감이라든가, 리뷰어가 병가 중이었다든가, 제가 몰랐던 맥락이 대개 있습니다. 설령 없더라도, 이 질문 하나가 이건 판결이 아니라 대화라는 걸 상대에게 알려 줍니다.

피드백은 앞으로의 방향이 붙어 있을 때 훨씬 잘 받아들여집니다. 문제 목록이 아니라 “다음번엔 이렇게 해 보면 어떨까요?” 같은 것이요. 그 방향이 상대 입에서 나오면 더 좋습니다.

그래도 반발할 때

#

다 제대로 해도 저항이 올 수 있습니다. 대개 알아볼 만한 몇 가지 형태로 오고, 형태마다 대응이 조금씩 다릅니다.

가장 흔한 건 부정입니다. “그런 일 없었는데요.” 이걸로 다투지 마세요. 커밋, 메시지, 날짜처럼 둘 다 볼 수 있는 것으로 돌아가서, 제가 뭘 놓치고 있는지 묻습니다. 사실관계 자체가 정말 엇갈린다면 “둘 다 한번 다시 확인해 보고 내일 이어서 얘기하죠"라고 해도 괜찮습니다.

다음은 화살 돌리기입니다. “요구사항이 계속 바뀌었잖아요"나 “누구누구도 그렇게 하는데요” 같은 거죠. 일리가 있는 경우가 많으니 무시하지 말고 인정합니다. “맞아요, 요구사항 문제도 고쳐야죠.” 그리고 부드럽게 다시 가져옵니다. “그거랑 별개로, 리뷰 단계 얘기를 하고 싶어요.”

“그쪽도 맨날 리뷰 없이 머지하잖아요” 같은 역공은 똑같이 받아치지 않기가 제일 어렵습니다. 숨을 한번 고르세요. 상대 말이 맞다면 맞다고 하세요. 분위기를 가라앉히는 가장 빠른 방법이고, 상대에게 바라는 열린 태도를 방금 제가 먼저 보여 준 셈이기도 합니다. 그런 다음 원래 얘기로 돌아옵니다.

입을 닫아 버리는 경우도 있습니다. 침묵이든 “네, 말씀대로 하죠"든, 동의처럼 보이지만 동의가 아닙니다. 저는 “이 얘기가 잘 안 와닿은 것 같네요. 괜찮아요” 정도로 부드럽게 짚고, 나중에 이어서 하자고 제안합니다. 마음을 닫은 사람에게서 억지로 대답을 받아 내면 가짜 대답만 돌아옵니다.

과하게 사과하는 것(“제가 이런 걸 진짜 못해요, 정말 죄송해요”)도 방어입니다. 방향이 안쪽을 향할 뿐이죠. 비판이 들어오기 전에 먼저 자기를 깎아내리면서 스스로를 지키는 겁니다. 이건 특정한 한 가지 얘기일 뿐 전체 성과에 대한 얘기가 아니라고 안심시키고, 앞으로 어떻게 할지로 넘어갑니다.

이 모든 경우에 제가 지키려는 원칙은 하나, 상대의 텐션에 말려들지 않는 것입니다. 상대가 방어적으로 나오면 제 본능도 똑같이 방어적으로 되받으려 하는데, 대화를 확실하게 망치는 수가 딱 그거 하나입니다. 제가 차분함을 유지하면 분위기는 대개 알아서 가라앉더군요. “이 얘기 듣기 답답하실 거 알아요"처럼 감정을 말로 꺼내 주는 것도 도움이 됩니다. 긴장이 없는 척하는 것보다 훨씬 낫습니다.

멈출 때를 알기

#

이 모든 게 안 통하고 벽이 안 내려올 때도 있습니다. 그 시점에서 더 밀어붙여 봐야 얻는 게 없습니다. 대화를 잠시 접어 두고, 상황이 좀 가라앉은 하루 이틀 뒤에 다시 꺼내면 됩니다. 피드백의 내용은 내일이 되어도 여전히 사실이고, 사람은 하룻밤 자고 나면 훨씬 차분하게 돌아보는 경우가 많습니다. 제가 했던 후속 대화 중 가장 좋았던 몇 번은 상대가 “그때 하신 말씀, 계속 생각해 봤는데요"라며 먼저 시작했습니다.

이걸 배우는 데 제일 오래 걸렸습니다.

대화가 끝난 뒤

#

그다음 일주일 동안 일어나는 일이 대화 자체만큼 중요합니다. 상대가 행동을 바꿨다면 알아챘다고, 분명하게, 빨리 말해 주세요. 그래야 저한테서 오는 피드백이 늘 나쁜 소식만은 아니라는 걸 상대가 알게 되고, 다음 대화도 쉬워집니다.

그리고 상황이 맞으면 피드백이 어떻게 받아들여졌는지 물어봅니다. “아까 얘기, 공정했나요?” 이 한마디가 대화의 균형을 잡아 주고, 상대에게 바라는 열린 태도를 먼저 보여 줍니다. 매니저가 되고 나서 이걸 습관처럼 하기 시작했는데, 제 머릿속에서는 분명했지만 입 밖으로는 그만큼 분명하지 않았던 경우를 몇 번 잡아냈습니다.

정리하면

#

문제를 꺼내기 전에 위협감부터 낮추세요. 한 가지를 골라 따로, 빨리 꺼내고, 사람이 아니라 행동과 그 영향을 말하고, 해결책을 내놓기 전에 상대 이야기를 먼저 들으세요. 상대가 반발하면 맞받아치지 마세요. 감정을 인정하고, 사실로 돌아가고, 멈췄다가 다른 날 이어 가도 된다는 여유를 가지세요. 그리고 꼭 후속으로 챙기세요. 신뢰는 대화 이후의 대화에서 쌓입니다.