엔터프라이즈 경험

• 대기업에서 1년간 일하며 기존 스타트업, SME 환경과 극명한 차이를 체감함
• 책임 소재 파악과 사내 프로세스가 복잡해지면서 소규모 조직에서는 문제되지 않던 점들이 해결 불가 과제로 바뀜
• 자원 낭비와 채용 기준의 불균형으로 인해 조직의 효율성과 동기 부여에 문제 발생함
• 업무 긴급성, 보안 관리 등 조직 내 주요 개념들이 실제 의미와 달리 형식적, 절차적 행위로 변질됨
• 다양한 문제 속에서도 역량 개발, 커리어 성장 등 긍정적 경험을 발견함

---

엔터프라이즈 경험 1년 회고

대기업과 스타트업의 차이

• $ENTERPRISE에서 첫 1년을 보내며 기존 스타트업 및 SME(중소기업)와의 차이를 경험함.
• 사내 소프트웨어 개발 경험 부족이 비판이 아니라 오히려 긍정적 신호임을 나중에 인식함.
• 관찰한 점을 정리하며 대기업 근무 환경의 현실을 소개함.

소기업에서 문제 없던 것이 대기업에서는 큰 문제로 변함

• Tool 관련 오류 해결 시, 책임자나 담당자 파악에 오랜 시간이 소요됨.
• 조직 내 정보 공유 부족 및 담당자 변경으로 인해 비효율과 비용 낭비가 발생함.
• 일시적 해결책은 로컬 설정 오버라이드이지만, 근본적으로 조직 구조적 한계임.

자원 배분의 비합리성

• 소규모 회사에서 충분한 예산 없이 일하던 경험과 달리, 대기업에서는 과도한 자원 낭비가 빈번함.
• 단기적 프로젝트 실패, 불필요한 클라우드 사용 등이 재정 낭비로 이어짐.
• 실제 필요와 동떨어진 예산 및 자원 관리로 업무 동기 저하를 초래함.

일관성 없는 동료 및 채용 구조

• 스타트업에서는 실력 기반 채용이 상대적 기준을 유지함.
• 대기업에서는 실력과 상관없는 채용 및 구조조정이 일반적임.
• 특정 직위가 업무 역량과 무관하거나, 보고서의 품질에 상관없이 조직이 유지되는 현상이 발생함.

업무의 긴급성 해석

• 스타트업에서는 명확한 긴급성이 기준이었지만, 대기업에서는 업무의 다층적 의미 해석이 필요함.
• 진짜 긴급 상황(예: 서비스 장애) 외에도 형식적 긴급성이 자주 발생함.
• 이러한 절차 속에서는 진정한 업무 우선순위 파악 역량이 요구됨.

형식화된 보안 관리

• 보안 프로세스는 조직에 중요한 역할이지만, 실제 리스크 대비 형식적 보고에 치중함.
• 수치 목표나 지표 달성을 위해 의미가 퇴색된 보안 업무가 일상화됨.
• 엔지니어와 보안 담당자 간 의사소통의 비효율도 존재함.
• 모두가 수치만 중시하는 문화가 위험함을 강조함.

직급의 무의미함

• "Head of Architecture" 등 중복 직책이 흔하며, 역할이 분명하지 않음.

불확실성을 약점으로 간주하는 조직 문화

• 대규모 조직 개편과 수시 구조조정 속에서 리더들은 "모르겠다"는 말을 금기시함.
• 도메인의 복잡성에도 불구하고, 리더십에서는 즉각성, 자신감만이 우선시됨.
• 이로 인해 과거의 실수가 반복되는 구조가 고착화됨.

사일로화된 엔지니어링 팀

• 각각의 엔지니어링 팀(혹은 '제국')은 자체 표준과 문화를 가짐.
• 부서 간 장애물이 커지고, 표준화나 베스트 프랙티스 확산이 어려워짐.
• 각 부서의 자율성이 팀 간 협력에 제한 요인으로 작용함.

긍정적 경험

• 엔지니어 커뮤니티 참여를 통해 소프트웨어 개발에 대한 관점 확장성 경험함.
• 커리어 성장, 멘토십 기회, 대규모 사용 경험 등 새로운 만족감 존재함.
• 전문성 고도화, 다양한 동료와의 협력, 교육과 역량 개발이 적극적으로 권장됨.
• 정기적 급여 지급, 직무 보장성과 같은 안정성도 장점으로 작용함.

결론

• 비판적 시각에도 불구하고 대기업의 긍정적 가치는 명확함.
• 향후 오랜 시간이 흐른 뒤 변화된 시각을 다시 점검해볼 의향임.

[GN⁺]

Hacker News 의견

• 항상 Remy's Law of Enterprise Software(관련 링크: https://thedailywtf.com/articles/graceful-depredations)을 기억해야 함. 소프트웨어가 "enterprise"라고 불린다면 보통 별로임. 농담은 제쳐두고, 글 마지막에 언급된 긍정적인 점들을 보고 흥미로웠음. 몇몇은 이해했지만, 실제로는 더 많은 문제만 만드는 것처럼 보이는 항목도 있었음. 예를 들어 "실제 경력 개발 기회가 있다"는 게 있는데, 경력 개발이 단순히 더 많은 돈을 번다는 의미면 그냥 "돈을 더 벌 수 있다"고 하지, 굳이 돌려 말할 필요는 없다고 생각함. 아니라면, 그동안 언급된 조직의 비효율과 문제 속에서 더 깊이 파묻히는 것 외에 경력 개발이란 게 무엇인지 궁금함. 그리고 "수백만 명이 사용하는 소프트웨어를 만드는 것은 만족스럽다"는 것도, 만약 그 소프트웨어가 좋지 않거나 사용자에게 해를 끼치면 여전히 만족스러운지 의문임

  • 경력 개발이 단순히 돈을 더 버는 것이라는 질문에 대해, 인생을 오래 고민하면 결국 우리는 훨씬 더 큰 시스템에서 작은 역할을 맡고 있다는 현실을 마주하게 됨. 이런 고민을 하다 보면 '부당한 사회에서 나는 정의로울 수 있을까?', '작은 역할을 맡은 내가 공동체에 긍정적인 영향을 미치려면 어떻게 해야 할까?' 같은 깊은 질문이 따라옴. 사람마다 이 질문에 대한 대응은 다름. 어떤 사람은 변화의 기회를 찾기 위해 적극적으로 움직이고, 반면 어떤 이는 시스템 내에서 무력감을 느끼고 아예 외면하게 됨. 내 경우 우리가 하는 일에 신념이 있고, 회사에서의 경력 개발은 단순히 돈이 아니라 책임이 늘고 변화를 일으킬 수 있는 역량이 높아지는 것임. 비효율적인 조직에서 내가 할 수 있는 선택지는 회사를 떠나거나, 현재 위치에 머무르거나, 조직 깊숙이 들어가 긍정적 변화를 만드는 것이 있음. "사용하는 소프트웨어가 나쁘거나 해를 끼치면 만족스러운가?"에 대한 질문에는, 어떤 사람은 해를 주는 일에도 만족한다고 답하겠지만, 적어도 나는 그런 사람이 아니며 내가 하는 일이 사회적으로 순기능이라고 믿음. "수백만 명이 사용하는 사회에 긍정적인 소프트웨어를 만드는 것은 만족스럽다"라는 뜻임

  • 대기업에서 경력 개발은 돈 이상의 의미가 있음. 예를 들어 더 큰 규모의 프로젝트를 리드하거나, 예전엔 스타트업 하나가 만들 법한 제품을 사내에서 전체 개발해볼 기회가 종종 생김. 몇 년간 여러 프로젝트에 참여하거나, 더 큰 규모의 팀을 이끄는 경험도 대기업에서는 상대적으로 얻기 쉬움. 그리고 소프트웨어가 나쁘거나 해가 된다면? 스타트업과 작은 회사가 무조건 더 좋은 건 아니고, 케이스마다 다름

  • 데이터 사이언티스트 연구원, 개발자 에반젤리스트 같은 직무를 꿈꾼다면 그 일을 지원해 줄 수 있는 조직이 필요함. 마이크로서비스 아키텍트 같은 역할도 소형 조직에서는 어울리지 않지만 3000명 이상 대기업에서는 환영받음. 엔지니어링 매니저 경로도 인력 풀이 충분해야 의미가 있듯, 규모에서 오는 경력 개발 기회가 있음. 소프트웨어가 나쁘거나 해로운 것도 있는데, 우리가 작업하는 게 반드시 엔터프라이즈 소프트웨어일 필요도 없고, 오히려 아니길 바람

  • 엔터프라이즈 소프트웨어가 본질적으로 나쁘다고 생각하지 않음. 물론 좋은 엔터프라이즈 소프트웨어도 충분히 만들 수 있는데, 복잡한 요구사항을 지키면서 그걸 해내는 것 자체가 상당한 능력임. 하지만 실제로 조직에서 사용자 경험에 얼마나 신경 쓰는지 평가받는 일은 드뭄. 심지어 내가 7년 넘게 $ENTERPRISE에 있으면서 사용자를 직접 만난 건 한 번뿐임

  • 소프트웨어가 나빠도, 해가 돼도 만족스러운가에 대해, 많은 엔지니어는 큰 규모에서 일하고 있다는 것에만 만족을 느끼거나, 무력감을 느껴 아예 자신과 무관하다고 여길 수 있음. 정말 그 스케일을 가지려면 거대 기업에 소속되어야만 하니까, 결국 거기서 반복되는 알고리즘적 다크 패턴, 주주 이익 극대화 등 자본주의 구조로 빠질 수밖에 없음

• 누락된 점이 있는데, 새로운 리더십이 들어오면 기존 구성원을 몰아내고 자기 사람들로 채운다는 점이 있음. 그리고 매년 팀 이름이 바뀌는데, 실제로 하는 일은 변하지 않고 팀 이름에 "Innovation", "Discovery", "Leadership" 같은 단어만 추가되는 일이 반복됨

  • 팀 이름이 그렇게 자주 바뀔 바에야 차라리 ‘Pikachu’ 같은 이름으로 고정해서 쭉 일했으면 함. 이름이 뭔지는 중요하지 않다는 걸 모두가 알면 이름 변경을 멈출 텐데, 이름 바뀔 때마다 문서 수정하고 전체에 알리는 데 불필요한 수고와 시간이 많이 들어감

  • 우리 조직에는 Terraform CDK로 만든 내부 인프라 코드 라이브러리가 있음. Datadog, Pagerduty에 모니터링 자원을 자동으로 생성해줌. 어느 날 ‘team’이라는 필수 인자가 사실상 7개월마다 바뀌다시피 해 그냥 삭제했음

  • 내 라이벌은 새로운 회사에 들어갈 때마다 예전 동료 전체 헬프 데스크, 개발팀을 천천히 다 데리고 옴. 그 이유는 충성도 때문임. 결과가 안 좋아도 불만도 없고, 윗선에 문제를 제기하지 않음. 이분 회사에서 일해본 전직 직원들의 말을 들어보면 항상 똑같이

    1. 문제점 진단(새로운 Microsoft 파트너 CRM이 없어서 문제라고 말함)
    2. 문제 해결 명목으로 돈을 들임(그 CRM 파트너와 Microsoft 덕에 연 3회 라스베이거스 출장)
    3. CRM 도입 실패(문제는 스코프가 충분히 크지 않아서라고 주장)
    4. 다시 프로젝트 범위 조정(복지 더 많아짐)
    5. 또 실패할 상황에서 새로운 회사로 이직하고 기존에는 문제만 남김

  • ‘Excellence’ 같은 단어가 프로젝트 명에 들어가면 대체로 신뢰가 가지 않음

• 본문의 내용은 대부분 공공기관에도 해당됨. 단, 주말 근무가 없다는 점, (기술적) 경력 개발의 기회가 있다는 점, 역량 개발이나 교육을 장려한다는 부분만 빼면 비슷함

  • 처음 나오는 재미와 재정적 이익에 대한 언급도 공공기관에는 그다지 해당되지 않는 것 같음

• 매우 재미있고 흥미로운 글이었음. 3년 정도 엔터프라이즈에 근무하고 있음. 기술적으로 성장하고 있지만, 실제로는 사람, 커뮤니케이션, 관료주의에 대해 더 많이 배우는 느낌임. 예산, 마우스에 관한 댓글도 공감함. 하지만 $ENTERPRISE의 재정적 안정성 덕에 그냥 내가 마우스를 직접 사버림. 누군가 승인 없는 마우스에 대해 문제를 제기할 수도 있지만... 그냥 무시하거나, 마우스 승인이라는 가짜 긴급함을 대수롭지 않게 넘길 수 있음

• 이런 조직에서는 도저히 견딜 수가 없음. 연봉을 3배를 준다고 해도 몇 달이면 완전히 무너짐

  • 보상금은 실제로 필요한 업무의 양과 반비례함

  • 정신과 약(졸로프트)를 아주 세게 복용해야 겨우 버틸 수 있음

  • 가끔은 돈을 우선순위로 두고 $ENTERPRISE에서 고연봉을 받고 충분히 모은 뒤 장기 안식년에 들어갈까 고민함. 하지만 면접 과정이 너무 힘들 것 같아 생각만으로도 의욕이 사라짐. 현재는 $MIDSIZENOLONGERSTARTUP에 있는데, 이곳 역시 나만의 방식으로 나를 지치게 만드는 여러 괴상한 일들이 있음

• 나도 유사한 환경에서 근무 중이며, 이 글이 고통스러울 정도로 정확하다고 느낌. 나는 내 일은 문제를 해결하고 소프트웨어를 배포하는 것이라 생각했지만 현실에서 조직의 ‘진짜 우선순위(revealed preferences, 관련 링크: https://en.wikipedia.org/wiki/Revealed_preference)’는 전혀 아님. 저자가 작은 회사에서 대기업으로 이직한 이야기처럼, 혹시 반대로 대기업에서 작은 회사로 옮긴 경험이 있는 사람이 있는지 궁금함. 엔터프라이즈 경험을 어떻게 소규모 팀 면접 때 어필하면 좋을지도 듣고 싶음

  • 내 경험에 따르면 이것은 마치 두 도시 이야기임. 나도 $ENTERPRISE에서 의미 없는 시간 낭비에 지쳐서 이제는 연봉 20%를 포기해서라도 작고 제대로 된 곳에서 무언가 성과를 내고 싶음. 그런데 지난 3년 동안 배운 것을 부정적 분위기 없이 설명하려 해도 스타트업 창업자들은 내 경력을 다소 부담스럽게 봄. 정글에서 필요한 생존 스킬과 동물원에서 필요한 생존 스킬이 너무 달라서, 동물원에 너무 오래 있었던 게 아니냐는 반응임. 반대로 대기업도 내부 프로세스와 계층 구조를 이해하는 사람을 뽑길 원해서, 스타트업 출신이 이런 곳에 면접보는 것도 쉽지 않음

  • 큰 회사에서 작은 회사로 옮긴 경험이 있는데, 회사 규모가 커질수록 풀어야 할 문제는 기술적인 것보다 사람과 조직 내 정치 문제가 훨씬 커짐. 대기업에서는 골든 핸드커프(관련 링크: https://en.wikipedia.org/wiki/Golden_handcuffs)식 보상으로 핵심 인재를 붙잡는 경우가 많고, 이 때문에 사람들이 보상을 포기하기 전까지는 조직의 각종 헛소리도 더 참고 견딤. "대기업을 떠나 실제 변화를 만들어내고 싶었다"는 식으로 스토리를 풀면 작은 팀에서는 대체로 이해해줌

• 대기업은 그들만의 결과물을 일관성 있게 제공하려고만 신경 씀. 목표 설정도 숫자 달성, 규제 절차, 임원의 결정 등 다양한 이유로 결정됨. 우리가 생각하는 인간적 합리성과는 전혀 다른 영역임

• "다른 제국들도 있다"는 원 글에 대해, 실제로 영국(매뉴얼 QA), 이집트(소프트웨어 피라미드) 외에도 몽골(어느 날 갑자기 가득한 요구사항을 던지고 사라짐), 스페인(모든 규정을 완벽하게 하려다 오히려 마찰만 많아짐), 일본(임원에게 질책당하고 커리어를 자해하는 모험을 함), 중국(회의의 미로에 빠지고 소통이 극도로 은밀함) 같은 식의 우스갯소리를 곁들임

  • 이 글 정말 즐겁게 읽었고, 특히 몽골과의 전쟁 비유가 재밌었음. 실제로 역사적으로도 몽골과의 싸움은 녹록지 않았음

• 좋은 인사이트와, 사무실 정치 및 경영진의 역할에 대한 중요성을 잘 전달해 준 글임

• 18개월째 $ENTERPRISE에 재직 중임. 현실에 너무 공감해서 아플 정도임