어차피 이곳에서 짤릴 각오를 하고 그동안 꾹꾹 눌러 담았던 이야기를 하고자 합니다.
저는 간혹 SI 업체의 면접을 보곤 합니다. 제 경력의 상당수는 FA와 의료 시스템 같은 특수 분야에 있기 때문에 상당한 호기심과 기대에 찬 마음으로 면접을 보러 갑니다. 하지만 지금까지 단 한 번도 저의 예상에서 벗어난 적이 없었습니다. 얼마나 빠르게 코딩할 수 있느냐의 기준에서만 보는 것이었죠.
저는 의료, 금융, 건설에서 회계나 물류, 인사와 관련된 프로젝트 경험이 거의 없습니다. 따라서 SI 개발자가 저의 업무 이해 수준을 낮게 평가하는 것을 매우 당연하게 받아들입니다. 그러나 반대로 SI 개발자들은 자신들이 프로그래밍에서 포인터, 스레드, 객체지향과 디자인 패턴, 윈도우즈 SDK 프로그래밍, 이미지 프로세싱 등에 수준이 낮다는 것을 굉장히 자존심 상하는 듯이 이야기합니다. 대체 왜 그럴까요.
저는 의료 SI 업체에서, 혹은 금융 SI 업체에서 잠시 일했던 경험이 있습니다. 의료 SI는 수십 년 동안 엄청난 변화를 몸소 겪으면서 그 이해의 폭과 깊이가 다릅니다. 예를 들어 지난 코로나 때 정부로부터 수시로 변경된 새로운 지침과 법률을 해당 시스템에 적용하기 위해 얼마나 많은 회의와 배포 과정을 거치는지를 경험했습니다. 의료 SI 10년 차, 20년 차의 의료 업무에 대한 이해는 디테일한 부분까지 엄청난 것입니다. 마찬가지로 물류나 회계 분야에서도 심지어 박사 학위를 가진 분들도 계십니다. 이 부분을 깊이 있게 공부한 개발자를 실제로 만나 본 적도 있습니다.
그런데요, 시스템 프로그래머들은 어떤가요. 포인터나 스레드를 밥 먹듯이 사용하면서 우리는 해당 시스템의 하드가 SSD인가 HDD인가에 따라 회전시킬 레코드 개수의 최대 범위를 직감적으로 설정할 수 있습니다. 또한 스레드 사용에 있어서 동기화 문제가 해당 라이브러리의 구조적 문제일 수 있다는 경험도 상당히 많습니다. 이것뿐만이 아닙니다. CPU 구조를 이해하기 위해 어셈블리를 공부하고 SSE와 MMX의 병렬처리를 연구합니다. 이것이 바탕이 되어 GPU 병렬처리 API에 엄청난 열광을 하게 됩니다. 그러나 이런 노력에도 불구하고 복잡성의 관리에 있어서는 클래스만으로 한계를 느낍니다. 상속을 하면 이상하게 더 꼬여 들어갑니다. 클래스 의존성이라는 것을 알게 되었고 이것을 해결하기 위해 디자인 패턴을 학습합니다. 이렇게 수많은 기술적 한계를 극복하기 위해 개인적으로 엄청난 공부를 해야 합니다. 보통 시스템 프로그래머들은 회사를 그만두고 최소한 6개월 이상 이런 부분에 대한 개인적인 학습을 하곤 합니다.
제가 지금까지 SI 업체에서 경험한 단 두 가지 이야기만 하겠습니다. 한 번은 업체에서 특정 문제를 해결해주면 상당한 보수를 주겠다고 했습니다. 그것은 시리얼 통신과 함께 얽혀 있는 SI 소스 프로젝트였습니다. 소스 코드를 보니 하나의 유닛 파일에 5만 라인 이상을 누적시켜 놓았더군요. 저는 그곳에 가서 일주일 동안 해당 5만 라인 코드를 각각의 클래스로 분리했습니다. 그리고 2주째 마침내 문제를 발견하고 해결했습니다. 그런데 이것을 해결하자 당황스러운 일이 벌어졌습니다. 저는 그 문제가 해당 회사에서 1년 동안 해결하지 못해 끙끙대던 것이라는 사실을 알지 못했고, 제가 너무 빠른 시간 안에 해결하자 담당 개발자 2명이 사직서를 낸 것이었습니다.
이와 비슷한 일이 또 있었습니다. 그곳도 마찬가지로 물류와 하드웨어 시스템이 결합된 곳이었습니다. 그곳은 더 어마어마했습니다. 하나의 main 함수에 약 2만 라인까지 들어 있었습니다. 저는 이것을 분리하느라 정말 고생했습니다. 결국은 해결했지만, 해당 회사에서 계속 근무해 달라는 요청을 뿌리치고 도망쳐 나와야 했습니다. 저렇게 줄 코딩이 심각한 회사는 미래도 없고, 돈을 아무리 많이 준다고 해도 스트레스로 몸이 망가질 것이 뻔했기 때문입니다.
SI 업체에서는 보통 해당 업무에 능통한 사람만 뽑는 경향이 많습니다. 그러나 제 생각에는 정말 답답한 관점입니다. 만약 제가 SI 업체의 팀장이나 사장이었다면, 해당 업무를 잘 아는 사람도 중요하지만 개발 관점에서 수준이 높은 사람도 반드시 필요하다고 생각했을 것입니다. 현재 제 수준에서 C++ 프로젝트나 SI 프로젝트를 보면 옵저버 패턴이나 스테이트 패턴만 써도 나중에 관리 비용이 한 사람 분량 정도 줄어들 것이라고 생각되는 곳들이 정말 많습니다. 그리고 이런 관점의 차이는 또 있었습니다.
대형 의료 시스템 업체였습니다. 한 번 검색하는 데 3분 이상 걸렸습니다. 저는 이 문제가 해괴하다고 생각했습니다. DB는 오라클이었는데 왜 이렇게 오래 걸리는지 이해가 되지 않았기 때문입니다. 그래서 날을 잡아 문제를 파악했습니다. 해당 SQL문에는 정렬이 포함되어 있었습니다. 이 정렬을 하지 않으니 단 1초 이내에 검색 결과가 리턴되었습니다. 그래서 수억 건의 데이터 중에서 2만 건 정도의 레코드를 일단 1초 이내에 내려받아 클라이언트에서 정렬해 그리드에 출력하자 문제가 해결되었습니다. 이 해결 방법을 알려주자 SI 개발자는 이해하지 못했습니다. 어째서 오라클인데 그렇게 느리고 또 어떻게 클라이언트에서는 그렇게 빠를 수 있냐는 것이었죠. SI 개발자들의 한계를 여실히 보여주는 경험이었습니다.
저는 위 글에서 SI 개발자의 소프트웨어 개발 역량이 낮다는 것을 비난하려는 목적이 아닙니다. 그것은 어쩔 수 없는 것이며, 우리 시스템 프로그래머들이 회계, 물류, 의료 시스템에 무지한 것과 다르지 않다는 사실을 이해시키기 위함입니다. 또한 SI 프로젝트에서도 수준 높은 시스템 프로그래머가 필요한 이유는 바로 성능과 속도뿐만 아니라 복잡성에 대한 엄청난 관리 능력이 요구되기 때문이라고 말씀드리고 싶습니다. 우리가 SI 개발자들에게 여러분의 전문 업무 분야에 대해 자랑하거나 우쭐대지 않듯이, 여러분들도 소프트웨어 개발 수준에 있어서 우리에게 자랑하거나 우쭐대지 않았으면 하는 아주 기본적인 바람일 뿐입니다.
감사합니다.