Stop Saying You Want Ownership Mindset
My 2nd article this week, I'm supposed to keep it to just once per week but whateverrr, I've had this...
개요 #
"오너십 마인드를 가진 엔지니어가 필요하다." 리더들이 입버릇처럼 하는 말이다. 그런데 정작 누군가 회의에서 진짜 오너십을 발휘하면, 그 사람은 순식간에 "까다로운 사람", "팀워크를 해치는 사람", "부정적인 사람"이 된다.
Dev.to에 올라온 이 글의 저자 Adam은 이 모순을 정면으로 겨냥한다. 관리자들은 슬로건은 사랑하지만 그 슬로건이 만들어내는 행동은 싫어한다는 것이다. 그가 여러 번 목격했다는 이 장면을, 한국 개발 조직에도 그대로 겹쳐 읽을 수 있다.
반복되는 각본 #
저자는 이 상황이 대본처럼 예측 가능하다고 말한다. 먼저 결정권을 쥔 사람이 이렇게 운을 뗀다.
"이 일은 진짜 오너십 있는 사람이 맡아야 해. 제품이 제대로 돌아가는지 신경 쓰는 사람 말이야."
그러면 누군가 실제로 아키텍처의 문제를 지적한다. 기분이 아니라 제약 조건, 데이터 모델, 장애 시나리오 같은 것. 새벽에 누군가를 깨울 바로 그 문제들이다. 그리고 90초 뒤, 같은 사람이 태도를 바꾼다.
"왜 이렇게 강하게 밀어붙여? 왜 이렇게 어렵게 굴어? 우리 이미 일정 늦었잖아. 그냥 배포해."
저자의 질문은 단순하다. 도대체 어느 쪽이냐고. 오너십을 요구했고, 상대는 오너십을 줬다. 그런데 이제 그 오너십에 의견이 딸려 왔다고 화를 낸다.
혼란이 아니라 편의의 문제다 #
저자는 한때 이걸 소통의 문제라고 생각했다고 한다. 아니었다. 인센티브의 문제였다.
지연은 오늘 체감되지만, 장애는 나중에 남의 일이 된다. 설계 단계의 반론은 이번 스프린트에 배포하려던 것을 늦춘다. 반면 그 반론이 막아준 사고는 다음 분기에, 그것도 다른 사람의 KPI 아래에서 터진다. 그러니 지금 눈앞의 고통을 줄이는 쪽으로 판단하게 된다.
위계는 위에서 내려다볼 때 효율처럼 느껴진다. 시니어의 결정에 질문이 붙으면 그건 엔지니어링이 아니라 무례로 읽힌다. 그 질문이 "이거 동시 쓰기 상황에서 데이터 깨집니다"일지라도 그렇다. 원한 건 "예"였는데 돌아온 건 "이유"였고, 자존심에게 이 둘은 전혀 다르게 느껴진다.
순응은 진전처럼 보인다. "네, 만들겠습니다"라는 말은 뭔가 움직이는 듯한 쾌감을 준다. "데이터 모델을 다시 생각해봐야 합니다"라는 말은 마찰처럼 느껴진다. 그래서 뇌는 게으른 계산을 한다. 마찰이 적으면 좋은 리더십이라고. 하지만 마찰이 적다는 건 실패가 더 조용히 진행된다는 뜻일 뿐이다.
게다가 '오너십'은 말하는 사람에 따라 뜻이 갈린다. 리더가 그 단어를 쓸 때는 보통 "배포되게 만들고 나 귀찮게 하지 마"에 가깝다. 엔지니어가 들을 때는 "우리를 망치지 않게 만들어"로 받아들인다. 이 둘은 충돌한다.
조용한 엔지니어는 아무것도 책임지지 않는다 #
여기서부터가 핵심이다. 시키는 대로, 매번, 웃으면서 구현하는 엔지니어는 오너십을 보여주는 게 아니다.
그들은 승인을 최적화하고, 충돌을 피하고, 지시를 따른다. 그 어느 것도 오너십이 아니다. 저자의 표현을 빌리면 그건 "책임 전가(liability transfer)"다. 나중에 문제가 터지면 완벽한 방패 문장이 준비되어 있다. "저는 명세대로 정확히 만들었는데요." 손은 깨끗하고 책임은 흩어진다.
반대로 "이거 나중에 우리 발목 잡습니다"라고 말하는 사람은, 그 결과를 자기 것으로 여기기 때문에 말하는 것이다. 그런 발언이 처벌받는 방에서 사회적 자본을 쓰고 있는 셈이다. 그런 사람을 벌주면, 그다음 세 사람이 입을 닫는 법을 배운다.
엔지니어 입장에서 본 진짜 오너십 #
저자는 오너십이 설계 리뷰에서 못되게 구는 게 아니라고 선을 긋는다. 그가 정리한 진짜 오너십은 이렇다.
- 우려는 일찍 나온다. 구현 3주 차, 방향을 틀면 스프린트 하나와 관계 하나가 날아가는 시점이 아니라 설계 단계에서.
- 기분이 아니라 근거로 말한다. "이 N+1 쿼리는 지금 성장 곡선이면 사용자 1만 명에서 죽습니다"가 "이거 좀 이상한데요"보다 낫다. 장애 시나리오를 설명하지 못하면 반문해도 된다. 설명한다면 들어야 한다.
- 거절이 아니라 대안을 낸다. "user_id로 인덱스 걸면 어떨까요?"는 오너십이다. "이거 안 될 거예요, 알아서 하세요"는 연기다.
- 에스컬레이션할 때와 일단 만들며 배울 때를 구분한다. 때로는 불완전한 걸 배포해 배워야 하고, 때로는 뻔한 지뢰를 향해 걷는 중이다. 좋은 오너는 지금이 어느 쪽 회의인지 알려준다.
- 결과까지 함께 남는다. "거봐, 내가 뭐랬어"는 오너십이 아니다. 내 판단이 틀렸다면 수습을 돕고, 맞았는데 무시당했더라도 수습을 돕는다. 다만 누가 무시했는지는 기억한다.
이걸 훈련으로 없애면 남는 것 #
저자는 이런 문화가 자리 잡는 과정을 여러 번 지켜봤다고 한다. 결과는 전혀 미묘하지 않다.
- "오래 가는 것을 만들자" 대신 "비난받지 말자"를 최적화하는 엔지니어
- 목소리 내는 게 커리어에 해가 되니 조용히 쌓이는 기술 부채
- 슬그머니 링크드인 프로필을 손보는 똑똑한 사람들
- 그런데도 리더십에게는 여전히 놀라운 사고들
- "팀 플레이어"가 "나쁜 결정에 토 달지 않는 사람"의 암호로 변질되는 현상
단기 속도를 사는 대신 중기 혼란을 치른다. 그러고 나서 회고를 잡는다. 모두가 "더 일찍 말했어야 했다"에 동의하지만, 정작 왜 사람들이 말하기를 그만뒀는지는 아무도 묻지 않는다.
정말 오너십을 원한다면 #
저자는 오너십을 성격 특성처럼 요구하지 말고, 그것을 발휘해도 안전한 조건을 만들라고 말한다.
설계 대화와 구현 대화를 분리하라. 스프린트를 이미 못 박기 전에, 이게 될지 안 될지 소리 내어 생각할 시간을 줘야 한다. 깊게 고민하는 것과 빠르게 배포하는 것은 원래 적이 아니다. 둘을 한 회의에 뭉개는 것이 문제다.
원한다고 말한 그 반론에 보상하라. 누군가 정당한 우려를 제기했는데 뒤집었다면, 그걸 눈에 보이는 결정으로 남겨라. 대화가 없었던 척하지 마라. 나중에 그가 옳았다면, 사람들 앞에서 소리 내어 인정하라. 틀렸다면 그는 도메인을 배운 것이다. 어느 쪽이든 신호는 하나다. 말을 꺼낸 건 잘한 일이었다고.
구체적으로 말하라. "오너십을 가져"는 쓸모없다. "금요일까지 지저분해도 배포해"라는 뜻이면 그렇게 말하라. "10배 트래픽을 견뎌야 해"라는 뜻이면 그렇게 말하라. 모호한 슬로건은 뭘 해야 덜 혼나는지 눈치 보는 사람만 만든다.
반론이 나오면 들어라. 늘 옳아서가 아니다. 엔지니어는 리더가 티켓으로만 보는 코드베이스 안에서 살기 때문이다. 그건 태도가 아니라, 애초에 그들을 뽑은 이유다.
의견 충돌을 정상으로 만들어라. 저자가 겪은 최고의 팀들은 설계를 두고 치열하게 싸우고도 다음 날 아침이면 서로를 신뢰했다. 반대는 개인적인 게 아니다. 그걸 개인적으로 만드는 순간 예스맨과 망가진 시스템이 남는다.
결론 #
저자의 마지막 정리는 이렇다. 당신은 아마 정말로 오너십 있는 엔지니어를 원할 것이다. 다만 당신이 자꾸 실수로 골라내고 있는 건, 웃으며 구현하고 당신이 벽에 부딪히도록 내버려 둔 채 인기를 유지하는 엔지니어다.
오너십은 성가시다. 불편한 질문을 던지고, "그냥 배포하자"는 회의를 늦추고, 시니어가 다 끝났다고 여기고 싶었던 결정을 다시 방어하게 만든다. 그게 피곤하게 들린다면 잘된 일이다. 그게 바로 실사용자가 건드리는 순간 무너지지 않는 무언가를 만드는 비용이니까.
"신경 쓰는 사람"과 "절대 반론하지 않는 사람"을 동시에 가질 수는 없다. 둘 중 하나를 고르라는 것이다. 그리고 순응을 골랐다면, 최소한 그걸 오너십이라고 부르지는 말라는 것이 저자의 마지막 일침이다.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.