소프트웨어 아키텍처 (Software Architecture)

소프트웨어 아키텍처(Software Architecture)는 시스템의 주요 구성 요소와 책임, 요소 사이의 관계와 상호작용을 정하는 구조입니다. 화면, 서버, 데이터 저장소를 어떻게 나누고 연결할지가 대표적인 설계 대상입니다. 사용하는 기술의 이름뿐 아니라 데이터가 이동하는 경로와 변경·장애가 다른 부분에 미치는 영향까지 함께 다룹니다.

구성 요소와 책임의 경계

CMU 소프트웨어공학연구소의 아키텍처 설명은 시스템 전체의 구조와 동작에 관한 설계 결정을 아키텍처로 설명합니다. 수정 가능성, 가용성, 보안 같은 특성을 구현 뒤에만 확인하지 않고 설계 단계에서 분석하는 데 쓰입니다. 기능 목록이 시스템이 무엇을 하는지 말한다면, 아키텍처는 그 기능을 어떤 요소들이 맡고 어떻게 협력할지 설명합니다.

문서 서비스를 만든다면 화면의 입력 처리, 계정 권한 확인, 본문 저장, 검색 색인 갱신을 나누어 볼 수 있습니다. 어느 부분이 원본 데이터를 보관하고 다른 부분은 어떤 경로로 접근하는지 정하면 변경의 영향을 추적하기 쉽습니다. 서버나 라이브러리 이름을 나열해도 각각이 맡는 일은 드러나지 않을 수 있습니다. 선으로 연결한 요소 사이에 어떤 요청과 데이터가 오가는지도 표시합니다.

코드의 폴더 구조와 실행 중인 시스템의 구조는 서로 다른 관점입니다. 여러 폴더의 코드가 하나의 서버 프로그램으로 실행될 수 있고, 하나의 저장소에서 여러 서비스를 배포할 수도 있습니다. 배포 위치와 데이터 흐름을 따로 확인하면 폴더가 나뉘었다는 이유만으로 장애나 권한 경계도 분리됐다고 오해하는 일을 줄일 수 있습니다.

아키텍처 유형과 선택 조건

마이크로소프트의 아키텍처 유형 안내는 계층형, 웹·큐·워커 등 공통 특성을 가진 구조를 소개합니다. 계층형 구조는 표현, 업무 로직, 데이터 접근처럼 책임을 나누고, 웹·큐·워커 구조는 요청 처리와 시간이 오래 걸리는 작업을 분리합니다. 유형 이름 자체보다 서비스가 처리하는 작업과 필요한 응답 방식에 맞는지 보는 것이 선택의 기준입니다.

마이크로서비스 아키텍처 안내는 작고 독립적인 서비스가 업무 능력을 맡고 API로 소통하는 구성을 설명합니다. 각 서비스를 독립적으로 배포할 수 있는 장점이 있지만 서비스 간 통신과 데이터 일관성, 전체 동작 관찰 같은 문제가 함께 생깁니다. 코드를 작은 파일로 나누는 것만으로 이 실행 구조가 만들어지지는 않습니다.

같은 기능도 팀 규모와 변경 빈도, 운영 능력에 따라 적합한 구조가 달라집니다. 초기 서비스에서 모든 기능을 별도 서비스로 나누면 개발할 코드보다 배포와 연결을 관리하는 일이 커질 수 있습니다. 반대로 독립적으로 자주 바뀌는 부분이 한 배포에 묶여 있으면 변경의 영향이 넓어질 수 있습니다. 어떤 문제를 줄이려는 선택인지 기록하면 구조를 다시 평가할 기준이 생깁니다.

변경과 장애를 따라 보는 검증

아키텍처를 검토할 때는 정상 요청 하나가 들어와 결과를 돌려주기까지의 경로를 따라가 봅니다. 그다음 외부 서비스가 느려지거나 저장이 실패했을 때 어느 부분이 기다리고 어느 결과가 남는지 살핍니다. 구성 요소 하나가 멈췄을 때 다른 기능까지 영향을 받는 범위가 드러납니다. 그림이 연결돼 있다는 사실만으로 실패 처리까지 설계됐다고 보지 않습니다.

설계 결정에는 선택한 방식과 이유, 고려한 다른 방식, 받아들인 제약을 함께 남길 수 있습니다. 검색용 데이터 복사본을 두었다면 조회 속도를 얻는 대신 갱신 지연을 어떻게 다룰지 설명하는 식입니다. 나중에 요구가 바뀌어도 당시의 조건을 알면 같은 논의를 처음부터 반복할 필요가 줄어듭니다. 문서는 실제 구현이 바뀔 때 함께 확인해야 유효한 설명으로 남습니다.

AI 코딩 도구가 부분 기능을 빠르게 만들더라도 그 변경이 전체 책임과 데이터 경계를 따르는지 검토합니다. 권한 검사를 화면에만 추가하거나 여러 경로에서 같은 데이터를 따로 갱신하면 당장의 기능은 보여도 일관성이 깨질 수 있습니다. 변경한 부분의 입력·출력과 호출 경로, 실패 시 결과를 기존 구조와 대조하면 테스트해야 할 범위가 구체적이 됩니다.