안녕하세요, 임리을입니다.
혹시 '아키텍처'라는 말을 들으면 어떤 생각이 드시나요? 많은 주니어 시절의 저를 포함해, '그거 그냥 폴더(디렉토리) 구조 잘 짜는 거 아니야?'라고 생각하는 경우가 많습니다. 실제로 많은 현업 프로젝트에서 '프로젝트 아키텍처'라는 이름으로 디렉토리 구조를 설명하기도 하죠.
저 역시 최근 새로운 프로젝트를 기획하며 이 익숙한 혼란과 다시 마주했습니다. 머릿속의 막연한 아이디어를 구체적인 설계로 옮기려니, 어디서부터 손대야 할지 막막했죠. '시스템은 어떻게 구성하지?', '소프트웨어의 핵심 원칙은 뭘로 잡아야 할까?', '그래서 폴더는 어떻게 나눠야 하지?'... 꼬리에 꼬리를 무는 질문들 속에서 헤매다 문득 깨달았습니다. 제가 이 용어들을 제대로 구분하지 못하고 있다는 사실을요.
그래서 프로젝트를 한 단계씩 구체화하는 동시에, 시스템 아키텍처, 소프트웨어 아키텍처, 프로젝트 구조라는 개념들을 하나씩 명확하게 정리해 나갔습니다.
오늘은 이 과정에서 건져 올린 인사이트를 공유해보고자 합니다.
결론부터: 시스템 > 소프트웨어 > 프로젝트
복잡한 설명에 앞서 핵심부터 말씀드리자면, 세 개념은 추상화 수준과 범위에 따라 명확한 계층을 이룹니다.
- 시스템 아키텍처: 최상위 레벨입니다. 하드웨어, 소프트웨어, 네트워크 등 눈에 보이는 모든 것을 포함한 전체 시스템의 큰 그림입니다.
- 소프트웨어 아키텍처: 시스템의 하위 집합으로, 오직 소프트웨어의 논리적인 구조와 동작 원칙에만 집중합니다.
- 프로젝트 구조: 가장 구체적인 레벨로, 코드와 파일을 어떤 디렉토리에 배치할지에 대한 실질적인 계획입니다.
아키텍처란 '사람들이 바꾸기 어렵다고 인식하는 것들'이다.— 마틴 파울러(Martin Fowler)가 그의 에세이 "Who Needs an Architect?"에서 설명한 핵심 개념[1]
한눈에 보는 상세 비교
이해가 쉽도록 가상의 'AI 블로그 포스팅 도우미' 프로젝트를 예시로 표를 정리해 보았습니다.
항목 (Item) | 시스템 아키텍처 (System Architecture) | 소프트웨어 아키텍처 (Software Architecture) | 프로젝트 구조 (Project Structure) |
관점 | 최상위(Top-level), 물리적+논리적 | 고수준(High-level), 논리적 | 저수준(Low-level), 물리적, 구체적 |
관심사 | "어떻게 통합되고 운영되는가?"
(전체 구성과 상호작용) | "무엇을(What), 왜(Why) 만드는가?"
(소프트웨어의 동작 원리와 설계 원칙) | "어떻게(How), 어디에(Where) 배치하는가?"
(코드의 물리적 배치와 관리) |
구성요소 | 사용자 PC, 서버, 클라우드 인프라, 네트워크 | 주요 컴포넌트, 계층(Layer), 데이터 흐름, API | 소스 코드 파일, 패키지, 디렉토리, 설정 파일 |
목표 | 시스템의 전체적인 성능, 신뢰성, 운영 효율 | 소프트웨어의 품질
(확장성, 안정성, 보안 등) | 개발 생산성
(가독성, 팀 협업, 빌드 효율성) |
가상 프로젝트 예시
(AI 블로그 포스팅 도우미) | - 사용자 PC에서 데스크톱 앱으로 실행
- 글감 생성을 위해 OpenAI 클라우드 API 활용
- 설정 및 백업 데이터는 클라우드 스토리지(Dropbox 등)와 동기화 | - 포스트 데이터는 로컬 Markdown 파일로 관리
- AI 기능은 REST API를 통해 외부 서비스 호출
- 핵심 기능은 작성모듈, AI모듈, 파일동기화모듈로 분리 | - 소스 코드는 src/ 디렉토리에 위치
- 각 모듈은 src/modules/ 하위 디렉토리로 구현
- 설정 파일은 config/ 디렉토리에서 관리 |
그래서, 이걸 왜 구분해야 할까요?
"굳이 이렇게 피곤하게 나눠야 하나?" 싶을 수도 있습니다. 하지만 이 구분이 중요한 이유는 각 설계가 프로젝트의 다른 차원에 영향을 미치기 때문입니다.
- 시스템 아키텍처는 프로젝트의 물리적 기반과 제약을 결정합니다. 아무리 소프트웨어가 뛰어나도 네트워크 대역폭이 부족하면 제 성능을 낼 수 없는 것처럼, 시스템 아키텍처가 부실하면 프로젝트 전체가 흔들립니다.
- 소프트웨어 아키텍처는 시스템의 논리적 품질과 생명 주기를 결정합니다. 흔히 말하는 확장성, 안정성, 보안이 여기서 결정됩니다. 기초가 부실한 건물과 같아서, 한번 잘못 설계되면 나중에 바로잡기가 정말 힘듭니다.
- 프로젝트 구조는 개발 효율성과 지속가능성을 결정합니다. 구조가 엉망이면 코드를 찾기 어렵고, 수정의 영향 범위를 파악하기 힘들며, 새로운 팀원이 적응하는 데 고통받습니다. 설계도는 훌륭하지만 자재와 인력이 뒤죽박죽인 건설 현장과 같죠.
마치며
결론적으로, 이 세 가지는 서로 다른 역할을 수행하는 상호 보완적인 관계이지, 동의어가 아닙니다.
- 시스템 아키텍처는 건물이 들어설 '땅과 환경'을 분석하는 일이고,
- 소프트웨어 아키텍처는 그 땅 위에 세워질 건물의 '설계도'를 그리는 것이며,
- 프로젝트 구조는 설계도에 따라 자재를 효율적으로 배치하고 관리하는 '현장 계획'과 같습니다.
저 역시 아직 배워가는 입장이지만, 이제는 '아키텍처'라는 말을 들으면 '시스템, 소프트웨어, 프로젝트 구조 중 어떤 관점의 이야기일까?'하고 잠시 멈춰 생각하게 되었습니다. 이 글을 읽으신 여러분께도 이런 생각의 전환을 가져다주는 작은 계기가 되었기를 바랍니다.
[1]: Martin Fowler, "Who Needs an Architect?", 2003. 이 글에서 마틴 파울러는 아키텍처를 "things that people perceive as hard to change"라고 정의할 수 있다고 설명합니다.
Share article
