완벽한 아키텍처 제안서가 임원 책상에서 3분 만에 휴지조각 된 이유 (feat. 통역의 기술)

솔직히 고백합니다.

저는 삼성전자 시절, '기술적 우아함'이 곧 비즈니스의 정답이라고 믿었던 순진한 기획자였습니다.

모놀리식(Monolithic) 구조가 낡아 빠졌으니 MSA(Microservices Architecture)로 가야 한다고 주장했었죠.

밤새워 만든 50장짜리 장표를 들고 임원 보고를 들어갔습니다.

기술적 당위성, 배포 속도, 최신 트렌드까지 완벽했습니다.

그런데 상무님이 딱 한 마디 하시더군요.

"그래서, 이거 하면 매출이 얼마나 오르나? 안 하면 우리 서비스 멈추나?"

저는 꿀 먹은 벙어리가 되었습니다.

얼굴이 화끈거려 쥐구멍에라도 숨고 싶더군요.

결국 그 프로젝트는 '시기상조'라는 딱지가 붙어 드랍(Drop) 되었습니다.

오늘 소개할 이야기는 바로 이 '엔지니어와 경영진 사이의 거대한 통역 장벽'에 관한 것입니다.

Kooth의 CTO인 Anna Shipman이 쓴 글을 보는데, 제 흑역사가 주마등처럼 스쳐 지나가더군요.

개발자나 PM들이 흔히 착각하는 게 있습니다.

내 제안이 기술적으로 옳으면, 경영진도 당연히 OK 할 것이라는 믿음입니다.

하지만 현실은 냉혹합니다.

여러분이 아무리 쿠버네티스(Kubernetes)의 오토스케일링 효율성을 침 튀기며 설명해도,

그들의 귀에는 외계어로 들릴 뿐입니다.

왜 내 완벽한 제안서가 임원 책상에서 먼지만 쌓이다가 반려되는지, 그 이유를 뼛속 깊이 파헤쳐 드립니다.

1. 임원도 '월급쟁이'이자 '을'이다

우리는 흔히 CEO나 C-Level 임원들이 절대 권력자라고 생각합니다.

천만의 말씀입니다.

그들에게도 상사가 있습니다.

바로 주주, 이사회, 그리고 시장(고객)입니다.

여러분이 팀장 눈치를 보듯, 그들도 투자자들의 눈치를 봅니다.

CEO의 머릿속은 '코드 퀄리티'가 아니라 '생존'과 '숫자'로 가득 차 있습니다.

회사의 방향을 정하고, 돈과 사람(Resource)을 어디에 태울지 결정하고, 리스크를 방어해야 합니다.

그러니 여러분의 제안이 단순히 "코드가 깔끔해집니다" 수준이라면?

그건 그들의 생존 숙제에 아무런 도움이 안 됩니다.

여러분의 제안이 그들의 상사(주주/고객)를 만족시키는 데 어떻게 기여하는지 증명해야 합니다.

2. 그들은 당신보다 바쁜 게 아니라, 볼 게 너무 많다

"상무님은 왜 내 보고서를 꼼꼼히 안 읽으실까?"

무시당했다고 생각하지 마십시오.

물리적으로 불가능한 겁니다.

엔지니어링 매니저는 팀원 6명을 챙기지만, CTO는 수백 명을, CEO는 회사 전체를 봅니다.

'관리의 범위(Span of Control)'가 다릅니다.

그들이 한 가지 안건에 쏟을 수 있는 시간은 여러분의 1/100도 안 됩니다.

그 짧은 3분 안에 승부를 봐야 합니다.

서론 다 빼고, 기술 용어 다 걷어내고, '핵심 가치'만 던져야 합니다.

3. 부분 최적화 vs 전체 최적화

개발팀 입장에선 리팩토링이 지상 최대의 과제일 수 있습니다.

하지만 경영진은 '회사 전체의 이익'을 저울질합니다.

엔지니어링 팀의 생산성이 20% 오르더라도, 그 기간 동안 마케팅이나 영업 쪽의 신규 기능 배포가 막힌다면?

그건 회사 입장에서 손해(Loss)입니다.

여러분의 제안이 엔지니어링 사일로(Silo) 안에서만 좋은 일인지,

아니면 회사 전체의 재무제표나 고객 경험에 긍정적인 영향을 주는지 따져봐야 합니다.

"우리 팀이 편해져요"는 최악의 설득 논리입니다.

4. 임원들이 무조건 던지는 질문 리스트 (미리 준비 안 하면 털린다)

제가 수많은 임원 회의에서 털리면서 깨달은, 그들의 공통 질문 패턴이 있습니다.

이건 Anna Shipman이 정리한 내용과 소름 돋게 일치합니다.

제안서 들고 가기 전에 자문자답해보십시오.

"비용(Cost)은 얼마인가?"
(단순 개발비뿐만 아니라 운영비, 기회비용 포함)

"그 돈 쓰면 우린 뭘 얻나? (ROI)"
(구체적인 숫자나 비즈니스 임팩트로 대답해야 함)

"다른 대안은 없나?"
(무조건 신기술이 답이 아님을 증명해야 함)

"왜 하필 지금인가? 안 하면 어떻게 되나?"
(가장 중요한 질문. 안 했을 때의 리스크가 비용보다 커야 승인남)

"실패하면 어떻게 수습할 건가?"
(롤백 플랜이나 리스크 완화책이 없으면 아마추어 취급받음)

이 질문들은 여러분을 괴롭히려고 하는 게 아닙니다.

그들이 자원 배분의 책임을 지기 위해 반드시 확인해야 할 체크리스트입니다.

이 질문에 버벅거리는 순간, 여러분의 신뢰도는 바닥을 칩니다.

결국은 '번역(Translation)'이다

엔지니어링은 복잡하고 전문적입니다.

그걸 그대로 들고 가서 "이해해 주세요"라고 떼쓰는 건 직무 유기입니다.

훌륭한 시니어 개발자나 PM이라면 '통역사'가 되어야 합니다.

API, CI/CD, 기술 부채 같은 용어를

'시장 출시 속도(Time to Market)', '운영 비용 절감(OpEx Saving)', '리스크 관리'라는 비즈니스 언어로 번역하십시오.

제가 삼성에서 50장짜리 장표로 깨졌을 때,

만약 "이걸 도입하면 연간 서버 비용을 30억 절감하고, 신규 서비스 런칭 주기를 2주에서 3일로 단축해 경쟁사를 따돌릴 수 있습니다"라고 첫마디를 뗐다면 어땠을까요?

아마 결과는 달랐을 겁니다.

기술만 아는 기술자는 부품으로 남지만,

비즈니스를 이해하고 통역할 줄 아는 기술자는 리더가 됩니다.

오늘도 혁신을 꿈꾸며 보고서를 쓰는 여러분,

부디 저처럼 회의실에서 식은땀 흘리지 마시고,

임원의 언어로 무장해서 멋지게 승인받으시길 바랍니다.