Skip to content
Published on

결국 사람이 하는 일 — 소프트웨어 팀에서 사람을 존중한다는 것

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
필사 모드
공유하기
Authors

들어가며 — 버그의 진짜 원인

장애 회고 자리에서 가장 자주 나오는 표면적 원인은 "특정 코드의 버그"입니다. 하지만 회고를 깊이 파고들다 보면, 진짜 원인은 코드가 아니라 사람들 사이의 무언가인 경우가 놀라울 만큼 많습니다.

제가 겪은 한 사례를 들려드리겠습니다. 결제 시스템에서 중복 청구 버그가 났습니다. 코드 자체는 두 줄이면 고칠 수 있었습니다. 그런데 회고를 해보니, 한 달 전 어떤 개발자가 이미 그 위험을 발견하고 코드 리뷰에서 언급했었습니다. 리뷰 코멘트에는 이렇게 적혀 있었습니다. "여기서 재시도가 일어나면 중복 청구가 될 수도 있을 것 같은데요?" 그 코멘트에 대한 답은 단 한 줄이었습니다. "지금은 시간이 없어서 나중에 보겠습니다." 그리고 아무도 나중에 보지 않았습니다.

버그의 진짜 원인은 코드가 아니라, 그 코멘트가 진지하게 다뤄지지 않았다는 사실이었습니다. 의견을 낸 사람은 무시당했다고 느꼈고, 그 뒤로 리뷰에서 점점 입을 닫았습니다. 이것은 기술 문제가 아니라 사람과 소통의 문제입니다.

소프트웨어는 컴퓨터가 실행하지만 사람이 만듭니다. 사람이 모여 결정하고, 토론하고, 때로 다투며 만듭니다. 그래서 "사람을 존중한다"는 말은 따뜻한 구호가 아니라 좋은 소프트웨어를 만드는 실질적 조건입니다. 이 글에서는 그 존중을 추상적 훈계가 아니라 구체적 행동으로 풀어보려 합니다.

기술 문제로 보이는 것의 본질

소프트웨어 팀에서 벌어지는 갈등은 표면적으로는 기술 논쟁의 옷을 입고 있습니다. "REST냐 GraphQL이냐", "모놀리스냐 마이크로서비스냐", "이 변수명이 맞냐 저 변수명이 맞냐." 하지만 그 밑을 들여다보면 종종 다음과 같은 비기술적 문제가 깔려 있습니다.

표면 (기술처럼 보임)본질 (사람·소통의 문제)
끝없는 아키텍처 논쟁누구의 의견이 더 존중받는가의 힘겨루기
코드 리뷰가 험악해짐비판과 인격을 구분하지 못함
같은 실수가 반복됨실수를 솔직히 말할 안전감의 부재
정보가 공유되지 않음신뢰와 협력의 부재
회의가 길고 결론이 없음의사결정 권한의 모호함

물론 순수하게 기술적인 논쟁도 있습니다. 모든 갈등을 사람 문제로 환원하는 것 역시 위험합니다. 핵심은, 기술 논쟁이 비정상적으로 격해지거나 반복될 때, 그 밑에 사람 문제가 깔려 있지 않은지 의심해 보는 것입니다. 보통 기술 문제는 데이터와 실험으로 풀리지만, 사람 문제는 그렇게 풀리지 않습니다.

존중의 구체적 행동들

"서로 존중합시다"라는 말은 누구나 동의하지만 아무것도 바꾸지 못합니다. 존중은 명사가 아니라 동사여야 합니다. 매일의 작은 행동으로 드러나야 합니다.

경청 — 말을 끊지 않고 끝까지 듣기

가장 기본이지만 가장 안 지켜지는 것입니다. 회의에서 누군가 말하는 도중에 끼어들지 않기, 동의하지 않더라도 끝까지 듣고 "내가 제대로 이해했는지 확인할게요"라고 되묻기. 이것만으로도 분위기가 달라집니다.

[경청하지 않는 대화]
A: 제 생각엔 캐시를 도입하면—
B: 아니 그건 안 돼요. 캐시 무효화가 얼마나 어려운데.
A: (말을 잃음)

[경청하는 대화]
A: 제 생각엔 캐시를 도입하면 응답 속도가 개선될 것 같아요.
B: 좋은 방향이에요. 한 가지 걱정은 캐시 무효화인데,
   그 부분은 어떻게 풀 생각이세요?
A: 아, 그건 TTL을 짧게 가져가면서—

두 대화의 기술적 내용은 같습니다. 다른 것은 한쪽이 상대를 사람으로 대했다는 점뿐입니다.

크레딧 — 공을 정확히 돌리기

누군가의 아이디어로 문제가 풀렸다면, 회의에서, 문서에서, 발표에서 그 사람의 이름을 명시적으로 말하는 것. "지난주에 OO님이 제안한 방법으로 해결했습니다"라는 한마디는 그 사람에게 큰 인정이 됩니다. 반대로 남의 공을 슬그머니 자기 것으로 가져가는 것만큼 신뢰를 빠르게 무너뜨리는 일도 없습니다.

공정 — 일관된 기준으로 대하기

같은 실수를 누구는 너그럽게, 누구는 가혹하게 대한다면 그것은 불공정입니다. 좋아하는 사람의 PR은 대충 통과시키고 싫어하는 사람의 PR은 꼬투리를 잡는다면, 사람들은 곧 알아챕니다. 공정함은 기준의 일관성에서 나옵니다.

시간 존중 — 상대의 집중을 함부로 깨지 않기

"잠깐만요"라며 남의 딥워크를 수시로 깨는 것도 존중의 결여입니다. 급하지 않은 질문은 비동기로 남기고, 회의는 필요한 사람만, 짧게. 동료의 시간은 동료의 가장 귀한 자원입니다.

코드 리뷰와 논쟁에서의 태도

코드 리뷰는 존중이 가장 자주 시험받는 자리입니다. 코드는 사람이 시간을 들여 만든 결과물이고, 그것을 비판하는 일은 본질적으로 예민할 수밖에 없습니다.

코드를 비판하되 사람을 비판하지 않기

[사람을 공격하는 리뷰]
"이걸 왜 이렇게 짰어요? 기본기가 부족하신 것 같은데."
"이 코드는 도저히 이해가 안 됩니다."

[코드에 집중하는 리뷰]
"이 부분에서 N+1 쿼리가 발생할 것 같아요. 한 번에 가져오면 어떨까요?"
"제가 이 흐름을 잘 못 따라가겠는데, 주석을 조금 더 달아주실 수 있나요?"

핵심 원칙은 "주어를 코드로 만들기"입니다. "당신이 틀렸다"가 아니라 "이 코드가 이런 상황에서 문제가 될 수 있다"로 말하는 것입니다.

질문의 형식을 빌리기

명령보다 질문이 부드럽습니다. "이렇게 바꾸세요"보다 "여기를 이렇게 바꾸면 어떨까요?"가 상대에게 생각할 여지를 줍니다. 단, 답이 정해진 가짜 질문("정말 이게 최선이라고 생각하세요?")은 오히려 더 공격적이니 피해야 합니다.

논쟁에서 이기려 하지 말고 옳은 결론에 도달하려 하기

기술 논쟁의 목적은 누가 똑똑한지 증명하는 게 아니라 더 나은 결정을 내리는 것입니다. "제가 틀렸네요, 그 방법이 더 낫습니다"라고 말할 수 있는 사람이 사실은 가장 강한 사람입니다. 의견 불일치는 건강하지만, 그것이 끝난 뒤에는 결정을 따르고(disagree and commit) 사람에 대한 앙금을 남기지 않아야 합니다.

다양성과 포용 — 다른 관점이 더 나은 결과를 만든다

다양성을 윤리적 당위로만 이야기하면 공허해지기 쉽습니다. 더 실용적인 관점이 있습니다. 동질적인 팀은 같은 사각지대를 공유합니다. 모두가 같은 배경, 같은 경험, 같은 사고방식을 가지면, 모두가 똑같은 것을 놓칩니다.

서로 다른 배경의 사람들은 서로 다른 질문을 던집니다. 누군가는 접근성을 떠올리고, 누군가는 다른 언어권 사용자를 떠올리고, 누군가는 보안 위협을 떠올립니다. 이 다양한 질문들이 모여 더 견고한 소프트웨어를 만듭니다.

포용(inclusion)은 다양성보다 한 걸음 더 나아갑니다. 다양한 사람을 모아두는 것을 넘어, 그들이 실제로 목소리를 낼 수 있게 만드는 것입니다. 회의에서 늘 같은 두세 명만 말한다면, 다양성은 있어도 포용은 없는 것입니다.

포용을 만드는 작은 실천
- 회의에서 조용한 사람에게 의견을 직접 물어보기
  "OO님은 이 부분 어떻게 생각하세요?"
- 비동기 채널(문서, 채팅)을 함께 운영해
  말로 끼어들기 어려운 사람도 의견을 낼 수 있게 하기
- 신입이나 비주류 의견을 먼저 듣고, 시니어 의견을 나중에 내기
  (먼저 권위 있는 의견이 나오면 다른 의견이 묻힌다)

안티패턴 — 천재 신화의 함정

소프트웨어 업계에는 "고독한 천재" 신화가 끈질기게 남아 있습니다. 한 명의 비범한 개발자가 모든 것을 만들어낸다는 환상입니다. 이 신화는 두 가지 면에서 해롭습니다.

첫째, 사실이 아닙니다. 우리가 아는 거의 모든 위대한 소프트웨어는 팀이 만들었습니다. 리눅스조차 수천 명의 기여자가 함께 만든 것이고, 리누스 토르발스 본인도 그 점을 누구보다 강조합니다.

둘째, 해롭습니다. "천재"로 떠받들어진 사람은 종종 무례함을 면죄받습니다. "원래 저 사람은 까칠하지만 실력이 좋으니까"라는 말이 팀 전체의 심리적 안전을 무너뜨립니다. 한 명의 뛰어난 개인이 만들어내는 가치보다, 그 사람이 주변 열 명을 위축시켜 잃게 만드는 가치가 더 클 수 있습니다.

구글이 자사 팀들을 분석한 아리스토텔레스 프로젝트(Project Aristotle)의 결론도 같은 방향을 가리킵니다. 최고의 팀을 만드는 가장 중요한 요인은 개별 구성원의 천재성이 아니라, 팀의 심리적 안전감이었습니다. 누구나 바보 같은 질문을 하고 실수를 인정할 수 있는 분위기 말입니다.

다른 안티패턴들도 짚어둡니다.

  • 영웅주의 보상: 평소에 차분히 일하는 사람보다, 불을 끄는(장애를 막판에 수습하는) 사람만 칭찬받는 문화. 결국 모두가 불을 지피게 된다.
  • 침묵의 외주화: "그건 저 팀 일이지"라며 책임을 떠넘기는 태도. 경계에서 문제가 곪는다.
  • 냉소의 전염: 모든 제안에 "그거 예전에 해봤는데 안 돼"로 응답하는 사람. 한 명의 냉소가 열 명의 시도를 죽인다.

사례 — 무례한 천재 vs 다정한 조력자

두 명의 시니어 개발자를 비교해 보겠습니다. 둘 다 실력은 출중했습니다.

S는 전형적인 "무례한 천재"였습니다. 코드는 훌륭했지만 리뷰는 가혹했고, 회의에서 다른 사람의 말을 자주 끊었습니다. 주니어들은 S에게 질문하기를 두려워했고, 모르는 것을 모른다고 말하지 못했습니다. 그 결과 같은 실수가 조용히 반복됐습니다.

D는 달랐습니다. 코드는 S만큼은 아니었지만, 주니어의 어설픈 질문에 진지하게 답했고, 자기 실수를 먼저 공개했습니다. "이거 제가 작년에 똑같이 틀렸어요"라고 말이죠. 시간이 지나자 D 주변의 주니어들이 빠르게 성장했고, 팀 전체의 생산성이 올라갔습니다.

1년 뒤 팀의 산출물을 비교했을 때, D가 속한 팀이 더 많은 것을, 더 안정적으로 만들어냈습니다. 개인 S의 코드 한 줄은 더 뛰어났을지 몰라도, 사람 D가 만든 팀이 더 강했습니다. 이것이 "결국 사람이 하는 일"이라는 말의 의미입니다.

세 가지 현장 사례

추상적인 원칙은 구체적인 이야기 속에서만 살아 움직입니다. 제가 가까이에서 보았거나 전해 들은 세 가지 사례를 통해, 존중이 어떻게 팀의 운명을 갈랐는지 짚어보겠습니다.

사례 1 — 크레딧을 빼앗기고 떠난 시니어

한 원격 팀에 J라는 시니어 엔지니어가 있었습니다. J는 분산 시스템의 까다로운 데이터 정합성 문제를 며칠을 매달려 풀어냈고, 그 해법을 팀 채널에 길게 정리해 공유했습니다. 문제는 그다음이었습니다. 팀의 리드가 그 해법을 임원 보고 자리에서 마치 자신이 설계한 것처럼 발표했고, J의 이름은 한 번도 나오지 않았습니다.

원격 환경이라 그 발표 자리에 J는 없었습니다. 나중에 회의록을 통해 알게 된 J는 처음엔 별말을 하지 않았습니다. 하지만 같은 일이 두세 번 반복되자, J는 조용히 기여를 줄이기 시작했습니다. 어려운 문제를 풀어도 더 이상 공개적으로 공유하지 않았고, 결국 반년 뒤 회사를 떠났습니다. 퇴사 면담에서 J가 남긴 말은 짧았습니다. "제가 한 일이 제 것으로 남지 않는 곳에서는 일할 이유를 못 찾겠습니다."

리드는 J가 떠난 진짜 이유를 끝내 이해하지 못했습니다. 표면적으로는 "더 좋은 조건의 이직"이었으니까요. 하지만 팀이 잃은 것은 사람 한 명이 아니라, 그 사람이 풀던 가장 어려운 문제들을 풀 능력 전체였습니다. 크레딧을 정확히 돌리는 일은 예의의 문제가 아니라 인재 보존의 문제입니다.

사례 2 — 격해진 PR 스레드, 그리고 진화

또 다른 사례는 한 오픈소스 기여 과정에서 벌어졌습니다. 한 기여자가 큰 리팩터링 PR을 올렸고, 메인테이너는 "이 변경은 우리 설계 철학과 맞지 않는다"는 짧은 코멘트로 닫으려 했습니다. 기여자는 발끈했고, 스레드는 빠르게 험악해졌습니다. "그럼 처음부터 가이드라인에 적어놨어야죠." "당신이 코드베이스를 제대로 안 읽은 겁니다." 양쪽 다 사람을 향하기 시작했습니다.

이 스레드를 살린 것은 제삼자였습니다. 다른 메인테이너가 끼어들어 이렇게 적었습니다. "두 분 다 같은 것을 원하는 것 같아요 — 더 깔끔한 코드베이스요. 다만 그 방법에 대한 가정이 다른 거고요. 우선 우리가 합의된 설계 원칙을 어디에도 문서화하지 않았다는 점은 우리 잘못입니다. 그 부분부터 정리하고, 이 PR은 작은 단위로 나눠서 다시 보면 어떨까요?"

이 한 코멘트가 분위기를 완전히 바꿨습니다. 그것은 (1) 양쪽의 공통 목표를 명시했고, (2) 책임의 일부를 메인테이너 쪽으로 가져왔으며, (3) 다음 행동을 구체적으로 제안했습니다. 결국 그 기여자는 PR을 세 개로 나눠 다시 올렸고, 그중 두 개가 머지됐으며, 나중에는 정식 메인테이너가 되었습니다. 갈등을 인격 싸움에서 문제 해결로 되돌리는 데에는, 누군가 한 명이 "우리는 같은 편"이라는 사실을 다시 상기시켜 주는 것으로 충분할 때가 많습니다.

사례 3 — 비난하는 회고 vs 비난 없는 회고

같은 장애를 두 팀이 어떻게 다르게 회고했는지 비교해 보겠습니다. 두 팀 모두 배포 후 데이터베이스 마이그레이션 실수로 30분간 서비스가 중단됐습니다.

A팀의 회고는 "누가 그랬나"로 시작했습니다. 마이그레이션을 실행한 주니어가 지목됐고, 회의 내내 그 사람은 고개를 들지 못했습니다. 결론은 "다음부터 더 조심하자"였습니다. 그 주니어는 그 뒤로 배포를 극도로 두려워하게 됐고, 다른 사람들도 위험한 작업을 서로 떠넘기기 시작했습니다. 한 달 뒤, 비슷한 실수가 다른 사람 손에서 또 났습니다.

B팀의 회고는 "어떻게 이런 일이 가능했나"로 시작했습니다. 마이그레이션을 실행한 사람을 탓하는 대신, 질문은 시스템을 향했습니다. "왜 위험한 마이그레이션이 자동 검증 없이 프로덕션까지 갈 수 있었나?" "왜 롤백이 30분이나 걸렸나?" 결론은 사람이 아니라 가드레일이었습니다 — 마이그레이션 사전 검증 자동화, 원클릭 롤백, 단계적 배포. 그 주니어는 오히려 검증 도구를 만드는 일을 맡았습니다. 비슷한 실수는 그 뒤로 다시 나지 않았습니다.

같은 사고, 정반대의 결과. 차이는 회고가 사람을 향했느냐 시스템을 향했느냐 하나뿐이었습니다.

비난하는 회고 vs 비난 없는 회고

두 회고 방식의 차이를 표로 정리하면 다음과 같습니다.

항목비난하는 회고비난 없는 회고
첫 질문누가 이 일을 저질렀나어떻게 이 일이 가능했나
초점개인의 실수시스템의 허점
분위기방어와 변명호기심과 학습
결과물더 조심하자는 다짐구체적인 가드레일과 액션 아이템
정보 공개실수를 숨기게 됨실수를 일찍 드러내게 됨
장기 효과같은 실수 반복같은 실수 차단
심리적 안전하락상승

비난 없는 회고(blameless postmortem)의 핵심 가정은 단순합니다. 사람은 주어진 상황에서 합리적으로 행동했다고 전제하고, 그렇다면 왜 그 행동이 합리적으로 보였는지를 묻는 것입니다. 이 전제가 사람들을 방어 모드에서 학습 모드로 옮겨 줍니다. Etsy가 공유한 "Blameless PostMortems and a Just Culture"는 이 접근의 고전적인 출발점입니다.

SBI 피드백 프레임워크

존중하면서도 솔직한 피드백은 즉흥적으로 나오지 않습니다. 구조가 필요합니다. 가장 실용적인 도구 중 하나가 SBI 프레임워크입니다. Situation(상황), Behavior(행동), Impact(영향)의 세 가지를 순서대로 말하는 것입니다.

  • Situation(상황): 언제, 어디서 있었던 일인지 구체적으로 짚습니다. "어제 오후 스프린트 회의에서"처럼.
  • Behavior(행동): 관찰 가능한 사실만 말합니다. 해석이나 추측이 아니라, 카메라에 찍혔을 법한 행동만. "동료가 말을 끝내기 전에 두 번 끼어들었어요"처럼.
  • Impact(영향): 그 행동이 나 또는 팀에 미친 영향을 말합니다. "그래서 그분이 의견을 끝까지 말하지 못했고, 좋은 아이디어가 묻힌 것 같아요"처럼.

SBI의 힘은 "당신은 무례하다" 같은 인격 평가를 "이 상황에서 이 행동이 이런 영향을 줬다"는 관찰로 바꾸는 데 있습니다. 듣는 사람이 방어할 필요가 줄어듭니다.

[SBI 적용 예시]
상황(S): 어제 오후 설계 리뷰에서,
행동(B): 제가 캐시 안을 다 설명하기 전에
         "그건 안 된다"고 두 번 끊으셨어요.
영향(I): 그래서 무효화 전략까지 설명할 기회가 없었고,
         저는 제 의견이 잘 전달되지 않았다고 느꼈습니다.
요청:    다음 리뷰에서는 제가 다 설명한 뒤에
         반론을 주시면 더 깊이 논의할 수 있을 것 같아요.

마지막의 "요청"은 SBI의 정식 구성 요소는 아니지만, 피드백을 비판이 아니라 협업의 제안으로 마무리하는 데 도움이 됩니다.

대화 예시 — 적대적 vs 존중하는 1:1 피드백

같은 상황, 같은 문제를 두고 두 가지 1:1 대화를 비교해 보겠습니다. 한 팀원이 최근 마감을 두 번 놓쳤습니다.

[적대적인 1:1]
리드: 요즘 왜 이래요? 마감을 벌써 두 번이나 놓쳤잖아요.
      이런 식이면 팀에 민폐예요.
팀원: 죄송합니다... 좀 바빠서요.
리드: 다들 바빠요. 변명하지 말고 그냥 제대로 좀 합시다.
팀원: ...네.
(팀원은 진짜 이유를 끝내 말하지 않는다.
 다음 마감도 위태롭다.)

[존중하는 1:1]
리드: 최근 두 번 마감이 밀렸는데, 무슨 일이 있었는지
      같이 한번 봤으면 해요. 탓하려는 게 아니라
      막힌 데가 있으면 풀어주고 싶어서요.
팀원: 사실... 결제 모듈 의존성 때문에 자꾸 막혔어요.
      그쪽 API가 자주 바뀌어서 다시 짜야 했고요.
리드: 아, 그건 혼자 끌어안을 문제가 아니네요.
      그 팀과의 조율은 제가 같이 들어갈게요.
      그리고 다음부터 이런 블로커는 일찍 올려주면
      훨씬 빨리 풀 수 있어요.
팀원: 네, 그렇게 할게요. 사실 말 꺼내기가 좀 그랬어요.
리드: 막히는 걸 말해주는 게 일 잘하는 거예요.
(진짜 원인이 드러나고, 구조적 해결로 이어진다.)

두 대화의 사실관계는 같습니다. 팀원이 마감을 두 번 놓쳤다는 것. 하지만 적대적인 대화는 진짜 원인을 숨기게 만들었고, 존중하는 대화는 그것을 드러내 해결로 이어지게 했습니다. 솔직함과 무례함의 차이는 "문제를 직시하느냐"가 아니라 "상대를 적으로 두느냐 같은 편으로 두느냐"에 있습니다.

반대 관점 — 심리적 안전이 오용될 때

지금까지의 이야기가 한쪽으로 치우치지 않으려면, 균형을 위한 반대 관점도 짚어야 합니다. 존중과 심리적 안전은 강력한 도구이지만, 잘못 쓰이면 정반대의 결과를 낳습니다.

심리적 안전 ≠ 책임의 면제

가장 흔한 오해는 "심리적 안전 = 누구도 지적받지 않는 상태"라는 것입니다. 이는 틀렸습니다. 에이미 에드먼슨 본인이 강조하듯, 심리적 안전은 높은 기준과 짝을 이뤄야 합니다. 안전감만 높고 기준이 낮으면 팀은 "편안한 무기력(comfort zone)"에 빠지고, 기준만 높고 안전감이 낮으면 "불안(anxiety zone)"에 빠집니다. 둘 다 높을 때에만 "학습과 고성과(learning zone)"가 나옵니다.

"실수해도 괜찮아"는 "실수를 책임지지 않아도 괜찮아"가 아닙니다. 비난 없는 회고도 "아무도 책임지지 않는 회고"가 아니라, "개인을 탓하는 대신 시스템과 프로세스가 책임지는 회고"입니다. 같은 사람이 같은 실수를 학습 없이 반복하는데도 아무 말 없이 넘어간다면, 그것은 심리적 안전이 아니라 방치입니다.

독성 긍정(toxic positivity)의 위험

또 다른 함정은 "긍정적으로만 말하자"는 문화가 솔직한 문제 제기를 막아버리는 것입니다. 모든 회의가 "좋아요", "멋져요"로만 채워지고, 누군가 위험을 지적하면 "왜 그렇게 부정적이냐"는 시선이 돌아온다면, 그 팀은 표면적으로는 화목하지만 실제로는 중요한 신호를 잃습니다. 글 앞머리의 결제 버그 사례를 떠올려 보세요. 위험을 지적한 코멘트가 묻힌 것은 무례함 때문만이 아니라, 불편한 진실을 진지하게 다루지 않는 분위기 때문이기도 했습니다.

진짜 존중은 "듣기 좋은 말만 하는 것"이 아니라 "불편하더라도 필요한 말을, 상대를 존중하는 방식으로 하는 것"입니다. 케임 스콧의 표현을 빌리면, 개인적으로 마음 쓰면서도(care personally) 직접적으로 도전하는 것(challenge directly), 둘 다입니다. 둘 중 하나만 있으면 무례한 공격이거나 파괴적 공감입니다.

자주 묻는 질문

Q. 솔직함과 무례함의 차이는 무엇인가요?

대상이 다릅니다. 솔직함은 문제를 향하고, 무례함은 사람을 향합니다. "이 설계는 이런 부하에서 깨질 것 같아요"는 솔직함입니다. "이런 설계를 하다니 실력이 의심스럽네요"는 무례함입니다. 또 하나의 기준은 의도입니다. 상대가 더 잘되기를 바라는 솔직함과, 상대를 깎아내려 자신을 높이려는 무례함은 듣는 사람이 본능적으로 구별합니다.

Q. disagree and commit이 결국 침묵을 강요하는 것 아닌가요?

순서가 핵심입니다. disagree and commit은 "충분히 disagree한 뒤에 commit하라"는 뜻이지, "그냥 입 닫고 따르라"가 아닙니다. 반대 의견을 낼 기회가 충분히 주어지고, 그 의견이 진지하게 검토된 뒤에 결정이 내려졌다면, 그 결정을 실행 단계에서 흔들지 않는 것입니다. 만약 disagree할 기회조차 없이 commit만 요구된다면, 그것은 이 원칙의 오용입니다.

Q. 원격 환경에서는 존중을 어떻게 보여주나요?

원격에서는 비언어적 신호가 사라지기 때문에, 존중을 더 명시적으로 표현해야 합니다. 몇 가지 구체적 실천이 있습니다. 텍스트로 크레딧을 명확히 남기기(채널에 "이건 OO님 아이디어였어요"라고 적기), 비동기 메시지에 빠르게 반응 이모지라도 달아 "읽었고 무시하지 않았다"는 신호 주기, 화상 회의에서 조용한 사람을 의도적으로 호명하기, 시간대가 다른 동료에게 새벽에 답을 강요하지 않기. 사례 1의 J가 떠난 것도 원격이라 크레딧 도난이 더 보이지 않게 일어났기 때문입니다.

Q. 무례하지만 실력이 뛰어난 사람은 어떻게 다뤄야 하나요?

먼저 "실력"의 정의를 넓혀야 합니다. 주변 사람을 위축시켜 팀 전체의 산출을 떨어뜨리는 사람은, 개인 기여가 아무리 뛰어나도 순(net) 기여가 마이너스일 수 있습니다. 다루는 방법은 명확한 기대치를 행동 언어로 전달하는 것입니다(앞의 SBI 참고). "당신은 무례하다"가 아니라 "리뷰에서 인신공격성 표현을 쓰면 사람들이 질문을 멈춘다, 이것이 팀의 학습을 막는다"처럼. 변화의 여지를 주되, 변하지 않는다면 그 사람의 실력이 팀에 남기는 손해를 정직하게 계산해야 합니다.

Q. 신입이라 의견을 내기가 두렵습니다. 어떻게 시작하면 좋을까요?

질문의 형식을 빌리는 것이 가장 안전한 출발점입니다. "이건 틀렸어요" 대신 "제가 이 부분을 잘 이해 못 한 걸 수도 있는데, 이렇게 하면 이런 경우엔 어떻게 되나요?"라고 물으면, 틀려도 배우는 자세가 되고 맞으면 문제를 짚은 것이 됩니다. 또한 비동기 채널을 활용하세요. 회의에서 말로 끼어들기 어렵다면, 문서 코멘트나 채팅으로 의견을 남기는 편이 부담이 적습니다.

Q. 우리 팀엔 이미 불신이 쌓였습니다. 어디서부터 시작하나요?

한 번의 큰 선언보다 작은 행동의 반복이 신뢰를 회복시킵니다. 리더라면 자기 실수를 먼저 공개하는 것에서 시작하세요. "이번 결정은 제가 잘못 판단했습니다"라는 한마디가, 다른 사람들에게 "여기선 실수를 인정해도 안전하다"는 신호가 됩니다. 그리고 작은 약속을 지키는 것을 반복하세요. 신뢰는 거창한 이벤트가 아니라, 지켜진 작은 약속들의 누적으로 쌓입니다.

온보딩 첫 30일 존중 체크리스트

새로 합류한 사람을 어떻게 맞이하느냐는 그 팀의 존중 문화를 가장 선명하게 드러냅니다. 첫 30일을 위한 체크리스트입니다.

[첫 1일차]
- [ ] 합류 첫날 환영 메시지를 팀 채널에 공개적으로 남긴다
- [ ] 개발 환경 세팅 문서가 최신인지 미리 확인해 둔다
- [ ] "모르는 건 언제든 물어봐도 된다"는 말을 명시적으로 전한다
- [ ] 점심이나 가벼운 1:1로 사람 대 사람으로 먼저 인사한다

[첫 1주차]
- [ ] 멘토 또는 버디를 한 명 지정해 준다
- [ ] 작고 안전한 첫 과제(쉬운 PR 한 건)를 함께 정한다
- [ ] 첫 PR에는 특히 따뜻하고 구체적인 리뷰를 남긴다
- [ ] "바보 같은 질문은 없다"는 것을 실제 반응으로 증명한다

[첫 2주차]
- [ ] 팀의 의사결정 방식과 권한 구조를 설명한다
- [ ] 과거의 주요 결정과 그 맥락(왜 이렇게 됐는지)을 공유한다
- [ ] 회의에서 한 번은 신입에게 직접 의견을 물어본다

[첫 30일]
- [ ] 1:1로 "지금까지 어땠는지" 솔직한 피드백을 양방향으로 나눈다
- [ ] 신입의 첫인상에서 나온 "왜 이렇게 하죠?" 질문을 진지하게 듣는다
      (외부의 눈은 우리가 못 보는 사각지대를 비춘다)
- [ ] 작은 기여라도 공개적으로 인정하고 이름을 언급한다

신입이 첫 달에 던지는 "왜 이렇게 하나요?"라는 순진한 질문은 사실 가장 값진 자산입니다. 그것은 우리가 너무 익숙해져 더 이상 의심하지 않는 것들을 다시 비춰주기 때문입니다. 그 질문을 "원래 그래"로 막는 순간, 팀은 외부의 눈 하나를 잃습니다.

실천 체크리스트

  • 이번 주 코드 리뷰에서 "당신"이라는 주어 대신 "이 코드"라는 주어로 코멘트를 작성한다.
  • 회의에서 한 번이라도 조용한 동료에게 직접 의견을 물어본다.
  • 누군가의 아이디어를 빌렸다면, 공개적으로 그 사람의 이름을 언급한다.
  • 내가 모르는 것을 "모르겠어요"라고 솔직히 말해 본다.
  • 동료의 집중 시간을 깨기 전에 "지금 잠깐 괜찮으세요?"라고 먼저 묻는다.
  • 논쟁에서 한 번쯤 "제가 틀렸을 수도 있겠네요"라고 먼저 인정해 본다.
  • 비동기 채널에 의견을 남겨, 말로 끼어들기 힘든 사람에게도 길을 열어준다.
  • 피드백을 줄 때 SBI(상황-행동-영향) 순서로 정리해 본다.
  • 다음 회고에서 "누가"가 아니라 "어떻게 가능했나"로 첫 질문을 연다.
  • 새로 합류한 동료의 첫 PR에 특히 따뜻하고 구체적인 리뷰를 남긴다.

마치며

소프트웨어의 품질은 결국 그것을 만든 사람들의 관계의 품질을 반영합니다. 서로를 존중하지 않는 팀이 만든 코드에는, 그 불신이 미묘하게 새겨집니다. 공유되지 않은 정보, 다뤄지지 않은 경고, 입을 닫아버린 사람들의 침묵으로 말이죠.

사람을 존중한다는 것은 거창한 일이 아닙니다. 끝까지 듣고, 공을 정확히 돌리고, 코드를 비판하되 사람을 비판하지 않고, 모르는 것을 모른다고 말할 수 있게 해주는 것. 이 작은 행동들이 쌓여 좋은 팀을 만들고, 좋은 팀이 좋은 소프트웨어를 만듭니다.

기억해 주세요. 우리가 만드는 것은 코드이지만, 우리가 함께 일하는 것은 사람입니다. 그리고 결국, 소프트웨어는 사람이 하는 일입니다.

참고 자료

Discuss on Twitter • View on GitHub