대기업에서 유능한 엔지니어들이 나쁜 코드를 작성하는 이유

• 대형 기술기업의 짧은 근속 기간과 잦은 조직 개편으로 인해, 많은 엔지니어가 자신이 익숙하지 않은 코드베이스에서 작업을 함
• 코드 변경의 상당 부분이 입사 6개월 이내의 ‘초보자’ 수준 엔지니어에 의해 이루어지는 현실
• 일부 숙련된 ‘올드핸드’ 엔지니어가 품질을 보완하지만, 이들은 과중한 업무와 비공식적 책임으로 인해 한계 존재
• 기업은 전문성보다 인력 이동성과 가시성(legibility) 을 우선시하며, 이는 의도된 품질 저하의 대가
• 결과적으로, 엔지니어 개인의 역량과 무관하게 낯선 시스템에서 빠른 납기 중심으로 일하는 구조적 문제가 나쁜 코드의 근본 원인

---

대기업에서 나쁜 코드가 생기는 구조

• 대형 기술기업은 높은 연봉으로 유능한 엔지니어를 채용하지만, 근속 기간이 1~2년에 불과한 경우가 많음
  • 주식 보상(share grant)이 4년 만에 완전 귀속되어 이후 급여가 절반으로 줄어드는 구조
  • 일부 연간 리프레시(refresh)가 있지만, 보장되지 않아 엔지니어가 이직을 선택하게 됨
• 내부 이동까지 포함하면, 한 코드베이스에 3년 이상 머무는 경우는 드묾
  • 조직 개편(re-org)이 매년, 혹은 그보다 자주 발생
• 반면 코드베이스는 10년 이상 유지되는 경우가 많아, 대부분의 엔지니어가 새로운 시스템을 ‘익혀가는 중’
  • 결과적으로 코드 변경의 상당 부분이 입사 6개월 이내의 초보자에 의해 이루어짐

‘올드핸드’의 역할과 한계

• 일부 엔지니어는 특정 시스템에 오래 머물러 깊은 전문성을 갖게 됨
  • 이들은 코드 리뷰를 통해 문제를 조기에 발견할 수 있음
• 그러나 이 구조는 비공식적이며 제도화되지 않음
  • 기업은 장기 전문성 유지에 관심이 적고, 숙련자를 다른 팀으로 이동시키는 경우가 많음
• 숙련자는 항상 과중한 업무에 시달림
  • 모든 변경을 직접 검토할 시간 부족
  • 자신의 업무 성과가 줄면 오히려 불이익을 받을 위험 존재

평균적인 생산적 엔지니어의 현실

• 대기업의 평균적인 생산적 엔지니어는 다음과 같은 특징을 가짐
  • 채용 기준을 통과할 만큼 유능하지만, 새로운 코드베이스나 언어에 익숙하지 않음
  • 동시에 여러 프로젝트의 중첩된 마감 기한을 맞추며 일함
• 결과적으로, 품질보다 일정 중심의 환경에서 최선을 다하는 구조
  • 예: 초보 엔지니어가 낯선 코드의 버그를 임시방편으로 수정하고, 숙련자가 간단히 검토 후 배포
  • 이후 수년이 지나 해당 코드가 다시 발견되며 “왜 이런 코드가 작성됐나”라는 의문이 생김

기업이 이 구조를 유지하는 이유

• 대기업은 생산성보다 내부 가시성(legibility) 을 중시
  • 누가 어떤 일을 하는지, 언제든 재배치 가능한 구조를 선호
• 이는 전문성과 코드 품질을 희생하는 의도적 선택
  • 숙련도 손실을 감수하고, 문제 발생 시 빠르게 인력을 재배치할 수 있는 유연성을 확보
• 특히 AI 등 새로운 분야로의 빠른 전환(pivot) 이 중요해진 상황에서 이 전략은 기업에 유리하게 작동
• 그러나 이런 환경에서는 낯선 시스템에서 급하게 작업하는 엔지니어가 많아질 수밖에 없음

엔지니어 개인의 한계와 ‘순수/비순수’ 엔지니어링

• 개별 엔지니어는 이 구조를 바꿀 힘이 없음
  • 2025년 현재, 권력의 중심이 엔지니어에서 경영진으로 이동
  • 개인이 할 수 있는 최선은 특정 영역의 ‘올드핸드’가 되어 최소한의 품질을 지키는 것
• 그러나 과도한 개입은 오히려 성과 부족으로 평가(PIP) 를 받을 위험 존재
• 글은 ‘순수(pure)’와 ‘비순수(impure)’ 엔지니어링의 차이를 제시
  • 순수 엔지니어링: 독립적 기술 프로젝트(예: 프로그래밍 언어 개발) 중심
  • 비순수 엔지니어링: 낯선 시스템에서 일정 중심으로 일하는 현실적 환경
• 대기업 엔지니어는 대부분 비순수 엔지니어링에 속하며, 이 경우 나쁜 코드는 불가피한 부산물
  • 시스템이 충분히 작동하면 프로젝트는 성공으로 간주됨

결론: 구조적 원인으로서의 ‘낯선 코드베이스’

• 대기업은 엔지니어를 자유롭게 이동시킬 권한을 가지며, 이는 전문성 손실을 감수한 기업의 선택
• 나쁜 코드의 책임은 개인이 아니라 조직 구조와 인력 운용 방식에 있음
• 모든 엔지니어의 역량을 두 배로 높여도, 낯선 코드베이스에서의 실수는 여전히 발생
• 근본 원인은 “대부분의 엔지니어가 익숙하지 않은 코드에서 대부분의 일을 수행해야 하는 구조”임
• 나쁜 코드 사례를 지적하는 것은 개선에 도움이 되지만, 비난의 대상은 엔지니어가 아니라 시스템임

[sonnet]

경험상 CS, 특히 PLT가 튼튼하면 결국 어떤 환경에서든 비교적 나은 코드를 작성합니다.

썩 대단한 지식은 없어도 가장 기본적인 원칙을 이해하고있기만 한 사람이라면 시간이 넉넉하고 익숙한 코드라면 나름대로의 코드품질이 나옵니다. 리팩토링 n회 하면 AI가 짜도 나름 그럴듯해지죠.

한 소스를 아무리 오래 잡고있어도, 20년차라면서 스파게티 뽑는 것 밖에 할 줄 모르는, 왜 그러면 안되는지 모르는 분들도 많죠.

완벽한 환경에서 무한한 시간과 예산이 주어질 수 없는 한 그다지 큰 의미가 없는 공허한 내용으로 느껴집니다. 어떤 시대의 어떤 직무든 이건 똑같은 거 아닌가요?

같은 시스템에서 나은 코드를 작성하는 건 명백히 엔지니어의 능력이 맞습니다.

[sonnet]

시스템이 좋은 품질을 제공할 수 있도록 여유있고 유연하게 짜여있으면 좋겠죠. 그리고 분명 지금보다 조직공학과 개발방법론이 덜 발달한 시대에 비하면 평균적으로 그러할겁니다.

다만, 제 눈에는 엔지니어로서의 자아는 비대한데, 조직의 일원으로서의 책임감은 부족한 사람이 이 모든것이 자기 탓이 아니라 경영진의 잘못이라고 변명하는 것처럼 들리네요.

건축기사, 산업 디자이너, 애니메이터는 납기가 없고, 생산성이 아닌 창의성과 품질만으로 평가를 받는데 오직 프로그래머만 납기가 있나요?

[wahihi]

먼 개떡같이 다 있네..나쁜 코드니 좋은 코드니 하는건, 주니어들이 떠드는거고, 그 업종에 맞는 소프트웨어 설계를 잘하는 시니어 있냐? 없냐? 가 더 중요함..

[sonnet]

여기 올라오는 글은 대체로 OCP마저 무시하는 국내 SI시장의 일부 관점이나 경험과는 다소 다른 환경일 수 있습니다.

어쨌거나, 리누스 토르발즈는 주니어가 아니죠...

[GN⁺]

Hacker News 의견

• 이 사람의 글을 여러 번 읽었는데, 항상 뭔가 불편한 감정이 남았음
  이제 이유를 알 것 같음. 글의 분석 자체는 논리적이지만, 그 밑바탕에는 일종의 허무주의가 깔려 있는 듯함
  아마도 한때 이상주의자였지만 나쁜 경험으로 인해 ‘무언가를 믿는 건 헛된 일’이라 설명하려는 사람 같음
  그래서 이런 질문이 떠오름 — 왜 대기업은 이렇게 행동해야 하는가, 왜 나쁜 코드가 엔지니어를 괴롭히는가, 정말 그 감정이 잘못된 건가, 아니면 우리가 사는 경제 구조의 탓인가, 혹은 거대한 힘에 순응하는 게 성숙함인가 하는 의문들임

  • 나쁜 코드가 왜 그렇게 거슬리냐고?
    내가 그 결과에 책임을 져야 하기 때문임.
    다른 사람이 만든 엉망인 코드를 고치느라 일정은 밀리고, 그 탓에 연말 평가도 깎임
    “왜 이렇게 오래 걸렸냐”는 질문을 받지만, 그건 내가 쓰레기 더미를 헤치며 문제를 찾아야 했기 때문임
    이런 문제를 경영진에게 이해시키려 수년간 노력했지만, 결국 시지프스의 노동 같았음
  • 엔지니어가 나쁜 코드를 싫어하는 이유는 장인정신 때문임
    건축가가 엉성한 건물을 보면 답답해하듯, 영화감독이 허술한 영화를 보면 괴로워하듯, 좋은 엔지니어는 완성도를 추구함
    성숙이란 무력함에 순응하는 게 아니라, 가능한 한 싸워보는 것이라 생각함
    흥미롭게도, 글쓴이를 허무주의자라 부르지만 ‘세상이 통제 불가능하다’는 생각 자체가 이미 허무주의적임
  • 엔지니어와 비즈니스가 ‘나쁜 코드’의 기준을 다르게 정의함
    예전엔 나도 완벽하지 않으면 나쁜 코드라 생각했지만, 여러 회사를 거치며 관점이 바뀜
    이제는 비즈니스 목표를 충족하고 기본 품질선만 넘으면 괜찮다고 봄
    결국 대부분의 코드는 개선 여지가 있기 마련임
  • 이 블로그를 처음 봤을 때 “나만 그런 게 아니었구나”라는 안도감을 느꼈음
    Staff+ 엔지니어링의 냉정한 현실을 그대로 말해줘서 공감했음
    “회사가 원하는 걸 하라, 비록 그게 옳지 않더라도”라는 주장은 냉소적이지만, 회사의 톱니바퀴에 갈려나가는 것보단 낫다고 생각함
  • 글쓴이를 너무 과대해석하는 것 같음
    그는 단지 당신의 이상을 믿지 않을 뿐, 그게 곧 허무주의는 아님

• 문제는 근속연수가 아니라 동기부여의 문제라고 생각함
  영화 Office Space의 대사처럼, “열심히 일해도 보상이 없으면 동기가 생기지 않음”이라는 현실이 떠오름

  • 대기업 엔지니어들은 실제로 매우 동기부여되어 있음 (나는 Google 엔지니어임)
    하지만 경영진은 좋은 코드보다 결과를 중시함
    유지보수의 가치를 평가할 수 없으니, 그 일은 인정받지 못함
    결국 엉성한 코드를 배포한 사람이 승진함
  • 동기만으로는 충분하지 않음
    나는 팀과 코드를 아끼며 꼼꼼히 일했지만, 결국 PR 개수 같은 단순 지표로 평가받았음
    코드의 난이도나 팀 기여도는 무시되고, “눈에 보이는 숫자”만 중요했음
    결국 나를 평가하던 상사도 몇 달 뒤 해고됨
    아이러니하게도, 내가 무관심했다면 이런 일로 상처받지 않았을 것임

• 대기업은 엔지니어를 교체 가능한 자원으로 취급함
  이는 단순히 효율성 문제가 아니라, 권력 균형을 경영진 쪽으로 기울이기 위한 전략임
  핵심 프로젝트가 특정 엔지니어 집단에 의존하지 않게 하려는 의도임

  • 자본은 효율성을 일부 포기하더라도 노동의 힘을 약화시키려 함
    모든 노동자가 대체 가능하길 원함
  • 하지만 실제로 회사가 일부러 숙련된 엔지니어를 다른 팀으로 옮기는 경우는 드묾
    오히려 좋은 엔지니어를 붙잡기 위해 노력하는 경우가 많음
  • 사실 엔지니어들끼리도 “Bob만 아는 코드”를 욕함
    즉, 이런 문화는 경영진만의 문제는 아님

• 코드의 문법과 구조는 교과서적이지만, 근본적인 접근이 잘못된 경우를 자주 봄
  코드 리뷰는 문법에만 집중하고, 비즈니스 문제나 복잡도는 논의되지 않음
  단기적으로는 괜찮지만, 장기적으로는 기술 부채가 폭발함

  • 완전 공감함. 데이터베이스 스키마 같은 건 첫 스프린트에 박제되고, 이후엔 절대 리팩터링되지 않음
    그 결과, 사소한 코드 품질 논쟁으로 PR이 며칠씩 지연됨
  • 대기업에서도 똑같이 봄
    다들 표면적인 코드 청결에만 집착함
    논리적 타당성이나 큰 그림을 보는 건 어렵고, 리뷰어가 맥락을 모르는 경우도 많음
  • 좋은 요구사항 수집과 문서화, 제품 설계가 부족하면 장기적으로 유지 가능한 설계를 하기 어려움
    조직 전체가 이런 피드백을 수용할 여유가 없으면, 결국 ‘그럭저럭 굴러가는 시스템’ 에 의존하게 됨
  • 코드 리뷰에서 아키텍처 문제를 발견한다면, 이미 프로세스 단계에서 실패한 것임
    큰 설계는 코드 리뷰 전에 검토되어야 함
  • 이런 패턴은 AI 생성 코드에서도 자주 보임
    우리는 장기적 비용을 자동화하고 있는 셈임

• 대기업은 코드 자체에 관심이 없음
  코드는 단지 회사를 움직이게 하는 매개체일 뿐임
  결국 중요한 건 코드가 아니라 프로세스임
  시스템이 망가졌을 때 이를 복구할 수 있는 절차가 있느냐가 핵심임

• 모든 산업은 규모가 커지면 비슷한 절충을 함
  완벽보다는 ‘충분히 괜찮은’ 품질이 이익을 만듦
  IKEA 의자와 Herman Miller 의자의 차이처럼, 제약 조건이 다를 뿐임
  진짜 실력은 어디서 타협할지 아는 능력임
  대기업 구조는 이런 타협을 엔지니어에게 강요함

• 좋은 시니어 엔지니어는 처음부터 나쁜 코드를 쓰지 않음
  문제는 단기 성과 압박과 기초 부족임
  리뷰를 생략하거나 아키텍처를 충분히 고민하지 않는 게 진짜 원인임

  • 하지만 현실은 이미 너무 엉망이라, 좋은 코드를 쓸 수 없는 경우도 많음
    이 댓글에 묘사된 것처럼, 수백만 줄의 해킹이 누적된 코드 위에서는 아무리 노력해도 깨끗하게 만들 수 없음
    결국 스파게티 전체를 들어올리는 꼴이 됨
  • 결국 둘 다 맞음
    시니어는 ‘제대로 하기’와 ‘빨리 끝내기’ 사이에서 늘 딜레마에 놓임
  • 좋은 코드는 맥락 의존적임
    복잡한 코드베이스를 하루아침에 이해할 수 없고, 조직이 지식 축적을 중시하지 않으면 품질은 악화됨
    새 직원에게는 문서화나 정리 작업을 맡겨 코드의 구조를 익히게 하는 게 좋음
  • 또 다른 이유는 호환성 유지 요구 때문임
    기존의 해킹된 코드가 많아도, 깨뜨릴 수 없으니 손대지 못함
  • 내가 쓴 최악의 코드는 변경되는 요구사항 때문이었음
    아무리 뛰어난 설계라도, 기반이 모래 위라면 무너짐

• 글쓴이가 말한 ‘가독성이 품질보다 우선된다’는 결론은, 그렇다면 모든 대기업 프로젝트에 정적 분석 도구와 자동 포매터가 필수여야 한다는 뜻임
  하지만 현실은 그렇지 않음
  이런 도구 도입은 비기술 관리자의 결정이며, 그들은 단기 비용을 싫어함
  결국 출시 일정이 모든 걸 압도함

  • “두 번째 모니터는 필요 없다”는 식의 관리자가 이런 문화를 상징함

• 한 제조 대기업에서 컨설팅할 때, 코드 전반에 이상한 객체 모델링 패턴이 있었음
  원인을 추적하니, 설계자가 의도한 개념(청사진–주형–제품)을 개발팀이 완전히 오해했음
  수정하자고 했지만, 돌아온 답은 “이미 너무 늦었다”였음
  그 결과, 10년 넘게 잘못된 모델이 유지되며 막대한 기술 부채를 낳았음

  • “그래도 그 제품이 사람을 죽이진 않겠지?”라는 농담이 나올 정도였음

• 대기업의 짧은 근속연수 통계는 오해의 소지가 있음
  인원 급증으로 인해 중간값이 짧아진 것뿐임
  실제로는 퇴사자 기준으로 봐야 정확함

  • 같은 이유로, 고참 개발자 비율도 과소평가됨
    단순히 과거에는 개발자 수가 적었기 때문임