작년 초, 3년 반의 단신 주재원 생활을 마치고 돌아왔습니다. 비록 혼자서 생활하긴 했지만, 그래도 살림집에서 생활을 하다 보니, 나갈 때는 얼마 안 되던 짐이 그사이 불고 불어 엄청난 양이 되어 있었습니다. 한국 집은 이미 기존 살림으로 꽉 차 있었고, 며칠 동안 버릴 건 버리고 옮길 건 옮기며 겨우 짐을 다 끼워 넣었습니다. 마치 살림살이들로 테트리스를 한 것 같습니다.
정리를 다 끝내고 나니, 무엇이 어디에 얼마나 있었고, 어디가 어떻게 비어 있는지가 비로소 눈에 들어왔습니다. 짐 정리는 단순히 버리는 일처럼 보이지만, 정작 중요한 건 어디에 무엇을 가지고 있는지 알게 되는 것이었습니다. 그래야 다음에 무얼 더 살지, 무얼 비울지 판단할 수 있으니까요.
사실 이건 코드 리팩토링과 다르지 않습니다. 깨끗한 코드 자체가 목적이 아니라, 무엇이 어디에 어떻게 있는지 읽어내 다음 변경을 안전하게 하기 위해서입니다. 좀 더 정확하게는 기술부채(tech debt)를 제로로 만드는 게 목적이 아니고, 기술부채를 관리 가능한 수준으로 만들어 주는 것이 리팩토링의 진짜 목적입니다.
소프트웨어 코드에서 익힌 이 원칙은 일상의 짐 정리를 하거나 조직을 관리할 때도 똑같이 적용할 수 있습니다.
목 차
완벽한 정리는 없다
코드 리팩토링을 열심히 해 보면 항상 할 일이 남습니다. 한 군데를 정리하면 다음 손볼 곳이 보이고, 그곳을 정리하면 또 다른 곳이 드러납니다. 방향이 정반대인 기법도 많습니다. 어떤 상황에서는 함수를 잘게 쪼개는 것이 옳고, 다른 상황에서는 합치는 것이 옳습니다. 추상화를 더하는 것이 정답일 때가 있고, 걷어내는 것이 정답일 때가 있습니다. 모든 코드에 통하는 단 하나의 완성된 리팩토링은 존재하지 않습니다.
관련 연구들도 비슷한 결론을 내놓습니다. 리팩토링이 코드 품질에 미치는 영향을 정량적으로 분석한 알샤예브(Alshayeb)의 연구에 따르면, 어떤 클래스에서 리팩토링이 가져온 이점이 다른 클래스의 품질 저하로 상쇄되는 경우가 많았습니다. 한쪽을 정리하면 다른 쪽이 나빠지곤 합니다. 정리에 완벽한 방법이 없습니다.
더 근본적으로 “어떤 순서로 정리하는 것이 최적인가”라는 질문조차도 답이 없습니다. 컴파일러는 코드를 최적화할 때 여러 변환을 순서대로 적용하는데, 이 변환들은 적용 순서에 따라 결과가 달라집니다. 그런데, 최적의 순서를 찾는 건 거의 불가능하기 때문에 경험칙(휴리스틱)에 기대어 적당한 순서를 고릅니다.
여기에 더해 결정적인 사실이 하나 더 있습니다. 일은 고정되어 있지 않고 계속 변화합니다. 요구사항이 바뀌면 코드도 따라서 자라고 죽습니다. 새 기능이 들어오고 낡은 코드가 사라집니다. 짐 정리를 아무리 잘 해놔도 생활하다 보면 끊임없이 물건을 사고 버리는 것과 똑같습니다. 그래서 완벽한 정리는 불가능할 뿐 아니라, 설령 한순간 도달한다 해도 의미가 없습니다. 도달하는 순간 이미 지형이 달라져 있기 때문입니다.
리팩토링이 일어나는 단위
리팩토링은 크게 두 단계가 있습니다. 대규모 리팩토링과 데일리 리팩토링입니다.
코드로 보면 분명합니다. 구조를 통째로 다시 설계하거나 소프트웨어 스택을 바꾸는 것과 같은 대규모 리팩토링이 있고, 커밋마다 변수명을 다듬고 함수를 쪼개는 데일리 리팩토링이 있습니다. 짐으로 보면 이사나 대청소 같은 큰 정리가 있고, 매일 물건을 제자리에 두고 버릴 것을 버리는 일상의 정리가 있습니다. 두 단계의 리팩토링은 짐 정리나 코드에서 똑같이 반복됩니다.
당연히 둘 중 어느 하나를 소홀히 하면 안 됩니다. 대규모 리팩토링만 있으면 그 사이에 각종 부채가 쌓여, 다음번 리팩토링을 할 때쯤이면 현재 상태를 파악하는 것부터 버거워집니다. 반대로 데일리 리팩토링만 있으면 하루하루 지저분한 문제는 제거할 수 있지만, 누적된 구조적 문제를 풀지 못합니다. 결국 두 단계가 함께 돌아가야 합니다. 큰 정리로 지형을 한 번 다시 그리고, 데일리 정리로 그 지형을 읽을 수 있는 상태로 유지하는 것입니다.
목표는 현황 파악
완벽한 정리는 불가능하고, 지속적으로 변화하기에 따라가기가 어렵다면, 정리 혹은 리팩토링의 목표는 무엇이어야 할까요? 제가 생각하기에, 그 목표는 어떤 완성된 상태에 도달하는 것이 아니라, 지금 무엇이 어디에 얼마나 있는지 아는 상태를 유지하는 것입니다.
소프트웨어 공학은 이 목표에 이름을 붙여 두었습니다. 리팩토링이 높이려는 핵심 품질 속성 중 하나가 이해가능성(understandability)입니다. 코드를 정리하는 이유는 깨끗함 자체가 아니라, 읽고 이해해서 다음 변경을 안전하게 할 수 있기 위해서입니다. 이해가능성은 코드 가독성과 개발자 생산성, 그리고 장기 유지보수성을 가르는 근본 요소로 꼽힙니다.
그런데 이런 현황 파악은 따로 마음먹는다고 되는 것이 아니고 정리의 결과물입니다. 제대로 정리되어 있어야 비로소 무엇이 어디에 얼마나 있는지 보입니다.
여기서 부채의 진짜 위험이 드러납니다. 부채는 단순히 지저분한 상태가 아니고, 현황 파악을 어렵게 만드는 것입니다. 짐이 정리되어 있지 않으면 무엇이 있는지 몰라 또 사게 되고, 기술부채가 쌓이면 코드가 어떻게 얽혔는지 몰라 손을 못 댑니다. 부채를 줄이는 이유는 깨끗함이 아니라, 변화하는 대상의 현재 상태를 언제든 읽고 다음 결정을 내리기 위해서입니다.
그리고 그 현황 파악은 대규모 리팩토링과 데일리 리팩토링, 두 정리가 함께 돌아갈 때 잘 유지됩니다.
조직 관리, 조직 부채
조직 관리도 다르지 않습니다. 조직의 일은 처음 정한 대로만 흘러가지 않습니다. 늘 새로운 일이 생기고, 기존 일은 줄거나 사라집니다. 어떤 완벽한 조직도를 그려 두어도 다음 분기면 일의 지형이 달라져 있습니다. 조직 역시 변화하는 대상입니다.
그래서 조직에도 두 단계의 정리가 필요합니다. 조직 개편 같은 큰 재구성이 있고, R&R을 조정하고 업무를 옮기는 상시적인 정리가 있습니다. 이것이 쌓이지 않고 처리되지 못한 채 남으면 조직부채(org debt)가 됩니다. 역할의 중복, 끊긴 책임, 아무도 설명하지 못하는 프로세스가 그것입니다.
조직부채가 위험한 이유도 기술부채와 같습니다. 쌓이면 리더가 조직의 현황 자체를 못 읽습니다. 큰 조직을 보면 모두가 바쁜 것 같지만, 막상 일은 늘 하는 사람만 합니다. 주방에 그릇이 가득 차 있어도 매번 쓰는 그릇은 정해져 있는 것과 같습니다. 누가 무엇을 얼마나 하고 있는지 파악되지 않으니, 새 일이 들어왔을 때 어디에 두어야 할지 판단하지 못합니다. 결국 일은 또 늘 하던 사람에게 얹히고, 쓰지 않는 그릇은 자리만 차지한 채 쌓입니다. 짐이 정리 안 되면 이미 있는 물건을 또 사들이듯, 조직부채가 쌓인 조직은 비효율이 쌓여갑니다.
변화하는 환경에서 현재 상태를 읽어내는 능력과 관련해서는 조직 이론에서도 다루고 있습니다. 엔즐리(Mica Endsley)가 정리한 상황 인식(Situational Awareness)입니다. 지각하고, 이해하고, 앞을 내다보는 세 단계로 이루어진 이 개념은 항공이나 의료처럼 상황이 빠르게 변하는 동적 환경에서 의사결정의 품질을 가르는 요소로 다뤄집니다. 조직 차원에서는 구성원이 공유하는 집합적 상태이며, 리더가 실제 운영 프로세스를 이해하고 정의하려 할 때 비로소 갖춰집니다. 코드의 이해가능성과 조직의 상황 인식은, 표현이 다를 뿐 같은 곳을 가리킵니다. 변화하는 흐름 속에서 현재를 읽을 수 있는 상태입니다.
이 문제는 AX 시대에 더 중요해집니다. AI가 일하는 방식을 바꾸면서 조직은 더 유연하고 애자일해질 것입니다. 그런데 흔히 생각하는 순서는 반대인 경우가 많습니다. 화려한 AI 기술을 먼저 가져다 붙이려 합니다. 정작 급한 것은 그 전에 숨어 있는 비효율을 찾아내는 일입니다. 쓰지 않는 그릇이 무엇인지, 누가 무엇을 얼마나 하고 있는지부터 읽어내야 합니다. AI는 일을 처리하는 방법(How)이고, 무엇을 정리하고 없앨지(What)를 모르면 화려한 도구도 비효율 위에 얹힐 뿐입니다. 흐름이 빨라질수록, 현황을 읽어 조직부채를 낮게 유지하는 일이 먼저입니다.
정리되지 않은 조직에 AI를 적용해도 정리되지 않는 상태는 유지됩니다.
맺음말
코드는 수시로 리팩토링을 해서 기술부채를 줄여나가야 합니다. 조직은 수시로 현황 파악을 하고 업무를 정리해서 조직부채를 줄여야 합니다. 둘 다 완벽한 상태를 만들기 위한 작업이 아니라, 흐름 속에서 현재를 읽을 수 있도록 유지하기 위한 작업입니다.
리더의 일은 완벽한 조직을 설계하는 것이 아닙니다. 언제든 “지금 우리 조직이 어떤 상태인가”를 읽을 수 있도록, 정리를 멈추지 않는 것입니다. 엔지니어 관점에서 개발을 하면서 배운 원칙을 그대로 조직 관리에도 적용할 수 있습니다.
완벽한 정리는 없습니다. 읽을 수 있는 상태가 있을 뿐입니다.
ChulJoo Kim (김철주)
※ 참고문헌
- Mica R. Endsley, 「Toward a Theory of Situation Awareness in Dynamic Systems」, Human Factors 37(1), 1995.03, https://doi.org/10.1518/001872095779049543
- Mohammad Alshayeb, 「Empirical investigation of refactoring effect on software quality」, Information and Software Technology 51(9), 2009.09, https://doi.org/10.1016/j.infsof.2009.04.002
- Satnam Kaur, Paramvir Singh, 「How does Object-Oriented Code Refactoring Influence Software Quality? Research Landscape and Challenges」, arXiv, 2019.08, https://arxiv.org/abs/1908.05399
- Ameer Haj-Ali et al., 「AutoPhase: Compiler Phase-Ordering for High Level Synthesis with Deep Reinforcement Learning」, arXiv, 2019.01, https://arxiv.org/abs/1901.04615
- Martin Fowler, 「Refactoring: Improving the Design of Existing Code (2nd Edition)」, Addison-Wesley, 2018.11, https://martinfowler.com/books/refactoring.html
ckarch.kr
© 2026
is licensed under
CC BY-NC-SA 4.0
