오래된 시스템, "왜 이렇게 만들었을까" — 체스터턴의 울타리

이론과 현장 - 7

오래 쓴 시스템을 전면적으로 다시 만드는 일이 부쩍 늘었습니다. 만드는 비용이 내려가면서 엄두를 못 내던 것을 시도하게 됐습니다.
그리고 그 과정에서 자주 나오는 말이 있습니다.
"이건 왜 이렇게 만들었을까요."
새로 구축하는 쪽에서 보면 이해가 안 되는 것이 많습니다. 같은 기능이 두 군데 있고, 안 쓰는 화면이 남아 있고, 조건문이 겹겹이 쌓여 있습니다.
그 말이 틀린 것은 아닙니다. 지금 기준으로 보면 정말 비효율적입니다.
그런데 만들어 온 쪽의 말도 맞습니다. 그때는 그럴 만한 이유가 있었습니다.
그리고 "만들어 온 쪽"이 한 사람도 아닙니다.
처음 만든 사람이 있고, 그것을 이어받은 사람이 있고, 또 그다음이 있습니다. 중간에 들어온 사람들도 똑같이 "왜 이렇게 만들었을까"를 겪었습니다.
그리고 각자 자기 시점의 조건에 맞춰 고쳤습니다.
둘 다 맞아서 갈등이 풀리지 않습니다.

체스터턴의 울타리

작가 길버트 체스터턴이 남긴 비유가 있습니다.

들판 한가운데 울타리가 있습니다. 왜 있는지 모르겠으니 치우자고 합니다.

핵심은 "치우지 마라"가 아닙니다. "알고 나서 치우라"입니다.

순서에 대한 이야기이지 변화를 막는 이야기가 아닙니다.

스파게티에는 시간이 담겨 있습니다

오래된 시스템의 코드를 흔히 스파게티라고 부릅니다. 면이 얽혀 있어 한 가닥만 집어낼 수 없는 것처럼, 한 군데를 고치면 어디가 영향받는지 알기 어려운 상태를 말합니다.

그런데 그것은 실패의 결과가 아니라 시간의 결과입니다.

처음부터 그랬던 것이 아닙니다. 회사가 자라는 동안 하나씩 붙은 것입니다.

무엇이 담겨 있나

코드에 남아 있는 것

조직이 커진 흔적 — 소규모일 때 만든 것 위에 계속 얹혔습니다

프로세스가 바뀐 흔적 — 여러 번 고쳐진 자리입니다

그때의 기술 제약 — 지금은 쉬운 것이 그때는 어려웠습니다

예외 처리 — 실제로 그런 일이 있었다는 증거입니다

특히 마지막이 중요합니다.

이상해 보이는 조건문 하나가, 몇 년 전 어떤 사고를 막기 위해 들어간 것일 수 있습니다. 그 사고를 겪은 사람은 그 조건이 왜 있는지 압니다. 그런데 코드에는 안 적혀 있습니다.

울타리가 여러 개 있고, 각각 다른 시점에 세워졌습니다.

결과를 알고 과정을 비판합니다

재구축을 맡은 쪽의 판단에는 한 가지 이점이 있습니다. 결과를 이미 알고 있다는 것입니다.

어떤 기능이 결국 안 쓰이게 됐는지, 어떤 구조가 나중에 발목을 잡았는지. 지금은 다 보입니다.

그때는 몰랐습니다. 그리고 몰랐다는 것이 판단의 조건이었습니다.

주식을 왜 그 시점에 안 팔았느냐는 말과 같습니다. 지금 가격을 알기 때문에 할 수 있는 말입니다.

그리고 기술 여건도 달랐습니다

지금은 필요한 기술을 찾아 가져다 쓰면 됩니다. 문서도 많고, 물어볼 데도 많습니다.

그때는 그렇지 않았습니다. 참고할 사례가 적었고, 쓸 수 있는 도구가 제한적이었습니다.

그래서 돌아간 것이고, 돌아간 흔적이 남은 것입니다.

어려운 것은 그때 그 자리에서 정하는 일입니다

정보가 없고, 시간이 없고, 앞으로 무엇이 필요해질지 모르는 상태에서 일단 돌아가게 만들어야 했습니다.

그리고 대개는 그 판단이 맞았습니다. 회사가 그 시스템으로 몇 년을 굴렀다면요.

잘못 만든 것이 아니라, 그때 조건에서 만들어진 것입니다.

AI가 바꾼 것과 바꾸지 않은 것

만드는 일은 확실히 쉬워졌습니다. 예전 같으면 엄두를 못 냈을 재구축을 시도하게 된 것도 그래서입니다.

그런데 쉬워진 것은 만드는 일뿐입니다.

알아야 할 것이 둘 있습니다

하나는 과거입니다. 왜 그 조건이 거기 있는지, 왜 그 예외가 들어갔는지.

코드를 읽어도 안 나옵니다. 적혀 있는 것은 무엇을 하는가이고, 적혀 있지 않은 것은 왜 그렇게 하는가입니다. 아는 사람에게 물어야 합니다.

다른 하나는 현재입니다. 지금 현업이 무엇을 필요로 하는가.

이것도 어렵습니다. 무엇이 필요한지를 말로 정리하는 것 자체가 어려운 일이고, 그건 예전에도 마찬가지였습니다. 정확한 요구사항이 처음부터 나오는 경우는 드뭅니다.

둘 다 안 빨라졌습니다

한 줄만 바뀌었습니다.

두 가지를 각각 파악해야 합니다

재구축 프로젝트에서 대개 현행 시스템 분석을 합니다. 기능 목록을 뽑고, 화면을 정리하고, 데이터 구조를 봅니다.

그런데 거기까지는 "무엇을 하는가"입니다. "왜 그런가"는 안 나옵니다.

과거는 사람에게 물어야 합니다

코드는 남아 있습니다. 왜 그렇게 짰는지는 사람에게 있습니다.

그리고 그 사람이 한 명이 아닙니다. 처음 만든 사람은 이미 없을 가능성이 큽니다. 중간에 이어받은 사람은 있을 수 있습니다. 그 사람도 전부는 모르지만, 자기가 고친 부분은 압니다.

왜 그랬는지는 여러 사람에게 나뉘어 있습니다.

물었을 때 나오는 답은 대개 셋입니다.

세 번째에서 흔히 "모른다니 없애자"로 갑니다.

그런데 모른다는 것은 이유가 없다는 뜻이 아닙니다. 아는 사람이 나갔거나, 이유가 어디에도 안 적혔을 뿐입니다.

"모르겠다"는 없애도 된다는 뜻이 아니라, 아직 판단할 수 없다는 뜻입니다.

현재는 시스템이 아니라 업무를 봐야 합니다

현행 시스템을 아무리 분석해도, 그 안에 없는 것은 나오지 않습니다. 불편해서 밖에서 하고 있는 일 같은 것요.

그런데 더 흔한 것은 그 반대입니다.

현업이 시스템에 맞춰 일하고 있습니다. 시스템이 그렇게 되어 있으니 그렇게 하는 것이지, 원래 그렇게 해야 해서가 아닙니다.

그리고 오래되면 그게 원래 업무인 줄 알게 됩니다.

밖에서 하는 것은 본인이 압니다. 그런데 맞춰서 하는 것은 본인도 모릅니다.

그래서 갭을 찾아야 합니다

지금 업무가 어떻게 돌아가는지와, 시스템이 무엇을 담고 있는지는 다릅니다. 그 차이가 갭입니다.

세 번째가 잘 안 보입니다. 본인도 모르기 때문입니다.

그래서 "무엇이 불편하십니까"만 물어서는 안 됩니다. 그건 본인이 아는 것만 나옵니다.

업무를 처음부터 다시 그려 보고, 시스템이 담고 있는 것과 맞춰 봐야 합니다. 그 사이에서 갭이 드러납니다.

업무 절차에도 울타리가 있는데, 그 울타리가 시스템 때문에 생긴 것일 수 있습니다. 그건 업무의 울타리가 아닙니다.

지금 만드는 것도 오래된 시스템이 됩니다

다만 지금 파악한 것도 지금의 것일 뿐입니다.

요구사항을 아무리 잘 정리해도 그것은 지금 시점의 요구사항입니다. 그리고 그때 만든 사람들도 그 시점의 요구사항을 정확히 담았을 것입니다.

시스템은 현업의 업무를 담는 것입니다. 그리고 업무는 계속 변합니다.

조직이 커지고, 프로세스가 바뀌고, 밖의 조건이 달라집니다. 그러면 시스템도 따라 바뀝니다. 고치고, 더하고, 또 고칩니다. 그러다 전체를 다시 만들게 됩니다.

지금 하는 재구축이 그 순환의 한 지점입니다.

몇 년 뒤에 누군가 우리가 만든 것을 보고 같은 말을 할 것입니다.

"이건 왜 이렇게 만들었을까요."

그때도 이유가 있을 것입니다. 그 시점의 조직, 그 시점의 업무, 그 시점의 기술. 그리고 그 이유는 코드에 안 적혀 있을 것입니다.

그러니 남겨 두면 됩니다. 왜 그렇게 했는지를요.

지금 우리가 아쉬워하는 것이 정확히 그것입니다.

관련 글

[현장의 질문들] PI만으로는 부족합니다 — 시스템 도입 전에 정할 것들

[이론과 현장] 기업의 지식이란 무엇입니까 — 암묵지를 형식지로 바꾸려다 실패한 뒤

[현장의 질문들] 지식관리시스템은 왜 대부분 실패했습니까