시스템아키텍처 이해와 활용

1. 업무 요구 — 중단을 막아야 할 업무와 허용 지연을 정한다

시스템아키텍처는 서비스를 제공하는 프로그램·데이터·서버 등을 어떻게 구성하고, 서로 연결해 동작하게 할지 정하는 것입니다. 쇼핑몰이라면 고객이 누른 주문 버튼이 주문 처리 프로그램으로 연결되고, 주문 내역이 데이터베이스에 저장되도록 전체 구조를 설계하는 일입니다.

교재에서는 이를 넓은 의미와 좁은 의미로 나눕니다. 넓게 보면 프로그램의 역할과 연결을 정하는 응용 아키텍처, 데이터를 어떤 구조로 저장하고 연결할지 정하는 데이터 아키텍처, 서버·네트워크와 실행에 필요한 소프트웨어를 배치하는 기술 아키텍처를 함께 다룹니다. 좁게 말할 때는 이 가운데 기술 아키텍처를 뜻합니다.

이런 구조를 설계하려면 각 기능을 누가 어떤 상황에서 쓰는지부터 알아야 합니다. 주문·결제가 멈추면 고객은 구매를 완료하지 못하지만, 관리자용 월간 통계는 잠시 늦게 조회되더라도 당장 구매를 막지는 않습니다. 이 차이를 알아야 각 기능에 필요한 처리 속도와 복구 시간을 정할 수 있습니다.

예를 들어 주문을 처리하던 서버가 고장 나도 주문을 계속 받으려면, 다른 서버가 그 일을 이어받도록 준비할 수 있습니다. 그러려면 서버를 추가로 운영하고, 실제로 일을 넘겨받을 수 있는지 점검해야 합니다. 비용과 관리할 일이 늘어나므로, 기능이 멈췄을 때 생기는 문제의 크기를 살펴보고 어디까지 대비할지 정합니다.

생각해 볼 질문
이 식당이 종이 주문으로 버틸 수 있는 시간과 주문량을 먼저 확인해야 하는 이유는 무엇이며, 주문·결제와 월간 통계의 복구 목표는 왜 달라야 합니까?

2. 레이어와 티어 — 역할 분리와 물리 배치를 구분한다

레이어는 프로그램을 맡은 일에 따라 나눈 구분입니다. 예약 사이트라면 화면을 보여 주는 부분, 빈자리가 있는지 판단하는 부분, 예약 내역을 저장하는 부분으로 나눌 수 있습니다.

티어는 이렇게 나눈 처리를 실제로 어디에 배치했는지 나타내는 구분입니다. 역할이 세 개라고 서버도 반드시 세 대인 것은 아닙니다. 여러 역할을 한 서버에서 실행할 수도 있고, 처리 프로그램과 데이터베이스를 서로 다른 서버에 둘 수도 있습니다.

서버를 나누면 필요한 부분만 늘릴 수 있지만, 서버 사이의 통신과 장애도 관리해야 합니다. 이용자가 적은지, 어떤 처리가 몰리는지, 팀이 관리할 수 있는지를 보고 배치 방법을 정합니다.

생각해 볼 질문
화면·예약 판단·저장을 구분해 작성했다는 사실만으로 서버가 세 대라고 말할 수 있나요? 레이어와 티어를 구분해 설명하세요.

3. 경계와 의존성 — 시스템 변경이 다른 시스템에 미치는 영향을 줄인다

인터페이스는 프로그램끼리 정보를 주고받을 때 지키는 약속입니다. 주문 번호를 보내면 배송 상태를 돌려주는 것처럼, 무엇을 보내고 어떤 결과를 받을지 정합니다. 여기에는 값의 형식과 실패했을 때의 응답도 포함됩니다.

의존성은 한 부분이 다른 부분에 기대어 동작하는 관계입니다. 배송 프로그램이 주문 데이터베이스의 특정 열을 직접 읽는다면, 그 열의 이름이 바뀌는 것만으로 배송도 실패할 수 있습니다.

필요한 정보를 정해진 인터페이스로 제공하면 내부 구조를 바꿀 때 영향을 줄일 수 있습니다. 다만 인터페이스 자체를 바꿀 때는 이용하는 프로그램을 확인하고, 기존 방식도 함께 지원할 기간을 정해야 합니다.

생각해 볼 질문
주문팀이 주소 형식을 바꾸기 전에 배송팀과 무엇을 합의해야 할까요? 보내는 값과 전환 기간을 들어 설명하세요.

4. 결함 허용과 격리 — 장애의 확산을 막는다

결함 허용은 시스템의 일부가 고장 나도 정해 둔 기능을 계속 제공하도록 만드는 것입니다. 결함 격리는 그 고장이 다른 부분까지 영향을 주지 않도록 막는 것입니다.

예를 들어 결제 화면이 추천 상품 서버의 답을 끝없이 기다리면, 추천 서버의 문제가 결제 중단으로 이어집니다. 추천은 일정 시간만 기다리고 결과가 없으면 생략하도록 정할 수 있습니다. 이것은 결제에 꼭 필요하지 않은 기능의 실패를 분리한 예입니다.

모든 실패를 생략해도 되는 것은 아닙니다. 실제 결제 승인에 실패했다면 결제 완료라고 안내해서는 안 됩니다. 계속할 기능과 중단해야 할 기능을 업무 기준으로 구분해야 합니다.

생각해 볼 질문
추천 목록 조회 실패와 예약 저장 실패에 같은 안내를 해도 될까요? 계속할 수 있는 일의 차이를 설명하세요.

5. 분산 데이터의 일관성 — 여러 시스템의 값이 다를 때 다시 맞춘다

주문 서버와 창고 서버처럼 여러 곳에서 데이터를 나눠 관리하면, 한쪽의 변경이 다른 쪽에 늦게 도착할 수 있습니다. 주문 화면에는 취소로 보이는데 창고 화면에는 아직 배송 준비로 보이는 식입니다.

최종 일관성은 새 변경이 더 생기지 않고 변경 내용이 정상적으로 전달되면, 잠시 달랐던 데이터가 결국 같은 상태에 도달하는 성질입니다. 기다리기만 하면 언제나 저절로 맞는다는 뜻은 아닙니다. 전달 실패를 찾아 다시 반영할 방법도 필요합니다.

어떤 정보는 잠시 달라도 되지만, 품절 상품의 판매나 취소된 상품의 출고처럼 되돌리기 어려운 행동은 별도의 확인이 필요합니다. 어느 시점에 어떤 상태를 확인할지 업무 규칙으로 정합니다.

생각해 볼 질문
취소 내용이 나중에 창고로 전달된다는 이유만으로 바로 출고해도 될까요? 출고 전에 확인할 정보를 설명하세요.

6. 성능과 용량 — 사용자의 기다림에서 출발한다

성능은 요청을 얼마나 빨리 처리하는지, 일정 시간에 얼마나 많은 일을 처리하는지 등으로 살펴봅니다. 용량계획은 필요한 성능을 내기 위해 서버·메모리·저장공간 등을 얼마나 준비할지 계획하는 일입니다. 규모산정은 그 요구를 구체적인 장비나 자원의 양으로 계산하는 일입니다.

먼저 사용자가 어떤 작업에서 얼마나 기다리는지 측정해야 합니다. 검색은 빨라도 결제만 느릴 수 있으므로 전체 평균 하나로 판단하면 문제를 놓칠 수 있습니다.

그다음 가장 오래 걸리는 단계를 찾습니다. 데이터베이스에서 필요 없는 자료까지 읽느라 느리다면 서버를 추가하기 전에 조회 범위를 줄이는 방법을 검토할 수 있습니다. 바꾼 뒤에는 같은 조건으로 다시 측정해 효과를 확인합니다.

생각해 볼 질문
전체 평균이 2초라는 정보만으로 결제 속도도 충분하다고 판단할 수 있나요? 예시의 수치를 이용해 설명하세요.

7. 관측 가능성 — 기록과 수치로 실패한 처리 단계를 찾는다

로그는 프로그램이 언제 무엇을 했는지 남기는 기록입니다. 처리 시간이나 실패 건수 같은 수치도 함께 보면 시스템 내부에서 일어난 일을 추적할 수 있습니다. 이런 기록과 수치로 내부 상태를 알아낼 수 있는 정도를 관측 가능성이라고 합니다.

주문 하나가 웹 서버, 주문 서버, 결제 서버를 지나간다면 각 서버의 기록에 같은 요청 번호를 남길 수 있습니다. 그러면 담당자가 같은 주문의 기록을 연결해 어느 단계에서 오래 걸렸는지 찾을 수 있습니다.

서버가 켜져 있다는 것과 주문이 성공했다는 것은 다릅니다. 실제 완료 여부까지 확인해야 합니다. 다만 분석에 필요하지 않은 비밀번호나 결제 비밀정보를 기록에 넣지는 않습니다.

생각해 볼 질문
세 서버가 남긴 기록의 시간이 비슷하다는 것만으로 같은 주문이라고 볼 수 있나요? 기록을 연결할 정보는 무엇인가요?

8. RTO와 RPO — 복구 시간과 손실 목표를 검증한다

RTO는 장애가 난 뒤 서비스를 다시 사용할 수 있을 때까지 허용하는 목표 시간입니다. RPO는 장애가 났을 때 어느 시점까지의 데이터를 복구해야 하는지 정한 목표이며, 허용할 데이터 손실을 시간으로 나타냅니다.

예를 들어 오전 10시에 장애가 났고 RTO가 1시간이라면 오전 11시까지 복구하는 것이 목표입니다. RPO가 10분이라면 적어도 오전 9시 50분 시점까지의 데이터를 복구할 수 있어야 합니다. 복구에 걸린 시간과 잃을 수 있는 데이터의 시간 범위는 서로 다른 기준입니다.

백업 파일이 있다는 사실만으로 이 목표를 충족한 것은 아닙니다. 설정과 필요한 키도 준비하고, 실제로 복원해 조회·주문 같은 기능이 동작하는지 시험해야 합니다. 매일 백업한다는 계획만으로 10분 RPO를 보장할 수는 없습니다.

생각해 볼 질문
10시 장애 후 10시 40분에 9시 자료로 복구했다면 RTO 1시간과 RPO 10분 중 무엇을 지켰고 무엇을 어겼습니까?

9. 안전한 변경 — 운영 상태에서 검증한다

형상관리는 프로그램·설정처럼 관리할 대상을 정하고, 어떤 버전을 기준으로 삼았는지와 무엇을 왜 바꿨는지 기록하는 활동입니다. 배포는 새 프로그램이나 설정을 실제 서비스에 적용하는 일입니다.

시험 환경에서 통과했어도 실제 이용자의 데이터와 사용 방식은 다를 수 있습니다. 일부 이용자나 서버부터 새 버전을 적용하면 문제를 발견했을 때 영향을 받은 범위를 줄일 수 있습니다. 이때 이전 버전과 오류·응답 시간을 비교합니다.

문제가 어느 정도면 배포를 중단할지, 어떻게 이전 버전으로 돌아갈지도 미리 정합니다. 새 버전이 데이터 형식까지 바꿨다면 프로그램만 되돌려서는 해결되지 않을 수 있으므로 이전 버전이 그 데이터를 읽을 수 있는지도 확인합니다.

생각해 볼 질문
새 버전이 데이터 형식을 바꿨다면 프로그램 파일만 이전 버전으로 바꿔도 될까요? 함께 확인해야 할 것을 설명하세요.

10. 총비용과 선택의 근거 — 도입 이후까지 계산한다

시스템 비용에는 처음 사거나 만드는 비용뿐 아니라 사용하는 동안 관리하고, 나중에 다른 시스템으로 옮기거나 폐기하는 비용도 포함됩니다. 월 사용료가 싸더라도 백업과 장애 대응에 많은 시간이 들면 전체 비용은 커질 수 있습니다.

예를 들어 직접 데이터베이스를 운영하면 설치·업데이트·복구를 팀이 맡습니다. 업체가 운영하는 서비스를 이용하면 일부 관리 작업이 줄지만 사용료와 기능 제한, 지원 범위를 확인해야 합니다.

비교할 때는 같은 사용 기간과 예상 사용량을 기준으로 삼습니다. 무엇을 직접 맡을 수 있고 어떤 비용을 감수했는지 기록해 두면 이용자가 늘거나 요금이 바뀔 때 다시 판단하기 쉽습니다.

생각해 볼 질문
월 사용료가 싼 서비스를 골랐는데 야간 대응이 늘었습니다. 처음 비용 비교에서 무엇을 빠뜨렸을 수 있나요?

11. 용량 계획 — 평소와 급증 상황을 나눠 본다

서버가 감당해야 할 일의 양을 부하라고 합니다. 용량을 계획할 때는 하루 평균뿐 아니라 가장 바쁜 시간에 어떤 요청이 얼마나 몰리는지 확인해야 합니다.

열차 명절 승차권 예매가 오전 7시에 열리면 많은 고객이 동시에 로그인하고 좌석을 조회할 수 있습니다. 화면을 보내는 서버만 늘려도 신청 내역을 저장하는 데이터베이스가 밀리면 전체 처리는 빨라지지 않을 수 있습니다. 전체 흐름의 속도를 제한하는 부분을 병목이라고 합니다.

로그인·조회·저장 등 실제 사용 순서를 따라 요청을 보내는 부하 시험으로 병목을 찾습니다. 그 결과를 바탕으로 자원을 늘리거나 불필요한 처리를 줄이고 다시 시험합니다.

생각해 볼 질문
웹 서버를 늘려도 신청이 빨라지지 않는다면 어느 처리 단계를 확인할까요? 요청이 저장될 때까지의 흐름으로 설명하세요.

12. 캐시 — 저장한 값이 원본보다 오래됐을 때를 대비한다

캐시는 자주 사용하는 값을 빠르게 보여 주려고 따로 저장해 다시 쓰는 공간입니다. 상품 정보를 매번 데이터베이스에서 읽지 않고 캐시에서 가져오면 조회 시간을 줄일 수 있습니다.

대신 원본과 캐시가 다른 값을 가질 수 있습니다. 원본의 할인 행사가 끝났는데 캐시가 갱신되지 않으면 화면에는 여전히 할인 가격이 나옵니다. 언제 새 값으로 바꾸고 얼마나 오래 보관할지 정해야 하는 이유입니다.

화면에 보여 주는 정보와 거래를 확정할 때 사용하는 정보도 구분합니다. 결제할 때는 정해진 가격 기준을 확인하고 표시 가격과 다르면 고객에게 알려야 합니다. 이 예의 서비스 데이터 캐시는 CPU 안의 캐시와 위치·관리 방법이 다릅니다.

생각해 볼 질문
캐시의 보관 기한을 정하면 그 기간 안에는 언제나 최신 가격이라고 할 수 있나요? 원본이 바뀌는 시점을 생각해 보세요.

13. 큐와 비동기 처리 — 접수와 완료를 구분한다

큐는 먼저 들어온 자료를 먼저 꺼내는 자료구조입니다. 처리할 작업을 큐에 넣어 두면 다른 작업자가 순서대로 꺼내 실행할 수 있습니다. 비동기 처리는 요청한 쪽이 작업의 최종 완료를 계속 기다리지 않고 다음 일을 할 수 있게 하는 방식입니다.

예를 들어 예약 저장은 즉시 끝내고 안내 메일은 큐에 넣어 나중에 보낼 수 있습니다. 사용자는 메일 발송 때문에 예약 결과를 오래 기다리지 않아도 됩니다.

그러나 큐에 들어갔다는 것은 작업이 끝났다는 뜻이 아닙니다. 접수·처리 중·완료·실패를 구분하고 실패한 작업을 찾을 방법이 필요합니다. 재시도할 때 같은 안내가 중복 발송되지 않는지도 확인해야 합니다.

생각해 볼 질문
보고서 작업을 큐에 넣자마자 ‘파일 생성 완료’라고 표시하면 왜 문제가 되나요? 접수와 완료를 나눠 설명하세요.

14. QoS와 과부하 제어 — 처리량을 넘는 요청을 제한한다

QoS는 통신 서비스의 품질을 필요한 수준으로 관리하는 개념입니다. 데이터가 도착하기까지 걸리는 지연, 지연 시간이 들쑥날쑥한 정도인 지터, 보낼 수 있는 양과 속도 등을 살펴봅니다. 영상 통화에서 전달이 고르지 않으면 소리가 끊기는 상황을 떠올릴 수 있습니다.

네트워크가 처리할 수 있는 양은 한정되어 있습니다. 교재에서는 어떤 데이터를 먼저 보낼지 정하거나, 보내는 양을 제한하거나, 필요한 자원을 예약하는 방법을 다룹니다.

이를 서비스 요청에 적용해 생각하면, 요청이 몰릴 때 무조건 모두 받아 기다리게 하기보다 일부를 제한하는 선택이 가능합니다. 실패했다고 즉시 무제한 재시도하면 요청이 더 늘어나므로 재시도 횟수와 간격도 정해야 합니다.

생각해 볼 질문
음성 통화에 우선순위를 주면 파일 업로드에는 어떤 대가가 생기며, 두 업무의 지연 허용 수준은 왜 다릅니까?

15. 고가용성과 페일오버 — 이중화한 서버가 함께 멈출 원인을 찾는다

가용성은 필요할 때 서비스를 사용할 수 있는 정도입니다. 고가용성은 장애가 생겨도 서비스 중단을 줄이도록 구성하는 것이며, 고장 난 서버의 일을 다른 서버가 맡도록 전환하는 것을 페일오버라고 합니다.

서버를 두 대 두었다고 자동으로 고가용성이 확보되는 것은 아닙니다. 두 서버가 같은 전원 장치나 저장소 하나를 사용하면 그 공통 장비가 고장 났을 때 함께 멈출 수 있습니다.

장애를 어떻게 발견하고 어느 서버로 전환할지 정한 뒤 실제 전환을 시험합니다. 한 서버가 다른 서버의 일까지 맡았을 때 필요한 처리량을 감당하는지도 확인해야 합니다.

생각해 볼 질문
두 서버가 같은 저장소 하나를 쓰면 어떤 장애를 막지 못할까요? 공통으로 의존하는 장비를 찾아 설명하세요.

16. 네트워크 경로 — 연결의 모든 단계를 확인한다

브라우저에서 사이트를 열 때는 여러 단계가 필요합니다. 도메인 이름에 해당하는 서버 주소를 찾고, 네트워크를 통해 연결한 뒤, 서버의 프로그램이 요청을 처리해야 합니다. 한 단계의 성공이 전체 성공을 뜻하지는 않습니다.

예를 들어 ping에 응답하더라도 웹 서버 프로그램이 멈췄다면 페이지는 열리지 않을 수 있습니다. ping은 네트워크 수준의 응답을 확인하는 도구이며 로그인이나 주문 기능까지 시험하는 도구는 아닙니다. 반대로 ping을 차단한 서버도 웹 접속은 허용할 수 있습니다.

담당자는 문제가 생긴 사용자의 위치에서 어느 단계까지 성공하는지 확인합니다. 서버 주소 확인, 접속을 허용하는 규칙, 통신 경로, 인증서와 프로그램의 응답을 나누어 조사하면 엉뚱한 코드를 고치는 일을 줄일 수 있습니다.

생각해 볼 질문
ping 성공만으로 결제가 된다고 말할 수 있나요? 네트워크 연결 이후에도 필요한 단계를 설명하세요.

17. 환경 재현 — 새 서버에서도 같은 서비스를 실행하게 한다

환경은 프로그램이 실행되는 운영체제, 필요한 라이브러리, 설정 등을 함께 가리킵니다. 프로그램 파일이 같아도 시간대나 라이브러리 버전이 다르면 결과가 달라질 수 있습니다.

환경 재현은 새 서버에서도 필요한 조건을 다시 갖춰 같은 서비스를 실행할 수 있게 하는 일입니다. 설치할 버전과 설정 순서, 변경 이유를 문서나 자동화 절차에 남깁니다. 이는 관리할 대상과 변경을 기록하는 형상관리의 원리를 운영에 적용한 것입니다.

문서가 있다는 사실만으로 충분하지는 않습니다. 새 서버에서 그 절차를 실제로 따라 해 누락을 찾습니다. 비밀번호 같은 비밀정보는 공개 설정 파일에 적지 않고 별도로 전달·보관합니다.

생각해 볼 질문
같은 프로그램을 복사했는데 결과가 다르다면 코드 외에 어떤 실행 조건을 비교해 볼 수 있나요?

18. 데이터 이전 — 옮긴 뒤 업무가 이어지는지 확인한다

데이터 이전은 기존 시스템의 자료를 새 시스템으로 옮기는 일입니다. 복사가 끝났는지만 보지 않고 새 시스템에서 실제 업무를 계속할 수 있는지 확인해야 합니다.

옮기는 동안 기존 시스템을 계속 사용하면 새 주문이나 취소가 추가됩니다. 처음 복사한 자료에는 그 변경이 없으므로, 이후 변경분을 어떻게 옮길지와 어느 시점부터 새 시스템을 사용할지 정해야 합니다.

건수만 같아도 내용이 다를 수 있습니다. 주문 금액이나 상태를 대조하고 실제 조회·수정도 시험합니다. 문제가 생겨 기존 시스템으로 돌아갈 때는 새 시스템에서 받은 주문을 어떻게 처리할지도 준비해야 합니다.

생각해 볼 질문
복사한 주문 건수가 맞아도 금액이나 상태가 다를 수 있나요? 건수 외에 확인할 내용을 두 가지 말해 보세요.

19. 외부 서비스 의존 — 공급자의 실패도 준비한다

사이트는 문자 발송이나 지도 검색처럼 다른 업체의 기능을 이용할 수 있습니다. 그 업체의 응답이 있어야 내 기능도 끝난다면, 내 서비스가 외부 서비스에 의존하는 것입니다.

SLA는 업체와 고객이 서비스의 범위·품질·측정 방법 등을 정한 합의입니다. SLM은 약속한 수준을 지키는지 계속 확인하고 관리하는 일입니다. 약속이 있다고 해서 장애가 절대 나지 않는 것은 아니므로 사용량 제한과 실패 때의 행동도 알아야 합니다.

예를 들어 주문 저장 뒤 보내는 안내 문자는 잠시 늦출 수 있는지 검토할 수 있습니다. 반면 본인 확인 문자가 꼭 필요한 절차라면 문자 없이 완료 처리하면 안 됩니다. 외부 기능이 맡은 일을 보고 대안을 정합니다.

생각해 볼 질문
주문 안내 문자와 로그인 인증 문자의 발송 실패에 같은 대안을 써도 될까요? 두 문자가 하는 일의 차이를 설명하세요.

20. 운영 준비 — 담당자가 판단할 수 있게 인계한다

운영은 서비스를 공개한 뒤 상태를 점검하고 문제가 생기면 대응하는 일입니다. 개발자가 기능을 완성했더라도 운영 담당자가 장애에 대응할 수 없다면 공개 준비가 끝난 것은 아닙니다.

운영 매뉴얼에는 정상 상태를 확인하는 방법, 경보가 뜻하는 상황, 먼저 할 점검, 조치할 수 있는 범위를 적습니다. 직접 판단하기 어려울 때 누구에게 어떤 정보를 전달할지도 정합니다.

절차를 넘긴 뒤 담당자가 직접 연습하도록 해야 빠진 설명을 찾을 수 있습니다. 예를 들어 재시작하면 처리 중인 주문이 어떻게 되는지 모른다면 무조건 재시작하라는 안내는 부족합니다.

생각해 볼 질문
‘문제가 생기면 서버를 재시작하세요’라는 한 줄에서 무엇이 빠졌나요? 판단 조건과 업무 영향을 들어 설명하세요.