리팩터링은 위험한 일인가? 더 위험한 일은 없는가?

묻고 따져서 개념을 만들고 실행하는 디지털 전환

Jan 19. 2026

<Fixing Bugs is Easy. Fixing Fear is Harder.>라는 인상 깊은 글을 읽고 여러 가지 생각이 들었습니다. 최근에 있던 서로 다른 몇 가지 사건이 복합적으로 작용해서 제 머릿속에서 언뜻 무관해 보이는 일들 사이의 분명한 관계가 느껴졌는데, 객관화해서 설명할 수 있을지는 모르겠네요. 일단, 시도해 봅니다.

핵심 메시지는 바로 비난과 혁신의 명료한 관련성을 전달하고, 그 둘과는 무관해 보이는 리팩터링의 연관성에 대한 것입니다.

누가 이 버그를 만들었냐고 비난한다면?

일단, <Fixing Bugs is Easy. Fixing Fear is Harder.>는 개발 조직에 대한 이야기이지만, 근래에 쓴 <기업의 디지털 전환 10년 경험을 꺼내다>의 영향으로 저자의 지적은 기성 조직 문화에서 디지털 전환이 어려운 이유와도 일치하는 듯했습니다. 다시 말해서 '누가 이 문제를 일으켰나요?'라는 지적은 도전을 하지 않는 조직 문화를 만듭니다. 많이들 알고 계시는 내용이죠.

그런데, 장애가 났을 때 버그를 만든 사람을 비난하는 일도 똑같은 조직 문화를 초래해 결과적으로 혁신을 위한 토양을 해친다는 사실입니다.

여기서 축덕질의 여파로 '축구 감독이 선수를 비난하면 생기는 일'도 비슷한 패턴이라고 저에게 말하는 듯했습니다. 해당 문구로 구글링해 보면 AI 개요로 이렇게 답합니다.

<Fixing Bugs is Easy. Fixing Fear is Harder.>의 저자는 '혁신과 조직의 안정 가운데 하나만 택할 수 있다'고 강조합니다. 누군가를 비난하게 되면 혁신의 가능성은 희박해지는 것이죠.

왜 리팩터링이 위험한 일이 될까?

사실 <Fixing Bugs is Easy. Fixing Fear is Harder.>에서 얻는 생각만으로는 굳이 글을 쓰고 싶은 상태는 아니었습니다. 회사 동료와 화상 미팅을 하던 중에 머릿속에서 커지는 생각을 공유하고 싶은 마음이 글을 쓰게 한 것이죠. 우리 회사에서는 너무나 당연하게 허용되는 일을 할 수 없는 다른 회사 개발자에 대한 이야기를 동료에게 듣다가 제 머릿속에서 불현듯 지난 11월의 기억이 스쳐 지나갔습니다.

두 달 전 호남권 개발자 워크숍에서 박성철 님 세션을 들을 때였습니다. '리팩터링은 위험한 일'이라며 전혀 뜻밖의 이미지를 보여주었습니다. 모순적인 그 장면은 제 기억에서 지워질 수 없는 강렬한 느낌을 선사했습니다.

두 달 만에 그 기억이 살아나 제 무의식에 깔려 있던 경험과 생각을 뽑아냅니다. 자, 그 생각을 풀어보겠습니다. 베터코드 설립 이후라면 리팩터링은 너무나 당연한 일이 되었습니다. 지금 보면 아주 운좋은 일이었는데, 중국에서 처음 일할 때 한국인 개발자가 '리팩터링을 거부하는 동료'에 대해 저에게 조치를 요구했습니다. 저는 그건 문제 삼을 일이 아니라고 생각했습니다. 다시 말해 리팩터링은 각자 알아서 판단할 일이지 강제로 시킬 성격의 일은 아니라고 단언한 것이죠. 그 친구가 팀장 직급에 있었기 때문에 그 일은 큰 반향을 일으켰습니다. 결과적으로 코드에 대한 '옳고 그름'은 누군가 권위를 가지고 정하는 일이 아니라 개발자(실행 주체)에게 일임하는 일이 되었습니다. 그렇게 10년을 살아온 것이죠.

보고 중심의 업무 조직에서 리팩터링은 뭐라 보고할까?

그런데 성철 님 강의는 그렇지 않을 수 있다는 생각의 씨앗을 심어 주었습니다. 제가 만든 회사에서 리팩터링을 다루는 방식은 대부분의 개발자가 속한 조직의 그것과는 매우 다를 수 있다는 점을 생각해 본 일이 없었습니다. 그러다가 두 달이 지난 후에 화상회의에서 무심코 떠오른 것입니다.

저는 화상 미팅이 끝난 후에 <Fixing Bugs is Easy. Fixing Fear is Harder.>에서 받은 영감을 다시 떠올렸습니다. 이는 저의 과거를 다시 되짚어보고 놓쳤던 의미를 해석하게 만들었습니다.

베터코드 설립 이전을 생각해 보면 지금도 동료인 한 친구가 리팩터링을 하고 싶어 했습니다. 하지만, 이커머스 사이트에서 주문 영역 코드를 리팩터링 하는 일은 가능하지 않은 일이라는 정서가 팽배했습니다. 제가 그곳에 합류하기 전에는 고작 몇 줄의 코드를 고치는 데에도 '영향도 분석'이라는 행위로 며칠을 보내는 일이 상식적이었습니다.

저항이 있었지만, 당시 저는 디지털 전환이라고 할 수 있는 역할의 책임자였기에 동료에게 기회를 줄 수 있었습니다. 결과적으로 그는 주문 코드를 개선하는 일에서 리팩터링이 가능하다는 사실을 증명하기 시작했습니다. 단박에 해결된 일은 아니고, 꽤 긴 시간 서로 믿음이 다른 개발자들이 함께 일하면서 벌어진 일이었습니다. 그 친구는 생각이 다른 동료들의 신임을 얻어 나중에는 아예 주문 개발자가 되어 이름만 들으면 대부분 아는 회사에 이직하기에 이릅니다. 아이러니하게 그곳에서 주문 코드를 개선할 수 없는 한계를 만나서 퇴사를 결심하기에 이릅니다.

바로 그 동료와 화상 미팅을 한 것인데, 리팩터링을 둘러싼 과거를 까맣게 잊고 있었습니다. 그도 그럴 것이 베터코드에서 '리팩터링'은 '개발자가 알아서 하는 일' 정도로 여겨졌습니다. 적어도 제 의식 속에서는 말이죠.

기억을 돌려 베터코드 설립 이전 제가 IT컨설턴트(아키텍트 겸직)로 일하던 개발 조직으로 돌아가 보겠습니다. 장애가 나면 범인(?)을 찾는 일이 문제를 해결하는 일만큼이나 중요하게 여겨졌습니다. 최상위의 대표나 임원에게 보고하는 것이 가장 중요한 기성 조직의 공통적인 조직 문화라고 할 수 있습니다. 보고가 중요하기는 하지만, 보고 자체를 서두르다가 정작 중요한 요인들도 다 잃어버려 결과적으로 '가짜 일'로 보이는 일들이 중요하게 여겨졌던 것 같습니다.

그런 상황을 가정하면 긁어 부스럼을 만드는 리팩터링은 충분히 '위험한 일'이 될 수 있습니다.

통제광이 되거나 위임하거나 둘 중 하나만 가능하다

다시 앞서 인용한 이미지를 보겠습니다. <Fixing Bugs is Easy. Fixing Fear is Harder.> 저자는 그림의 좌측과 우측은 공존하기 힘든 세계라고 설명합니다.

Every time you look for someone to blame, you trade innovation for safety and that’s how organizations stop growing.

누군가의 실수를 비난한다면 안전을 얻을 수는 있지만 그 대가로 혁신을 거래(포기)하게 되고 결과적으로 성장을 멈춘다고 말합니다.

그래서 둘 중 하나만 해야 한다고 말합니다. 통제광이 되거나 위엄하거나 둘 중 하나만 하라고 말합니다.

You are either a control freak, or you give empowerment.

기업에서 IT 역할의 다음 장을 향해서...

자, 이제 도전의 시간이네요. 머릿속에서 강렬한 느낌을 얻었지만, 말로 표현해야 할 시간입니다. 분명하게 계획된 것만 만들 수 있다면 IT 역할은 축소됩니다.

벌써 6년이 되어 가는 2017년에 썼던 차세대 프로젝트 관련 글이 소환하겠습니다. 기업에서 IT 시스템을 영업 수행에 따른 제반 비용으로 여기던 풍토에서 만들어진 대표적인 현상이 '차세대 프로젝트'입니다. IT컨설팅을 하던 시절에 CIO가 CFO 조직 하위에 있거나 경영지원 산하에 있는 경우가 많았습니다. 말 그대로 비용을 쓰는 부서이고 경영을 지원하는 수준으로 인식하는 것이죠.

하지만, IT가 소비자와 만나는 서비스가 되거나 제품 자체가 되는 경우는 비용 취급할 일이 아닙니다. 제조 원가로 따져야 하는 것이고, 코드 자체가 제품의 품질을 좌우한다면 말이죠. 그리고, 소프트웨어가 기존 산업을 먹어치우는 현상은 이러한 신종 기업의 힘에 기초한다고 믿습니다. 반면에 기성 마인드 즉, IT를 비용 쓰는 지원부서쯤으로 생각하는 분들은 '개발조직을 돈 먹는 하마'로 여기기 쉽습니다.

시장을 상대로 확실히 안다고 계획하면 곤경에 빠진다

리팩터링과 사업을 위한 새로운 시도는 전혀 다른 현상으로 보이지만, 둘 다 미래의 조직 혁신을 위한 방편임에는 틀림없습니다. 예전에 계획 없이 어떤 사업적 시도를 하는 일이 두렵고 마뜩지 않았던 두 명의 대기업 임원의 이야기를 쓴 적이 있습니다. 제목이 바로 <나는 애자일이 싫다>였습니다.