슬 개발일지

[빅데이터 분석기사] 1과목 개념 정리

yeseul-kim01 — Thu, 2 Apr 2026 01:03:50 +0900

빅데이터 분석 기획

DIKW - 데이터 정보 지식 지혜

byte 크기 순 - 킬 메 기 테 페 엑 제 요

빅데이터의 3v - Volume Varieyl Velocity

역량 교육 체계 설계의 절차

요구사항 직무별역량모델검토 역량차이분석 직무역량매트릭스 교육체계설계

조직성과 평가

목표 설정 , 모니터링 , 목표 조정 , 평가 실시 , 결과의 피드백 순임
균형 성과표 (BSC : balanced Score Card) 의 4가지 관점 - 과거 성과를 바탕으로 미래 성과를 창출 (재무적 , 고객 , 업무 프로세스 , 학습과 성장) 관점

빅데이터 플랫폼

구성 요소

수집 , 저장 , 분석 , 활용
수집에는 ETL , 크롤러 , EAI 등이 있음.

플랫폼의 데이터 형식

html , xml , csv , json
xml 은 sgml 문서 형식을 가진 마크업 언어를 만들 때 사용하는 다목적 마크업 언어고, 태그를 사용한다.

소프트웨어

R(시각화) , 우지 , 플럼 , Hbase , 스쿱
우지 는 워크플로우 관리 ! 스케줄링이나 모니터링 등등.. 맵 리듀스나 피그와 같은 액션들로 구성된 워크 플로우를 제어함.
플럼은 데이터 수집할 때 !- 이벤트 에이전트 활용함!!
분산 데이터 베이스인 Hbase 는 컬럼 기반 저장소로 HDFS 와 인터페이스를 제공함.
스쿱(하둡에서 관계형 디비로 데이터 보냄. 커넥터!!)은 정형 데이터 수집. sqoop , 커넥터를 사용해서 하둡 파일 시스템으로 데이터를 수집하거나 파일 시스템에서 관계형 데이터베이스로 데이터를 보내는 기능을 수행함.

분산 컴퓨팅 환경의 소프트웨어 구성 요소

맵리듀스
얀 ; 자원 관리 플랫폼
아파치 스피크 ; 실시간 !!!! 데이터 저장 ㄴㄴ 데이터 프로세싱 역할
하둡 분산 파일 시스템 ; 네임 노드 와 데이터 노드 로 이루어져있음.
아파치 하둡 ; 클라우드 플랫폼 위에서 클러스터를 구성해 데이터를 분석
하둡 에코 시스템 ; 수집,저장,처리,분석,시각화 기술로 구분이 가능함.

데이터 가공과 분석 관리를 위한 주요 기술

피그 , 하이브
피그는 맵 리듀스 api 를 단순화 시킴. sql 과 유사한 형태 , 피그 라틴이라는 자체 언어 제공
하이브 ; hiveQL 라는 쿼리를 제공하며 내부적으로 맵 리듀스로 변환되어 실행된다.
데이터 마이닝 : 머하웃 ; 하듑 기반임! 알고리즘을 구현한 오픈소스 - 데이터마이닝 알고리즘 구현한 오픈소스

개인정보 비식별 조치 - 가명 , 총계, 데이터 삭제 , 범주화 , 데이터 마스킹

가명처리는 휴리스틱 익명화 암호화 교환방법
데이터 범주화는 제어 올림 세분 정보 제한 범위 랜덤올림 범주화 기본

데이터 분석 계획

분석 로드맵 설정

분석 문제 정의

하향식 접근 ; 문제 탐색 먼저 ; 분석 과제가 정해져있는 거임
상향식 접근 ; 문제를 개선 ; 디자인 사고 접근법 ; 비지도 학습 , 프로토 타이핑(가설부터) 접근분석 기획의 유형 - 최적화 솔루션 통찰 발견
분석 대상과 분석 방법을 아는지 모르는지에 따라 나뉜다.
둘다 모르는거가 발견
둘다 아는게 최적화
방법만 아는게 통찰!
대상만 아는게 솔루션!분석 추진시 고려해야하는 우선순위 평가 기준
시급성 , 난이도
우선 순위 매트릭스

1 : 현 수준에서 과제 바로 적용하기 어렵지만 전략적 중요도가 젤 높고 시급하게 추진해야 한다.

2 : 전략도 중요도가 높지는 않지만 중장기적 관점에선 추진해야함. 난이도가 높음.

3 : 우선순위를 곧바로 적용 가능

4 : 적용은 가능하지만, 전략도 중요도는 낮다.

3 사분면 영역이 가장 우선적으로 적용 해야 한다.

빅데이터 분석 방법론의 유형

단계를 구성하는 단위활동 - 태스크 , 프로세스 그룹을 통해 산출물 생성 - 단계

KDD 분석 방법론 : 데이터 세트 선택 - 전처리 - 데이터 변환 - 데이터 마이닝 - 평가
CRISP-DM 분석 방법론 : 업무 이해 - 데이터 이해 - 데이터 주비 - 모델링 - 평가 - 배포
SEMMA 분석 방법론 : 샘플링 - 탐색 - 수정 - 모델링 - 검증

데이터 수집 및 저장 계획

데이터 수집 프로세스

목록을 작성해야 한다. 보안 문제나 수집 가능성 여부나 세부 데이터 항목 비용 등 검토!
데이터 소유 기관을 파악 해야 한다.
데이터 유형의 구분 및 확인
데이터 수집 실행수집 데이터 대상
내부 데이터 , 외부 데이터수집 방식 및 기술
ETL : 데이터 웨어하우스 및 데이터 마트로 이동시키기 위해 필요한 원본 데이터를 추출하고 변환해 적재하는 기술
FTP : TCPIP 프로토콜을 기반으로 해 서버 , 클라이언트 사이에서 파일 송수신
Sqoop : 커넥터를 활용해 관계형 데이터베이스 시스템에서 하둡 파일 시스템으로 전송
API : 실시간 데이터 수신 가능 , 인터페이스 기술임
RSYNC : 1:1 로 파일 과 디렉토리를 동기화 하는 응용 프로그램
크롤링 : 웹상 수집
RSS : XML 기반으로 정보를 배포하는 프로토콜을 활용해 데이터를 수집
스크래파이 : 파이썬 기반의 애플리케이션 프레임 워크
아파치 카프카 : 분산 스트리밍 플랫폼 기술
센싱 : 센서로부터
스트리밍 : 네트워크
플럼 : 스트리밍 데이터 흐름 을 비동기 방식!!!!!
스크라이브 : 단일 중앙 스크라이브 , 다수의 로컬 스크라이브 서버로 구성
척와 : 에이전트와 컬렉터 구성을 통해 데이터를 수집하고 하둡 파일 시스템에 저장하는 기능을 제공하는 데이터 수집 기술데이터 품질 검증
유효성
데이터 정확성 - 정확성,사실성,적합성,필수성,연관성
데이터 일관성 - 정합성, 일치성(의미 기능 성격 등이 동일한 데이터가 상호 동일한 용어와 형태 등으로 정의 ), 무결성활용성
데이터 유용성 - 충분성 , 유연성 , 사용성 , 추적성
데이터 접근성 - 접근성
데이터 적시성 - 비기능적 요구사항이 잘 대처되고 있는 지
데이터 보안성 - 보호성, 책임성 , 안정성

HDFS 란?

hadoop distributed file system (하둡 분산 파일 시스템) - 빅데이터 관리 플랫폼;
데이터를 수집하여 활용 가능한 형태의 데이터로 관리하기 위해 수집하고 저장하고 처리, 관리 등을 수행하는 소프트웨어 플랫폼이다.
하둡 , HDFS , 맵리듀스 , Spark 등이 있다.
GFS 와 동일한 소스코드를 사용한다. 복제 횟수는 관리자가 설정할 수 있으며 네임노드는 메타데이터를 별도로 관리한다.
관리하는 2개의 마스터 노드와 처리하는 1개의 슬레이브 노드로 이루어져있다.
복제 시에는 하나의 파일을 기본적으로 3개의 서버에 복제한다.

ETL - extraction , transformation , load : 3단계를 통해 DB에 적재한다. 데이터 수집 기술 중 하나

약 인공지능 , 강 인공지능

약인공지능 : 주어진 조건에서만 동작
강인공지능 : 인간과 동일한 사고가 가능
약인공지능의 제한된 기능을 뛰어넘어 더 발달된 인공지능이다.
강인공지능은 범용으로 사용되기는 시기 상조이다.

분산 파일 시스템이란?

네트워크로 연결된 여러 컴퓨터에 파일을 분산 저장하고 관리하는 시스템이고, 데이터베이스가 아닌 파일을 대상으로 한다.
네트워크를 통한 여러 파일을 관리 및 저장하는 개념이다.
HDFS , MapReduce , GFS 등이 있다.
맵 리듀스는 분산 병렬 처리 모델로 map - shuffle- reduce , input -> spliting -> mapping -> shuffing -> reducing
맵리듀스는 입력 데이터를 쪼개서 맵핑하고 섞은 후 분류하기 때문에 중복 제거와 합계 계산에 유용하며, 하둡에서 채택한 프로그래밍 모델이다.
GFS 는 파일을 여러 조각으로 나누어 저장했고, 하둡에 영향을 줬음! - 동일한 소스 코드 - 쓰기보다 읽기 위주!하둡 - 오픈소스 , 빅데이터 플랫폼의 핵심 기술
자바 기반 프레임 워크 ,
분산 파일 시스템 + 맵리듀스 모듈로 구성
하둡은 저장과 처리의 기본적인 기능만 제공 (실시간 데이터 처리 한계 , 일괄 처리임 , 복잡한 연산 처리 한계 , 64메가바이트 이하의 작은 파일 저장 시 관리가 힘들다. 데이터 백업 낮음. 3개의 복제본 파일 관리 방식이라 디스크 공간 낭비 , 단일 고장점이 존재함- 하나 멈추면 전체 중단)
하둡의 기능을 보완하는 오픈소스 프로그램 등이 많이 있음.YARM - 리소스 관리 , 분산 컴퓨팅 환경 , 컴퓨팅 자원 관리 , 스케쥴링 사용 관리 , 리소스 매니저임Zookeeper - 빅데이터 서버 시스템 관리 , 분산 환경 서버들 간의 상호 조정 서비스데이터 마이닝 - Mahout분산 데이터 베이스 - Hbase (HDFS 기반의 nosql 데베) , Cassandra (컬럼 중심 DB와 행 중심 DB의 복합형, Nosql 의 하나)
스트리밍 데이터 - Flume , Scribe , Chuckwa
데이터 분석 - Hive , Pig(MapReduce 대신 자체 언어 Pig Latin 제공)
워크 플로우 관리 - Oozie - 하둡 작업을 관리 , 빅데이터 처리 과정을 관리
직렬화 - Avro - RPC 와 데이터 직렬화를 지원함.

분석 로드맵 설정 - 우선순위 선정

비즈니스 성관 및 ROI (return on Investment) : 투자 대비 수익률을 관점으로 함. 비즈니스 관점임. 투자비용 요소 관점 - 다양성,속도,규모
분석 로드맵은 분석 데이터의 적용과는 전혀 연관이 없다!

분석 시나리오 - 이해 관계자 도출 , 업무성과 판단 , 분석 목표 도출

빅데이터 분석 기획의 절차

범위 설정 - 정의 - 수행 - 위험

개인정보 비동의 시에도 사용 가능한 경우

법렬상 의무 준수를 위함
계약 체결 이행을 위해
정보 주체나 제 3자의 이익,생명 을 위해 필요할 시

개인 정보 법 제도 - 개인정보보호,정보통신,신용정보(개정신)

개인정보 비식별화 기술 종류

총계처리 , 데이터 마스킹, 가명처리, 범주화

프라이버시 보호 모델

익명성 , 다양성 , 근접성

빅데이터의 3V - Volume, variety,velocity : 규모 다양성 속도

4V 는 Value 추가됨!

빅데이터 활용 3대 요소는 인력,자원(데이터),기술

1 제타바이트는 2의 70 승 바이트임!

데이터 처리를 제공하는 오픈소스 종류

스파크 ; 인메모리 기반 - 빠른 데이터
맵리듀스 ; 디스크 기반

정형 vs 비정형

형태소는 비정형 데이터 분석을 위한 단위

고품질 데이터 특성

정확성 , 적시성 , 일관성 , 완전성

데이터 저장소

데이터 웨어하우스 , 데이터 레이크 , 데이터 댐

차등프라이버시 - 개인정보차등보호 ; 데이터 노이즈 추가해 보호 및 분석 가능하게 함.

데이터 변환 기술 - 직렬화

데이터 시각화 기술 - 가시화

데이터 저장 기술 - nosql , 비디스크 기반 DBMS , 분산 파일 시스템

분산 파일 시스템 - 하둡 , 구글 파일 , 아마존 S3 파일 시스템
Nosql - 키값 모델 기반 Dynamo 이랑 Membase , 열 기반 Bigtable Hbase Cassandra , 문서 기반 couchDB MongoDB 가 있음.
분산 메인 메모리 기반 DBMS - SAP hana voltDb
플레시 메모리 활용 관리 시스템 - orcale smart flash cache 등이 있음.

데이터 처리 기술 - 맵리듀스

실시간 처리 , 분산 병렬 처리 , 인메모리 처리 , 인데이터베이스 처리 등의 방법
구글의 맵리듀스 , 하둡의 맵리듀스 , 마이크로소프트의 dryard
처리 프로그래밍 기술로는 sawzall, pig , 어파치 하이브 등이 있음.

데이터 접근 기술 - JDBC

데이터 분석 기술 - OLAP (online analytical processing)

olap :
데이터 마이닝
연관 분석
sns 분석
전통적 통계 분석

hadoop : 대용량 데이터를 분산 처리하기 위한 대표적인 프레임 워크

빅데이터 조직 및 인력 방안

집중 구조 : 중복 가능성 이 있음. 빠르게 적용 아님. 현업 부서의 다양한 요청에 신속 대응이 어려움. 현업 부서의 분석 요청이 몰리면 병목 현상이 있을 수 있음. 전사적 관점에서 분석 수행 및 표준화에 유리함.
기능 구조 : 직접 하는 거, 분석 결과를 협업 부서의 업무에 가장 빠르게 적용할 수 있다.
분산 구조 : 분석 조직 인력을 현업 부서에 배치하는 거 , 분석 결과를 협업 부서의 업무에 가장 빠르게 적용할 수 있다.

개인 정보는 정보 주체 동의 하에 원본 그대로 사용할 수 있다. 가명 익명 처리는 2차적 활용할 때 적용임.

책임 원칙 위배

정의: 정확한 결과를 바탕으로 책임을 지우는 기존 책임 원칙이 빅데이터의 예측 알고리즘 발달로 훼손되는 현상.
책임 원칙은 데이터의 수집, 활용, 결과에 대한 책임 주체를 명확히 해야 한다는 원칙.
'빅브라더의 일상 감시'는 누가, 어떤 목적으로 데이터를 사용하는지 불투명하며, 이로 인한 피해 발생 시 책임 소재가 불분명해지는 대표적인 책임 원칙 위배 사례

총계 처리

특정 개인 식별 불가
평균 소득 은 총계 처리의 에시
개인정보를 안전하게 활용하기 위한 비식별조치 기술 중 하나

빅데이터 플랫폼의 계층

소프트웨어 , 플랫폼 , 인프라 스트럭처
소프트 웨어 는 데이터 처리 , 분석 , 수집 정제, 서비스 관리 , 사용자 관리 , 보안 , 모니터링
플랫폼 은 작업 스케쥴링 , 자원 할당 , 프로파일링 (스트럭처 자원을 할당하는 자원 , 응용 파일링 등을 수행함) ,서비스 사용자 관리 , 모니터링 , 보안 , 데이터 관리
인프라스트럭처 계층 - 자원 배치 , 노드 관리 , 데이터 관리 , 자원 관리 등등등

로그 스트리밍 수집 - flume , logstash

개인 정보 보호

가명정보 ; 추가 정보 결합 해야지 개인 식별 가능
익명 정보 ; 더이상 식별 불가.

빅데이터 분석

분석 주제 유형

최적화 - 모두 알 때
통찰 - 방법은 모름 ; 군집 분석 기법을 사용해서 고객을 그룹화해서 각 그룹의 특징을 발견하는 활동
해결/솔루션 - 방법은 모르는데 대상은 암
발견/탐색 - 둘다 모름.

데이터 웨어 하우스 - 주제 지향성 , 데이터 통합 , 시계열성 , 비휘발성 DW!! 정형 데이터를 저장.

강화학습

시행 착오를 통해 최적의 행동 학습
Q 러닝 , SARSA 등의 알고리즘이 있다.
순차적인 의사결정 문제에 주로 적용된다.

[NLP BootCamp - 02] NLP 입문

yeseul-kim01 — Mon, 23 Mar 2026 14:20:00 +0900

NLP란? 자연어 처리의 정의

자연어 처리(Natural Language Processing, NLP)는 컴퓨터가 인간의 언어를 이해·처리하도록 돕는 기술 분야이다. 즉, 사람이 일상적으로 사용하는 언어(텍스트나 음성)를 컴퓨터가 해석하여 의미를 이해하거나 생성할 수 있도록 한다. 일반적으로 NLP는 통계적 방법과 머신러닝·딥러닝 기법을 결합해 동작하며, 인공지능(AI)의 하위 분야로 분류된다. 예를 들어 IBM은 “NLP는 머신러닝을 활용해 컴퓨터가 인간의 언어를 이해하고 소통하도록 돕는 AI의 하위 분야”라고 정의하고 있으며, AWS 역시 “컴퓨터가 인간 언어를 해석·조작하고 이해할 수 있도록 하는 기술”이라 설명한다. NLP 기술은 검색 엔진의 질의 처리나 챗봇, 음성비서(예: Alexa, Siri) 등 다양한 응용에 필수적이다.

자연어의 특징

자연어는 맥락 의존성, 불완전성, 다양성 등의 특징을 지닌다.

맥락 의존성: 같은 단어라도 문맥에 따라 의미가 달라진다. 예를 들어 “배”는 “배가 고프다”일 때는 ‘배(위장)’를, “배가 출항했다”일 때는 ‘배(선박)’를 뜻한다. 자연어에는 동음이의어·다의어·동형어 등이 많아, 단어의 정확한 의미 판단에는 주변 문맥이 중요하다.
불완전성: 일상 언어 표현은 문법이나 문장이 불완전해도 의사소통이 가능하다. 사람들은 때로 주어를 생략하거나 비문(非文) 형태로 말해도 서로 이해한다(예: “대신 부탁했다”라는 문장만으로는 누가 무슨 부탁을 했는지 모호하다). 따라서 NLP 시스템은 이런 불완전한 표현에서도 의미를 유추해야 한다)
다양성: 같은 의미라도 여러 방식으로 표현된다. 뉘앙스나 어순, 방언·은어 등으로 표현 방식이 매우 다양하다. 이미지 데이터의 작은 변화가 시각적 의미에 큰 영향을 주지 않는 반면, 자연어는 단어 하나, 어순 하나가 바뀌면 뜻이 완전히 달라질 수 있어 정규화가 어렵다. 예를 들어 “조용히 해”와 “해 조용히”는 어순만 달라도 의미가 달라질 수 있다.

주요 NLP 태스크

자연어 처리에서는 위와 같은 특징을 해결하기 위해 다양한 태스크가 개발되었다. 주요 예시는 다음과 같다:

개체명 인식(Named Entity Recognition, NER): 텍스트에서 사람 이름, 장소, 기관명 같은 의미 단위를 찾아 분류하는 작업이다. 예를 들어 문장에서 “런던”을 장소로, “마리아”를 사람 이름으로 식별한다. NER은 문서 요약, 정보 검색, 기계번역 등에서 중요한 역할을 한다.
품사 태깅(Pos Tagging): 문장 속 각 단어의 품사(명사, 동사, 형용사 등)를 문맥에 맞게 결정한다. 예컨대 “I can make a paper plane”에서 ‘make’는 동사, “What make of car”에서는 ‘make’가 명사(자동차 제조사)임을 구분한다.
단어 의미 명확화(WSD, Word Sense Disambiguation): 다의어(여러 뜻을 가진 단어)의 적절한 의미를 문맥에 따라 정한다. 예를 들어 “make the grade”와 “make a bet”에서 ‘make’의 의미가 각각 ‘성취하다’, ‘행하다’로 다르다는 것을 구별한다.
질의응답(Question Answering, QA): 문서나 데이터베이스에서 사용자의 질문에 대한 답을 찾아내는 작업이다. 예를 들어, 어떤 문서를 주고 “뉴턴이 제창한 이론은?”이라는 질문이 들어오면, 문서에서 답변에 해당하는 구절을 추출해야 한다. 특히 추출형 QA에서는 질문에 해당하는 문서 내 텍스트 범위를 답으로 찾아낸다.
기계번역과 요약: 한 언어의 문장을 다른 언어로 변환(기계번역)하거나, 긴 문서에서 핵심 정보를 추출해 짧게 요약하는 작업이다. IBM은 NLP 툴이 핵심 정보를 자동 분류·추출하여 콘텐츠를 요약하고, 한 언어에서 다른 언어로 번역하는 데 활용된다고 설명한다. 예를 들어 문서 처리 파이프라인에서 “하이라이트 자동 요약”이나 “영어-한국어 번역” 등이 여기에 속한다.

이 외에도 맞춤법 검사, 텍스트 정규화, 감성 분석, 구문 분석(파싱) 등 수많은 NLP 태스크가 연구되고 활용된다. 각각의 태스크는 자연어의 모호성과 다양성을 풀기 위해 문맥 이해, 통계 모델링, 딥러닝 등을 기반으로 한 알고리즘을 사용한다.

트랜스포머(Transformer) 이후의 변화

2017년 트랜스포머 아키텍처의 등장은 NLP 연구와 응용을 근본적으로 바꾸었다. 그 전에는 순환신경망(RNN) 기반 시퀀스-투-시퀀스 모델이 주로 기계번역 등에 사용되었다. 그러나 트랜스포머는 병렬 연산이 가능해 학습이 빠르고, 문맥을 멀리까지 한 번에 고려할 수 있어 BERT나 GPT 같은 대형 언어모델을 가능하게 했다.

이로 인해 모든 NLP 태스크를 생성 문제로 통합하려는 시도가 늘었다. 예를 들어 구글의 T5(Text-to-Text Transfer Transformer) 모델은 모든 NLP 태스크를 “텍스트-투-텍스트” 문제로 재구성해 다룬다. 이전에는 감정분석 결과를 0/1로 출력하거나 NER에서 각 토큰에 클래스 레이블을 붙였지만, 이제는 “이 문장은 긍정입니다”처럼 모델이 자연어 형태로 답을 생성하도록 한다. 대표적인 모델인 GPT 시리즈는 자기회귀 생성 모델로 설계되어, “다음 단어 예측” 문제를 통해 언어 모델링뿐 아니라 분류·생성 등 다양한 태스크를 수행할 수 있다. 실제로 IBM은 GPT-4 같은 사전학습 언어모델이 프롬프트에 따라 기사·보고서 등 사람과 유사한 텍스트를 생성할 수 있다고 보도한다.

그러나 모든 문제를 생성으로만 풀 수 있는 것은 아니다. 생성 모델의 출력은 확률적이어서 항상 정확성을 보장하지 않는다. 특히 할루시네이션(hallucination)이라 불리는, 그럴듯하지만 사실과 다른 내용을 생성하는 현상이 여전히 큰 문제로 남아 있다. 최근 연구에서는 “대규모 언어모델의 환각 현상은 본질적 한계이며 완전히 제거할 수 없다”고 경고한다. 또한 출력 포맷을 명확히 제한하기 어렵고, 생성된 텍스트의 품질 평가 지표 마련도 쉽지 않다. 그럼에도 불구하고 트랜스포머 기반 생성모델은 NLP의 새로운 전기를 열었으며, 다양한 태스크를 단일한 모델로 다룰 수 있게 되었다.

NLP 태스크 이해의 중요성

비록 현대에는 거대 생성 모델이 많은 작업을 자동화해 주지만, 전통적 NLP 태스크의 이해는 여전히 중요하다. 예를 들어 RAG(Retrieval-Augmented Generation) 방식의 QA 시스템은 사용자가 질문을 하면 곧바로 답을 생성하는 대신, 먼저 관련 문서를 검색(retrieval)한 후 유의미한 내용을 추출(extraction)하고 이를 바탕으로 답을 생성(generation)한다. IBM 설명에 따르면, RAG는 외부 지식 베이스와 연결하여 LLM이 보다 높은 품질의 응답을 제공할 수 있게 해 준다 실제로 RAG는 검색 과정을 통해 최신 정보와 도메인 특화 내용을 학습 없이 활용할 수 있으므로, 오류 가능성을 줄이고 보다 정확한 답변을 얻는 데 기여한다.

따라서 생성형 모델의 실패를 분석하거나 사용자 질의에 대한 설명 가능한 응답을 생성하려면, 전통적인 NLP 기법들(NER, 구문 분석, 정규화 등)에 대한 이해가 필요하다. 예를 들어, 생성 모델의 출력 결과가 의도와 어긋난다면 어떤 단계에서 문제가 발생했는지 파악하기 위해 토큰 분류 모델이나 문장 분석 모델 등을 활용해 내부 상태를 점검할 수 있다. 또한 모델이 특정 도메인 지식을 다루도록 하려면 전문 문서를 검색·추출하는 RAG 같은 파이프라인 설계가 유용하다.

모델 출력 설계

NLP 시스템의 전형적인 파이프라인은 입력 X의 전처리 → 벡터 표현 → 모델 추론 → 출력 Y의 디코딩 단계를 거친다. 먼저 입력 문장은 토크나이저를 이용해 단어 또는 하위어(subword) 단위로 분리(Tokenization)되고, 어간 추출이나 불용어 제거 등의 작업을 통해 정제된다. 이어서 각 토큰은 Word2Vec, GloVe 같은 임베딩 기법이나 최근 유행하는 문맥 임베딩을 통해 고정 길이의 벡터로 변환된다. 이렇게 만들어진 벡터 시퀀스가 모델(RNN이나 트랜스포머)을 거쳐 학습된 특징을 반영한 출력 벡터를 생성하면, 마지막으로 이 벡터를 사람이 이해할 수 있는 형태로 디코딩하는 과정을 거친다.

모델의 출력 설계는 풀고자 하는 태스크에 따라 달라진다. 크게 두 가지 유형인 분류(classification)와 회귀(regression)로 구분할 수 있다. 분류 문제의 경우 출력은 이산적인 클래스 라벨이 되며, 회귀 문제의 경우 연속적인 실수 값이 된다. 예를 들어 감성분석에서는 “긍정/부정”과 같은 이진 클래스로 예측할 수 있고, 품사 태깅에서는 어휘마다 품사 카테고리를 예측한다. 자연어 생성 태스크의 경우 Y를 문장 자체로 정의하며, 모델은 주어진 입력으로부터 연속된 단어 시퀀스를 생성한다. GPT-4 같은 거대 생성모델은 프롬프트에 따라 기사나 보고서 같은 텍스트를 생성할 수 있는데, 이때 각 단계마다 모델은 어휘 전체에 대한 확률 분포를 계산해 가장 높은 점수의 단어를 선택한다(순차적 토큰 예측).

이처럼 NLP 모델의 출력값은 문제 유형에 맞추어 분류값, 회귀값 혹은 생성된 텍스트 등 다양한 형태로 설계된다. 분류형 출력(이산 값)은 결과의 정확성과 제약 조건 적용이 비교적 쉽지만, 생성형 출력(연속된 텍스트)은 표현력이 풍부한 반면 제어가 까다롭고 때로는 불안정한 측면이 있다. 따라서 원하는 태스크에 적합한 출력 방식을 잘 설계하는 것이 NLP 시스템의 성능과 안정성을 높이는 데 중요하다.

[NLP BootCamp - 01] Language Model의 발전: N-gram에서 RNN, 그리고 그 한계까지

yeseul-kim01 — Wed, 18 Mar 2026 12:19:51 +0900

자연어 처리에서 가장 기본적인 질문 중 하나는 이것이다.

“이 문장이 얼마나 자연스러운가?”

사람은 문장을 보면 어색한지 자연스러운지 어느 정도 직관적으로 판단할 수 있다. 하지만 컴퓨터는 문장을 사람처럼 이해하지 못한다. 대신 지금까지 관찰한 데이터로부터, “이런 단어 다음에는 어떤 단어가 나올 가능성이 높은가”, 혹은 “이 문장 전체가 실제로 등장할 가능성이 얼마나 되는가”를 확률적으로 계산한다. 이러한 관점에서 등장한 것이 바로 언어 모델(Language Model) 이다.

이번 글에서는 언어 모델이 어떤 문제를 풀기 위해 등장했는지부터 시작해서, 전통적인 N-gram Language Model, 임베딩을 도입한 Neural Probabilistic Language Model(NPLM), 그리고 긴 문맥을 다루기 위해 등장한 RNN과 LSTM까지의 흐름을 정리해보려고 한다.

1. 모델(Model)이란 무엇인가

인공지능 분야에 한정하지 않더라도 모델이라는 용어는 정말 자주 등장한다. 물리학에서는 운동 방정식, 경제학에서는 시장 모델, 기상학에서는 날씨 모델처럼, 모델은 일반적으로 현실 세계의 일부 현상이나 대상을 단순화해 표현한 수학적·계산적 구조를 의미한다.

이러한 모델의 공통점은 세 가지다.

첫째, 현실의 어떤 패턴이나 현상을 설명하려는 목적이 있다.

둘째, 그 패턴을 수학적 구조로 표현한다.

셋째, 학습되거나 정의된 구조를 바탕으로 미래 혹은 새로운 입력에 대해 예측할 수 있다.

인공지능에서는 보통 이를 다음과 같이 생각할 수 있다.

여기서 x는 입력, y는 예측값, 세타 는 모델의 파라미터다.

즉 모델 학습이란, 입력 x가 주어졌을 때 예측값 y가 실제 정답 y에 가까워지도록 파라미터 세타를 조정하는 과정이라고 볼 수 있다.

자연어 처리에서는 이런 모델 중에서도 특히 확률 모델의 관점이 중요하다. 언어는 정답/오답처럼 딱 잘라 떨어지기보다, 특정 표현이 얼마나 그럴듯한가로 판단하는 편이 훨씬 자연스럽기 때문이다.

2. Language Model이란 무엇인가

프로그래밍 언어처럼 문법을 먼저 설계한 뒤 만들어진 체계와 달리, 자연어는 사람들이 먼저 쓰고 나중에 문법이 정리된 체계에 가깝다. 그래서 자연어에는 다음과 같은 경우가 흔하다.

문법적으로는 맞지만 어색한 문장
문법적으로는 다소 틀렸지만 의미 전달은 되는 문장
문맥에 따라 자연스러움이 달라지는 문장

즉, 자연어를 다룰 때는 단순히 “맞다 / 틀리다”보다는, “이 문장이 실제로 등장할 가능성이 얼마나 높은가" 를 묻는 편이 훨씬 현실적이다. 이때 등장하는 것이 언어 모델이며, 언어 모델은 문장 W가 등장할 확률을 모델링한다.

P(W)

이 확률이 높다는 것은, 해당 문장이 데이터에서 더 자주 등장할 법하고 언어적으로 더 자연스럽다는 뜻으로 해석할 수 있다.

예를 들어 다음 두 문장을 생각해보자.

A: 나는 매일 아침 사과를 먹는다.
B: 나는 매일 아침 능금을 먹는다.

두 문장 모두 문법적으로는 큰 문제가 없지만, 일반적인 현대 한국어 코퍼스에서는 보통 A가 더 자주 관측될 가능성이 크다. 그렇다면 언어 모델은 보통 P(A)를 P(B)보다 더 높게 부여하게 된다.

3. 문장 확률과 Chain Rule

언어 모델의 목표는 문장 전체의 확률 P(W)를 계산하는 것이다.

문장을 w_1, w_2, ... , w_n이라는 단어열로 두면, 문장 확률은 다음과 같이 표현할 수 있다.

그런데 긴 문장을 통째로 하나의 사건처럼 다루는 것은 매우 어렵다. 실제 자연어는 조합의 수가 너무 많고, 문장이 길어질수록 똑같은 문장이 다시 등장할 가능성은 급격히 낮아지기 때문이다. Jurafsky와 Martin도 전체 문장 확률은 chain rule로 분해해 다루는 것이 기본이라고 설명한다.

확률의 chain rule을 적용하면 문장 확률은 다음처럼 쪼갤 수 있다.

즉, 문장 전체의 확률은 각 시점에서 이전 단어들이 주어졌을 때 다음 단어가 등장할 조건부 확률을 모두 곱한 것으로 볼 수 있다.

이 식은 언어 모델의 핵심을 보여준다. 결국 언어 모델은 “다음 단어 예측 문제”를 반복하는 구조로 바꿔 생각할 수 있다.

4. 확률적 언어 모델과 N-gram

이론적으로는 w_k를 예측할 때 그 앞에 등장한 모든 단어를 전부 봐야 한다. 하지만 현실적으로는 그렇게 하기 어렵다. 앞 문맥이 길어질수록 가능한 조합 수가 폭발적으로 증가하고, 특정 긴 문맥이 코퍼스에서 정확히 같은 형태로 다시 등장할 가능성은 매우 낮아지기 때문이다. 이 문제를 줄이기 위해 고전적으로 사용된 근사가 바로 Markov Assumption이다.

핵심 아이디어는 이렇다.

다음 단어의 확률은 전체 과거가 아니라, 직전 N-1개의 단어만 보면 충분하다고 가정하자.

그러면 다음과 같이 근사할 수 있다.

이것이 바로 N-gram Language Model이다.

예를 들어 bigram은 직전 1개 단어만, trigram은 직전 2개 단어만, 4-gram은 직전 3개 단어만 본다.

5. N-gram은 실제로 어떻게 계산되는가

N-gram 모델은 본질적으로 빈도를 세는 모델이다.

예를 들어 trigram 기준으로 다음 확률을 계산한다고 해보자.

이 값은 최대우도추정(MLE) 기준으로 다음처럼 구할 수 있다.

즉, 코퍼스에서 “나는 사과를” 다음에 “먹는다”가 얼마나 자주 이어졌는지를 세는 방식이다. 예를 들어 “나는 사과를”이 총 100번 등장했고, 그중 10번이 “먹는다”로 이어졌다면 위 확률은 0.1이 된다. 이런 빈도 기반 정규화가 전형적인 N-gram 확률 추정 방식이다.

이 접근은 직관적이고 단순하며, 실제로 오랫동안 매우 성공적으로 사용되었다. Bengio의 2003년 논문도 전통적인 n-gram 접근이 매우 성공적이었지만, 차원의 저주(curse of dimensionality) 때문에 한계가 분명하다고 설명한다.

6. N-gram의 장점과 한계

N-gram의 장점은 명확하다.

구현이 단순하다.
해석이 쉽다.
적은 자원으로도 비교적 빠르게 동작한다.
짧은 문맥 기반의 다음 단어 확률 추정에는 꽤 강력하다.

하지만 한계도 매우 명확하다.

6.1 희소성(Sparsity) 문제

예를 들어 “사과를 먹는다”는 자주 나왔지만, “포도를 먹는다”가 한 번도 등장하지 않았다고 하자.

N-gram은 단지 본 적이 없다는 이유로 두 번째 패턴에 매우 낮은 확률 혹은 0에 가까운 확률을 부여할 수 있다. 그러나 사람은 사과와 포도가 모두 “먹을 수 있는 과일”이라는 유사성을 이용해 두 문장 모두 자연스럽다고 판단한다. N-gram은 이런 단어 간 의미적 유사성을 반영하지 못한다.

6.2 긴 문맥을 보지 못함

N-gram은 직전 N-1개만 보기 때문에 문장이 길어지면 앞쪽 문맥 정보를 잃어버린다. 예를 들어 문장 초반에 중요한 힌트가 있었더라도, 현재 시점에서 그 힌트가 N-1개 범위를 벗어나면 모델은 그것을 전혀 활용할 수 없다. 이것 역시 언어 이해에서 큰 한계다.

7. N-gram은 실무에서 어디에 활용되었나

요즘 언어 모델의 주류는 Transformer 기반이지만, N-gram은 오랫동안 다양한 실무 시스템의 핵심 구성요소였다.

대표적인 예는 음성 인식이다. Jurafsky와 Martin은 N-gram이 음성 인식과 음성 합성, 철자 교정 등에서 중요한 구성요소라고 설명한다. 실제로 Mikolov의 RNN LM 논문도 비교 대상으로 state-of-the-art backoff n-gram language model을 두고, RNN LM이 음성 인식에서 perplexity와 word error rate를 개선함을 보고한다. 즉, RNN이 등장하기 전까지는 N-gram이 음성 인식에서 매우 강력한 기본기술이었다고 볼 수 있다.

또 다른 예는 자동완성과 검색어 추천이다. 오늘날 검색 시스템에서는 prefix matching, edge n-gram matching 같은 기법이 자동완성에 활용된다. OpenSearch 문서도 edge n-gram이 입력 중인 검색어의 앞부분을 잘라 빠른 부분 일치 검색을 지원한다고 설명한다. 엄밀히 말하면 이것은 고전적인 word-level language model과는 조금 다르지만, “n개의 연속된 문자 조각”을 이용해 실시간 추천과 부분 검색을 구현한다는 점에서 n-gram 계열 아이디어의 실용적 활용 예시다.

정리하면 N-gram은 다음과 같은 곳에서 강점을 가졌다.

음성 인식의 언어 모델
철자 교정과 오타 보정
검색 자동완성
짧은 문맥 기반의 다음 단어 예측
비교적 가벼운 통계 기반 텍스트 시스템

즉, N-gram은 단순한 이론 모델이 아니라 실제 산업 시스템에서 오랫동안 폭넓게 사용된 실전형 기본기 모델이었다.

8. NPLM: 임베딩을 도입한 신경망 언어 모델

N-gram의 가장 큰 한계 중 하나는, 단어를 단지 “기호”처럼 다룬다는 점이다. “사과”와 “포도”가 비슷한 의미를 갖는다는 사실을 전혀 반영하지 못한다.

이 문제를 해결하기 위해 Bengio 등이 제안한 것이 Neural Probabilistic Language Model(NPLM) 이다. 이 논문의 핵심은 두 가지를 동시에 학습하는 것이었다.

각 단어의 distributed representation, 즉 밀집 벡터 표현
그 벡터 표현을 기반으로 한 단어열의 확률 함수

즉, 단어를 one-hot 인덱스가 아니라 의미가 담긴 벡터로 표현하고, 유사한 단어는 벡터 공간에서 서로 가깝게 놓이도록 학습한다. 그러면 한 번도 보지 못한 문장이라도, 그 문장을 구성하는 단어들이 이미 본 적 있는 단어들과 의미적으로 가깝다면 더 높은 확률을 줄 수 있다. Bengio 논문은 이를 “training sentence가 semantically neighboring sentences에 대해서도 일반화한다”고 설명한다.

9. NPLM의 계산 흐름

NPLM은 구조적으로 보면 고정 길이 문맥을 입력으로 받는 feed-forward neural language model이다.

예를 들어 4-gram 상황이라면, 직전 3개의 단어 w_{t-3}, w_{t-2}, w_{t-1}를 보고 다음 단어 w_t를 예측한다고 생각할 수 있다.

9.1 One-hot에서 임베딩으로

각 단어는 처음에 one-hot vector로 표현할 수 있다.

하지만 실제 계산에서는 임베딩 행렬 C를 통해 각 단어를 저차원 밀집벡터로 바꾼다.

이 연산은 실제 코드 관점에서는 “one-hot과 행렬곱”이라기보다, 단어 인덱스로 임베딩 행렬의 특정 행 또는 열을 lookup하는 과정으로 이해하는 편이 더 직관적이다.

9.2 Concatenation

그다음 직전 문맥에 해당하는 임베딩 벡터들을 이어 붙인다.

9.3 Hidden Layer

이 벡터를 MLP에 통과시켜 문맥을 반영한 은닉 표현을 만든다.

9.4 Output Layer와 Softmax

은닉 표현으로부터 어휘집 전체 크기 V에 대한 점수를 만든 뒤,

마지막으로 softmax를 적용해 다음 단어의 확률 분포를 얻는다.

핵심은 N-gram이 단순 빈도 기반이었다면, NPLM은 단어 간 유사성을 반영하는 연속 벡터 공간을 도입해 희소성 문제를 완화했다는 점이다.

10. NPLM 한계

NPLM은 분명 큰 진전이었다. 하지만 구조적으로는 여전히 고정 길이 문맥만 본다.

즉, 4-gram 기반 NPLM이라면 앞에 아무리 긴 문장이 있었어도 결국 직전 3개 단어만 입력으로 사용한다.

예를 들어 다음 문장을 보자.

“나는 어제 저녁에 고기를 먹었다. 그래서 오늘 저녁에는 __ 외에 다른 음식을 먹고 싶다.”

이 문장에서 빈칸에 들어갈 단어를 예측하려면 “어제 저녁”, “고기” 같은 앞 문맥이 중요하다. 하지만 고정 길이 NPLM은 현재 시점 바로 앞의 몇 단어만 보기 때문에 이런 장거리 의존성을 충분히 반영하기 어렵다. Mikolov의 RNN LM 논문도 Bengio의 feed-forward neural LM이 fixed-length context를 사용했다는 점을 언급하면서, recurrent connection이 이를 확장하는 방향임을 설명한다.

11. RNN: 문맥을 기억하는 언어 모델

이 한계를 극복하기 위해 등장한 것이 RNN(Recurrent Neural Network) 이다.

RNN의 핵심 아이디어는 단순하다.

이전 시점의 정보를 버리지 말고, 현재 시점 계산에 다시 넣자.

Olah의 설명처럼, RNN은 같은 네트워크 블록이 시퀀스의 각 시점에 반복적으로 적용되며, 이전 단계의 정보가 다음 단계로 전달된다. 즉 RNN은 sequence 데이터에 자연스럽게 맞는 구조다.

RNN의 기본 수식은 다음과 같다.

여기서,

x_t: 현재 시점의 입력 벡터
h_{t-1}: 이전 시점의 hidden state
h_t: 현재 시점의 hidden state
W_h, W_x: 가중치
tanh: 비선형 활성화 함수

이 식의 의미는 명확하다.

현재 입력 x_t와 이전까지의 문맥 요약 h_{t-1}를 함께 사용해 새로운 문맥 요약 h_t를 만든다는 것이다.

즉, NPLM처럼 입력 창(window)을 고정해 잘라보는 방식이 아니라, 시퀀스를 따라가면서 문맥 정보를 hidden state에 누적해 전달하려는 구조다. Mikolov의 RNN LM은 이런 recurrent 구조를 이용해 고정 길이 문맥 모델보다 더 넓은 문맥을 활용할 수 있었고, 음성 인식 실험에서 backoff n-gram 모델 대비 perplexity와 WER 개선을 보고했다.

12. RNN의 직관적 동작

RNN을 시점별로 생각해보면 다음과 같다.

시점 t=0에서 첫 번째 입력 x_0를 받아 h_0를 만든다.

시점 t=1에서는 두 번째 입력 x_1과 이전 hidden state h_0를 함께 사용해 h_1을 만든다.

이 과정을 반복하면 h_t는 이론적으로 x_0부터 x_t까지의 정보를 요약한 벡터가 된다.

이 구조의 장점은 문장 길이가 달라져도 같은 가중치 W_h, W_x를 반복 사용하므로, 가변 길이 시퀀스를 자연스럽게 처리할 수 있다는 점이다. 이것이 feed-forward NPLM과 RNN의 가장 큰 차이다.

13. RNN의 한계 1: Information Vanishing

RNN은 과거 정보를 hidden state 하나에 계속 압축해서 전달한다.

문제는 이 hidden state의 크기는 고정되어 있다는 점이다.

즉, 시퀀스가 길어질수록 더 많은 정보를 같은 크기의 벡터에 계속 눌러 담아야 한다.

그러다 보니 문장 초반의 정보는 점차 희석되고, 뒤쪽 시점으로 갈수록 최근 정보가 상대적으로 더 큰 비중을 차지하게 된다.

이 문제는 흔히 information vanishing이라고 설명할 수 있다.

학습 이전에라도, 표현 자체가 고정 크기 병목(bottleneck)을 가지기 때문에 아주 긴 문맥의 세부 정보를 온전히 보존하기 어렵다.

쉽게 말해, RNN은 “시퀀스 전체를 기억하고 싶다”는 의도로 설계되었지만, 실제로는 시간이 지날수록 초반 정보가 흐려지기 쉽다.

14. RNN의 한계 2: Gradient Vanishing

RNN의 더 큰 문제는 학습 과정에서 드러난다.

역전파 시에는 시간축을 따라 기울기가 뒤로 전달되는데, 이 과정에서 작은 값들이 반복적으로 곱해지면 gradient가 점점 0에 가까워진다. 이것이 gradient vanishing이다. 반대로 큰 값이 반복되면 gradient exploding이 발생할 수 있다.

직관적으로 보자면, 입력항과 비선형성을 잠시 무시하고 recurrent weight만 단순화해 생각하면,

와 비슷한 형태를 떠올릴 수 있다.

여기에 역전파에서는 \tanh의 미분값까지 반복적으로 곱해진다. 그런데 \tanh의 미분은 0과 1 사이 값이므로, 이 값이 여러 시점을 거쳐 계속 곱해지면 gradient는 쉽게 작아진다.

결국 문장 초반 단어가 현재 예측에 중요하더라도, 그 정보는 학습 시점에 충분한 gradient를 받지 못해 잘 학습되지 않는다. 이 때문에 표준 RNN은 긴 문맥을 이론적으로는 다룰 수 있지만, 실제 학습에서는 장기 의존성을 잘 잡지 못하는 경우가 많았다.

15. LSTM: RNN의 한계를 완화한 구조

이 문제를 해결하기 위해 등장한 대표적인 구조가 LSTM(Long Short-Term Memory) 이다.

Olah의 설명처럼 LSTM은 기본 RNN에 비해 훨씬 정교한 구조를 가지며, 핵심은 cell state와 여러 gate를 통해 정보의 보존·삭제·추가를 제어하는 데 있다.

LSTM의 cell state 업데이트는 대표적으로 다음과 같이 표현된다.

여기서,

이 식의 중요한 점은, 단순 RNN처럼 매 시점 완전히 새로 hidden state를 덮어쓰는 것이 아니라, 기존 기억을 얼마나 남길지와 새 정보를 얼마나 넣을지를 gate로 조절한다는 것이다. 그 결과 gradient가 훨씬 안정적으로 흐를 수 있고, 표준 RNN보다 장기 의존성을 더 잘 학습할 수 있다. Olah도 실전에서 흥미로운 RNN 성능의 대부분이 사실상 LSTM에 의해 가능해졌다고 설명한다.

다만 LSTM도 완전한 해결책은 아니었다. 시퀀스를 여전히 순차적으로 처리해야 하므로 병렬화에 한계가 있고, 아주 긴 문맥을 다루는 데에는 여전히 구조적 부담이 남아 있었다. 이후 이러한 한계를 더 효과적으로 해결한 것이 Attention과 Transformer다.

16. 정리: 왜 N-gram에서 RNN으로 발전했는가

지금까지의 흐름을 한 번에 정리하면 이렇다.

N-gram

짧은 문맥의 빈도를 세어 다음 단어 확률을 추정한다.

직관적이고 강력했지만, 희소성 문제와 긴 문맥 처리의 한계가 있었다.

NPLM

단어를 임베딩 벡터로 바꾸어 단어 간 유사성을 반영했다.

희소성 문제를 완화했지만, 여전히 고정 길이 문맥만 사용했다.

RNN

이전 hidden state를 현재 계산에 재사용하는 순환 구조를 도입해, 시퀀스 전체 문맥을 다루려 했다.

하지만 information vanishing과 gradient vanishing 문제가 발생했다.

LSTM

cell state와 gate 구조를 통해 장기 의존성 문제를 완화했다.

그러나 순차 처리 구조 자체의 한계는 남아 있었다.

결국 언어 모델의 발전사는 더 긴 문맥을 더 안정적으로, 더 일반화 가능하게 다루려는 시도의 역사라고 볼 수 있다.

17. 마무리

처음 언어 모델은 문장 전체 확률을 계산하는 문제로 출발했지만, 실제로는 이를 각 시점의 다음 단어 예측 문제로 분해해 다뤄왔다. 그 과정에서 N-gram은 매우 단순하면서도 강력한 통계적 방법이었고, NPLM은 임베딩을 통해 단어 유사성을 반영했으며, RNN은 고정 길이 문맥의 한계를 넘기 위해 순환 구조를 도입했다.

하지만 RNN 역시 긴 시퀀스에서 정보를 안정적으로 전달하는 데 한계가 있었고, 이를 완화한 LSTM을 거쳐 결국 Attention과 Transformer로 흐름이 이어지게 된다.

즉, Language Model의 발전은 결국 “문맥을 얼마나 잘 기억하고 활용할 수 있는가”를 둘러싼 발전사라고 정리할 수 있다.

[AWS] ECS는 Running인데 계속 Unhealthy? ALB Health Check 실패의 진짜 원인 (보안그룹 아웃바운드 문제) (Product : SpeakNote)

yeseul-kim01 — Mon, 16 Feb 2026 03:12:44 +0900

이번에 Next.js 프론트를 ECS Fargate + ALB 구조로 배포하면서 이상한 현상을 겪었다.

컨테이너는 분명히 살아있는데 ECS는 계속 태스크를 죽이고 다시 올렸다.

증상

ECS 서비스 이벤트 로그

task ... port 3000 is unhealthy in target-group ... reason: Health checks failed Amazon ECS replaced 1 tasks due to an unhealthy status.

그리고 무한 반복.

태스크 → 실행됨
Target group → Unhealthy
ECS → 태스크 교체
다시 Unhealthy
또 교체

무한 루프

1차 의심: 컨테이너 문제?

ECS Exec으로 직접 들어가서 확인했다.

200

/ health /api/health

전부 200

컨테이너 내부에서는 완벽히 정상

2차 의심: HTTPS 리다이렉트 문제?

ALB에서

80 → 443 리다이렉트
443 → target group

구성.

Next.js가 HTTPS 강제 리다이렉트 해서 Health check가 301 받는 건가 의심을 해봤는데

헤더 강제로 넣어서 테스트를 해도

Host: dev.speaknote.site X-Forwarded-Proto: https

→ 여전히 200.

리다이렉트 문제 아님.

3차 의심: Target Group 설정?

Health check path → /
→ /health
→ /api/health

다 바꿔봤다.

여전히 Unhealthy.

진짜 원인: ALB 보안그룹 아웃바운드

여기서 깨달았다.

ALB 보안그룹 상태

인바운드

443 허용 (내 IP만)

아웃바운드

443만 허용

문제는 여기.

ALB는 443으로만 통신하지 않는다

ALB는 클라이언트와는 443으로 통신하지만,

타겟(ECS)으로는

타겟 포트(여기서는 3000) 로 접속한다.

즉,

ALB → ECS : TCP 3000

그런데 ALB 보안그룹 아웃바운드가

TCP 443 only

로 되어 있었다.

그럼 ALB는 타겟으로 연결 자체를 못한다.

Health check도 못하고
Forward도 못한다.

해결 방법

ALB 보안그룹 수정

Outbound: TCP 3000 → ecs-service 보안그룹

또는

All traffic → 0.0.0.0/0 (개발 환경이면 이게 편함)

수정하자마자

Target group → Healthy
ECS 교체 루프 종료
정상 접속

끝.

왜 내부에서는 200이었을까?

컨테이너 안에서는

curl localhost:3000

정상.

하지만 ALB는

ALB → ECS (3000)

이 경로가 보안그룹에 막혀 있었음.

즉,

앱은 정상
네트워크가 막혀있던 것

정리

ECS에서 Unhealthy 뜨면 무조건 앱 문제부터 의심하는데
이번 케이스는 완전히 네트워크였다.

체크 순서

컨테이너 내부 200 확인
Target group path 확인
리다이렉트 여부 확인
ALB 보안그룹 아웃바운드 확인 ← 이게 핵심

오늘의 교훈

ALB는 클라이언트와 443으로 통신하지만
타겟과는 “타겟 포트”로 통신한다.

이걸 안 열어두면
헬스체크는 영원히 실패한다.

개 뻘~~~~짓을 했고,, 나는 또 새벽 3시에 잠들지만,,,, 한가지를 알아가서 행복하다..

[AWS - ECS & ALB]ECS + ALB+RDS 기반 서비스 아키텍처 정리

yeseul-kim01 — Tue, 10 Feb 2026 10:26:00 +0900

[ Internet ]
     |
     v
[ Route53 ]
     |
     v
[ ALB ]  ← (여기에 WAF를 "나중에" 붙일 예정)
     |
     v
[ ECS Fargate ]
     |
     v
[ Spring Boot App ]

이번 글에서는 특정 기능 구현 이야기가 아니라,
Spring Boot 기반 API 서버를 SaaS 구조로 설계하고 AWS 상에 배포하면서 고민했던 아키텍처 포인트를 정리해보려 한다.

단순히 애플리케이션을 배포하는 것을 넘어, 멀티테넌시 구조, 무중단 배포 전략, 헬스체크 설계, 네트워크 경계 설정, 관찰성까지 고려한 “운영 가능한 구조”를 목표로 설계했다. (트래픽 분산처리는 하지 않음.)

EC2 vs ECS

초기에는 EC2에 직접 배포할지, ECS를 사용할지 고민했다.

Spring Boot 애플리케이션은 어차피 Docker 컨테이너로 패키징할 예정이었고,
운영 환경 또한 컨테이너 단위로 관리하고 싶었다.

EC2를 선택한다면 다음을 직접 관리해야 한다.

OS 패치 및 보안 업데이트
Docker 런타임 관리
인스턴스 스케일링 전략
로드밸런서 및 네트워크 구성
배포 시 인스턴스 단위 교체 전략

반면 ECS(Fargate)는 컨테이너 실행에 집중할 수 있는 환경을 제공한다.

Docker Image → ECR → ECS Service

구조로 배포하면, 인프라 레벨의 서버 관리 부담을 크게 줄일 수 있다.

ECS를 선택한 이유

컨테이너 중심 아키텍처와의 정합성

이미 Docker 기반으로 설계했기 때문에,
컨테이너를 1급 실행 단위로 취급하는 ECS가 자연스러운 선택이었다.

EC2 위에서 Docker를 직접 관리하는 것보다,
컨테이너 오케스트레이션 레이어를 활용하는 것이 구조적으로 명확하다고 판단했다.

비용 관점

이번 서비스는 트래픽이 일정하지 않고, 고정적으로 인스턴스를 상시 유지할 필요가 없었다.

Fargate는

인스턴스 예약 불필요
사용한 리소스만 과금
초기 운영 비용 부담 감소

라는 장점이 있었다.

EC2는 유연성이 높지만, 소규모 SaaS 서비스에서는 오히려 관리 오버헤드가 더 클 수 있다고 판단했다.

네트워크 및 라우팅 구성의 편의성

ECS + ALB 구조

Internet
  ↓
ALB
  ↓
Target Group
  ↓
ECS Task

이 구조는

헬스체크 기반 트래픽 제어
무중단 배포 (Rolling Update)
네트워크 경계 분리 (ALB SG → ECS SG)
향후 스케일아웃 확장

를 지원하기 때문에 EC2 단독 구성보다, 운영 관점에서 구조적 안정성을 확보하기 쉬웠다.

ALB를 선택한 이유

우선 서비스를 계속 운영 하되 , 비용적인 부분에서 최소화를 하고 싶었기 때문에
ip 접속 제한이 필수였다. 만약 ec2 일 경우에는 엔진엑스 설정을 통해 블랙 화이트 리스트를 설정하면 됐지만, ecs로 배포하기로 마음을 먹었기 때문에 ALB + WAF 의 경우를 생각해서 ALB를 선택했다.

(추후 ip 제한을 달기 위해서 현재는 적용하지 않았음.)

설정 순서

Step A. RDS(Postgres) 만들기 (DB 먼저)
Step B. ECR에 Spring 이미지 푸시
Step C. ECS Fargate + ALB(HTTPS)로 서비스 오픈
Step D. Route53에서 fileext.yeseulkim.cloud → ALB 연결
Step E. (나중에) WAF로 IP 제한 ON

우선 들어가기 전에 로컬에서 먼저 해둔 설정들 부터 정리해보자면

로컬에서의 기본 설정

들어가기 전, 기본적으로 도메인을 따로 구매해놔야 한다. (가비아에서 구매함! )

서버는 모놀로식으로 구성했기 때문에, 여러개를 할 필요 없이 ECR 에 올릴 하나의 도커 이미지만 연결하면 됐었다.

내 컴퓨터 로컬 환경에서 aws 로그인이 가능해야 한다. (왜냐면 이미지 빌드 한 뒤에 올리는 과정 때문... 여러개의 방법이 있었는데 처음은 키 발급이었음.)

ECS 배포에 들어가기 전에, 단순히 콘솔을 여는 것보다 먼저 준비해야 할 것들이 있다.
이 단계를 정리하지 않으면 이후 과정에서 권한 오류, 네트워크 오류, 이미지 푸시 실패 같은 문제가 반복된다.

AWS 계정 및 IAM

루트 계정으로 작업하지 않기

운영 환경에서는 루트 계정 대신 IAM User를 생성하여 작업해야 한다.

필수 권한 예시

ECR Full Access
ECS Full Access
Elastic Load Balancing
IAM Role 관리 권한
CloudWatch Logs 권한

AWS CLI 설치 및 로그인

로컬에서 Docker 이미지를 ECR에 업로드해야 하므로
AWS CLI 설정은 필수다.

aws configure

입력 항목

AWS Access Key
AWS Secret Key
Default Region (ex: ap-northeast-2)
Output format (json 권장)

확인

aws sts get-caller-identity

정상적으로 계정 ID가 나오면 설정 완료.

ECS Service Linked Role 생성

ECS가 내부적으로 ALB, Target Group 등을 연결하기 위해 필요한 역할이다.

aws iam create-service-linked-role --aws-service-name ecs.amazonaws.com

이미 있다면 에러가 나지만 무시해도 된다.

Docker Desktop 실행 확인

ECR 로그인 및 이미지 푸시 전 반드시 확인해야 한다.

docker ps

여기서

Cannot connect to the Docker daemon

오류가 나오면 Docker Desktop이 실행되지 않은 상태다.

Mac(M1/M2)의 경우 반드시 실행 후 다시 시도해야 한다.

빌드 시 주의할 점!!!!!!!!
OS 에 따라 안돌아갈수도 있기 때문에,
docker buildx build \
  --platform linux/amd64 \
  -t ${ECR_URI}:latest \
  --push \
  .
나는 위의 방식으로 빌드를 진행했음!

ECR 로그인

Docker 이미지를 AWS ECR에 업로드하기 위해 로그인한다.

aws ecr get-login-password --region ap-northeast-2 \
| docker login --username AWS --password-stdin <ACCOUNT_ID>.dkr.ecr.ap-northeast-2.amazonaws.com

로그인이 성공하면

Login Succeeded

가 출력된다.

도메인 준비

Route53 사용할 거임
ALB Alias 레코드 연결할 거

를 이용할 거기 때문에 미리 도메인을 구매해놔야 된다.

(도메인 등록은 aws 에서 프리티어 계정에는 지원을 안하는걸로 알고있기 때문에 참고하여 설정하시길!)

클라우드 세팅

앞서 로컬에서의 기본 세팅을 마쳤으면, 클라우드 세팅을 미리 해두는게 좋을 거 같다.

중심으로 본거는 네트워크와 보안 쪽이다. (잘 올려도 여기서 연결이 잘 안되면 호스팅 자체가 안됨.)

보안 & 네트워크

나는 우선 default VPC 를 선택했다. (단순 포폴용이기 때문에)

그래도 보안그룹은 따로 나눠놔야된다. (안그러면 ECS 용과 RDS 가 섞여버림.)

즉 설정해둔 VPC 에 총 3개의 보안그룹을 생성해둔다.

SG-ALB (예: sg-alb-(프로젝트명))

ALB public inbound

Inbound: 80, 443 from 0.0.0.0/0
Outbound: all

Inbound Rules

HTTPS

443

0.0.0.0/0

외부 사용자 접속 허용

※ HTTP(80)는 HTTPS 리다이렉트용이면 80 추가 가능
※ 그 외 모든 포트는 차단

Outbound Rules (ALB → ECS 통신 허용)

All traffic

All

0.0.0.0/0

SG-ECS (예: sg-ecs-(프로젝트명))

Inbound: 8089 from SG-ALB
Outbound: all (RDS 붙이면 5432는 아웃바운드에서 자동 OK)

Inbound Rules (ALB → ECS)

TCP

8089

위에서 만든 보안 그룹

ALB에서만 접근 허용

0.0.0.0/0 금지
직접 외부 접근 차단

Outbound Rules (ECS → RDS 통신 허용)

All traffic

All

0.0.0.0/0

여기서 선택한 소스가 sg-alb 보안그룹임

SG-RDS (예: sg-rds-(프로젝트명))

Inbound: 5432 from SG-ECS
Public access: No

Inbound Rules

PostgreSQL

5432

ECS SG

ECS에서만 DB 접근 허용

VPC 전체 허용 금지
default SG 허용 금지
0.0.0.0/0 절대 금지

Outbound Rules

기본값 유지 (All traffic 허용)

Internet
   ↓ 443
ALB (Public Subnet)
   ↓ 8089 (SG로 제한)
ECS Fargate (Private)
   ↓ 5432 (SG로 제한)
RDS (Private)

ACM 인증서 발급 & Route53 설정하기

위의 보안그룹설정이 마쳤다면, 편하게 도메인 연결을 하기 위해서 Route 설정과 ACM 인증서를 먼저 발급해둔다.

여기서 만들어둔 인증서는 나중에 loadbalancer 에 붙음. 인증서 발급을 요청하면 도메인의 CNAME 이 나오는데 이걸 Route53에 붙여줘야 된다.

첫번째로 해야될것은 route 53의 host zone 생성이다.

생성 시에 ns 레코드 4개의 네임서버가 나오는데, 나는 DNS 관리를 가비아에 들어가서 매일 하기 귀찮을 듯 해 네임서버를 가비아에 등록해서, DNS 관리를 route 53에서 진행할 수 있게 했다.

이렇게 설정을 해두면 이제 route 53 에서 DNS 관리를 할 수 있음!

두번째로 해야될 설정은 HTTPS 인증서 발급이다.

ACM (Certificate Manager) 에 접속 (설정 시 나는 ALB나 전체 서비스의 리전을 단일로 했음. 서울로 선택!)

인증서 요청할 때의 주의사항은 *.~~.~~ 는 빼야된다.. (비용 폭탄됨)

인증서 요청 후에는 CName 레코드가 나오는데 이제 그걸로 Route 53 의 도메인에 레코드로 등록해주면 되고,

기다리다보면 인증서의 상태가 변경된다.

ECS + ALB+RDS

기본적인 세팅을 마쳤기 때문에 이제 전체 설정을 해줘야 된다.

(보안그룹 선택과 네트워크는 위에서 설정해뒀던걸 잘 기억하며 선택하면 됨.)

위에서 설정한 aws cli 를 통해, ecr에 이미지를 배포해야 된다.

해당 ECR 에 들어가서 실제로 존재하는지 확인을 한다. (배포과정에 대한 설명은 생략,, gpt가 잘 알려줌 ㅜ)

이미지가 무사히 올라가있다면 ecs 를 하기 전에 RDS 먼저 설정을 해보려 한다.

(ecs 먼저하게 되면, 배포 중 rds 연결 에러가 뜨기 때문에... )

RDS 연결

우선 일단 RDS 연결 먼저 해두려고 한다. (ECS 올릴 때 에러 피하기 위함임..미리 안해두면 재빌드가 되기 때문에 ㅜ)

선택은 자유지만, 나는 포폴용으로 올리는 예시기 때문에 비용이 최저로 나올 수 있게 올렸다.

마스터 사용자 이름이나 암호는 Spring의 (백엔드서버) 프로포티에 입력해둔 값들로 적으면 된다.

네트워크 같은 경우는 default VPC 보다는 따로 프로젝트용 설정을 권장하는데 굳이 여러개의 프로젝트를 올릴게 아니라면, 기본을 사용해도 된다. (하지만 보안 그룹은 분리해야함.)

퍼블릭 액세스 같은 경우는 인터넷에 직접 노출할지 말지를 결정하는 용도인데, 개발용에 외부 통신이 필요하다면 오픈해도 되지만, 나는 내부 통신으로만 열어뒀다. 만들고 나서 나오는 RDS 의 엔드포인트로 spring에서 접근하기 떄문에 저장해놔야 된다.

ECR에 Spring 이미지 푸시하기

RDS 를 마쳤다면, 이제 docker build 를 해야할 차례!
Spring boot 던 python이던 환경변수 파일 설정은 중요하다. 우선 Spring 기준으로 해둔 설정들만 공유해보면

.env.prod 모드에는 RDS 정보값 입력, cors 다시한번 확인하기!

ECS 로 클러스터 만들기

클러스터를 만들 때 주의할 점은 health check 부분,,

태스크를 만들게 되면 loadbalancer 설정을 하게 되는데 이때 리스너 규칙에 설정하는 헬스체크의 시간대를 잘 지정해둬야 된다.

Health Check Interval & Threshold

기본값으로 두면 배포 직후 바로 Unhealthy로 빠지는 경우가 있다.
Spring Boot는 기동 시간이 있기 때문에,
기본 Health Check 설정으로 두면 애플리케이션이 완전히 올라오기 전에 ALB가 Unhealthy로 판단해버린다.

이 경우 다음과 같은 문제가 발생할 수 있다.

배포 직후 태스크가 반복적으로 재시작됨
Rolling Update가 제대로 동작하지 않음
서비스가 순간적으로 0개 태스크 상태가 됨
무중단 배포 실패

그래서 나는 다음과 같이 설정했다.

Interval: 30초
Timeout: 5초
Healthy threshold: 2
Unhealthy threshold: 5

이렇게 하면 애플리케이션이 완전히 기동될 시간을 확보할 수 있고,
배포 시에도 트래픽이 기존 태스크에서 신규 태스크로 자연스럽게 넘어간다.

헬스체크는 단순히 “살아있나?”를 확인하는 기능이 아니라,

무중단 배포를 가능하게 하는 핵심 장치
트래픽 흐름을 제어하는 스위치
장애 감지의 1차 필터

역할을 한다.

ECS + ALB 구조에서는
헬스체크 설계가 곧 운영 안정성 설계라고 봐도 무방하다.

최종 아키텍처 정리

Internet
↓ 443
ALB (Public Subnet)
↓ 8089 (SG 제한 + Health Check)
ECS Fargate (Private)
↓ 5432 (SG 제한)
RDS (Private)

외부 직접 접근 차단
내부 통신만 허용
HTTPS 강제
DB 비공개
헬스체크 기반 트래픽 제어

[GCP] egress 비용 폭증 원인 분석 -> 아키텍처 재설계 (Product : SpeakNote)

yeseul-kim01 — Sat, 31 Jan 2026 04:59:35 +0900

문제 배경

SpeakNote를 GCP 환경에서 운영하던 중,
GCP Billing 리포트에서 Network egress 비용이 비정상적으로 급증한 것을 확인했다.

트래픽이 갑자기 폭증한 것도 아니고,
기능을 대규모로 추가한 시점도 아니었기 때문에 단순 사용량 증가로 보기에는 이상한 상황이었다.

조사를 진행하면서 egress 비용 증가의 원인은 하나가 아니라 여러 개라는 것을 알게 되었다.

Docker 이미지 빌드 시 캐시 없이 반복 빌드되던 문제
외부 AI API 연동 구조
그리고 GCP 네트워크 아키텍처 자체의 문제

이 글에서는
아직 해결 중인 빌드/코드 레벨 이슈는 제외하고, GCP 아키텍처 재배포로 실제 비용을 줄인 과정만 정리한다.

초기 상황: “같은 서버끼리 통신하는데 왜 egress가 나가지?”

SpeakNote는 다음과 같은 구성으로 배포되어 있었다.

GCP Load Balancer
단일 VM 인스턴스
VM 내부에서 Docker Compose로
- Frontend
- Spring Boot
- FastAPI
- Redis / DB 컨테이너 실행

겉보기에는 단순한 구조였지만,
문제는 네트워크 트래픽 경로에 있었다.

서비스 간 통신이 모두 Load Balancer를 기준으로 구성되어 있었고,
이로 인해 다음과 같은 일이 발생했다.

같은 VM 내부 컨테이너 간 통신임에도
트래픽이 외부 → LB → 다시 VM 으로 돌아오는 구조

즉, 논리적으로는 내부 통신이지만
GCP 입장에서는 egress + ingress 트래픽으로 계산되는 구조였다.

원인 정리: egress는 “트래픽 양” 문제?

이슈를 분석하면서 가장 크게 느낀 점은 이것이었다.

egress 비용은
“데이터를 많이 보내서” 생기는 게 아니라
“어디로 보내느냐”에 따라 발생한다

기존 구조에서는

내부 서비스 호출
헬스체크
WebSocket 연결 유지 트래픽

같은 것들조차
외부 네트워크 경로를 타고 다시 들어오는 구조였고,
이 트래픽들이 모두 비용으로 누적되고 있었다.

해결 전략: 아키텍처 구조 수정

이 문제는 코드 최적화만으로는 해결할 수 없다고 판단했다.

요청 수를 줄여도 근본 원인은 그대로
API 호출을 줄여도 내부 통신 egress는 계속 발생

그래서 선택한 방법은 아키텍처 재배포였다.

핵심 전략은 단순했다

내부 통신은 무조건 internal/private 경로로
외부 노출이 필요한 엔드포인트만 Load Balancer에 연결
VM 내부 서비스 간 호출은
- localhost
- docker network
- private IP 기준으로 통일

즉,

“외부 공개용 트래픽”과
“내부 서비스 간 트래픽”을 명확히 분리

핵심 전환점: Global Load Balancer → Regional Load Balancer

egress 비용을 본격적으로 분석하면서,
가장 먼저 의심하게 된 지점은 Load Balancer의 스코프였다.

기존 SpeakNote는 Global HTTP(S) Load Balancer를 사용하고 있었다.

기존 구성의 문제점

Global Load Balancer는 이름 그대로 전 세계 엣지(Edge)를 기준으로 동작한다.
이 자체는 글로벌 서비스를 운영할 때는 매우 강력한 장점이지만,
현재 SpeakNote의 상황에는 과한 선택이었다.

기존 구조에서는 다음과 같은 문제가 있었다.

트래픽이 글로벌 엣지 → 리전 → VM 경로를 탑
같은 리전에 있는 서비스 간 통신임에도
cross-region / global routing으로 인식될 여지
결과적으로 내부 통신 성격의 요청까지
egress 비용으로 잡히는 구조

즉,

“글로벌 확장을 고려한 인프라”가
“단일 리전 서비스”에는 오히려 비용 리스크가 된 상황

변경 결정: Global LB를 버리고 Regional LB로

SpeakNote의 실제 사용 시나리오는 다음과 같았다.

단일 리전(GCP 한 리전)에서만 서비스 운영
글로벌 트래픽 분산, Anycast 라우팅 필요 없음
지연(latency)보다 비용 안정성이 더 중요한 단계

구조 변화 한눈에 보기

Before (Global LB 기반)

상단을 보면 Asia / America / Europe 등
글로벌 엣지(Edge) 위치에서 트래픽이 유입되고 있다.

실제 사용자는 대부분 Asia 리전에 있음
그럼에도 Global LB 특성상
- 글로벌 엣지를 기준으로 라우팅
- 리전 간 개념이 개입될 여지 존재

즉,
단일 리전 서비스임에도 글로벌 네트워크 비용 구조를 그대로 안고 있는 상태였다.

Client → Global Edge
Edge → Region → VM
내부 통신도 LB 경유
egress 발생 지점이 불명확

After (Regional LB 기반)

Client → Regional LB → VM
내부 서비스 간 통신은 private 경로
외부/내부 트래픽 역할 분리
egress 발생 지점 명확

이 결정을 통해 얻은 교훈

Global LB는 항상 좋은 선택은 아니다
서비스 규모·운영 단계에 맞는 인프라 선택이 중요
GCP egress 비용은
트래픽 양보다 라우팅 구조의 문제인 경우가 많다

SpeakNote에서는
Global → Regional LB 전환이
egress 비용 문제를 해결할 가장 큰 분기점..이었음 좋겠다...

[GCP - egress] GCP 요금 폭증 – Egress 트래픽 추적기(Product : SpeakNote)

yeseul-kim01 — Fri, 30 Jan 2026 23:01:25 +0900

SpeakNote 프로젝트의 고도화 기간 중, 기존에는 로컬로만 테스트를 돌렸었는데

아무래도 운영 환경에서의 테스트도 중요할 거 같아 배포를 미리 해두기로 마음을 먹었다.

다만, 1월 24일경 시작을 했는데 크레딧의 반절을 써버림.. (뭔가 단단히 잘못됨..)

한번도 이랬던 적이 없어서 우선 인스턴스를 중지 시킴.

(고정 ip 와 디스크로 몇천원 결제되는게 더 나을 듯해서...)

우선 요금이 폭등하게 된 원인부터 찾으려 함.

Google cloud 의 billing -> 보고서를 클릭

오잉??

그룹화 기준을 날짜 > SKU 로 변경 (1월 29일날 인스턴스 중지를 시켰습니다. 나온 974는 아마도 고정 ip와 디스크 값이겠죵?)

뭔지 정확히 확인하기 위해 csv 다운로드를 클릭합니다. (27일만 많이 나온게 아니라 28일도 많이 나온것으로 확인이 됨.)

1월 28일자 원인

1월 27일자 원인

Vm의 스펙에 따른 가격은 대충 예상한대로 나온거라 큰 의미는 없지만,

비용의 대부분 = Compute Engine Network Egress

이게 문제인 거 같습니다.

Metrics Explorer 에 들어가서 리소스 선택을 VM instance 에 두고, Egress bytes 를 선택

그렇다면 구성한 FastAPI 쪽 서버 (Upstage API 를 사용하고 있음) 의 문제일 거 같은데

가장 가능성 있는게

1. Docker build (노 캐시)
2. Upstage Parser , 임베딩 api 연결

이 두 부분이 문제일 거 같음.

코드 수정은 다음 파트에서 다루겠음.

[GCP - ssh] Compute Engine SSH 접속 실패 원인과 해결 – 콘솔 SSH로 직접 고친 방법 (Product : SpeakNote)

yeseul-kim01 — Wed, 28 Jan 2026 18:50:13 +0900

SSH 키 등록했는데 로컬에서 접속이 안 됐던 문제 (해결까지 한 번에 정리)

Compute Engine 인스턴스를 생성하면서
초기 설정 화면에서 SSH 공개키를 분명히 등록했습니다.

하지만 인스턴스 생성 이후, 로컬 터미널에서 다음과 같이 접속을 시도했을 때

ssh user@<외부 IP>

SSH 접속이 정상적으로 이루어지지 않았습니다.

즉,

VM 생성 단계에서 SSH 키를 넣었음
GCP 콘솔에서는 인스턴스가 정상적으로 떠 있음
그런데 로컬 터미널에서는 SSH 접속 실패

라는 상황이었습니다.

당시 문제 상황 정리

이 시점에서 확인했던 사항은 다음과 같습니다.

VM에는 외부 IP가 정상적으로 할당되어 있었고
방화벽에서도 22번 포트는 열려 있는 상태였으며
SSH 키 자체도 로컬에 정상적으로 존재했습니다

즉, 네트워크나 포트 문제라기보다는 SSH 키 적용 방식 문제로 판단했습니다.

원인으로 판단한 부분

GCP에서는 SSH 키를 등록하는 위치가 여러 군데 존재합니다.

VM 생성 시 입력하는 SSH 키
프로젝트 메타데이터(Project-wide SSH keys)
인스턴스 메타데이터(Instance-level SSH keys)

이 중에서,

생성 단계에서 입력한 SSH 키가 실제 인스턴스에 제대로 반영되지 않았거나
프로젝트/인스턴스 메타데이터 적용 우선순위 문제로
로컬 SSH 접속 시 인증이 실패한 것으로 보였습니다.

이런 경우에는
“왜 안 되는지 끝까지 파고들기”보다
가장 확실한 방식으로 키를 다시 적용하는 것이 빠르다고 판단했습니다.

실제로 사용한 해결 방법 (삽질하다가 해결방법 찾음.. 위에꺼 다 해봐도 안됐음.)

이 문제는 GCP 콘솔에서 제공하는 브라우저 기반 SSH 터미널로 먼저 접속한 뒤,
인스턴스 내부에서 SSH 키를 직접 갱신하는 방식으로 해결했습니다.

진행한 순서는 다음과 같습니다.

GCP 콘솔 → Compute Engine → 해당 인스턴스 → [SSH] 버튼 클릭
브라우저 기반 SSH 터미널로 인스턴스에 접속
접속 후, 인스턴스 내부에서 아래와 같은 방식으로
로컬에서 사용 중인 공개키를 authorized_keys에 직접 추가

mkdir -p ~/.ssh
chmod 700 ~/.ssh

nano ~/.ssh/authorized_keys

로컬에서 사용 중인 공개키(~/.ssh/id_ed25519.pub 등)의 내용을
authorized_keys 파일에 그대로 붙여넣기
저장 후 권한 설정

chmod 600 ~/.ssh/authorized_keys

브라우저 SSH 세션 종료 후, 로컬 터미널에서 다시 SSH 접속 시도

ssh user@<외부 IP>

위 과정을 거친 이후,
로컬 터미널에서 SSH 접속이 정상적으로 이루어졌습니다.

이 방식이 효과적이었던 이유

VM 생성 단계에서 등록한 SSH 키가
메타데이터/계정 생성 과정에서 정상 반영되지 않은 상태였고
인스턴스 내부의 authorized_keys 파일에는
실제로 유효한 키가 존재하지 않았던 상황이었습니다

그래서

GCP 메타데이터를 우회
인스턴스 내부 SSH 인증 파일을 직접 수정하여
SSH 인증 경로를 명확하게 맞춘 것이 핵심이었습니다

참고로 정리해두는 포인트

SSH 접속이 안 될 때
“키를 어디에 넣었는지”보다
~/.ssh/authorized_keys에 실제로 키가 들어가 있는지가 더 중요합니다.
브라우저 SSH는 되는데 로컬 SSH가 안 되면
거의 대부분 이 파일 문제로 귀결됩니다.

정리

Compute Engine 생성 시 SSH 키를 넣었음에도
로컬 SSH 접속이 되지 않는 경우가 발생할 수 있음
이때는 복잡하게 원인을 모두 추적하기보다는
- 인스턴스 수정 → SSH 키 직접 등록
  방식이 가장 확실한 해결책이었습니다.

SSH 접속 문제 없이 서버 설정, 포트별 서비스 실행, Load Balancer 설정을
정상적으로 진행할 수 있었습니다.

[GCP - global LB & compute Engine] GCP 서버 구성 기록 (default VPC + 전역 로드밸런서 기반)(Product : SpeakNote)

yeseul-kim01 — Wed, 28 Jan 2026 02:35:28 +0900

Compute Engine 생성부터 전역 Load Balancer 연결까지

본 글은 SpeakNote 서비스를 GCP 환경에 배포하면서
Compute Engine 생성 → SSH 접속 → 서비스 실행 → Load Balancer 선택 및 설정 → 도메인 연결
까지의 과정을 순서대로 기록한 글입니다.

설계 배경보다는 실제로 어떤 설정을 했는지를 중심으로 정리합니다.

나중에 운영 서버는 AWS 에서 진행할 거지만,, (Upstage 와 제휴업체인걸로 알고있어서!)

AWS 는 현재 start up 신청 대기 중이기 때문에, 개발 단계는 GCP 로 진행을 하려 합니다.

GCP 계정 설정

처음 가입하면 , First Project 라고 뜨는걸로 알고있는데, 우선 저는 프로젝트별 관리를 편안히 하기 위해 새프로젝트를 만들었습니다.

Compute Engine 인스턴스 생성

먼저 GCP 콘솔에서 Compute Engine 인스턴스(VM) 를 생성했습니다.

기본 설정

리전: asia-northeast3 (서울)
머신 유형: e2 계열 (CPU/메모리는 서비스 규모에 맞게 선택)
부팅 디스크
- OS: Ubuntu 22.04 LTS
- 디스크 유형: 표준 영구 디스크
외부 IP: 고정 IP 할당

SpeakNote는 실시간 처리 요소(WebSocket, AI API 호출 등)가 포함되어 있어
프리티어보다는 안정적인 리소스 확보를 우선했습니다.

여기서 주의할점은

1. 네트워크 설정

만약에 네트워크를 처음부터 본인이 만들거라면,, default 가 아니라,

vpc 네트워크에서 한개 만들어준다음 설정하세요. (나중에 가서 수정 안됨.)

2. 부팅 디스크 설정

만약에 Spring 서버를 돌려야 돼서 , java 실행 명령어가 필요하면 Ubuntu 로 하시는게 좋습니다.

3. 외부 IP 고정 할당

Lb 를 다실거면, 굳이 할 필요는 없습니다! (나중에 lb 설정 시 고정 ip 설정하는게 있음.) 하지만 , VM 자체에 접속해서 테스트를 자주해야된다! 하시면 설정하시는게 좋습니다.

(저는 개발용이라 설정해놨습니다. 왜냐면 mysql , redis를 제 로컬에서 확인하기 좀더 수월히 하기 위해서, 그리고 홉스카치를 통해 직접 요청해보려고요..)

4. 머신 유형 설정

머신 유형은 단순히 “CPU/메모리”만 보지 말고,

서버에 설치할 구성 요소
Docker 컨테이너 개수
로그, 캐시, 이미지 용량

까지 전체 리소스 사용량을 고려해서 선택하시는 것이 좋습니다.

특히

Spring + AI 서버 + 프론트엔드를 한 VM에서 돌릴 경우

메모리는 생각보다 빨리 부족해질 수 있습니다

Compute Engine 접속을 위한 SSH 키 설정

VM 생성 시 기본 설정 화면에서 SSH 공개키를 등록했습니다.

로컬에서 SSH 키 생성
생성한 공개키를 VM 생성 화면의 SSH 키 항목에 등록

이론적으로는 이 설정만으로

ssh user@<외부 IP>

형태의 접속이 가능해야 합니다.

(지금까지 이렇게 잘 해왔었는데... 이번엔 안되더라구요..? 왜인지 이유는 찾지 못했음.)

실제로 겪었던 문제

하지만 제 경우에는,

VM 생성 시 SSH 키를 분명히 등록했음에도
로컬 터미널에서 SSH 접속이 정상적으로 되지 않는 문제가 발생했습니다.

그래서 이 단계에서는

GCP 콘솔의 “인스턴스 수정 → SSH 키 직접 수정” 방식으로 우회해서 해결했습니다.

이 SSH 이슈와 해결 과정은 별도의 게시물로 정리할 예정이라,
본 글에서는 “이런 이슈가 있었고, 콘솔에서 SSH 키를 수정하는 방식으로 해결했다”는 기록만 남깁니다.

무사히 접속 성공...!!! VS 에 설정하는 방법도 다른 게시물에서 다루겠습니다.

SSH 접속이 가능해진 이후에는, VM 내부에서 각 서비스들을 포트별로 실행했습니다.

프론트엔드 (Next.js): 3000
백엔드 (Spring Boot): 8080
AI 서버 (FastAPI): 8000

여기서 주의할 점!

1. Docker 올리기 전

도커 파일에 꼭꼭,, 캐시 활성화를 해두세요!!!(안그럼 요금 폭탄 맞음. 배포 할 때 마다)

2. health api 세개를 각 서버별 만들어두세요 (next -> /health , fast-> /fastapi/health , spring -> /api/heath 로 해둠)

3. cors 설정은 미리 바꿔놓던 .env 로 빼두세요.. 안그럼 다시 re build 해야 합니다.

이 단계에서는 서비스 실행 자체보다는,

각 포트에서 정상적으로 LISTEN 상태인지
컨테이너/프로세스가 정상 기동되었는지

를 확인하는 것이 목적이었습니다. (나중에 health check를 LB에서 진행을 하기 때문에 미리미리 올려놨습니다! )

localhost:3000 접속 확인

서비스 실행 후, SSH 터널링 또는 VM 내부에서 직접

http://localhost:3000

으로 접속하여 프론트엔드가 정상적으로 뜨는지를 먼저 확인했습니다.

이 단계까지 완료되면,

서버 내부에서 서비스는 정상 기동
문제는 “외부에서 어떻게 접근할 것인가”로 넘어가게 됩니다.

Nginx vs Load Balancer 고민

다음 단계에서 고민했던 선택지는 두 가지였습니다.

VM 내부에 Nginx 리버스 프록시 구성
GCP 전역(External) HTTP(S) Load Balancer 사용

당시 상황 정리

WebSocket 기능은 아직 고도화 단계
현재는
- 파일 업로드
- 문서 임베딩 처리
- Google 로그인 연동
  까지 확인 중인 상태

그럼에도 불구하고 Load Balancer를 선택한 이유

HTTPS / SSL 인증서 관리 부담 감소
단일 도메인에서 경로 기반 분기 필요
추후 WebSocket 확장 고려
GCP에서 제공하는 관리형 인프라 활용

결과적으로 Nginx는 사용하지 않고, 전역 HTTP(S) Load Balancer를 사용하는 방향으로 결정했습니다.

전역 HTTP(S) Load Balancer 설정

Load Balancer는 External HTTP(S) Load Balancer (전역) 로 생성했습니다.

주요 설정

프론트엔드 설정 시에는 고정 ip 만들기 하시면 됩니다! (해당 lb IP 를 가지고 이제 도메인 구매한 곳에 가서 설정하면 됨.)

Backend: Compute Engine VM
Backend Service
- 포트별 서비스 연결
  - 3000 (Frontend)
  - 8080 (Backend)
  - 8000 (AI)

URL Map
- / → Frontend
- /api/* → Backend
- /fastapi/* → AI 서버

헬스 체크 설정

각 서비스별로 헬스 체크 엔드포인트를 지정했습니다.

/health 또는 /api/health
해당 포트로 접근 가능해야 함

헬스 체크 설정 후에는 반드시 방화벽에서 헬스 체크 트래픽을 허용해야 합니다. 안그럼 아예 안됩니다.

Load Balancer 사용 시 추가한 방화벽 설정

Load Balancer를 사용하는 순간,
“VM이 살아있다”와 “LB가 접근 가능하다”는 완전히 다른 문제가 됩니다.

그래서 default VPC에 다음 규칙들을 추가했습니다.

헬스 체크용 Ingress 허용
- Load Balancer 헬스 체크 소스 대역 허용
- 포트: 3000 / 8080 / 8000
LB → VM 내부 전달 트래픽 허용
- 내부 IP 대역 허용
- 이 설정이 없으면 connection timeout 문제가 발생할 수 있습니다.

이 단계에서 방화벽 설정이 누락되면,

Backend가 Unhealthy로 표시되거나
upstream connect error가 발생합니다.

가비아 도메인 연결 및 SSL 인증서 설정

도메인은 가비아(Gabia) 를 사용했습니다.

도메인 설정 단계

가비아 DNS 설정 화면 접속
A 레코드 추가
- 값: Load Balancer의 외부 IP
TTL 기본값 유지

이후 GCP Load Balancer에서:

Google Managed SSL 인증서 생성
해당 도메인을 인증서에 연결

SSL 인증서는 Load Balancer에서 종료되며,
VM 내부에서는 HTTPS 설정을 따로 하지 않았습니다.

선택) IP 제한을 걸고 싶다면?

만약 특정 IP만 접근 가능하도록 제한하고 싶다면,
방법은 두 가지입니다.

방화벽 규칙으로 Ingress 제한
- 특정 IP 대역만 허용
Cloud Armor 사용
- IP 기반 접근 제어
- 추후 WAF 확장 가능

현재 단계에서는 개발/검증 목적이므로 IP 제한은 최소한으로만 적용했고, 운영 단계에서 추가 적용을 고려하고 있습니다.

이 글에서는 SpeakNote의 GCP 서버 환경을
아주 처음 단계부터 Load Balancer 연결까지 순서대로 정리했습니다.

다음 글에서는:

SSH 키 접속 문제 상세 분석 https://ye-seul0-0.tistory.com/192

[GCP - ssh] Compute Engine SSH 접속 실패 원인과 해결 – 콘솔 SSH로 직접 고친 방법 (Product : SpeakNote)

SSH 키 등록했는데 로컬에서 접속이 안 됐던 문제 (해결까지 한 번에 정리)Compute Engine 인스턴스를 생성하면서초기 설정 화면에서 SSH 공개키를 분명히 등록했습니다.하지만 인스턴스 생성 이후,

ye-seul0-0.tistory.com

Load Balancer + 방화벽 트러블슈팅

를 다뤄보겠습니당.

[Architecture] 병목 현상을 줄이기 위한 실시간 아키텍처 설계(Project:SpeakNote)

yeseul-kim01 — Fri, 23 Jan 2026 21:06:12 +0900

병목 현상을 줄이기 위한 실시간 아키텍처 설계

— SpeakNote의 설계 선택과 그 이유

https://ye-seul0-0.tistory.com/185

[CS | 실시간 시스템] 병목이 발생하는 이유

실시간 시스템에서 병목이 발생하는 이유실시간 시스템을 처음 설계할 때 가장 많이 착각하는 부분 중 하나는“성능을 충분히 높이면 병목은 없앨 수 있다”는 생각입니다.저 역시 SpeakNote 프로

ye-seul0-0.tistory.com

이전 글에서는 실시간 시스템에서 병목 현상이 왜 필연적으로 발생하는지, 그리고 병목이 단순한 성능 문제가 아니라 구조적인 문제라는 점을 정리했습니다.

이번 글에서는 그 연장선에서, SpeakNote에서는 병목을 줄이고, 병목이 전체 시스템으로 확산되는 것을 막기 위해 어떤 아키텍처를 선택했는지를 실제 설계를 기준으로 설명하고자 합니다.

SpeakNote는 실시간 음성 입력 → STT → AI 요약 → 주석 렌더링이라는 여러 단계가 연속적으로 연결된 시스템입니다.
이 구조에서 병목은 특정 코드의 문제가 아니라, 입력 속도와 처리 속도가 다른 여러 단계가 동시에 연결되면서 자연스럽게 발생합니다.

따라서 이 시스템의 핵심 설계 목표는 다음과 같았습니다.

병목이 발생해도 전체 흐름이 무너지지 않을 것
한 사용자의 지연이 다른 사용자에게 전파되지 않을 것
실시간성을 “즉시 반영”이 아니라 “체감 가능한 지연 범위”로 정의할 것

병목을 없애는 것이 아니라,
병목이 발생하더라도 시스템이 무너지지 않도록 만든다.

SpeakNote 전체 아키텍처 개요

(Java Backend – Python Backend – Google STT Streaming 구조)

SpeakNote는 크게 세 계층으로 나뉩니다.

클라이언트 (Browser)
실시간 오디오 캡처 및 주석 렌더링
애플리케이션 계층 (Spring Boot)
WebSocket 기반 실시간 처리 + REST 기반 비실시간 처리
AI 처리 계층 (Python / FastAPI)
문서 파싱, 요약, 주석 생성 등 고비용 연산

이 중 병목 관리의 핵심은 Java Backend 내부의 세션 단위 실시간 처리 구조에 있습니다.

1. WebSocket 입력 단계: 병목은 ‘속도’가 아니라 ‘유입 제어 불가’에서 시작된다

사용자의 음성 입력은 WebSocket을 통해 Java 서버로 전달됩니다.
WebSocket은 연결 유지형 프로토콜이기 때문에, 서버가 클라이언트의 입력 속도를 직접 제어하기 어렵습니다.

즉, 사용자가 빠르게 말할수록 오디오 청크는 밀리초 단위로 계속 유입됩니다.

이 단계에서 발생할 수 있는 병목은 다음과 같습니다.

서버가 다음 단계(STT 전송)를 처리하지 못해도
오디오 입력은 계속 들어오고
결과적으로 메모리 누적 또는 지연 전파가 발생

이를 해결하기 위해 “즉시 처리” 대신 “즉시 큐잉” 구조를 선택했습니다.

2. 세션 단위 Inbound Queue: 병목을 분리하는 첫 번째 장치

각 WebSocket 연결은 서버 내부에서 독립된 SessionState로 관리됩니다.
그리고 각 세션마다 다음 구성 요소를 가지게 구성했습니다.

InboundAudioQueue
STT Text Buffer
OutboundQueue
세션 전용 워커 스레드
세션 전용 Google STT gRPC 스트림

WebSocket 핸들러는 오디오 청크를 수신하자마자 바로 InboundAudioQueue에 넣고 반환합니다.
이렇게 함으로써 WebSocket I/O 스레드는 음성 처리 로직에 의해 블로킹되지 않습니다.

이 구조의 핵심은 다음과 같습니다.

입력 폭주가 발생해도 큐까지만 영향
STT 처리 지연이 발생해도 입력 수신은 지속
세션 간 큐가 분리되어 한 사용자의 병목이 다른 사용자에게 전파되지 않음

즉, 병목을 “없앤 것”이 아니라 영향 범위를 세션 단위로 가둔 것!!

3. Google STT Streaming: 병목이 발생해도 흐름이 끊기지 않게

WebSocket 단계에서 입력 폭주(backpressure 부재)가 병목의 출발점이라면, 그 다음 단계인 Google STT 스트리밍은 “지연이 발생했을 때 시스템 전체로 전파되는가”를 결정하는 구간이다. 특히 STT는 네트워크 I/O와 외부 API 응답 지연에 크게 영향을 받는 구간이므로, 단일 스트림 또는 공유 스트림 구조로 설계할 경우 특정 사용자의 STT 지연이 곧바로 전체 서버의 지연으로 확산될 위험이 큽니다. SpeakNote는 이 문제를 피하기 위해 세션 단위로 STT 스트림을 완전히 분리하고, STT 처리는 세션 전용 워커가 전담하도록 구성했습니다.

3.1 세션별 STT gRPC 스트림 분리 설계

SpeakNote에서 각 WebSocket 세션(Session A/B/N)은 독립적인 Google STT gRPC 스트림을 가집니다. 이는 “단일 클라이언트 인스턴스 또는 단일 스트림을 여러 세션이 공유”하는 방식에서 자주 발생하는 충돌/경합 문제를 회피하기 위한 선택입니다. 스트리밍 STT는 기본적으로 한 스트림 내에서 오디오 프레임의 순서와 타이밍이 중요하며, 여러 세션의 오디오가 섞이거나 동시 요청이 엉키는 순간 인식 품질 저하뿐 아니라 스트림 정지, 응답 꼬임과 같은 장애로 이어질 수 있는데 따라서 SpeakNote는 세션당 하나의 스트림을 열어 “세션 내 순서 보장”과 “세션 간 격리”를 동시에 만족시키는 방향을 택했습니다.

이 구조의 핵심은 단순히 스트림을 분리하는 것에서 끝나지 않는데, STT 스트림으로 오디오를 전송하는 역할은 WebSocket 핸들러가 아니라 세션 전용 워커(Session Worker)가 담당합니다. 즉, WebSocket I/O 스레드가 STT 호출을 직접 수행하지 않고, 입력 큐에 적재한 뒤 빠르게 반환함으로써 서버의 연결 유지 성능을 확보하는 것.

3.2 세션 전용 워커의 역할과 처리 흐름

세션 전용 워커는 해당 세션의 STT 처리에서 다음 역할만 수행하도록 책임을 제한했습니다.

InboundAudioQueue에서 오디오 청크를 소비(consume)
WebSocket으로 수신된 오디오 청크는 즉시 InboundAudioQueue에 적재되고, 워커는 이 큐를 FIFO로 소비한다. 이때 큐는 순서를 보장하며, 세션 내 오디오 흐름이 뒤섞이지 않도록 한다.
해당 세션의 STT gRPC 스트림으로 순서대로 전송
워커는 큐에서 꺼낸 청크를 해당 세션의 gRPC 요청 스트림에 순차적으로 write한다. “오디오 입력 순서가 그대로 STT 스트림 전송 순서”가 되기 때문에, 스트리밍 인식 모델이 기대하는 입력 흐름을 깨뜨리지 않는다.
STT 응답은 비동기 콜백으로 수신하고 TextBuffer에 누적
STT의 partial/final transcript 응답은 비동기 observer 콜백으로 수신된다. 응답이 도착할 때마다 세션의 TextBuffer를 갱신하고, final 결과가 확정되면 해당 문장을 누적하여 이후 요약/주석 생성 트리거의 입력으로 사용한다.

이 설계는 “STT 지연이 발생하더라도 WebSocket 서버가 멈추지 않는 구조”를 만들기 위한 의도적인 분리인데, WebSocket I/O 스레드는 오디오를 받는 역할만 최소 비용으로 수행하고, 실제 STT 전송과 응답 처리는 세션 워커 및 비동기 콜백으로 분산되어 결과적으로 STT가 느려지는 순간에도 WebSocket 서버의 주요 스레드가 외부 호출로 블로킹되지 않습니다.

3.3 STT 지연이 전체 시스템으로 전파되지 않는 이유

이 구조가 병목을 “해결”한다기보다는, 병목이 생겼을 때 영향 범위를 세션 내부로 격리한다는 점이 중요한데, SpeakNote는 STT 지연이 발생해도 다음 조건을 만족하도록 설계했습니다!

STT 응답이 늦어져도 입력 큐는 유지됨.
STT 호출이 느려지면 워커의 소비 속도가 감소하고 InboundAudioQueue에 청크가 쌓이기 시작하지만 그러나 이 누적은 세션 단위 큐에서 발생하며, WebSocket 서버 전체가 멈추는 형태가 아니라 “해당 세션의 처리 지연”으로 국한됩니다.

지연은 세션 내부에서 흡수된다(세션 격리)
세션 A의 STT가 느려졌다고 해서 세션 B의 STT 전송이나 응답 처리에 간섭하지 않는다. 스트림, 큐, 워커가 모두 세션 전용이기 때문에 STT 지연은 공유 자원 경합으로 확대되지 않는다.
WebSocket 서버는 계속 연결을 유지한다
WebSocket 핸들러는 오디오를 큐에 넣고 빠르게 반환한다. 즉, STT 응답이 늦어도 서버의 연결 유지 능력은 유지되며, 다른 세션의 오디오 수신/전송이 블로킹되지 않는다.

결과적으로 SpeakNote에서 Google STT Streaming 구간은 “지연이 발생할 수밖에 없는 외부 I/O”라는 현실을 인정하고, 그 지연이 서버 전체 다운/정지로 번지지 않도록 설계한 단계라고 정리할 수 있습니다. 병목이 완전히 사라지는 것은 아니지만, 지연이 발생해도 서비스가 끊기지 않고, 문제 범위를 특정 세션으로 제한하며, 전체 파이프라인을 지속 가능하게 만듭니다.

4. AI 요약 단계: 병목을 ‘비동기 분리’로 관리

AI 요약은 전체 파이프라인 중 가장 느린 단계입니다.
따라서 이 단계는 절대 실시간 흐름에 직접 연결되지 않도록 설계함

STT 텍스트 누적 → 조건 충족 시 요약 요청
요약 요청은 비동기 HTTP로 Python 서버에 전달
응답은 즉시 WebSocket으로 보내지 않고 OutboundQueue에 적재

이렇게 함으로써,

요약이 느려져도 STT·입력 처리는 계속 진행
요약 결과 전송 지연은 출력 큐에서 흡수
필요 시 오래된 결과를 드롭하여 최신성 유지

즉, 가장 큰 병목 구간을 파이프라인 바깥으로 밀어낸 구조입니다!

4.1 Python 계층에서의 병목 조건 정의

애플리케이션 계층(Java)으로부터 Python 서버는 다음 두 가지 형태의 입력을 지속적으로 수신합니다.

STT 텍스트 조각(msg): 수 초 간격으로 꾸준히 도착하는 짧은 문자열
문서 경로(doc_path): 세션당 한 번 업로드되는 비교적 무거운 전처리 대상

이때 병목이 발생하는 조건은 명확한데,
AI 주석 생성은 단일 요청 처리 시간이 입력 간격보다 길어 예를 들어, 음성 인식 결과가 3초마다 들어오지만, AI 주석 생성에는 10초 이상이 걸릴 수 있다면, 단순한 동기 처리나 즉시 비동기 호출 방식은 필연적으로 요청 누적과 지연 폭증으로 이어집니다. 이 문제를 해결하지 않으면 “처리 자체는 되지만, 시간이 지날수록 응답이 끝없이 밀리는 구조”가 됩니다.

4.2 Task Manager 기반 큐잉: 요청을 즉시 처리하지 않는다

SpeakNote의 Python 계층은 들어오는 모든 요청을 즉시 LLM 호출로 넘기지 않고 대신, Task Manager를 중심으로 한 작업 큐 기반 구조를 도입했습니다. 이 구조의 핵심은 “요청을 바로 처리하지 않고, 처리 가능한 단위로 묶어 관리한다”는 점입니다.

Task Manager는 다음과 같은 책임을 가집니다.

들어오는 요청을 Chat Task / Context Task로 분리
요청을 Max_process_num 단위의 묶음(batch)으로 구성
일정 시간(patient time) 동안 요청이 충분히 모이지 않더라도 강제로 flush
큐에 들어간 작업만 백그라운드에서 비동기 실행

이 방식은 단순한 비동기 호출과 다른데, 단순히 asyncio.create_task()를 요청마다 호출하면, 요청 폭주 시 태스크 수가 무제한으로 늘어나 오히려 시스템이 불안정해지지만 반면 Task Manager는 병렬 처리의 상한을 명시적으로 제한하고, 작업 생성 시점을 제어함으로써 병목이 “지연”으로만 나타나고 “장애”로 확대되지 않도록 하는 것입니다.

4.3 세션 단위 격리와 순서 보장

Python 계층에서 중요한 또 하나의 설계 원칙은 세션 단위 순서 보장입니다. SpeakNote는 단일 사용자의 발화 흐름이 의미적으로 연결되어 있다는 점을 전제로 해야하기 때문에 따라서 동일 세션에서 발생한 STT 텍스트들은 순서를 유지한 채 처리되어야 하며, 동시에 다른 세션의 요청과는 병렬로 처리될 수 있어야 합니다.

이를 위해 Chat Task는 내부적으로 세션 ID를 기준으로 관리되며, 같은 세션의 요청은 논리적으로 연결된 작업 흐름을 유지합니다. 반면 서로 다른 세션의 Chat Task들은 Task Manager에 의해 병렬로 실행될 수 있습니다. 이 구조 덕분에 특정 사용자의 요청이 느리게 처리되더라도, 다른 사용자의 요청이 그 영향을 받지 않습니다.

4.4 문서 전처리 병렬화: 무거운 작업을 한 번에 끝내지 않는다

문서 전처리는 AI 계층에서 가장 무거운 작업 중 하나

SpeakNote는 문서 내 텍스트뿐 아니라 도표, 차트, 수식과 같은 시각 정보를 LLM을 통해 자연어로 변환하는 과정을 포함하는데 이 과정은 필연적으로 긴 지연을 발생시키며, 단일 스레드로 처리할 경우 사용자 체감 대기 시간이 급격히 늘어납니다.

이를 완화하기 위해 문서 전처리는 내부적으로 카테고리 단위 비동기 병렬 처리로 설계되었습니다.

문서에서 figure, chart, equation과 같은 시각 정보들을 먼저 수집한 뒤, 각 카테고리에 대해 비동기 함수로 전처리를 수행, 모든 카테고리에 대한 전처리가 완료되면 결과를 하나의 Context 객체로 통합합니다.

이 구조는 문서 전처리 자체를 빠르게 만드는 것이 목적이 아니며 핵심은 “문서 전처리로 인한 지연이 전체 시스템을 막지 않도록 분리”하는 데 있습니다. 전처리는 Context Task로 분리되어 백그라운드에서 처리되며, 채팅 기반 주석 생성(Chat Task)과는 독립적으로 관리합니다.

4.5 느린 AI 연산을 실시간 흐름에 맞추는 방식

SpeakNote의 Python 계층은 단일 요청 기준으로 보면 결코 빠르지 않습니다. 오히려 의도적으로 “느릴 수밖에 없는 구조”를 인정하고, 그 느림이 사용자 경험에 직접적으로 누적되지 않도록 설계했습니다. 첫 응답은 반드시 지연이 발생하지만, 이후에는 Task Manager와 비동기 병렬 구조를 통해 요청 간 간격보다 빠른 속도로 응답을 지속적으로 반환할 수 있습니다.

즉, 이 계층에서의 병목은 제거의 대상이 아니라 관리의 대상

병목을 숨기지 않고, 병목이 발생해도 시스템이 안정적으로 동작하도록 구조적으로 흡수하기 때문에 그 결과 SpeakNote는 다중 사용자 환경에서도, 단일 사용자 환경에서도 “응답이 밀리다 멈추는 시스템”이 아니라 “느리더라도 끊기지 않는 시스템”으로 동작할 수 있습니다.