원문: How good engineers write bad code at big companies

몇 년에 한 번씩, 빅테크 기업들이 때때로 놀라울 정도로 엉성한 코드를 만들어낸다는 사실을 누군가 지적하곤 합니다. 대기업에서 일해본 적이 없다면 이런 일이 어떻게 일어나는지 이해하기 어려울 수 있습니다. 빅테크 기업들은 유능한 엔지니어를 영입하기 위해 충분히 높은 보수를 지급합니다. 또한, 업무 속도가 느려서 충분한 시간을 들여 견고한 작업을 할 수 있는 것처럼 보입니다. 그런데 도대체 어떻게 나쁜 코드가 만들어지는 걸까요?

대부분의 코드 변경은 상대적으로 경력이 낮은 개발자가 수행합니다

저는 가장 큰 이유가 대기업이 자신의 전문 분야가 아닌 곳에서 일하는 엔지니어들로 가득 차 있기 때문이라고 생각합니다. 빅테크 직원의 평균 근속 연수는 고작 1~2년 정도입니다¹. 실제로 빅테크의 보상 패키지는 일반적으로 엔지니어의 근속 기간을 4년으로 제한하도록 설계되어 있습니다. 4년이 지나면 입사 시 받은 초기 주식 부여분이 모두 베스팅되어, 엔지니어의 급여가 50%까지 삭감될 수 있는 구조입니다. 회사들이 매년 임시로 추가 주식 보상을 제공하긴 하지만, 이는 엔지니어들로 하여금 매년 내 연봉의 나머지 절반을 받을 수 있을지 고민할 필요가 없는 다른 직장을 찾도록 부추기는 꼴입니다.

사내 이동까지 포함하면 상황은 더 심각합니다. 제가 커리어 초반에 단일 팀이나 코드베이스에서 머물렀던 가장 긴 기간은 3년이었습니다. 저는 적어도 매년, 종종 그보다 훨씬 자주 조직 개편이 있을 것이라 예상합니다.

하지만 빅테크 기업 내 코드베이스의 평균 수명은 그보다 훨씬 깁니다. 제가 작업하는 서비스 중 다수는 10년 이상 되었으며, 수년 동안 담당자가 수도 없이 바뀌었습니다. 이는 많은 빅테크 엔지니어들이 끊임없이 “파악하는 중”이라는 것을 의미합니다. 상당히 높은 비율의 코드 변경은 “초심자”들에 의해 이루어집니다. 지난 6개월 이내에 회사, 코드베이스, 또는 심지어 해당 프로그래밍 언어에 막 온보딩한 사람들 말입니다.

베테랑 엔지니어

이 문제는 “베테랑”들에 의해 어느 정도 완화됩니다. 이들은 특정 시스템의 궤도 안에 충분히 오래 머물러 실질적인 전문성을 쌓은 엔지니어들입니다. 이 엔지니어들은 심도 있는 코드 리뷰를 제공하고 명백한 문제점들을 확실하게 잡아낼 수 있습니다. 하지만 “베테랑”에게 의존하는 것에는 두 가지 문제가 있습니다.

첫째, 이 과정은 전적으로 비공식적입니다. 빅테크 기업들은 개별 시스템에 대한 장기적인 전문성을 키우는 데 놀라울 정도로 노력을 기울이지 않으며, 일단 전문성을 확보하더라도 이를 유지하는 데는 거의 신경 쓰지 않는 것 같습니다. 종종 해당 엔지니어들은 다른 서비스로 이동하게 되고, 사실상 자원봉사 형태로 “베테랑”의 임무를 유지하거나, 아니면 이를 포기하고 완전히 새로운 시스템의 상대적 초심자가 되어야 합니다.

둘째, 경험 많은 엔지니어들은 항상 과중한 업무에 시달립니다. 특정 서비스에 대한 깊은 전문성을 가진 소수의 엔지니어 중 한 명으로서 바쁜 업무를 수행해야 합니다. 모든 소프트웨어 변경 사항을 직접 검토하거나 모든 의사 결정 과정에 적극적으로 참여할 시간이 충분하지 않습니다. 당신에게도 본인의 업무가 있다는 사실을 기억해야 합니다. 만약 변경 사항을 검토하고 토론에 참여하는 데 모든 시간을 쓴다면, 개인적인 성과가 부족하다는 이유로 회사로부터 불이익을 받을 가능성이 큽니다.

생산적인 엔지니어의 평균적인 모습

이 모든 것을 종합해 볼 때, 빅테크 기업에서 생산적인² 엔지니어의 평균적인 모습은 어떤 모습일까요? 그들은 보통 다음과 같습니다.

• 채용 기준을 통과하고 업무를 수행할 수 있을 만큼 유능하지만,
• 자신에게 생소한 코드베이스나 언어로 작업하고 있거나,
• 본인의 업무를 처리하면서 쏟아지는 코드 변경 사항을 감당하려 애쓰고 있습니다.

그들은 거의 확실히 마감 기한에 쫓기고 있거나, 다른 프로젝트들의 겹치는 마감 기한들에 맞춰 일하고 있습니다. 다시 말해, 그들은 양질의 코드를 생산하도록 설정되지 않은 환경에서 최선을 다하려고 노력하고 있을 뿐입니다.

이것이 바로 “명백히” 나쁜 코드가 발생하는 과정입니다. 예를 들어, 주니어 엔지니어가 거의 익숙하지 않은 코드베이스의 성가신 버그에 대한 티켓을 맡았다고 가정해 봅시다. 그들은 며칠 동안 문제를 파악하고 땜질 식의 해결책을 내놓습니다. 더 시니어인 “베테랑” 중 한 명이 (운이 좋다면) 30분의 여유 시간에 이를 훑어보고는 거부권을 행사한 뒤, 적어도 작동은 할 만한 조금 더 나은 방법을 제안합니다. 주니어 엔지니어는 최선을 다해 이를 구현하고, 작동하는지 테스트한 뒤, 짧게 리뷰를 받고 배포합니다. 그리고 관련된 모든 사람은 즉시 더 높은 우선순위의 업무로 넘어갑니다. 5년 뒤 누군가 이것을 발견하고³ 생각합니다. “와, 정말 엉망이네. 어떻게 이렇게 큰 소프트웨어 회사에서 이런 나쁜 코드가 작성된 거지?”

빅테크 기업들은 이에 개의치 않습니다

저는 이러한 상황에 기여하는 기술 기업 내부의 역학 관계에 대해 많은 글을 써왔습니다. 특히 ’소프트웨어 회사처럼 보기(Seeing like a software company)’ 라는 글에서, 저는 빅테크 기업들이 일관적으로 생산성보다는 내부적인 파악 용이성 (누가 무엇을 작업하고 있는지 한눈에 파악하고 마음대로 변경할 수 있는 능력)을 우선시한다고 주장했습니다. 대기업들은 엔지니어를 대체 가능한 자원으로 취급하고 이리저리 옮기는 것이 단일 코드베이스에 대한 장기적인 전문성을 개발하는 능력을 파괴한다는 것을 알고 있습니다. 이것은 의도적인 트레이드오프입니다. 그들은 ‘이달의 문제’가 무엇이든 숙련된 엔지니어를 신속하게 투입할 수 있는 능력을 얻기 위해 일정량의 전문성과 소프트웨어 품질을 포기하는 것입니다.

이것이 좋은 생각인지 나쁜 생각인지는 모르겠습니다. 특히 “AI 관련 분야로 얼마나 빨리 방향을 틀 수 있는가”가 중요한 지금, 빅테크 기업들에게는 확실히 효과가 있는 것처럼 보입니다. 하지만 이런 방식을 취한다면, 당연히 진짜 나쁜 코드가 만들어질 수밖에 없습니다. 익숙하지 않은 시스템에서 엔지니어들에게 작업을 서두르라고 요구하면 일어나는 일입니다.

개별 엔지니어는 이러한 역학을 바꿀 힘이 전혀 없습니다. 엔지니어에서 기술 기업 경영진으로 권력의 균형이 기울어진 2025년에는 더욱 그렇습니다. 개별 엔지니어로서 할 수 있는 최선은 “베테랑”이 되기 위해 노력하는 것입니다. 적어도 한 분야에서 전문성을 키우고, 이를 이용해 최악의 변경 사항을 막고 사람들이 최소한의 합리적인 기술적 결정을 내리도록 이끄는 것입니다. 하지만 이조차도 조직의 흐름을 거스르는 일인 경우가 많으며, 미숙하게 대처했다가는 PIP(성과 향상 프로그램) 대상자가 되거나 더 나쁜 상황에 처할 수 있습니다.

순수 엔지니어링과 불순한 엔지니어링

저는 이 문제의 많은 부분이 순수 소프트웨어 엔지니어링과 불순한 소프트웨어 엔지니어링의 차이에서 비롯된다고 생각합니다. 프로그래밍 언어와 같은 독립적인 기술 프로젝트를 수행하는 순수 엔지니어들에게 나쁜 코드에 대한 유일한 설명은 무능함입니다. 하지만 불순한 엔지니어들은 배관공이나 전기 기술자와 더 비슷하게 작동합니다. 그들은 자신에게 비교적 새로운 프로젝트의 마감 기한에 맞춰 일하며, 기술적 기본기가 흠잡을 데 없다 하더라도, 해당 상황의 특정 설정에는 항상 어색하거나 놀라운 무언가가 존재합니다. 불순한 엔지니어들에게 나쁜 코드는 불가피한 것입니다. 전체 시스템이 충분히 잘 작동하는 한, 그 프로젝트는 성공입니다.

빅테크 기업에서 엔지니어들은 자신이 순수 엔지니어링 작업을 할지 불순한 엔지니어링 작업을 할지 결정할 수 없습니다. 그건 그들의 코드베이스가 아니니까요! 회사가 당신을 데이터베이스 인프라 작업에서 새로운 결제 시스템 구축 업무로 이동시키고 싶다면, 회사는 전적으로 그렇게 할 권리가 있습니다. 낯선 시스템에서 당신이 실수를 저지를 수 있다는 사실, 혹은 DB 인프라 팀의 옛 동료들이 당신의 전문성 부재로 고통받을 수 있다는 사실은 엔지니어가 아니라 회사가 내린 의도적인 트레이드오프입니다.

대기업의 나쁜 코드 사례를 지적하는 것은 괜찮습니다. 적어도, 임원들은 나쁜 PR을 좋은 PR로 바꿀 기회를 덥석 물기 때문에 특정 사례들을 고치는 효과적인 방법이 될 수는 있습니다. 하지만 그 일차적인 책임을 해당 회사의 엔지니어들에게 돌리는 것은 실수⁴라고 생각합니다. 만약 요술 지팡이를 휘둘러 모든 엔지니어를 두 배로 뛰어난 실력자로 만든다 해도, 여전히 나쁜 코드는 존재할 것입니다. 왜냐하면 완전히 새로운 코드베이스에 들어와 실수 없이 빠르게 변경 사항을 만들어낼 수 있는 사람은 거의 없기 때문입니다. 근본적인 원인은 대부분의 대기업 엔지니어들이 낯선 코드베이스에서 대부분의 업무를 수행하도록 강요받는다는 점입니다.

수정: 이 글은 Hacker News와 lobste.rs에서 많은 댓글을 받았습니다.

많은 댓글 작성자가 이러한 관점을 불쾌할 정도로 허무주의적이라고 느꼈다는 점이 놀라웠습니다. 저는 제 업무에 대해 꽤 낙관적이라고 생각합니다. 사실, 저는 이 글을 비평가들로부터 빅테크 소프트웨어 엔지니어들을 강력하게 옹호하기 위해 썼습니다! 그럼에도 불구하고, 저는 이 반박 블로그 글이 “이건 너무 냉소적이다”라는 입장을 훌륭하게 표현했다고 생각하며, 조만간 이에 대한 후속 글을 쓸 예정입니다. 기다리기 힘드시다면, 제가 2025년 초에 쓴 ‘관리자가 원하는 대로 하는 것이 냉소적인가?’라는 글을 읽어보세요.

일부 Hacker News 댓글 작성자들은 나쁜 코드가 발생하는 다른 이론들을 제시했습니다. 동기 부족, 노조 결성을 막기 위해 의도적으로 엔지니어들의 사기를 꺾음, 혹은 순수하게 속도만을 최적화함 등입니다. 제 경험상 이런 주장들은 설득력이 없습니다. 제 동료 중 다수는 매우 의욕적이며, 어떤 기술 기업도 의도적으로 엔지니어들의 사기를 꺾고 불행하게 만들려 한다고 믿지 않습니다.

몇몇 독자들은 회사에서 주식 리프레시를 주기 때문에 RSU가 퇴사 유인이 된다는 제 의견에 동의하지 않았습니다. 저는 이에 대해 잘 모르겠습니다. 저도 리프레시를 받지만, 계약서에 명시된 것이 아니라면 중요하지 않다고 생각합니다. 회사는 리프레시를 중단함으로써 언제든지 보상의 50%를 지급하지 않기로 결정할 수 있고, 이는 4년 더 보상을 확정받기 위해 이직하려는 유인이 됩니다.

이 글이 마음에 드셨다면, 제 새 글에 대한 이메일 업데이트를 구독하거나 Hacker News에 공유해 주세요. 여기 이 글과 태그를 공유하는 관련 글의 미리 보기가 있습니다.

스태프 소프트웨어 엔지니어로서 기술 기업의 사내 정치에 영향력을 행사하는 법

많은 소프트웨어 엔지니어는 사내 정치에 대해 운명론적입니다. 그들은 참여하는 것이 무의미하다고 믿는데, 그 이유는 다음과 같습니다.

여기서 일반적인 생각은 소프트웨어 엔지니어가 진짜 정치꾼들과 같은 수준에서 게임을 할 준비가 되어 있지 않다는 것입니다. 이는 사실입니다! 소프트웨어 엔지니어가 마치 왕좌의 게임에 나오는 것처럼 음모를 꾸미고 계략을 짜야 한다고 생각하는 것은 끔찍한 실수입니다. 당신의 계략은 즉시 발각되어 당신에게 불리하게, 그리고 다른 사람들의 이익을 위해 역이용될 것입니다. 계략을 꾸미기 위해서는 경험과 권력이 필요한데, 소프트웨어 엔지니어에게는 그 두 가지 모두 없습니다.

🚀 한국어로 된 프런트엔드 아티클을 빠르게 받아보고 싶다면 Korean FE Article을 구독해주세요!