검색 - IT세상을 바꾸는 힘 지디넷코리아

ZDNet 검색 페이지

'나희동'통합검색 결과 입니다. (2건)

태그
기간
- 3개월
- 1년
- 1년 이전

재검색

[크리스의 SW아키텍트⑰] 대전센터 화재...아키텍처 기본 원칙 무너진 것 보여줘

어제 참담한 소식을 들었다. 국가정보자원관리원(국정자원) 화재 사태 수습을 맡았던 주무 부처 공무원이 우리 곁을 떠났다는 이야기다. 기술인으로서, 또 한 명의 동료로서, 그가 마지막까지 느꼈을 막막함과 압박감을 생각하니 여러 면에서 안타까운 생각이 들었다. 지난 주 대구센터 화재는, 사실 그 자체만으로는 국가 시스템 전체를 마비시킬 만한 대형 사고가 아닐 수도 있었다. 하지만 이 사건은 우리 디지털 정부의 근본적인 취약성을 수면 위로 드러냈다. 바로 '이중화(Redundancy)의 부재' 라는, 시스템 아키텍처의 가장 기본 원칙이 무너져 있었다는 사실이다. 언론 보도를 통해 우리가 알게 된 사실은 더욱 충격적이다. 국정자원은 이미 시스템 장애에 대비하기 위한 'Active-Active' 방식의 재해복구(DR) 시스템 구축을 공언했지만, 정작 내년도 관련 예산은 24억 원 규모의 시범사업비에 그쳤다고 한다. 심지어 행정안전부는 작년 4월, 시범사업이 우선이라는 이유로 각 부처에 '1·2등급 재해복구시스템 구축 투자 금지' 지침까지 내렸다고 한다. “잘못된 방향으로 투자해 비용이 발생하는 것보다 시범 사업을 통해 모델을 확정한 이후 투자하는 것이 좋겠다”는 것이 공식적인 입장이었다. 전면적인 이중화에 수천억 원이 넘는 비용이 든다는 현실 앞에서, 우리는 결국 '알면서도 미뤄둔 위험' 을 선택한 셈이다. 이런 총체적인 상황 앞에서, 과연 한두 명의 실무 책임자에게 모든 짐을 지우는 것이 온당한 일일까? 필자는 이번 비극의 가장 깊은 뿌리가, 우리 모두가 오랫동안 외면해 온 '소프트웨어 아키텍처의 실종'에 있다고 생각한다. 시스템 전체 설계도를 아는 사람이 없는 상황에서, 예산 삭감과 정책적 제약이라는 현실의 벽에 부딪히며 동시다발적으로 터져 나오는 문제들을 홀로 감당해야 했던 그 막막함은 기술을 아는 사람이라면 누구나 그 무게를 짐작할 수 있을 것이다. 필자는 지난 35년간 이 땅에서 소프트웨어 개발자로, 또 아키텍트로 살아왔다. 2000년대 초반, 동료들과 밤을 새워가며 전자정부 프레임워크와 '마르미(MARMI)' 방법론을 만들며 컴포넌트 기반 개발의 씨앗을 뿌렸고, '소프트웨어 아키텍트'라는 직업의 개념조차 생소했던 시절에 포럼을 만들어 그 중요성을 외치던 기억이 생생하다. 그러다 10여 년 전, 국내 해운SW를 글로벌 솔루션으로 만들겠다는 꿈을 안고 해외 시장에 뛰어들었다 최근 컨설팅 회사 대표로 돌아왔다. 돌아와서 마주한 우리 현실은, 마치 30년 전으로 되돌아간 듯한 깊은 당혹감이었다. 필자가 떠나기 전 동료들과 그토록 열정을 쏟았던 '소프트웨어 아키텍처'라는 개념은, 어느새 응용 아키텍처나 기술 아키텍처 같은 좁은 영역으로 축소돼 있었다. 사람들은 시스템 전체의 뼈대와 철학을 논하기보다, 당장의 요구사항이 구현되었는지만을 확인하는 데 급급해 보였다. 행안부 주도로 야심 차게 추진했던 'EA(Enterprise Architecture)'는 현행화되지 못한 채 장롱 속 산출물로 전락했고, 대기업 참여 제한으로 어느 한 업체도 시스템 전체의 품질을 끝까지 책임지기 어려운 구조가 됐다. 연이은 보안 사고에 대한 대책으로 도입된 망 분리는, 역설적으로 외부의 좋은 기술로부터 우리를 고립시키고 G-Cloud라는 복잡한 기술 섬을 만들었다. 이러한 '보여주기식' 관리는 결국 아키텍처의 총체적 부실을 낳는다. 마케팅적으로 그럴듯한 키워드 중심으로 시스템을 관리하다 보니, 정작 시스템의 혈관과도 같은 근본 구조는 곪아 터지고 있었던 것이다. 지금도 상황이 다르지 않다. 모두가 AI라는 키워드에만 매몰돼 막대한 비용을 쏟아붓고 있지만, 정작 그 AI가 제대로 작동하기 위해 필요한 아키텍처 개선, 즉 낡은 기술 부채를 청산하고 데이터의 맥락을 이해하는 새로운 계층(Contextual Layer)을 설계하는 본질적인 노력에는 누구도 관심을 두지 않는다. 이런 위태로운 토대 위에서 어떻게 시스템의 신뢰를 쌓아갈 수 있을까? 얼마 전 아제르바이잔 공무원들을 초청해 한국의 IT 관제 시스템을 소개해 준 적이 있다. 그때 그들이 가장 깊은 인상을 받은 건 놀랍게도 기술 그 자체가 아니었다. 서울의 고궁과 최첨단 IT 시스템이 함께 공존하는 모습에서 한국이라는 나라의 저력을 느꼈다고 했다. 그 말을 들으며 필자는 생각했습다. 우리는 왜 레거시(Legacy)를 청산의 대상으로만 여기는지, 낡았지만 여전히 작동하는 기존 시스템과 새로운 기술이 조화롭게 공존하는 전체 아키텍처를, 그리고 그것을 사람들에게 설명하며 신뢰를 얻어내는 제대로 된 설계를, 우리는 정말 이걸 할 수 없는 걸까? . 한 동료의 안타까운 선택 앞에서, 우리는 더 이상 이 문제를 외면해서는 안된다. 지금처럼 낡은 구조 위에 새로운 기술만 덧대는 식의 위태로운 공사를 계속하다가는, 언젠가 이보다 훨씬 더 큰 사회적 재난과 마주하게 될 것이라는 불길한 예감이 든다. 이제는 멈춰 서서, 우리가 발 딛고 있는 시스템의 기초부터 다시 살펴봐야 할 때다. 다음 편에서는 미중 기술 패권 경쟁과 같은 지정학적 변화가 만들어내는 '다극화 세계' 속에서 SW 아키텍트가 어떤 새로운 역할과 책임을 마주하는지 그 거시적인 도전을 다뤄보려 한다. ◆ 나희동 크리스커퍼니 대표는... -정보관리기술사 (54회), SW아키텍트 (CPSA), 수석감리원 -전남대학교 산업공학과, 서울과학기술대학교 컴퓨터공학 석사 -CMU SEEK 1기 MSE, UTD SW MBA 수료 -전/투이컨설팅 SW아키텍처 담당 이사, 마르미III 개발참여 -전/싸이버로지텍 기술연구소 및 플랫폼사업본부 상무 -전/동양시스템즈 솔루션사업본부 본부장

2025.10.04 10:59나희동

[크리스의 SW아키텍트③] AI혁신으로 복잡도 증가...레거시 시스템 'SOS'

지난 1편과 2편에서 대형 정보기술(IT) 서비스 장애가 시스템 복잡성과 보안 관리 부재에서 비롯되며 결국 보안은 아키텍처 문제임을 설명했다. 다음 금융 위기는 잘못된 거래가 아니라, 낡은 SW아키텍처 때문에 올 것이라고 전문가들은 경고하고 있다. 인공지능(AI) 혁신을 발생하는 복잡도를 레거시 시스템이 감당하지 못하는 것이 원인이 될 것이라는 전망이다. 실제로 AI를 도입한 기업 중 93% 기업이 AI도입 이후 아키텍처 불일치(architectural misalignment), 즉 모호한 아키텍처로 기술부채가 증가하는 문제로 부정적인 비즈니스 문제를 경험했고, 이들 중 63%는 보안 위험 증가와 프로젝트 지연을 겪었다. 업계에서는 'AI유발 기술부채(AI-induced tech debt)라는 용어가 등장할 정도다. 이런 문제는 두 가지 원인으로 정리된다. 첫째, AI로 새로운 혁신 기능을 적용할 때 시스템 복잡성이 급증한다는 점이다. AI 기반 추천, 챗봇, 자동화 등 혁신 기능을 시스템에 통합하면, 기존 시스템에 비해 데이터 흐름, 연산량, 서비스 간 통신이 크게 늘어난다. AI 모델이 요구하는 대용량 데이터, 고성능 컴퓨팅 자원, 실시간 처리 등 새로운 인프라 요구사항도 생겨난다. 특히 대형 언어 모델이나 머신러닝 기능을 기존 단일구조 시스템에 얹으면 전체 시스템 확장에 비효율이 발생한다. 설사 마이크로서비스 구조로 분리해도 서비스 간 호출이 급증해 관리·운영 복잡성이 커지며, 이는 시스템 전체 관찰 가능성 저하, 장애 원인 파악 어려움, 보안 취약점 증가 등 아키텍처적 위험을 가중시킨다. 둘째, AI로 코드를 생성하거나 자동화할 때도 구조 복잡성이 증가한다. AI코드 생성 도구가 보편화되면서 개발 속도는 빨라지지만, AI가 생성한 코드가 중복·비효율·일관성 부족 문제를 일으킬 수 있다. 이로 인해 코드 품질 관리, 리팩토링(Refactoring), 모듈화 등 기존 소프트웨어 공학 원칙이 약화되곤 한다. AI가 생성한 코드가 시스템 전반에 무분별하게 통합되면 전체 아키텍처 구조 일관성이 깨지고, 장기적으로 관리·운영이 어려워질 수 있다. 이러한 AI로 촉발된 아키텍처 복잡성 때문에, MSA를 도입해야 하는 기업이나 이미 MSA를 도입한 기업 모두 새로운 아키텍처를 고려해야 하는 상황에 직면하고 있다. 이미 MSA로 전환을 성공한 기업들 조차도 AI적용 이후에 갑자기 기존의 마이크로 서비스 아키텍처가 퍼져버리는 MSA 붕괴(MSA Sprawl)현상을 겪곤 한다. 이런 마이크로서비스 운영 복잡성에 대한 고민 속에서 최근 소프트웨어 구조 분야에서는 기존 금융기관들을 중심으로 AI 변화에 효과적으로 대응하기 위한 새로운 구조 방식들이 주목받고 있다. 그중 하나가 모듈형 단일구조(Modular Monolithic) 아키텍처다. 이는 단일 배포 단위를 유지하면서 시스템을 논리적으로 독립된 여러 모듈로 나누는 방식이다. 마이크로서비스처럼 서비스를 물리적으로 분리하지 않아 분산 시스템의 복잡한 네트워크 통신이나 배포 관리의 어려움을 피할 수 있다. 동시에 모듈화를 통해 코드 응집도를 높이고, 팀별 모듈 개발로 마이크로서비스와 유사한 개발 효율성을 얻을 수 있다. 특히 금융, 통신처럼 비즈니스 프로세스가 크고 복잡해 여러 서비스를 포함한 기능 단위로 변경이 잦은 경우, 모듈 내에서는 직접 메서드 호출이 가능한 구조로 설계해 성능과 개발 효율성을 높일 수 있다. 이는 복잡한 트랜잭션의 안정성과 성능이 중요한 시스템에 특히 유리한 선택이다. 또 다른 대안으로는 셀 기반 아키텍처(Cell-based Architecture)다. 이는 대규모 분산 시스템 안정성과 확장성 확보 필요성에 따라 등장했으며, 시스템 전체를 완전히 독립적으로 배포 및 운영할 수 있는 '셀(Cell)' 단위로 구성하는 개념이다. 각 셀은 자체 데이터 저장소를 포함한 모든 구성 요소를 갖춘 작은 독립 시스템처럼 작동하며, 셀 간 의존성은 최소화된다. 이러한 구조는 특정 셀의 장애가 다른 셀로 전파되는 것을 막아 시스템 전체의 안정성을 높이고, 셀 단위 독립 확장이 가능해 대규모 시스템에 적합하다. 아마존 웹 서비스(AWS: Amazon Web Services) 등 대규모 클라우드 사업자들이 회복탄력성 높은 서비스 운영을 위해 발전시킨 개념으로, 우버(Uber) 등도 유사 개념을 적용하고 있다. 과거처럼 시스템 전체를 한 번에 개편하는 '차세대 시스템' 구축이 어려워진 지금, 대부분 시스템은 부분적이고 점진적인 개선을 통해 발전한다. 이때 시스템 개선 단위를 어떻게 설정하고, 각 시스템 환경과 비즈니스 목표에 따라 어떤 아키텍처 스타일을 선택할 것인지가 매우 중요하다. MSA, 셀 아키텍처, 모듈형 단일구조 중 만병통치약은 없다. 중요한 것은, 아키텍처 스타일과 관계없이 고려하지 못했던 작은 서비스 하나의 장애가 시스템 전체에 심각한 영향을 미칠 수 있음을 항상 인지하는 것이다. 따라서 개별 서비스나 모듈 최적화를 넘어, 엔터프라이즈 시스템 전체에 일관된 아키텍처 철학이 필요하다. 최적의 아키텍처를 전략적으로 선택하고 유지하는 AI시대에 안정적인 디지털 트랜스포메이션에 핵심 경쟁력이 된 것이다. 다음 편에서는 AI시대에서 SW아키텍트 역할에 대해서 살펴보려고 한다. ◆ 나희동 대표는... -정보관리기술사 (54회), 국제SW아키텍트 (CPSA) -서울과학기술대학교 컴퓨터공학 석사 및 미국 CMU SEEK 1기 연수 -전/투이컨설팅 SW아키텍처 담당 이사 -전/싸이버로지텍 기술연구소 및 플랫폼사업본부 상무 -전/동양시스템즈 솔루션사업본부 본부장

2025.06.28 23:12나희동