IT에서 아키텍트(Architect)는 요구사항과 제약을 바탕으로 시스템의 구조와 주요 기술 결정을 설계하고, 구현·운영에서도 그 결정이 유효한지 확인하는 역할입니다. 건축가라는 일반적인 뜻과 구분해야 합니다. 개발자와 별개의 자격 등급을 뜻하지 않으며, 작은 팀에서는 개발자가 아키텍트의 책임도 함께 맡습니다.
개발자와 아키텍트는 무엇이 다른가요?
구현에서는 “이 기능을 어떻게 동작시킬까?”를, 아키텍처에서는 “어떤 책임으로 나누고 어떤 제약을 감수할까?”를 더 넓게 살펴봅니다. 두 일은 겹칩니다. 코드와 운영 결과를 확인하지 않는 설계만으로 시스템 품질을 판단할 수는 없습니다.
| 관점 | 주로 확인하는 것 | 남길 결과 |
|---|---|---|
| 기능 구현 | 입력·출력, 예외, 테스트 | 코드와 검증 결과 |
| 시스템 설계 | 모듈 경계, 장애 전파, 가용성·비용 | 구성도, 결정 이유, 실패 조건 |
SA·TA·AA·EA·DA 역할 비교
다음은 책임을 이해하기 위한 흔한 구분입니다. 조직마다 명칭과 범위가 다르고, 약어도 겹칠 수 있으므로 채용 공고나 팀의 실제 책임을 함께 확인하세요.
- SA(Solution Architect): 서비스 요구사항과 외부 연동을 포함한 전체 해결 방안.
- TA(Technical Architect): 배포·네트워크·관측 등 기술 기반과 운영 기준.
- AA(Application Architect): 애플리케이션의 모듈·API·트랜잭션 경계.
- EA(Enterprise Architect): 조직 전체 시스템과 사업 방향의 정렬.
- DA(Data Architect): 데이터 모델, 흐름, 소유권과 관리 기준.
주문 서비스로 보는 설계 과정
“결제를 중복 처리하면 안 된다”는 요구가 있다고 가정해 봅시다. SA는 결제 사업자 연동과 장애 시나리오를, TA는 배포·알림·복구 경로를, AA는 주문 상태 전이와 중복 요청 처리를 검토할 수 있습니다. 특정 제품을 먼저 고르기보다 실패했을 때의 동작을 정하는 편이 요구사항을 검증하기 쉽습니다.
- 동일 주문의 재시도, 결제 응답 지연 등 실패 조건을 적습니다.
- 동기 처리와 비동기 처리의 대안을 비교합니다.
- 선택한 방식의 데이터 정합성·복잡도·운영 비용을 기록합니다.
- 중복 요청과 장애 복구 테스트로 설계 가정을 확인합니다.
아키텍트의 결과물을 확인하는 질문
구성도에 기술 이름만 있는지, 선택 이유와 포기한 대안도 있는지 보세요. 담당자가 바뀌어도 “왜 이렇게 만들었는가”를 설명할 수 있어야 후속 변경에서 같은 실수를 줄일 수 있습니다. AWS Well-Architected는 이런 품질 검토의 한 사례이며, 위 직함 분류를 표준으로 정의하는 문서는 아닙니다.
참고 자료
기존 기록의 화면과 도식
최초 발행 당시의 참고 자료입니다. 최신 설정은 위 설명과 해당 버전의 공식 문서를 확인하세요.
