AI 에이전트는 생각보다 훨씬 잘합니다.

실제로 다양한 도구를 연결해주면, 단순 질의응답을 넘어서 데이터를 바탕으로 사람이 인지하지 못했던 영역까지 분석하고, 급등/급락 감지, 재구매 코호트 분석, 크로스셀 경로 제안까지 — 그래프를 만들고, KPI를 비교 분석하고, 예측을 위한 동적 UI를 구성하고, 디테일한 인사이트와 다음 액션까지 제안할 수 있습니다.

저희 팀도 글로벌 K-뷰티 기업에 AI 에이전트 스킬팩을 배포하면서 이 가능성에 여러 번 놀랐습니다. 데이터를 바탕으로 사람이 인지하지 못했던 영역까지 분석하고, 인사이트를 제공하는 경험은 단순히 "자동화"라는 단어로는 부족했습니다. 실제로 고객사 전무님이 에이전트 동작과 분석 결과를 보시고 "대~박"이라고 하셨다는 이야기를 전달받을 정도였습니다.

그런데 프로덕션에 붙이기 전, 내부 테스트 과정에서 중요한 걸 깨달았습니다. 드물게 실패가 발생했을 때, 대비가 없으면 치명적이라는 점이었습니다.

도구를 쓰는 기본 흐름

AI → 도구 호출 → 결과 수신 → 다음 행동 결정

문제는 도구가 실패했을 때입니다. 내부 테스트 과정에서 발견하고 수정한 문제는 크게 네 가지였습니다.

1. 같은 실패를 반복했다

도구가 에러를 반환하면 AI는 같은 호출을 반복했습니다. 사용자는 응답을 기다리는데, 내부에서는 같은 API가 여러 번 호출되며 비용과 지연이 같이 커졌습니다.

해결: Circuit Breaker

연속 실패 횟수가 일정 기준을 넘으면 해당 도구를 잠시 비활성화하고, AI에게는 내부적으로 "이 도구는 더 쓰지 말고 다른 방법을 찾아라"는 신호를 전달했습니다. 분산 시스템에서 흔히 쓰이는 패턴이지만, AI 에이전트 맥락에서는 "AI의 행동을 제어하는 신호"로 작동한다는 점이 핵심이었습니다.

2. 같은 도구를 중복 호출했다

같은 도구, 같은 파라미터를 다시 호출하는 경우도 있었습니다. AI 입장에서는 확인 행동일 수 있지만, 시스템 입장에서는 중복 트래픽이었습니다.

해결: Dedup Cache

같은 tool + 같은 parameter 조합이면 두 번째 호출에는 캐시된 결과를 반환하도록 했습니다. 캐시 TTL은 도구 특성에 따라 다르게 설정했습니다. 실시간 데이터를 다루는 도구는 짧게, 정적 데이터를 다루는 도구는 길게.

3. 도구가 멈추면 전체 루프가 같이 멈췄다

외부 API가 응답 없이 멈추면 AI 루프 전체가 블로킹됐습니다. 사용자 화면에는 그냥 "로딩 중…"만 계속 남는 상황이 됐습니다.

해결: Timeout 강제

30초를 넘기면 시간 초과로 처리하고, AI에게는 "파라미터를 단순화해서 한 번만 재시도해봐" 같은 식으로 안내했습니다. 타임아웃 값은 도구별로 다르게 설정했고, 외부 API의 평균 응답 시간 데이터를 기반으로 조정했습니다.

4. 에러 메시지 설계가 AI의 행동을 바꿨다 — 핵심 발견

이 부분이 가장 중요한 발견이었습니다.

단순히 "에러 발생"이라고만 전달하면, AI는 같은 행동을 반복하는 경향이 있었습니다. 반대로 에러를 종류별로 구분해 전달하면 행동이 달라졌습니다.

즉, 에러 메시지는 로그가 아니라 제어 신호에 가까웠습니다.

이 피드백 루프가 핵심이었습니다. 사람이 개입하지 않아도, AI가 실패를 인식하고 스스로 전략을 바꿔서 해결하는 구조. 에러 메시지를 잘 설계하는 것만으로, AI의 복구 능력이 근본적으로 달라졌습니다.

이 모든 피드백은 사용자에게는 보이지 않는 내부 채널로 전달됩니다.

이게 우리만의 문제가 아니었다

찾아보니 AI 업계 전체가 같은 문제를 겪고 있었습니다.

LangGraph (2025)

LangGraph(LangChain의 에이전트 프레임워크)는 langgraph-prebuilt v1.0.1에서 도구 에러 처리 기본값을 "자동 활성화"에서 "비활성화"로 변경했습니다. 기존 동작에 의존하던 그래프들이 예고 없이 깨지면서 이슈로 보고됐습니다. 이건 단순 버그라기보다, "에러 처리를 프레임워크가 어디까지 기본 제공해야 하느냐"는 질문을 드러낸 사례로 보였습니다.

OpenAI / Anthropic

OpenAI와 Anthropic도 도구 호출 자체는 지원합니다. OpenAI 공식 문서는 function calling을 "애플리케이션이 외부 시스템과 연결해 실행하는 흐름"으로 설명하고 있고, Anthropic 공식 문서도 Claude가 tool_use를 내보내면 개발자가 도구를 실행한 뒤 tool_result를 다시 돌려주는 구조를 전제로 합니다. Anthropic은 is_error 같은 기본 에러 시그널도 제공하지만, 재시도 정책, 도구 폴백, 타임아웃 제어, 상태 복구 같은 워크플로 수준의 안전장치까지 자동으로 해결해주는 것은 아닙니다. 결국 이 부분은 애플리케이션이나 에이전트 프레임워크가 직접 설계해야 하는 영역에 가깝습니다.

MCP 2026 로드맵

MCP(Model Context Protocol) 2026 공식 로드맵에서는 Tasks primitive를 실제 프로덕션에서 운영한 뒤, retry semantics와 expiry policies를 공식적으로 정리해야 할 과제로 적고 있습니다. 프로토콜 차원에서도 "실패 시 누가 재시도하는가"와 "결과를 얼마나 보존하는가"가 중요한 운영 이슈로 인식되고 있다는 신호입니다.

SHIELDA (arXiv 2508.07935, 2025)

SHIELDA는 LLM 에이전트 워크플로우의 예외 처리만을 별도 주제로 다루며, 12개 에이전트 아티팩트에 걸친 36개 예외 유형 taxonomy를 제시합니다. 중요한 점은, 실행 단계에서 터진 예외를 그 이전 단계의 원인과 연결해 복구하려는 관점을 전면에 둔다는 것입니다. "예외 처리를 에이전트 운영의 중심 문제로 본다"는 점이 분명합니다.

저희가 내부 테스트에서 부딪히며 만든 해결책이 업계가 향하는 방향과 정확히 같은 맥락이었습니다.

얻은 교훈

결국 저희가 프로덕션에 앞서 붙인 장치들—circuit breaker, dedup cache, timeout, error classification—은 과한 엔지니어링이 아니었습니다. 오히려 지금의 에이전트 생태계에서는 원래 애플리케이션이 책임져야 하는 기본 운영 장치에 가까웠습니다.

이 경험을 통해 얻은 교훈은 단순합니다.

• 도구는 실패합니다
• AI는 같은 실수를 반복합니다
• 에러를 분류하고 제어 신호로 전달하면, AI가 스스로 복구합니다
• 그 실패를 어떻게 처리하느냐가 사용자 경험을 결정합니다

프로덕션 에이전트의 진짜 실력은 "얼마나 똑똑한가"보다 "실패했을 때 AI가 스스로 얼마나 안전하게 복구하는가"에 더 가깝다고 생각하게 됐습니다.

좋은 에이전트는 답을 잘 내는 에이전트이기도 하지만, 그보다 먼저 실패를 드러내고, 분류하고, 스스로 복구할 수 있는 에이전트여야 합니다.

기술로 이기려 하지 마세요. 지금의 기술 우위는 생각보다 빠르게 평준화됩니다.

지금은 구글, MS, OpenAI 같은 빅테크가 기능 하나만 출시해도 스타트업 수천 개의 가치 제안이 흔들리는 시대입니다. 소위 ‘바이브 코딩’이라 불리는 흐름 속에서, 비개발자도 AI를 활용해 앱을 빠르게 만들고 있습니다. 기술의 진입장벽은 우리가 생각하는 것보다 훨씬 빠르게 낮아지고 있습니다.

이건 2~3년 뒤의 미래가 아닙니다. 이미 벌어지고 있는 현실입니다.

그렇다면 기술이 상향 평준화되는 시대에, 진짜 해자는 무엇일까요?

저는 그 답이 고객의 문제를 얼마나 깊게 정의하느냐, 그리고 그 문제 위에 축적된 데이터와 신뢰에 있다고 생각합니다.

AI가 발전할수록 코드를 짜고, 분석하고, 리포트를 만드는 실행의 많은 부분은 AI의 몫이 됩니다. 인간과 기업의 역할은 점점 오케스트레이터에 가까워집니다.
무엇을 해결해야 하는지 정의하고, AI가 올바른 방향으로 일하도록 설계하는 능력이 핵심 경쟁력이 되는 것입니다.

결국 살아남는 기업은 겉으로 화려한 기술을 보여주는 기업이 아니라, 고객의 페인 포인트를 집요하게 파고드는 기업입니다.

바티CIS가 주목하는 해자도 분명합니다.
• COSRX의 42개 글로벌 마켓플레이스 거래 데이터
• 리쥬란의 글로벌 커머스 데이터

이런 도메인 특화 데이터는 범용 AI만으로는 확보하거나 복제하기 어려운 자산입니다. 단지 보안의 문제가 아니라, 비즈니스 구조 자체가 쉽게 허용하지 않기 때문입니다. 기술은 계속 바뀌지만, 특정 도메인의 깊이와 그 위에 쌓인 데이터와 신뢰는 시간이 갈수록 더 강한 해자가 됩니다.

지금은 ‘기술 경쟁’의 시간이 아니라, ‘문제 정의’의 골든타임입니다.
이 기회의 창은 길어야 1~2년이라고 생각합니다.

기술을 직접 구현하는 능력보다, 고객의 문제를 정확히 정의하고 AI를 동료처럼 활용해 해결책을 설계하는 팀이 결국 이길 것입니다.

여러분의 팀은 지금 무엇을 해자로 쌓고 있나요?

2024-2025년 글로벌 자본 흐름은 AI로 극적으로 재편되고 있다. AI 스타트업은 2024년 전체 VC 펀딩의 37%(약 $1,000억)를 흡수했고, cbinsights 2025년 상반기에만 $1,160억을 기록해 이미 2024년 전체를 초과했다. Gartner는 2025년 글로벌 AI 지출을 $1.5조, 2026년에는 $2조 이상으로 예측한다.

자본은 극단적으로 집중되어 있다. 2024년 AI 펀딩의 **69%가 메가라운드($1억 이상)**에서 발생했고, $10억 이상 라운드가 13건에 달했다. cbinsights Databricks($100억, $620억 밸류에이션), OpenAI($66억, $1,570억), xAI($60억+), Anthropic($40억+)이 자본을 독식하고 있다. 미국이 펀딩의 76%, 딜 수의 **49%**를 차지하며, cbinsights 유럽(13%)과 아시아(10% 미만)는 크게 뒤처진다.

AI 스택별 투자 현황이 말해주는 것

엔터프라이즈 GenAI 지출 $370억(2025년) Menlo Ventures 중 각 레이어별 흐름이 중요하다:

가장 빠르게 성장하는 영역은 애플리케이션 레이어다. 특히 코딩/엔지니어링 도구가 부서별 AI 지출의 **55%($40억)**를 차지하며 압도적 1위다. Menlo Ventures 수직 AI 솔루션($35억)에서는 헬스케어가 **43%**로 선두다. Menlo Ventures 이것이 의미하는 바는 명확하다—인프라는 이미 대기업이 장악했고, 진짜 기회는 특정 산업과 워크플로를 깊게 파고드는 수직 애플리케이션에 있다.

정부 자금: 규제 장벽이 곧 해자가 된다

정부 AI 정책 자금은 전례 없는 규모로 집행 중이다:

• 미국: CHIPS Act $2,800억 (반도체 $520억, AI/R&D $2,000억+), Intel $78억, TSMC $66억 수령
• EU: InvestAI €2,000억 동원 목표, AI 공장 €100억 공동 투자, 13개 AI 팩토리 설립
• 중국: 2030년까지 $1,500억 AI 펀딩 약속, 국가 AI 펀드 $82억
• 한국: 디지털 뉴딜 $535억, 글로벌 AI 칩 공급의 37% 점유

전략적 시사점: 정부 조달 시장은 FedRAMP 20x(2025년 신설)로 진입 장벽이 극적으로 낮아졌다. GSAOpenAI와 Perplexity가 이미 우선 인가를 받았고, GSA가 Perplexity와 직접 계약을 체결했다. FedScoop 정부 시장은 규모뿐 아니라 보안 인증이 경쟁 해자로 전환되는 시장이다.

역사적 기술 혁명이 AI 시대에 주는 교훈

"기술 자본주의는 기술이 아니라 자본주의"라는 명제는 역사가 증명한다. 모든 기술 혁명에서 명백한 초기 승자와 실제 최종 승자는 달랐다.

골드러시에서 PC까지: 승자 패턴의 일관성

골드러시(1848-1855): 광부들은 대부분 실패했다. 리바이 스트라우스는 광부에게 청바지를 팔아 사망 시 $3,000만(현재 가치 $8.7억)의 재산을 남겼다. 웰스파고는 금융 서비스로 성공했다. 패턴: 변동성 높은 "금" 자체보다 모든 참여자에게 필요한 내구재/서비스가 승리.

철도혁명(1850s-1900s): 철도 회사들은 자본 집약성과 경쟁으로 대부분 파산했다. 앤드류 카네기는 철도에 철강을 공급해 $5억(J.P. 모건에 매각)을 벌었다. J.P. 모건은 금융으로 철도를 지배했다. 패턴: 인프라 건설자보다 필수 구성요소 공급자와 자본 통제자가 승리.

PC혁명(1981-2000): IBM이 PC를 발명했지만, 시간 절약을 위해 칩(Intel)과 OS(Microsoft)를 외부 조달했다. 결과적으로 **초크포인트(chokepoint)**를 장악한 MS와 Intel이 승리했다. IBM의 PC 아키텍처가 오픈소스화되면서 하드웨어는 상품화됐다. 패턴: 조립자보다 모든 조립자에게 라이선스되는 표준 구성요소가 승리.

인터넷혁명(1995-2010): AOL, Yahoo 같은 포털이 초기 승자로 보였다. 그러나 구글은 PageRank로 10배 뛰어난 검색 기술을 구현하고, 배너 광고(CPM) 대신 **의도 기반 광고(PPC)**라는 다른 비즈니스 모델을 선택했다. Yahoo는 2000년에 구글의 검색 결과를 라이선스 받아야 했고, 이는 사용자들에게 구글을 학습시키는 결과를 낳았다. 패턴: "충분히 좋은" 기술을 추구한 기업보다 핵심 기술에 집중 투자하고 올바른 비즈니스 모델을 선택한 기업이 승리.

AI 시대의 "리바이스"는 누구인가

역사적 패턴을 AI에 적용하면, 승자의 특성이 드러난다:

1. 모든 AI 참여자에게 서비스 제공 (특정 모델/회사에 의존하지 않음)
2. 일회성이 아닌 반복적 필수 가치 제공
3. 복제 불가능한 해자 보유
4. 결과와 관계없이 AI 붐 자체에서 이익

가장 유망한 "리바이스" 후보군:

• 데이터 레이어: Scale AI(Meta가 $150억 지분 투자), 독점 훈련 데이터, 합성 데이터 생성 amadeuscapital
• 평가/검증 레이어: EU AI Act 등 규제 준수 검증 도구 (규제 순풍)
• 데이터 해자를 가진 수직 AI 애플리케이션: 사용을 통해 독점 데이터를 생성하는 앱
• 에이전트 오케스트레이션: 여러 AI 에이전트를 조율하는 플랫폼

피해야 할 영역: GPT 래퍼(차별화 없는 AI 앱), 파운데이션 모델 경쟁(오픈소스 3개월 내 추격), 자본 집약적 인프라(마진 압축 불가피).

AI 레이어별 마진과 방어력: 상품화가 진행 중이다

현재 AI 스택의 수익성과 위험

가장 빠르게 상품화되는 레이어는 파운데이션 모델이다. 오픈소스 모델(Llama 3, DeepSeek)이 독점 모델과의 격차를 3개월 이내로 좁히고 있다. DeepSeek의 2025년 1월 출시가 미국 앱스토어 1위를 기록한 것은 상징적이다. Carnegie Endowment for International Peace 중국 기업들의 "지능 인볼루션(intelligence involution)"—가격을 무자비하게 낮추는 경쟁—이 LLM을 상품으로 전환시키고 있다.

마진이 집중될 영역(3-5년 전망):

1. 독점 데이터 자산 (복제 불가능한 훈련 데이터, 피드백 루프)
2. 워크플로에 내장된 AI 에이전트
3. 효율적 파인튜닝/훈련 최적화 도구
4. 평가/검증 레이어 (규제 준수)
5. 엣지 추론 실리콘 (저전력 온디바이스 AI) amadeuscapital

엔터프라이즈 SaaS의 AI 전환: 네 가지 모델

Salesforce: 에이전트포스와 하이브리드 수익화

Salesforce는 Einstein(2016) → Einstein GPT(2023) → **Agentforce(2024)**로 진화했다. Agentforce는 자율적으로 업무를 수행하는 AI 에이전트 플랫폼으로, Marc Benioff는 "2025년 말까지 10억 에이전트"를 목표로 한다.

Data Cloud가 핵심 해자다. Data Cloud + AI ARR은 $14억(YoY 114% 성장)에 달하며, 이것이 AI의 기반이 되는 고객 데이터 통합 플랫폼 역할을 한다. Agentforce는 출시 7개월 만에 8,000+ 고객(유료 5,000건)을 확보했다.

수익화 전략은 하이브리드다: 초기 $2/대화 모델에서 고객 반발 후 Flex Credits($0.10/액션)로 전환했다. 시트 기반($125-650/유저/월)과 사용량 기반을 결합해 예측 가능성과 성장 잠재력을 모두 확보했다.

ServiceNow: "AI 컨트롤 타워" 전략

ServiceNow는 워크플로 자동화 리더에서 **"엔터프라이즈 AI 오케스트레이션 플랫폼"**으로 전환 중이다. ITSM 시장 40% 점유율을 기반으로, Now Assist(생성 AI)와 Agentic AI(자율 에이전트)를 3단계로 제공한다.

2024년 매출 $109.8억(YoY 22% 성장), Computer Weekly Now Assist 딜 QoQ 150%+ 성장, Pro Plus 딜 YoY 4배 증가. AI 제품에서 2025년 $100억 ACV 목표를 설정했다. Klover 차별화 요소는 Workflow Data Fabric(데이터 사일로 해결)과 AI Control Tower(거버넌스, 리스크 관리)다. Klover

Palantir: 정부-기업 간 브릿지 모델의 교과서

Palantir가 성공한 이유는 AI 모델이 아니라 **온톨로지(Ontology)**다. 온톨로지는 원시 데이터를 실행 가능한 운영 인텔리전스로 변환하는 시맨틱 레이어로, 디지털 데이터를 실제 자산과 인과관계로 매핑해 AI가 맥락을 이해하게 한다.

재무 실적이 압도적이다: 2024년 매출 $28.7억(YoY 29% 성장), Yahoo Finance 미국 상업 부문 YoY 93% 성장(Q2 2024), IG Rule of 40 점수 83%, 조정 영업이익률 44%, Klover 현금 $64억(무차입). 미 육군 $100억 10년 계약(2025년 8월)이 정부 신뢰도를 증명한다.

AIP(AI Platform) Bootcamp 모델이 게임 체인저다. 5일간 고객 데이터로 실제 프로토타입을 구축하는 집중 워크숍은 "try-before-you-buy" 접근으로 회의론자를 구매자로 전환한다. Q1 2025에만 $100만+ 딜 139건을 창출했다.

B2B AI 플랫폼을 위한 Palantir 교훈:

1. "라스트 마일" 문제 해결—모델만으로는 부족, 운영 워크플로에 통합 필요
2. 가장 어려운 문제부터 시작—복잡할수록 경쟁 장벽이 높아짐
3. 보안이 차별화—정부급 보안 인증은 기업 신뢰로 전환됨
4. 인내심—Palantir는 2003년 설립, 20년의 해자 구축 기간이 있었음

AI 네이티브 플랫폼의 현재: 수직 vs 수평의 승부

Glean: 엔터프라이즈 AI의 정석

Glean은 $72억 밸류에이션(2025년 6월), Glean 18개월간 3.3배 밸류 성장, TechCrunch 출시 3년 내 $1억 ARR 달성으로 "카테고리 리더"로 자리잡았다. Glean 100+ 앱 커넥터를 통한 엔터프라이즈 지식 통합과 Glean Agents(연간 1억+ 에이전트 액션)로 에이전틱 AI에 진입했다. TechCrunch MAU의 40%가 DAU인 것은 일반 엔터프라이즈 소프트웨어(15-20%)의 2-3배다. SiliconANGLE

위험 요소는 Microsoft 365 Copilot, Amazon Q Business의 플랫폼 확장이다. CEO Jain도 "Google, Microsoft, OpenAI 모두 우리가 시작한 영역에 들어오고 싶어한다"고 인정한다. CNBC

Harvey AI: 수직 AI의 승리 공식

Harvey는 법률 AI로 $80억 밸류에이션(2025년 12월)에 도달했다—18개월 전 $7.15억에서 11배 성장. $1억+ ARR, 337개 법률 고객, 미국 상위 10대 로펌 대다수 확보. 처음에는 "GPT 래퍼"로 비판받았지만, 깊은 도메인 전문성(변호사 직원 채용), 워크플로 통합, 미션 크리티컬 유스케이스로 프리미엄 밸류에이션을 정당화했다.

Jasper AI: GPT 래퍼의 경고

Jasper는 경고 사례다. 2022년 10월 $15억 밸류에이션 유니콘, $8,000만 ARR, 12만+ 사용자. 그러나 ChatGPT 출시(2022년 11월)가 "사실상 하룻밤 사이에 강력한 저비용 경쟁자"를 만들었다. Maginative 2023년 CEO 교체, 내부 밸류에이션 20% 하락, Fast Company ARR 예측 30%+ 하향. Maginative OpenAI 모델에 대한 과의존과 차별화 부재가 원인이었다.

이후 마케팅 팀 전용으로 피벗해 엔터프라이즈 ARR 400% 성장을 기록했지만, Fast Company "first-mover advantage는 일시적"이라는 교훈을 남겼다.

"AI OS" 개념의 현실

"AI OS"는 대부분 마케팅 용어에 가깝다. 실제로 실행 가능한 것은 Microsoft Copilot 생태계다—Windows, Office, Edge 전반에 걸친 AI 레이어와 "Windows가 에이전틱 OS로 진화" 비전. Notion AI는 Notion 데이터에만 제한되어 "기능"에 불과하고, Rabbit R1/Humane은 하드웨어 우선 접근이 채택에 실패했다. The Media Gen

스타트업이 진정한 "OS"가 되는 것은 비현실적이다. 대신 **특정 도메인의 "시스템 오브 레코드"**가 되는 것이 달성 가능한 목표다.

네트워크 효과와 Lock-in 구축: 소규모 팀의 방어력

실제로 작동하는 Lock-in 메커니즘

AI 플랫폼에서 작동하는 네트워크 효과는 제한적이다. a16z는 "데이터 네트워크 효과에 대한 대부분의 내러티브는 실제로는 데이터 스케일 효과"라고 경고한다. 그러나 다음은 실제로 작동한다:

1. 피드백 루프 효과: 인간의 승인/거부가 AI 출력을 개선 (Harvey의 변호사 검증)
2. 누적된 맥락: 재생성 불가능한 조직 지식 그래프
3. 딥 인테그레이션: 개발자 200+ 시간의 전환 비용 창출
4. 컴플라이언스/보안 투자: FedRAMP, SOC2, HIPAA 인증이 전환 마찰 생성
5. 커스텀 모델 훈련: 기업 특화 데이터로 훈련된 모델

핵심 원칙: "SaaS의 진정한 성공은 떠나기 어려운 것이 아니라, 대체하기 어려운 것이다." Medium

데이터 해자 구축: 성공하는 전략

성공하는 접근:

• 사용에 따른 독점 데이터 생성 (센서, 특수 산업 데이터 캡처)
• 큐레이션된 산업 데이터셋 (법률, 헬스케어, 금융 특화)
• 운영 데이터 축적 (모든 고객 인터랙션이 모델 개선)
• 신뢰받는 수탁자 지위 (다른 기업이 접근할 수 없는 민감 데이터 권한 획득)

실패하는 접근:

• 피드백 루프 없이 데이터=해자라고 가정
• 쉽게 복제되는 일반 데이터
• 더 나은 제품으로 복리화되지 않는 데이터

서버에서 Node.js 애플리케이션을 운영할 때, 단순히 node app.js로 실행하면 터미널이 종료되거나 애플리케이션이 크래시될 때 서비스가 중단됩니다. 이런 문제를 해결하기 위해 systemd를 활용해 Node.js 애플리케이션을 시스템 서비스로 관리하는 방법을 알아보겠습니다.

systemd란?

systemd는 Linux 시스템의 init 시스템으로, 시스템 부팅 과정과 서비스 관리를 담당합니다. Ubuntu 16.04부터 기본 init 시스템으로 채택되었으며, 강력한 서비스 관리 기능을 제공합니다.

기존 실행 방법들과의 비교

1. 직접 실행 (node app.js)

node app.js
# 또는
yarn start

단점:

• 터미널 종료 시 프로세스 종료
• 크래시 시 자동 재시작 불가
• 시스템 부팅 시 자동 시작 불가
• 로그 관리 어려움

2. nohup 사용

nohup yarn start > app.log 2>&1 &

장점:

• 터미널 종료되어도 실행 지속
• 간단한 로그 관리

단점:

• 크래시 시 자동 재시작 불가
• 프로세스 관리 번거로움
• 시스템 부팅 시 자동 시작 불가

3. PM2 사용

pm2 start yarn --name "app" -- start

장점:

• 자동 재시작
• 로드 밸런싱
• 실시간 모니터링
• 클러스터 모드

단점:

• 추가 패키지 설치 필요
• PM2 자체 관리 필요
• 메모리 오버헤드

4. systemd 사용 ⭐

sudo systemctl start my-app

장점:

• 시스템 레벨 관리
• 부팅 시 자동 시작
• 강력한 재시작 정책
• 표준화된 로그 관리
• 리소스 제한 가능
• 의존성 관리

systemd 서비스 설정하기

1. 서비스 파일 생성

/etc/systemd/system/my-app.service 파일을 생성합니다:

[Unit]
Description=My Node.js Application
After=network.target

[Service]
Type=simple
User=ubuntu
WorkingDirectory=/home/ubuntu/my-app
Environment=NODE_ENV=production
Environment=PORT=3000
ExecStart=/usr/bin/yarn start
Restart=always
RestartSec=10
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=my-app

[Install]
WantedBy=multi-user.target

2. 주요 설정 옵션 설명

[Unit] 섹션

• Description: 서비스 설명
• After: 네트워크가 활성화된 후 시작

[Service] 섹션

• Type=simple: 단순한 포그라운드 프로세스
• User: 실행할 사용자
• WorkingDirectory: 작업 디렉토리
• Environment: 환경 변수 설정
• ExecStart: 실행할 명령어
• Restart=always: 항상 재시작
• RestartSec=10: 재시작 대기 시간 (초)

[Install] 섹션

• WantedBy=multi-user.target: 멀티유저 모드에서 자동 시작

3. 서비스 등록 및 실행

# 서비스 파일 다시 로드
sudo systemctl daemon-reload

# 서비스 활성화 (부팅 시 자동 시작)
sudo systemctl enable my-app

# 서비스 시작
sudo systemctl start my-app

# 서비스 상태 확인
sudo systemctl status my-app

고급 설정 옵션

재시작 정책

[Service]
Restart=on-failure          # 실패 시에만 재시작
RestartSec=5                # 5초 후 재시작
StartLimitInterval=60       # 60초 간격 내에서
StartLimitBurst=3           # 최대 3번까지 재시작 시도

리소스 제한

[Service]
MemoryLimit=512M            # 메모리 제한
CPUQuota=50%               # CPU 사용률 제한
TasksMax=20                # 최대 프로세스/스레드 수

보안 설정

[Service]
NoNewPrivileges=true        # 새로운 권한 획득 방지
ProtectSystem=strict        # 시스템 디렉토리 쓰기 방지
ProtectHome=true           # 홈 디렉토리 접근 제한

서비스 관리 명령어

기본 명령어

# 서비스 시작/중지/재시작
sudo systemctl start my-app
sudo systemctl stop my-app
sudo systemctl restart my-app

# 서비스 상태 확인
sudo systemctl status my-app

# 서비스 활성화/비활성화 (부팅 시 자동 시작)
sudo systemctl enable my-app
sudo systemctl disable my-app

로그 관리

# 실시간 로그 보기
sudo journalctl -u my-app -f

# 최근 로그 확인
sudo journalctl -u my-app -n 50

# 특정 시간 범위 로그
sudo journalctl -u my-app --since "2024-01-01" --until "2024-01-02"

자동화 스크립트 예제

실제 운영 환경에서 사용할 수 있는 배포 스크립트:

setup-service.sh

#!/bin/bash

SERVICE_NAME="my-app"
WORK_DIR="/home/ubuntu/my-app"
USER="ubuntu"

# 서비스 파일 생성
sudo tee /etc/systemd/system/$SERVICE_NAME.service > /dev/null << EOL
[Unit]
Description=My Node.js Application
After=network.target

[Service]
Type=simple
User=$USER
WorkingDirectory=$WORK_DIR
Environment=NODE_ENV=production
Environment=PORT=3000
ExecStart=$WORK_DIR/start.sh
Restart=always
RestartSec=10
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=$SERVICE_NAME

[Install]
WantedBy=multi-user.target
EOL

# 실행 스크립트 생성
tee $WORK_DIR/start.sh > /dev/null << EOL
#!/bin/bash
cd $WORK_DIR
yarn start
EOL

chmod +x $WORK_DIR/start.sh

# systemd 등록
sudo systemctl daemon-reload
sudo systemctl enable $SERVICE_NAME

echo "✅ Service setup complete!"

deploy.sh

#!/bin/bash

SERVICE_NAME="my-app"

echo "🔄 Stopping service..."
sudo systemctl stop $SERVICE_NAME

echo "📦 Pulling latest code..."
git pull origin main

echo "🔨 Building application..."
yarn build

echo "🚀 Starting service..."
sudo systemctl start $SERVICE_NAME

echo "✅ Deployment complete!"
sudo systemctl status $SERVICE_NAME --no-pager

systemd의 장단점

장점 ✅

1. 시스템 통합: Linux 시스템과 완벽하게 통합
2. 자동 재시작: 크래시 시 자동으로 재시작
3. 부팅 시 자동 시작: 서버 재부팅 후 자동으로 서비스 시작
4. 강력한 로그 관리: journald를 통한 체계적인 로그 관리
5. 리소스 제어: CPU, 메모리 등 리소스 사용량 제한 가능
6. 의존성 관리: 다른 서비스와의 시작 순서 제어
7. 보안: 다양한 보안 옵션 제공
8. 표준화: 대부분의 Linux 배포판에서 표준

단점 ❌

1. Linux 전용: Windows나 macOS에서 사용 불가
2. 학습 곡선: 초기 설정과 개념 이해 필요
3. 복잡성: 간단한 애플리케이션에는 과도할 수 있음
4. 디버깅: 문제 발생 시 systemd 지식 필요

모니터링과 알림

서비스 상태 모니터링

# 서비스가 실행 중인지 확인
systemctl is-active my-app

# 서비스가 활성화되어 있는지 확인
systemctl is-enabled my-app

알림 설정 (OnFailure)

[Unit]
OnFailure=failure-notification@%n.service

결론

systemd는 Node.js 애플리케이션을 프로덕션 환경에서 안정적으로 운영하기 위한 강력한 도구입니다. 초기 설정은 다소 복잡할 수 있지만, 한 번 설정하면 다음과 같은 이점을 얻을 수 있습니다:

• 높은 안정성: 자동 재시작과 에러 복구
• 운영 편의성: 표준화된 관리 명령어
• 확장성: 여러 서비스 동시 관리 가능
• 보안성: 시스템 레벨 보안 기능

특히 서버 운영 경험이 있거나 안정적인 서비스 운영이 중요한 경우라면 systemd 도입을 강력히 추천합니다.

이 글이 도움이 되셨다면 실제 프로젝트에 적용해보시고, 궁금한 점이 있으시면 언제든 문의해주세요! 🚀

🎯 목표

SQLite에서 다음과 같은 데이터 변환을 수행하는 것

변환 전:

IDvalues_column1a,b,c2d,e3f,g,h,i

변환 후:

IDvalue1a1b1c2d2e3f3g3h3i

🛠️ 해결 방법들

방법 1: JSON 함수 사용 (SQLite 3.45+)

WITH split_data AS (
    SELECT 
        id,
        json_extract(value, '$') as split_value
    FROM your_table,
    json_each('["' || replace(values_column, ',', '","') || '"]')
)
SELECT id, trim(split_value) as value
FROM split_data
ORDER BY id;

장점: 간단하고 효율적

단점: 최신 SQLite 버전 필요, 특수문자 처리 주의

방법 2: 재귀 CTE 사용 (권장 ⭐)

WITH RECURSIVE split_string(id, remaining, extracted, pos) AS (
    -- 초기 단계: 끝에 쉼표를 추가하여 일관성 확보
    SELECT 
        id,
        values_column || ',' as remaining,
        '' as extracted,
        1 as pos
    FROM your_table
    WHERE values_column IS NOT NULL AND values_column != ''
    
    UNION ALL
    
    -- 재귀 단계: 첫 번째 값을 추출하고 나머지를 다음으로 전달
    SELECT 
        id,
        substr(remaining, instr(remaining, ',') + 1) as remaining,
        trim(substr(remaining, 1, instr(remaining, ',') - 1)) as extracted,
        pos + 1
    FROM split_string
    WHERE instr(remaining, ',') > 0 AND pos < 100
)
SELECT id, extracted as value
FROM split_string
WHERE extracted != '' AND extracted IS NOT NULL
ORDER BY id, pos;

장점:

• 모든 SQLite 버전에서 작동
• 특수문자 문제 없음
• 컬럼 개수 무제한

단점: 상대적으로 복잡

-- 테스트 데이터 생성
CREATE TABLE test_data (
    id INTEGER PRIMARY KEY,
    values_column TEXT
);

INSERT INTO test_data (values_column) VALUES 
('a,b,c'),
('d,e'),
('f,g,h,i'),
('j');

-- 방법 1 사용 (가장 추천)
WITH split_data AS (
    SELECT 
        id,
        json_extract(value, '$') as split_value
    FROM test_data,
    json_each('["' || replace(values_column, ',', '","') || '"]')
)
SELECT id, trim(split_value) as value
FROM split_data
ORDER BY id;

🔍 재귀 CTE 작동 원리 분석

핵심 아이디어

1. 끝에 쉼표 추가: "a,b,c" → "a,b,c," 로 변환하여 일관된 처리
2. 점진적 추출: 매번 첫 번째 값만 추출하고 나머지는 다음 단계로
3. 자동 종료: 더 이상 쉼표가 없으면 재귀 중단

실행 과정 시뮬레이션

입력: values_column = "apple,banana,cherry"

단계remainingextractedpos초기"apple,banana,cherry,"""11차"banana,cherry,""apple"22차"cherry,""banana"33차"""cherry"4종료(쉼표 없음)--

핵심 함수들

-- 첫 번째 쉼표 위치 찾기
instr(remaining, ',')

-- 첫 번째 쉼표 이전 부분 (현재 값)
substr(remaining, 1, instr(remaining, ',') - 1)

-- 첫 번째 쉼표 이후 부분 (남은 문자열)
substr(remaining, instr(remaining, ',') + 1)

🚨 JSON 방법의 함정과 해결책

JSON 함수를 사용할 때 다음 오류가 발생할 수 있습니다:

[SQLITE_ERROR] SQL error or missing database (malformed JSON)

원인

• 쌍따옴표 (") 포함
• 백슬래시 (\\) 포함
• 개행문자, 탭 문자 포함

해결책

-- 특수문자 이스케이핑
WITH safe_json AS (
    SELECT 
        id,
        '["' || replace(
            replace(
                replace(values_column, '\', '\\'), 
                '"', '\"'
            ), 
            ',', '","'
        ) || '"]' as json_array
    FROM your_table
    WHERE json_valid('["' || replace(values_column, ',', '","') || '"]') = 1
)
-- ... 이후 처리

💡 실전 응용 사례

학생 수업 프로그램 데이터 분할

실제 업무에서 자주 마주치는 케이스입니다:

WITH RECURSIVE 
-- 데이터 정리
cleaned_data AS (
    SELECT
        `등록일`,
        `이름`,
        `학생연락처`,
        `pageID`,
        REPLACE(`수업프로그램`, '페이지 아이디: ', '') AS `cleaned_programs`
    FROM 재원학생
    WHERE `수업프로그램` IS NOT NULL AND `수업프로그램` != ''
),
-- 재귀로 프로그램 분할
split_programs(등록일, 이름, 학생연락처, pageID, remaining, extracted, pos) AS (
    SELECT 
        `등록일`, `이름`, `학생연락처`, `pageID`,
        `cleaned_programs` || ',' as remaining,
        '' as extracted,
        1 as pos
    FROM cleaned_data
    
    UNION ALL
    
    SELECT 
        등록일, 이름, 학생연락처, pageID,
        substr(remaining, instr(remaining, ',') + 1) as remaining,
        trim(substr(remaining, 1, instr(remaining, ',') - 1)) as extracted,
        pos + 1
    FROM split_programs
    WHERE instr(remaining, ',') > 0 AND pos < 100
)
SELECT
    ROW_NUMBER() OVER (ORDER BY `pageID`, extracted) AS `record_id`,
    `등록일`, `이름`, `학생연락처`,
    extracted AS `수업프로그램_ID`,
    `pageID`
FROM split_programs
WHERE extracted != '' AND extracted IS NOT NULL
ORDER BY `record_id`;

⚡ 성능 최적화 팁

1. 인덱스 활용

-- 분할 후 임시 테이블에 인덱스 생성
CREATE INDEX idx_split_result ON temp_split_table(original_id, split_value);

2. 배치 처리

대용량 데이터의 경우:

-- ID 범위별로 나누어 처리
WHERE id BETWEEN 1 AND 10000

3. 재귀 깊이 제한 조정

-- 더 많은 분할이 필요한 경우
WHERE instr(remaining, ',') > 0 AND pos < 1000

🔄 다른 구분자 응용

세미콜론으로 분할

-- 쉼표 대신 세미콜론
values_column || ';' as remaining
substr(remaining, instr(remaining, ';') + 1)

여러 구분자 동시 처리

-- 쉼표, 세미콜론, 파이프 모두 쉼표로 통일
replace(replace(replace(values_column, ';', ','), '|', ','), ':', ',') || ','

📋 방법별 비교표

방법호환성성능복잡도특수문자 처리JSON 함수SQLite 3.45+⭐⭐⭐⭐⚠️ 주의 필요재귀 CTE모든 버전⭐⭐⭐⭐✅ 안전고정 분할모든 버전⭐⭐⭐⭐⭐⭐✅ 안전

🎯 결론 및 권장사항

1. 일반적인 경우: 재귀 CTE 방법 사용 (가장 안전하고 유연)
2. 최신 SQLite + 특수문자 없음: JSON 함수 방법
3. 고정된 분할 개수: 직접 분할 방법

재귀 CTE 방법은 약간 복잡해 보이지만, 한 번 이해하면 어떤 상황에서든 안정적으로 작동하는 강력한 도구입니다!

🔗 참고 자료

• SQLite 공식 문서 - Recursive CTE
• SQLite JSON 함수
• 문자열 함수 레퍼런스

Docker Desktop은 macOS에서 Docker 환경을 쉽게 실행할 수 있는 GUI 기반 도구로 널리 사용됩니다. 그러나 사용 중 자주 무거움을 느끼거나 리소스 과다 소모로 인해 배터리가 빠르게 소모되는 경우가 많습니다. 특히, 고성능 작업 시 Docker Desktop이 자주 느려지거나 갑작스럽게 종료되는 문제를 경험할 수 있습니다. 이러한 문제를 해결하기 위해 경량화된 대안으로 등장한 도구가 바로 Colima입니다.

Colima는 macOS에서 Docker 환경을 실행하는 오픈소스 경량화 도구로, GUI를 제공하지 않지만 Docker CLI와 완벽히 호환되며, 배터리 소모를 줄이고 성능을 최적화하는 데 초점을 맞춘 가상 머신(VM) 기반 도구입니다. 또한 Kubernetes와 파일 공유 기능까지 지원하여 다양한 개발 환경에서 유연하게 활용할 수 있습니다. 아래에서 Colima를 설치하고 활용하는 방법을 알아보겠습니다.

1. Colima 설치 및 시작

1.1 Colima 설치

Colima와 Docker CLI를 설치하려면 Homebrew를 사용합니다.

brew install colima docker docker-compose

1.2 Colima 시작

설치 후 Colima를 시작하여 Docker 환경을 준비합니다.

colima start

• 기본적으로 Colima는 2개의 CPU, 2GB 메모리, 60GB 디스크 크기를 할당합니다.

필요하면 다음과 같이 설정을 조정할 수 있습니다:

colima start --cpu 4 --memory 8 --disk 30

1.3 설치 확인

Docker CLI와 Colima가 제대로 작동하는지 확인합니다.

docker run hello-world

• 정상적으로 "Hello from Docker!" 메시지가 출력되면 설치가 완료된 것입니다.

2. Colima 리소스 사용량 확인

2.1 Docker 컨테이너 리소스 확인

현재 실행 중인 Docker 컨테이너의 CPU, 메모리, 네트워크 사용량을 실시간으로 확인하려면:

docker stats

예시 출력:

CONTAINER ID   NAME              CPU %     MEM USAGE / LIMIT     NET I/O
abc123456789   my-container      2.14%     512MiB / 2GiB         1.2MB / 1.5MB

2.2 Colima 상태 확인

Colima VM의 CPU, 메모리, 디스크 설정을 확인하려면:

colima status

출력 예:

colima is running
  CPU: 2
  Memory: 4GiB
  Disk: 20GiB

2.3 macOS Activity Monitor 사용

macOS의 Activity Monitor에서 colima 또는 qemu-system-x86_64를 검색하여 CPU 및 메모리 사용량을 확인할 수 있습니다.

3. Colima 관리

3.1 Colima 중지

작업이 끝난 후 Colima를 중지하여 리소스와 배터리를 절약합니다.

colima stop

3.2 Colima 재시작

Colima를 다시 시작하려면:

colima start

• 이전 상태에서 VM을 재시작합니다.

3.3 Colima 자동 시작 설정

Mac을 부팅할 때 자동으로 Colima를 실행하려면:

colima start --daemon

• Colima가 백그라운드에서 자동으로 실행됩니다.

4. Colima 활용 팁

4.1 컨테이너 정리

사용하지 않는 컨테이너를 정리하여 리소스를 확보합니다:

docker container prune

4.2 네트워크 확인

Docker 네트워크를 확인하고 관리하려면:

docker network ls

4.3 파일 공유 최적화

Colima VM과 macOS 간의 파일 공유를 최적화하려면 VirtioFS를 활성화합니다:

colima start --filesystem virtiofs

4.4 Kubernetes 사용

Kubernetes가 필요한 경우 Colima에서 활성화 가능합니다:

colima start --with-kubernetes

• Kubernetes가 필요 없는 경우 기본 설정으로 사용하여 배터리 소모를 줄입니다.

5. Colima 관리 주요 명령어

6. Colima의 주요 이점

1. 낮은 배터리 소모:
   • Docker Desktop 대비 리소스 사용량과 배터리 소모가 적습니다.
2. 간단한 설정:
   • CLI 중심의 간단한 명령어로 VM을 유연하게 관리할 수 있습니다.
3. Kubernetes 지원:
   • 필요 시 Kubernetes를 손쉽게 활성화할 수 있습니다.
4. Docker Desktop 대체:
   • GUI 기반 Docker Desktop 없이도 macOS에서 효율적인 Docker 환경을 제공합니다.

7. 추천 운영 방식

1. 작업 전 Colima 시작:
   • 작업 시작 전에 colima start로 VM을 시작합니다.
   • 필요할 경우, CPU 및 메모리 설정을 조정하여 시작합니다.
2. 작업 후 Colima 중지:
   • 작업이 끝난 후 colima stop으로 Colima를 중지하여 배터리 소모를 방지합니다.
3. 리소스 확인 및 정리:
   • docker stats로 컨테이너 리소스 사용량을 모니터링.
   • 필요하지 않은 컨테이너 및 네트워크를 주기적으로 정리.
4. 파일 공유 최적화:
   • VirtioFS를 사용하여 파일 시스템 속도를 최적화합니다.

Colima는 macOS에서 Docker Desktop을 대체할 수 있는 훌륭한 도구입니다. 간단한 설치와 효율적인 관리 기능을 통해 배터리 사용량을 줄이고, 개발 환경을 최적화할 수 있습니다.

오랜만에 다시 블로그 포스팅을 남겨본다. 최근 진행하는 프로젝트 중 Postgres 를 많이 다루고 있는데 자주쓰는게 있어서 기록차원에서 남겨봄. CTE(Common Table Expression)에 대한 개념과 실무에서 자주 활용하는 비중(Portion) 기반의 할인 안분 계산 방법을 다뤄보려고 함. 이 내용을 알면, 복잡한 할인 계산을 단순화하고, SQL 쿼리의 가독성과 효율성을 높일 수 있음.

1️⃣ CTE(Common Table Expression) 개념과 원리

1. CTE란?

• CTE (Common Table Expression)는 SQL의 WITH 절을 사용해 임시 테이블을 만드는 방법
• 서브쿼리와 비슷하지만, 한 번만 정의해 여러 번 재사용할 수 있다는 게 가장 큰 장점
• SQL의 가독성을 높이고, 복잡한 쿼리를 단순화할 때 아주 유용함
• 서브쿼리와의 차이점: 서브쿼리는 중첩된 형태로 작성되며 매번 새로 계산되지만, CTE는 이름을 지정해 한 번 정의한 뒤 여러 번 재사용할 수 있음. 그래서 가독성과 성능 측면에서 더 유리함.

2. CTE의 문법

WITH cte_name AS (
    -- 하위 쿼리 (임시 테이블)
    SELECT column1, column2
    FROM some_table
    WHERE some_condition
)
-- 메인 쿼리 (CTE를 참조)
SELECT * FROM cte_name;

3. CTE의 활용 사례

• 복잡한 서브쿼리를 단순화하고, 중복 계산을 피할 수 있음.
• 재귀 쿼리: 계층 구조(조직도, 카테고리) 데이터를 다룰 때 자주 써.
• 집계 및 임시 테이블 생성: 임시로 집계한 데이터를 메인 쿼리에서 재사용할 때도 좋아.
• 쿼리 재사용: CTE는 여러 메인 쿼리에서 참조할 수 있기 때문에, 반복 작업을 줄일 수 있어.

2️⃣ 비중(Portion) 기반의 할인 안분 계산

1. 문제 정의

판매 내역 데이터를 기준으로, 장바구니 기준 할인과 상품 기준 할인을 동시에 계산해야 해.

목표

이 글의 목표는 할인 안분 계산의 실전 적용 방법을 명확히 이해하고, 이를 활용해 효율적인 SQL 쿼리 작성 능력을 키우는 것이야. 구체적으로, 다음 두 가지를 다룰 거야.

1. 장바구니 기준 할인: 장바구니(cart_id)별 총 할인 금액을 각 상품의 금액 비중으로 나눔.
2. 상품 기준 할인: 상품(product_id)별 총 할인 금액을 각 상품의 수량 비중으로 나눔.

할인 공식

• 장바구니 기준 상품별 할인 = (상품 금액 / 장바구니 총 금액) × 장바구니 할인 금액
• 상품 기준 상품별 할인 = (상품 수량 / 상품 총 수량) × 상품별 할인 금액

3️⃣ 예제 테이블 및 데이터

1. 테이블 생성

CREATE temp TABLE t_sales (
    order_id SERIAL PRIMARY KEY,       -- 주문 ID
    cart_id INT NOT NULL,               -- 장바구니 ID
    product_id INT NOT NULL,            -- 상품 ID
    product_name VARCHAR(100) NOT NULL, -- 상품 이름
    quantity INT NOT NULL,              -- 판매 수량
    price NUMERIC(10, 2) NOT NULL,      -- 단가 (개당 가격)
    cart_discount NUMERIC(10, 2),       -- 장바구니 기준 할인 금액
    product_discount NUMERIC(10, 2)     -- 상품 기준 할인 금액
);

2. 데이터 삽입

INSERT INTO t_sales (cart_id, product_id, product_name, quantity, price, cart_discount, product_discount) VALUES
(1, 101, '노트북', 1, 1000.00, 100.00, 50.00), 
(1, 102, '마우스', 2, 25.00, 100.00, 10.00), 
(1, 103, '키보드', 1, 50.00, 100.00, 5.00), 
(2, 101, '노트북', 2, 1000.00, 200.00, 80.00), 
(2, 104, '모니터', 1, 300.00, 200.00, 40.00), 
(3, 105, 'USB 메모리', 3, 15.00, 50.00, 5.00), 
(3, 103, '키보드', 2, 50.00, 50.00, 10.00), 
(4, 102, '마우스', 5, 25.00, 30.00, 5.00), 
(4, 105, 'USB 메모리', 1, 15.00, 30.00, 2.00), 
(5, 104, '모니터', 3, 300.00, 0.00, 60.00);

4️⃣ 최적화된 CTE 쿼리

쿼리 작성

이 쿼리는 장바구니와 상품 기준으로 할인을 동시에 계산하는 예시야. 여기서의 목표는 중복 계산을 피하고, 효율성을 높이는 CTE 활용법을 보여주는 것이야. CTE에서 미리 비중(Portion)을 구해두고, 최종 쿼리에서 간단히 결과를 출력하는 방식으로 쿼리 성능을 최적화했어.

WITH cart_summary AS (
    -- 장바구니(cart_id)별 총 금액 및 총 할인 금액
    SELECT 
        cart_id,
        SUM(quantity * price) AS total_cart_price,
        SUM(cart_discount) AS total_cart_discount
    FROM t_sales
    GROUP BY cart_id
), 
product_summary AS (
    -- 상품(product_id)별 총 판매 수량 및 총 할인 금액
    SELECT 
        product_id,
        product_name,
        SUM(quantity) AS total_quantity,
        SUM(quantity * price) AS total_product_sales,
        SUM(product_discount) AS total_product_discount
    FROM t_sales
    GROUP BY product_id, product_name
), 
portion_calculations AS (
    -- CTE 레벨에서 장바구니와 상품의 비중(Portion)을 미리 계산
    SELECT 
        ts.order_id,
        ts.cart_id,
        ts.product_id,
        ts.product_name,
        ts.quantity,
        ts.price,
        ts.quantity * ts.price AS product_price,
        -- 비중 (상품 금액 / 장바구니 총 금액)
        (ts.quantity * ts.price) / cs.total_cart_price AS cart_portion,
        -- 비중 (상품 수량 / 상품 총 수량)
        ts.quantity / ps.total_quantity AS product_portion,
        -- 장바구니 기준 할인 (비중 * 장바구니 할인)
        ((ts.quantity * ts.price) / cs.total_cart_price) * cs.total_cart_discount AS cart_discount_allocation,
        -- 상품 기준 할인 (비중 * 상품 할인)
        (ts.quantity / ps.total_quantity) * ps.total_product_discount AS product_discount_allocation
    FROM t_sales ts
    JOIN cart_summary cs ON ts.cart_id = cs.cart_id
    JOIN product_summary ps ON ts.product_id = ps.product_id
)
-- 최종 결과 출력
SELECT 
    order_id,
    cart_id,
    product_id,
    product_name,
    quantity,
    price,
    product_price,
    ROUND(cart_portion, 4) AS cart_portion,
    ROUND(product_portion, 4) AS product_portion,
    ROUND(cart_discount_allocation, 2) AS cart_discount_allocation,
    ROUND(product_discount_allocation, 2) AS product_discount_allocation,
    ROUND(cart_discount_allocation + product_discount_allocation, 2) AS total_discount
FROM portion_calculations;

5️⃣ 최종 정리

왜 이렇게 하는 걸까?

1. 효율성: 비중(Portion)을 미리 계산해두면 중복 연산을 줄일 수 있어. 예를 들어, 한 번의 쿼리 실행으로 총 실행 시간이 5초에서 3초로 줄어들 수 있어.
2. 가독성: 메인 쿼리가 더 단순해져서, 유지보수가 쉬워. 불필요한 중복 계산이 없어지니까 쿼리의 흐름이 명확해져.
3. 성능 최적화: CTE 레벨에서 미리 계산을 마치고 메인 쿼리에서는 간단히 조합만 하니까, 전체 실행 속도가 더 빨라져. 특히, 대용량 데이터셋에서도 효율적이야.

6️⃣ 마무리

이번 글에서는 CTE(Common Table Expression)와 비중(Portion) 기반의 할인 안분 계산 방법을 다뤘어. 장바구니 기준 할인과 상품 기준 할인을 동시에 계산하는 실전 예시도 소개했으니까, 직접 DBeaver에서 실행해보면서 익혀보길 추천할게!

💡 이 글이 유익했다면 댓글로 피드백 부탁해!

궁금한 부분이 있으면 댓글로 남겨줘. 추가로 설명할게!

Next.js는 React 기반의 강력한 웹 프레임워크로, 서버 사이드 렌더링(SSR)과 정적 사이트 생성(SSG)을 쉽게 구현할 수 있게 해줍니다. Next.js 13 버전부터는 기존의 Pages Router와 함께 새로운 App Router가 도입되었습니다. 이 포스트에서는 두 라우팅 시스템의 차이점을 자세히 살펴보고, 각각의 장단점을 비교해보겠습니다.

목차

1. Pages Router 소개
2. App Router 소개
3. 주요 차이점
4. Pages Router 예제
5. App Router 예제
6. 언제 어떤 라우터를 사용해야 할까?
7. 결론

Pages Router 소개

Pages Router는 Next.js의 전통적인 라우팅 시스템입니다. 이 시스템은 파일 시스템 기반 라우팅을 사용하며, pages 디렉토리 내의 파일 구조가 곧 애플리케이션의 라우트 구조가 됩니다.

주요 특징:

• pages 디렉토리 사용
• 파일 이름 기반의 라우팅
• getStaticProps, getServerSideProps 등을 통한 데이터 페칭
• 간단하고 직관적인 구조

App Router 소개

App Router는 Next.js 13에서 도입된 새로운 라우팅 시스템입니다. React 18의 새로운 기능들을 활용하며, 특히 React Server Components를 기본적으로 지원합니다.

주요 특징:

• app 디렉토리 사용
• 폴더 구조 기반의 라우팅
• 레이아웃, 로딩 상태, 에러 처리 등을 위한 특수 파일들
• 서버 컴포넌트 기본 지원
• 향상된 성능과 유연성

주요 차이점

1. 디렉토리 구조
   • Pages Router: pages 디렉토리
   • App Router: app 디렉토리
2. 라우트 정의
   • Pages Router: 파일 이름으로 라우트 정의
   • App Router: 폴더 이름으로 라우트 정의, page.js 파일이 해당 라우트의 UI를 담당
3. 레이아웃
   • Pages Router: _app.js와 _document.js로 전역 레이아웃 관리
   • App Router: 각 폴더에 layout.js 파일을 두어 중첩 레이아웃 쉽게 구현
4. 데이터 페칭
   • Pages Router: getStaticProps, getServerSideProps 등의 특수 함수 사용
   • App Router: 컴포넌트 내에서 직접 async/await 사용 가능
5. 서버 컴포넌트
   • Pages Router: 클라이언트 컴포넌트만 사용
   • App Router: 서버 컴포넌트 기본 지원, 'use client' 지시어로 클라이언트 컴포넌트 지정
6. 동적 라우트
   • Pages Router: [param].js 파일로 동적 라우트 생성
   • App Router: [param] 폴더로 동적 라우트 생성

Pages Router 예제

다음은 Pages Router를 사용한 간단한 블로그 애플리케이션의 예제입니다:

pages/
  index.js
  about.js
  posts/
    [id].js

pages/index.js

import Link from 'next/link'

export default function Home() {
  return (
    <div>
      <h1>Welcome to my blog</h1>
      <Link href="/about">About</Link>
      <Link href="/posts/1">First Post</Link>
    </div>
  )
}

pages/about.js

export default function About() {
  return <h1>About Us</h1>
}

pages/posts/[id].js

import { useRouter } from 'next/router'

export default function Post() {
  const router = useRouter()
  const { id } = router.query

  return <h1>Post: {id}</h1>
}

export async function getServerSideProps(context) {
// 서버 사이드에서 데이터 페칭
  return {
    props: {},// 컴포넌트에 전달할 props
  }
}

App Router 예제

같은 블로그 애플리케이션을 App Router로 구현해보겠습니다:

app/
  layout.js
  page.js
  about/
    page.js
  posts/
    [id]/
      page.js

app/layout.js

export default function RootLayout({ children }) {
  return (
    <html lang="en">
      <body>{children}</body>
    </html>
  )
}

app/page.js

import Link from 'next/link'

export default function Home() {
  return (
    <div>
      <h1>Welcome to my blog</h1>
      <Link href="/about">About</Link>
      <Link href="/posts/1">First Post</Link>
    </div>
  )
}

app/about/page.js

export default function About() {
  return <h1>About Us</h1>
}

app/posts/[id]/page.js

export default function Post({ params }) {
  return <h1>Post: {params.id}</h1>
}

// 서버 컴포넌트에서 직접 데이터 페칭
export async function generateMetadata({ params }) {
  const post = await fetchPost(params.id)
  return { title: post.title }
}

언제 어떤 라우터를 사용해야 할까?

1. Pages Router 사용이 좋은 경우:
   • 기존 Next.js 프로젝트를 유지보수하는 경우
   • 팀이 새로운 App Router에 익숙하지 않은 경우
   • 간단한 웹사이트나 애플리케이션을 빠르게 개발해야 하는 경우
2. App Router 사용이 좋은 경우:
   • 새로운 프로젝트를 시작하는 경우
   • 서버 컴포넌트의 이점을 활용하고 싶은 경우
   • 복잡한 레이아웃 구조가 필요한 경우
   • 최신 React 기능을 최대한 활용하고 싶은 경우

결론

Pages Router와 App Router는 각각의 장단점이 있습니다. Pages Router는 간단하고 직관적이지만, App Router는 더 강력하고 유연한 기능을 제공합니다. 프로젝트의 요구사항과 팀의 숙련도를 고려하여 적절한 라우팅 시스템을 선택하는 것이 중요합니다. Next.js는 두 시스템을 동시에 지원하므로, 필요에 따라 점진적으로 App Router로 마이그레이션할 수 있습니다.

Next.js의 발전과 함께 App Router가 더욱 중요해질 것으로 예상되므로, 새로운 프로젝트를 시작한다면 App Router를 고려해보는 것이 좋겠습니다. 하지만 궁극적으로는 프로젝트의 특성과 팀의 상황에 가장 적합한 선택을 해야 합니다.

실제 차이 예시

PagesRouter

import type { NextApiRequest, NextApiResponse } from 'next'

export default async function handler(req: NextApiRequest, res: NextApiResponse) {
  const { memberIdx, page = '0', size = '10' } = req.query;

  try {
    const response = await fetch(`${process.env.API_BASE_URL}/short-url/list?memberIdx=${memberIdx}&page=${page}&size=${size}`, {
      headers: {
        // 필요한 경우 인증 헤더 등을 추가
      },
    });

    if (!response.ok) {
      throw new Error('Failed to fetch short URLs');
    }

    const data = await response.json();
    res.status(200).json(data);
  } catch (error) {
    console.error('Error fetching short URLs:', error);
    res.status(500).json({ error: 'Failed to fetch short URLs' });
  }
}

AppRouter

import { NextResponse } from 'next/server';

export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const memberIdx = searchParams.get('memberIdx');
  const page = searchParams.get('page') || '0';
  const size = searchParams.get('size') || '10';

  try {
    const response = await fetch(`${process.env.API_BASE_URL}/short-url/list?memberIdx=${memberIdx}&page=${page}&size=${size}`, {
      headers: {
        // 필요한 경우 인증 헤더 등을 추가
      },
    });

    console.log(response);

    if (!response.ok) {
      throw new Error('Failed to fetch short URLs');
    }

    const data = await response.json();
    return NextResponse.json(data);
  } catch (error) {
    console.error('Error fetching short URLs:', error);
    return NextResponse.json({ error: 'Failed to fetch short URLs' }, { status: 500 });
  }
}

실제 사용 경험과 추세

1. Pages Router 선호 이유:
   • 익숙함: 많은 개발자들이 이미 Pages Router에 익숙합니다.
   • 단순성: 간단한 프로젝트에서는 Pages Router가 더 직관적일 수 있습니다.
   • 안정성: Pages Router는 오랜 기간 사용되어 안정적입니다.
   • 학습 곡선: App Router는 새로운 개념 학습이 필요합니다.
2. App Router 불편 사항:
   • 복잡성: 일부 개발자들은 App Router의 구조가 더 복잡하다고 느낍니다.
   • 호환성 문제: 일부 라이브러리가 App Router와 완벽히 호환되지 않을 수 있습니다.
   • 변화 속도: Next.js의 빠른 변화로 인한 학습 부담이 있습니다.
3. 실제 사용 추세:
   • 점진적 도입: 많은 팀들이 새 프로젝트에서 App Router를 시도하고 있습니다.
   • 혼합 사용: 일부는 두 라우터를 혼합해서 사용하며 점진적으로 전환합니다.
   • 기업 환경: 대규모 기업에서는 안정성 때문에 Pages Router를 선호하는 경향이 있습니다.

npm과 Yarn은 모두 Node.js에서 사용하는 패키지 매니저로, 프로젝트의 의존성을 설치하고 관리하는 데 사용됩니다. 두 패키지 매니저는 유사하지만 성능, 기능, 사용 편의성 측면에서 차이점이 있습니다. 이 포스팅에서는 npm과 Yarn의 특징과 차이점을 비교하고, 각 패키지 매니저의 장단점 및 주요 명령어를 소개합니다.

npm 소개

npm(Node Package Manager)은 Node.js와 함께 기본으로 제공되는 패키지 매니저로, 전 세계적으로 가장 많이 사용됩니다. package.json 파일을 통해 프로젝트의 의존성을 정의하고, 패키지를 설치하거나 관리할 수 있습니다.

• 출시: 2010년, Node.js와 함께
• 기본 제공: Node.js를 설치하면 자동으로 npm도 설치됩니다.
• 저장소: npm 레지스트리에는 180만 개 이상의 패키지가 등록되어 있으며, Node.js 생태계에서 중요한 역할을 담당하고 있습니다.

Yarn 소개

Yarn은 2016년에 Facebook에서 개발한 패키지 매니저로, npm의 속도와 안정성을 개선하기 위해 만들어졌습니다. 병렬 설치 및 오프라인 캐싱과 같은 기능을 통해 npm보다 더 빠른 패키지 설치 경험을 제공합니다.

• 출시: 2016년
• 주요 특징: 더 빠른 설치 속도, 캐싱, 워크스페이스 지원

npm vs Yarn: 주요 차이점

npm의 장점과 단점

장점

• Node.js 기본 패키지 매니저로 설치와 사용이 간편합니다.
• 전 세계적으로 사용되며, 방대한 패키지 레지스트리를 통해 다양한 패키지를 사용할 수 있습니다.
• npm audit을 통해 보안 취약점을 검사할 수 있습니다.
• npm 5 이후 속도와 성능이 크게 개선되었습니다.

단점

• 이전 버전의 npm은 설치 속도가 느리고, 의존성 충돌 문제가 발생할 수 있었습니다.
• 패키지 잠금 파일(package-lock.json)과 설치된 패키지 간의 일관성이 문제가 되는 경우가 있었습니다.

Yarn의 장점과 단점

장점

• 더 빠른 패키지 설치 속도: Yarn은 병렬 설치와 캐시를 통해 npm보다 더 빠르게 패키지를 설치할 수 있습니다.
• 오프라인 캐싱: 한 번 설치된 패키지를 캐시에서 다시 불러오기 때문에, 네트워크 없이도 설치가 가능합니다.
• 워크스페이스 지원: Monorepo(여러 프로젝트를 하나의 저장소에서 관리) 환경에서 의존성을 쉽게 관리할 수 있습니다.
• 무결성 검사: 패키지가 변조되지 않았음을 확인할 수 있는 무결성 검사를 제공합니다.

단점

• Yarn은 npm과 호환되지만, 특정 상황에서는 두 패키지 매니저 간의 충돌이 발생할 수 있습니다.
• npm 5 이후 속도 차이가 크게 줄어들어, Yarn만의 큰 장점이 감소한 측면이 있습니다.

주요 명령어 비교

결론

npm과 Yarn은 모두 훌륭한 패키지 매니저입니다. npm은 Node.js와 함께 제공되는 기본 패키지 매니저로, 최근 버전에서 성능과 기능이 크게 개선되었습니다. 반면, Yarn은 빠른 설치 속도와 오프라인 캐싱, Monorepo 지원 등 강력한 기능을 제공하며, 특히 대규모 프로젝트에서 장점을 발휘합니다.

언제 npm을 선택할까?

• Node.js와의 기본 통합이 필요한 경우
• 더 단순한 프로젝트 구조나 작은 프로젝트에서

언제 Yarn을 선택할까?

• Monorepo 구조를 사용하는 프로젝트
• 패키지 설치 속도와 오프라인 캐싱이 중요한 대규모 프로젝트에서

각 프로젝트의 요구 사항에 맞춰 npm 또는 Yarn을 선택하여 사용할 수 있습니다.

PM2는 Node.js 애플리케이션을 위한 프로덕션 레벨의 프로세스 관리자입니다. 서버 재부팅 후에도 애플리케이션을 계속 실행할 수 있게 하고, 프로세스 모니터링, 로깅, 클러스터링 등 다양한 기능을 제공합니다. 특히, 실시간 프로세스 관리 및 자동 재시작을 통해 안정적인 서버 운영을 돕습니다.

주요 특장점

1. 프로세스 관리

• PM2는 서버에서 실행되는 Node.js 애플리케이션을 백그라운드에서 실행하며, 각 프로세스의 상태를 쉽게 모니터링할 수 있습니다.
• 자동 재시작: 애플리케이션이 크래시하면 자동으로 재시작해줍니다.
• 자동 재부팅: 서버가 재부팅될 때, PM2는 애플리케이션을 자동으로 다시 시작합니다.

2. 클러스터 모드

• PM2는 클러스터 모드를 제공하여 여러 CPU 코어에서 로드 분산을 자동으로 처리합니다. 이 기능을 통해 성능을 최대한 활용할 수 있습니다.

3. 실시간 로그 및 모니터링

• PM2는 실시간 로그를 제공하여 현재 프로세스의 상태와 로그를 즉시 확인할 수 있습니다.
• pm2 monit 명령어를 통해 실시간으로 메모리, CPU, 프로세스 상태 등을 모니터링할 수 있습니다.

4. 배포 관리

• PM2는 배포 환경에서도 사용 가능하며, 자동화된 배포와 롤백 등의 기능을 지원합니다.

5. 유연한 구성 및 통합

• ecosystem.config.js 파일을 통해 다중 애플리케이션을 관리하거나, 특정 스크립트, 포트, 환경 설정 등을 미리 정의할 수 있습니다.

PM2 설치

npm install pm2 -g

이 명령어로 PM2를 전역으로 설치한 후, 애플리케이션 관리를 시작할 수 있습니다.

자주 사용하는 명령어

1. 애플리케이션 시작

pm2 start app.js

이 명령어는 app.js 파일을 백그라운드에서 실행합니다.

npm/yarn 명령어 사용:

pm2 start yarn --name "app-name" -- start

2. 프로세스 목록 보기

pm2 list

현재 실행 중인 모든 프로세스의 상태를 확인할 수 있습니다.

3. 프로세스 재시작

pm2 restart app-name

프로세스 이름 또는 ID로 재시작할 수 있습니다.

4. 프로세스 종료

pm2 stop app-name

애플리케이션을 종료합니다.

5. 프로세스 삭제

pm2 delete app-name

프로세스를 종료하고 PM2에서 제거합니다.

6. 애플리케이션 로그 확인

pm2 logs

애플리케이션의 실시간 로그를 확인할 수 있습니다.

7. 애플리케이션 상태 모니터링

pm2 monit

메모리, CPU 사용량 및 프로세스 상태를 실시간으로 모니터링할 수 있습니다.

8. PM2 상태 저장 및 자동 재시작 설정

서버 재부팅 후 자동 재시작 설정:

pm2 startup

현재 상태 저장:

pm2 save

이 명령은 서버가 재시작되면 PM2가 자동으로 시작되도록 설정합니다.

PM2의 장단점

장점

• 자동 재시작: 애플리케이션이 중단되었을 때 자동으로 다시 시작되므로 서비스 중단을 방지합니다.
• 클러스터 모드: 여러 CPU 코어를 활용하여 애플리케이션의 성능을 극대화합니다.
• 쉬운 모니터링: 실시간으로 프로세스를 관리하고 로그를 확인할 수 있어 문제를 빠르게 해결할 수 있습니다.
• 간편한 배포: 여러 애플리케이션을 동시에 관리할 수 있으며, 설정 파일을 통해 자동화된 배포 프로세스를 지원합니다.

단점

• 리소스 소비: 백그라운드에서 실행되므로, 대규모 애플리케이션에서는 리소스가 추가로 소모될 수 있습니다.
• 초기 설정: 다중 애플리케이션 및 복잡한 설정이 필요한 경우, 처음에는 설정이 다소 복잡할 수 있습니다.

결론

PM2는 안정적인 Node.js 애플리케이션 관리를 위한 훌륭한 도구로, 자동화, 모니터링, 클러스터링 등 다양한 기능을 제공하여 프로덕션 환경에서도 안정적으로 애플리케이션을 운영할 수 있도록 도와줍니다. 쉽고 유연한 설정으로 작은 프로젝트부터 대규모 서비스까지 적용 가능하며, 특히 장기적으로 안정성과 모니터링이 중요한 환경에서 큰 장점을 발휘합니다.

LLM(대형 언어 모델)을 활용한 Chat 서비스를 만들면서, 기존 방식으로는 긴 응답 시간을 기다리는 것이 사용자 경험에 좋지 않은 영향을 미친다는 것을 깨달았습니다. 응답이 완전히 처리될 때까지 기다려야 하는 구조는 사용자에게 답변이 지연된 것처럼 느껴지게 했습니다. 이를 해결하기 위해 SSE(Server-Sent Events)를 이용해 실시간 스트리밍 응답 방식을 도입하여 사용자 경험을 크게 개선했습니다.

이번 글에서는 제가 어떻게 기존의 Chat 서비스를 스트리밍 기반으로 전환했는지, 그리고 그로 인해 사용자 인터페이스(UI)와 경험이 어떻게 개선되었는지를 공유하려 합니다.

문제점

기존의 API 통신 방식에서는 axios를 사용하여 Chat GPT API에 요청을 보내고, 서버로부터 응답이 전부 도착한 후에야 사용자에게 메시지를 전달했습니다. 이 방식은 큰 모델의 긴 응답 시간이 있을 때 사용자가 아무런 피드백 없이 기다리게 되어, 느리다는 인식을 주기 쉽습니다.

해결 방법: 스트리밍 기반의 처리

이 문제를 해결하기 위해 SSE(Server-Sent Events)를 활용하여 서버가 응답을 생성하는 대로 실시간으로 데이터를 전송하고, 클라이언트에서 이를 즉시 렌더링하는 방식을 도입했습니다.

SSE는 한 번의 HTTP 연결로 서버에서 발생하는 이벤트를 클라이언트에 실시간으로 전달할 수 있게 해주는 기술입니다. 이를 활용하면 서버의 응답을 스트리밍 형태로 받아서 사용자에게 실시간으로 출력할 수 있습니다.

변경된 코드 분석

1. index.tsx 변경사항

클라이언트 측에서 스트리밍 처리

index.tsx 파일에서는 기존에 axios로 요청을 보내고 전부 응답을 받은 후 처리하던 로직을 fetch로 대체하여 스트리밍 데이터를 처리할 수 있도록 변경했습니다.

const handleSendMessage = async (message: string) => {
  // Fetch를 사용하여 서버에 메시지 전송
  const response = await fetch('/api/chat', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ message }),
  })

  const reader = response.body?.getReader()
  if (!reader) throw new Error('No reader')

  // 비동기로 서버에서 오는 데이터를 스트림 처리
  let assistantMessage: Message = { role: 'assistant', content: '' }
  setCurrentChat(prev => ({
    ...prev!,
    messages: [...prev!.messages, assistantMessage],
  }))

  while (true) {
    const { done, value } = await reader.read()
    if (done) break

    const chunk = new TextDecoder().decode(value)
    const lines = chunk.split('\\n').filter(line => line.trim() !== '')

    for (const line of lines) {
      const message = line.replace(/^data: /, '')
      if (message === '[DONE]') {
        setIsLoading(false)
        return
      }
      try {
        const parsed = JSON.parse(message)
        assistantMessage.content += parsed.content
        setCurrentChat(prev => ({
          ...prev!,
          messages: [...prev!.messages.slice(0, -1), { ...assistantMessage }],
        }))
      } catch (error) {
        console.error('Error parsing SSE message:', error)
      }
    }
  }
}

주요 변경 사항:

• axios → fetch: fetch는 스트리밍 응답을 쉽게 처리할 수 있기 때문에 사용했습니다.
• ReadableStream 사용: 서버에서 오는 데이터를 스트리밍 방식으로 읽기 위해 ReadableStream을 사용했습니다.
• 각 스트리밍 청크를 수신하고 즉시 메시지를 업데이트하여, 사용자가 실시간으로 응답을 받을 수 있도록 했습니다.

2. chat.ts 변경사항

서버 측에서 스트리밍 응답 구현

chat.ts 파일에서는 서버가 스트리밍으로 응답할 수 있도록 SSE 헤더를 설정하고, OpenAI API로부터 받은 스트리밍 데이터를 클라이언트에 전송하는 로직을 추가했습니다.

export default async function handler(
  req: NextApiRequest,
  res: NextApiResponse
) {
  res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache, no-transform',
    'Connection': 'keep-alive',
  })

  try {
    const response = await axios.post(
      '<https://api.openai.com/v1/chat/completions>',
      {
        // OpenAI API에 스트리밍 옵션 추가
        stream: true,
      },
      {
        headers: {
          'Authorization': `Bearer ${process.env.OPENAI_API_KEY}`,
        },
        responseType: 'stream',
      }
    )

    response.data.on('data', (chunk: Buffer) => {
      const lines = chunk.toString().split('\\n').filter(line => line.trim() !== '')
      for (const line of lines) {
        const message = line.replace(/^data: /, '')
        if (message === '[DONE]') {
          res.write(`data: [DONE]\\n\\n`)
          res.end()
          return
        }
        try {
          const parsed = JSON.parse(message)
          const content = parsed.choices[0].delta.content
          if (content) {
            res.write(`data: ${JSON.stringify({ content })}\\n\\n`)
          }
        } catch (error) {
          console.error('Error parsing SSE message:', error)
        }
      }
    })
  } catch (error) {
    res.write(`data: ${JSON.stringify({ error: 'Error processing your request' })}\\n\\n`)
    res.end()
  }
}

주요 변경 사항:

• SSE 헤더 설정: Content-Type을 'text/event-stream'으로 설정하고, 캐시를 비활성화하는 등의 옵션을 추가했습니다.
• OpenAI API의 스트리밍 처리: OpenAI API 요청 시 stream: true 옵션을 활성화하고, 스트리밍 응답을 받아서 클라이언트로 전송합니다.
• 각 청크가 수신될 때마다 실시간으로 데이터를 파싱하여 클라이언트에 전송합니다.

스트리밍 방식의 장점

이렇게 스트리밍 방식을 적용한 후, 사용자 경험은 크게 개선되었습니다.

• 빠른 피드백: AI가 답변을 생성하는 즉시 사용자에게 전달되므로, 사용자는 응답이 실시간으로 생성되는 과정을 볼 수 있습니다.
• 응답 시간 단축 체감: 실제로 처리되는 총 응답 시간은 동일할 수 있지만, 사용자가 실시간으로 답변을 확인할 수 있기 때문에 기다리는 시간이 짧게 느껴집니다.
• UX 향상: 사용자는 더 이상 아무런 피드백 없이 기다리지 않아도 되며, 즉시 결과를 확인할 수 있어 더욱 직관적이고 만족스러운 경험을 제공합니다.

결론

이번 스트리밍 기반의 LLM Chat 서비스 개선 작업을 통해 실시간 피드백의 중요성을 깨달았습니다. 사용자가 기다리는 동안 계속해서 피드백을 제공하는 방식은 단순한 성능 개선 이상의 사용자 경험(UX) 향상으로 이어질 수 있습니다.

SSE를 활용한 실시간 스트리밍 응답은 특히 대화형 AI 서비스와 같이 응답 시간이 중요한 서비스에 강력한 도구가 될 수 있습니다. 앞으로 더 많은 기능을 개선하고 최적화하며 더 나은 사용자 경험을 제공할 수 있도록 노력할 계획입니다.

미션

"개인과 기업이 생산성, 효율성, 그리고 성장을 통해 더 큰 가치를 창출하고, 세상에 긍정적인 영향력을 미칠 수 있도록 지원합니다."

"개인과 기업이 업무 효율성과 생산성을 극대화하여 더 큰 가치를 창출하도록 지원합니다. 이를 통해 모두에게 유익을 주는 세상을 만들어갑니다."

비전

"모두가 자신의 잠재력을 최대한 발휘하여 세상을 더 나은 곳으로 변화시키는 미래를 함께 만들어 나가겠습니다."

"모두가 자신의 잠재력을 최대한 발휘하고, 세상에 긍정적인 변화를 함께 만들어가겠습니다."

(참고) 빅테크 기업의 비전과 미션

1. 애플 (Apple) - 스티브 잡스, 스티브 워즈니악
   - 초기 비전: 개인용 컴퓨터를 모든 사람의 손에 쥐어주자.
   - 미션: 기술을 단순하고 직관적으로 만들어 일반 대중이 쉽게 접근할 수 있도록 하여 개인의 창의성과 생산성을 향상시키는 것.
   - 현재 비전: "세상에서 가장 훌륭한 제품을 만들어 사람들의 삶을 향상시키는 것"
2. 마이크로소프트 (Microsoft) - 빌 게이츠, 폴 앨런
   - 초기 비전: "모든 책상과 가정에 컴퓨터를 한 대씩 놓자."
   - 미션: 소프트웨어를 통해 개인과 기업의 생산성을 높이고 기술의 민주화를 실현하는 것.
   - 현재 비전: "지구상의 모든 개인과 조직이 더 많은 성과를 이루도록 돕는 것"
3. 구글 (Google) - 래리 페이지, 세르게이 브린
   - 초기 비전: "전 세계의 정보를 체계화하여 모두가 접근 가능하고 유용하게 만들자."
   - 미션: 방대한 인터넷 정보를 효율적으로 검색하고 제공하여 지식의 접근성을 높이는 것.
   - 현재 비전: "사용자가 필요한 정보를 즉시 얻을 수 있도록 도와주고, 전 세계의 정보를 조직화하여 모두에게 유용하게 제공"
4. 아마존 (Amazon) - 제프 베조스
   - 초기 비전: "세계에서 가장 고객 중심적인 회사가 되자.
   - 미션: 고객들이 온라인에서 무엇이든 찾아서 구매할 수 있는 플랫폼을 제공하여 쇼핑 경험을 혁신하는 것.
   - 현재 비전: "고객 중심적인 회사로, 사람들이 온라인에서 무엇이든 찾고, 발견하고, 구매할 수 있도록 돕는 것"
5. 페이스북 (Facebook, 현재 Meta Platforms) - 마크 저커버그
   - 초기 비전: "사람들을 연결하여 더 개방적이고 연결된 세상을 만들자.
   - 미션: 전 세계 사람들이 쉽게 소통하고 정보를 공유할 수 있는 플랫폼을 제공하는 것.
   - 현재 비전: "커뮤니티를 만들고 세상을 더 가깝게 만드는 것"
6. 테슬라 (Tesla) - 엘론 머스크
   - 초기 비전: "지속 가능한 에너지로의 전환을 가속화하자."
   - 미션: 전기 자동차와 재생 에너지 솔루션을 통해 환경에 긍정적인 영향을 미치는 것.
7. 넷플릭스 (Netflix) - 리드 헤이스팅스, 마크 랜돌프
   - 초기 비전: "인터넷을 통해 영화를 대여하고 감상할 수 있게 하자."
   - 미션: 엔터테인먼트 콘텐츠의 접근성을 높이고 사용자에게 개인화된 경험을 제공하는 것.

공통된 특징과 시사점

• 접근성 확대: 기술이나 서비스를 통해 더 많은 사람들이 혜택을 받을 수 있도록 함.
• 문제 해결: 기존의 불편함이나 비효율성을 개선하여 사용자 경험을 혁신.
• 생산성 향상: 개인과 기업이 더 나은 성과를 낼 수 있도록 도와줌.
• 긍정적 영향력: 세상에 선한 영향력을 미치고자 하는 목표.

→ "문제 해결"과 "접근성 확대"

최근 말하기에 대한 부족함을 많이 느낀다.

마치 뒤에 누군가 쫓아오고 있는것처럼 급하다. 마음의 여유가 없는 탓일까? 아니면 오랫동안 그렇게 지내온 탓에 마치 몸에 스며든 습관같은걸까?

오늘 잠재 고객과 줌미팅을 하는 과정에서 이쒑 팀장님이 핵심을 찌르는 매우 객관적인 피드백을 주었다. 역시 인사이트가 있다. 고마워 나의 동반자 아래 핵심 5가지만 고쳐도 많이 좋아질거란 희망적 메세지와 함께.

앞으로 일을 해나가는데 나에게 있어 말하기란 항상 따라다닐수 밖에 없는 존재다. 피해다닐 것인가, 관성에 젖어 인지못하고 매번 그저그렇게 지나갈 것인가, 변화를 주고 노력을 통해 극복하고 개선해나갈 것인가.

앞으로는 좀더 개선해나가야지~라고 생각은 하지만 성향상 내일이 되고 모레가 되면 또다시 잊게될 것이다. 이를 조금이라도 더 극복해보고자 오늘 이렇게 포스팅을 통해 글을 남긴다.

1. 급하다. 머리속에서 하는 생각들을 말이 따라가질 못한다. 두서가 없이 정리가 안된 단어들이 질서없이 던져진다. 무조건 말하기 속도를 기존의 0.5배속으로 말한다.
2. 상대방의 말을 끊는다. 말이 끝나지 않았음에도 가로채고 정리되지 않은 말을 내뱉는다. 최악이다. 시급한 개선이 필요하다. 상대방의 말이 끝나고 최소 1초의 쉼을 갖고난 다음이 내 차례다.
3. 확실하지 않으면 승부를 걸지마라. 정확히 기억나지 않거나 의사결정하지못한 사항에 대해 왈가왈부하지 않는다. 상대방은 혼란스러울뿐이다. 해당 사항은 제가 미팅끝나고 체크한 후 정리해서 말씀드리겠습니다. 얼마나 깔끔한가.
4. 대화를 하다보면 언제나 생각하고, 고민해봐야할때가 있다. 혹은 기억을 떠올리기위해 노력해야하는 순간들. 그럴때 천정을 보며 눈을 희번덕거리지 않는다. 차라리 위가 아닌 아래쪽을 바라봐라.
5. 대화에서 IF문을 사용하지 않는다. 특히 끝맺음이 없는 ~하니까 체는 적극 지양한다. 정리된 ~다 체가 필요하다. 정보를 전달할때는 사실은 ~입니다. 한문장으로 말한다. 그리곤 요청사항만 말한다.

부끄럽지만 장기기억을 강화하고 확실한 개선을 위해 잘못 얘기한 예시들도 함께 기록한다. 아마 조만간 삭제할거 같다 이제 슬렉을 켠다.

[항상 0.5배속으로 말한다고 생각하고 말하기]
제발 여유를 가지고 천천히하자

[확실한 정보만 말하기]
문자 원가 등 확실치 않은 정보는 말하지 않는다.
아 제가 다시 확인해보고 말씀드리겠습니다. >> 문자가 몇십원인데 다해드리겠씁니다!

[~하니까 조건문 말투 금지]
저희가 요금이 사용량 베이스로 채정됩니다. 그래서 월 몇건 발송하시는지 알 수 있을까요? >> ~사용량 베이스로 책정되니까, 얼마 쓰는지 알아야되요
~주시면 하겠습니다 >> ~이니까, 제가 ~해서 드려야하니까

Windows

Windows 10 버전 1803 이후부터는 OpenSSH가 기본으로 포함되어 있습니다. 활성화하려면:

1. 설정 > 앱 > 앱 및 기능 > 선택적 기능 관리로 이동
2. "OpenSSH 클라이언트" 설치

Ubuntu/Debian

대부분 기본 설치되어 있지만, 없다면:

sudo apt update
sudo apt install openssh-client openssh-server

macOS

SSH 클라이언트가 기본으로 설치되어 있습니다.

2. SSH 키 생성

모든 플랫폼에서 다음 명령어로 키를 생성할 수 있습니다:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/myserver_key

• t rsa: RSA 암호화 사용
• b 4096: 4096비트 키 길이 (강력한 보안)
• f ~/.ssh/myserver_key: 키 파일 저장 위치 및 이름

비밀문구(passphrase) 설정은 선택사항입니다.

3. 공개키를 서버에 복사

Linux/macOS 사용자

ssh-copy-id 명령어 사용:

ssh-copy-id -i ~/.ssh/myserver_key.pub user@server_ip -p port_number

Windows 사용자

Windows에는 ssh-copy-id가 없으므로 수동으로 복사해야 합니다:

1. 복사한 공개키 내용을 붙여넣고 저장 (Ctrl+X, Y, Enter)

권한 설정:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

서버에서 authorized_keys 파일 편집:

mkdir -p ~/.ssh
nano ~/.ssh/authorized_keys

서버에 SSH 접속:

ssh -p port_number user@server_ip

공개키 내용 확인:

type %USERPROFILE%\\.ssh\\myserver_key.pub

4. SSH 접속 테스트

ssh -i ~/.ssh/myserver_key -p port_number user@server_ip

Windows에서는 전체 경로를 사용해야 할 수 있습니다:

ssh -i C:\\Users\\YourUsername\\.ssh\\myserver_key -p port_number user@server_ip

5. 추가 설정 및 팁

SSH 설정 파일 사용

~/.ssh/config 파일을 생성하고 다음과 같이 설정:

Host myserver
    HostName server_ip
    User username
    Port port_number
    IdentityFile ~/.ssh/myserver_key

이제 ssh myserver로 간단히 접속 가능합니다.

서버 측 보안 강화

서버의 /etc/ssh/sshd_config 파일에서:

PasswordAuthentication no
PermitRootLogin no

변경 후 SSH 서비스 재시작:

sudo systemctl restart sshd

키 관리 팁

• 여러 서버에 대해 다른 키 사용
• 정기적으로 키 교체
• 키 암호(passphrase) 사용 고려

이 가이드를 따라하면 비밀번호 없이 안전하게 SSH 키 인증으로 서버에 접속할 수 있습니다. 보안과 편의성을 모두 높일 수 있는 훌륭한 방법입니다.

보안옵션

SSH 서버의 보안을 강화하는 중요한 옵션들입니다. 각각의 기능과 fail2ban에 대해 자세히 설명해 드리겠습니다.

1. PasswordAuthentication no
   • 기능: 비밀번호를 사용한 SSH 로그인을 비활성화합니다.
   • 효과: 무차별 대입 공격(brute-force attack)을 방지합니다. 오직 SSH 키를 통한 인증만 허용됩니다.
2. PermitRootLogin no
   • 기능: root 계정으로의 직접적인 SSH 로그인을 금지합니다.
   • 효과: 시스템의 가장 강력한 계정인 root에 대한 무단 접근을 방지합니다. 대신 일반 사용자로 로그인 후 필요 시 sudo를 사용하여 root 권한을 얻도록 합니다.
3. PubkeyAuthentication yes
   • 기능: 공개키 인증 방식을 활성화합니다.
   • 효과: SSH 키 쌍을 사용한 인증을 허용합니다. 이는 비밀번호 인증보다 더 안전한 방법입니다.
4. fail2ban
   • 기능: 지속적인 로그인 실패 시도를 모니터링하고 차단하는 도구입니다.
   • 설치: sudo apt install fail2ban
   • 효과:
     • 특정 IP 주소에서 반복적으로 로그인 실패가 발생하면 해당 IP를 일정 시간 동안 차단합니다.
     • SSH뿐만 아니라 다양한 서비스(예: 웹 서버)에 대한 공격을 방어할 수 있습니다.
     • 무차별 대입 공격을 효과적으로 막을 수 있습니다.

이러한 설정들을 조합하면 SSH 서버의 보안을 크게 향상시킬 수 있습니다:

1. PubkeyAuthentication yes와 PasswordAuthentication no를 함께 사용하면, 오직 SSH 키를 통한 인증만 허용되어 보안이 강화됩니다.
2. PermitRootLogin no를 설정하여 root 계정의 직접적인 접근을 차단합니다.
3. fail2ban을 추가로 설치하여 자동화된 공격 시도를 탐지하고 차단합니다.

이러한 설정을 적용한 후에는 반드시 SSH 서비스를 재시작해야 합니다:

bashCopysudo systemctl restart sshd

주의: 이러한 설정을 적용하기 전에 반드시 SSH 키 인증이 제대로 작동하는지 확인하세요. 그렇지 않으면 서버에 접근할 수 없게 될 수 있습니다.

1. sudo apt install fail2ban
   • 설치만으로는 기본 설정으로 동작하지만, 완전한 커스터마이징을 위해서는 추가 설정이 필요합니다.
   • 기본 설정으로도 SSH에 대한 기본적인 보호가 적용됩니다.
2. SSH 옵션 설정 방법: 이 옵션들은 SSH 서버 설정 파일에서 변경합니다.

설정 후 서비스 시작:

sudo systemctl start fail2ban
sudo systemctl enable fail2ban

추가 설정 방법:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

이 파일에서 해당 옵션들을 찾아 수정하거나 추가합니다:

변경 후 SSH 서비스 재시작:

sudo nano /etc/ssh/sshd_config

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no

sudo systemctl restart sshd

3. PubkeyAuthentication yes
   • 대부분의 현대 SSH 서버 설정에서는 기본적으로 활성화되어 있습니다.
   • 하지만 명시적으로 설정하는 것이 좋은 습관입니다:
     • 설정의 명확성을 위해
     • 향후 업데이트나 변경에 대비하여
     • 일부 오래된 시스템이나 특수한 설정에서는 기본값이 다를 수 있기 때문

주의사항:

• 이러한 변경을 적용하기 전에 반드시 SSH 키 인증이 제대로 작동하는지 확인하세요.
• PasswordAuthentication no를 설정하면 키 인증만 가능하게 되므로, 키 설정이 완료된 후에 적용하세요.
• 변경 사항을 적용한 후에는 새로운 SSH 세션에서 로그인이 가능한지 반드시 테스트하세요.

이러한 설정들을 통해 SSH 서버의 보안을 크게 향상시킬 수 있습니다. fail2ban은 추가적인 보안 계층을 제공하며, SSH 설정은 기본적인 접근 방식을 제어합니다.