Architecture - 디지털 트랜스포메이션

in DEV on Architecture


이 포스트에서는 아래 내용에 대해 알아본다.

  • 디지털 트랜스포메이션을 수익 창출을 위한 비즈니스 전략으로 설정
  • 일반적으로 혁신은 존재하는 것을 획기적으로 개선하는 것들로 구성됨
    현재 존재하는 것들을 새로운 전달 메커니즘과 수익 모델을 잘 고려하면 어제보다 훨씬 더 큰 가치를 제공하는 혁신의 촉매제가 됨

스페이스엑스의 혁신

그들은 당시 유일한 자금 조달 방법인 정부와 계약해로 일하지 않았음
그들의 최우선 목표는 우주에 물체를 발사하는 비용을 극적으로 줄이는 것이었고, 주요 하위 목표는 부스터 로켓을 복원해서 재사용하는 것이었음

실험과 이벤트를 통합하는 전략(부스터 로켓 발사 실험)은 여러 엔지니어링 팀이 다른 팀들과 최신 버전을 빠르게 시험해볼 수 있는 가장 좋은 방법이었음

그들이 정부와 맺었던 전략은 아마도 스페이스엑스가 실험 도중 생긴 많은 추락사고를 용납하지 않았을 것임
하지만 세부 사항까지 모든 것을 계획하고 고민하는 대신에 몰랐던 것을 밝히기 위해 실험 도중 수많은 추락을 경험함으로써 신뢰성이 높으면서도 저렴한 부스터 로켓을 5배나 빨리 개발할 수 있었음

스페이스엑스 팀은 리스크가 없을 때까지 기다리는 대신 실험해보고 추락의 원인을 찾아내는 것이 훨씬 저렴하다고 이야기 함

목차

1. 디지털 트랜스포메이션(DX: Digital Transformation)의 목표

온프레미스에서 클라우드로의 전환이 어떤 유형의 비용을 다른 유형의 비용으로 치환하는 것에 불과하다면 이것은 트랜스포메이션이 아니다.

디지털 트랜스포메이션은 디지털 기술을 활용해서 비즈니스의 방식, 문화, 고객 경험 등을 혁신적으로 변화시키는 것이다.
디지털 트랜스포메이션의 핵심은 단순히 새로운 기술을 도입하는 것을 넘어서, 비즈니스 전반을 디지털 중심으로 재설계하여 경쟁력을 강화하고, 새로운 가치 창출을 하는 것이다.

<디지털 트랜스포메이션>

  • 목적
    • 단순히 기술을 도입하는 것이 아니라 회사의 경쟁력을 높이고, 고객 가치를 혁신하는 것
  • 방법
    • 클라우드, 빅데이터, AI, IoT 와 같은 디지털 기술을 비즈니스 모델이나 운영 방식에 깊이 통합함
  • 결과
    • 업무 자동화, 고객 경험 향상, 의사결정 고도화, 비용 절감, 새로운 수익 모델 창출

<디지털 트랜스포메이션의 대표 사례>

  • 아마존
    • 전통적인 오프라인 서점을 디지털 플랫폼으로 전환하고, AWS 를 통한 클라우드 비즈니스까지 확장
  • 넷플릭스
    • DVD 대여 서비스에서 스트리밍 플랫폼으로 전환
    • 빅데이터 기반의 개인화 추천 시스템 도입

소프트웨어 아키텍처는 불가피한 변화를 지원해야 한다.
현재 아키텍처에서 기존 컴포넌트들이 새로운 요구사항을 충족하지 못하는 경우 과도한 비용이나 노력없이 교체가 가능해야 한다.
또한, 아키텍처는 전체 아키텍처에 큰 영향을 미치지 않으면서 필요한 확장을 수용할 수 있어야 한다.

1.1. 디지털화(Digitalization)와 디지털 트랜스포메이션(Digital Transformation)

구분디지털화(Digitalization)디지털 트랜스포메이션(DX)
정의아날로그 데이터를 디지털로 변환하는 과정디지털 기술을 활용하여 비즈니스 전체를 혁신하는 과정
범위제한적(데이터, 문서, 기록 등)전사적(비즈니스 모델, 고객 경험, 조직 문화 등)
목적정보 저장과 전달의 효율성 향상경쟁력 확보, 새로운 가치 확보
예시종이 문서를 PDF 로 스캔고객 서비스를 챗봇과 AI 기반 상담으로 전환

즉, 디지털화는 ‘변화’ 이고, 디지털 트랜스포메이션은 ‘혁신’이다.

2. 소프트웨어에 문제가 생기는 이유

시간이 지남에 따라 비즈니스의 핵심 목적은 향상될 수도 있지만 때로는 상당히 변형될 수도 있다.

처음 설계한 애플리케이션에 지속적으로 새로운 기능을 추가하다 보면 애초의 의도와 목적이 희미해지고, 핵심이 손실되는 상황이 발생할 수 있다.

빠른 개발은 전략적 유지로의 변질될 가능성이 있다.
애자일과 빠른 배포를 지향하다 보면, 빠른 개발을 ‘실패를 보상하기 위한 개발 문화’로 전락할 수 있다.

  • 긴급한 버그를 해결하고,
  • DB 를 직접 수정하며,
  • 단기적인 문제 해결에 집중하는 방식은

결국 전략적인 방향에서 벗어나 점점 더 임시방편적인 운영으로 이어질 수 있다.

기존 코드의 복잡성과 무질서가 커질수록, 새로운 기능을 추가하는 일은 더 조심스럽고 느리게 진행될 수밖에 없다.

  • 시스템 전반에 걸친 영향 범위를 파악하기 어렵고
  • 과거 변경 이력에 대한 맥락이 누락되며
  • 변경 하나가 어디까지 영향을 미칠 지 알 수 없는 상황이 되기 때문이다.

즉, 지나친 기능 확장과 즉흥적 수정은 시스템의 본래 목적을 흐리게 만들고, 점점 변화에 대한 두려움과 비효율성을 키워간다.
결과적으로 소프트웨어를 구현했던 아이디어는 암묵적이어서 작업한 소수 사람의 기억에 의존하게 된다.

잘못된 아키텍처 설계는 시스템에 심각한 문제를 초래할 수 있는데 특히 아래 두 가지를 경계해야 한다.

  • 아키텍처를 명확한 필요없이 설계하는 경우
  • 단순히 새로운 기술이나 개발 스타일에 매혹되어 아키텍처를 도입하는 경우

소프트웨어 설계자와 개발자는 새로운 개발 스타일이나 트렌디한 아키텍처에 쉽게 매료될 수 있다.
하지만 이런 경우

  • 기술 도입의 실질적 필요를 충분히 검토하지 않거나
  • 새로운 아키텍처가 운영 환경에 미칠 영향을 깊이 고려하지 않은 채 결정을 내리는 경우가 많다.

이로 인해 우발적인 복잡성이 발생하고, 전체 시스템의 실행 환경과 운영에까지 부정적인 영향을 줄 수 있다.

즉, 아키텍처는 “기술적으로 멋져 보이기 때문”이 아니라 “명확한 비즈니스와 운영적 필요”에 의해 도입되어야 한다.

2.1. 기술 부채(Technical Debt)

기술 부채는 시스템 내 소프트웨어 모델이 현실과 점점 어긋나면서 생기는 부정확성을 뜻하며, 이런 상황을 빚이라는 은유로 설정한다.
즉, 빨리 바꿔야 하지만 미루고 있는 결정이 쌓이면서 시스템의 유연성이 점점 떨어지는 현상을 말한다.

소프트웨어 리팩터링은 단순히 “코드를 정리하는 것”처럼 보일 수 있지만, 사실은 개발팀이 문제 도메인에 대해 더 잘 이해하게 됨에 따라 그 이해를 코드 구조에 반영하는 과정이다

리팩터링을 하지 않으면

  • 팀의 도메인 이해와 실제 시스템 사이에 괴리가 생기고
  • 그로 인해 기능 추가 속도가 점점 느려지고
  • 결국 개발 자체가 어려운 상태로 진입하게 된다.

<기술 부채를 방치할 경우 발생하는 일>

  • 새로운 기능을 추가하는데 시간이 점점 더 오래 걸림
  • 점차적으로 개발 속도가 느려짐
  • 결국 거의 개발이 멈춘 것처럼 보일 정도로 진전이 어려운 상태에 이르게 됨

즉, 리팩터링은 시스템을 깔끔하게 만드는 작업이 아니라 팀이 깊어진 문제 이해를 코드에 반영하여 기술 부채를 줄이고 개발 속도를 유지하는 전략적 사업이다.

일정이 부족해서 일부 기능을 나중에 구현하기로 하고 우선 제품을 오픈하는 경우는 기술 부채일까?

이러한 경우도 기술 부채이지만, 나중에 반드시 갚아야 할 빚이라는 걸 인지하고 있는 상태라면 전략적인 판단임

기술 부채의 2종류

  • 의도적인 기술 부채
    • 일정, 비용, 시장 출시 등 현실적인 이유로, 단기적으로 부채를 감수하는 경우
    • 예) 베타 오픈을 위해 인증 기능을 임시로 하드코딩 처리
  • 의도치 않은 기술 부채
    • 초기에는 모르고 넘겼지만, 나중에 복잡성을 유발하는 구조가 됨
    • 예) 설계없이 개발 시작 → 나중에 구조가 꼬임

따라서 이런 경우는 의도적인 기술 부채에 해당하며, 일정상 어쩔 수 없이 선택한 전략적인 절충안임

중요한 것은

  • 반드시 부채 리스트를 남겨놓아야 함
  • 추후 우선순위를 정해서 갚은 계획을 세워야 함
  • 계속해서 미루지 않을 것

소프트웨어의 부채가 많은 개발자는 결국 큰 손해를 보게 된다.
기능을 추가하는 것이 점점 더 오래 걸리다가 결국은 거의 진전을 이루지 못할 상태까지 이르게 된다.

2.2. 소프트웨어 엔트로피

소프트웨어 엔트로피는 통제되지 않은 변경이 반복적으로 시스템에 축적되면서, 소프트웨어가 점점 무질서하고 복잡해지는 현상이다.
즉, 작은 부주의와 임시 방편이 쌓여서 시스템 전체의 품질이 서서히 붕괴하는 과정을 뜻한다.

<소프트웨어 엔트로피의 특징>

  • 명확한 설계나 구조없이 수정이 계속될 때 발생
  • 코드를 변경할수록 이해하기 어렵고 유지보수가 힘들어짐
  • 시간이 지날수록 기능 추가나 수정이 점점 더 위험하고 비용이 많이 듦

작은 무질서라도 방치하면 소프트웨어는 점점 손댈 수 없는 상태로 무너진다.

설계 엔트로피(Design Entropy)

시간이 지날수록 시스템이 점점 복잡해지고, 이해하기 어렵고, 유지보수가 힘들어지는 현상

엔트로피가 높아지면 생기는 문제

  • 버그 발생 확률 증가
  • 신규 기능 추가 시 시간 증가
  • 코드 가독성 하락
  • 테스트 어려움
  • 팀 생산성 저하

설계 엔트로피 줄이는 방법

  • 리팩터링을 통해 주기적으로 구조를 정리하고, 중복 제거
  • 코드 리뷰를 통해 설계와 일관성 유지, 원칙 준수 점검
  • 테스트 도입으로 설계가 바뀌어도 안전성 확보
  • 문서화를 통해 시스템 구조와 의도를 공유하여 무질서 방지
  • DDD 를 통해 도메인 중심의 구조화로 복잡도 관리

2.3. 빅볼 오브 머드(Big Ball of Mud)

빅볼 오브 머드는 소프트웨어 엔트로피와 기술 부채가 극도로 쌓인 시스템이다.
즉, 명확한 설계 없이 무질서하게 성장하여 구조도 없고 일관성도 없는 소프트웨어 덩어리가 되어 버린 상태를 말한다.

<빅볼 오브 머드의 특징>

  • 무작위적이고 계획되지 않은 구조
  • 규제되지 않은 무분별한 성장
  • 반복적이고 임시방편적인 수정
  • 정보의 난잡한 공유
  • 전역 상태(global state) 와 중복된 핵심 데이터

<빅볼 오브 머드의 문제>

  • 소프트웨어를 배포하는 주기가 점점 길어짐
  • 팀과 개인이 시스템을 개선할 수 없다는 무력감을 느낌
  • 점차 변화에 무관심해지고, 현실에 안주하는 문화 형성
  • 결국 환멸과 사기 저하로 이어짐

빅볼 오브 머드는 소프트웨어뿐 아니라 팀 문화와 조직 분위기까지 서서히 붕괴시킨다.

화이트 레이블(white-label)

화이트 레이블 제품은 한 회사(생산자)가 생산한 제품 또는 서비스를 다른 회사(마케터)가 브랜드를 변경해 마치 마케터 회사가 만든 것처럼 보이게 하는 것임

3. 콘웨이의 법칙(Conway’s Law)

콘웨이의 법칙은 아래와 같이 정의된다.

“시스템의 구조는 그것을 설계한 조직의 커뮤니케이션 구조를 닮는다.”

즉, 조직 내 사람들이 소통하는 방식과 경계가 자연스럽게 시스템 아키텍처에도 반영된다는 뜻이다.

<콘웨이의 법칙의 작용 방식>

  • 팀이 분리되면 시스템도 자연스럽게 분리됨
  • 부서 간 소통이 단절되면 시스템 간 연동도 부자연스러워짐
  • 조직 구조가 복잡하면, 소프트웨어 아키텍처도 복잡하게 얽힘

만유인력의 법칙처럼 콘웨이의 법칙은 극복할 수 있는 문제가 아니다.
완전히 피해 갈 수는 없지만 이 법칙을 이해하고 의식적으로 조직 구조와 커뮤니케이션 방식을 개선함으로써 더 나은 시스템 구조를 만들기위해 노력할 수 있다.

<콘웨이의 법칙 활용법>

  • 조직 구조를 시스템 아키텍처에 맞게 설계
    • 시스템의 모듈 경계에 맞춰 팀 구성
    • 시스템 간 통신이 필요한 만큼 팀 간 커뮤니케이션 유도
  • 팀 간 커뮤니케이션 경계를 명확히 설정
    • 필요 이상의 팀 간 의존성과 커뮤니케이션 비용을 줄임
    • 팀이 독립적이라 빠르게 움직일 수 있도록 함
  • 필요할 때 조직을 재구성
    • 새로운 아키텍처 요구사항이나 비즈니스 변화에 따라 팀 구조도 함께 조정
    • ‘조직은 고정된 것이 아니다’라는 관점 유지

시스템은 사람들의 소통 방식을 반영한다.
따라서 좋은 시스템을 만들기 위해서는 좋은 커뮤니케이션 구조를 먼저 만들어야 한다.

콘웨이 법칙을 의도적으로 활용하는 전략 중 대표적인 전략은 팀 토폴로지(Team Topologies) 이다.

<Team Topologies 핵심 개념>

구분설명
스트림 얼라인 팀(Stream-Aligned Team)특정 비즈니스 가치 흐름(스트림)에 집중하는 팀
엔블러 팀(Enabling Team)다른 팀이 빠르게 움직일 수 있도록 지원하는 전문가팀
컴플리케이트 서브시스템 팀(Complicated Subsystem Team)복잡하고 전문적인 서브시스템을 담당하는 팀
플랫폼 팀(Platform Team)공통 기능을 제공해 다른 팀의 개발 속도를 높이는 팀

시스템을 잘 설계하고 싶다면, 조직과 커뮤니케이션 구조를 함께 설계해야 한다.

3.1. 커뮤니케이션은 지식에 관한 것

암묵지(Tacit Knowledge) 는 문서화되어 있지 않고, 개인의 경험이나 작업 습관에 기반한 지식을 말한다.
예) 특정 업무를 처리하는 비공식적인 방법, 개인이 선호하는 개발 스타일, 숙련자만 알고 있는 암묵적인 노하우 등

이런 지식은 사람들 사이의 경험과 커뮤니케이션을 통해서만 전파된다.

조직 내에서 지식은 의사 소통을 통해 지식을 교환하기 때문에 조직의 커뮤니케이션이 활발할수록 암묵지 공유와 학습이 더 잘 이루어진다.

지식은 단순히 백과사전처럼 지식을 저장한다고 해서 공유가 이루어지지 않는다.
명확한 목표를 가지고 업무를 개선하거나 문제를 해결하려는 맥락 속에서 지식을 나눌 때 진짜 학습이 일어나고, 집단 지성이 강화된다.

집단 학습의 힘은 아래와 같다.
목표 중심의 지식 공유는 개인 학습을 넘어, 팀과 조직 전체의 혁신을 이끌어 낼 수 있다.

지식은 목표없는 기록이 아니라, 목표를 향한 소통과 학습을 통해 살아있는 힘이 된다.

3.1.1. 암묵지(Tacit Knowledge)를 명시지로 만들기: SECI 모델

암묵지는 방치하면 전달되기 어렵고 사라지기 쉽다.

이를 해결하기 위해 SECI(Socialization-Externalization-Combination-Internalization) 모델이 제시되었다.
SECI 모델은 지식이 어떻게 생성되고 확산되는지를 설명하는 모델이다.

아래는 SECI 의 4가지 단계이다.

단계설명예시
사회화(Socialization)사람들 간에 직접 경험을 통해 암묵지를 공유신입사원이 선배와 함께 일하면서 일하는 방식을 체득
명시화(Externalization)암묵지를 명확한 형태로 표현팀 내에서 노하우를 문서화하거나 표준 프로세스를 만드는 것
결합(Combination)다양한 명시지를 조합하여 새로운 지식 생성여러 문서를 통합하여 새로운 가이드라인 생성
내재화(Internalization)명시지를 개인이 학습하여 암묵지로 흡수문서로 배운 절차를 실제 경험을 통해 자기 것으로 만듦

암묵지 → 명시지 → 명시기 조합 → 새로운 암묵지 순으로 지식은 순환하며 조직 전체가 점점 더 지식 기반으로 강해진다.

즉, 지식을 쌓기 위해서는 암묵지를 명시화하고, 공유하고, 다시 체득하는 순환 구조를 만들어야 한다.

3.2. 지식의 전달 과정과 왜곡

지식은 단순히 정보로만 존재하지 않는다.
사람이 정보를 전달할 때 정보는 구조화되어 외재화(마음속에 있는 생각이나 지식을 다른 사람들이 볼 수 있도록 표현)되고, 수신자는 이를 자신의 경험과 문맥을 통해 의미 해석하게 된다.
즉, 정보는 구조적 형태로 외부에 드러나지만 그 의미는 각 수신자의 해석에 따라 달라질 수 있다.

두 사람이 동일한 정보를 받아도

  • 각자의 과거 경험
  • 정보를 읽는 문맥
  • 의사소통의 정확성 에 따라 부여하는 의미가 달라질 수 있다.
    어떤 사람이 의도한 의미와 수신자가 해석한 의미가 완전히 일치한다고 보장할 수 없는 것이다.

의사소통은 전달되는 모든 단계에서 왜곡이 발생할 수 있다.
메시지를 전달하는 사람이 많을수록 왜곡은 더 심해지며, 결국 처음 의도한 메시지와 최종 수신자의 해석은 상당히 다를 수 있다.

따라서 완벽한 의사소통을 기대하기보다는 계속 확인하고 피드백을 주고받는 과정이 필수적이다.

즉, 정보는 전달될 때마다 왜곡될 수 있다.
명확한 의사소통은 어렵지만, 이를 인식하고 지속적으로 조율하는 노력이 필요하다.

3.2.1. 정보 왜곡 줄이기

정보 왜곡을 줄이기 위한 커뮤니케이션 전략은 아래 5가지 정도가 있다.

  • 피드백 루프
    • 한 방향으로만 정보를 전달하지 않음
    • 수신자가 이해한 내용을 다시 확인하고, 전달자가 추가 설정이나 수정할 기회를 갖는다.
    • 예) “제가 이해한 바로는 ~라는 의미같은데, 맞나요?”
  • 반복 확인
    • 핵심 메시지는 여러 번 강조하고 반복함
    • 중요한 내용일수록 다른 표현과 예시를 활용해 재전달한다.
    • 예) 회의 끝에 핵심 결정 사항을 다시 정리해서 공유
  • 명확한 컨텍스트 설정
    • 정보를 주기 전에 배경(이걸 왜 이야기하는지)과 목표(이걸 통해 무엇을 얻으려는지)를 명확히 전달함
    • 수신자가 올바른 맥락에서 정보를 해석할 수 있도록 돕는다.
    • 예) “지금 이야기하는 것은 다음 분기 목표 설정과 관련된 논의입니다.”
  • 문서화와 기록
    • 구두로 전달된 내용은 짧게라도 요약 문서로 남김
    • 시간과 기억의 왜곡을 줄이고, 나중에 일관성있게 참고할 수 있게 한다.
    • 예) 회의 후 결정사항 메모 공유
  • 전달 경로 최소화
    • 가능하면 중간 전달자없이 직접 소통함
    • 사람을 많이 거칠수록 메시지가 왜곡될 위험이 커진다.
    • 예) 중요한 의사결정은 직접 참여한 사람들이 함께 공유

3.3. 기술 리더십과 변화에 대한 저항

<변화에 대한 기술 리더십의 불안>
기술 리더십은 아래와 같은 상황에서 불안을 느낄 수 있다.

  • 팀의 일에 대한 외부 비평이 위협처럼 다가올 때
  • 조직 내에서 큰 변화 조짐이 나타날 때

특히 변화의 필요성이 잘못 해석되면 기존에 열심히 쌓아온 시스템과 노력이 “지속 불가능하다”는 부정적 평가로 받아들여질 수 있다

역사적으로

  • 인간은 자신이 직접 일궈낸 것에 막대한 감정적 투자를 함
  • 자아는 변화를 개인적 실패로 받아들이게 만듦

즉, “내가 만든 시스템이 틀렸다는 말인가?” 이런 감정이 자연스럽게 생긴다.

<외부 인사와 내부 상황의 단절>
때로 외부에서 온 사람들은 통상적인 비즈니스 흐름에 맞지 않는 급진적인 변화를 요구하고, 기술 부채/소프트웨어 엔트로피/시간 압박 등 내부 팀이 겪어온 오랜 고충을 이해하지 못한다.
이로 인해 기술 리더십은 외부의 요구를 적대적 공격처럼 받아들이게 되고, 경영진의 배신감까지 느끼게 된다.

기술 리더십이 불안을 느끼면 자신의 우려는 소수 팀원들에게 공유한다. 이로 인해 신뢰하는 팀원들 사이에서 의심과 두려움이 확산되고, 이 두려움은 조직 전체로 퍼져서 점차 광범위한 변화 저항으로 이어진다.

결과적으로 경영진은 변화를 밀어붙이기 위해 새로운 책임자를 지정하고, 기존 팀은 가차없는 방식으로 기술 부채를 상환해야 하는 상황에 놓이게 된다.
이로 인해 조직 내 긴장과 저항은 더욱 심화된다.

기술 리더십이 변화에 대한 두려움과 불신을 키우며 이는 팀 전체의 저항으로 번지고, 결국 조직은 더 고통스러운 방식으로 변화를 겪게 된다.

3.4. 최적의 의사소통을 위한 고려 요소

  • 모두를 ‘우리’로 생각하기
    • 조직 내에서 ‘우리 vs 그들’ 프레임을 만들지 않는다.
    • 모든 구성원은 하나의 팀이라는 인식을 공유한다.
  • 섬김 리더십(Servant Leadership)
    • 진정한 리더는 누구보다도 낮은 위치에서 섬긴다.
    • 리더십은 지시하는 것이 아니라, 팀이 성장하고 성공할 수 있도록 지원하는 것이다.
  • 전략적 조직 구조의 중요성
    • 잘 설계된 조직 구조는 효과적인 커뮤니케이션과 협업을 촉진한다.
    • 구조는 단순히 명령 체계를 만드는 것이 아니라, 사람들이 더 잘 연결되고 움직일 수 있도록 돕는 역할을 해야 한다.
  • 안전한 의견 표현
    • 누구든지 건설적인 의견을 말할 때 위협을 느껴서는 안된다.
    • 심리적 안전성이 확보되어야 건강한 피드백과 발전적인 논의가 가능하다.
  • 긍정적인 동기 부여
    • 긍정적인 영향력은 사람들이 자발적으로 건설적인 행동을 하게 만든다.
    • 비판보다는 격려와 인정을 통해 팀의 에너지를 높이는 것이 중요하다.
  • 비즈니스-기술 파트너십
    • 비즈니스와 기술은 따로 노는 것이 아니라 상호 존중을 기반으로 한 파트너십을 맺어야 한다.
    • 목표를 함께 설정하고, 같은 방향을 바라보며 나아가는 것이 필수적이다.
  • 심도 있는 소통과 협력
    • 심도 있는 소통, 비판적 사고, 능동적인 협력없이는 혁신적이고 파괴적인 소프트웨어 시스템을 만들 수 없다.
    • 진정한 혁신은 깊은 논의와 치열한 사고 과정을 통해 탄생한다.

즉, 최적의 커뮤니케이션은 심리적 안전성과 상호 존중을 기반으로, 모두가 동등하게 목표를 향해 협력할 때 가능해진다.

4. 소프트웨어 전략 다시 생각하기

우리가 추구해야 하는 전략적 비즈니스 목표가 무엇인지 이해할 때까지는 시스템의 기술적 특성을 결정하려고 해서는 안된다.

4.1. 깊이 있는 사고와 기술 선택의 중요성

<무의식적인 현실 안주>

  • 사람은 세부 사항에 대해 깊이 고민하지 않을수록 점점 자신의 행동을 의식적으로 돌아보지 않게 된다.
  • 이는 노년기에 지적 활동을 멈춘 사람들이 인지 능력을 점점 상실하는 것과 비슷한 메커니즘이다.

<개발자의 현실 안주가 초래하는 문제>
소프트웨어 개발자도 깊이 생각하지 않고 습관적으로 개발하기 시작하면 기술 부채 상환이 더뎌지고, 규제되지 않은 성장이 반복되며, 결국 편법적 수리만 반복하는 상황으로 몰락할 수 있다.
또한 비즈니스 전체를 바라보기보다는 단순히 회사가 판매할 제품을 만드는 데만 몰두하는 현상도 우려된다.

먼저 적절한 비즈니스 결정을 내린 후 그 위에서 시스템 사양을 세부적으로 검토하고 기술 결정을 내려야 한다.
특정 아키텍처나 기술을 선택할 때,

  • 단순히 유행하거나 (포모 증후군)
  • 이력서에 한 줄 추가하고 싶거나 (CV 주도 개발)
  • 주변에서 떠든다고 해서 선택하는 것이 아니라
  • 실제 비즈니스 및 기술 요구사항에 부합하는지 철저히 검토해야 한다.

포모 증후군(FOMO, Fear of Missing Out)

다른 사람들이 나보다 더 재미있고 나은 삶을 지내는 것을 보고, 그것이 나에게는 없을 때 느끼는 심리적 불안감
여기서는 유행하는 기술을 나는 알아야 하고, 자랑하고 싶은 마음에 맹목적인 선택을 하는 상황을 뜻함

CV(이력서, Curriculum Vitae) 주도 개발(DDD)

어떤 문제를 해결할 때 특정 기술이 합리적인지보다 프로그래머의 이력서를 향상시킬 설계 및 개발 기술 선택을 우선시하는 소프트웨어 개발 프로세스

확고한 의견을 갖고 큰 목소리를 낸다고 해서 그 주장이 옳은 것은 아니다.
중요한 것은 정보에 기반해 명확하고, 광범위하며, 깊이 있고, 비판적으로 생각하는 것이다.

깊이 없는 생각은 현실 안주와 기술 부채를 불러온다.

4.2. 레거시 시스템 교체 시 전략

레거시 시스템을 교체할 때 가장 큰 문제는 아래와 같다.

  • 기존에 작동하는 기능이 누락되거나 손상될 위험
  • 새롭고 현대적인 기술 스택을 사용한다고 해서 변경이 안전해지지는 않음
  • 완전한 재구현을 시도할 경우, 몇 개월 이상의 개발 기간이 필요함
  • 변경 요구를 보류하는 동안 새롭거나 급박한 요구사항이 계속 쌓임

즉, 완전 교체 전략은 단순해 보이지만, 현실적으로는 큰 위험을 내포하고 있다.

시스템의 재구현은 전략적이어야 하고, 파장을 최소화하는 세심한 접근이 필요하다.
대규모 문제를 무계획적으로 접근하면 문제가 해결되기 보다는 또 다른 엄청만 문제를 초래할 가능성이 높다.

아래는 전략적 학습에 필요한 핵심 질문들이다.

  • 사업 목표와 전략은 무엇인가?
    • 전략적 이니셔티브에 포함된 모든 소프트웨어 기능은 핵심 비즈니스 목표에 명확히 연결되어야 하며, 아래를 반드시 명시해야 한다.
      • 비즈니스 목표
      • 목표가 영향을 끼칠 시장 세그먼트
      • 해당 시장 세그먼트에서 기대하는 영향
  • 우리는 왜 이것을 하지 않을까?
    • 기술 결정을 내릴 때 YAGNI(You Aren’t Gonna Need It, 필요하지 않을 것이다.) 를 반드시 고려한다.
    • 불필요한 기능 추가를 방지하는 것은 중요하지만
    • YAGNI 를 무조건적인 무기로 삼으면 팀의 신뢰를 잃고, 학습 기회를 차단할 수도 있다.
    • 즉, YAGNI 는 신중하게 사용되어야 하며, 소통의 도구이며 억압의 수단이 되어서는 안된다.
  • 서비스 수준 요구사항(SLA, SLO 등) 은 무엇인가?
    • 초기에 모든 아키텍처 결정을 서두르지 않는다.
    • 필요한 경우 세부 결정을 지연시키는 것은 아래와 같은 이점을 준다.
      • 먼저 실제 비즈니스 문제 해결에 집중하고
      • 인프라 복잡성은 나중에 점진적으로 도입함
    • 예로 어떤 문제를 해결하기 위해 MSA 가 필요하다는 확신이 생겼는데 네트워크에서 분산된 서비스 도입을 연기하면 분산 컴퓨팅으로 인한 오버헤드에 대처하는 것보다 실제 비즈니스에 집중하는데 도움이 될 수 있다
    • 필요한 복잡성만 도입하고, 핵심 비즈니스 가치를 먼저 달성하는 것이 중요하다.

전략적 이니셔티브(Strategic Initiative)

조직이 장기 목표나 비전을 달성하기 위해 선택적으로 추진하는 중요한 프로젝트나 행동
즉, 조직이 미래를 위해 의도적으로 추진하는 중요하고 영향력 큰 행동이나 프로젝트

전략적 이니셔티브의 특징

  • 목적이 명확함
    • 단순한 업무나 개선이 아니라, 회사의 전략적 방향과 연결됨
  • 리소스를 집중함
    • 시간, 예산, 인력을 우선순위로 배정함
  • 변화를 만듦
    • 단순 반복 업무가 아니라, 회사의 방향이나 체질을 바꾸는 것을 목표로 함
  • 측정 가능한 성과를 가짐
    • 성공 여부를 평가할 수 있는 명확한 목표나 KPI 가 설정됨

레거시 교체는 기술적 화려함보다 전략적 사고가 더 중요하다.
무엇을, 왜, 어떻게 해야하는지 명확히 하고 움직여야 성공할 수 있다.

5. 모놀리스(Monolith) 시스템은 나쁜 것인가?

모놀리스는 단순히 전체 애플리케이션 또는 전체 시스템의 소프트웨어가 둘 이상의 서브시스템을 하나의 컨테이너 안에서 함께 동작하도록 설계된 구조를 말한다.
즉, 서버 하나, 배포 단위 하나, DB 하나로 모든 기능이 통합된 형태이다.

궁극적인 시스템 아키텍처가 MSA 라도 초기에는 모놀리스로 시작하는 것이 유리할 수 있다.

  • 네트워크 연결 이슈 회피
    • 서브시스템 간 네트워크 통신이 없기 때문에 초기 개발 단계에서 불필요하고 비생산적인 문제를 피할 수 있음
  • 복잡도 감소
    • 분산 시스템 특유의 문제(네트워크 장애, 데이터 일관성 문제) 를 초기에 걱정할 필요가 없음
  • 느슨한 결합에 대한 감각 획득
    • 하나의 모놀리스 안에서도 서브시스템 간 의존성을 주의 깊게 살펴보면, 미래에 서비스 분리 기준을 찾을 수 있음

모놀리스는 단순히 모든 것을 묶어두는 구조가 아니라, 초기 시스템을 빠르게 구축하고, 자연스럽게 서브시스템 간 경계를 이해하는데 도움이 되는 전략적 선택이다.

6. 마이크로서비스는 좋은 것인가?

마이크로서비스를 나누는 기준으로 가장 좋은 방법은 크기가 아니라 목적을 정의하는 것이다.

7. 부채가 쌓인 시스템에서도 변화를 추구해야 하는 이유

기술 부채가 많고 소프트웨어 엔트로피가 극에 달한 시스템은 진전을 이루는 데 시간이 걸릴 수 있다.
하지만 그렇다고 해서 변화를 시도하는 것이 시간이나 돈을 낭비하는 것은 아니다.
오히려 변화하지 않고 기존 시스템에 집착하는 것이 더 큰 손실로 이어질 위험이 크다.

변화를 두려워하면 빠지게 되는 2가지 심리적 함정이 있다.

  • 결정의 심층적 확정
    • 사람들이 과거의 결정과 행동에 묶여 명백히 부정적인 결과가 나타나도 진로를 바꾸지 못하는 패턴을 말함
    • 잘못된 방향임을 알면서도 이전 결정을 고집하며 비합리적인 행동을 계속함
  • 매몰 비용 오류
    • 매몰 비용은 이미 지불되어 돌이킬 수 없는 과거의 투자를 말함
    • 논리적으로 매몰 비용은 미래 의사결정에 영향을 주어서는 안되지만 사람들은 “이미 이만큼 투자했으니 계속 밀어붙어야 한다” 라는 심리에 빠져 비합리적인 추가 투자를 정당화하려는 경향이 있음
    • 즉, 더 이상 의미없는 곳에 시간과 돈을 계속 퍼붓게 되는 심리적 함정이다.

부채가 쌓이고 엔트로피가 극심한 시스템을 감정적 이유(애착)이나 재정적 이유(매몰 비용)로 그대로 유지하려는 것은 손실을 더욱 키우는 잘못된 선택이다.
비록 시간이 걸리고 고통이 따르더라도 “진흙 속으로 더 깊이 가라앉지 않고, 앞으로 전진하는 것”이 절대적으로 필요하다.

정리하며..

  • 혁신은 디지털 트랜스포메이션의 가장 중요한 측면임
  • 소프트웨어 아키텍처는 엄청난 비용과 노력을 들이지 않고 불가피한 변화를 지원할 수 있어야 함
  • 빅볼 오브 머드 시스템은 조직이 지식을 공유하고 학습할 수 없는 단절된 의사소통 구조를 가졌을 때 만들어지는 결과임
  • 모놀리스 시스템이 반드시 나쁜 것은 아니며, 마이크로서비스가 반드시 좋은 것도 아님

참고 사이트 & 함께 보면 좋은 사이트

본 포스트는 반 버논, 토마스 야스쿨라 저자의 전략적 모놀리스와 마이크로서비스를 기반으로 스터디하며 정리한 내용들입니다.




© 2020.08. by assu10

Powered by assu10