소프트웨어 아키텍처는 의사결정이지, 모방이 아니다

HJ, Ph.D. / Software Architect
(js.seth.h@gmail.com)
초안: 2022년 07월 / 개정: 2025년 11월

Software architecture is decision-making, not mimicry.

Abstract

• 소프트웨어 아키텍처는 종종 '의사결정'이라고 말하지만, 대부분은 그냥 무언가를 따라할 뿐이다.
• 이러한 '흉내 내기'는 조직의 맥락, 팀의 역량, 비즈니스 목표를 무시한 채, 성공 사례의 표면만 좇다가 비용이라는 대가를 치른다.
• 모든 비즈니스는 고유 흐름이 있고, 그 흐름에 걸맞는 구조가 있다. 따라서, '문제에 대한 이해'와 '달성해야 할 목표'에 대한 성찰이 반드시 필요하다.
• 적절한 결론을 얻기 위해서는 정확한 문제 인식 위에 충분한 배경지식, 다양한 모범 사례(Best Practice)와 그 변형을 알아야 한다.
• 트레이드오프(Trade-off)를 이해하고 이익을 추구해라.
• 선택함에 있어, 기꺼이 치를 수 있는 대가만 수용해라.
• 때론 손해 보더라도 조화를 이루어, 병립 가능하게 해라.

의사결정이란 무엇인가?

소프트웨어 아키텍처에서 의사결정이란, 단순히 기술을 고르는 행위가 아니라, 다양한 제약과 목표, 조직의 상황을 종합적으로 고려해 최적의 방향을 정하는 과정이다. 단순히 말해 트레이드오프의 가운데 절묘하게 중심을 잡고 서는 행위이다. 따라서, 그 결정이 어떤 트레이드오프, 즉 2개 이상의 축에서 손실과 이익을 어떻게 가져오는지 알고 있지 못한다면, 그건 '의사결정'이 아니라, 흉내 내기에 그친 것이다.

'의사결정'은 최소한, 무엇을 추구했으며, 무엇을 감내했는지 알고 있어야 한다.

왜 단순 모방에 그치는가?

인간에게 최대 편익의 추구는 사실상 본능이다.
그럼에도 어째서 이익과 손해를 명확히 알지 못하고, 흉내 내기에 그치는가?
그것은 모범 사례의 구조는 파악했을지언정, 그 속의 결정을 이해하지 못해서다.

Restful API, Monolithic, MSA, RPC 등 수많은 방법론이 동시에 존재하며, 그중 하나로 통일되지 않는다는 사실 자체가 만능 공구는 없다는 반증이다.

모두 장점이 있다. 다들 자신의 장점을 열심히 홍보한다. 그러나 그보다 더 중요한 것은, 어떤 선택이든 모두 단점, 즉 희생이 있다는 점이다. 트레이드오프를 보지 못한다면, 겉모습만 베끼는 것에 머무르게 된다.

왜 망해버리는가?

설계도는 단지 결정을 그림으로 표현한 것에 불과하다. 관례적인 모방은 최선도 차선도 얻지 못한다. 각자의 사정에 의해, 도저히 치를 수 없는 대가가 있기 마련이다.

운이 좋아, 모범사례와 모든 면이 비슷하여, 비슷한 대가를 치르면서 성공할 수도 있다. 그러나 프로젝트는 성공하는 이유보다 실패하는 이유를 피해가는 것이 더 필요한 법이다. “남들도 쓰니까”라는 이유로 특정 기술을 도입한 뒤, 그 단점을 상쇄할 방법을 찾지 못한다면, 실패로 이어질 가능성이 높다.

비즈니스의 고유 흐름이란 무엇인가?

모든 비즈니스는 고유한 업무 흐름과 요구사항을 가진다. 위키시스템과 쇼핑몰의 시스템은 전혀 다른 흐름을 지닌다. 장부관리 시스템과 자동차 엔터테인먼트 시스템도 마찬가지다. 주요 처리 흐름의 다른 비즈니스는 서로 다른 구조를 가지는 것이 타당하다.

그러나, 현실 개발에서 대부분의 프로젝트를 보면 Restful API로 만들려고 시도한다. 그러면, 적어도 절반은 비효율적 선택이다. 그리고 그렇게 비효율을 감당하는 사람 중 Roy Fielding의 REST 스타일 제안을 직접 읽고, 그 안의 트레이드오프를 이해하고, 그것을 극복하기 위한 Roy Fielding의 제안을 이해한 사람은 없을 것이다. 이해한다면, 그렇게 하지 않을 테니까.

모든 비즈니스는 그 속에 가장 흔하게 발견되는 컴퓨팅 패턴이 있다. 아마도 인간이 특정 업무군을 묶어서 발전시켜왔기 때문 아니겠는가? 업무에 맞는 적절한 등뼈를 선택해야 한다. 고양이 몸을 생선가시로 지탱할 수는 없다. 워드프레스를 수정해서 관계형 데이터베이스를 만들려는 아키텍트가 있겠는가?

배경지식은 어떻게 얻는가?

배경지식을 얻는 경로는 거의 유일하다. 전공서를 봐라. 컴퓨터 과학의 역사는 매우 짧다. 고작 70년도 안 된다. 또한 다른 학문과 거의 겹치지 않는 사실상 격리된 학문이다. 그 안에는 가장 기초적인 것들이 모두 들어 있다. 어떤 라이브러리, 프레임워크도 기초 위에 세워져 있기에, 전공 기초를 아는 사람과 모르는 사람의 이해는 크게 차이날 수밖에 없다.

모범사례와 변형은 어떻게 아는가?

모범사례는 다양한 경로로 얻을 수 있다. 기술 서적, 공식 문서, 커뮤니티, 컨퍼런스, 오픈 소스, 실제 프로젝트의 결과 등 모두 해당한다. 뛰어난 개발자들이 각자의 문제를 고민하여 최선의 결과를 도출했다면, 그 대부분은 모범사례다. 다만, 그 계산서에는 대가가 명시되어 있지 않을 뿐이다.

그럼 변형은 어떻게 아는가? 답은 깊은 전공 지식이다. 변형은 누구도 모두 설명할 수 없다. 하지만 본질적으로 모범사례의 계산서는 트레이드오프이므로, 그것을 이해한다면 조정할 수 있다. 각자의 사정에 따라 최적으로 조정하는 것이 변형을 아는 것이다. 다시 말하지만, 설계는 '의사결정' - 균형점 잡기이지, 정해진 도면에서 선택하는 것이 아니다. 그러니, 변형은 앎의 대상이 아니라, 능력에 해당한다.

최대 이익

설계의 궁극적 목표는 제한된 자원으로 최대의 효과를 내는 것이다. 예를 들어, 트래픽이 적은 서비스에 대규모 분산 시스템을 도입하는 것은 오히려 자원 낭비가 될 수 있다. 또한 팀의 역량이 부족한 방향을 추구하는 것도 최대 이익이 될 수 없다. 개발자의 대부분이 백엔드 기반 템플릿 엔진에 익숙하다면, React.js를 선택하는 것은 비용 효율이 낮다. 데이터 수정이 빈번하고 트랜잭션이 필요하며, 캐시를 많이 쓸 수 없는 시스템에 Restful API를 추구하는 것도 매우 큰 낭비를 가져온다.

인력이든, 운영비든, 개발 기간이든 원하는 요소가 있을 것이다. 최대한 적은 대가를 치르고, 많은 것을 챙겨라.

어떻게 적절한 결정을 내리는가?

절대, 모든 것을 가질 순 없다.

트레이드오프가 존재하는 한, 모든 측면에서 최대의 이익을 얻는 것은 불가능하다. 생산성을 올리려면, 디테일을 줄여야 하고, 안정성을 추구하려면 투입 시간과 운영비를 늘려야 한다. 디테일이 가장 많고, 안정성이 가장 높으면서, 가장 단시간에, 가장 저렴한 운영비의 소프트웨어는 만들 수 없다.

세상 대부분의 일은 불가분성을 가지고 있고, 소프트웨어 개발도 예외가 아니다.

아키텍처는 요소 사이에서 균형을 찾아야 하며, 일부를 포기하는 결단이 항상 필요하다. 중요한 것은, 무엇을 우선순위로 둘지 명확히 하고, 그에 따라 합리적인 선택을 하는 것이다. 희생할 수 없는 것과 희생해도 좋은 것을 명확히 하고, 그 조절 가능한 구간 사이에서 시스템 목표를 병립시키는 것이 적절한 결정이다. 즉, 원하는 것을 챙기고, 감당할 수 있는 대가를 치러라.

결론

모든 아키텍처는 비용을 치른다.

• 포트와 어댑터(Port and Adapter) 아키텍처는 각 인터페이스 확장성의 한계를 사전에 정하는 것이 비용이다.
• Restful은 멀티 리소스 처리가 어렵다는 대가를 치른다.
• 리눅스의 X Window 설계는 느린 GUI가 단점이고, MS 윈도우는 블루 스크린이 단점이다.
• MSA(MicroService Architecture)는 더 많은 통신 비용, 많은 운영 인력을 대가로 치른다.
• Monolithic 구조는 수평 확장 불가능이라는 한계가 있다.
• 비동기 IO는 이벤트 폴링(Event Polling) 매커니즘이 필수적으로 요구된다.

모범 사례를 차용하면서, 내가 치른 대가가 무엇인지 고민해 본 적 있는가? 만약 없다면, 후회할 확률이 절반이 넘을 수밖에 없다.

옷을 입는 것조차도 T.P.O.(Time, Place, Occasion)을 따져야 한다. 소프트웨어 수명은 평균적으로 5~10년이고, 그동안 아키텍처는 크게 변하기 어렵다.

만약, 7년 동안 옷 하나만 선택해서 입어야 한다면, 그저 남을 모방할 것인가?

See Also

• 소프트웨어 아키텍처는 확장보다 불변에 의해 결정된다 - 아키텍처 결정하기
• 불신의 코딩 vs 신뢰의 코딩 - 아키텍처를 포괄한 거시적 개발전략에 관한 의사 결정
• One Man Framework 가능성의 증명 - 비즈니스 흐름이 확정적일 때 가능한 것
• 디자인 패턴은 본래 고쳐 쓰는 것이다 - 디자인 패턴 역시 모방의 대상이 아니다.
• 직관을 따라야 읽기 좋고, 읽기 좋아야 고치기 좋다 - 전산학 지식의 효과가 간과 되는 지점

Author

HJ, Ph.D. / Software Architect
(js.seth.h@gmail.com)
https://js-seth-h.github.io/website/Biography/

Over 20 years in software development, focusing on design reasoning and system structure - as foundations for long-term productivity and structural clarity.

Researched semantic web and meta-browser architecture in graduate studies,
with an emphasis on structural separation between data and presentation.

Ph.D. in Software, Korea University
M.S. in Computer Science Education, Korea University
B.S. in Computer Science Education, Korea University