이석영

스캐너 7종을 하나로 통합하자 초기 구조가 그대로는 버티지 못했습니다. 스캐너마다 출력 형식이 제각각이고, 결과는 수만 건 단위로 쏟아졌으며, 서비스는 여러 파드로 나뉘어 떠 있었습니다. 결국 두 숙제를 동시에 풀어야 했습니다. 많은 결과를 느리지 않게 보여주는 것, 그리고 여러 파드에서도 상태가 어긋나지 않게 하는 것.

화면이 느린 걸 처음엔 쿼리 탓이라 생각했지만, 뜯어보니 두 지점 모두 구조가 근본 원인이었습니다.

• ① 상세·목록이 원본 결과를 매 조회마다 다시 파싱했고,
• ② 파드 간 실시간 상태가 공유되지 않아 이벤트가 어긋나고 작업이 중복됐습니다.

읽기 경로와 이벤트 전파, 두 설계 모두에 문제가 있었습니다.

• ① 저장 시점 정규화 · 조회할 때마다 원본을 다시 가공하던 방식을 버리고, 스캔이 끝나는 시점에 3NF로 정규화·투영해 저장했습니다. 조회는 조립된 행을 읽기만 하면 되어 상세·목록 응답이 함께 좋아졌습니다.
• ② Redis 이벤트 브리지 · 파드 간 이벤트를 Redis Pub/Sub로 잇고 분산 락으로 중복 작업을 막았으며, 이벤트를 조직 단위로 스코핑해 파드가 늘어도 알림이 섞이거나 어긋나지 않게 했습니다.

• 조회 성능
  저장 시점 정규화로 상세·목록 개선
• 멀티 파드
  이벤트 정합성 · 작업 중복 해소

VPN으로 접속하는 사설 클러스터에서 리소스 목록만 가볍게 가져오는 스캔은 잘 되는데, 클러스터 전체 설정을 동시에 훑는 무거운 병렬 검사만 TLS handshake timeout으로 실패했습니다. 작은 패킷을 주고받는 TCP 연결은 멀쩡히 통과하는데, 인증서를 교환하느라 수 KB짜리 대형 레코드를 보내는 TLS 핸드셰이크에서만 멈추는, 재현조차 까다로운 증상이었습니다.

유저스페이스 WireGuard가 외부 UDP 경로 위에 트래픽을 다시 감싸면서, 내부 MTU 1420에 WG 오버헤드가 더해져 외부 경로의 실제 전송 한계(PMTU)를 넘겼습니다. 그 결과 큰 패킷만 조용히 버려졌습니다. "연결은 되는데 TLS 핸드셰이크만 타임아웃"이라는 조합이 결정적 단서였습니다. 이건 MTU 드롭의 전형적인 신호였습니다.

터널 MTU를 1420 → 1280으로 낮췄습니다. 여기에 한 방향 EOF에 양쪽 소켓을 즉시 닫아 대용량 응답이 중간에 잘리던 파이프 버그를 전이중 half-close(CloseWrite)로 고치고, 연결이 한꺼번에 몰릴 때의 일시적 실패를 1회 재시도로 흡수했습니다. 무거운 병렬 검사에는 검사 대상을 네임스페이스 단위로 좁혀 동시 핸드셰이크 폭주 자체를 줄였습니다.

• TLS 핸드셰이크
  70초 타임아웃→안정 통과
• 사설 클러스터 스캔
  2,895건 E2E 성공
• 대용량 응답
  중간 잘림 제거

운영 서버의 OS 패키지 취약점 스캔이 항상 0건으로 돌아왔습니다. 결과가 비는 데 그치지 않고, 재조정 로직이 "이번엔 결과가 없다"고 판단해 이전에 쌓아둔 1,208건까지 삭제했습니다. 스캔이 실패하고 있다는 신호도 남지 않았습니다.

접속 경로(VPN·SSH)도 스캐너도 정상이었지만, 이 서버의 rpm 패키지 DB가 181MB로 비대했습니다. 스캐너가 이를 파싱하다 메모리 2.9GB를 넘겨 OOM으로 강제 종료됐고, 수집본 전체를 한 번에 훑는 구조라 한 곳의 실패가 스캔 전체를 0건으로 만들었습니다. 결과가 비는 것과 기존 데이터가 지워지는 두 증상이 여기서 함께 나왔습니다.

무거운 원본 DB를 통째로 전송하는 대신, 호스트에서 설치된 패키지 목록만 추출해 표준 형식(CycloneDX SBOM)으로 변환한 뒤 그 목록을 스캐너로 분석하도록 파이프라인을 전환했습니다. 단일 결과만 생성되어 OOM도, 기존 결과 덮어쓰기도 사라졌습니다.

• OS 패키지 취약점
  0건→5,706건 탐지
• 기존 데이터
  1,208건 오삭제 재발 방지
• 스캐너 메모리
  OOM(2.9GB+) 제거

스캔이 DB·큐상 분명히 완료됐는데도, 프론트의 상태 배지는 계속 '분석중'에 머물렀습니다. 로그를 초 단위로 맞춰보니, 완료 이벤트를 보내는 그 순간 소켓은 분명히 연결(clients=1)돼 있었는데도 브라우저가 그것을 받지 못했습니다.

WebSocket에 ping/pong keepalive가 없어, 피어가 끊겨도 서버는 TCP 타임아웃(~60초) 전까지 그 사실을 모릅니다. 그 사이 소켓은 readyState가 여전히 OPEN이라, 완료 이벤트가 살아있어 보이는 죽은 소켓(half-open)으로 send되어 유실됐습니다. 브라우저는 새 소켓으로 재연결하지만, 지나간 이벤트는 다시 오지 않았습니다.

서버에 30초 주기 heartbeat를 두어, 직전 주기에 pong이 없던 소켓을 연결 목록에서 제거하고 terminate했습니다. 죽은 소켓을 60초가 아니라 30초 안에 감지해 유실 창을 좁혔고, 여기에 프론트 재연결 시 진행 중 스캔을 다시 조회해 유실 창에 떨어진 완료까지 복구했습니다.

• 좀비 소켓 감지
  ~60초→~30초
• 완료 신호
  유실 제거 · 확실히 도달
• '분석중' 잔류
  heartbeat + 재연결 reconcile 2겹

"전체 페이지를 그대로 저장한다"는 제품의 핵심 가치는 실제 웹사이트 앞에서 가장 자주 깨졌습니다. 스크롤할 때 따라다니는 sticky 헤더가 화면마다 중복으로 찍히고, lazy-load 이미지는 회색 자리표시자로 비어 나오며, 스크롤 애니메이션 라이브러리는 요소를 반쯤 나타난 상태로 얼렸습니다. 사이트마다 깨지는 양상이 달라, 재현과 대응이 가장 까다로운 영역이었습니다.

단순히 페이지 높이만큼 스크롤하며 이어 붙이는 방식으로는 현대 웹의 동적 렌더링을 담을 수 없었습니다. 진짜 스크롤 컨테이너가 body가 아니라 내부 요소일 때가 많았고(오버플로 컨테이너·Perfect Scrollbar), position:fixed/sticky 요소는 뷰포트에 고정돼 프레임마다 재등장했으며, 이미지·콘텐츠는 스크롤이 닿아야 비로소 로드됐습니다. 게다가 캡처 도중 페이지 전체 높이가 늘어나 좌표가 밀리기도 했습니다.

브라우저 확장의 콘텐츠 스크립트에서 캡처 파이프라인을 단계로 나눠 이 변수들을 하나씩 통제했습니다.

• ① DOM을 훑어 실제 스크롤 컨테이너를 탐색(메인 문서 / 내부 오버플로 / Perfect Scrollbar, 화면 밖·초소형 요소 필터)하고,
• ② 캡처 직전 sticky→relative 전환·스크롤바 숨김·스크롤 애니메이션 라이브러리(AOS·Skrollr 등) 무력화·사이트별 예외 처리를 적용했습니다.
• ③ 본 캡처 전 페이지를 빠르게 훑는 warmup 스크롤로 lazy-load를 미리 트리거하고,
• ④ 프레임마다 fixed 요소를 처리하며, 캡처 중 높이가 변하면 위치 배열을 재계산·재큐잉했습니다.

• sticky·fixed 중복
  프레임별 처리로 제거
• lazy-load 이미지
  warmup 선트리거로 온전히 캡처
• 내부 스크롤·동적 높이
  컨테이너 탐색 · 좌표 재계산으로 대응
• 페이지 길이
  Canvas 한계 우회 · 사실상 무제한

초기 구조는 사용자가 캡처를 요청하면 API 서버가 직접 Playwright를 띄워 대상 페이지에 접속·렌더링·스크린샷·저장까지 전부 처리했습니다. 캡처 1건당 평균 30~40초가 걸렸고, 그동안 서버 자원이 묶여 다른 요청까지 느려졌습니다.

Node.js는 싱글 스레드입니다. CPU·I/O 집약적인 캡처가 이벤트 루프를 오래 점유하면서, 실시간 응답·브라우저 렌더링·파일 저장이라는 성격이 다른 세 가지 일을 한 서버가 동시에 떠안는 구조적 병목이 근본 원인이었습니다.

고비용 작업(캡처·업로드)을 별도 Worker App으로 분리하고, 그 사이를 메시지 큐로 이었습니다. 요청 처리와 실제 작업 수행을 떼어내고, Page Capture Queue와 Snapshot Processor Queue를 나눠 캡처와 이미지 후처리가 서로 독립된 파이프라인에서 돌게 했습니다.

• API 체감 응답 시간
  ▼ 97% 단축
• 확장
  Worker 추가만으로 선형 확장
• 사용자 경험
  processing/completed 실시간 표시

긴 페이지를 캡처하면 전체를 하나의 초대형 이미지로 병합한 뒤 후처리했습니다. 100MB가 넘는 이미지에서 최대 2GB 이상 메모리를 쓰다 OOM으로 프로세스가 강제 종료됐고, 32,000px 이상 페이지는 포맷·Canvas 한계로 잘렸습니다.

전체를 먼저 병합한 뒤 타일로 자르는 순서 자체가 문제였습니다. 초고해상도 이미지를 단일 객체로 메모리에 통째로 올려 압축·최적화하는 동안 대형 버퍼가 오래 상주했고, 모든 처리가 메모리 위에서 동기적으로 일어났습니다.

순서를 뒤집어 병합 단계를 없애고, 캡처된 프레임에서 필요한 영역만 바로 타일로 생성하도록 파이프라인을 재설계했습니다. 이미지 전체를 적재하는 대신 Sharp로 필요한 부분만 스트리밍하고, 프레임 전처리는 Promise.all 병렬, 타일 업로드도 순차 → 병렬로 바꿨습니다. 포맷은 PNG → WebP(품질 92)로 전환했습니다.

• 피크 메모리
  2GB→600MB
• 처리 시간
  45초→15초
• 동시 처리
  2개→10개 (5배)
• 타일 용량
  2MB→350KB (82%↓)

구독 결제를 붙이자, 완료를 알리는 웹훅이 재시도·중복으로 도착할 수 있었습니다. 게다가 팀 결제는 결제는 성공했는데 뒤이은 조직 생성이 실패하면 "돈은 빠졌는데 상태는 없는" 최악이 가능했고, 업그레이드는 즉시·다운그레이드는 다음 주기부터여야 하는 상태 전이도 까다로웠습니다.

결제 완료 이벤트는 정확히 한 번을 보장하지 않았고(at-least-once), 외부 결제 API는 확인 도중 실패할 수 있었습니다. 클라이언트가 결제 금액을 중간에 바꿀 여지도 있었고, 다운그레이드를 즉시 반영하면 남은 기간만큼 손해였습니다.

• ① 웹훅 멱등 · 이벤트 식별자에 UNIQUE를 걸고 처리 전에 게이팅해, 같은 웹훅이 몇 번 와도 상태가 두 번 바뀌지 않게 했습니다.
• ② 금액 위변조 차단 · 결제 확인 직전, 서버가 발급한 대기 주문(30분 TTL)의 기대 금액과 대조해 클라이언트가 조작한 금액을 거부했습니다.
• ③ 원자적 팀 체크아웃 · 외부 API 호출과 DB 쓰기를 분리하고 조직·구독·결제 기록을 한 트랜잭션으로 묶어, 실패하면 자동 환불로 롤백(환불까지 실패하면 이벤트를 발행해 수동 개입)했습니다.
• ④ 안전한 상태 전이 · 업그레이드는 즉시, 다운그레이드·취소는 주기 말에 반영하고, 조직당 활성 구독은 항상 하나만 유지했습니다.

• 웹훅 중복·재시도
  DB UNIQUE로 정산 1회 강제
• 팀 결제 실패
  자동 환불로 원자적 롤백
• 결제 실패
  상태 무오염 · 재시도 가능
• 금액 조작
  서버 대조로 거부

전력 데이터의 백업·삭제 배치가 대량 구간에서 비정상적으로 느려졌습니다. 삭제 로직을 제외한 테스트로 대량 데이터 처리 자체가 병목임을 먼저 좁혔습니다.

처음엔 Chunk Size로 인한 메모리·I/O 병목을 의심했습니다. 그런데 코드를 뜯어보니 Reader가 MongoPagingItemReader였던 게 진짜 원인이었습니다. 이 방식은 skip + limit 기반이라, 500만 번째 데이터를 읽으려면 앞선 499만 개를 모두 조회한 뒤 건너뜁니다. 데이터가 많을수록 조회 시간이 기하급수적으로 늘어나는 구조였습니다.

Reader를 MongoCursorItemReader로 교체해 커서 기반 스트리밍으로 전환, skip/limit이 만들던 불필요한 스캔을 제거했습니다. 배치 종료 시 커서를 명시적으로 닫아 리소스 누수도 막았습니다. 첫 가설(Chunk Size)에 머무르지 않고 Reader 구현까지 내려가 근본 원인을 확인한 것이 핵심이었습니다.

• 약 600만 건 처리
  5일+→20분
• 안정성
  대량에서도 일정한 성능 확보

관리자 시스템에서 장치를 CRUD하면 그 결과가 서로 다른 두 시스템(관리자 DB · 장치 시스템)에 함께 반영돼야 했습니다. 그런데 한쪽은 성공하고 다른 쪽은 실패하는 상황이 생기면서, 두 시스템의 데이터가 어긋나는 심각한 정합성 문제가 있었습니다.

시스템 간 통신이 각각 개별적으로 처리돼, 요청 성공/실패 여부를 일관되게 관리할 체계가 없었습니다. 게다가 장치 시스템은 장치 정보를 JSON 파일로 저장하는 구조라, DB 반영 순서를 제어하지 않으면 언제든 불일치가 날 수 있었습니다.

• ① ResponseMessage 공통화 · 공통 모듈에 응답 객체를 정의하고 두 시스템 간 모든 통신을 이 객체로 주고받게 해, 요청 성공/실패를 명확하게 판별할 수 있게 했습니다.
• ② 요청 순서 재설계 · 파일 기반이라 되돌리기 어려운 장치 시스템을 먼저 처리하고, 그게 성공했을 때만 DB에 최종 반영하도록 순서를 뒤집었습니다. 실패 시에는 DB 반영을 차단해 불일치를 원천 차단했습니다.

• 두 시스템 정합성
  데이터 불일치 원천 차단
• 에러 추적
  성공/실패 명확화로 대응 용이

모든 데이터는 MongoDB에 UTC 기준으로 저장되고, 배치 서버는 KST(UTC+9)를 쓰고 있었습니다. 원래 의도는 KST 자정(UTC 15:00:00) 이전 데이터를 삭제하는 것이었는데, 실제로는 UTC 06:00:00까지의 데이터가 삭제되는, 하루가 밀린 현상이 나타났습니다.

시각 계산에 ZonedDateTime.withZoneSameInstant(UTC).toLocalDateTime()을 썼는데, toLocalDateTime()에서 타임존 정보가 사라지자 Spring Data MongoDB가 그 값을 다시 서버 기본 타임존(KST)으로 재해석했습니다. 그 결과 UTC 15:00:00 값이 한 번 더 변환되며 경계가 밀렸습니다. 눈에 안 보이는 타임존 이중 변환이 범인이었습니다.

toLocalDateTime() 대신 Instant를 그대로 사용해 타임존 손실 자체를 없앴습니다. 쿼리도 Criteria.where("createDate").lt(zonedDateTime.toInstant())처럼 UTC Instant를 직접 전달해, 컨버터가 올바른 UTC로 변환하도록 고쳤습니다.

• 삭제 경계
  정확히 KST 자정 기준으로 동작
• 타임존 손실
  근본 해결 · 다양한 Timezone 확장 가능

입·출고가 종이 서류와 담당자 간 대면 확인에 의존했습니다. 처리에 시간이 오래 걸렸고, 무엇보다 기록된 수량과 실제 재고가 자주 어긋나 재고를 믿기 어려웠습니다.

자재 정보가 수기·종이로만 관리돼 실시간 집계와 이력 추적이 불가능했습니다. 입·출고 내역이 사람의 기록과 대면 인수인계에 묶여 있어, 누락·중복·오기입이 나면 어디서 틀어졌는지 되짚을 근거 자체가 없었습니다.

오프라인 대면 프로세스를 웹으로 전산화했습니다. 품목 정보(품명·규격·단가 등)를 DB로 옮기고, 재고 수량은 입고에서 출고를 뺀 값으로 계산했습니다. 모든 입·출고를 트랜잭션으로 기록했기 때문에 재고가 언제나 정확하고 일관되게 맞아떨어졌습니다. 처리·조회를 화면에서 바로 할 수 있게 만들어 대면 확인 단계 자체를 없앴습니다.

• 업무 처리 시간
  ▼ 50%+ 단축
• 재고 수량 정확도
  입고-출고 계산으로 항상 일치
• 이력 추적
  입·출고 전 과정 기록·조회 가능