86. 프로세스 뷰 (Process View) - 동시성, 동기화, 성능 설계 도면

⚠️ 이 문서는 소프트웨어 시스템을 4+1개의 관점으로 해부하는 필립 크루첸의 모델 중에서, 정적으로 멈춰있는 코드(클래스)나 기계(서버) 껍데기를 보는 것을 넘어, **시스템이 실제로 램(RAM)에 올라가서 살아서 돌아갈 때, 수십만 명의 접속자가 몰렸을 때 1번 스레드와 2번 스레드가 DB를 서로 차지하려고 싸우다 터지는 '교착 상태(Deadlock)'를 막고 속도(성능)를 보장하기 위해 그리는 '살아 움직이는 동적 생태계 도면인 프로세스 뷰'**를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 시스템의 '정지 화면(사진)'이 아니라 '동영상(Video)'을 캡처한 도면이다. 소스코드가 컴파일되어 OS 위에서 실행되는 런타임(Runtime) 환경에서, 프로세스와 스레드(Thread)들이 시간 순서대로 어떻게 병렬로 달리고 통신하는지를 까발린다.
  2. 가치: "왜 개발자 PC에서는 잘 되던 결제 시스템이 1만 명 트래픽이 몰리는 운영 서버에서는 응답 대기로 서버가 뻗어버릴까?"라는 시스템 통합자(SI)와 성능 테스터들의 가장 끔찍한 악몽(동시성 이슈, 병목)을 사전에 찾아내어 박살 내는 유일한 백신이다.
  3. 기술 체계: 스레드 1과 스레드 2가 시간에 따라 서로 데이터를 던지고 대기하는 핑퐁 과정을 그리는 **시퀀스 다이어그램(Sequence Diagram)**과, 시스템의 상태가 [대기] $\rightarrow$ [처리 중] $\rightarrow$ [완료]로 변하는 것을 그리는 **상태 다이어그램(State Diagram)**이 핵심 무기로 쓰인다.

Ⅰ. 정적 도면의 한계와 런타임(Runtime)의 공포

설계도상 예쁜 집이라도, 1만 명이 동시에 화장실을 쓰면 배관이 터진다.

  1. 논리 뷰(Logical View)의 태생적 장님 현상:
    • 앞서 배운 논리 뷰에서는 [주문 클래스] - [결제 클래스] - [DB 객체]를 예쁘게 선으로 묶어놨다.
    • 이 그림은 코드가 디스크에 저장된 '죽은 상태(정적)'의 뼈대만 보여줄 뿐, 실제 고객 1만 명이 동시에 결제 클래스를 때렸을 때 메모리 안에서 어떤 지옥도가 펼쳐지는지 단 1%의 정보도 주지 않는다.
  2. 프로세스 뷰의 등장 목적 (비기능적 요구사항 해결):
    • 시스템이 '무엇(What)'을 하냐가 아니라, '어떻게(How fast, How safe)' 버텨낼 것인가를 증명해야 한다.
    • 동시성 (Concurrency): 1번 스레드와 2번 스레드가 똑같은 비행기 좌석 1개를 동시에 예약(Update)하려 할 때 데이터가 꼬이지 않도록 락(Lock)을 거는 타이밍.
    • 성능 및 확장성 (Performance & Scalability): 1만 건의 메시지를 동기(Sync)로 기다리면 서버가 멈추니까, 메시지 큐(Kafka)에 던져놓고 비동기(Async)로 빠져나오는 이벤트 흐름 파악.

📢 섹션 요약 비유: 논리 뷰가 자동차 공장의 "컨베이어 벨트와 기계 10대의 예쁜 배치도(정지 사진)"라면, 프로세스 뷰는 공장의 전원 스위치를 탁! 켠 뒤 "1번 로봇이 철판을 3초 만에 깎아 넘기면, 2번 로봇이 0.5초 대기했다가 페인트를 칠하는 쉴 새 없이 돌아가는 동적 시뮬레이션(동영상)"입니다. 배치도가 아무리 예뻐도 1번 로봇이 너무 늦게 철판을 주면 2번 로봇이 놀면서 공장 전체가 마비되는 병목(성능 저하)을 잡아내려면 무조건 이 동적 도면이 필요합니다.

Ⅱ. 핵심 무기: 시퀀스(Sequence) 다이어그램의 지배력

시간의 흐름에 따라 핑퐁 치는 통신의 민낯을 까발린다.

  1. 시간 축과 생명선 (Lifeline):
    • 시퀀스 다이어그램은 위에서 아래로 **'시간(Time)'**이 흐른다.
    • 화면 맨 위에 [사용자], [웹 서버 스레드], [DB 커넥션] 이라는 상자를 세워두고, 각 상자 밑으로 점선(생명선)을 쭈욱 내린다.
  2. 동기(Sync)와 비동기(Async)의 화살표 전쟁:
    • [사용자]가 [웹 서버]로 꽉 찬 화살표(동기 호출, Sync)를 쏘며 "결제해 줘!"라고 요청한다.
    • [웹 서버]는 응답을 주기 위해 [DB]로 또 화살표를 쏜다. DB가 대답(점선 화살표, Return)을 줄 때까지 웹 서버의 생명선에는 뚱뚱한 막대기(활성화 상태, Blocked)가 그려지며 아무 일도 못 하고 대기한다.
    • 아키텍트는 이 뚱뚱한 막대기가 너무 길어 병목이 예상되면, 꽉 찬 화살표를 뚫린 화살표(비동기 호출, Async)로 스윽 바꿔 그린다. "야, DB 대답 기다리지 말고 끊어! 나중에 콜백(Callback) 받으면 되잖아!"라며 성능 문제를 도면 위에서 즉시 수술해 버린다.
  3. 병렬 처리 (Parallel) 쪼개기:
    • 무거운 회원 가입 로직을 만났을 때, 스레드를 2개로 쪼개어 하나는 메일 서버로 보내고 하나는 DB로 보내는 병렬 분기(Fork & Join) 흐름을 네모난 프레임 상자(alt, par 등)로 묶어 명확하게 그려낸다.

📢 섹션 요약 비유: 연극의 대본(대사집)과 같습니다. 세 명의 배우(사용자, 서버, DB)가 무대에 서 있습니다. 1번 배우가 대사를 치고(요청), 2번 배우가 그 대사를 듣고 고민하는 3초 동안 1번 배우가 입을 다물고 가만히 얼음 상태로 기다리는지(동기 통신), 아니면 2번이 고민하는 동안 1번이 재빨리 뒤돌아 3번 배우에게 윙크를 하는지(비동기 통신) 시간의 흐름에 따른 행동 지침을 소름 돋게 1초 단위로 적어놓은 런타임 핑퐁 대본입니다.

Ⅲ. 프로세스 뷰의 완성: 누가 이 도면을 보는가?

이 도면이 없으면 시스템 통합업체(SI)는 지옥을 본다.

  1. 시스템 통합자(Integrator)의 생명줄:
    • 큰 기업의 시스템은 내가 만든 서버 하나로 돌아가지 않는다. 신용평가사 API, 페이게이트웨이(PG), 사내 ERP 등 10개의 시스템이 엮인다.
    • "누가 먼저 찌르고, 누가 타임아웃 3초를 세고 끊을 것인가?" 프로세스 뷰(시퀀스 다이어그램)에 이 룰을 명확히 그려놓지 않으면, 10개 업체 개발자가 모인 통합 테스트 첫날 서버가 통신 데드락(Deadlock)에 빠져 다 같이 뻗어버린다.
  2. 성능 테스터 (Performance Tester)의 공격 맵:
    • 부하 테스트(JMeter, 1만 명 쏘기)를 하는 엔지니어는 소스코드를 읽지 않는다.
    • 이 프로세스 뷰를 펴놓고, "아, 로그인할 때 스레드가 무조건 DB 조회를 3번이나 하네? 여기가 1만 명 들어오면 무조건 목이 졸려서 죽는 병목 지점(Choke Point)이네. 여기를 집중적으로 때려서 테스트해 봐야겠다"라고 작전을 짠다.
  3. +1 (유스케이스)와의 증명:
    • 사장님의 요구사항(+1)인 "블랙프라이데이 동시 접속 10만 명을 버텨라"라는 시나리오를 이 프로세스 뷰에 부어본다.
    • 스레드가 다 털리고 DB 커넥션 풀이 터지는 그림이 도면상에서 발견되면, 아키텍트는 당장 1단계 설계(논리 뷰)로 돌아가서 스레드 개수를 늘리거나 캐시(Redis) 서버를 욱여넣어 문제를 고치고 도면을 다시 그린다.

📢 섹션 요약 비유: 10개의 강물이 모여 하나의 거대한 댐(통합 시스템)을 이룹니다. 프로세스 뷰는 물이 흘러들어오는 수문(API)이 언제 열리고 언제 닫히는지 초 단위의 수문 조작 타이머를 적어놓은 방재 센터의 작전 지도입니다. 이 지도가 없으면 홍수(트래픽)가 났을 때 A 강물과 B 강물이 동시에 밀려와 댐이 터져버립니다(성능 장애). 댐 관리자(성능 테스터)는 이 지도를 보고 "아, 이 수문이 3초만 늦게 열려도 물바다가 되네? 여길 집중적으로 수리해라!"라고 진단을 내리는 생존 필수 도면입니다.