Skip to content
Published on

엔지니어를 위한 대화법: 기술 결정을 설득하는 법

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

들어가며 — 코드는 옳았지만 아무도 안 들었다

경력이 쌓이면 누구나 한 번쯤 이런 경험을 합니다. 분명히 더 나은 아키텍처를 알고 있었는데, 회의에서 그 방향으로 결정이 나지 않았습니다. 몇 달 뒤, 다른 팀이 우연히 비슷한 결론에 도달해 칭찬을 받습니다. 억울합니다. 나는 진작 알았는데.

여기서 대부분의 엔지니어가 잘못된 교훈을 얻습니다. "정치가 문제야." 하지만 진짜 문제는 대개 더 단순하고, 다행히 고칠 수 있는 것입니다. 좋은 아이디어를 가진 것과, 그 아이디어를 남이 채택하게 만드는 것은 완전히 다른 기술이라는 사실을 모르고 있었던 겁니다.

시니어와 스태프 엔지니어를 가르는 선은 코드 실력이 아닙니다. 그 지점에 오면 대부분 코드는 충분히 잘 짭니다. 진짜 차이는 결정을 통과시키는 능력입니다. 옳은 답을 아는 것을 넘어, 조직이 그 답을 선택하도록 만드는 능력. 이 글은 그 기술을 다룹니다. 정치가 아니라, 명료함에 관한 이야기입니다.

설계 문서와 RFC — 말보다 글이 이기는 이유

기술 결정을 밀어붙이는 가장 강력한 도구는 프레젠테이션도, 열정적인 회의 발언도 아닙니다. 설계 문서(design doc) 혹은 **RFC(Request for Comments)**라 불리는, 잘 쓴 한 편의 글입니다. 구글이 엔지니어링 문화의 핵심으로 설계 문서를 꼽는 데는 이유가 있습니다.

글이 말을 이기는 이유는 구체적입니다.

  • 글은 검토받는다. 회의에서 말로 던진 제안은 그 자리의 분위기와 목소리 큰 사람에게 휘둘립니다. 문서는 사람들이 각자의 속도로, 냉정하게 읽고 여백에 반박을 답니다. 좋은 아이디어는 이 정밀 검토를 견디고, 나쁜 아이디어는 여기서 걸러집니다.
  • 글은 생각을 강제한다. 어떤 아이디어는 머릿속에서는 완벽해 보이다가, 문장으로 옮기는 순간 구멍이 드러납니다. "이 부분은 어떻게 처리하지?"라는 질문이 글을 쓰다가 저절로 떠오릅니다. 쓰는 행위 자체가 설계입니다.
  • 글은 확장되고 남는다. 회의는 그 방에 있던 사람만 압니다. 문서는 시간대가 다른 동료, 반년 뒤 합류한 신입, 결정의 배경이 궁금한 미래의 나 모두에게 똑같이 전달됩니다.

좋은 설계 문서에는 대체로 공통된 뼈대가 있습니다.

  제목 / 작성자 / 상태(초안·검토중·승인·폐기) / 날짜

  1. 배경과 문제 (Context)
     - 지금 무엇이 왜 문제인가. 이 문서를 읽는 이유.

  2. 목표와 비목표 (Goals / Non-Goals)
     - 무엇을 풀려 하고, 명시적으로 무엇은 풀지 않는가.
     - 비목표는 논의를 산으로 가지 않게 막아 주는 울타리다.

  3. 제안 (Proposed Design)
     - 핵심 접근. 다이어그램, 데이터 흐름, 주요 인터페이스.

  4. 검토한 대안 (Alternatives Considered)
     - 다른 선택지들과 왜 그것을 택하지 않았는가.

  5. 트레이드오프 / 위험 (Trade-offs / Risks)
     - 이 선택이 무엇을 포기하는가. 어디서 잘못될 수 있는가.

  6. 롤아웃 / 마이그레이션 (선택)

이 중 대부분의 사람이 빠뜨리는 두 섹션이 실은 가장 중요합니다. 검토한 대안과 트레이드오프입니다. 이 둘이 없는 문서는 "내 답을 받아 달라"는 주장이지만, 이 둘이 있는 문서는 "함께 판단하자"는 초대입니다. 리뷰어는 후자를 훨씬 신뢰합니다. 자기가 반박하려던 대안이 이미 문서 안에서 진지하게 검토되고 기각된 것을 보면, "이 사람은 생각을 제대로 했구나" 하고 안심하기 때문입니다.

해답이 아니라 문제로 먼저 설득하라

엔지니어가 저지르는 가장 흔한 설득 실수는, 자기가 이미 사랑에 빠진 해답부터 꺼내는 것입니다. "우리 이거 Kafka로 바꿉시다." 이 순간 방 안의 절반은 마음속으로 반대편에 섭니다. 아직 왜 바꿔야 하는지도 모르는데 벌써 결론을 강요당했기 때문입니다.

사람은 해답을 사기 전에 문제를 먼저 삽니다. 순서를 뒤집으세요.

  • 먼저 문제를 선명하게 그립니다. "지금 주문 처리가 피크 시간에 밀려서, 최근 한 달간 결제 후 재고 반영이 평균 40초 지연됐고, 그 사이 초과 판매가 217건 발생했습니다."
  • 이 시점에서 방 안의 모두가 같은 편이 됩니다. 아무도 초과 판매를 원하지 않으니까요. 여러분은 이제 함께 문제를 바라보는 사람들을 얻었습니다.
  • 그다음에 비로소 해답을 대안들과 함께 꺼냅니다. 사람들은 이미 문제에 공감했기에, 이제 해답을 "적인지 아군인지"가 아니라 "얼마나 잘 맞는지"로 봅니다.

사람들은 해답에 반대하기는 쉬워도, 잘 정의된 문제에 반대하기는 어렵다.

이것을 반대로 뒤집어 보면 진단 도구가 됩니다. 누군가 여러분의 제안에 격렬히 반대한다면, 대개 해답이 싫은 게 아니라 애초에 그것이 풀어야 할 문제라는 데 동의하지 않는 것입니다. 그럴 때 해답을 더 열심히 방어하는 것은 헛수고입니다. 한 걸음 물러나 문제로 돌아가야 합니다. "우리가 지금 같은 문제를 보고 있는 게 맞나요?"라는 질문이 열 번의 기능 비교보다 논의를 앞으로 밀어냅니다.

청중에 맞춰 메시지를 바꿔라

같은 결정도 누구에게 설명하느냐에 따라 완전히 다르게 포장되어야 합니다. 가장 흔한 실패는, 동료 엔지니어에게 하듯 경영진에게 구현 디테일을 쏟아붓는 것입니다. 상대는 5분 만에 흥미를 잃고, 여러분은 "저 사람은 기술을 모른다"고 오해합니다.

핵심은 각 청중이 무엇을 걱정하는가를 아는 것입니다.

축경영진 / 리더동료 엔지니어
가장 궁금한 것비용, 위험, 일정트레이드오프, 구현 방식
원하는 결론"얼마나 들고, 뭐가 위험하고, 언제 되나""왜 이 설계인가, 어디가 취약한가"
좋아하는 근거사업 영향, 기회비용, 경쟁 리스크벤치마크, 실패 모드, 코드 구조
디테일 수준결론 먼저, 요약 위주깊게, 근거까지
시간 예산짧다. 3문장 안에 요점길다. 파고들 준비가 됨

경영진에게는 결론부터 말합니다. "이 마이그레이션은 6주가 걸리고, 진행 중 롤백 계획이 있으며, 안 하면 다음 분기 트래픽에서 장애 위험이 큽니다." 리더가 원하는 것은 우아한 알고리즘이 아니라 의사결정에 필요한 재료 — 비용, 위험, 일정 — 입니다. 그들은 이 세 가지로 다른 열 개의 우선순위와 여러분의 제안을 저울질해야 합니다.

동료 엔지니어에게는 반대로 트레이드오프와 구현을 깊게 나눕니다. 그들은 "왜 A가 아니라 B인가", "이 설계가 동시성에서 어떻게 무너질 수 있는가"를 알고 싶어 하고, 그 질문에 성실히 답할수록 신뢰가 쌓입니다.

같은 진실을 말하되, 상대가 들고 갈 수 있는 형태로 건네는 것 — 그것은 조작이 아니라 배려이자 번역입니다.

트레이드오프를 명시하라

미숙한 제안과 성숙한 제안을 가르는 단 하나의 신호를 꼽으라면, 저는 트레이드오프를 스스로 밝히는가를 봅니다. 모든 기술 결정은 무언가를 대가로 치릅니다. 공짜 점심은 없습니다. 그런데 초보의 제안은 장점만 나열합니다. "이러면 더 빠르고, 더 깔끔하고, 더 확장성 있습니다." 이런 제안은 오히려 불신을 삽니다. 노련한 리뷰어는 압니다. 비용이 안 보인다는 것은 아직 그 비용을 발견하지 못했다는 뜻임을.

그래서 강한 제안은 자기 약점을 먼저 말합니다.

  • "이 캐시 계층은 읽기를 크게 빠르게 하지만, 캐시 무효화 복잡성이라는 새로운 부류의 버그를 들여옵니다."
  • "마이크로서비스로 쪼개면 팀이 독립적으로 배포할 수 있지만, 그 대가로 분산 트랜잭션과 운영 복잡도를 떠안습니다."
  • "이 라이브러리를 쓰면 두 달을 아끼지만, 우리를 그들의 릴리스 주기에 묶어 놓습니다."

이렇게 비용을 먼저 이름 붙이면 세 가지가 동시에 일어납니다. 첫째, 신뢰를 얻습니다. "이 사람은 균형 잡힌 시각을 가졌다." 둘째, 논의의 주도권을 쥡니다. 상대가 약점을 지적하며 "잡았다" 하기 전에, 여러분이 먼저 그 약점을 무대에 올렸기 때문입니다. 셋째, 결정의 질이 올라갑니다. 감춰진 비용이 아니라 드러난 비용을 놓고 팀 전체가 판단하게 되니까요.

모든 결정은 무언가를 치른다. 그 값을 당신이 부르지 않으면, 나중에 청구서가 이자까지 붙어서 온다.

비동기 vs. 동기 — 문서가 이길 때, 회의가 이길 때

"이건 문서로 쓸까, 회의를 잡을까?" 매번 헷갈리는 이 선택에는 사실 꽤 명확한 기준이 있습니다. 축은 두 개입니다. 정보의 복잡성과 의견의 수렴 정도입니다.

비동기(문서·스레드)가 이기는 경우:

  • 정보가 복잡하고 정밀함이 중요할 때. 아키텍처 제안, 장애 회고, API 설계 — 사람들이 각자 속도로 곱씹고 정확히 반박해야 하는 것들.
  • 여러 시간대에 걸친 팀. 문서는 잠든 사람을 깨우지 않고도 논의를 이어 갑니다.
  • 기록이 남아야 할 때. 6개월 뒤 "왜 이렇게 결정했지?"의 답이 필요한 모든 결정.

동기(회의·통화)가 이기는 경우:

  • 의견이 갈리고 감정이 실렸을 때. 스레드에서 다섯 번 왕복해도 안 좁혀지는 대립은, 15분 통화로 풀리는 경우가 많습니다. 텍스트는 오해와 방어를 증폭시키기 쉽습니다.
  • 아직 문제 정의조차 흐릿할 때. 무엇을 풀어야 할지 함께 더듬는 브레인스토밍은 실시간 캐치볼이 압도적으로 빠릅니다.
  • 긴급하고 관계가 걸렸을 때. 신뢰를 쌓거나 갈등을 봉합하는 일은 얼굴(혹은 목소리)이 필요합니다.

실전에서 가장 강력한 것은 둘을 결합하는 것입니다. 회의 전에 문서를 미리 돌려 모두가 같은 맥락 위에 서게 하고("read before the meeting"), 회의는 이미 문서에 남은 이견만 골라 실시간으로 좁히는 데 씁니다. 그리고 회의에서 내린 결정은 다시 문서에 적어 비동기 기록으로 남깁니다. 아마존의 유명한 "6페이지 내러티브를 회의 첫 20분간 침묵 속에 읽는" 관행이 정확히 이 결합입니다. 문서의 정밀함과 회의의 실시간성을 둘 다 취하는 것이죠.

한 가지 안티패턴을 경계하세요. 스레드에서 벌어지는 끝없는 논쟁입니다. 같은 주제로 댓글이 스무 개를 넘어가고 각자 조금씩 방어적으로 변해 간다면, 그것은 "회의를 잡으라"는 신호입니다. 반대로, 즉답이 필요 없는 사안을 자꾸 회의로 끌고 오는 것도 낭비입니다. 남의 캘린더에 30분을 예약하는 일에는 늘 그만한 근거가 있어야 합니다.

동의하지 않지만 따른다 (Disagree and Commit)

아무리 잘 설득해도, 여러분의 안이 채택되지 않는 날이 옵니다. 데이터가 부족했을 수도, 리더가 여러분이 못 본 제약을 봤을 수도, 그저 조직이 다른 방향을 택했을 수도 있습니다. 이때 여러분이 무엇을 하느냐가 시니어의 성숙도를 결정합니다.

가장 나쁜 두 가지 반응이 있습니다. 하나는 뒤에서 삐지는 것 — 회의에선 조용히 있다가 나가서 "그거 망할 거라니까"라고 흘리는 것. 다른 하나는 은근한 사보타주 — 결정에 마음으로 동의하지 않았으니 실행에도 소극적으로 임하는 것. 둘 다 팀을 좀먹고, 결정적으로 여러분에 대한 신뢰를 무너뜨립니다.

성숙한 대안이 아마존이 원칙으로 삼은 **"동의하지 않지만 따른다(disagree and commit)"**입니다. 이것은 이런 뜻입니다.

  1. 논쟁의 순간에는 최선을 다해 반대한다. 조용히 참는 것은 미덕이 아닙니다. 여러분이 아는 위험을 명확히, 강하게 테이블에 올리는 것은 의무입니다. 이 단계에서 봐주는 것은 오히려 불성실입니다.
  2. 결정이 내려지면 온전히 실행한다. 일단 조직이 방향을 정하면, 여러분은 그 결정을 마치 자기 것이었던 것처럼 성공시키기 위해 뜁니다. 마음속 앙금을 실행에 묻히지 않습니다.

이 둘을 분리하는 것이 핵심입니다. "설득의 국면"과 "실행의 국면"은 다릅니다. 전자에서는 치열하게 이견을 내고, 후자에서는 깨끗이 커밋합니다. 이렇게 할 수 있는 사람은 역설적으로 다음번에 더 큰 신뢰를 얻습니다. "저 사람은 반대할 땐 세게 반대하지만, 일단 정해지면 뒤통수를 치지 않는다"는 평판만큼 값진 자산은 없습니다.

한 가지 덧붙이면, 커밋한다는 것이 틀렸음을 영원히 삼키는 것은 아닙니다. 결정이 실제로 나쁜 결과를 낳으면, 그 데이터를 들고 다시 테이블에 오를 수 있습니다. 다만 그때의 근거는 "내가 말했잖아"가 아니라 새로 관측된 사실이어야 합니다. 커밋과 재론은 모순되지 않습니다. 커밋은 실행을 태만히 하지 않겠다는 약속이지, 영원한 침묵의 서약이 아닙니다.

"강한 의견, 느슨하게 쥐기"의 함정

기술판에는 오래된 슬로건이 하나 있습니다. "강한 의견, 느슨하게 쥐기(strong opinions, loosely held)." 원래 미래학자 폴 사포(Paul Saffo)가 예측의 태도로 제안한 것으로, 불확실한 미래에 대해 일단 강한 가설을 세우되 새 증거가 오면 미련 없이 버리라는, 그 자체로는 건강한 조언입니다.

문제는 이 문구가 현장에서 자주 정반대로 오용된다는 데 있습니다. 실제로 벌어지는 일은 이렇습니다.

  • 회의에서 가장 자신 있게, 가장 큰 목소리로 단정하는 사람이 방을 지배합니다. "강한 의견" 파트만 실천된 것이죠.
  • 그런데 "느슨하게 쥐기" 파트는 증발합니다. 반박당하면 마음을 바꾸는 게 아니라, 다음 주제에서 또 다른 것을 똑같이 강하게 단정합니다.
  • 결과적으로 이 슬로건은 자신감을 근거로 위장하는 면허가 됩니다. 실제로는 데이터가 아니라 목소리 크기가 이깁니다.

여기에는 조용하지만 심각한 부작용이 있습니다. 방 안에서 가장 신중한 사람 — 대개 "확실치 않다"고 정직하게 말하는 사람, 아직 데이터를 모으는 중인 주니어 — 의 의견이 자동으로 눌립니다. 강하게 말하는 것이 곧 옳음으로 오해되는 문화에서는, 목소리 큰 사람의 실수가 조용한 사람의 통찰을 이깁니다. 이것은 팀의 의사결정 품질을 서서히 갉아먹습니다.

그럼 어떻게 해야 할까요. 문구를 버리라는 게 아니라, 진짜로 실천하라는 것입니다.

  • 의견을 낼 때 확신의 정도를 함께 밝히세요. "이건 거의 확실합니다"와 "이건 직감인데요"를 구분해서 말하는 것만으로 논의의 질이 달라집니다.
  • 무엇이 자기 마음을 바꿀지를 미리 말하세요. "만약 벤치마크에서 X가 나오면 저는 제 입장을 접겠습니다." 이 한 문장이 "느슨하게 쥐기"를 말이 아닌 행동으로 만듭니다.
  • 그리고 실제로 반박당했을 때 눈에 보이게 마음을 바꾸세요. "아, 그 포인트를 놓쳤네요. 당신이 맞습니다"라고 공개적으로 말하는 시니어는 팀에 강력한 신호를 보냅니다. 여기서는 옳음이 자존심보다 위에 있다는 신호를.

강한 의견을 갖는 것은 값싸다. 그것을 정직하게 내려놓는 것이 그 문구의 전부다.

마치며

기술 결정을 통과시키는 능력은 타고난 언변이 아닙니다. 그것은 배울 수 있는 몇 가지 습관의 합입니다. 말이 아니라 검토받는 글(설계 문서·RFC)로 제안하기, 해답이 아니라 문제로 먼저 사람들을 같은 편으로 만들기, 경영진에게는 비용·위험·일정을 동료에게는 트레이드오프·구현을 건네기, 모든 결정의 대가를 스스로 이름 붙이기, 사안에 맞게 문서와 회의를 고르기, 논쟁에서 진 뒤에는 깨끗이 커밋하기, 그리고 "강한 의견"을 자신감의 면허가 아니라 정직한 가설로 다루기.

이 모두를 관통하는 하나의 태도가 있다면, 그것은 명료함에 대한 책임입니다. 여러분이 무엇을 아는지가 아니라, 그것을 남이 이해하고 신뢰하고 함께 결정하게 만드는 것 — 거기서부터가 시니어의 일입니다. 좋은 코드를 쓰는 것이 절반이라면, 그 코드가 옳다는 것을 조직이 함께 믿게 만드는 것이 나머지 절반입니다. 그리고 대개, 후자가 더 어렵고 더 값집니다.

참고 자료

Discuss on Twitter • View on GitHub