혁신은 사고방식이지 이정표가 아님
귀사의 엔지니어링 문화에 기술적 민첩성을 도입합니다
Jimdo의 CTO로서 저는 애플리케이션 혁신이 일회성 디지털 변환이나 클라우드 마이그레이션 같은 단일 이벤트로 논의되는 경우를 자주 목격했습니다. 마치 이를 단 한 번의 프로젝트로 치부하고, 일단 완료되면 조직이 다른 곳에 집중할 수 있게 되는 것처럼 말입니다. 하지만 현실적으로 애플리케이션 혁신은 시작일과 종료일이 있는 프로젝트가 아닙니다. 엔지니어링 문화에 내재되어야 하는 운영 원칙입니다.
모든 기술 리더에게 진정한 도전은 새로운 기능과 유지 관리 중에서 선택하는 일이 아닙니다. 이는 엔지니어링 에너지를 지속해서 관리하는 것입니다. 저는 최근 Beyond the App Stack에 출연해 Cloudflare 필드 CTO인 Trey Guinn과 대화를 나누며 민첩성을 확보하면서도 안정성을 희생시키지 않아야 하는 과제에 대해 논의한 적이 있습니다.
제 생각에 그 해답은 정렬에서 시작됩니다. 저는 합의를 믿지 않습니다. 성장 중인 기업에서는 합의를 이루기가 너무 어렵습니다. 대신, 저는 하향식 전략과 상향식 실행을 결합하는 접근 방식을 지지합니다. 임원들은 '무엇을'과 '어디에서'를 설정하지만, 엔지니어들과 부사장은 '어떻게'를 결정합니다. 이러한 과정을 거쳐야만 애플리케이션 혁신을 말할 때 실제로는 비즈니스 성장을 뜻한다는 확신을 가질 수 있습니다.
유지 관리와 혁신의 시소
회복을 실행하기 위해 우리는 '안정화세'를 도입했습니다. 노력의 60%는 핵심 기술 부채를 해결하는 데 투입하고, 나머지 40%는 혁신에 투자했습니다. 이것은 마법 같은 숫자가 아니라, 우리 팀이 코드베이스의 난맥상에 발목 잡히지 않도록 하기 위한 전략적 기준이었습니다.
일관성을 유지하는 비결은 고정된 비율을 영원히 고수하는 것이 아니라, 팀의 마찰 수준을 평가하는 데 있습니다. 릴리스가 느리고 복잡도가 높은 경우 부 채세가 높아질 것입니다. 3년 동안 절제했기 때문에 우리는 그 비율을 바꿀 자격이 생겼습니다. 지금도 혁신에 더 많은 시간과 비용을 들이지만, 기술 부채를 아예 없앨 수는 없습니다. 60/40이든 20/80이든 규칙은 동일합니다. 과거 비용을 갚아야 미래를 보호할 수 있습니다.
레거시 시스템을 포기하기로 결정
CTO가 가장 내리기 어려운 결단 중 하나는 시스템이 회복 불가능할 정도로 망가졌을 때를 결정하는 것입니다. 모든 것을 버리고 다시 시작하고 싶은 유혹은 끊이지 않지만, 제 경험상 그러한 결정은 기술적인 좌절감 때문이 아니라 비즈니스 전략에 근거해야 합니다.
Jimdo에서는 한때 전략적 변곡점을 마주했습니다. 사용자가 HTML과 CSS를 알아야 하는 DIY 웹 사이트 빌더에서 Web 2.0 시대로 이전하며 웹 사이트를 사용자에게 제공했습니다. 비즈니스 모델이 근본적으로 변화하면서 기존의 솔루션은 속도를 높여주는 것이 아닌 오히려 그 반대가 되었습니다. 저희는 Jimdo 2.0을 재구축하는 핵심 업무를 맡은 팀을 따로 두었습니다.
당시의 경험은 오늘날 주요 기술 변화를 평가하는 저의 기준이 되었습니다. 인프라 재구축은 단순히 기술적 부채를 해소하는 것만으로는 충분하지 않으며, 반드시 비즈니스 문제를 해결해야 한다는 점을 알게 되었습니다. 요즘은 엔지니어링 책임자가 애플리케이션 혁신에 대한 대규모 투자를 요청할 때마다 저는 항상 다음과 같은 간단한 질문 세 가지를 던집니다.
이 투자를 하면 더 빨라질까?
이 투자를 하면 복잡성이 줄어들까?
이 투자를 하면 제품 전환율 개선에 도움이 될까?
해당 제안이 회사의 전략과 긴밀하게 연계되고 이 세 가지 질문에 명확한 답변이 제시된다면, 저희는 이를 승인하고 해당 분기 동안 작업을 진행합니다. 책임이 가장 중요합니다. 단순히 예산을 요청하는 것이 아니라 그 투자의 비즈니스 사례를 마련하는 것이 중요합니다.
집중하는 날을 통한 실험 확장
혁신을 위해서는 제약 없이 실험할 수 있는 시스템이 필요합니다. Jimdo에서는 매주 하루를 집중하는 날로 정해 지키고 있습니다. 최소한 이 날 하루만은 엔지니어들이 도구를 연구하고, 기존 코드베이스를 개선하며, 기술 세계의 변화 흐름에 발맞춰 나가려는 노력을 할 수 있습니다.
천성적인 엔지니어이기 때문에, 저는 연구하고 배우지 않으면 시대에 뒤처진다고 생각합니다. AI의 대두로 이것은 그 어느 때보다 더 사실이 되었습니다. AI는 세상을 바꾸고 있습니다. AI 를 통해 코딩이 훨씬 빨라집니다. 그러나 적절한 안전장치가 마련되어야 AI를 통해 승리를 거둘 수 있습니다. 저는 직원들이 이러한 도구를 연구하고 더 빠르게 작업할 방법을 찾도록 독려하고 있으며, 이러한 호기심에 대한 투자는 이미 성과를 내고 있습니다.
이처럼 얻은 결과를 내부 커뮤니케이션 채널을 통해 공유합니다. 모두가 동일한 목표를 가지고 동료들이 무엇을 만드는지 알면 바람직한 압박감이 생깁니다.
매몰 비용의 함정: 2년간의 실패에서 배운 교훈
모든 애플리케이션 혁신 시도가 다 성공하는 것은 아닙니다. 저도 여러 차례 실패를 경험했습니다. 그 중에는 가장 고통스러웠던 투자 프로젝트 1건도 포함됩니다. 무려 2년 넘게 지속되었던 프로젝트였습니다.
문제는 시장이 변화하고 당사의 전략이 바뀌면서, 비즈니스와 더 이상 맞지 않는 제대로 준비되지 않은 프로젝트가 남았다는 것입니다. 유지 관리하기가 무척 힘들었습니다. 그 실패를 통해 중요한 교훈을 얻었습니다. 항상 작업을 마일스톤으로 나누어 올바른 길을 가고 있는지 확인해야 한다는 것입니다.
자동차를 만드는 것에 비유해 보겠습니다. 바퀴를 4개 만들고 그다음에 차축을 만들지는 않습니다. 스케이트보드를 만든 다음 자전거, 이어서 자동차를 만드는 방식인 셈입니다. 작은 단위로 단계적으로 완성해 나감으로써, 스스로를 보호할 수 있습니다. 전략이 바뀌거나 시장이 변화하더라도 2년간의 노력이 사라지지 않은 채로 중단할 수 있습니다. 민첩성은 속도에 관한 것만이 아니라, 방향이 맞지 않을 때 멈출 줄 아는 능력입니다.
애플리케이션 혁신은 사고방식이지, 이정표가 아닙니다
이 문제를 잘 해결하기 위한 쉬운 방법은 없습니다. 기술 부채를 갚기 위해 필요한 엔지니어링 역량을 보호하려면 강력한 리더십이 필요합니다. 특히 새로운 기능을 출시해야 한다는 끊임없는 압박이 있을 때 더욱 그렇습니다.
2026 Cloudflare 애플리케이션 혁신 보고서에서 분명히 드러나듯이, 최고의 기업은 시간이 지나면서 대규모 애플리케이션 혁신을 예측하고 계획할 수 있는 기업입니다. 이러한 기업에서는 기술을 고정된 자산이 아니라, 지속적인 관심이 필요한 살아있는 시스템으로 간주합니다.
애플리케이션 혁신은 애플리케이션을 개선하는 데 보내는 시간을 가치 있게 활용하는 것입니다. 팀에서 최신 정보를 습득하고 비즈니스 목표에 명확히 부합하며 부채를 해소할 수 있는 체계를 갖추도록 지원함으로써, 단순히 제품을 유지하는 것을 넘어 경쟁력을 갖춘 엔진을 구축하게 됩니다.
혁신 확장
진정한 애플리케이션 혁신은 어떤 목적지에 도달하는 것보다는 조직에서 디지털 자산을 구축, 보호, 배포하는 방식을 발전시키는 것에 더 가깝습니다. 기술의 민첩성을 지속 가능한 비즈니스 이점으로 바꾸려면 철저한 보안 표준을 유지하면서도 마찰을 제거할 수 있는 기반이 필요합니다.
Cloudflare의 통합 애플리케이션 보안 및 성능 플랫폼은 이러한 진화에 특화되어 있습니다. 조직에서 레거시 시스템을 최신화하고, 분산 아키텍처를 최적화하며, AI 기반 역량에 투자함에 따라, Cloudflare에서는 혁신과 복원력의 균형을 맞출 수 있는 기반을 제공합니다. Cloudflare에서는 세계적 수준의 성능, 깊이 있는 관찰 가능성, 개발자 중심의 도구를 하나의 프로그래밍 가능한 계층으로 통합하여 엔지니어의 시간을 확보하고, 분리된 도구의 오버헤드나 비용 상승 없이 혁신을 주도합니다.
이 글은 오늘날의 기술 의사 결정자에 영향을 주는 최신 동향 및 주제에 대한 시리즈 중 일부입니다.
이 주제에 관해 자세히 알아보세요.
많은 조직에서 애플리케이션 스택과 프로세스를 어떻게 최신화하고 있는지 자세히 알아보려면 2026 Cloudflare 애플리케이션 혁신 보고서를 확인하세요.
작성자
Felipe Furlan — @ffurlansilva
Jimdo의 CTO
핵심 사항
이 글을 읽고 나면 다음을 이해할 수 있습니다.
혁신과 정기 유지 관리 간의 균형을 잡는 방법
재구축, 리팩터링, 투자를 통해 기술 부채를 줄여야 하는 시기
최신화 제안 평가 기준