개인적 공간/독서와 사색

사내정치

조금씩 차근차근 2026. 3. 5. 19:00

최근 A사에서 다대다 면접을 진행했다.

해당 면접은 A사의 인프라 면접관님과 백엔드 면접관님, J사의 IT기획 면접관님, A사의 HR 면접관님과 함께 다대다 면접이 진행됐다.

 

그 면접을 진행하면서, 나의 면접 답변에 잘못된 점이 있었는지, 기획 팀 리더셨던 면접관분의 표정이 굉장히 안좋아지셨다.

그래서, 면접관님께 넌지시 떠보듯 여쭤봤는데, 정말 따끔한 조언을 들었다.

 

이 인사이트가 정말 중요하고 귀중하다고 생각했기에, 다음과 같은 회고를 남긴다.

 

제목에서 나타내듯 토픽은 사내정치 이다.
사내 정치가 왜 발생할 수 밖에 없는지를, 그리고 일하는 마음가짐을 다룬다.

 

기획 면접관님은 다음과 같은 질문을 던지셨다.

 

요즘 AI가 발전하는 만큼,  개발자들도 AI와 경쟁하는 상황에 놓여있다.
이와 같이, 개발자들도 누군가와 경쟁하는 상황에 놓일 수 있다.
그렇다면, 당신은 어떻게 경쟁력을 확보할 것인가?

 

나는 이 질문을 듣고, 애초에 핀트를 잘못 잡았다.

AI가 경쟁의 대상이라고? 지금 AI덕분에 이렇게 압도적인 개발 속도를 갖고, 내가 상상하는 것이라면 무엇이든 7~8배 이상 빠르게 구현할 수 있게 되었다는 확신이 생겼는데? AI는 경쟁이 아니라 활용의 대상이다.

 

그래서 이와 같은 맥락으로 대답했다.

  • AI는 경쟁이 아니라, 협업의 대상이다.
  • AI가 없다면 내가 할 수 있는 일이 많이 없어지듯, 동료들이 없다면 내가 할 수 있는 일이 많이 줄어들게 된다.
  • 따라서, 동료들 또한, 경쟁이 아닌 협업의 대상으로 볼 것이다.

하지만, 이 답변 후 해당 면접관님의 표정은 급격히 안좋아졌다.

 

그래서 (궁금함을 참지 못한 나는) 면접관님께 해당 질문에 대한 의도 및 피드백을 넌지시 여쭤보았고, 정말 중요한 답변을 얻을 수 있었다.

 

  • 그런 마인드로는 회사에서 살아남을 수 없다.
  • 결국 기획자의 입장에서는, 예산은 한정되어 있다.
  • 더욱 많은 예산을 따내기 위해, 타 기획팀과 경쟁해야 한다.
    • 경쟁 과정에서, 우리 팀의 기획이 좀 더 타당함을 어필해야 하고,
    • 이를 위해 다양한 근거들을 제시해야 한다.
  • 그렇다면, 어떻게 해야 이 예산을 집행하는 최고 책임자분들 마음에 들 수 있을까?
    • 회사의 목적은 돈을 버는 것이다.
    • 결국, 이런 책임자분들에게 중요한 것은, 해당 기획이 돈을 벌 수 있다는 논리적인 근거이다.
    • 이 기술이 얼마나 "최신 기술"인지는 중요하지 않다.
      • 그래서, 그 변화가 어느정도의 재정적 가치를 가져올 수 있는지를 설득할 수 있어야 한다.
      • 이는 철저히 비즈니스 데이터 기반으로 누군가를 설득할 수 있는 능력에 기인한다. 
  • 그런 논점에 따르면, 개발자 또한 데이터 분석 능력이 필요하다는 관점이 맞나?
    • 정확하다. 결국 개발자도 경쟁 관계인 무언가들 중 하나를 선택해야 한다.
    • 타 기획보다 이 기획이 낫다는 논리적인 기준 & 비즈니스 데이터 분석 능력은 필수이다.

 

이 답변을 그림으로 풀어보자.

 

일반적인 회사의 기획부터 구현까지의 흐름을 살펴보면, 다음과 같다.

 

  • 먼저, 기획팀은 치열하게 자신의 기획이 좀 더 나음을 비즈니스 가치로 증명한다.
    • 이 과정에서, 기획자들 끼리의 사내 정치는 필연적이다.
    • 누군가 나의 기획을 도와 완성도를 함께 높여간다면, 전우애가 생기는 것은 당연할 것이다.
    • 다른 기획의 나의 기회를 뺏으려 한다면, 이를 이겨내기 위한 상대방에 대한 의식은 피할 수 없다.(비록 나중에 풀릴지라도)
  • 그 사이, 개발팀은 최신 기술 스터디 등, 기술 역량 함양에 집중한다.

즉, 이 경우는 기획 부분에서 발생하는 경쟁(사내 정치)가 개발자까지 전파되지 않는다.

그렇게 기획이 확정되면, 제한된 예산만큼으로 특정 요구사항을 만족시킬 것을 요청한다.

하지만, 개발자가 기획을 모른다면, 앞서 공부한 최신 기술 스터디는 의미가 없어진다.

왜냐? 예산은 최신 기술을 도전적으로 직접 사용해볼 만큼 주어지지 않는다.

 

기획자는 예산 및 기한을 개발자만큼 최신 트렌드에 맞춰 예측할 수 없다. 

이는 기한과 관련된 부분에선 더욱 그렇다.

기획에 배제된 개발자는 주어진 예산을 쥐여짜내는 데 집중해야 하고, 그래야 주어진 요구사항을 만족할 수 있다.

 

그렇게 예산에 맞춘 한 단계 낮은 선택지를 선택해야 하고, 이는 개발자들의 커리어 측면의 불안이 된다.

(주변에서 듣기론, AI를 많이 쓸 수록 "너무 AI 많이 쓰는 것 아니냐"는 피드백을 듣는 경우도 있다고 들었다.)

한 단계 낮춘 선택지 내에서도 최선의 결과를 내는 것 또한 개발자의 역량이라 생각한다.
그렇게 나는 꿋꿋히 코덱스 Plus 버전을 사용했다(...)

반대로, 이번엔 IT전문 기업들(예: 구글, 무신사)을 떠올려보자.

 

무신사의 경우, 모든 직원들이 다음 7가지의 기준으로 의사결정을 수행할 것을 권고한다.

 

  • 고객과 브랜드 중심의 사고: 고객과 파트너 브랜드의 성공을 최우선으로 생각합니다.
  • 오너십 (Ownership): 주도적으로 목표를 설정하고 책임감 있게 행동합니다.
  • 학습 역량 (Learning): 새로운 것을 배우고 성장하는 데 집중합니다.
  • 결과 집중 (Result Oriented): 단순히 열심히 하는 것이 아니라 실질적인 성과를 냅니다.
  • 단순화 (Simplification): 복잡한 문제를 단순하게 해결하여 효율을 높입니다.
  • 높은 기준 (High Standards): 더 높은 수준의 결과물을 향해 끊임없이 도전합니다.
  • 경계를 넘는 협업 (Cross-functional Collaboration): 경계 없이 소통하며 시너지를 만들어 냅니다.

여기서 "경계를 넘는 협업"에 주목할 수 있다.

이 부분은, 특히 IT 기업 및 IT 스타트업에서 많이 확인할 수 있었다.

 

 

이러한 회사들은, 개발자들 또한 기획에 적극 참여할 것을 권장한다.

개발자가 느끼는 예산과 기한 부분에 관련된 최적화는 개발자들이 수행하는 것이 압도적으로 유리하기 때문이다.

 

새로운 기술은 매번 개발되고 있다.

이들은 직접 사용해봐야 늘 수 있다.

 

이것이 유리하다 증명하는 것은 개발자의 몫이다.

 

 

하지만, 이때 발생하게 되는 독특한 단점이 있다.

엄연히 개발자가 

  • 기획자 A: 우리 기획, 중요도 A++입니다. 이것 먼저 구현해주세요.
  • 기획자 B: 우리 기획, 중요도 S++ 입니다. 이것 먼저 구현해주세요.
  • 나: 이 기능 분명 전사적으로 큰 도움이 될텐데, 이것 먼저 구현할 순 없나?

시간은 제한되어 있고, 결국 몇가지 기능은 구현하지 못할 수 있다.

 

결국, 결과만이 가장 이해되기 쉽다.

 

개발자가 생각한 기한 및 예산 최적화는 기획자들에 비해 미숙할 것이고,

분명 특정 기획의 기능은 다른 기획의 기능보다 부족할 수 있다.

기획을 잘 이해한 개발자는, 핵심 기능 구현으로 기획자의 가능성을 증명해줄 수 있다.

하지만, 기획을 잘못 이해한다면, 이는 핵심 기능의 누락으로 나타난다.

기획자가 보기 힘든 요구사항(예: 비기능 요구사항)은, 개발자의 깊은 기획 이해가 있어야 발견 가능하다.

 

기획을 부탁한 기획자는 기능의 불완전성에 불만족할 것이고, 더욱 정교하게 개발된 다른 산출물과 비교하게 되는 것이 사람의 마음이다.

 

이러한 애매함을 설득하지 못한다면,

이 결정이 단순한 나의 직감처럼 보이게 되고,

이는 사내 정치의 형태로 발산되게 된다.

 

이러한 형태의 경우에는, 개발자를 대표해 줄 대표자는 없다.

오로지 나의 선택은 나의 책임이 된다.

 

비즈니스 임팩트가 강한 기능을 우선 구현해야 한다.

비즈니스 임팩트가 적은 사소한 기능이 공수가 많이 든다면, 과감히 기획자와 해당 기능 제거를 협의해야 한다.

비즈니스 데이터 기반으로 기획을 완전히 이해하지 못한다면,

다른 말로 하면, 기획자의 언어를 이해하지 못한다면, 이는 불건강한 사내 정치의 형태로 나타나기 쉬워질 것이다.

결론은 다음과 같다.

  • 기획자의 언어를 이해하자.
    • 비즈니스 데이터를 이해하자.
    • 이는 기능의 우선순위 결정에 매우 유용하다.
  • 개발자의 언어를 기획자가 이해하기 쉽게 설명하자.
    • 비즈니스 데이터 스럽게 표현하자.
    • 도표/그림을 적극 활용해서 표현하자.
    • SLI/SLO를 함께 정의하자.

 

어째서, 언론에서 아무리 개발자가 고연봉을 받는다고 하지만, 실질적으로 기업의 최고 연봉을 담당하는 부서는 기획자인지 알 수 있었던, 냉철한 분석력이었다.

또한, 임원 바로 밑인 팀장 역할로, 어떻게 기획자로써 살아남을 수 있었는지를 보여주셨던 답변이었다.

 

왜 전통적 대기업의 개발자들이 최신 기술을 겪어보기 어려운지 이해할 수 있었고,

내가 얼마나 개발자만의 시선에서 좁게 보고 있었는지, 세상을 "아름답게" 보고 있었는지 확인할 수 있었다.

동시에 항상 누군가와 의견을 대립하고 다투는 역할을 앞장서서 해왔던 입장에서

나 자신을 믿을 수 있게 됨과 동시에 적지 않은 위로를 받을 수 있었다.

물론, 실제로 입사하게 되면 나의 생각과는 많이 다를 수도 있다.

하지만, 여러모로 배울 점이 많았던 시간이었다.

일단, 해당 부분을 열심히 학습하면, 많이 유용할 것 같단 생각이 든다.

 

개발자도 반드시 알아야 하는 핵심 비즈니스 데이터/지표

결국 개발자도 직원이기에, 다양한 부서의 사람들과 소통해야 한다.아무래도 가장 자주 소통하게 될 쪽은 기획일텐데, 일의 우선순위가 전사적 목표에 따라 결정되기 때문이다.회사의 입장에서

dev.go-gradually.me