SI 현장에서 바라본 ‘소프트웨어 개발의 역사’

SI 산업 가이드북 ⑮

부트캠프를 수강하는 학생들이 제게 묻고는 합니다.

학생: 멘토님. 상속은 왜 받는 거예요? 이렇게 실행해도 되는데 꼭 그렇게 해야 하나요?

나: 음, 그렇긴 하지만 이건 이렇고 저건 저렇고….

상속, 의존성, 단일 책임. 코딩을 배우러 온 학생들에게, 소프트웨어 개발의 영역은 모르는 용어 천지입니다. 왜 하는지도 모르겠습니다. 프론트엔드, 백엔드, 풀스택. 뭘 배워야 할지, 어떻게 해야 할지도 모르겠습니다.

이런 학생들에게 저는 소프트웨어 개발의 변천사를 이야기해줍니다. 큰 맥락을 알면 조금은 눈에 보이니까요. 나머지는 구글이나 챗GPT에 물어보면 됩니다.

그렇게 들려주던 이야기를 정리해 봅니다. 천공카드에 펀칭으로 코딩하던 시절은 건너뜁니다.

한국 소프트웨어 개발 현장의 변화 1980년대: 상업용 코딩의 시작 1980년대 은행의 Host-Terminal 구조

1980년대. 은행으로 가보겠습니다. 직원들 앞에는 모니터와 키보드만 있었습니다. 컴퓨터 본체가 없었죠.

본체는 같은 건물 전산실에 있었습니다. 선을 길게 끌어와서 은행 창구에 모니터를 설치했죠.

컴퓨터가 비싸니 본체 한 대에 여러 대의 모니터, 키보드를 달아서 나눠 쓰는 방식이었습니다.

그 컴퓨터를 영어로는 메인 프레임(main frame), 한글로는 주전산기라 불렀습니다.

은행 프로그램은 메인 컴퓨터에서 실행되었습니다. 이를 “호스트(Host, 주인)”라 불렀습니다. 서버라고 부르지 않았습니다.

모니터, 키보드는 연결선 끝에 있으니 “단말(端末)”이라고 불렀습니다. 영어로는 “터미널(Terminal)”이었죠.

그래서 이 구조를 호스트-터미널(Host-Terminal)이라고 불렀습니다.

물리적으로 연결할 수 있는 케이블 수에는 제한이 있었습니다. 최대 12~32개 정도? 연결 단자 수가 그것밖에 안 되었습니다. 이 숫자가 “동시접속자 수”입니다. 공유기를 달아 이 숫자를 늘렸습니다.

지금이야 랜 케이블 하나로 여러 대의 접속 요청을 처리하지만 이 때엔 그런 기술이 없었습니다. 공유기를 설치하는 것도 나름 어려운 기술이었죠.

호스트 내부의 소프트웨어 하나가 여러 터미널에서 오는 INPUT을 처리했습니다. 개발자는 1인용으로만 코드를 만들었죠. 각 터미널에 맞게 대응해 주는 건 CPU와 실행 프로그램의 몫이었습니다. 멀티태스킹의 초기 형태인데 “시분할 방식”이라고 불렀죠.

예금조회화면 Cobol 예제

상업용 언어로는 Cobol을 썼습니다. 순차형 언어다 보니 화면과 로직을 나눌 수 없었죠. 그 때문에 그냥 print 문으로 화면을 그렸습니다. 그래서 화면 하나에 업무 한 개, 로직 한 개를 연결할 수밖에 없었습니다.

자연스레 개발량을 화면 개수로 측정했습니다. 단위를 “본(本)”이라고 불렀는데, 이건 “페이지”의 일본식 한자 표현입니다. 초창기에는 메인 프레임을 일본에서 수입했거든요.

네트워크가 느렸습니다. 전화선을 이용했죠. 낮이면 전화선이 붐벼서 전송 속도가 느려졌습니다.

오후 6시. 명동지점에서 일 결산이 끝나면 중앙 센터로 데이터를 전송해야 했습니다. 그래야 전체은행의 일 결산이 끝나니까요. 하루치 데이터를 묶은 다음 압축해서 전송했습니다. 이런 묶음처리를 “배치(Batch) 작업”이라고 불렀죠.

“본”, “배치 처리” 같은 용어가 이때 자리를 잡았는데, 아직도 쓰이고 있습니다.

즉, “화면 개수 + 배치 프로그램 수 = 개발량”이었습니다. 거의 정확했죠.

DB는 만들어서 썼습니다. 파일로 저장하는 방식인데 이걸 ISAM DB라고 불렀습니다. Linked List 같은 알고리즘을 원시적으로 구현해야만 했죠. 삼성과 LG 등 회사마다 개발한 게 달랐습니다.

동시 처리를 하다 보니 데이터 중복이 발생하는 경우도 많았죠. 알고리즘을 잘 설계해야 했습니다.

이때는 “소프트웨어를 설치한다”는 개념이 없었습니다. 메인 프레임이 움직이도록 하드웨어를 “프로그래밍” 한다는 개념이었죠. 그래서 개발자라기 보다는 “프로그래머”라고 불렀습니다.

삼성전자 같은 기업이 “메인 프레임”을 고객 요구에 맞춰 프로그래밍한 후 납품을 했습니다. 개발 가격은 장비 가격에 합산해서 청구했죠. 제법 큰 돈이 되었습니다. 1990년대 후반까지도 이랬습니다.

1990년대: PC 프로그래밍의 시대 1990년대 클라이언트, 서버 구조 Time traveler 유튜브 참조>

초기 버전 컴퓨터인 XT, AT는 건너뜁시다. 1990년대 후반, 80386 PC와 함께 윈도우가 보급됩니다.

PC 성능도 좋았고, 멀티태스킹도 가능했죠. 기업들은 성능이 좋아진 PC를 업무 처리에 쓰고 싶어 합니다. 서버 비용을 줄이고 싶어서죠. 당시 서버용은 하드디스크, CPU, 메모리까지 모두 비쌌습니다.

기술 구조가 변합니다. PC에서 중앙센터의 데이터를 불러와 처리한 후 다시 중앙센터에 저장하는 방식으로 말이죠. “클라이언트-서버” 구조라고 합니다.

중앙센터가 데이터를 나누어 주므로 “서버”, PC 는 데이터를 받아 가므로 “클라이언트”라고 불렀습니다.

처음에는 SI 회사들이 서버, PC, 프로그램을 함께 묶어 납품했습니다. 통합 견적이었죠.

하지만 국산 PC가 등장하며 가격이 저렴해지자 상황이 달라집니다. 기업들이 PC를 따로 샀거든요. 옛날 PC를 그대로 쓰기도 하죠. SI 회사들은 PC를 빼고 납품하기 시작합니다.

그래서 개발 비용을 장비 가격에 포함시킬 수 없게 됩니다. 개발비를 따로 청구해야 했죠. 그런데 계산 기준이 SI 회사마다 케바케입니다. 갑자기 정부가 난감해집니다. 통일된 기준과 근거가 있어야 하거든요. 1997년 “소프트웨어 대가기준”을 만들게 됩니다. 귀찮으니 일반 기업도 따라하게 되죠.

이 기준에 따라 만든 소프트웨어는 삼성, LG, 삼보 등 다양한 PC에서 똑같이 실행되어야 하니 호환성이 중요해집니다. 서버에서 개발할 것도 많아집니다. 버전 관리, 데이터 관리, 백업 관리 등이 추가되자 ‘단순 화면 수’ 말고도 개발량 산정 기준이 필요해지죠.

당시 현장 관리자가 대충 묻습니다. “얼마나 걸릴 것 같아요?”

개발자들이 어림잡아 대답합니다. “3개월이면….”

“넵, 3개월.” 이렇게 개발 기간 산정 방식이 굳어집니다.

이때는 대부분의 기능을 PC에서 처리하면 Fat(Thick) Client, 서버가 처리하면 Thin Client라 불렀습니다. PC, 서버가 기능을 나누어서 담당하는 구조도 있었죠. 상황은 케바케였습니다.

프로그램이 PC와 서버로 나뉘어지니 프로젝트 관리도 복잡해집니다. 이제는 메인 프로그램 하나만 관리하면 안 되었거든요. PC, 서버를 따로 개발한 후 합쳐야 했습니다. “통합 테스트”가 등장하죠.

간혹 옛날 방식으로 프로젝트를 관리하기도 했습니다. 그러면 일정 관리와 테스트가 다 달라져서 문제가 되었습니다. 선 반영 후 수습으로 진행했죠.

2000년대: 웹 개발의 등장 2000년대 웹 개발의 시대

클라이언트 프로그램은 단점이 있습니다. PC가 버벅대면 데이터 전송도 늦어진다는 겁니다. “윈도우 프로그램”이었거든요.

경마장에선 큰 일이었습니다. 경기 시작 전마다 마권 창구가 미어 터졌거든요. PC가 버벅댄다고 늦어지기라도 하면 난리가 났습니다. 돈이 걸린 일이니까요. 그래서 “미들웨어”가 등장합니다. PC는 가볍게 화면만 보여주고, 무거운 업무 기능은 “서버”가 담당했죠. 이를 연결하는 걸 “미들웨어”라 불렀습니다.

시간이 지나면서 미들웨어가 웹페이지를 지원합니다. Weblogic 같은 프로그램이 나옵니다. 이런 프로그램들을 “웹 어플리케이션 서버” * 라 부르게 되죠.

*웹 어플리케이션 서버(WAS, Web Application Server): 서버용 코드를 실행시키는 프로그램인데, 웹 전용으로 쓰이면서 붙여진 말입니다. 일반 프로그램은 Application Server라고 부릅니다.

최초의 웹페이지는 “워드 문서”를 대체하기 위해 나왔습니다. 그래서 저장된 페이지만 보여줄 수 있었죠. 동적 표현은 불가능했습니다. 하지만 JavaScript가 나오면서 간단한 동적 표현이 가능해졌고, 웹 서버가 나오면서 커다란 데이터를 출력할 수 있게 되었습니다.

초기에는 웹 화면이 간단하다 보니 로직 속에 뭉쳐서 한 개발자가 만들었습니다. 그래서 그냥 “웹 개발자”라고 불렀습니다. 하지만 단점이 있었죠. 메인 로직과 화면을 잘 분리해서 만들어야 했다는 겁니다.

화면이 100개를 넘어가면 서버 기능은 300~400개를 넘어갑니다. 양이 너무 많아 관리가 안 되었죠. 또, 함께 일하는 개발자마다 코딩 스타일도 달랐습니다. 소스코드가 중구난방이었죠.

MVC 패턴이 생기고 Java Spring이 등장합니다. HTML, CSS가 진화합니다. 그에 맞춰 웹 브라우저가 발전합니다. jQuery가 나타납니다. Ajax가 등장하고, Node.js가 발표됩니다.

이제 웹 화면은 완전히 동적으로 예쁘게 만들 수 있게 됩니다. 마치 윈도우 프로그램처럼요.

코딩이 아주 복잡해집니다. “프론트엔드”라는 분야가 등장하죠.

메인 로직 개발은 “백엔드”로 불리게 됩니다. 처음에는 “백엔드 개발자”가 로직 개발만 했지만, 지금은 DB 관리를 하기도 합니다.

테스트, 코드 관리 체계도 복잡해집니다. 공용 라이브러리도 중구난방이 되죠. 수십 명의 코드를 모아 하나의 바이너리로 만드는 것 자체가 복잡해지죠.

Gradle의 조상 격인 Ant가 등장합니다. 덕분에 IDE도 복잡해집니다. Eclipse(Java IDE)가 메모리를 1GB씩 먹었죠. 컴파일을 돌리는 데만 1시간이 넘게 걸렸습니다. 테스트 한 번 하는 게 일이었죠.

“프로젝트 관리”는 산으로 갑니다. 일정 관리를 너머 소스 관리, 통합빌드 관리까지 해야 했죠. 옛날 기술들과 달라서 위험 관리, 일정 관리, 이슈 관리 방법도 달라져야 했습니다. 하지만, 어떻게 해야 할지 몰랐죠.

한편 작업량과 일정 예측도 시급했습니다. 그래야 예산을 잡고 프로젝트를 시작할 수 있으니까요.

미들웨어 등장 후 화면 수 산정 방식은 버려졌습니다. 기능 점수(Function Point) 방식이 등장하죠. 우당탕탕 잘 되진 않았습니다. 이것도 딱 나누기 어려운 게 많았거든요.

프론트엔드, 백엔드로 나눠지면서 개발량 산정은 저세상 복잡도가 됩니다. 계산 방식도 어려울뿐더러 산정했다 하더라도 실제와 전혀 맞지 않았죠. 대부분 다시 M/M(맨먼스) * 산정방식으로 돌아옵니다.

*M/M(맨먼스): Man per Month의 약자로, 한 달에 몇 명의 개발자가 투입되어 일해야 하는가를 기준으로 비용을 산정하는 방식입니다. 개발자 한 명의 하루 작업량을 예측해서 데이터를 뽑습니다.

2010년대: 네트워크의 시대 2010년대 인터넷의 시대

PC, 유선 인터넷의 보급과 함께 무선 통신이 발전합니다. 그리고 2010년, 한국에도 아이폰이 출시됩니다.

새로운 아이디어, 새로운 비즈니스가 우후죽순 쏟아집니다. Node.js 같은 경량 플랫폼이 등장하죠. 화면 개발에 빠르게 대응할 수 있게 됩니다.

스마트폰 화면은 작습니다. 웹처럼 넓게 펼쳐놓을 수 없죠. 기능을 보여줬다 감췄다 해야 합니다. UX가 중요해졌죠.

화면 조작이 복잡해지자 코드도 복잡해집니다 프론트엔드가 급격하게 발전하죠. React, TypeScript 같은 프론트엔드 툴들이 쏟아집니다. BootStrap, 머티리얼 등 디자인 툴까지 나오죠. 개발은 어려워진 듯 쉬워집니다.

반면 기술 구조는 복잡해서 개발 관리, 일정 관리 난이도가 하늘 높은 줄 모르고 치솟습니다. 특히 UX 설계는 종료 기한을 만들기 어렵습니다. 이건 유저 반응을 보면서 수정해야 완성도가 높아지거든요. 아웃소싱으로는 한계가 있습니다.

인터넷이 보급되면서 API를 이용한 매쉬업 * 도 활발해집니다. 이젠 다른 회사 기능을 섞어 내 제품을 만들 수도 있게 되죠. 그러다보니 프론트엔드, 백엔드로만 영역을 나눌 수 없어집니다. 비즈니스 특성에 따라 서버 종류와 구현 방식이 천차만별로 달라지거든요. 그래서 이런 리스크 관리를 하려면 다양한 개발 경험이 반드시 필요했습니다.

*매쉬업(Mash up): 하나 이상의 외부 컨텐츠를 모아 만든 사이트입니다. 예를 들어 기상청 API와 네이버 지도 API를 이용하면 “지도로 보는 기상예보”사이트를 만들 수 있습니다.

과학과 공학, 아키텍처와 속도 더 깊은 이해를 위해 ‘컴퓨터 과학’과 ‘컴퓨터 공학’, 그리고 ‘아키텍처’의 관점에서 발전 역사를 다시 짚어보겠습니다. 생각해 볼 시사점도 함께 정리합니다.

OS의 진화와 Java의 등장 Unix의 역사 위키피디아 >

초기 컴퓨터는 OS와 프로그래밍 언어가 일체형이었습니다. 전원을 켜면 까만 화면에 커서만 깜빡였죠. 여기다 한 줄 한 줄 코딩을 했습니다. 프로그래밍 언어가 “Fortran”이면 공학용, “Cobol”이면 상업용 컴퓨터라고 불렀습니다.

이때는 컴퓨터를 만드는 게 “과학”이었습니다. 약간 가내 수공업 느낌이었죠. 주문 요구사항에 따라 컴퓨터도 조금씩 달랐습니다. 그러다 보니 컴퓨터 구조도 폐쇄적이었죠. 자체 규격을 쓰다 보니 프린터 등이 호환되지 않았습니다.

Unix가 나오면서 OS와 프로그래밍 언어가 분리됩니다. 이제 컴퓨터를 켜면 파일 복사, 삭제는 할 수 있었지만, 코딩할 수는 없었죠. C/C++, Fortran 등을 따로 설치해야 했습니다. 그걸 실행해야 코딩할 수 있었죠. 보통 텍스트 파일로 길게 만든 후 기계어로 컨버팅을 했는데, 이 과정을 “컴파일”이라고 불렀습니다.

Unix가 “메인 프레임”을 대체하게 된 이유는 Multi User, Multi Processing이 가능했기 때문입니다.

여러 대의 PC가 동시에 접속해도 동시 처리가 가능했었죠. 다른 기종의 접속도 허용하다 보니 설계나 규격이 오픈됩니다. “개방형 시스템”이라고 불렀죠.

DBMS도 설치할 수 있게 됩니다. 춘추전국시대가 열리죠. 여러 대의 PC 요청을 처리하다 보니, 무결성, 일관성, 정규화 등이 중요해집니다. 설계 원칙과 기법들이 정리되죠. 이때 접속 요청을 구분하는 용어가 필요해집니다. “트랜잭션”이라는 용어가 널리 퍼집니다.

“컴퓨터 공학”의 시대였습니다. 표준화, 규격화, 호환성 등이 중요했거든요.

HP, 후지쯔, SUN 등이 성능 경쟁을 합니다. 기업들은 다시 자사 규격을 쓰면서 Unix 커널까지 바꿉니다. 같은 C 프로그램이라고 하더라도 호환되지 않을 정도였죠.

2,000년대 초, 이 문제가 심각해집니다. 10억 들여 만들어 놓은 프로그램이 서버 기종을 바꾸면 동작하지 않았거든요. 특정 하드웨어 회사에 종속성이 생겨 버린 거죠.

이 문제를 해결한 게 Java였습니다. 일종의 소프트웨어 머신을 만들어 버린 겁니다. 기종마다 달라지는 건 Java 팀이 해결하고, 일반 개발자는 Java에만 맞추어 코드를 만들었습니다. 그러면 하드웨어가 달라져도 잘 작동할 수 있었죠.

동시에 Unix를 작게 만들고자 하는 움직임도 있었습니다. 오랜 경쟁 끝에 Linux가 시장을 제패합니다. 클라우드 덕분이었죠. AWS가 Linux를 하나의 애플리케이션으로 만들어 버립니다. 이를 “인스턴스”라고 불렀죠. 일종의 소프트웨어 OS가 되어버린 겁니다.

JavaScript(Node.js), Go, Python 등 언어가 경량화되기 시작합니다. Java처럼 다양한 머신을 지원할 필요가 없었거든요. 지금은 Linux에서만 잘 돌아도 충분하니까요.

메인 프레임(폐쇄형) → Unix(개방형) → 소프트웨어 머신(Java VM) → 소프트웨어 OS(인스턴스, Linux) → 여러 개의 OS(쿠버네티스, Docker, Linux)

하드웨어는 이렇게 소프트웨어로 변해버립니다. 그에 따라 기업용 애플리케이션을 만드는 방식도 크게 달라지죠.

아키텍처의 중요성이 높아지다 2000년대 이전

이때는 “시스템 아키텍처”라는 개념이 없었습니다. 그 정도로 시스템 구성이 복잡하지 않았기 때문입니다. “컴퓨터 설계도”나 “하드웨어 설계도” 정도의 개념밖에 없었죠. 실행프로그램이 한 대의 호스트에서만 돌아가면 되었으니까요.

클라이언트, 서버라고 해봐야 구성품은 “PC 프로그램, DB” 두 개가 전부였습니다. 이때는 “빠른 개발”, “코드 재활용” 등이 중요했습니다. RAD * , CBD ** 같은 용어가 뜹니다.

*RAD: Rapid Application Development. 여러 도구를 이용해 코딩 속도를 높이는 방법입니다. 주로 코딩 편의를 높이는 도구들이 IDE에 포함되어 보급됩니다.

**CBD: Component Based Development. 기능을 컴포넌트(모듈)화 시키고, 필요에 따라 조립해서 소프트웨어를 개발하는 방식입니다.

2000년대, 웹 개발의 시대

웹 서버가 등장하자 비즈니스가 폭발적으로 성장합니다. 많은 회사가 웹으로 뭔가를 해보고자 했죠. 비즈니스 복잡도가 높아지며 생기는 문제는 “미들웨어”에서 해결하고자 합니다. * 복잡한 설계철학과 추상화가 중요해집니다. “미들웨어” 자체의 기능도 커지고 무거워집니다.

*Java 플랫폼도 미들웨어에 해당합니다. Java Spring은 웹, J2EE는 서버 개발에 특화된 제품입니다.

기능을 어떻게 그룹화하고 어떻게 배치할 것인가 하는 문제가 중요해집니다. 잘 정리해 놓아야 기능을 추가, 삭제하기 쉽거든요. SOA * 같은 개념이 나옵니다. 메시지 규격도 XML로 구조화시키죠.

*SOA: Service Oriented Architecture. 단순한 라이브러리 개념을 하던 기능 모듈이 호출 가능한 서비스가 됩니다. 서비스를 호출하기 위한 인터페이스를 분리함으로써, 변화하는 비즈니스 요구에 쉽게 대응하려는 설계 패턴입니다.

2,000년대 은행의 SOA 설계도 IJETAE >

Java는 많은 변화를 겪습니다. 온갖 걸 다 지원하려고 하거든요. Java Spring(웹 개발), J2EE(서버 애플리케이션), Java ME 등으로 분화됩니다. 그러다 어느 순간부터 복잡한 예약어와 규칙들로 감당 불가능한 언어가 됩니다. 배우기 쉽게 시작된 언어가 오히려 배우기 어려워지게 되었죠.

2010년대, 네트워크의 시대

여러 대의 서버가 거대한 하나의 시스템을 구성하게 됩니다. 서버가 많아지고 소프트웨어 구성도까지 복잡해지죠. “미들웨어 고도화”로는 한계에 부닥칩니다. MSA * 같은 개념이 등장하죠.

일(=단위 시스템, 서비스 등)을 잘게 쪼개어 개발 및 관리의 편의성을 높이자고 합니다. 좀 더 큰 조립식 개발 구조를 만들죠.

*MSA : Micro Service Architecture. 서비스를 작게 쪼갠 다음 독립된 도메인으로 만들어서 큰 서비스를 만들자는 방식입니다.

Java가 무겁고 복잡해지자 실리콘밸리에서부터 Node.js 같은 경량 플랫폼으로 갈아탑니다. 복잡성을 미들웨어에서 해결하지 않고, “아키텍처”를 통해 해결하고자 하죠.

단위 기능은 CRUD 같은 단순 처리에 집중합니다. 연결은 API를 활용하고 통신 메시지도 단순화시키죠. REST API와 JSON이 거의 제패합니다.

이 흐름을 부채질한 건 AWS였습니다. 클릭 한 번으로 Linux 서버를 만들 수 있게 되었거든요. 이제는 서비스 단위가 아니라 시스템 단위로 부수고 만들 수 있게 됩니다. EC2, S3, Auto Scaleout 같은 기능들이 추가되자 “복잡한 아키텍처” 만들기도 쉬워집니다. 물론 옛날과 비교해서 말이죠.

서버, 클라이언트 관점의 다양한 스택들 biosistemika >

플랫폼이 경량화되고 클라우드가 일반화되자 개발자들은 소프트웨어 구성품을 묶어서 다루기 시작합니다. “스택”이라고 불렀죠.

“LAMP 스택”이 특히 인기를 끕니다.

Linux + Apache + MySQL/MongoDB + PHP/Python/Perl의 줄임말로, OS, 웹 서버, DB, 프로그래밍 언어를 함께 패키징한 겁니다.

개념이 생긴 지는 조금 되었는데, 인기를 끌게 된 건 클라우드 때문입니다. AWS에서 인스턴스를 만들면 기본으로 설치되어 있었거든요. CentOS가 “패키지 관리”를 온라인으로 하면서 금방 사라지긴 했지만요.

“기술 스택”이라는 개념이 보편화됩니다. “풀스택 개발자”라는 호칭도 등장하죠.

“스택”을 쓰면 장단점이 있습니다. 조금만 공부해도 적절한 완성도를 만들어낼 수 있죠. 대신 고급 아키텍처를 만들긴 어렵습니다. 어차피 다 분해해야 하거든요.

SI 현장은 어려워집니다.

기업에는 여러 가지 아키텍처가 섞여 있으니까요. 분해해서 써야 하는 경우가 많습니다. 그런데 그런 “아키텍트”를 구하기 어렵습니다. 새로운 걸 가르치는 곳조차 없으니 알아서 익혀야 하죠.

“프로젝트 관리”는 점점 더 미궁 속으로 빠져듭니다. 옛날 방식은 안 통하고 새로운 방식을 배울 곳도 없습니다. 그냥 요령껏 알아서 잘하는 회사만 살아남습니다.

기술 변화 속도는 더 빨라질까 신기술이 빠르게 탄생해도 산업 보급 속도는 느립니다.

클라이언트-서버 환경이 웹 개발로 넘어오는 데 10년 걸렸죠. 웹 개발에서 네트워크의 시대로 넘어가는 데도 10년 걸렸습니다. 대중화 끝물 시점 기준입니다.

기술은 끊임없이 변하는데, 산업 변화는 왜 이렇게 느릴까요?

산업 변화의 주도 세력은 크게 두 부류로 구분됩니다. 일반기업과 스타트업이죠.

일반 기업은 전통적인 방식으로 기술을 받아들입니다. 매출을 높일 수 있거나 비용을 줄일 수 있어야 하죠. 두 가지 중 하나가 보장되어야 기술에 투자를 합니다.

스타트업은 가볍고 빠르게 기술을 받아들입니다. 괜찮겠다 싶으면 만들어 보죠. 투자도 가능성에 합니다. 맨땅이기 때문에 신경 써야할 옛날 시스템도 없습니다. 새로 시작할 수 있죠.

이처럼 신기술은 스타트업이 효과를 입증하면 일반 기업이 사서 씁니다. 사회적 변화 과정이 오래 걸리죠.

그래서 큰 기업들은 가능하면 프로젝트 규모를 키웁니다. 한 번 만들기 어려우니, 만들 때 크게 만드는 거죠. 복잡도는 높고, 요구사항은 많고, 오래 써야 하니, 프로젝트 난이도는 올라갑니다. 관리 위험성도 커지죠. 100% 한 군데 이상 펑크가 납니다.

기술은 이런 위험을 해결하고자 진화합니다. 복잡도가 높아질수록 변화의 속도는 더 빨라지죠. 빨리 해결할수록 돈을 더 많이 벌 수 있으니까요.

기술은 얼마나 더 복잡해질까? R&D는 논외로 하고 상용 기술에 한해 이야기해 봅니다.

“기술이 얼마나 더 복잡해질까요?”

인스타그램처럼 B2C 분야에서 기술 진화는 “사람 수준”까지 이어져야 합니다. 그래야 돈을 벌 수 있거든요. 사람들이 자연스럽게 지갑을 꺼내는 수준까지 진화하게 됩니다.

웹 개발에서 네트워크로, 서버 한 대가 여러 대로, 구조가 끊임없이 복잡해진 것도 사람처럼 보이기 위해서입니다. 인터넷 쇼핑몰의 복잡한 추천기능은 사실 판매원을 대신하는 겁니다. 더 자연스럽고 취향에 맞게 보여줘 신용카드를 꺼내게 만드는 거죠.

앞으로 이런 기술들은 얼마나 복잡해질까요? 아마 한참 더 복잡해질 겁니다.

“은행” 같은 B2B 분야에선 어떨까요?

B2B 분야의 기술 진화는 “비즈니스 가치사슬을 잘 유지하는 수준”까지 일어납니다.

말이 좀 어렵죠? 쉽게 말하면, 그 기업이 그 산업 속에서 담당하는 역할까지만 진화합니다.

B2B 분야, 특히 사회 인프라는 부품처럼 맞물려 있습니다. 크게 한 번 투자해서 가늘고 오래 사업을 지속하는 구조죠. 서로 구역을 침범하지 않는 묵시적 룰이 있습니다. 이걸 어기면 전쟁이죠.

예를 들어 국민은행과 기업은행은 주력 포인트가 다릅니다. 기업은행은 중소기업 지원을 위해 설립된 은행이라 기업 대출을 잘 해줘야 하거든요. 반면 국민은행은 전세 대금 같은 걸 잘해줘야 합니다.

그리고 은행 앱에는 네이버처럼 배너 광고를 붙이진 않습니다. 은행 사업의 본질이 아니거든요.

일반인용 AI 는 기업에선 큰 도움이 되지 않습니다. 기업 간 특수관계를 학습시키기 곤란하거든요. 색다른 고민이 필요하게 되죠.

B2B 분야에선 비즈니스 흐름이 길어지거나 복잡해지기 어렵습니다. 복잡성이 높아질수록 비용이 커지는데, 인프라형 사업에선 소비자 가격을 높이기 힘들잖아요.

그래서 복잡해지다 임계점을 넘어서면 다시 단순해지는 현상을 반복합니다. 고급 기능을 저렴하게 제공해야 하는 비즈니스 환경인 거죠.

이런 현상은 기술 발전과 아키텍처의 적절성을 이해하는 중요한 시사점을 줍니다. 산업 분야마다 비즈니스 환경이 다르다는 뜻이죠.

더욱 중요해지는 프로젝트 관리 SI 현장은 여전히 복잡합니다. 기술 이슈는 그나마 쉬운 주제이죠. AI의 활용성이 많이 좋아졌거든요.

문제는 프로젝트 관리입니다. “프로젝트 관리”란 기술적, 비기술적 위험 요소를 식별해 내고, 위험 요소를 적절하게 제거해서, 원하는 기간 내에 목표 결과물을 얻어내는 방법론을 말합니다.

프로젝트를 하다 보면 사람마다 이해 수준이 다르고 처리 역량도 달라 반드시 갈등이 생기거든요.

이걸 해소하려면 사람, 서버, 기술 자원 등을 잘 통제해야 합니다. 오케스트라의 지휘자와 같죠. 어렵습니다.

“프로젝트 관리” 기술은 “프로젝트 성공률”로 입증됩니다. SI 기업을 찾은 고객이 일을 맡길 수 있는 지표가 되죠.

그런데 이토록 중요한 프로젝트 관리 노하우는 성장하지 못했습니다. 옛날 것이 잘 작동하지 않고, 새로운 기술은 잘 모르니까요. 가르치기도 배우기도 어려운 상황이죠. 애자일이 잘 나갔지만, 그게 전부는 아닙니다.

앞으론 프로젝트 성공률이 높고 고객평이 좋은 회사가 더욱 돋보일 겁니다. 프로젝트 관리 노하우는 그 회사를 차별화시키는 중요한 요소가 될 거고요. SI 기업이 그러려니 하고 넘길 수 있는 건 아니죠.

그래서 다음엔 SI 기업의 생존과 이어질 중요한 포인트인 “리스크 관리”와 “자원 관리”에 대해 좀 더 자세히 알아보겠습니다.