brunch

You can make anything
by writing

C.S.Lewis

by JorbaChoi Jan 26. 2023

을의 Digital Finance 블로그 (2)

국내 IT서비스 생태계 발전을 위해  - "좋은 SW란 무엇인가?"

90년 초부터 “업”으로서 IT서비스를 수행해 오면서, 나름 보람 있는 일도 많았으나 돌아다보면 어떤 사회적인 가치를 창출하고 있는지,  어떤 흔적을 남기고 있는지 가끔 자문하게 되었다.  우리나라 경제와 사회가 발전하는 데, 지원과 촉매제의 역할도 해 왔고 어떨 때는 주도적인 역할을 수행해 오기도 했던 거 같다.  나는 국수주의자는 아니지만, 그래도 우리나라 사회의 일원으로 선진국으로 발전하는 IT서비스는 어떤 모습이어야 하는지 무의식적으로도 고민해 왔었던 거 같다.  이러한 질문이 디지털 시대에 접어들어 IT가 더 주도적인 역할을 요구받게 되면서 고민의 깊이는 더 커져갔고,  단순히 개인적으로 기술을 연마한다고 또는 개별조직의 역량이 강화된다고 해결될 수는 없는 생태계 차원의 문제도 있음을 인지하게 하게 되었던 거 같다. 


"국내 IT서비스 생태계의 문제점은 무엇이고 발전방향은 무엇인가?"라는 질문은 범위가 커서 자칫 일반론에 치우칠 우려가 있다.  또 대상이 되는 SW의 종류가 많기도 하고  SW 경쟁력에 대한 객관적인 지표도 찾기 힘들어 보인다.  한편으로는 IT서비스 업계에서 오늘도 불철주야 노력하고 계신 분들의 노력과 결과물을 혹시나 폄훼하지는 않을까 걱정도 있다.  하지만 보다 발전적인 방향을 논의하고자 하는 개인적인 관점으로 너그럽게 봐주시면 좋겠다. 


논의에 앞서 범위와 용어를 간단히 정의해 가보고자 한다.  본 블로그에서  IT서비스업은  서비스업인 3차 산업으로 국한해보고자 하며,  통상 반도체, HW 같은 제조업은 제외하고,  주로 SW산업을 중심으로 살펴보고자 한다.  SW가 세상을 먹어 치운다라는 말처럼, HW보다는 SW경쟁력이 더 중요해지고 있고,  HW를 조립하고 구성하는 작업조차  IaC(Infra as a Code) 즉  SW화 되어 가는 클라우드 환경에서,  IT서비스 산업을 SW를 중심으로 국한해도 크게 무리가 없으리라 생각한다. 


이렇게 SW 중심으로 IT서비스 산업의 경쟁력, 문제점을 크게 두 가지 측면에서 살펴보고자 한다.  첫째,  최종 산출물인 Output으로서의 SW가 선진국 대비 얼마나 경쟁력이 있는가?  를  상용 SW, 맞춤 SW 각 영역별로 살펴보고자 한다.  두 번째,  Input으로서의 SW 투입요소들의 경쟁력은 어떠한가? 에 대해 생각을 정리해 보고자 한다.   즉 참여하는 이해관계자( 금융기관(임원, 현업, 개발자), 수행사, 파트너 등),  구현 대상인 비지니스 프로세스, IT서비스 환경적 요소( SW저작권, 하도급법, 보안 규제 등)가 얼마나 경쟁력이 있는가로 나누어 보고자 한다.   내용적인 측면에서는 필자의 경험인 금융 IT서비스를 중심으로 논의를 진행해 보겠다.  


우선 논의 출발점인 좋은 프로그램, 좋은 SW란 무엇인지부터 시작하는 것이 우선일 거 같다.  


좋은 SW란 무엇인가?   


산출물로서의 SW의 경쟁력을 측정할 수 있는 객관적인 잣대는 쉽게 찾기는 어려운 거 같다. 기준을 찾아보기 위해  고전인 제럴드 와인버그의 저서 "The Psychology of Computer Programming"중의  한 챕터인 "좋은 프로그램이란 무엇인가?"라는 질문으로 돌아가 보고자 한다.   저자에 따르면 좋은 프로그램은 "이 프로그램은 82.7점이다"와 같이 절대적인 척도에 따라 측정하기는 어렵다.  또 상대적인 척도를 사용할 수 있을 것도 같지만, 실제 비교 대상과 기준을 찾기도 쉽지 않다고 한다.  프로그래밍은 개인적 차원의 단순한 인간행위가 아니라,  사회적 차원의 고도로 복잡한 인간행위이기 때문이기도 하다.  또한 통상  IT는 후행 프로세스 중의 하나로  전략, 조직, 환경 등으로부터 영향을 많이 받는다.  따라서 일반적으로 프로그램의 평가에서는 절대적, 상대적으로 평가하기보다는 개발에 관련된 모든 상황에 비추어 그 프로그램을 평가해야 한다고 한다. 종합해 보면 요건에 부합하는지, 납기를 준수하였는지, 비용 효율적인지,  향후 유지보수가 용이한지, 수익성은 어떠한지 등이 좋은 SW의 기준이 될 수 있겠다. 


첫째,  좋은 SW의 첫째 기준은 요건(요구명세)에 부합하는 SW이다.  솔직히 우리가 원하는 것은 고난도의 최신 기술을 사용한 프로그램이 아니라, 요건에 부합하는 프로그램이다.  프로그램이 정상 작동하지 않는 상황에서는 효율성, 비용 등 다른 척도는 전혀 의미가 없다.  나아가 사용자가 한 명인 프로그램과 진정한 SW사이에는 큰 차이가 있다.  사용자가 여러 명이고, 요구사항이 많아지면 정상 작동에 대한 정의도 여러버전이 존재하게 된다.  

국내 SI업계에서는 가장 어려운 고객 중 하나는 대학과 병원이다.  독립적인 의견을 내는 대학교수와 병원의사들을 포함한 여러 이해관계자가 있고 이들을 기획, 통제할 주체가 불분명해서, 요구사항을 충족시키기가 가장 어렵다고 한다.  마찬가지 이유로 기업 내부의 소수 사용자를 전제로 한 SW 대비, 불특정 다수 고객을 상대로 한 B2C 플랫폼 SW가 요건을 맞추기가 더 어려운 이유이기도 하다. 

물론 모든 요구사항이 동일한 우선순위를 갖는 것은 아니다.  필자가 모 외국계 보험사 CIO재직 시절 적체된 요구사항들이 많아서, 왜 개발계획만 세우고 진전이 없는지 살펴본 적이 있다.  한 달에 한번 1~2시간 수작업을 하면 되는데, 요구사항 작성에 8시간 이상이 걸리니 요구사항을 몇 년째 제출하지 못하는 것이 많았다. 복잡한 도메인 지식을 요구하는 보험사 후선 업무는 담당자 아니면 요건정의가 불가능하다. RPA를 통해 현업주도로 개발하는 보다 효과적인 방법을 포함하여, 현업 부서의 요구사항 목록을 주기적으로 재정비하면서,  계정계 시스템이 복잡해지는 것을 관리해 갔다. 국내 회사 대비 IT부족원이 더 존중받기도 하였고,  보다 합리적인 의사결정 과정을 통해 이해당사자간에 합의하기가 더 용이했다고 생각된다.  반면 국내 모 보험사는 모든 요건을 전통적인 계정계  시스템에 무조건 수용하는 경향이 많아서,  차세대 구축 시 10,000본이었던 시스템이 몇 년 내 16,000본으로 늘어나 복잡성을 관리하는 어려움을 겼고 있다고 하는데, 바람직한 현상은 아니라고도 생각된다. 


둘째,  프로젝트에서 가장 중요한 문제 중의 하나는 일정을 맞추는 일이다.  더 좋은 품질의 프로그램을 작성하기 위해 출시를  몇 달 늦출 경우,  해당 SW를 당장 사용하지 못해서 발생하는 비용 대비  완성도 높은 SW를 출시하는 효과를 비교해 봐야 한다. Speed가 중요한 디지털 시대이지만, 일반적으로 프로그램의 납기지연 때문에 발생하는 실제 손실이 항상 그렇게 큰 것은 아니다. 이미 구축경험이 있는 프로젝트라면 모르겠지만, 매번 새로운 디지털 시대의 프로젝트는 정확한 기간을 정의하기 어렵기도 하다.    종종 초기 일정 계획 변경의 어려움, 내부 조직의 KPI 등 정치적인 이유로 완성도가 낮은 SW를 출시하면서,  고객으로 부터 신뢰를 잃거나 또는 수정을 위해 더 많은 비용을 지불하는 경우도 종종 있다. 


셋째, 유지보수의 용이성이 중요한 기준이 된다.  한 번만 실행되고 버려지는 프로그램은 거의 없다.  프로그램은 시간을 견디는 SW 엔지니어링의 산출물이어야 한다. 하지만 처음부터 추후에 변경될 것을 대비하여 작성된 프로그램은 거의 없다. 향후 수정에 대비하여 문서화를 해 놓기도 하지만 항상 불충분하다.  다른 모든 면도 만족시키면서 유지보수성까지 뛰어난 SW를 만들 수는 있지만 치러야 할 시간과 비용이 크다.   향후 수정하기 쉽게  만들려면 프로그램이 느려지거나, 너무 커지거나 시간과 비용이 더 많이 소요되기도 한다.  

재사용성에 초점을 둔 최근의 마이크로서비스 방식의 개발도 유지보수 용이성을 극대화하는 방법이다. (잘 만들어진 마이크로서비스는 재활용이란 용어 대신 재사용이라는 용어가 보다 정확하다.  재활용 쓰레기에서 보듯이 재활용을 위해서는 많은 노력이 든다. ) 하지만 실제로는 무늬만 클라우드 네이티브 방식의 마이크로 서비스를 적용했다고 하지만, 이를  제대로 구현하는 데는 정말 많은 노력과 시간이 소요된다는 점이 종종 간과된다.   


넷째, 중요한 척도 중 하나는 비용효율성인데, 전체 비용 관점에서 비용효율성을 봐야 한다. 일회성인 시스템 개발비만이 아니라 운영비, 유지보수비도 고려해야 한다. 점점 HW가격은 내려가고, 클라우드가 발전함에 따라 개발비를 포함한 인건비 비중이 더 중요한 항목이 되고 있다.  일부 요구명세를 줄이면 비용을 줄일 수 있지만, 사람이 하는 수작업 비용이 늘어나게 될 수도 있다. 

디지털 시대에는 고도화, 업그레이드라는 명목하에  프로그램을 수정하고 변경하는 비용이 더 들기도 한다.  적어도 5년을 내다보는 총 소유비용(Total Cost of Owenership) 관점에서 봐야 한다.  이런 측면에서 발주사 내부 인력의 인건비 (기획, 개발, 운영을 포함한)를 최초 프로젝트 기획부터 비용에 산정하지 않은 경우도 종종 있는데,  전체 비용 관점에서는 이것까지 추가해서 고려해야한다고 생각한다.     


다섯째,  마지막 중요한 척도로 경제적 요소인 수익성이 있다.  많이 팔리고 큰 수익을 내는 소프트웨어가 더 좋은 프로그램이라는 것은 명백하다.  DB, 미들웨어 등 기반 소프트웨어를 만드는 회사나,  패키지 소프트웨어를 만드는 상용 패키지 SW사업자는 판매고를 좋은 SW의 기준으로 본다.   반면에 일반 기업에서 만드는 맞춤 SW는 사용성을 목적으로 하지,  판매를 목적으로 SW를 만드는 경우는 거의 없다.  하지만 클라우드 네이티브 시대에서  마이크로서비스, API 기술의 발전으로 인해, 기업이 만드는 SW의 품질이 높아지고 있다.  나아가 이를 외부에 개방하고,  SaaS 방식으로 판매하는 길 또한 열리고 있다.  SW의 재사용성이 조직을 넘어서서, 확대되는 것은 사회발전을 위해서도 바람직하다고 생각한다.        


이상 다섯 가지 좋은 SW의 기준을 살펴봤는데, 많은 관리자들은 아직도 많은 것을 원하고 있다.  타자에게는 연 타석 홈런을, 투수에게는 모든 이닝에 삼진아웃을 요구하는 초보 야구 감독과 유사하다.  아마 군대 시절 1000원 주면서 담배 한 보루, 치킨 한 마리를 요구했던 메기병장(갑)을 자주 봐서 둔감해졌는지도 모르겠다.   보유한 자원 범위 내에서 최선의 소프트웨어를 만들려면 무언가를 얻는 대신에 다른 무언가를 희생해야 하는, Trade off 가 필요함을 여전히 모른다.  이런 환경에서 불가피하게 중요한 Trade off는 특히  현장의 IT전문가, 실무 개발자 수준에서 암묵적으로 결정되고 있기도 하다.  이해관계자 간의 조정 문제,  복잡한 기술적인 문제, 커뮤니케이션의 어려움으로 중요한 Trade off의 일부만 피상적으로 커뮤니케이션되고 있기도 하다.  


개인적으로 SW 자체는 혁신보다는 진화의 산물이라고 생각한다.  초연결 시대, 디지털 시대에 접어들면서 SW는 살아 움직이는 생물에 가깝다고 보인다.  연결된 SW들과의 호환성 이슈부터, 지속적인 요건 변경까지 포함하여 정말 손이 많이 간다. 물도 주고 주기적으로 가꾸어줘야 정상 작동하고 꽃도 피울 수 있다. 반면 혁신은 SW를 활용해서 얻는 비지니스 Outcome이다.  잘 활용해서 새로운 고객경험을 제공하고, 비지니스 프로세스를 바꾸고, 일하는 방식을 바꾸고 결과적으로 새로운 비지니스 모델을 만들어 갈 수 있도록 한다.  좋은 SW는 잘 만드는 것보다,  잘 진화시키는 것이 더 중요하고, 나아가 비지니스 혁신에 이르도록 활용하는 것에 있다고 생각된다. 


다음 블로그에서는 이어서 선진국 대비 우리는 좋은 SW를 만들고 있는가? 에 대해서 고민해 보고자 한다. 


참고문헌 : 제럴드 와인버그 "프로그래밍 심리학 (The Psychology of Computer Programming)" p49~69

작가의 이전글 을의 Digital Finance 블로그 (1)
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari