🚀 소프트웨어 개발, 빠른 길이 항상 옳은 길은 아니다

 

음악에서 소프트웨어로, 그의 특별한 여정

LaunchDarkly의 릴리스 자동화 책임자 Tom Totenberg는 사실 정통 개발자 출신이 아니에요. 그는 음악을 전공했고, 교사가 되기 위한 교육을 받았죠. 하지만 그는 음악과 소프트웨어 개발 사이에 놀라운 공통점을 발견했어요.

거대한 음악 작품을 개별 음표로 쪼개서 연습하는 것처럼, 복잡한 소프트웨어도 작은 단위로 나누어 접근하는 게 핵심이라는 거예요. 오케스트라에서 팀원들과 호흡을 맞추는 것과, 엔터프라이즈 소프트웨어를 만들며 협업하는 건 본질적으로 같은 스킬을 요구한다고 하더라구요.

고등학교 때부터 게이밍 PC를 직접 조립하며 기술에 관심을 가졌던 그는, 결국 자신의 창의적 배경과 기술적 열정을 결합해 지금의 자리에 오르게 됐어요.

엔지니어의 "게으름"이 만드는 위험한 지름길

Tom은 자신이 만난 최고의 엔지니어들에게는 공통점이 하나 있다고 말해요. 그들은 본질적으로 "게으르다"는 거예요. 물론 이건 부정적인 의미가 아니에요. 그들은 항상 가장 쉬운 길을 찾으려 하고, 측정 가능한 지표가 있으면 그걸 게임처럼 공략하려 한다는 거죠.

빌 게이츠가 했다는 유명한 말이 있잖아요. "효율적으로 일을 끝내고 싶으면 게으른 사람에게 맡겨라." 5초를 아끼기 위해 1시간을 투자하는 게 장기적으로 더 효율적이라는 거죠.

문제는 이런 "게으름"이 너무 과하게 작동할 때예요. 물은 항상 가장 쉬운 길로 흐르듯이, 개발자들도 마찬가지거든요. 보고서만 그럴듯하게 보이면, 귀찮게 건드리지 않으면, 그들은 어떤 지름길이든 택하게 된다는 거예요.

비즈니스 압박이 만들어낸 "덕테이프 솔루션"

요즘 소프트웨어 업계의 트렌드는 명확해요. 더 빠르게, 더 빠르게, 더 빠르게. 1년에 두 번 릴리스하는 건 구시대 방식이고, 2주 단위 애자일도 모자라서 이젠 지속적 배포가 표준이 되어가고 있죠.

McKinsey의 2024년 보고서에 따르면, 소프트웨어 개발 속도에 대한 경영진의 압박은 지난 3년간 평균 40% 이상 증가했다고 해요. 시장 출시 시간을 단축하라는 요구가 그 어느 때보다 강해진 거죠.

이런 비즈니스 압박 속에서 기술적 디테일은 자주 놓치게 돼요. 그리고 여기서 "덕테이프 솔루션"이 등장해요. 원래는 하중을 지탱하도록 설계되지 않은 임시방편이었는데, 누군가 "어, 나도 이거 쓸 수 있겠는데?"라고 하면서 팀 전체가 의존하게 되는 거죠.

구체적인 예를 들면 설정 관리 도구예요. 배포와 릴리스를 분리하는 게 좋다는 걸 다들 알게 되면서, 수많은 이상하고 복잡한 커스텀 도구들이 생겨났어요. 문제는 이게 규모가 커지거나 뭔가 잘못되면 바로 대형 사고로 이어진다는 거죠.

AI 코딩 시대, 더 큰 위험이 온다

Tom은 우리가 지금 "바이브 코딩"의 황금기에 접어들고 있다고 경고해요. AI 도구 덕분에 코드를 만드는 진입장벽이 전례 없이 낮아졌지만, 문제는 그만큼 개발자가 실제 코드로부터 멀어진다는 거예요.

최근 시장조사 기관 Gartner는 2025년까지 소프트웨어 개발의 약 70%가 로우코드 및 노코드 플랫폼을 통해 이루어질 것으로 전망했어요. GitHub의 2024년 통계를 보면, AI 코드 생성 도구인 Copilot이 생성한 코드 비중이 전체 코드베이스의 평균 46%에 달한다고 하더라구요.

더 심각한 건, AI가 생성한 코드에 대한 리뷰 프로세스예요. Tom이 최근 한 고객사에서 목격한 사례는 충격적이었어요. 개발자가 Claude에게 코드를 생성하게 하고, 자기 자신이 그 코드를 리뷰하는 거예요. 다른 사람의 눈은 전혀 거치지 않고요.

그래서 그 회사는 새로운 규칙을 만들었어요. AI가 생성한 코드는 반드시 두 명의 실제 사람이 리뷰해야 한다는 거죠. API 키 유출이나 보안 취약점 같은 치명적인 문제를 방지하려면 이런 안전장치가 필수적이에요.

지름길과 기술부채, 어떻게 다를까?

많은 사람들이 헷갈려하는 게 바로 이거예요. 지름길과 기술부채는 뭐가 다른 걸까요?

Tom의 설명은 명쾌해요. 지름길은 기술부채를 만들어내는 원인이라는 거죠. MVP를 빨리 내놓기 위해 확장 가능한 기본 플랫폼을 고려하지 않고 만들면, 나중에 모든 걸 다시 뜯어고쳐야 하는 상황이 와요.

워크플로우 플랫폼을 만든다고 생각해볼까요? 1단계에서 2단계로 넘어가는 간단한 기능만 급하게 만들었는데, API는 만들었나요? 확장 가능하게 설계했나요? 나중에 분기 로직이 필요해질 수도 있는데 그걸 고려했나요?

이런 걸 생각 안 하고 그냥 "바이브"로 만들거나 MVP만 급하게 내놓으면, 그게 바로 기술부채가 돼요. 나중에 리팩토링하는 게 처음부터 제대로 만드는 것보다 훨씬 더 어렵고 비용이 많이 들거든요.

Stripe의 2024년 엔지니어링 비용 분석에 따르면, 기술부채를 해결하는 데 드는 비용이 초기 개발 비용의 평균 3.5배에 달한다고 해요. 처음엔 시간을 절약한 것 같지만, 결국엔 더 많은 시간과 비용을 쏟게 되는 거죠.

비즈니스 압박에 맞서는 법

모든 엔지니어가 한 번쯤 겪어봤을 거예요. "빨리 움직여라", "일단 MVP를 내놔라"는 압박 말이에요. 어떻게 이런 압박에 맞설 수 있을까요?

Tom은 소프트웨어 개발 생명주기에서 가장 중요한 단계가 계획 단계라고 강조해요. 리드 타임, 자동화 테스트, 배포 시간 같은 건 다들 신경 쓰는데, 정작 계획 단계는 소홀히 하는 경우가 많다는 거죠.

워터폴 방법론을 옹호하는 건 아니에요. 다만 워터폴의 한 가지 장점은 철저하고 포괄적인 계획이었다는 거예요. 우리가 만드는 이 기능이 전체 그림에서 어디에 위치하는지, 다른 팀이 이미 비슷한 걸 만들고 있진 않은지, 재사용 가능하게 만들 수 있는지 같은 걸 미리 고민하는 거죠.

확장 가능하게 만드는 데 1.5배의 시간이 걸린다면? 그게 나중에 두 번 만드는 데 드는 2배 시간보다 훨씬 낫다는 거예요.

성공 지표를 미리 정의하는 것의 중요성

Tom이 가장 강조하는 건 바로 이거예요. 계획 단계에서 실패와 성공을 어떻게 정의할 것인지 명확히 해야 한다는 거죠.

어떤 종류의 실패를 걱정해야 할까요? 성능 저하인가요, 비즈니스 전환율 하락인가요? 결제 처리 시스템이라면 코어 플로우를 반드시 보호해야 하고, API 실패율이나 지연시간 같은 걸 철저히 관리해야 해요.

하지만 왜 이렇게 "좋은 것"을 정의하기가 어려울까요? Tom은 여기에 두 가지 이유가 있다고 봐요.

첫째, 지난 10년에서 15년간 업계는 작고 민첩한 애자일 팀을 강조해왔어요. 완전한 소유권을 가진 팀, 좋죠. 하지만 작은 팀은 작은 솔루션을 만들고, 작은 문제만 해결하려는 경향이 있어요. 그러다 보면 다른 팀과 충돌하거나, 비슷한 걸 중복으로 만들게 되는 거죠.

마이크로서비스가 주로 조직적 특성이지 엔지니어링 특성이 아니라는 말, 들어보셨나요? Tom도 예전 직장에서 100개가 넘는 마이크로서비스 차트를 봤는데, 그중 상당수가 더 이상 아무 일도 하지 않는 좀비 서비스였대요.

느리게 가서 빠르게 가기

Jeff Bezos가 2000년대 초반 Amazon에 내린 유명한 지시가 있어요. 모든 것을 플랫폼으로 만들어라. 모든 것에 명확한 입력과 출력을 정의하라. 당시엔 그냥 온라인 서점이었는데 말이죠.

이런 상호운용성, 명확한 입출력, 조직 전체가 어떻게 맞물리는지에 대한 집중은 장기적으로 엄청난 이익을 가져왔어요. 결국 그게 AWS가 된 거니까요. 현재 AWS는 연간 약 900억 달러 이상의 매출을 올리는 클라우드 플랫폼의 선두주자가 됐죠.

Tom이 말하는 "느리게 가서 빠르게 가기" 전략은 바로 이거예요. 처음에 조금 더 시간을 투자해서 제대로 된 기반을 만들면, 나중에 훨씬 빠르게 움직일 수 있다는 거죠.

Stack Overflow의 2024년 개발자 설문조사에 따르면, 개발자들이 가장 많은 시간을 소비하는 활동 중 하나가 바로 레거시 코드와 기술부채 해결이었어요. 평균적으로 주당 약 10시간 이상을 여기에 쓴다고 하더라구요. 그 시간이면 새로운 기능을 얼마나 많이 만들 수 있을까요?

지속 가능한 릴리스 프로세스 구축하기

Tom은 릴리스 프로세스를 릴리스 카테고리별로 분류하고, 각각에 대한 자동화 전략을 수립해야 한다고 말해요.

위험도가 낮은 변경, 예를 들어 프론트엔드 문구 수정 같은 건? 빠르고 공격적으로 진행해도 돼요. 하지만 데이터 스키마 변경이나 개인정보 관련 새로운 API 도입 같은 건? 훨씬 느리고 통제된 릴리스 프로세스를 거쳐야 하죠.

여기서 핵심은 제어와 측정이에요. 변경의 특성에 따라 어떤 경로를 따를지 자동으로 결정할 수 있어야 하고, 베타 유저의 1%에게만 먼저 노출시킨 다음 그 영향을 측정할 수 있어야 해요.

Open Telemetry 같은 표준 프레임워크를 활용하면 더 좋아요. CNCF의 2024년 조사에 따르면, 대부분의 관찰성 제공업체가 이미 OpenTelemetry를 지원하고 있고, 도입 기업의 85% 이상이 벤더 종속성 감소 효과를 경험했다고 해요. 처음에 조금 시간을 들여 래퍼를 만들어두면, 나중에 벤더를 쉽게 교체할 수 있거든요.

경영진의 "파괴적 변화"에 대응하는 법

새로운 리더가 들어와서 "우리 이전 회사에선 이렇게 했어요"라며 파괴적인 변화를 요구한다면? Tom은 명확한 답을 제시해요.

비즈니스 지표로 대응하라는 거예요. 현재 시스템이 훌륭한 가동시간을 유지하고 있고, 평균 복구 시간이 좋으며, 변경 관리가 순조롭게 진행되고 있다는 데이터를 보여주는 거죠.

"저는 이렇게 하고 싶어요"는 설득력 있는 논리가 아니에요. 하지만 "이 변경이 현재 우리가 측정하고 있는 지표를 악화시킬 수 있습니다. 우리 고객을 보호해야 합니다"는 항상 방어 가능한 입장이에요.

Value Stream Management라는 개념이 있어요. 독일의 어느 자동차 제조사 사례인데, 거기선 청소부든 경리 직원이든 기계 정비사든, 모든 사람이 조립 라인에서 나가는 자동차를 볼 수 있대요. 우리가 왜 여기 있는지, 우리의 가치가 무엇인지 모두가 알고 있는 거죠.

결국 중요한 건 개념적 사고

Tom이 마지막으로 강조하는 건 이거예요. 특정 도구나 방법론보다 개념적 사고가 더 중요하다는 거예요.

기술은 너무 빠르게 변하고 있어요. 특정 툴이나 특정 프로세스에 집착하면 금방 뒤처지게 돼요. 하지만 근본 원칙을 이해하고 개념적으로 사고하는 능력을 키우면, 어떤 변화가 와도 대응할 수 있어요.

AI 시대든, 포스트 AI 시대든, 우리가 살아남는 방법은 바로 이거예요. 한발 물러서서 개념을 생각하고, 근본 원칙으로 돌아가는 거죠.

LaunchDarkly 같은 회사들이 주목받는 이유도 여기 있어요. 그들은 단순히 도구를 제공하는 게 아니라, 더 나은 릴리스 관리 철학과 프로세스를 제공하거든요. 최근 LaunchDarkly는 시리즈 D 펀딩에서 5억 4천만 달러 이상의 기업가치를 인정받았는데, 이는 지속 가능한 소프트웨어 개발 프로세스에 대한 시장의 수요가 얼마나 큰지를 보여주는 지표예요.

마무리하며

소프트웨어 개발에서 지름길은 매력적이에요. 빠르게 결과를 낼 수 있으니까요. 하지만 Tom Totenberg의 이야기에서 배울 수 있는 핵심은 명확해요. 진짜 속도는 처음부터 제대로 만드는 데서 나온다는 거예요.

계획 단계에 충분한 시간을 투자하고, 성공과 실패 지표를 명확히 정의하고, 확장 가능한 플랫폼을 구축하는 것. 이것들이 지루하고 느린 작업처럼 보일 수 있지만, 결국 가장 빠른 길이에요. 기술부채에 시달리며 레거시 코드를 고치는 데 주당 10시간을 쓰는 것보다, 처음에 제대로 만드는 게 훨씬 낫잖아요.

AI 코딩 시대가 본격화되면서 이런 원칙들은 더욱 중요해질 거예요. 코드를 만드는 건 쉬워졌지만, 좋은 코드를 만드는 건 여전히 어렵거든요. 그리고 그 차이를 만드는 건 바로 계획, 측정, 그리고 지속 가능성에 대한 집중이에요. 빠르게 가고 싶다면, 먼저 느리게 가세요. 그게 역설적이게도 가장 빠른 길이니까요.