One Hundred Years of Gossip

One Hundred Years of Gossip

Poooling·2026년 1월 7일·3

뒷담화로 팀을 망가뜨렸던 과거의 흑역사를 고백하며, 100년 전 '자네르츠의 첫 번째 법칙'을 통해 배운 진정한 동료애와 건강한 피드백 문화의 중요성을 다룹니다.

제목

"그 코드 누가 짰어?" 뒷담화로 팀을 박살 냈던 나의 흑역사 (feat. 100년 된 개발 원칙)

본문

솔직히 고백하겠습니다. 저는 과거에 꽤나 입이 거친 개발자였습니다. 소규모 스타트업에서 "야생형"으로 구르던 시절, 제 밥벌이의 반은 코딩이었고 나머지 반은 레거시 코드에 대한 욕설이었다고 해도 과언이 아닙니다.

화면이 멈추거나 DB 쿼리가 타임아웃을 낼 때마다 저는 습관적으로 옆 자리 동료에게 메신저를 날렸습니다. "아, 이 코드 로직 누가 짠 거예요? 진짜 생각 없이 짰네." 혹은 "기획팀은 왜 스펙을 이따위로 바꾸는 거죠?" 같은 말들이었죠. 당시의 저는 그게 '팀을 위한 정의로운 분노'라고 착각했습니다. 기술적 부채를 만든 원흉을 색출하고 비판하는 것이야말로 실력 있는 개발자의 태도라고 믿었으니까요.

하지만 그 정의감 넘치던 뒷담화가 결국 우리 팀을 어떻게 망가뜨렸는지, 저는 뼈저리게 겪어야 했습니다.

최근 한 아티클을 읽다가 얼굴이 화끈거려 혼났습니다. 1925년 독일의 브루더호프(Bruderhof) 공동체에서 제정된 '자네르츠의 첫 번째 법칙(First Law of Sannerz)'에 관한 이야기였습니다. 100년 전 룰이라니, 고리타분하게 들리시나요? 하지만 내용을 들여다보면 등골이 서늘해집니다.

"누군가의 약점 때문에 화가 난다면, 유일한 해결책은 사랑으로 그들에게 직접 이야기하는 것이다. 뒷담화는 절대 용납될 수 없다."

이 법칙을 만든 에버하르트 아놀드는 더 무서운 말을 덧붙입니다. "사랑 없는 사실은 살인이다(Truth without love kills)."

저는 이 문장을 보고 3년 전 제가 날렸던 코드 리뷰 코멘트 하나가 떠올랐습니다. 당시 저는 갓 입사한 주니어 개발자의 PR(Pull Request)에 대해 맹비난을 퍼부었습니다. 팩트만 나열했으니 문제없다고 생각했죠. "이 구조는 확장성이 전혀 없네요. 다시 짜세요." 심지어 그 친구가 없는 자리에서 다른 시니어와 "기본기가 부족하다"며 수군대기도 했습니다.

결과는 어땠을까요? 그 주니어 개발자는 더 이상 질문하지 않게 되었습니다. 모르는 게 있어도 저에게 물어보지 않고 혼자 끙끙 앓다가, 결국 프로덕션 배포 날 치명적인 버그를 냈습니다. 그리고 얼마 안 가 퇴사했죠. 제가 휘두른 '사랑 없는 사실'이 동료의 성장을 죽이고, 결국 프로젝트의 안정성까지 해친 셈입니다. 뒷담화는 스트레스 해소제가 아니라, 신뢰라는 자산을 갉아먹는 가장 확실한 바이러스였습니다.

지금 제가 몸담고 있는 대기업 환경은 스타트업 때보다 훨씬 복잡합니다. 유관 부서만 수십 곳이고, MSA(마이크로서비스 아키텍처)로 쪼개진 시스템만큼이나 팀 간의 장벽도 높습니다. "저쪽 API 팀이 문제야", "데브옵스 쪽 대응이 너무 느려"라며 손가락질하기 딱 좋은 환경이죠.

하지만 이제는 압니다. 누군가를 비난하고 싶을 때, 그 화살을 메신저 창이 아니라 당사자에게 직접 돌려야 한다는 것을요. 물론 어렵습니다. 100년 전 공동체 사람들도 "뒷담화 금지는 인간 본성을 거스르는 일"이라며 힘들어했다니까요.

그래서 저는 몇 가지 원칙을 세우고 실천하고 있습니다.

첫째, '제3자 개입 금지'입니다. A라는 개발자에 대한 불만은 A에게 직접 말하거나, 코드 리뷰 툴(GitLab, GitHub)에서 정식으로 논의합니다. B에게 가서 A를 흉보는 순간, 저는 팀을 깨뜨리는 공범이 됩니다.

둘째, 'Slack DM 대신 스레드 활용'입니다. 불만이나 의문점은 공개된 채널의 스레드에서 이야기합니다. "이거 왜 이렇게 짰어요?"가 아니라 "이 부분의 의도가 궁금합니다. 트래픽이 몰릴 때 리소스 이슈는 없을까요?"라고 묻습니다. 공개된 장소에서의 질문은 감정을 빼고 논리에 집중하게 만들어줍니다.

셋째, '사랑(존중)이 담긴 직설'입니다. AI 시대가 도래하면서 Cursor나 Copilot이 코드를 짜주는 세상이 왔습니다. 하지만 그 코드를 검증하고 책임을 지는 건 결국 사람입니다. 기계적인 완벽함보다 중요한 건, 실수를 통해 배우고 성장하려는 동료를 존중하는 마음입니다. 팩트를 말하되, 그 밑바탕에 '너를 비난하려는 게 아니라, 우리가 더 좋은 제품을 만들기 위함이야'라는 뉘앙스를 깔아야 합니다.

개발자로서 우리는 매일 기술적 부채(Technical Debt)를 갚기 위해 노력합니다. 하지만 더 무서운 건 '관계의 부채(Emotional Debt)'입니다. 뒷담화로 쌓인 부채는 리팩토링도 불가능합니다. 그저 팀 해체라는 파산 선고만 기다리고 있을 뿐이죠.

오늘 동료의 코드를 보고 한숨이 나오셨나요? 메신저를 켜고 옆 사람에게 험담을 늘어놓으려던 손을 멈추고, 잠시 숨을 고르시길 바랍니다. 그리고 그 동료에게 다가가(혹은 정중한 코멘트로) 직접 물어보세요. 그 작은 용기가, 100년 전 독일의 어느 시골 마을에서부터 내려온, 팀을 살리는 가장 강력한 기술일지도 모릅니다.

Poooling
PooolingAuthor

Poooling님의 다른 글

댓글 0

첫 번째 댓글을 남겨보세요!