Skip to content
Published on

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

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
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가 만든 팀이 더 강했습니다. 이것이 "결국 사람이 하는 일"이라는 말의 의미입니다.

실천 체크리스트

  • 이번 주 코드 리뷰에서 "당신"이라는 주어 대신 "이 코드"라는 주어로 코멘트를 작성한다.
  • 회의에서 한 번이라도 조용한 동료에게 직접 의견을 물어본다.
  • 누군가의 아이디어를 빌렸다면, 공개적으로 그 사람의 이름을 언급한다.
  • 내가 모르는 것을 "모르겠어요"라고 솔직히 말해 본다.
  • 동료의 집중 시간을 깨기 전에 "지금 잠깐 괜찮으세요?"라고 먼저 묻는다.
  • 논쟁에서 한 번쯤 "제가 틀렸을 수도 있겠네요"라고 먼저 인정해 본다.
  • 비동기 채널에 의견을 남겨, 말로 끼어들기 힘든 사람에게도 길을 열어준다.

마치며

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

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

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

참고 자료

Discuss on Twitter • View on GitHub