소프트웨어도 지속적으로 재구성해야 살아남을 수 있다

감히 시도하는 설계의 정석

Mar 4. 2026

<단순함은 일 처리 방법이 아니라 일을 대하는 마음가짐>을 쓰는 중에 떠오른 생각을 담은 글입니다.

복합적인 규칙을 무시하면 복잡함이 찾아옵니다

인용했던 구절을 다시 보겠습니다.

소프트웨어의 복합적인 면을 다루기 어렵지만, 그 안에는 분명한 규칙이 존재합니다. 하지만 그 규칙을 무시하면 '복잡함'이 찾아옵니다. 그리고 이 복잡함은 우리의 프로젝트를 이해할 수도, 예측할 수도 없는 엉킨 논리 덩어리로 만들어 버립니다. <중략> 복잡함을 다루는 일은 규칙도 모른 채 게임을 하는 것과 같습니다. 더 심각한 문제는 이 규칙은 애초에 알 수 없다는 점입니다.

흔히 개발자들이 '이 건 그대로 나가면 안 됩니다'와 같은 식으로 말할 때가 많습니다. 지금 생각해 보면 놀라운 일인데, 너무나 자주 벌어지기에 둔감해진 일이기도 합니다.

제가 놀라운 부분은 미리 고지하거나 교육하지 않아도 상당수의 많은 개발자가 그런 태도를 보였다는 점입니다. 그렇지만 대개의 경우는 무시당하고 맙니다. 가장 큰 이유는 개발자가 합당한 이유를 설명하지 못하기 때문입니다.(개발자 탓이라는 뜻은 아닙니다.)

그리고, 긴 시간 생각지 못했던 생각을 하게 되었습니다. 어쩌면 그렇게 간과하는 조직적인 합의(?)가 기술 부채를 낳는 것일 수 있다는 가설이죠. 마치 긴 시간 알 수 없던 영역에 있던 지식이 다른 4분면 이동하려는 것이 아닌가 싶습니다.

대개는 모든 것을 다 정하면서 개발할 시간이 없다

그런데 왜 그럴까요? 다시 한번 저자의 주장을 읽어 보겠습니다.

소프트웨어의 복합적인 면을 다루기 어렵지만, 그 안에는 분명한 규칙이 존재합니다. 하지만 그 규칙을 무시하면 '복잡함'이 찾아옵니다. 그리고 이 복잡함은 우리의 프로젝트를 이해할 수도, 예측할 수도 없는 엉킨 논리 덩어리로 만들어 버립니다.

앞서 말한 선의를 가진 다수 개발자의 행동 패턴을 떠올려 보겠습니다. 지금 당장 정할 수 없는 의사결정 요소들을 들고 질문을 던집니다. 개발자에게 질문을 받은 사람은 열심히 답을 하다가 벽을 만납니다. 지금은 알 수 없는 탓일 수도 있고, 자신의 결정 범위를 넘어서는 것일 수도 있기 때문입니다. 거기서 (두 사람이 감정에 이끌리거나 사실을 숨기지 않아 놀랍게도) 아주 정교한 소통이 일어나지 않는다면, '그 문제'는 덮고 당장 중요한 기능만 개발하자는 결론에 도달합니다.

이는 일종의 학습된 무기력(learned helplessness)으로 개발자들의 행동 양식이자 조직의 문화로 자리 잡는 일을 어렵지 않게 관찰할 수 있습니다. 그동안 전혀 별개의 문제를 연결하게 된 바탕에 작동한 문구가 하나 더 있습니다.

언러닝이나 비슷한 행위가 없다면 기술 부채는 필연이다

놀랍게도 이 글과 아무런 상관도 없어 보이는 <언러닝>을 읽고 쓴 <리더가 관성에 빠지면 통제 불가능한 간접비용을 낳는다>에 나오는 내용이자 그 제목입니다.

그들은 오직 일상적인 경영 활동을 통해 얻은 정보나 편견을 바탕으로 주위 세계를 바라보는 근시안적인 시각에 사로잡힌다. 리더들은 빠르게 성과를 내야 한다는 중압감 탓에 비즈니스의 결과물을 찬찬히 되돌아보고 반성할 기회가 없다.

집단적으로 말하면 우리는 <왜 소프트웨어가 유통업을 먹어치우고 있는가?> 같은 질문에 답을 할 수 없습니다. 그저 창발적으로 벌어진 그 일을 두고 생각할 수 있을 뿐입니다.[1] 그래서, 언러닝이 주는 교훈을 이용해서 개발자들의 행동과 후속으로 벌어지는 학습된 무기력(learned helplessness) 현상을 이렇게 해석해 볼 수 있습니다.

그저 변화에 적응해 보려는 기업인들은 소프트웨어(혹은 디지털 기술, 클라우드 아니면 인공지능 따위)를 도입했을 뿐입니다다. 그 변화에 적응하기 위해 어떻게 사고해야 하는지 모릅니다. 어떤 결정은 내릴 수 있는지조차 알지 못하기에 그들은 배울 기회가 필요합니다. 쓰다 보니 그 과정을 바로 <언러닝>이라고 부를 수 있습니다.

자연은 균형을 맞추기 위한 활동을 강요하는 걸까?

조금 생뚱맞을 수도 있지만, 이미 거리가 먼 경험과 지식들을 연결하고 있으니 그냥 가 보죠. 2009년에 있었던 개발자 행사에서 애자일 프랙티스에 대한 경험을 발표한 적이 있습니다.

어떤 이유였는지 기억이 나지 않지만, 발표를 시작할 때, 계절의 순환을 예로 들어 '반복'의 필요성을 강조했습니다. 그때부터 지금까지 그 계절 중에서 '겨울'의 필요성에 대해 한 번도 생각해 본 일이 없습니다. 인공지능 삼총사에게 빠르게 물어보겠습니다.[2]

그 결과 중에서 눈에 띄는 문구만 모아 보았습니다.

인간관계도 지속적으로 재구성을 해야 한다

여기서 또 다른 우연이 강력한 지적 자극을 줍니다. <단순함은 일 처리 방법이 아니라 일을 대하는 마음가짐>을 쓰는 중에 <흥미로운 Tidy First 고찰>을 찾았는데, 글 속에 전혀 뜻밖의 내용이 있었습니다.

심리학 책의 소개 문구는 '나의 관계를 재구성하라'라고 합니다.

이때 가장 먼저 챙겨야 할 사람은 바로 나 자신이다. 프로그래머로써의 임무가 아니라 개성을 갖춘 나 말이다. 2019년 흥미롭게 읽었던 <관계를 읽는 시간>이라는 책이 있다. 그 책에는 인간관계로 고생하는 사람들을 상담해 온 전문가가 자신이 경계 설정의 중요성을 설파한다.

그렇습니다. 인간관계도 삶의 다양한 활동과 주변의 변화로 인해 복잡해집니다. 그대로 두면 탈이 날 수 있습니다. 갈등이 생길 수도 있지만, 자신의 내면이 힘들어지거나 심지어 마음의 병이 생기기도 합니다. 갑자기 왜 심리학 이야기냐고요?

소프트웨어도 지속적으로 재구성해야 살아남을 수 있다

생뚱맞게 순환하는 계절 그중에서도 특히 수축의 계절인 겨울을 지나 봄이 오는 장면을 두고 지속하기 위해 필연적인 과정인가 생각해 보았습니다. 인간관계의 경우도 내 역할이나 상황이 바뀌면 재조정을 해야 한다는 측면에서 어딘가 비슷한 점이 있다는 생각이 들었습니다.

마찬기지로 우리가 다뤄야 할 업무와 그 업무의 대상이 되는 자료와 파일 그리고 절차도 마찬가지죠. 소프트웨어는 우리가 하는 일의 형태를 혁신하기 위한 매개체에 지나지 않습니다. 혁신적인 도구지만 목적 자체는 아니니까요. 그러므로 소프트웨어 개발 역시 지속하기 위해서는 어떤 형태로든 순환하며 재조정하는 절차를 만들어 넣어야 이 자연이 요구하는 진화의 압박에 견뎌낼 수 있을지도 모른다는 증명할 수 없는 생각으로 글을 마찹니다. 다만, 그 진화의 압박은 생물학적인 것이 아니라 시장 경쟁의 형태로 마주하게 됩니다.

글을 다 쓰고 나서 짧은 시간 차이를 두고 본 두 개의 이미지가 이 글에 다룬 주제를 둘러싼 이야기를 전개하는 듯해서 첨부합니다. 왼쪽은 MIT Sloan의 기사로 생성형 AI로 만들어낸 코드의 숨은 비용을 말합니다. 오른쪽은 링크드인에서 인도 친구 프라샤드Prasad의 링크드인 글에 첨부된 이미지입니다.