AI가 비서를 넘어 대리인이 되는 시대

OpenClaw란 무엇인가?

'챗봇'과 '에이전트'의 결정적 차이

우리가 그동안 사용해온 ChatGPT나 Claude는 엄밀히 말하면 '챗봇'입니다. 여러분이 질문을 던지면 답을 해주는 일종의 '백과사전'이나 '상담원'에 가깝습니다. 하지만 OpenClaw는 'AI 에이전트(Agent)' 라고 불립니다.

• 챗봇: "이 이메일 답장 좀 써줘" $\to$ 답장 초안을 써서 화면에 보여줌 (실제 전송은 사람이 해야 함)
• OpenClaw(에이전트): "이 이메일에 답장 보내줘" $\to$ 실제로 이메일 앱을 열고, 내용을 입력한 뒤 전송 버튼까지 누름

즉, OpenClaw는 단순히 말만 하는 존재가 아니라, 여러분의 컴퓨터에서 직접 마우스와 키보드를 움직여 실제로 일을 끝마치는 '디지털 직원' 입니다.

왜 지금 OpenClaw인가?

2026년 초, OpenClaw가 깃허브(GitHub)에서 스타 15만 개를 돌파하며 전 세계적인 신드롬을 일으킨 이유는 단순합니다. "진짜로 작동하기 때문" 입니다. 이전에도 비슷한 시도는 많았지만, 너무 느리거나 실수가 잦았습니다. OpenClaw는 마치 숙련된 비서처럼 빠르고 정확하게 업무를 처리하며, 우리가 '귀찮아하던 일'들을 대신해주기 시작했습니다.

세번의 개명과 탄생 비화

OpenClaw의 창시자 '피터 스타인버거'는 원래 PDF 기술로 수천억 원의 기업 가치를 일궈낸 성공한 사업가였습니다. 그는 은퇴 후 한가로운 삶을 즐기려 했으나, 2025년 AI 기술이 폭발적으로 발전하는 것을 보고 다시 키보드를 잡았습니다.

이 프로젝트는 처음에 'Clawdbot'으로 시작했습니다. 앤스로픽(Anthropic)의 AI 모델 '클로드(Claude)'의 이름을 딴 장난스러운 명칭이었죠. 하지만 상표권 이슈로 인해 잠시 'Moltbot'이라는 이름을 거쳤습니다. Molt는 게나 가재가 허물을 벗고 더 크게 성장하듯, AI가 스스로 학습하고 진화하며 껍질을 깨고 나온다는 철학적 의미를 담고 있습니다.

결국 이 프로젝트는 누구나 자유롭게 사용할 수 있다는 의미의 'Open'과 실행력을 상징하는 'Claw(집게발)'를 합쳐 현재의 OpenClaw로 확정되었습니다.

OpenClaw의 3대 핵심 철학

"나의 데이터는 밖으로 나가지 않는다" (Local-first)

대부분의 AI는 우리가 입력한 모든 정보를 서버로 보냅니다. 기업 비밀이나 사생활이 유출될까봐 걱정되는 부분이죠. 하지만 OpenClaw는 '로컬 우선' 방식으로 작동합니다.

• 모든 중요한 작업 기록과 파일은 여러분의 PC나 개인 서버에만 저장됩니다.
• AI 모델(두뇌)만 외부와 연결될 뿐, 여러분의 개인적인 문서는 철저히 여러분의 공간 안에 머뭅니다. 이는 보안을 중시하는 기업들이 OpenClaw에 열광하는 결정적 이유입니다.

"한 번에 하나씩, 완벽하게" (Lane Queue)

사람도 한꺼번에 너무 많은 지시를 받으면 실수를 하듯, AI도 여러 작업을 동시에 하면 엉뚱한 결과를 낼 때가 있습니다. OpenClaw는 이를 해결하기 위해 'Lane' 시스템을 도입했습니다. 마치 고속도로의 전용 차선처럼, 한 명의 사용자가 시킨 일은 순서대로 하나씩 확실하게 처리하여 시스템이 꼬이지 않도록 합니다.

"보는 것이 아니라 이해한다" (Semantic Snapshots)

OpenClaw가 인터넷 쇼핑몰에서 물건을 대신 산다고 가정해 봅시다. 기존 AI는 화면을 사진 찍듯 캡처해서 분석했습니다. 그래서 버튼 위치가 1cm만 바뀌어도 당황했죠.

OpenClaw는 화면의 '디자인'이 아니라 '구조와 의미'를 읽습니다. "이 버튼은 결제 버튼이구나"라고 의미 자체를 파악하기 때문에, 웹사이트가 개편되어도 길을 잃지 않습니다.

무엇을 할 수 있나요?: 실생활 활용 사례

OpenClaw를 처음 접하는 분들이 가장 많이 묻는 질문입니다. "그래서 이걸로 뭘 할 수 있죠?"

1. 스마트 비서 업무: "내 이메일 훑어보고, 이번 주 회의 일정들 캘린더에 다 정리해 놔. 겹치는 시간 있으면 상대방한테 사과 메일 보내고 시간 조정해."
2. 데이터 수집 및 정리: "경쟁사 5곳의 신제품 가격을 조사해서 엑셀로 표 만들어줘. 지난번 조사랑 비교해서 가격이 오른 곳은 빨간색으로 표시해."
3. 복잡한 예약 대행: "내일 저녁 7시 강남역 근처 이탈리안 레스토랑 4명 예약해줘. 만약 예약 꽉 찼으면 비슷한 급의 다른 곳으로 알아보고 나한테 물어봐."

"먼저 말을 거는 AI"

기존의 AI들은 우리가 질문을 하기 전까지는 죽은 듯이 가만히 있었습니다. 하지만 OpenClaw는 다릅니다. 가끔 "아까 지시하신 작업 결과가 나왔는데 확인해보실래요?"라며 먼저 말을 걸기도 하죠. 이게 어떻게 가능할까요?

AI의 심장 박동, 하트비트

OpenClaw 내부에는 'Heartbeat'라는 기능이 있습니다. 말 그대로 일정한 간격으로 심장이 뛰듯 AI가 스스로를 깨우는 것입니다.

• 체크리스트 확인: 자다가 깬 AI는 "내가 지금 놓친 작업이 있나?", "사용자가 기다리는 결과가 있나?"를 확인합니다.
• 능동적인 보고: 만약 작업이 끝났거나 중요한 변화가 생겼다면, 사용자가 물어보기 전에 먼저 알림을 보냅니다.

이 기술 덕분에 OpenClaw는 단순한 '도구'가 아니라, 항상 곁에서 상황을 살피는 '진짜 비서' 같은 느낌을 줍니다.

AI의 건망증을 치료하다

많은 분이 AI와 대화하다 보면 답답해한 적이 있을 겁니다. AI는 기본적으로 대화가 길어지면 앞 내용을 잊어버리는 '건망증'이 있기 때문입니다. OpenClaw는 이 문제를 두 개의 기억 저장소로 해결했습니다.

• 블랙박스 (모든 기록): 비행기의 블랙박스처럼 AI가 했던 모든 행동과 대화를 하나도 빠짐없이 기록합니다. 나중에 문제가 생겼을 때 "너 그때 왜 그랬어?"라고 추궁하면 이 기록을 뒤져봅니다.
• 요약 노트 (핵심 기억): 하지만 모든 기록을 다 읽으면 시간이 너무 오래 걸리죠. 그래서 OpenClaw는 중요한 정보(예: 사용자의 취향, 프로젝트 마감일 등)만 골라 MEMORY.md라는 파일에 깔끔하게 정리해 둡니다.

AI는 일을 시작하기 전 항상 이 '요약 노트'를 먼저 읽습니다. 덕분에 토큰(비용)은 아끼면서도, 사용자의 중요한 요청사항은 절대 잊어버리지 않는 똑똑한 기억력을 갖게 되었습니다.

AI에게 새로운 기술을 가르치기

OpenClaw가 처음 설치되었을 때는 기본적인 일만 할 줄 압니다. 하지만 여러분이 원한다면 얼마든지 새로운 기술을 가르칠 수 있습니다. 이를 'Skills(스킬)'이라고 부릅니다.

스마트폰 앱 같은 확장성

우리가 스마트폰에 앱을 깔아 기능을 늘리듯, OpenClaw에도 '기술'을 추가할 수 있습니다. 예를 들어서 "포토샵으로 이미지 보정하기", "사내 인사 시스템에서 휴가 신청하기" 등의 기술을 추가할 수 있습니다. 예전에는 개발자가 일일이 코드를 짜야 했지만, 이제 OpenClaw는 설명서(API 문서)만 읽어주면 스스로 그 기술을 습득합니다. "아, 이렇게 하면 휴가 신청을 할 수 있구나!" 라고 스스로 배우는 것이죠.

AI들의 SNS, '몰트북(Moltbook)'

OpenClaw의 가장 놀라운 점은 혼자 일하지 않는다는 것입니다. 전 세계의 OpenClaw 에이전트들이 서로 정보를 공유하는 거대한 네트워크, '몰트북(Moltbook)'이 있기 때문입니다.

여러분의 OpenClaw가 아주 어려운 문제에 봉착했다고 가정해 봅시다.

1. 검색: OpenClaw는 몰트북에 접속해 "이런 문제를 해결해본 다른 에이전트 있어?"라고 물어봅니다.
2. 학습: 다른 에이전트가 올려둔 성공 사례(작업 로그)를 다운로드하여 순식간에 공부합니다.
3. 해결: 사용자의 개입 없이도 새로운 지식을 얻어 업무를 완수합니다.

이것은 AI들이 서로 노하우를 공유하는 페이스북과 같습니다. 전 세계 에이전트들의 지혜가 모이면서, OpenClaw는 시간이 갈수록 기하급수적으로 똑똑해지고 있습니다.

여러 대의 AI가 팀을 이루다: 멀티 에이전트

이제 업무는 한 대의 AI가 아니라 'AI 팀'이 처리합니다. OpenClaw 안에서 여러 명의 가상 직원이 협업하는 모습을 상상해 보세요.

• 매니저 AI: 전체 계획을 세우고 업무를 분담합니다.
• 실무자 AI: 실제로 코드를 짜거나 문서를 작성합니다.
• 검수자 AI: 실무자가 한 일에 실수가 없는지 꼼꼼히 체크합니다.

이들은 서로 대화하며 정보를 주고받습니다. 여러분은 그저 최종 결과물만 승인하면 됩니다. 이것이 바로 OpenClaw가 꿈꾸는 '1인 기업'의 미래입니다.

내 컴퓨터를 지키는 울타리

OpenClaw는 매우 강력합니다. 여러분의 컴퓨터에서 명령어를 직접 실행할 수 있기 때문이죠. 하지만 이는 마치 "칼을 쥔 요리사"와 같습니다. 맛있는 요리를 할 수도 있지만, 실수로 손을 다칠 수도 있죠. 그래서 필요한 것이 바로 '샌드박스'입니다.

샌드박스는 말 그대로 '모래 놀이터'라는 뜻입니다. 아이들이 모래판 안에서 아무리 모래를 뿌리고 성을 허물어도 놀이터 밖의 화단은 망가지지 않는 것과 같은 원리입니다.

• 격리 환경: OpenClaw가 작업하는 공간을 실제 내 중요한 파일들이 있는 곳과 분리합니다.
• 피해 최소화: 만약 AI가 실수로 "모든 파일 삭제"라는 명령을 내려도, 샌드박스라는 가상의 상자 안에서만 파일이 삭제될 뿐, 실제 여러분의 소중한 사진이나 업무 문서는 안전하게 보호됩니다.

설치의 기술: "어떤 바구니에 담을 것인가?"

OpenClaw를 설치할 때 가장 고민되는 지점입니다. 전문가들은 보통 '도커(Docker)'라는 방식을 강력하게 권장합니다.

구분	직접 설치 (Native)	컨테이너 설치 (Docker)
비유	내 거실 바닥에서 요리하기	주방 보조 칸(별도 공간)**에서 요리하기
보안성	낮음 (거실 전체가 지저분해질 수 있음)	높음 (주방 칸만 치우면 끝)
편의성	복잡함 (설치할 게 많음)	간편함 (상자 통째로 가져오면 끝)
추천 대상	개발자	일반 사용자 및 기업

'에이전트 경제(Agent Economy)'의 서막

OpenClaw가 불러온 변화는 단순히 "일이 편해졌다"에서 끝나지 않습니다. 우리가 돈을 벌고 쓰는 방식 자체가 바뀌는 '에이전트 경제'로 진입하고 있습니다.

사람이 쇼핑하지 않는 시대 (A2A 거래)

지금은 우리가 쿠팡이나 아마존에 들어가서 최저가를 검색하고 결제 버튼을 누릅니다. 하지만 이 양상이 달라집니다.

1. 나의 에이전트: "사용자님, 냉장고에 우유가 떨어졌어요. 평소 드시던 저지방 우유 중 가장 신선하고 싼 걸로 주문할게요."
2. 마트의 에이전트: "우리 마트 지금 타임 세일 중이야! 우리한테 사면 쿠폰 줄게."
3. 협상과 결제: 에이전트들끼리 0.1초 만에 협상을 끝내고 결제까지 완료합니다. 우리는 그저 도착한 우유를 마시기만 하면 됩니다.

'노동'의 정의가 바뀝니다

이제는 "얼마나 성실히 엑셀을 채우는가"는 중요하지 않습니다.

• 과거: 기술을 배우고 직접 실행하는 사람
• 미래: AI 에이전트에게 정확한 의도(Intention)를 전달하고, 결과물을 승인하는 사람

지금 당장 시작해야 할 3가지 액션 플랜

이 글을 읽고 "와, 신기하다"에서 멈추면 기회를 놓치게 됩니다. 지금 바로 다음 세 단계를 실천해 보세요.

1. AI 거버넌스 이해하기: 무턱대고 AI에게 모든 권한을 주지 마세요. "어디까지 허용할 것인가"에 대한 나만의 기준을 세워야 합니다.
2. 데이터를 깨끗하게 정리하기: AI는 여러분이 가진 데이터를 먹고 자랍니다. 폴더 이름 하나, 문서 제목 하나를 깔끔하게 정리해 두는 것만으로도 OpenClaw의 성능은 2배 이상 올라갑니다.
3. 작은 일부터 맡겨보기: 오늘 당장 "내일 날씨 확인해서 복장 추천해줘" 같은 아주 작은 일부터 OpenClaw에게 시켜보세요. 에이전트와 대화하는 법을 익히는 것이 미래의 가장 큰 경쟁력이 됩니다.

당신의 새로운 파트너를 환영하세요

OpenClaw는 우리의 일자리를 뺏으러 온 괴물이 아닙니다. 오히려 우리를 단순 반복 노동이라는 감옥에서 해방시켜줄 가장 유능한 파트너입니다.

처음에는 낯설고 어려울 수 있습니다. 하지만 이 '집게발(Claw)'을 잡는 순간, 여러분은 혼자가 아니라 든든한 AI 팀을 거느린 Owner가 될 것입니다. 2026년, OpenClaw와 함께 새로운 비즈니스의 지평을 열어보세요.

설치 Tip

설치 환경

• Windows 11
• WSL - Ubuntu 24.04 준비
• systemd 활성화 (/etc/wsl.conf 파일내에 systemd=true 인지 확인)

Ubuntu 실행 후, 아래의 단계를 수행합니다.

Nodejs 설치
$curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
$source ~/.bashrc
$nvm install 22
$node -v #22.x.x 버전 확인

pnpm 설치
$corepack enable
$corepack prepare pnpm@latest --activate

Openclaw 설치
$npm install -g openclaw@latest

설치 후 아래의 명령어로 온보딩 진행하면 됩니다.
$openclaw onboard --install-daemon

Read More

통합의 두 얼굴, 합치는 것과 연결하는 것의 차이

시스템의 효율성을 고민하는 리더들에게 "통합"은 매력적인 단어입니다. 비슷한 기능을 하는 것 같은 시스템을 합치면 개발비와 운영비도 줄일 수 있지 않을까?라는 생각은 지극히 합리적인 경영적 판단입니다.

그러나 소프트웨어 아키텍처 세상에서는 조금 더 고민을 해봐야 합니다.

물리적 통합의 함정: 왜 비용 절감이 비용 폭증이 되는가?

겉보기에는 비슷해 보이는 두 시스템을 하나의 모놀리스(Monolith)로 합칠 때 발생하는 리스크가 있습니다.

1.복잡도 증가

비즈니스 부서가 다르면 비즈니스 규칙이 미묘하게 다릅니다.

• A 사업부: "우리는 결제 시 포인트 적립이 필수입니다."
• B 사업부: "우리는 포인트 대신 즉시 할인을 적용합니다."

이런 상황에서 통합을 하면 하나로 합쳐진 시스템 내부에는 아래와 같은 분기 로직이 코드 곳곳에 침투합니다.

if(businessUnit == 'A') {
 ...
} else {
 ...
}

시간이 흐를수록 코드는 읽기 어려워지고, 작은 수정 하나에도 다른 사업부 기능이 망가질까봐 아무도 건드리지 못하는 "레거시 유물"이 됩니다.

2.장애 전파의 확대

시스템을 통합한다는 것은 "운명 공동체"가 된다는 의미입니다. A 사업부의 이벤트로 인해 트래픽이 몰려 시스템이 다운되면, 아무 상관 없는 B 사업부의 비즈니스까지 마비됩니다. 이는 리스크 관점에서 매우 치명적입니다.

3.변화의 병목

A 사업부는 내일 당장 새로운 기능을 출시하고 싶은데, 시스템을 공유하는 B 사업부의 테스트가 끝날 때까지 배포를 기다려야 합니다. 비용을 아끼려다 시장 대응 속도를 잃는 상황이 발생합니다.

합치지 말고 연결하라

20년전 개념인 EIP(Enterprise Integration Pattern)이 제시하는 해답은 "느슨한 결합(Loose Coupling)"을 통한 유기적 연결입니다. 각 사업부의 자율성을 존중하되, 공통의 인터페이스를 통해 소통하게 하는 것이 진정한 의미의 통합니다. 요즘 시대의 EIP의 구현체는 Cloud + MSA지요.

왼쪽 그림은 물리적으로 통합된 형태이고, 오른쪽 그림은 느슨하게 결합된 형태입니다.

연결(Connection)이 가져다주는 이점:

1. 독립적 진화: 각 사업부는 자신의 비즈니스 로직을 자유롭게 수정할 수 있습니다.
2. 장애 격리: 한 시스템에 문제가 생겨도 전체 서비스가 중단되지 않습니다.
3. 데이터 정합성: 서로 다른 데이터 모델을 가진 시스템이라도 "메시지 변환"을 통해 깔끔하게 정보를 주고 받을 수 있습니다.

"통합" 관점을 고려할 땐, 상황에 맞춰서 판단하면 됩니다. 물리적 통합만 존재하는 건 아니니까요.

비용 절감의 새로운 패러다임

개발비와 운영비 절감은 매우 중요한 목표입니다. 하지만 진정한 비용 절감은 처음 만들때의 비용이 아니라, 운영하면서 들어가는 유지보수 비용에서 결정됩니다.

• 물리적 통합: 초기 구축비는 적어 보일 수 있으나, 향후 복잡도 증가로 인한 수정 비용과 장애 발생 시 손실 비용이 증가할 수 있습니다.
• EIP 기반 연결: 초기 설계 비용은 조금 더 들 수 있으나, 시스템이 안정적이고 각 사업부의 요구사항에 민첩하게 대응할 수 있어 장기적인 TCO 측면에서 유리합니다.

따로 또 같이

Dzone에 있는 글에서 언급하듯, EIP는 단순히 기술적인 도구가 아니라 시스템 간의 거리를 어떻게 유지할 것 인지가 철학입니다. (지금 구현체는 Cloud + MSA)

이름이 비슷하거나 하는 역할이 비슷해보인다고 해서 비즈니스 본질까지 같은 것은 아닙니다. 진정한 통합은 각 사업부의 개성을 살리면서도 데이터와 흐름을 표준화된 패턴으로 연결하는 것입니다.

이 글을 읽는 여러분들은 어떤 통합을 고민하시는지요?

참조 자료 및 문헌

• DZone: The Timeless Architecture: Enterprise Integration Patterns - 왜 EIP가 클라우드 시대에도 유효한지 설명
• Martin Fowler: MonolithFirst - 모놀리스의 장점과 한계, 그리고 분산 시스템으로의 전환 시점에 대한 통찰
• Hohpe & Woolf: Enterprise Integration Patterns - 65가지 패턴을 통해 연결의 기술적 방법론을 제시

Read More

온프레미스 DR과 클라우드 네이티브

 

대부분 기업이 온프레미스 환경에서 DR 없이 서비스를 운영해 왔던 이유는 명확합니다. "비용 효율성" 때문입니다. 인프라를 소유하고 최적화하여 사용하면, 겉보기에는 클라우드보다 저렴해 보입니다. 그러나 이는 "재해"라는 변수를 배제한 계산법입니다. 비즈니스가 성장하고 서비스 연속성이 필수 조건이 되는 순간, 온프레미스의 비용 구조는 거대한 장벽에 부딪힙니다.

왜 그럴까요?

온프레미스에서 DR을 구축하면 단순히 서버 대수만 두 배가 되는 것이 아닙니다. 그 이유는 아래와 같습니다.

• 상시 유휴 자산의 발생: DR 센터는 평상시에 거의 사용되지 않습니다. 그러나 주 센터와 동일한 사양의 서버, 스토리지, 네트워크 장비를 구매(CAPEX)해야 합니다. 99%의 시간 동안 놀고 있는 장비에 투자하는 꼴입니다.

• 운영 복잡도의 기하급수적 증가: 데이터 센터를 하나 더 관리한다는 것은 전기료, 냉각비, 상주 인력, 보안 관제 비용이 고스란히 추가됨을 의미합니다.

• 동기화의 늪: 두 센터 간 데이터 정합성을 맞추기 위한 고가의 전용 회선과 솔루션 비용은 "비용 효율성"이라는 단어를 무색하게 만듭니다.

클라우드쪽으로 생각해볼까요?

클라우드로 단순히 서버를 옮기는(Lift & Shift) 것이 아니라, "클라우드 네이티브" 아키텍처를 택했을 때 DR 비용은 혁신적으로 줄어듭니다. 그 이유는 아래와 같습니다.

첫째, "소유"에서 "대기"로: Pilot Light 전략

클라우드 네이티브 환경에서는 DR을 위해 모든 서버를 준비할 필요가 없습니다. 핵심 데이터만 실시간 복제하고, 서비스 자원은 "코드(IaC)" 형태로 있다가 재해 발생 시에만 수 분 내로 인프라를 프로비저닝하여 기동합니다.

둘째, 스케일링을 통한 유연성

온프레미스 DR은 최대 트래픽을 견딜 만큼의 장비를 미리 사야 합니다. 반면 클라우드 네이티브는 장애 시 최소 사양으로 복구를 시작한 뒤, 트래픽이 몰리면 서버를 늘릴 수 있습니다. "놀고 있는 장비"에 대한 비용 지불이 사라집니다.

셋째, 서버리스와 매니지드 서비스 활용

DB 복제나 메시지 큐 등을 CSP의 매니지드 서비스를 활용하면, 인프라 관리 부담을 CSP에게 넘기는 것입니다. 즉. 선택과 집중을 할 수 있습니다. 이는 인적 운영 비용을 낮출 수 있습니다.

DR이 없었을 때는 온프레미스의 비용이 저렴할 수 있지만, DR을 하는 순간 비용은 증가합니다. 운영 효율까지 본다면 더 많겠지요. 재해 복구를 고려해서 인프라를 선택할 때는 생각을 바꿔야 합니다.

"온프레미스가 클라우드보다 저렴한가?" 에서 "재해 복구가 가능한 수준의 인프라를 구축할 때, 어디가 더 경제적인가?"로 질문을 해야 합니다.

위 질문에 대한 답은 무엇일까요?

클라우드 네이티브는 단순한 기술적인 유행이 아니라, "가용성"과 "경제성"이라는 두 마리 토끼를 잡기 위한 현실적인 전략입니다.

참고로 비용 시뮬레이션을 해보았습니다.

#비용 시뮬레이션 설정

- 서비스 규모: 50대의 물리/가상 서버, 100TB 데이터 저장소

- 기간: 3년 TCO 기준

- DR 목표: RTO 4시간 이내, RPO 1시간 이내

#온프레미스 DR

온프레미스에서 DR을 구축하면 아래의 항목에서 비용이 발생합니다. (3년 합계)

항목	(A) 온프레미스 (현상태: No DR)	(B) 온프레미스 (DR 구축 1:1)	(C) 클라우드 네이티브
장비 구매(CAPEX)	약 5억원 (최초 1회)	10억원 (주+DR)	0 (구매 비용 없음)
각 센터 임차	3.6억 (월 1,000만)	7.2억 (월 2,000만)	0 (구독형 포함)
네트워크 전용선	0.4억 (월 100만)	2.2억 (회선 + 동기화 비용)	연 1억원 (데이터전송/Egress)
클라우드 서비스 이용료 (OPEX)	0원	0원	11억원 (Compute/Storage)
운영/유지보수 리소스	6억 (연 2억)	9억 (연 3억)	4억 (자동화로 효율화)
총 3년 TCO	15억	28.4억	16억

위 시나리오 (A)와 (B)를 비교하면 약 1.9배의 비용 상승이 발생합니다. 단순히 장비만 두 배가 되는 것이 아니라, 두 데이터 센터를 잇는 전용 회선과 이중화된 운영 인력 비용이 추가되기 때문입니다. (보안 비용은 포함하지 않았습니다.) 즉, 온프레미스에서 DR을 하면 비용은 거의 2배가 됩니다.

클라우드 네이티브 시나리오 (C)는 DR이 포함되어 있음에도 DR이 없는 온프레미스 단일 센터와 비용 차이가 크지 않습니다. 이유는 클라우드는 평상 시 DR용 서버를 켜두지 않는 Pilot Light 방식을 사용하기에, 실제 장애가 나기 전까지는 하드웨어 비용을 지불하지 않기 때문입니다. (DB 비용만 존재) Pilot Light는 데이터베이스는 실시간 복제하되, 애플리케이션 서버는 꺼두었다가 재해 시에만 즉시 생성하는 전략입니다.

이제까지 시장은 온프레미스가 더 비용 효율적이라는 의견이 지배적이었습니다. 그건 DR을 고려하지 않은 단일 센터 기준으로는 맞는 이야기입니다. 그러나 DR을 필수조건으로 넣는 순간 판도는 바뀝니다.

• CPEX의 소멸: 5억 원의 장비를 미리 사서 썩힐 필요가 없습니다. 그 자본을 다른 사업에 투자할 수 있는 기회 비용이 발생합니다.

• 규모의 경제와 유연성: 클라우드는 재해 시에만 서버를 빌려 씁니다. 온프레미스처럼 혹시 모를 상황에 대비해 미리 사두는 유휴 자원이 없습니다.

• 관리의 자동화: 온프레미스 DR은 두 장소의 OS 패치, 하드웨어 노후화를 각각 챙겨야 합니다. 클라우드 네이티브는 걱정이 없습니다.

또한, 요즘은 환율 그리고 반도체 가격이 상승하고 있는 시장상황에 처해 있습니다. 국내 기업이 사용하는 서버 장비 대부분은 외산이며 달러 결제가 기본입니다.

• 환율 리스크: 고환율 기조가 유지되는 상황에서 하드웨어 수입 비용은 기업의 예상치를 상회합니다. 온프레미스 DR은 모든 장비를 직접 구매해야 하므로 환율 변동에 무방비로 노출됩니다.

• 클라우드의 방어 기재: 클라우드 서비스 역시 달러 기반이지만, 예약 인스턴스 혹은 Savings Plans를 통해 할인도 받을 수 있고, CSP가 긴 기간으로 공급사와 계약을 하기에 반도체 상승에 따른 환경 변화가 크지 않습니다.

끝으로,

온프레미스 DR이 “장비를 하나 더 사는 것”이라면, 클라우드 네이티브는 “필요할 때만 인프라를 생성하는 것”입니다. 효율성을 고려한다면 아래를 참고해야 합니다.

• Pilot Light 아키텍처: 데이터베이스만 최소한으로 복제하고, 웹/앱 서버는 재해 시에만 코드를 실행하여 생성. 이 경우 DR 비용은 온프레미스보다 적은 수준으로 절감 가능

• CAPEX에서 OPEX로: 불확실한 경기 상황에서 DR을 위한 투자를 묶어두는 것은 리스크가 클 수 있음. 클라우드는 초기 투자비 없이 매달 사용량만큼 지출하기에 재무 유동성 확보에 유리 (단, 클라우드 네이티브가 되어 있어야 함)

• 운영 자동화: CSP의 매니지드 서비스(RDS, EKS 등)를 활용하면 하드웨어 관리 및 패치 비용을 절감할 수 있어, 운영 리소스를 낮출 수 있음

“온프레미스 단일 센터가 가장 저렴하다.”는 생각은 재해라는 리스크를 배제했을 때만, 유효합니다. 그러나 DR이 필수인 시대에 반도체 가격 상승과 고환율이라는 거센 파도를 온몸으로 맞으며 온프레미스 DR을 구축하는 것은 비합리적입니다.

클라우드 네이티브로의 전환은 단순히 기술을 바꾸는 것이 아닙니다. 인프라를 “고정 자산”에서 “유연한 비용”으로 전환하는 거시경제 리스크를 방어하는 최선의 재무 전략이라고 생각합니다.

Read More

아키텍트로 전향하고픈 엔지니어가 알아야 할 사항

이 글을 읽는 개발자 혹은 엔지니어분들은 해당 직무에서 꽤 오랫동안 일해 왔고, 개발 시 필요한 라이브러리 및 모듈에 대해서는 이미 잘 알고 계십니다. 개발 시 발생하는 버그도 디버깅을 통해 다 해결해봤지요. 담당하는 개발 모듈의 세계를 넘어서 더 큰 그림을 보려면 준비해야 할 것이 무엇인지 본 글에서 다룰려고 합니다.

마인드셋의 전환 - “어떻해”에서 “왜”와 “무엇”으로

가장 중요한 점은 관점의 변화입니다. 엔지니어는 주어진 문제를 해결하기 위해 “어떤 기술”을 사용하여 어떻게 구현할 것인가?에 집중합니다. 그러나 아키텍트는 아래의 질문에서 시작해야 합니다.

1. 비즈니스 목적(Why?): 이 시스템이 왜 필요하지? 비즈니스 목표를 달성하기 위해 가장 중요한 것은 무엇이지?
2. 트레이드 오프: 모든 기술적 결정에는 대가가 따릅니다. A라는 프레임워크를 선택했을 때 포기해야 하는 B는 무엇이지?
3. 지속 가능성: 이 구조가 시장 트렌드가 바뀌는 3년 뒤에도 유지가 가능할까?

현실에서는 요구사항을 해소하기에 바쁘긴합니다. 그럼에도 아키텍트가 되려면 “이 요구사항이 전체 시스템의 정합성을 해치지는 않는가?”에 대한 답변을 끊임없이 고민하는 습관을 가져야 합니다.

기술적 깊이와 넓이의 균형

아키텍트는 모든 것을 다 알아야 한다는 압박감을 가질 수 있습니다. 그러나 핵심은 “넓게 알되, 특정 분야에 대해서는 누구보다 깊은 통찰력을 가지는 것”입니다.

그러기 위해서는 첫째, 폭넓은 기술 스택을 탐색해야 합니다. 현 시장에서 많이 쓰고 있는 기술 스택에 대해서 이해해야 합니다. (e.g. Springboot/Java, Python, Nodejs 등)

둘째, 인프라에 대한 이해가 있어야 합니다. AWS, Azure, GCP와 같은 클라우드 환경 및 On-premise 환경에 대한 이해가 필수입니다.

셋째, 데이터 아키텍처를 이해해야 합니다. RDBMS를 넘어 NoSQL과 데이터 파이프라인에 대한 이해가 있어야 합니다.

추가로, 아키텍트는 코딩에 손을 떼면 안됩니다. 어떤 기능을 구현해야 하는 관점보다는 실제 구현의 어려움을 이해하기 위해 프로토타이핑이나 핵심 모듈 개발에 참여해야 하기 때문입니다. 기술적 깊이와 논리없이 입으로만 일하면 엔지니어분들께 신뢰를 얻지 못합니다.

아키텍처 결정

아키텍트의 가장 중요한 산출물은 코드가 아니라 “결정” 입니다.

왜 이 데이터베이스를 선택했는지, 왜 MSA(Microservices Architecture)를 선택했는지등을 기록으로 남겨야 합니다. 이렇게 해야 나중에 멤버가 변경되었을 때나 히스토리를 파악할 때 결정적인 자산이 됩니다.

이런 의사 결정을 할때는 감이나 트렌드에 의존하는 것이 아니라, 명확한 기준(비용, 성능, 개발 생산성, 인력 수급 등)을 바탕으로 결정해야 합니다.

실 업무를 하게 되었을 때, 현실적인 벽에 부딪히기도 합니다. 상급자의 지시나 고객의 무리한 요구가 있을 수 있지요. 그런 상황에서 기술적 근거를 바탕으로 논리적으로 설득 할 수 있는 강력한 무기가 됩니다.

기술과 비즈니스의 가교

아키텍트 역량의 50% 이상이 “소프트 스킬”입니다. 일반적인 엔지니어 분들이 가장 힘들어 하는 부분이기도 하죠. 그 이유는 아래와 같습니다.

• 시각화 능력: 복잡한 시스템을 이해관계자(기획자, 경영진, 엔지니어, 현업)가 이해할 수 있도록 그림으로 표현해야 합니다.
• 설득의 기술: 엔지니어에게는 기술적 비전을 제시하고, 경영진에게는 기술 투자가 가져올 비즈니스 가치(비용 절감, 장애 감소, 비즈니스 확장 등)를 설명해야 합니다.
• 중재자 역할: 프론트 엔드와 백엔드 간의 인터페이스 갈등, 개발팀과 인프라팀 간의 여러 갈등을 해결하는 능력이 필요합니다.

각 환경에 따른 전략

우리가 일하는 IT는 여러 분야로 나눠져 있습니다. 크게 SI, 스타트업/서비스, 레거시 현대화로 나눠보면 각 환경의 특수성을 고려한 전략이 필요합니다.

• SI: 고객사에서 제공하거나 사용하는 표준 프레임워크의 제약 안에서 어떻게 유연한 설계를 할 것인가가 관건입니다. 여기서는 “표준 준수”와 “성능 최적화” 사이의 균형이 필요합니다.
• 스타트업/서비스: 빠른 출시(Time-to-Market)가 우선입니다. 아키텍트는 처음부터 완벽한 설계를 하기보다는, 나중에 확장하기 쉬운 “점진적 아키텍처”로 설계해야 합니다.
• 레거시 현대화: 많은 기업들이 노후화된 시스템을 현대화하려고 합니다. 이때 점진적 전환 전략을 제시할 수 있어야 합니다.

자기계발과 네트워킹

아키텍트로의 전환은 단기간에 이뤄지지 않습니다. 고전과 신간의 기술 서적을 병행해서 읽으면서 공부를 해야 합니다. 또한 오픈 소스에 기여하거나 커뮤니티 활동을 하면서 최신 트렌드를 파악하고 연습을 해보는 것도 중요합니다. 제일 좋은 것은 주변에 시니어 아키텍트가 있다면 멘토로 삼아 그들의 의사결정 과정을 옆에서 지켜보는 것이 가장 빠릅니다.

끝으로,

아키텍트는 완벽한 정답을 내놓는 사람이 아닙니다. 변화하는 비즈니스 환경에 맞춰 시스템을 가장 적절한 방향으로 이끄는 “나침반” 같은 존재이기에 아래의 사항이 중요합니다.

• 더 큰 그림을 보는 것
• 기술과 비즈니스 간의 격차를 해소하는 것
• 제품이 고객의 요구 사항을 실제로 충족하는지 확인 하는 것

이는 기술, 의사소통, 발표, 멘토링이 필수적이라는 것을 의미합니다.

엔지니어에서 아키텍트로 성장하기 위해서는 기술적 탁월함을 기본으로 하되, 비즈니스를 이해하고 이해관계자와 소통하는 능력을 키워야 합니다. 아키텍트는 코드가 아닌 시스템 전체의 건강함을 책임지기에, 이런 시각을 지니고 있다면 이미 아키텍트의 길에 들어선 것입니다. 가장 중요한 것은 열린 마음과 끊임없이 배우고자 하는 호기심이니까요.

Read More

RAG의 환각에 대한 대응

현 거대 언어 모델(LLM)은 지난 몇 년간 급격한 성장을 이루었습니다. 단순히 AI 모델을 사용하는 것을 넘어, 자사의 방대한 내부 데이터를 LLM에 연동하여 실질적인 비즈니스 가치를 창출하고자 하는 요구에 직면해 있습니다. 이런 배경에는 RAG(Retrieval-Augmented-Generation)가 있습니다. RAG는 모델에 없는 최신 정보나 비공개 기업 데이터에 접근할 수 있도록, 데이터베이스에서 관련 내용을 검색하여 프롬프트에 주입하는 기술입니다. 이는 이론적으로 LLM의 가장 큰 약점이었던 환각(Hallucination) 현상을 완화하고, 지식의 최신성을 보장하는 완벽한 솔루션처럼 보였습니다.

Dzone에 언급된 https://dzone.com/articles/rag-illusion-grafting-memory-limitations 내용에 의하면 현재의 RAG 방식이 가진 근본적인 한계를 지적하며 이를 환상적 접목이라는 은유로 설명을 하고 있습니다. “접목”의 사전적 의미는 서로 다른 두 식물의 조직을 연결하여 하나의 개체처럼 자라게 하는 기술이지만, 접목된 두 식물은 기능적으로 공존할 뿐, 유전적으로나 구조적으로 완전히 융합된 것은 아닙니다.

현재의 RAG도 이와 유사합니다. 검색(Retriever)라는 “가지”를 생성 모델(Generator)라는 “나무”에 억지로 붙여놓은 형상입니다. 겉으로 보기에는 LLM이 기업 데이터를 완벽히 이해하고 답변하는 것처럼 보이지만, 실제로는 두 모듈이 서로의 작동 원리를 이해하지 못한 채 단절된 상태로 기능하고 있습니다. 검색 모듈은 생성 모델이 어떤 논리를 필요로 하는지 모른 채 키워드 유사성에만 의존해 결과를 던져주고, 생성 모델은 그 문서가 적절한지 판단할 수 있는 피드백 채널 없이 주어진 텍스트를 앵무새처럼 가공할 뿐입니다. 이런 구조적 분열은 복잡한 추론이 필요한 실 비즈니스 환경에서 심각한 오류와 비효율을 초래할 수 있습니다.

본 글은 RAG 아키텍처의 한계를 살펴보고, 그 대안을 살펴봅니다.

RAG 아키텍처의 구조적 결함

현재 RAG 시스템의 결함은 검색 모듈과 생성 모듈이 서로 다른 목적을 위해서 서로 다른 방식으로 최적화되었다는 점입니다. 이를 “분절된 최적화”라고 표현합니다.

• 검색: 검색은 주로 유사성을 기준으로 작동합니다. 사용자의 질문과 데이터베이스 내 데이터 간의 벡터 거리를 계산하여 가장 가까운 문서를 찾습니다. 이는 마치 도서관 사서가 책의 내용이 사용자에게 얼마나 도움이 되는지를 판단하는게 아니라, 사용자가 말한 단어가 포함된 책을 무조건 가져다주는 것과 같습니다.
• 생성: LLM은 인과성과 문맥을 기반으로 다음 단어를 예측하도록 훈련했습니다. LLM은 논리적인 답변을 구성하기 위해 특정 정보가 필요한데, 검색은 문맥적 필요성이 아닌 표면적 유사성만으로 정보를 제공합니다.

위 두 모듈 사이에는 피드백 루프가 존재하지 않습니다. 만약 검색 모듈이 엉뚱한 문서를 가져오더라도, 생성 모듈이 “이 문서는 답변을 만드는 데 쓸모가 없어, 다른 것을 찾아줘!”라고 요청 할 수 없습니다. 그저 주어진 엉뚱한 정보를 바탕으로 그럴듯한 환각을 만들어내거나, 답변을 거부할 뿐입니다. 이는 두 명의 전문가가 서로의 말을 듣지 못한 채 각자 떠드는 것과 같습니다.

RAG의 핵심 저장소인 백테 데이터베이스는 텍스트의 의미를 숫자의 나열 즉, 임베딩 벡터로 변환하여 저장합니다. 그러나 이 방식은 상관관계의 함정에 취약합니다.

검색 알고리즘은 질문과 키워드가 많이 겹치는 문서를 선호합니다. 그러나 복잡한 문제 해결을 위해서는 키워드가 겹치지 않아도 논리적으로 연결된 정보가 필요합니다. 예를 들어서, “프로젝트 A의 지연 원인”을 질문했을 때, 벡터 검색은 “프로젝트 A”, “지연”이라는 단어가 들어간 보고서를 찾습니다. 그러나 진짜 원인이 “공급망 파트너사의 파산”이라는 제목의 이메일이 있고 그 메일에 “프로젝트 A”라는 단어가 명시적으로 없다면., 벡터 검색은 이 결정적인 단서를 놓치게 됩니다. 이는 검색 모듈이 표면적 유사성에 매몰되어 인과적 정보를 무시하기 때문입니다.

더욱 심각한 기술적 문제는 벡터 임베딩이 인간의 언어 논리 중에 “부정”을 제대로 처리하지 못한다는 점입니다. 대부분의 임베딩 모델은 문맥상 함께 자주 등장하는 단어들을 가까운 벡터 공간에 배치합니다. 문제는 긍정과 부정이 대부분의 단어를 공유한다는 점입니다.

• 문장 A: “이 약은 부작용이 있다.”
• 문장 B: “이 약은 부작용이 없다.”

위 두 문장은 “이”, “약”, “부작용”이라는 핵심 단어를 공유하며, “있다”와 “없다”의 차이만 존재합니다. 벡터 공간에서 이 두 문장은 매우 가깝게 위치하게 됩니다. 따라서 사용자가 “부작용이 없는 약”을 질의 했을 때, RAG는 “부작용이 있다”는 문서들을 대거 검색해오는 오류를 범할 수 있습니다. 이는 단순한 검색 실패라기보다는 사용자의 의도와 정반대되는 정보를 제공할 수 있는 구조적 결함입니다.

문맥 창(Context Window)를 늘리면 해결될 문제라고 생각할 수 있습니다. 100만 토큰을 처리할 수 있는 모델들이 등장하면서, 모든 문서를 프롬프트에 넣으면 된다는 주장이 있을 수 있습니다. 그러나 문맥(Context)은 기억이 아닙니다.

문맥 창에 데이터를 집어넣는 것은 마치 시험 직전에 벼락치기로 내용을 보는 것과 같습니다. 모델은 그 내용을 학습하거나 구조화하여 장기 기억으로 전환하지 않습니다. 매번 질문할 때마다 큰 문서를 다시 읽어야 하기에 연산 비용이 증가하고, 무엇보다 정보의 양이 많아질수록 중간에 위치한 정보를 망각하는 소실 현상이 발생할 수 있습니다. 이는 단순히 양적인 확장이 질적인 추론 능력 향상으로 이어지지 않음을 시사합니다. (참고: https://medium.aiplanet.com/overcome-lost-in-middle-phenomenon-in-rag-using-longcontextretriver-2334dc022f0e, https://arxiv.org/abs/2307.03172)

대안

RAG의 한계를 극복할 대안으로 Apple과 에든버러 대학 연구진이 개발한 CLaRa(Continuous Latent Reasoning) 프레임워크를 제시합니다. CLaRA는 텍스트를 읽는 것이 아니라 의미를 다운로드 하는 방식으로의 패러다임 전환을 의미합니다. (참고: https://github.com/apple/ml-clara)

CLaRa는 데이터를 처리하는 방식이 다릅니다. 기존 RAG는 원본 텍스트를 그대로 잘라서 사용합니다. 반면 CLaRa는 SCP(Salient Compressor Pretraining)라는 과정을 통해 문서를 기억 토큰으로 압축합니다.

SCP의 작동 원리는 모방입니다. 우리가 책을 읽고 나면 책의 모든 문장을 토시 하나도 안틀리고 기억하는 것이 아니라, 핵심 내용과 논리 구조만을 뇌에 저장하지 않나요? SCP는 이 과정을 모방합니다.

또한, 긴 문서를 입력받았기에 불필요한 조사나 반복적인 표현 그리고 문법적 장식 등을 제거하고 오로지 “의미”와 “논리”만을 담은 고밀도 벡터로 압축합니다.

고밀도 벡터는 아래 두 가지 과제를 수행하며 훈련합니다.

• 질의 응답: 압축된 정보만으로 문서 내용에 대한 질문에 답할 수 있어야 한다.
• 의역: 문자의 형태가 바뀌더라도 의미는 동일하게 유지해야 한다.

위 과정을 통해 CLaRa는 기존 텍스트 기반 RAG 대비해서 많은 양의 데이터를 줄일 수 있고, 이는 LLM이 처리해야 할 데이터의 양이 줄어들기에 “중간 소실” 현상을 방지하는데 기여합니다.

CLaRa는 검색과 생성을 수학적으로 연결합니다. 앞에서 언급한 “분절” 문제를 해결하기 위해 CLaRa는 검색 과정을 미분 가능한 함수로 만듭니다.

기존 RAG는 검색 -> 분절 -> 생성의 형태로 답변을 했고, 이 플로우에서는 생성 모듈의 오류가 검색 모듈로 전달되지 않았습니다.

CLaRa는 검색 모듈과 생성 모듈이 하나의 연속적인 잠재 공간을 공유합니다. 생성 모듈의 답변이 틀리면, 그 오차를 계산하여 검색 모듈까지 전달합니다. 즉, 생성 모듈이 검색 모듈에게 “너가 전달한 이 압축 벡터는 답변을 만드는데 도움이 안돼. 다음에는 논리적으로 더 적합한 벡터를 전달해줘”라고 수학적인 신호를 보냅니다. 이렇게 피드백 루프가 형성되기에 검색 모듈은 단순한 단어 유사성보다, 답변 생성에 필요한 의미를 기준으로 데이터를 찾도록 피드백을 통해 진화합니다.

이것이 바로 “접목”을 넘어선 “융합”의 개념입니다. 검색과 생성은 더 이상 별개의 작업이 아니라, 하나의 거대한 추론 과정이 되는 것이지요.

비교

조금 더 이해를 돕기위해 세 가지 주요 접근 방식을 표로 비교해봅니다.

항목	기존 RAG (접목)	긴 문맥 (물량)	CLaRa (융합)
철학	검색해서 보여주자	전부 다 읽어보자	핵심만 기억하자
데이터 형태	원본 텍스트 조각	원본 문서 전체	압축된 기억 토큰
연결 방식	단절	검색 안함	미분 가능
한계	검색 정확도에 의존	중간 소실 현상 발생	압축으로 한계 극복
추론 비용	높음 (매번 재독해)	매우 높음 (토큰당 과금)	낮음 (압축 정보 처리)
학습 가능 여부	불가능 (검색 모듈 고정)	불가능 (Pre-training 고정)	가능 (피드백 학습)
예시	오픈북 시험	책 한권 외우기	개념 이해 후 시험

RAG가 실패하고 CLaRa가 성공하는 시나리오를 작성해봤습니다.

#시나리오: 기업 내부 감사

상황: 감사팀이 “2025년 프로젝트 지연의 근본 원인”을 찾고자 한다.

기존 RAG:

• 사용자 질문: “2025년 프로젝트 지연 원인 알려줘”
• 벡터 검색: “2025년”, “프로젝트”, “지연”이라는 단어가 포함된 주간 보고서를 찾는다. 보고서에는 “부품 수급 문제로 지연됨”이라고만 적혀 있다.
• 답변: “부품 수급 문제 때문입니다.” (표면적 원인)

CLaRa:

• 사용자 질문: “2025년 프로젝트 지연 원인 알려줘”
• CLaRa는 모든 이메일과 주간 보고서를 압축하여 “기억 토큰”으로 가지고 있습니다.
• 생성 모델은 “부품 수급 문제”라는 단서를 보고, 그 원인을 찾기 위해 관련된 잠재 벡터를 탐색합니다.
• 이 과정에서 “2025년”, “지연”이라는 단어는 없지만, “공급사 A 파산 선고”라는 제목의 이메일이 “부품 수급”과 인과적으로 연결되어 있음을 잠재 공간에서 파악합니다.
• 답변: “직접적인 원인은 부품 수급 문제이나, 근본적으로는 주요 공급사 A의 파산이 영향을 미친 것으로 보입니다.” (심층 추론)

결론

현재의 RAG는 과도기적 기술입니다. 검색 모듈을 통해 LLM에 접목하는 방식은 단순한 사실 검색에는 유용하지만, 고차원적인 문제 해결과 추론에는 한계가 드러납니다.

CLaRa와 같은 프레임워크는 이러한 한계를 극복하기 위해 압축과 통합을 제안합니다.

• 압축: 방대한 문서를 날것으로 읽지 않고, 핵심 의미로 압축하여 효율성을 높임
• 통합: 검색과 생성을 별개의 작업이 아닌, 미분 가능한 하나의 활동으로 연결

여기서 얻을 수 있는 시사점은 단순히 어떤 벡터 데이터베이스를 사용할까? 혹은 어떤 LLM을 붙일까?를 고민하는 단계를 벗어나야 한다는 것입니다.

첫째, 단순히 텍스트를 검색하는 것을 넘어, 데이터의 의미를 어떻게 추출하고 압축할 것인가(SCP)에 대한 고민이 필요합니다.

둘째, 검색 정확도만 따질 것이 아니라, 최종 답변의 완결성과 인과 관계 파악 능력도 평가해야 합니다.

셋째, CLaRa와 같은 기술이 어느정도 완성이 되기 전까지는, 벡터 검색의 한계를 보완하기 위해 키워드 검색을 병행하고, 지식 그래프 등을 활용하여 인과성을 보강하는 전략이 필요합니다.

우리는 지금 “책을 펴고 시험보는 RAG”에서 “내용을 이해하고 숙지한” 단계로 진화하는 변곡점에 서 있습니다. “접목”을 넘어 “융합”으로 나아가는 것, 이것이 핵심이지 않을까 합니다.

Read More

레거시 시스템 현대화를 위한 데이터 우선 전략과 기술적 실행 패턴

많은 기업이 레거시 시스템(Legacy System)을 현대화(Modernization)하려 할 때 가장 먼저 직면하는 벽은 분석이 어려운 코드입니다. 오랫동안 쌓인 스파게티 코드와 비즈니스 로직 그리고 파편화된 많은 줄의 코드들은 역공학(Reverse Engineering)을 어렵게 만듭니다.

대부분 현대화 프로젝트들은 코드를 먼저 분석하고 이를 이해하고 접근하는 방식을 취하지만, 이는 실패하거나 막대한 비용이 발생할 수 있습니다. 본 글은 레거시 시스템 현대화의 기술적 복잡성을 해결하려는 아키텍트와 개발 리더들을 위한 가이드라인을 담고 있습니다.

레거시의 진실은?

레거시 시스템은 사용되지 않는 코드와 비즈니스 로직처럼 보이지만 실제 다른 동작을 하는 코드 그리고 로직과는 무관한 주석이 존재할 수 있습니다. 그러나 데이터베이스(Database)에는 실제로 저장된 값이 담겨 있고 이는 비즈니스의 결과를 볼 수 있는 Fact입니다.

여기서 제가 언급하고자 하는 부분은 “데이터 출처 접근 방식” 입니다. 데이터 출처 접근 방식은 레거시 시스템의 DB 스키마를 데이터를 담는 그릇보다는 시스템 현대화를 위한 지도(Map)으로 바라봅니다. 코드를 읽어 내려가는 대신, 데이터베이스에 흐르는 데이터의 패턴, 제약 조건 그리고 In/Out을 분석하여 현대화할 대상과 범위를 정의합니다.

실행 전략

1단계로 데이터 모델링을 하여 현대화를 위한 영토 지도를 만들어야 합니다. 즉, 새로운 코드를 작성하기 전에 현 시스템의 논리적 모델을 분석해야 합니다. 아래의 작업들이 필요합니다.

• 물리 스키마의 논리화: 실 데이터베이스 테이블 간의 관계를 역공학하여 논리 모델을 구축
• 제약 조건 추출: 레거시 데이터베이스는 FK(Foreign Key)가 설정되지 않은 경우가 많습니다. 즉, 애플리케이션 로직 속에 숨겨진 데이터 간의 연관 관계를 찾아내서 명시해야 합니다.
• 불필요한 데이터 식별: UI이나 보고서에 나타나지 않는 컬럼과 테이블은 현대화 대상에서 과감하게 제외합니다.
• 미래 상태 모델링: 새로운 비즈니스 요구사항을 기반으로 마찰 지점을 파악합니다.

위 작업이 완료되면, 2단계로 데이터 프로파일링을 해야 합니다. 개발/인터페이스/UI 문서에는 특정 필드가 “필수”라고 명시되었지만, 실 데이터는 “옵션”일 수 있습니다. 시스템의 실제 사용 필드를 파악하기 위해 프로파일링을 수행해야 합니다.

1. 통계 분석: 각 열에 대해 null 비율, 카디널리티를 계산합니다.
2. 단일 항목 분석: DEFAULT 값 분포를 확인해야 합니다. 해당 열에 DEFAULT 값이 있는 경우가 99.9% 이상이면 이 데이터는 사용되지 않을 가능성이 높습니다.
3. 상관 분석: 종속성을 감지 해야 합니다. A열의 값에 종속되는 B열의 값을 봐야 합니다.
4. 문제 추출: 비즈니스에 의미가 없는 데이터를 지정해야 합니다.

3단계에서는 기존 시스템의 일관성 없는 명명 규칙이 없는 찾아봐야 합니다. 예를 들어서 고객 아이디를 cust_id, customer_id, c_id 등으로 지정했을 수 있습니다. 이런 것들을 조사해야 합니다.

1. 항목 추출: 기존 스키마에서 모든 열 이름을 추출합니다.
2. 단어 그룹화: 주소, 고객 등의 의미를 가지고 있는 이름들을 그룹화 합니다.
3. 사전 생성: 표준 용어를 정의합니다. (저는 개인적으로는 영어사전에 있는 full name을 선호합니다.)
4. 표준 정의: 모든 데이터 요소에 대한 표준을 정의합니다.
5. 코드 값 정의: 플래그 값들이 존재하면 표준화 합니다.
6. 매핑: 기존 열의 이름을 새 표준에 맞게 매핑합니다.
7. 통합: 매핑된 정보를 기준으로 새 표준에 맞게 변경합니다.

그 다음 4단계로 동기화 브릿지를 구축합니다. 레거시 시스템과 현대화 시스템이 공존하는 기간 동안 데이터 일관성을 유지해야 하기 때문입니다.

• CDC(Change Data Capture) 활용: 레거시 코드를 수정하지 않고도 데이터를 새 시스템으로 실시간 복제합니다.
• 이벤트 기반 아키텍처: 데이터 변경을 이벤트로 발행하여 새로운 서비스들이 이를 소비하게 하고 이를 통해 각 서비스간 결합도를 낮춥니다.

5단계로 점진적 전환을 해야 합니다. “빅뱅” 방식의 전환은 항상 위험이 도사리고 있습니다. 특정 데이터 영역(고객 정보, 주문 정보 등)을 먼저 분리하여 새 시스템으로 옮기고, 레거시 시스템의 해당 기능을 점진적으로 비활성화합니다.

핵심 기술 패턴

CDC (Change Data Capture)

레거시 코드는 손대기 매우 위험합니다. CDC는 데이터베이스 엔진의 트랜잭션 로그를 직접 읽어 들여 소스 코드 수정 없이도 데이터 흐름을 추적할 수 있게 합니다. 이는 레거시를 현대화된 “이벤트 소스”로 변환하는 방법입니다.

트랜잭셔널 아웃박스 패턴 (Transactional Outbox Pattern)

데이터 우선 접근 방식에서 데이터 일관성을 보장하기 위해 사용됩니다. 로컬 트랜잭션내에서 비즈니스 데이터 업데이트와 이벤트 메시지 저장을 수행함으로써, 시스템 장애 시에도 데이터 유실이나 중복 처리를 방지합니다.

부패 방지 계층 (Anti Corruption Layer)

레거시 데이터 모델이 현대화 시스템의 도메인 모델을 오염시키지 않도록 중간에서 변환 역할을 수행하는 계층입니다. 이를 통해 현대화 시스템은 레거시 데이터 구조에 종속되지 않고 현대적인 설계를 유지할 수 있습니다.

리스크 관리와 성공을 위한 Tip

현대화 프로젝트의 70%는 기술적 난이도보다 데이터 무결성 문제로 어려움을 겪습니다. “데이터 우선” 전략이 성공하기 위해서는 아래의 사항을 기억해야 합니다.

• 성능 저하 모니터링: CDC나 실시간 동기화가 레거시 데이터베이스의 성능에 미치는 영향을 철저히 테스트해야 합니다.
• 조직적 협업: 데이터베이스 관리자나 비즈니스 분석가 개발자가 초기 모델링 단계부터 긴밀히 협력해야 합니다.
• 완벽주의 포기: 모든 레거시 데이터를 가져갈 필요는 없습니다. 현재 비즈니스 가치가 있는 데이터에 집중해야 합니다.

끝으로, 현대화는 단순히 과거 기술 스택을 현대 기술 스택으로 넘어가는 것만이 아니라, 불필요한 것들을 정리할 수 있는 기회이기도 합니다. 코드부터 살펴보면 시스템 작동 방식의 복잡함에 기겁할 수 있습니다. 그러나 데이터부터 살펴보면 시스템이 실제로 무엇을 하는지 이해할 수 있습니다. 현대화 계획이 있다면 먼저 운영 데이터베이스를 프로파일링하세요.

Read More

데이터 엔지니어, 파이프라인이 아닌 제품을 설계하라

과거의 데이터 엔지니어링은 “전달”에 집중했습니다. 소스 시스템에서 데이터를 가져와서 정제하고, 데이터웨어하우스에 적재하는 것만으로도 역할을 다했다고 평가 받았습니다. 하지만 데이터의 양이 폭증하고 비즈니스의 요구사항이 복잡해진 오늘날에는 단순히 데이터를 옮겼다는 것만으로는 충분하지 않습니다.

대부분 기업이 데이터 플랫폼을 구축했지만, 현업에서는 쓸만한 데이터가 없다거나 데이터의 신뢰도가 낮다라는 이야기를 하기도 합니다. 왜 이런 상황이 발생할까요? 이는 데이터 엔지니어가 “주문받는 사람”의 역할에 머물기 때문입니다. 이제 데이터 엔지니어는 스스로를 제품을 만드는 사람으로 재정의해야 합니다.

그래서 Data as a Product라는 개념이 등장합니다. 기존의 데이터는 서비스나 제품에서 나온 부산물로 취급되었습니다. 그러나 데이터를 제품으로 바라보는 관점(Data as a Product)에서는 데이터를 고객에게 가치를 전달하기 위해 설계된 제품으로 정의합니다.

Source: https://www.analytics8.com/blog/building-effective-data-products-a-step-by-step-guide/

왜 이런 개념이 나왔을까요?

데이터 소스가 다양해지면서 파이프라인만으로는 관리 효율이 떨어지게 되었고, 데이터 생산자와 소비자 간의 소통 부재로 인한 소통이 저하되었고, 기술적 성취보다는 비즈니스 성과로 데이터의 존재 가치를 증명해야 하는 시대적 상황이기 때문입니다.

데이터 엔지니어가 제품 관리자처럼 생각한다는 것은 단순히 기획 업무를 한다는 것은 아닙니다. 관점의 변화가 필요합니다.

첫째, 사용자 중심 사고가 필요합니다. PO는 항상 “제품을 누가 사용하는가?” 에 대해서 질문합니다. 데이터 엔지니어도 마찬가지입니다. 그럼 어떤 사고를 해야 할까요?

• 페르소나 정의: 데이터 분석가, 데이터 사이언티스트, 비즈니스 의사 결정권자, 현업 등 각 사용자별로 데이터를 통해 해결하려는 문제가 무엇인지 파악해야 합니다.
• 사용자 여정 분석: 사용자가 데이터를 발견하고, 이해하고, 활용하여 인사이트를 얻기까지의 과정에서 겪는 Pain-points를 분석해야 합니다.

둘째, 결과 중심의 사고를 해야 합니다. Output과 Outcome을 명확하게 정의해야 합니다.

• Output: 10개의 파이프라인을 구축하고 100개의 테이블을 생성
• Outcome: 마케팅 캠페인 최적화로 인한 매출 15% 상승, 의사 결정 속도 2배 향상 등 기술적 구현(Output)에 매몰되지 않고, 비즈니스에 어떤 영향을 주는지 집중

셋째, 로드맵과 우선순위를 설정해야 합니다.

모든 데이터를 다룰 수는 없습니다. PO처럼 비즈니스 임팩트와 구현 난이도를 고려하여 제품 백로그를 관리해야 합니다.

그럼 실무에는 어떻게 적용을 해야 할까요? 재밌는 점은 데이터 제품도 일반적인 소프트웨어 제품처럼 Life-cycle을 가진다는 것입니다.

첫째, 문제를 발견하고 기획을 해야 합니다. 사용자와 인터뷰를 하면서 “어떤 데이터가 필요해요?”라고 묻기보다는 “어떤 질문에 답을 하고 싶으세요?” 라고 질문해야 합니다. 예시를 들면 “로그 데이터가 필요해요.” 보다는 “고객이 결제 페이지에서 이탈하는 이유를 알고 싶어요.”로 문제를 재정의 해야 합니다.

둘째, 설계 및 Data Contract를 정의해야 합니다. 데이터 생산자와 소비자 간의 약속(스키마, 품질 지표, 갱신 주기 등)을 정의합니다. 이렇게 해야 소스 시스템의 변경으로 인해 파이프라인이 깨지는 현상을 방지할 수 있습니다.

셋째, 개발 및 모니터링을 해야 합니다. 제품이 출시된 후 잘 작동하는지 모니터링 하듯이, 데이터의 건강 상태를 체크해야 합니다. 데이터 가용성/최신성을 보장해야 하고, 구체적인 품질 목표 수치를 설정해야 합니다.

위에서 언급한 것처럼 데이터 엔지니어의 역할 범위가 넓어지게 되면 모든 도메인의 데이터를 이해하고 가공하는 것이 가능할까요? 저는 불가능하다고 생각됩니다. 그래서 중요한 것이 “책임의 분산”입니다.

• 도메인 중심 소유권: 각 비즈니스 부서가 자신들의 데이터를 제품으로서 책임지고 관리해야 합니다.
• 셀프 서비스 제공: 데이터 엔지니어는 각 부서가 데이터를 제품화할 수 있는 셀프 서비스 플랫폼을 제공해야 합니다.

위에서 언급한 환경을 어떻게 적용 할 수 있을까요?

데이터 제품도 MVP(Minimum Viable Product)처럼 시작해야 합니다. 처음부터 완벽하게 만들 수는 없습니다. 가장 시급한 문제를 해결하는 작은 데이터부터 제공하며 피드백 교류를 해야 합니다.

데이터 엔지니어가 제품을 잘 만들어도 소비자가 쓰지 못하면 소용 없습니다. 사용자를 대상으로 데이터 구조 및 활용법을 지속적으로 교육해야 합니다.

끝으로,

데이터 엔지니어링의 성공 지표는 “데이터 제품의 채택률”과 “사용자 만족도”가 되어야 합니다. 기술적으로 잘하는 것은 기본입니다. 기본위에 비즈니스와 사용자에 대한 이해라는 옷을 입을 때, 데이터 엔지니어는 단순한 기술 지원 역할을 넘어 비즈니스의 성장을 견인하는 핵심 파트너로 거듭날 수 있습니다.

[Tip] 데이터 엔지니어를 위한 제품 관리자 체크 리스트

데이터 엔지니어가 새로운 파이프라인을 구축하거나 데이터 제품을 기획할 때, 스스로에게 던져야 할 질문을 정리해봤습니다. 참고해주세요.

[ ] 누가 이 데이터를 사용하는가?

[ ] 사용자는 이 데이터로 어떤 비즈니스 문제를 해결하려고 하는가?

[ ] 이 데이터가 생성되지 않거나 틀렸을 때 발생하는 문제점은 무엇이고, 기회비용은 얼마인가?

[ ] 기존에 유사한 데이터가 있는가? (e.g 데이터 중복 방지)

[ ] Data contact이 체결 되었는가?

[ ] 데이터 신선도 기준은 무엇인가? (e.g 매일 오전 8시 업데이트, 실시간 등)

[ ] 민감 정보(개인정보 등)에 대한 비식별화 처리가 되었는가?

[ ] 데이터 파이프라인 가시성이 확보 되었는가? (e.g 장애 발생 시 알림 등)

[ ] 데이터 Lineage가 기록되고 있는가? (e.g 데이터 출처 및 흐름 파악)

[ ] 사용자가 데이터를 찾는데 걸리는 시간이 단축 되었는가?

[ ] 이 데이터 제품의 채택률은 얼마나 되는가?

[ ] 사용자 피드백을 수집할 채널이 준비되어 있는가?

Read More