완벽한 시스템은 없다. 문제 해결에 집중하자.

완벽해야만 하는 시스템

KT OSS (출처 : KTDS 사업소개)

이동통신사 인프라는 6천만 명의 고객이, 

법인고객까지 포함하자면 약 1억명의 고객이, 

쉬지 않고 트래픽을 발생시키는 시스템이다.

쉴 새 없이 전화를 하거나 인터넷을 한다.
그 트래픽은 다 미터기처럼 과금이 되는 돈이다.

스트레스와 긴장도가 이만저만한 게 아니다.
API 장애가 1분만 일어나도 수천만이 후두둑 날아간다.
무중단 무장애를 위해 완벽한 시스템을 만들려고 한다.
개발자들은 자연스럽게 완벽을 추구한다.

 

바깥을 통제할 수 없다.

KT 네트워크 구성도 (출처 : 과기부, 2023년 KT 망장애 보고서)

인증과 빌링 시스템은 그 중에서도 가장 긴장도가 높다.
바로 돈을 다루는 시스템이기 때문이다.
6천만 명으로부터 동시에 민원전화를 받을 수도 있다.
진상고객을 만나면 그 스트레스가 운영하고 있는 개발자에게까지 온다.
아, 민원처리는 정말 실다.

그런데, 이렇게 "완벽"이라는 단어가 필요한 현장에서조차 완벽한 시스템은 없다.
민원, 쉴 새 없이 이어지는 시스템 변경 등... 개발환경과 개발목표가 개떡같이 변하기 때문이다.
규칙 속에서 시스템이 돌아가도록 내버려두지 않는다.

스마트폰 규격이 느슨해서 제조사마다 동작방식이 다르다.
LG 폰에서는 오류가 나는데, 삼성폰에서는 나지 않는다.
다음 달 새로 출시되는 폰이 새로운 에러를 낸다.

예외 처리를 예측할 수도 없고, 규칙으로 묶을 수도 없다.
그런 일을 7년 8년 해야 한다.
당연히 시스템은 넝마가 될 수 밖에 없고, 개발자는 그렇게 되지 않도록 최대한 정리를 할 수 밖에 없다.

그러니 "완벽론자"가 될 수 없다.
완벽해지려면 모든 걸 통제해야 하는데, 그럴 수 없는 거다.

 

사람을 통제할 수 없다.

은행이 앱을 처음 만들었을 때 담당자들은 당황했다.
내 폰에서는 분명히 오류가 안나는데, 
어떤 고객이 오류가 난다고 자꾸 민원을 올리기 때문이다.

어찌 어찌 오류를 잡았는데, 새로운 에러가 난단다.
미쳐버릴 지경이다.
은행이 한 번도 맞딱뜨려본지 없는 상황이었다.

금융은 오류 없는 완벽한 처리를 위해, 전산 환경을 엄청나게 통제해 왔다.
그러니, 오류가 날 리 없다.
소수점 아래의 이자처리까지 맞아야 했다.

하지만, 일반들의 스마트폰을 은행 하나가 통제할 순 없다.
무결점 시스템을 만들 수 없다는 건 은행 담당자들에게 꽤 큰 스트레스였다.

 

그게 계속해서 변한다.

KB 국민은행 조직도 (업무구분)

이런 일을 겪게 되니, 완벽한 시스템을 만들기 보다 조화로운 시스템을 만드는 데 집중했다.
더러운 시스템이면 더러운 코드를 더해주고, 깨끗한 코드면 깨끗한 코드를 더해주었다.
그 자리에 맞춰 문제를 가장 잘 해결해줄 수 있도록 기능을 개발했다.

TDD니 뭐니 좋다.
그게 새로운 설계방법이라고 할 수도 있다.
그게 대부분의 문제를 해결할 수 있다 주장해도 좋다.
하지만, 예측하지 못한 문제들은 어떻게 할지 고민해야 한다.

 

정말 훌륭한 시스템도 만들어 봤다.

나보다 더 훌륭한 사람이 만든 시스템도 구경해봤다.

 

하지만 현장은 설계 당시 예측하지 못했던 문제들로 가득했다.

의사 결정 또한 설계 당시와는 다르게 내려진다.

그 당시의 설계자가 없다면 시스템은 금방 더럽혀진다.

 

완벽하겠다는 것.

그건 개발자의 공명심 같은 거다.

 

"내가 완벽한 시스템을 개발했어 !"

그런 일은 일어나지 않는다.

 

"내가 모든 공격으로부터 완벽하게 막을 수 있는 한가지 프로그램을 만들어 냈어 !"

이런 일은 허구에 가깝다.

 

그러지 말자.

그런 사람이 만들어 놓은 시스템을 유지보수 하다 빡친 적이 한두번이 아니다.

그런 사람을 한두번 만나본게 아니다.

 

제발 현재를 잘 바라보고, 유지보수를 쉽게 할 수 있도록 만들어 놓자.

ERD 라도 제대로 관리하고, 주석이라도 제대로 달아놓으면 좋겠다.

 

과거는 미래를 알 수 없다.

기능 설명 하지 말고, 왜 이렇게 만들었는지,

왜 이럴  수 밖에 없었는지 정도를 적어주면 좋겠다.

진짜 테스트라도 제대로 해보고 올려주면 좋겠다.

 

자기 모듈의 정상 작동 여부 말고,

이 모듈이 돌아야 하는 환경에서 테스트를 했으면 좋겠다.

 

내 모듈에 오류를 만들어 내는 건, 내가 잘못 짰기 때문이 아니라,

이미 짜 놓은 모듈이 지금의 상황을 생각하지 않고 짜놓았기 때문이다.

미래에 일어날 일을 알 수 없기 때문에 !!!

 

그러니까, 미래인 오늘 개발을 했다면, 그 모듈을 고려하고 개발을 해야 한다는 거다 !!!

그걸 만드는 동안은 알 수 없으니까, 연동 테스트나 통합 테스트를 하면서 알아내야 한다.

 

우아한 이론, 설명들로 현장의 문제를 가리지 않았으면 좋겠다.

 

끝.