기술은 항상 진보하는 방향으로 흐른다
우리는 결국 변화를 받아들이게 된다
기술의 역사를 길게 볼 필요는 없다.
우리가 몸으로 겪어온 변화만 떠올려도 충분하다.
메인프레임에서 분산 시스템으로,
온프렘 환경에서 가상화와 클라우드로,
수동 배포에서 자동화와 CI/CD로.
속도의 차이는 있었지만, 방향이 바뀐 적은 없었다.
기술은 늘 더 유연하고, 더 빠르고, 더 확장 가능한 방향으로 이동해 왔다.
그리고 그 흐름은 한 번도 거꾸로 간 적이 없다.
변화는 선택이 아니라 누적된 결과다
기술 전환은 흔히 이렇게 설명된다.
“우리가 선택했다”
“전략적으로 도입했다”
“아직은 시기상조다”
하지만 실제로는 다르다.
대부분의 기술 변화는 선택의 결과라기보다 누적의 결과다.
요구사항이 늘어나고
변화 속도가 빨라지고
기존 방식으로는 감당이 안 되는 순간이 온다
그때 조직은 선택한다기보다
더 이상 버틸 수 없는 방향에서 밀려난다.
메인프레임에서 자바로,
온프렘에서 클라우드로,
DevOps로의 이동도 이 연장선에 있다.
메인프레임에서 자바로의 전환은 필연이었다.
금융권에서 메인프레임 기반 시스템이 자바 기반 시스템으로 전환되던 시기를 떠올려보면,
그 변화는 결코 매끄럽지 않았다.
안정성에 대한 불신
성능에 대한 우려
운영 복잡도 증가
잦은 초기 장애
그럼에도 불구하고 전환은 멈추지 않았다.
왜냐하면 메인프레임은 더 이상 변화 속도를 감당할 수 없었기 때문이다.
중요한 점은 이것이다.
자바가 완벽해서 전환된 것이 아니라,
메인프레임이 한계를 드러냈기 때문에 전환되었다.
기술 진보는 언제나 기존 기술의 실패 지점에서 가속된다.
DevOps도 같은 경로를 밟고 있다
DevOps에 대한 금융권의 반응은 낯설지 않다.
“통제가 안 된다”
“사고 나면 책임이 불분명하다”
“우리 업종에는 아직 이르다”
이 말들은 과거에 자바를 두고 했던 말과 거의 같다.
클라우드를 두고 지금도 반복되고 있다.
하지만 DevOps가 등장한 이유는 분명하다.
시스템은 더 자주 바뀌고
릴리스 주기는 짧아지고
수동 통제는 점점 병목이 된다
DevOps는 속도를 높이기 위한 선택이 아니라,
복잡해진 시스템을 유지하기 위한 생존 전략에 가깝다.
그래서 DevOps 역시
금융권에서 완전히 배제될 수는 없다.
그럼에도 불구하고, 왜 ‘되돌아간’ 사례가 나올까
이 지점에서 흔히 이런 반박이 등장한다.
“그런데 클라우드 갔다가 온프렘으로 돌아간 사례도 있잖아?”
이 사례는 기술 진보의 반례처럼 보이지만, 실제로는 그렇지 않다.
자세히 들여다보면 대부분 이런 형태다.
전체 시스템 롤백 X
특정 워크로드에 한하여 회수
비용·규제·책임 문제로 재조정
즉, 기술 방향을 포기한 것이 아니라,
조직이 감당 가능한 범위로 속도와 방식을 조정한 것이다.
메인프레임에서 자바로 넘어가던 시절에도
비슷한 조정과 혼합 구조가 존재했다.
그렇다고 해서 자바 전환이 실패로 평가되지는 않는다.
기술은 진보하고, 조직은 적응한다
기술은 항상 한 발 앞서 나간다.
조직은 그 뒤를 따라가며 적응한다.
때로는
멈춘 것처럼 보이고
되돌아간 것처럼 보이며
하이브리드 형태로 머무르기도 한다
하지만 시간이 지나고 나면,
기술의 방향은 다시 분명해진다.
DevOps도 마찬가지다.
금융권에서도 결국 안착하게 될 것이다.
속도는 다를 수 있지만,
방향은 바뀌지 않는다.
결론
기술은 항상 진보하는 방향으로 흐른다.
변화는 선택의 문제가 아니라
결국 받아들이게 되는 현실이다.
되돌아간 것처럼 보이는 사례는
진보가 멈췄다는 증거가 아니라,
조직이 적응하는 과정일 뿐이다.
DevOps 역시 그 흐름 위에 있다.
금융권도 예외는 아니다.
다만 언제나 그렇듯,
조직이 준비된 만큼의 속도로 도달하게 될 것이다.
