# 대기업에서 유능한 엔지니어들이 나쁜 코드를 작성하는 이유 > Clean Markdown view of GeekNews topic #24710. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24710](https://news.hada.io/topic?id=24710) - GeekNews Markdown: [https://news.hada.io/topic/24710.md](https://news.hada.io/topic/24710.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-11-29T20:33:11+09:00 - Updated: 2025-11-29T20:33:11+09:00 - Original source: [seangoedecke.com](https://www.seangoedecke.com/bad-code-at-big-companies/) - Points: 17 - Comments: 5 ## Summary 대기업의 코드 품질 문제는 개인 역량보다 **조직 구조와 인력 운용 방식**의 산물임을 짚습니다. 잦은 **조직 개편과 짧은 근속 주기** 속에서 대부분의 엔지니어가 낯선 코드베이스를 다루며, 품질보다 **납기 중심의 ‘비순수 엔지니어링’**이 일상이 됩니다. 일부 **‘올드핸드’ 엔지니어**가 품질을 지탱하지만, 이들의 역할은 제도화되지 않아 지속 가능하지 않습니다. 결국 나쁜 코드는 게으름의 결과가 아니라, **전문성보다 이동성과 가시성을 중시하는 시스템 설계의 부산물**이라는 통찰이 인상적입니다 — 구조를 이해하면 비난보다 개선의 방향이 보입니다. ## Topic Body - 대형 기술기업의 **짧은 근속 기간과 잦은 조직 개편**으로 인해, 많은 엔지니어가 자신이 익숙하지 않은 코드베이스에서 작업을 함 - 코드 변경의 상당 부분이 **입사 6개월 이내의 ‘초보자’ 수준 엔지니어**에 의해 이루어지는 현실 - 일부 숙련된 **‘올드핸드’ 엔지니어**가 품질을 보완하지만, 이들은 과중한 업무와 비공식적 책임으로 인해 한계 존재 - 기업은 **전문성보다 인력 이동성과 가시성(legibility)** 을 우선시하며, 이는 의도된 품질 저하의 대가 - 결과적으로, 엔지니어 개인의 역량과 무관하게 **낯선 시스템에서 빠른 납기 중심으로 일하는 구조적 문제**가 나쁜 코드의 근본 원인 --- ### 대기업에서 나쁜 코드가 생기는 구조 - 대형 기술기업은 높은 연봉으로 유능한 엔지니어를 채용하지만, **근속 기간이 1~2년에 불과**한 경우가 많음 - 주식 보상(share grant)이 4년 만에 완전 귀속되어 이후 급여가 절반으로 줄어드는 구조 - 일부 연간 리프레시(refresh)가 있지만, 보장되지 않아 엔지니어가 이직을 선택하게 됨 - 내부 이동까지 포함하면, **한 코드베이스에 3년 이상 머무는 경우는 드묾** - 조직 개편(re-org)이 매년, 혹은 그보다 자주 발생 - 반면 코드베이스는 10년 이상 유지되는 경우가 많아, **대부분의 엔지니어가 새로운 시스템을 ‘익혀가는 중’** - 결과적으로 코드 변경의 상당 부분이 **입사 6개월 이내의 초보자**에 의해 이루어짐 ### ‘올드핸드’의 역할과 한계 - 일부 엔지니어는 특정 시스템에 오래 머물러 **깊은 전문성**을 갖게 됨 - 이들은 코드 리뷰를 통해 문제를 조기에 발견할 수 있음 - 그러나 이 구조는 **비공식적이며 제도화되지 않음** - 기업은 장기 전문성 유지에 관심이 적고, 숙련자를 다른 팀으로 이동시키는 경우가 많음 - 숙련자는 **항상 과중한 업무**에 시달림 - 모든 변경을 직접 검토할 시간 부족 - 자신의 업무 성과가 줄면 오히려 불이익을 받을 위험 존재 ### 평균적인 생산적 엔지니어의 현실 - 대기업의 평균적인 생산적 엔지니어는 다음과 같은 특징을 가짐 - 채용 기준을 통과할 만큼 유능하지만, **새로운 코드베이스나 언어에 익숙하지 않음** - 동시에 여러 프로젝트의 **중첩된 마감 기한**을 맞추며 일함 - 결과적으로, **품질보다 일정 중심의 환경**에서 최선을 다하는 구조 - 예: 초보 엔지니어가 낯선 코드의 버그를 임시방편으로 수정하고, 숙련자가 간단히 검토 후 배포 - 이후 수년이 지나 해당 코드가 다시 발견되며 “왜 이런 코드가 작성됐나”라는 의문이 생김 ### 기업이 이 구조를 유지하는 이유 - 대기업은 **생산성보다 내부 가시성(legibility)** 을 중시 - 누가 어떤 일을 하는지, 언제든 재배치 가능한 구조를 선호 - 이는 **전문성과 코드 품질을 희생하는 의도적 선택** - 숙련도 손실을 감수하고, 문제 발생 시 빠르게 인력을 재배치할 수 있는 유연성을 확보 - 특히 AI 등 새로운 분야로의 **빠른 전환(pivot)** 이 중요해진 상황에서 이 전략은 기업에 유리하게 작동 - 그러나 이런 환경에서는 **낯선 시스템에서 급하게 작업하는 엔지니어**가 많아질 수밖에 없음 ### 엔지니어 개인의 한계와 ‘순수/비순수’ 엔지니어링 - **개별 엔지니어는 이 구조를 바꿀 힘이 없음** - 2025년 현재, 권력의 중심이 엔지니어에서 경영진으로 이동 - 개인이 할 수 있는 최선은 특정 영역의 **‘올드핸드’가 되어 최소한의 품질을 지키는 것** - 그러나 과도한 개입은 오히려 **성과 부족으로 평가(PIP)** 를 받을 위험 존재 - 글은 **‘순수(pure)’와 ‘비순수(impure)’ 엔지니어링**의 차이를 제시 - 순수 엔지니어링: 독립적 기술 프로젝트(예: 프로그래밍 언어 개발) 중심 - 비순수 엔지니어링: 낯선 시스템에서 일정 중심으로 일하는 현실적 환경 - 대기업 엔지니어는 대부분 **비순수 엔지니어링**에 속하며, 이 경우 **나쁜 코드는 불가피한 부산물** - 시스템이 충분히 작동하면 프로젝트는 성공으로 간주됨 ### 결론: 구조적 원인으로서의 ‘낯선 코드베이스’ - 대기업은 엔지니어를 자유롭게 이동시킬 권한을 가지며, 이는 **전문성 손실을 감수한 기업의 선택** - 나쁜 코드의 책임은 개인이 아니라 **조직 구조와 인력 운용 방식**에 있음 - 모든 엔지니어의 역량을 두 배로 높여도, **낯선 코드베이스에서의 실수는 여전히 발생** - 근본 원인은 “대부분의 엔지니어가 **익숙하지 않은 코드에서 대부분의 일을 수행**해야 하는 구조”임 - 나쁜 코드 사례를 지적하는 것은 개선에 도움이 되지만, **비난의 대상은 엔지니어가 아니라 시스템**임 ## Comments ### Comment 46985 - Author: sonnet - Created: 2025-11-30T20:17:43+09:00 - Points: 1 경험상 CS, 특히 PLT가 튼튼하면 결국 어떤 환경에서든 비교적 나은 코드를 작성합니다. 썩 대단한 지식은 없어도 가장 기본적인 원칙을 이해하고있기만 한 사람이라면 시간이 넉넉하고 익숙한 코드라면 나름대로의 코드품질이 나옵니다. 리팩토링 n회 하면 AI가 짜도 나름 그럴듯해지죠. 한 소스를 아무리 오래 잡고있어도, 20년차라면서 스파게티 뽑는 것 밖에 할 줄 모르는, 왜 그러면 안되는지 모르는 분들도 많죠. 완벽한 환경에서 무한한 시간과 예산이 주어질 수 없는 한 그다지 큰 의미가 없는 공허한 내용으로 느껴집니다. 어떤 시대의 어떤 직무든 이건 똑같은 거 아닌가요? 같은 시스템에서 나은 코드를 작성하는 건 명백히 엔지니어의 능력이 맞습니다. ### Comment 46987 - Author: sonnet - Created: 2025-11-30T20:23:31+09:00 - Points: 1 - Parent comment: 46985 - Depth: 1 시스템이 좋은 품질을 제공할 수 있도록 여유있고 유연하게 짜여있으면 좋겠죠. 그리고 분명 지금보다 조직공학과 개발방법론이 덜 발달한 시대에 비하면 평균적으로 그러할겁니다. 다만, 제 눈에는 엔지니어로서의 자아는 비대한데, 조직의 일원으로서의 책임감은 부족한 사람이 이 모든것이 자기 탓이 아니라 경영진의 잘못이라고 변명하는 것처럼 들리네요. 건축기사, 산업 디자이너, 애니메이터는 납기가 없고, 생산성이 아닌 창의성과 품질만으로 평가를 받는데 오직 프로그래머만 납기가 있나요? ### Comment 46978 - Author: wahihi - Created: 2025-11-30T18:04:59+09:00 - Points: 2 먼 개떡같이 다 있네..나쁜 코드니 좋은 코드니 하는건, 주니어들이 떠드는거고, 그 업종에 맞는 소프트웨어 설계를 잘하는 시니어 있냐? 없냐? 가 더 중요함.. ### Comment 46982 - Author: sonnet - Created: 2025-11-30T20:11:00+09:00 - Points: 1 - Parent comment: 46978 - Depth: 1 여기 올라오는 글은 대체로 OCP마저 무시하는 국내 SI시장의 일부 관점이나 경험과는 다소 다른 환경일 수 있습니다. 어쨌거나, 리누스 토르발즈는 주니어가 아니죠... ### Comment 46966 - Author: neo - Created: 2025-11-29T20:33:12+09:00 - Points: 2 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=46082223) - 이 사람의 글을 여러 번 읽었는데, 항상 뭔가 **불편한 감정**이 남았음 이제 이유를 알 것 같음. 글의 분석 자체는 논리적이지만, 그 밑바탕에는 일종의 **허무주의**가 깔려 있는 듯함 아마도 한때 이상주의자였지만 나쁜 경험으로 인해 ‘무언가를 믿는 건 헛된 일’이라 설명하려는 사람 같음 그래서 이런 질문이 떠오름 — 왜 대기업은 이렇게 행동해야 하는가, 왜 나쁜 코드가 엔지니어를 괴롭히는가, 정말 그 감정이 잘못된 건가, 아니면 우리가 사는 경제 구조의 탓인가, 혹은 거대한 힘에 순응하는 게 성숙함인가 하는 의문들임 - 나쁜 코드가 왜 그렇게 거슬리냐고? 내가 그 **결과에 책임**을 져야 하기 때문임. 다른 사람이 만든 엉망인 코드를 고치느라 일정은 밀리고, 그 탓에 연말 평가도 깎임 “왜 이렇게 오래 걸렸냐”는 질문을 받지만, 그건 내가 쓰레기 더미를 헤치며 문제를 찾아야 했기 때문임 이런 문제를 경영진에게 이해시키려 수년간 노력했지만, 결국 **시지프스의 노동** 같았음 - 엔지니어가 나쁜 코드를 싫어하는 이유는 **장인정신** 때문임 건축가가 엉성한 건물을 보면 답답해하듯, 영화감독이 허술한 영화를 보면 괴로워하듯, 좋은 엔지니어는 완성도를 추구함 성숙이란 무력함에 순응하는 게 아니라, 가능한 한 싸워보는 것이라 생각함 흥미롭게도, 글쓴이를 허무주의자라 부르지만 ‘세상이 통제 불가능하다’는 생각 자체가 이미 허무주의적임 - 엔지니어와 비즈니스가 **‘나쁜 코드’의 기준**을 다르게 정의함 예전엔 나도 완벽하지 않으면 나쁜 코드라 생각했지만, 여러 회사를 거치며 관점이 바뀜 이제는 비즈니스 목표를 충족하고 기본 품질선만 넘으면 괜찮다고 봄 결국 대부분의 코드는 개선 여지가 있기 마련임 - 이 블로그를 처음 봤을 때 “나만 그런 게 아니었구나”라는 안도감을 느꼈음 **Staff+ 엔지니어링의 냉정한 현실**을 그대로 말해줘서 공감했음 “회사가 원하는 걸 하라, 비록 그게 옳지 않더라도”라는 주장은 냉소적이지만, 회사의 톱니바퀴에 갈려나가는 것보단 낫다고 생각함 - 글쓴이를 너무 과대해석하는 것 같음 그는 단지 **당신의 이상**을 믿지 않을 뿐, 그게 곧 허무주의는 아님 - 문제는 근속연수가 아니라 **동기부여**의 문제라고 생각함 영화 *Office Space*의 대사처럼, “열심히 일해도 보상이 없으면 동기가 생기지 않음”이라는 현실이 떠오름 - 대기업 엔지니어들은 실제로 **매우 동기부여**되어 있음 (나는 Google 엔지니어임) 하지만 경영진은 좋은 코드보다 **결과**를 중시함 유지보수의 가치를 평가할 수 없으니, 그 일은 인정받지 못함 결국 엉성한 코드를 배포한 사람이 승진함 - 동기만으로는 충분하지 않음 나는 팀과 코드를 아끼며 꼼꼼히 일했지만, 결국 **PR 개수** 같은 단순 지표로 평가받았음 코드의 난이도나 팀 기여도는 무시되고, “눈에 보이는 숫자”만 중요했음 결국 나를 평가하던 상사도 몇 달 뒤 해고됨 아이러니하게도, 내가 무관심했다면 이런 일로 상처받지 않았을 것임 - 대기업은 엔지니어를 **교체 가능한 자원**으로 취급함 이는 단순히 효율성 문제가 아니라, **권력 균형을 경영진 쪽으로 기울이기 위한 전략**임 핵심 프로젝트가 특정 엔지니어 집단에 의존하지 않게 하려는 의도임 - 자본은 효율성을 일부 포기하더라도 **노동의 힘을 약화**시키려 함 모든 노동자가 대체 가능하길 원함 - 하지만 실제로 회사가 일부러 숙련된 엔지니어를 다른 팀으로 옮기는 경우는 드묾 오히려 좋은 엔지니어를 **붙잡기 위해 노력**하는 경우가 많음 - 사실 엔지니어들끼리도 “Bob만 아는 코드”를 욕함 즉, 이런 문화는 경영진만의 문제는 아님 - 코드의 문법과 구조는 교과서적이지만, **근본적인 접근이 잘못된 경우**를 자주 봄 코드 리뷰는 문법에만 집중하고, 비즈니스 문제나 복잡도는 논의되지 않음 단기적으로는 괜찮지만, 장기적으로는 **기술 부채**가 폭발함 - 완전 공감함. 데이터베이스 스키마 같은 건 첫 스프린트에 박제되고, 이후엔 절대 리팩터링되지 않음 그 결과, 사소한 코드 품질 논쟁으로 PR이 며칠씩 지연됨 - 대기업에서도 똑같이 봄 다들 **표면적인 코드 청결**에만 집착함 논리적 타당성이나 큰 그림을 보는 건 어렵고, 리뷰어가 맥락을 모르는 경우도 많음 - 좋은 요구사항 수집과 문서화, 제품 설계가 부족하면 장기적으로 유지 가능한 설계를 하기 어려움 조직 전체가 이런 피드백을 수용할 여유가 없으면, 결국 **‘그럭저럭 굴러가는 시스템’** 에 의존하게 됨 - 코드 리뷰에서 아키텍처 문제를 발견한다면, 이미 **프로세스 단계에서 실패**한 것임 큰 설계는 코드 리뷰 전에 검토되어야 함 - 이런 패턴은 **AI 생성 코드**에서도 자주 보임 우리는 장기적 비용을 자동화하고 있는 셈임 - 대기업은 코드 자체에 관심이 없음 코드는 단지 회사를 움직이게 하는 **매개체**일 뿐임 결국 중요한 건 코드가 아니라 **프로세스**임 시스템이 망가졌을 때 이를 복구할 수 있는 절차가 있느냐가 핵심임 - 모든 산업은 규모가 커지면 비슷한 **절충**을 함 완벽보다는 ‘충분히 괜찮은’ 품질이 이익을 만듦 IKEA 의자와 Herman Miller 의자의 차이처럼, 제약 조건이 다를 뿐임 진짜 실력은 **어디서 타협할지 아는 능력**임 대기업 구조는 이런 타협을 엔지니어에게 강요함 - 좋은 시니어 엔지니어는 처음부터 나쁜 코드를 쓰지 않음 문제는 **단기 성과 압박**과 **기초 부족**임 리뷰를 생략하거나 아키텍처를 충분히 고민하지 않는 게 진짜 원인임 - 하지만 현실은 이미 너무 엉망이라, 좋은 코드를 쓸 수 없는 경우도 많음 [이 댓글](https://news.ycombinator.com/item?id=18442941)에 묘사된 것처럼, 수백만 줄의 해킹이 누적된 코드 위에서는 아무리 노력해도 깨끗하게 만들 수 없음 결국 **스파게티 전체를 들어올리는 꼴**이 됨 - 결국 둘 다 맞음 시니어는 ‘제대로 하기’와 ‘빨리 끝내기’ 사이에서 늘 **딜레마**에 놓임 - 좋은 코드는 **맥락 의존적**임 복잡한 코드베이스를 하루아침에 이해할 수 없고, 조직이 **지식 축적**을 중시하지 않으면 품질은 악화됨 새 직원에게는 문서화나 정리 작업을 맡겨 코드의 구조를 익히게 하는 게 좋음 - 또 다른 이유는 **호환성 유지** 요구 때문임 기존의 해킹된 코드가 많아도, 깨뜨릴 수 없으니 손대지 못함 - 내가 쓴 최악의 코드는 **변경되는 요구사항** 때문이었음 아무리 뛰어난 설계라도, 기반이 모래 위라면 무너짐 - 글쓴이가 말한 ‘가독성이 품질보다 우선된다’는 결론은, 그렇다면 모든 대기업 프로젝트에 **정적 분석 도구와 자동 포매터**가 필수여야 한다는 뜻임 하지만 현실은 그렇지 않음 이런 도구 도입은 **비기술 관리자**의 결정이며, 그들은 단기 비용을 싫어함 결국 **출시 일정이 모든 걸 압도**함 - “두 번째 모니터는 필요 없다”는 식의 관리자가 이런 문화를 상징함 - 한 제조 대기업에서 컨설팅할 때, 코드 전반에 **이상한 객체 모델링 패턴**이 있었음 원인을 추적하니, 설계자가 의도한 개념(청사진–주형–제품)을 개발팀이 완전히 오해했음 수정하자고 했지만, 돌아온 답은 “이미 너무 늦었다”였음 그 결과, 10년 넘게 잘못된 모델이 유지되며 **막대한 기술 부채**를 낳았음 - “그래도 그 제품이 사람을 죽이진 않겠지?”라는 농담이 나올 정도였음 - 대기업의 **짧은 근속연수 통계**는 오해의 소지가 있음 인원 급증으로 인해 중간값이 짧아진 것뿐임 실제로는 퇴사자 기준으로 봐야 정확함 - 같은 이유로, **고참 개발자 비율**도 과소평가됨 단순히 과거에는 개발자 수가 적었기 때문임