RAG란 무엇인가 — 모든 기업이 "우리 회사 챗봇"에 뛰어드는 이유

직원 약 500명 규모의 한 산업용 장비 제조사에서, 현장 기사가 매뉴얼 속 정보 하나를 찾는 데 걸리던 시간은 평균 18분이었다. 낡은 인트라넷, 버전이 뒤섞인 PDF, 담당자만 아는 사내 위키를 뒤지다 지쳐 결국 옆자리 선배에게 전화를 거는 게 더 빨랐다. 그런데 이 회사가 사내 문서를 연결한 RAG(검색 증강 생성, Retrieval-Augmented Generation) 챗봇을 도입한 뒤, 같은 질문에 대한 응답 시간은 평균 90초로 줄었다. 정보 검색 시간이 95% 단축된 것이다. 이 숫자 하나가 지금 한국 기업들이 앞다퉈 "우리 회사 전용 챗봇"을 만들겠다고 나서는 이유를 압축해서 보여준다. RAG는 더 이상 AI 스타트업의 실험실 용어가 아니라, 2026년 현재 한국 기업 챗봇 도입의 60% 이상이 채택하는 사실상의 표준 구조가 됐다.

🕰️ RAG는 어디에서 왔는가 — 2020년 논문에서 2026년 표준까지

RAG라는 개념이 학계에 처음 등장한 것은 2020년, 메타(당시 페이스북 AI 리서치)의 패트릭 루이스(Patrick Lewis) 연구팀이 세계적 AI 학회 NeurIPS에서 발표한 논문 "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"였다. 이 논문의 핵심 아이디어는 단순했다. 거대 언어모델이 가진 지식(파라미터에 저장된 '기억')만으로 답하게 하지 말고, 질문이 들어올 때마다 외부 문서 저장소에서 관련 정보를 먼저 찾아온 뒤 그 내용을 근거로 답을 생성하게 하자는 것이다. 연구팀은 이렇게 만든 모델이 순수 파라미터 지식만 쓰는 모델보다 더 구체적이고, 다양하며, 사실에 기반한 답변을 만들어낸다는 것을 오픈도메인 질의응답 벤치마크 3종에서 입증했다.

이후 2021년에는 검색과 생성이 상호작용하는 방식을 정교화한 퓨전인디코더(Fusion-in-Decoder) 등 후속 연구가 이어졌고, 2022~2023년 챗GPT발 생성형 AI 붐을 거치며 RAG는 "환각(hallucination)을 줄이는 실용적 해법"으로 산업계에 빠르게 흡수됐다. 그리고 2025~2026년 현재는 벡터 데이터베이스, 임베딩 모델, 리랭킹(re-ranking) 기술이 성숙하면서 중소기업도 몇 주 안에 자체 RAG 시스템을 구축할 수 있는 단계에 이르렀다. 5년 남짓한 시간 동안 RAG는 논문 속 아이디어에서 기업 IT 부서의 필수 프로젝트로 자리를 옮긴 셈이다.

도구 생태계의 성숙 — 왜 지금 "누구나 가능"해졌나

같은 아이디어라도 2020년과 2026년의 진입 장벽은 완전히 다르다. 초기에는 검색 인프라와 임베딩 모델을 직접 설계해야 했지만, 이후 Pinecone·Chroma·pgvector 같은 벡터 데이터베이스, LangChain·LlamaIndex 같은 오케스트레이션 프레임워크, OpenAI·Anthropic·구글 등의 고품질 임베딩 API가 잇따라 등장하면서 개발 난이도가 크게 낮아졌다. 실제로 앞서 소개한 중견 제조사 사례에서는 text-embedding-3-large 임베딩 모델, Postgres+pgvector 데이터베이스, 리랭킹, Claude Sonnet 생성 모델을 조합해 8주 만에 시스템을 완성했다. 즉 RAG 확산의 절반은 알고리즘 발전이고, 나머지 절반은 "이미 잘 만들어진 부품을 조립하는 일"이 쉬워진 결과다.

💡 RAG란 정확히 무엇인가 — "오픈북 시험"을 보는 AI

검색(Retrieval) + 생성(Generation)의 결합

RAG를 가장 쉽게 이해하는 방법은 시험에 비유하는 것이다. 일반적인 거대 언어모델은 "암기한 지식만으로 시험을 보는 학생"과 같다. 학습 시점에 본 데이터를 바탕으로 답하기 때문에, 어제 업데이트된 사내 정책이나 회사 내부 문서는 애초에 알 수가 없다. 반면 RAG 기반 챗봇은 "오픈북 시험을 보는 학생"이다. 질문을 받으면 곧바로 회사의 문서함(벡터 데이터베이스)을 펼쳐 관련 페이지를 찾아 옆에 놓고, 그 내용을 참고해 답을 작성한다.

동작 원리 3단계

기술적으로는 크게 세 단계로 나뉜다. 첫째, 사내 문서(정책·매뉴얼·고객 응대 기록 등)를 잘게 쪼개 의미 벡터로 변환해 저장하는 임베딩·인덱싱 단계. 둘째, 사용자의 질문이 들어오면 그 질문과 의미적으로 가장 가까운 문서 조각을 찾아오는 검색(retrieval) 단계. 셋째, 검색된 조각들을 거대 언어모델에 함께 넣어 실제 문서에 근거한 답변을 생성하는 단계다. 최근에는 검색 정확도를 높이기 위한 리랭킹(re-ranking) 모델을 추가하는 것이 사실상 표준이 됐다.

💡 핵심 정리 — RAG는 AI 모델을 다시 학습시키는 것이 아니라, 답을 하기 직전에 "참고자료"를 붙여주는 방식이다. 그래서 문서가 바뀌면 모델을 재학습할 필요 없이 즉시 반영된다.

💼 왜 모든 기업이 "우리 회사 챗봇"을 원하는가 — 구조적 원인

지금 한국의 거의 모든 업종에서 "사내 전용 AI 챗봇을 만들자"는 요구가 동시다발적으로 터져 나오고 있다. 이는 우연이 아니라 몇 가지 구조적 원인이 겹친 결과다.

비정형 데이터의 폭증

기업이 보유한 데이터의 80% 이상이 이메일, 회의록, 계약서, 고객 상담 티켓 같은 비정형 데이터로 추정된다. 이 데이터는 기존 데이터베이스 검색으로는 활용이 어려웠지만, RAG는 이런 문서 더미를 그대로 검색 가능한 지식 자산으로 바꿔준다.

정보 탐색 비용의 누적

실제 사례에서 봤듯, 직원 한 명이 정보를 못 찾아 헤매는 18분은 사소해 보이지만 수백 명, 수천 건의 문의로 곱하면 막대한 인건비 손실이 된다. 콜센터·헬프데스크·현장 인력이 많은 제조업·금융업·시설관리업일수록 이 비용은 더 크게 체감된다.

경쟁사도 이미 하고 있다는 압박

KB국민카드는 매일 바뀌는 이벤트 문서와 수백 건에 달하는 프로모션 정보를 관리하는 부담을 줄이기 위해 'BELLA QNA'라는 사내 RAG 챗봇을 도입했다. 이런 사례가 업계 컨퍼런스와 기사로 알려지면서, 동종 업계 다른 회사들도 "우리도 늦으면 안 된다"는 조바심을 갖게 된다. 이 압박은 때로 비즈니스 문제 정의 없이 "일단 챗봇부터 만들자"는 성급한 의사결정으로 이어지기도 한다.

📊 데이터로 보는 RAG 열풍 — 시장은 얼마나 커졌나

수치로 보면 이 흐름은 일시적 유행이 아니라 명백한 구조적 전환이다. 시장조사기관 그랜드뷰리서치에 따르면 글로벌 RAG 시장은 2023년 약 12억 달러 규모에서 2030년까지 약 110억 달러로 성장할 것으로 전망되며, 2025~2030년 연평균 성장률(CAGR)은 49.1%에 달한다. 또 다른 조사기관 마켓츠앤마켓츠는 2025년 시장 규모를 19.4억 달러로, 2030년에는 98.6억 달러로 추산하며 연평균 38.4% 성장을 예상했다. 두 기관의 수치는 다르지만 방향은 같다 — RAG 시장은 앞으로 5년간 매년 40~50% 가까이 커진다는 것이다.

국내 도입 현황

국내에서도 2026년 현재 기업 챗봇 신규 도입 프로젝트의 60% 이상이 RAG 구조를 채택하고 있는 것으로 파악된다. 도입 규모도 다양하다. 개념 증명(PoC) 단계는 1,500만~3,000만원, 실제 운영 가능한 시스템은 3,000만~7,000만원, 엔터프라이즈급 대규모 구축은 1억~3억원 수준이며 운영비는 월 100만원에서 월 1,000만원까지 조직 규모에 따라 편차가 크다.

업종별 온도차

성장세가 모든 업종에서 균일한 것은 아니다. 시장 성장을 이끄는 핵심 동력은 대형 언어모델이 의료·금융·고객 서비스 산업 전반에 채택되는 흐름과, 기업이 보유한 데이터의 80% 이상을 차지하는 비정형 데이터를 활용하려는 수요다. 반면 RAG 모델을 학습·배포하는 데 드는 높은 연산 비용은 중소기업 입장에서 여전히 진입 장벽으로 작용한다는 지적도 나온다. 이는 앞서 살펴본 실패 사례처럼, 예산이 적은 조직일수록 문서 품질 관리나 평가 체계에 투자할 여력이 부족해 실패 확률이 높아지는 현상과도 무관하지 않다.

📌 한눈에 보기 — 글로벌 RAG 시장은 2025~2030년 연 38~49% 성장 전망(그랜드뷰리서치·마켓츠앤마켓츠), 국내 기업 챗봇의 60% 이상이 RAG 구조 채택(2026년 기준).

🔍 실무 사례로 본 성공과 실패 — 같은 기술, 다른 결과

성공 사례 1 — 제조업, 정보 탐색 시간 95% 단축

앞서 소개한 산업용 장비 제조사(직원 약 500명)는 현장 기사가 매뉴얼을 찾는 시간을 18분에서 90초로 줄였다. 핵심은 기술 자체보다 "무엇을 검색 가능하게 만들 것인가"를 명확히 정의한 데 있었다. 흩어진 PDF 매뉴얼을 정리하고 최신 버전만 남긴 뒤 인덱싱한 것이 성공의 절반이었다.

성공 사례 2 — 금융업, 매일 바뀌는 정보의 실시간 반영

KB국민카드의 'BELLA QNA'는 매일같이 갱신되는 이벤트·프로모션 문서 수백 건을 관리해야 하는 운영 부담을 RAG로 해결한 사례다. 파인튜닝 방식이었다면 문서가 바뀔 때마다 모델을 다시 학습시켜야 했겠지만, RAG는 문서를 갱신하는 즉시 챗봇 답변에 반영된다는 장점을 살렸다.

실패 사례 — 중소 IT 기업, 4개월 만에 운영 중단

모든 사례가 성공적인 것은 아니다. 직원 80명 규모의 한 중소 IT 기업은 사내 협업툴(Confluence) 문서 약 600건을 기반으로 RAG 챗봇을 4주, 약 1,200만원을 들여 구축했지만 PoC 시작 4개월 만에 운영을 중단했다. 정확도는 41%에 그쳤고, 사용률은 12%에서 6%로 오히려 떨어졌다. 원인은 명확했다. 5년치 문서를 중복·구버전 정리 없이 그대로 임베딩했고, 사용한 경량 임베딩 모델의 한국어 처리 정확도를 사전 검증하지 않았으며, 평가 데이터셋 없이 곧바로 운영에 들어갔다.

실패 사례 — 글로벌 금융 서비스 기업의 지연·불일치 문제

한 글로벌 금융 서비스 기업의 초기 RAG 시스템은 검색 결과로 오래된 정책 문서가 반환되고, 업무가 몰리는 시간대엔 응답 지연이 급격히 늘었으며, 상담사마다 일관되지 않은 답변을 전달받는 문제를 겪었다. IT전문지 ITWorld는 이를 두고 "기업용 RAG는 왜 실패하는가"라는 제목의 분석 기사에서, 진짜 어려움은 프롬프트 설계나 모델 선택이 아니라 데이터 수집·정제, 검색 최적화, 메타데이터 관리, 버전 관리, 장기적 거버넌스에 있다고 짚었다.

⚠️ 주의 — 개념 증명(PoC) 단계까지 도달하는 기업은 많지만, 이를 실제 운영 환경에서 안정적으로 운영하는 데 성공하는 사례는 여전히 드물다는 것이 업계 공통된 진단이다.

⚖️ RAG vs 파인튜닝 vs 프롬프트 엔지니어링 — 무엇을 선택해야 하나

"우리 회사 챗봇"을 만들겠다고 결심했다면 다음 질문이 따라온다. RAG로 만들 것인가, 모델 자체를 다시 학습(파인튜닝)시킬 것인가, 아니면 프롬프트만 잘 짜서 쓸 것인가. 세 방식은 목적과 비용 구조가 다르다.

구분	RAG (검색 증강 생성)	파인튜닝	프롬프트 엔지니어링
핵심 방식	답변 전 외부 문서 검색 후 근거로 생성	모델 가중치 자체를 재학습	지시문만 정교하게 설계
적합 상황	정보가 자주 바뀌고 출처 제시가 중요할 때	전문 용어·말투·논리 구조를 깊이 학습시켜야 할 때	일반 대화, 간단한 분류·요약
정보 갱신	문서만 교체하면 즉시 반영	재학습 필요(수 주·수백만원)	즉시 반영(단, 모델 자체 지식엔 한계)
비용	파인튜닝 대비 5~10배 저렴	상대적으로 고비용·장기간	가장 저렴, 대신 성능 한계 뚜렷
출처 제시(감사 대응)	가능 — 답변 근거 문서 표시	어려움 — 근거 추적 곤란	불가능

실무에서는 셋 중 하나만 택하기보다 조합하는 경우가 많다. 국내 RAG 챗봇 현장에서는 'RAG + 프롬프트 엔지니어링' 조합이 가장 흔하며, 예산이 빠듯한 조직은 RAG 단독으로 먼저 시작해 운영 데이터가 충분히 쌓인 뒤 특정 영역(법률·의학처럼 전문 용어·규칙이 정교해야 하는 분야)에 한해 파인튜닝을 검토하는 단계적 접근이 효율적이라는 게 여러 업계 가이드의 공통된 조언이다.

⚠️ RAG의 한계 — "환각을 없애는 마법"이 아니다

RAG가 확산되면서 한 가지 오해도 함께 퍼졌다. "RAG를 도입하면 AI가 거짓말(환각)을 하지 않는다"는 믿음이다. 하지만 이는 정확한 설명이 아니다. 업계 전문가들은 RAG가 환각을 완전히 없애는 것이 아니라, 모델의 답변 범위를 검증된 지식 경계 안으로 제한하는 것에 가깝다고 설명한다. 즉 참고자료가 부실하면 참고자료에 근거한 그럴듯한 오답이 나올 수 있다는 뜻이다.

가장 흔한 함정 — 오염된 문서함

2026년 기준 기업이 겪는 가장 큰 문제 중 하나는 '소스 품질'이다. 챗봇이 참조하는 문서함에 오래된 PDF, 중복된 지식베이스 글, 폐기된 제품 페이지, 검증되지 않은 사내 메모가 뒤섞여 있으면, 챗봇은 서로 모순된 정보를 조합해 답을 만들어낼 수 있다. 다단계 추론이 필요한 업무, 엄격한 규제 준수가 걸린 업무, 실시간 운영 데이터 통합이 필요한 업무에서는 RAG 단독으로는 한계가 뚜렷하다는 지적도 나온다.

⚠️ 주의 — "문서를 다 넣기만 하면 똑똑한 챗봇이 된다"는 생각은 가장 흔한 착각이다. 정리되지 않은 문서는 오히려 잘못된 답변의 재료가 된다.

🧭 전문가 시각과 논쟁 — 거버넌스가 먼저다

업계 전문가들 사이에서도 강조점은 조금씩 다르다. 일부는 검색·임베딩 기술의 고도화(고급 리랭킹, 하이브리드 검색)를 강조하는 반면, 다른 전문가들은 기술보다 조직의 문제 정의와 데이터 거버넌스가 성패를 가른다고 본다. 여러 실패 사례를 비교 분석한 글에서 공통적으로 지적되는 차이점은 이렇다. 실패한 조직은 "AI 도입 자체"를 목표로 삼았고, 성공한 조직은 "명확한 비즈니스 문제 해결 수단"으로 AI를 활용했다는 것이다.

환각 감소 문제 역시 모델 선택의 문제가 아니라 시스템 설계와 거버넌스의 문제로 다뤄야 한다는 것이 최근 전문가 논의의 공통된 방향이다. 컴플라이언스 문서화와 감사 추적(audit trail) 체계는 나중에 덧붙이기보다 처음 설계 단계부터 포함하는 편이 훨씬 수월하다는 조언도 함께 나온다. 이는 규제 산업(금융·의료·공공)일수록 더 중요해지는 대목이다.

서로 다른 관점 — 기술 낙관론 vs 신중론

한쪽에서는 리랭킹·하이브리드 검색·멀티모달 RAG 같은 기술 고도화가 빠르게 진행 중이라며 조만간 도입 장벽이 더 낮아질 것이라 본다. 실제로 멀티모달 RAG 툴링 시장을 다루는 조사도 잇따라 나오고 있어, 텍스트를 넘어 이미지·표·도면까지 검색 대상에 포함시키는 흐름이 감지된다. 반대로 신중론자들은 "워크플로가 다단계 추론, 엄격한 규제 준수, 실시간 운영 데이터 통합을 요구할 때는 RAG 단독으로는 충분하지 않다"고 짚는다. 두 시각은 상충한다기보다, RAG를 "만능 해법"이 아니라 "적합한 문제에 쓰는 도구"로 봐야 한다는 점에서 결국 같은 결론으로 수렴한다.

🗺️ 우리 회사에 RAG 챗봇, 어떻게 시작해야 하나 — 실전 가이드

지금까지 살펴본 성공·실패 사례를 종합하면, RAG 도입은 기술 선택보다 준비 과정이 훨씬 중요하다. 실무에서 참고할 수 있는 단계별 접근은 다음과 같다.

문제부터 좁힌다 — "챗봇을 만들자"가 아니라 "어떤 반복 질문에 시간이 가장 많이 낭비되는가"를 먼저 정의한다. 헬프데스크·온보딩·현장 매뉴얼 검색처럼 범위가 좁고 반복적인 영역이 첫 시도로 적합하다.
문서를 정리한다 — 중복·구버전 문서를 걸러내지 않고 통째로 임베딩하면 실패 확률이 급격히 올라간다는 것이 앞선 실패 사례의 공통된 교훈이다. 최신 버전만 남기고 메타데이터(작성일·부서·버전)를 정리하는 작업이 전체 프로젝트에서 가장 많은 시간을 차지한다.
작게 시작해 검증한다 — 처음부터 전사 시스템을 구축하기보다 특정 부서·특정 문서군으로 PoC를 진행하고, 정확도·사용률 같은 평가 지표를 미리 정의해 측정한다.
거버넌스를 함께 설계한다 — 답변 근거(출처) 표시, 오답 신고 체계, 정기적인 문서 업데이트 프로세스를 처음부터 포함시킨다.
단계적으로 확장한다 — RAG만으로 부족한 특정 전문 영역이 확인되면 그때 파인튜닝이나 추가 리랭킹 모델 도입을 검토한다.

실제 프로젝트 기간은 조직 규모와 문서량에 따라 다르지만, 앞서 소개한 사례들을 종합하면 소규모(문서 수백 건, 특정 부서 한정)는 4~8주, 중견 규모(문서 수천 건, 여러 부서)는 2~3개월가량이 현실적인 기준으로 언급된다. 중요한 것은 일정 자체보다, 각 단계가 끝날 때마다 "이 챗봇이 실제로 시간을 아껴주는가"를 데이터로 확인하고 다음 단계로 넘어가는 것이다.

이 과정을 사내 인력만으로 처음부터 끝까지 설계하기는 쉽지 않다. 문서 정제, 임베딩 모델 선택, 벡터 데이터베이스 구성, 리랭킹, 거버넌스 설계까지 다뤄야 할 영역이 많기 때문에, 실제 구축 사례와 실패 원인을 함께 검토하며 접근하는 학습이 도움이 된다. NUGUNA(누구나패스)의 사내 RAG 챗봇 구축 과정에서는 이런 실무 단계를 사례 중심으로 다룬다.

❓ 자주 묻는 질문 (FAQ)

Q1. RAG와 챗GPT 같은 일반 AI 챗봇은 뭐가 다른가요?
일반 챗봇은 학습 시점까지의 지식으로만 답합니다. RAG 챗봇은 질문마다 회사 내부 문서를 실시간으로 검색해 그 내용을 근거로 답하기 때문에, 최신 사내 정책이나 비공개 정보도 반영할 수 있습니다.

Q2. 우리 회사도 RAG 챗봇을 꼭 만들어야 하나요?
꼭 그렇지는 않습니다. 반복적으로 같은 정보를 찾는 업무(헬프데스크, 매뉴얼 검색, 사내 FAQ)가 많고 문서가 자주 바뀌는 조직일수록 효과가 큽니다. 반대로 정보량이 적고 질문 패턴이 단순하다면 프롬프트 엔지니어링만으로도 충분할 수 있습니다.

Q3. 구축 비용은 대략 얼마나 드나요?
2026년 국내 기준 개념 증명(PoC)은 약 1,500만~3,000만원, 실제 운영 가능한 수준은 3,000만~7,000만원, 대규모 엔터프라이즈급은 1억~3억원 선으로 알려져 있으며 운영비는 조직 규모에 따라 월 100만~1,000만원 범위로 편차가 큽니다.

Q4. RAG를 쓰면 AI가 틀린 답을 하지 않나요?
아닙니다. RAG는 환각을 줄이는 데 도움을 주지만 완전히 없애지는 못합니다. 참고 문서 자체가 오래됐거나 부정확하면 그 내용을 근거로 한 오답이 나올 수 있어, 문서 품질 관리가 필수입니다.

Q5. RAG와 파인튜닝을 같이 쓸 수도 있나요?
가능합니다. 실무에서는 RAG로 먼저 시작해 운영 데이터를 쌓은 뒤, 법률·의료처럼 전문 용어와 규칙이 정교해야 하는 영역에 한해 파인튜닝을 추가하는 단계적·혼합 접근이 흔합니다.

Q6. 비전문가도 RAG 챗봇 구축을 배울 수 있나요?
벡터 데이터베이스나 임베딩 같은 용어가 낯설 수 있지만, 최근에는 이런 개념을 실습 중심으로 익힐 수 있는 온라인 강의가 많아졌습니다. 기초 개념부터 실제 구축 사례까지 단계적으로 학습하는 편이 시행착오를 줄이는 길입니다.

Q7. 실패하는 RAG 프로젝트의 공통점은 무엇인가요?
문서 정리 없이 그대로 임베딩하는 것, 한국어 처리 성능을 검증하지 않은 임베딩 모델을 그대로 쓰는 것, 평가 데이터셋 없이 곧바로 운영에 들어가는 것이 반복적으로 지적되는 실패 원인입니다. 아울러 "AI 도입 자체"를 목표로 삼고 시작하는 프로젝트도 실패 확률이 높다는 점이 여러 사례 분석에서 공통으로 나타납니다. 반대로 어떤 반복 업무를 줄이겠다는 목표가 명확한 프로젝트일수록 성공률이 높았습니다.

🚀 결론 — 기술보다 준비가 먼저다

RAG는 2020년 한 편의 논문에서 시작해 2026년 현재 한국 기업 챗봇 도입의 60% 이상이 채택하는 표준 구조로 자리 잡았다. 글로벌 시장 규모도 매년 40~50%씩 성장하고 있다. 그러나 이 글에서 살펴본 성공·실패 사례가 공통으로 말해주는 것은 하나다. RAG는 "정리된 지식을 빠르게 찾아주는 도구"이지, "아무 데이터나 넣으면 똑똑해지는 마법 상자"가 아니라는 점이다. 정보 탐색 시간을 95% 줄인 제조사와, 4개월 만에 운영을 중단한 중소 IT 기업의 차이는 기술력이 아니라 문서 정리와 문제 정의, 그리고 거버넌스에 있었다.

RAG의 기본 원리, 사내 데이터 정제 방법, 벡터 검색과 리랭킹 같은 실무 스킬을 체계적으로 익히고 싶다면 NUGUNA의 IT 강의 목록이나 무료 강의에서 AI·데이터 관련 과정을 먼저 살펴보는 것도 방법이다. 전체 커리큘럼은 전체 강의 보기에서, 학습 로드맵이 필요하다면 학습 페이지를 확인해보자. 사내 RAG 챗봇 구축을 구체적으로 준비하고 있다면 사내 RAG 챗봇 구축 과정에서 실제 설계 흐름을 참고할 수 있다.