소프트웨어 개발 현장에는 ‘산출물(output)이 곧 성과(outcome)’이라는 위험한 착각이 고착돼 있다. 더 많은 시간을 투입하거나 코드 줄 수를 늘리면 결국 문제를 해결할 수 있다는 믿음이다.

최근 ‘더 프래그매틱 엔지니어(The Pragmatic Engineer)’로 알려진 게르게이 오로스가 이 통념을 정교하게 해부했다. 오로스는 중국 빅테크 기업에서 확산된 ‘996’ 업무 문화(오전 9시부터 밤 9시까지 주 6일 근무 방식)에 대해 “다른 곳에서 먼저 나온 더 나은 제품을 복제하거나 변주한 것이 아닌, 주목할 만한 무언가를 만들어낸 996 기업을 거의 떠올릴 수 없다”라고 지적했다. 장시간 노동은 비인간적일 뿐 아니라 비효율적이라는 의미다.

억지로 시간을 늘리면 산출량은 늘 수 있어도 차별성은 거의 생기지 않고, 혁신은 더욱 요원해진다.

중국의 996 문화를 비판하기 전에 기업은 스스로의 관행을 돌아볼 필요가 있다. 여러 창립자가 과도한 업무 강도를 ‘하드코어’, ‘올인’, ‘그라인드 문화’ 등으로 포장하지만 본질은 같다. 근무 시간을 극단적으로 밀어붙이면 언젠가 뛰어난 결과물이 튀어나올 것이라는 막연한 기대가 있는 것이다. 이제 우리는 이 방식 자체를 코드, 더 정확히는 GPU에 주입하려 하고 있다. LLM에 사실상 ‘주 수천 시간’에 해당하는 작업량을 부여해 초인적인 속도로 코드를 만들어내면 더 나은 소프트웨어가 마법처럼 탄생할 것이라는 가정이다.

하지만 그렇게 되지는 않는다. 현재의 문제를 더 확장한 결과만 얻을 뿐이다. 중복적이고 비대하고 관리하기 점점 어려워지는 코드가 더 많이 쌓일 뿐이다.

코드 변경이 초래하는 높은 비용

필자는 이 문제를 오래전부터 경고했다. 최근에는 인터넷이 ‘가치 낮고 양만 많은 콘텐츠’로 숨막혀 가고 있다는 점을 지적한 바 있다. 생산 과정의 마찰이 사라지면서 값싼 콘텐츠가 폭증하고 있다는 의미다. 소프트웨어 역시 똑같은 상황을 맞고 있다.

이를 뒷받침하는 데이터도 있다. 1억 5,300만 줄의 코드를 분석한 깃클리어(GitClear)의 2024년 보고서를 다루며 언급했듯, 코드 변경 후 2주 안에 다시 고쳐지거나 폐기되는 ‘코드 이탈률(code churn)’이 급격히 치솟고 있다. 연구 결과를 보면 복사·붙여넣기된 코드 비중이 늘고, 리팩터링은 크게 줄었다.

AI는 개발 속도를 높여주고 있다. 깃허브 분석에 따르면 최대 55% 빨라졌다. 그러나 더 나은 소프트웨어를 만드는 데 도움을 주고 있지는 않다. 코드는 더 많이 생성되지만 이해도는 떨어지고 수정 작업은 더 잦아지고 있다. AI가 코드를 작성한다는 사실이 위험한 것이 아니라, ‘과도한 코드 작성을 부추긴다’는 점이 진정한 위험이다. 비대해진 코드베이스는 보안이 어렵고, 구조를 파악하기도 힘들며, 인간 개발자가 책임지고 관리하기는 더더욱 어려워진다. 코드는 적을수록 좋다.

이것은 996 문화가 기계로 옮겨간 형태다. 996식 사고방식은 혁신을 제한하는 요인이 ‘투입 시간 부족’이라고 전제한다. AI 네이티브식 사고방식은 그 제약이 ‘타이핑된 문자 수’에 있다고 본다. 하지만 모두 틀렸다. 혁신을 가로막는 진짜 제약은 언제나, 그리고 앞으로도 변함없이 사고의 명료함의 부족이다.

코드는 자산이 아니라 부채

핵심으로 돌아가 보자. 경험 많은 엔지니어라면 누구나 알고 있듯, 소프트웨어 개발은 타이핑 경쟁이 아니다. 연속적인 의사결정 과정이다. 중요한 것은 코드를 얼마나 많이 쓰느냐가 아니라, 어떤 코드를 쓰지 않아야 하는지를 판단하는 데 있다. 허니콤 설립자이자 CTO 채리티 메이저스는 “시니어 소프트웨어 엔지니어에게 요구되는 역량은 장기간 운영되는 방대한 코드베이스를 이해하고 유지하고 설명하고 관리하는 능력, 그리고 비즈니스 요구를 기술 구현으로 정확히 번역하는 능력에 훨씬 더 가깝다”라고 설명했다.

배포되는 코드 한 줄 한 줄이 모두 부채다. 모든 코드는 보안 검토를 거쳐야 하고 디버깅하고 유지하고 언젠가는 리팩터링해야 한다. AI로 소프트웨어의 ‘구축’ 단계만 억지로 밀어붙이면 이 부채가 기하급수적으로 커진다. 단기적으로는 눈앞의 지라(Jira) 티켓을 처리하는 듯 보일지 모르지만, 장기적으로는 플랫폼 안정성을 갉아먹는 거대한 복잡성을 만들어낼 뿐이다.

오로스가 996 기업이 ‘복제품만 만든다’라고 지적한 대목은 많은 것을 시사한다. 혁신은 회의라는 끊임없는 방해 없이 사유할 수 있는 여유에서 나온다. 잠시라도 고요한 시간이 생기면, 막 만들려 했던 기능이 사실 불필요하다는 사실을 깨달을 수도 있다. 그러나 개발자가 하루 종일 AI가 생성한 풀 리퀘스트(PR)를 끝없이 검토하는 데 시간을 쏟는다면 이런 여유는 사라진다. 그들은 설계자가 아니라, 쉬지 않고 코드를 토해내는 로봇의 뒤를 치우는 관리 인력에 가까워진다.

그렇다고 AI가 소프트웨어 개발에 해롭다는 의미는 아니다. 오히려 현실은 정반대다. 오픈소스 분야의 오랜 전문가이자 하버드대 교수인 카림 라카니는 “AI가 인간을 대체하진 않는다”라며 “다만 AI를 활용하는 인간이 AI 없이 일하는 인간을 대체하게 될 것”이라고 설명했다. AI는 도구로 사용할 때 탁월한 효과를 내지만, 996 문화의 잘못된 약속을 기계적으로 반복하는 툴로 쓰기 시작하면 오히려 해가 된다.

기술 스택에서 인간이 맡는 역할

그렇다면 우리는 어떻게 ‘실리콘 위의 996 문화’를 만들지 않을 수 있을까? 핵심은 AI를 ‘개발자 대체 수단’으로 다루는 태도를 버리고, 996 문화가 가장 먼저 파괴하는 요소인 ‘시간’을 되돌려주는 도구로 활용하는 것이다.

AI가 유닛 테스트, 보일러플레이트 코드, 문서 업데이트와 같은 단순 반복 업무를 맡아줄 수 있다면, 그것은 스프린트에 기능을 더 우겨 넣을 명분이 아니라 개발 속도를 늦추고 ‘인간이 해야 할 일’에 집중할 기회가 되어야 한다. 예를 들어 다음과 같은 일들이다.

• 문제 정의하기. “우리가 실제로 무엇을 해결하려는가?”라는 질문은 단순해 보이지만, 대부분 소프트웨어 프로젝트가 무너지는 지점이다. 올바른 문제를 선택하는 일은 높은 맥락 이해와 공감 능력이 필요한 작업이다. LLM은 위젯을 구현하는 다섯 가지 방식을 제시할 수 있지만, 그 위젯이 고객의 실제 워크플로에 맞지 않는 잘못된 해결책인지는 판단할 수 없다.
• 불필요한 코드 과감하게 걷어내기. AI 덕분에 코드 작성 비용이 사실상 ‘거의 0’이 되는 순간, 가장 중요한 역량은 코드를 지우는 능력이 된다. 개발자는 ‘노(no)’라고 말하는 결정을 스스로 책임져야 한다. 커밋 속도가 아니라 설계의 단순함을 기준으로 보상해야 하고, 복잡성을 더하는 대신 제거하는 ‘마이너스 코드’ 커밋이 인정받아야 한다.
• 문제 발생 범위 책임지기. 시스템은 언젠가 반드시 고장 나기 마련이고, 그때 사고 보고서에 적힐 이름은 LLM이 아니라 개발자 본인이다. 장애 상황에서 디버깅할 수 있을 만큼 시스템을 깊이 이해하는 능력은 직접 코드를 작성하지 않으면 점차 약해진다. ‘AI 보조’가 ‘인간 분리’로 변질되지 않도록 해야 한다. 특히 필자는 주니어 개발자가 LLM이 주는 답변을 그대로 수용하는 습관을 경계해야 한다고 강조하고 싶다. 모든 개발자가 AI를 효과적으로 활용할 수 있도록 충분한 교육과 훈련이 필요하다.

로봇이 양산한 저품질 코드에 대한 반발은 러다이트(Luddite) 운동이 아니다. 핵심은 품질이다.

오로스가 996 문화를 비판한 이유도 여기에 있다. 그 방식은 지친 사람과 기억에 남지 않는 제품만 만들어낸다. 개발자가 주의하지 않는다면 AI 도입도 똑같은 결과를 낳을 수 있다. 기계가 생성한 취약하고 의미 없는 코드 더미를 업무에 지쳐가는 인간이 떠안아 유지하는 구조 말이다.

지금 필요한 것은 더 많은 코드가 아니다. 더 좋은 코드다. 그리고 좋은 코드는 고요하고 복잡하지 않은 공간에서 사고할 수 있는 인간에게서 나온다. AI에는 반복적이고 힘든 작업을 맡기고 사람에게는 혁신할 시간을 돌려줘야 한다.
dl-itworldkorea@foundryco.com