LLM 워크플로의 조건 분기 완벽 가이드

LLM 애플리케이션에서 조건 분기를 활용하여 동적인 워크플로를 구축하는 방법을 알아봅니다. if-else부터 switch-case, 그리고 실전 라우팅까지 단계별로 학습합니다.

---

목차

1. 조건부 실행
2. if-else 패턴
3. Switch-case 패턴
4. 실습: 라우팅 워크플로
5. 실습: 동적 경로 선택

---

1. 조건부 실행

어느 날 김개발 씨는 회사에서 고객 문의를 자동으로 처리하는 LLM 시스템을 개발하고 있었습니다. 그런데 모든 문의에 똑같은 방식으로 답변하다 보니 고객 불만이 쏟아졌습니다.

"환불 문의인데 왜 제품 설명을 하는 거야?" 박시니어 씨가 다가와 말했습니다. "조건부 실행을 모르면 이런 문제가 생기지."

조건부 실행은 특정 조건에 따라 서로 다른 코드 경로를 선택하는 프로그래밍의 기본 개념입니다. 마치 갈림길에서 이정표를 보고 방향을 선택하는 것과 같습니다.

LLM 워크플로에서 조건부 실행을 제대로 활용하면 사용자의 의도에 맞는 정확한 응답을 제공할 수 있습니다.

다음 코드를 살펴봅시다.

# 조건부 실행의 기본 구조
def process_customer_inquiry(inquiry_type, message):
    # 문의 유형에 따라 다른 처리 로직 실행
    if inquiry_type == "refund":
        # 환불 관련 LLM 프롬프트 사용
        response = handle_refund_inquiry(message)
    elif inquiry_type == "product":
        # 제품 문의용 프롬프트 사용
        response = handle_product_inquiry(message)
    else:
        # 일반 문의 처리
        response = handle_general_inquiry(message)

    return response

김개발 씨는 입사 6개월 차 주니어 개발자입니다. 최근 회사에서 LLM을 활용한 고객 응대 시스템을 맡게 되었는데, 처음에는 모든 문의를 하나의 프롬프트로 처리했습니다.

결과는 참담했습니다. 환불을 원하는 고객에게 제품 설명을 늘어놓고, 배송 문의에는 엉뚱한 답변이 돌아왔습니다.

박시니어 씨가 커피 한 잔을 건네며 말했습니다. "LLM이 아무리 똑똑해도 상황에 맞는 지시를 받아야 제대로 된 답을 할 수 있어.

그게 바로 조건부 실행이야." 그렇다면 조건부 실행이란 정확히 무엇일까요? 쉽게 비유하자면, 조건부 실행은 마치 병원 접수처와 같습니다.

환자가 내과 증상을 호소하면 내과로, 외과 증상이면 외과로 안내합니다. 모든 환자를 한 곳으로 보내면 의사도 환자도 혼란에 빠지겠죠.

프로그램도 마찬가지입니다. 입력에 따라 적절한 처리 경로로 안내해야 합니다.

조건부 실행이 없던 시절에는 어땠을까요? 개발자들은 하나의 거대한 함수에서 모든 경우를 처리해야 했습니다.

코드는 금세 스파게티처럼 엉키고, 새로운 기능을 추가할 때마다 전체 로직을 건드려야 했습니다. 버그가 생기면 어디서 문제가 발생했는지 찾기도 어려웠습니다.

바로 이런 문제를 해결하기 위해 조건부 실행이 체계화되었습니다. 조건부 실행을 사용하면 각 상황에 맞는 독립적인 처리 로직을 구성할 수 있습니다.

코드의 가독성이 높아지고, 특정 조건의 로직만 수정해도 다른 부분에 영향을 주지 않습니다. 무엇보다 LLM 워크플로에서는 각 상황에 최적화된 프롬프트를 사용할 수 있다는 큰 장점이 있습니다.

위의 코드를 한 줄씩 살펴보겠습니다. 먼저 함수는 inquiry_type과 message 두 개의 매개변수를 받습니다.

inquiry_type은 문의 유형을 나타내고, message는 실제 고객의 메시지입니다. 그 다음 if-elif-else 구조를 통해 문의 유형에 따라 서로 다른 핸들러 함수를 호출합니다.

각 핸들러는 해당 유형에 최적화된 LLM 프롬프트를 사용합니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 이커머스 플랫폼의 챗봇을 개발한다고 가정해봅시다. 고객이 "주문한 상품이 언제 오나요?"라고 물으면 배송 조회 시스템과 연동된 응답을 제공하고, "이 상품 색상 다른 것도 있나요?"라고 물으면 상품 데이터베이스를 조회하는 식입니다.

조건부 실행 없이는 이런 분기 처리가 불가능합니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 조건의 순서를 고려하지 않는 것입니다. 더 구체적인 조건을 먼저 검사해야 합니다.

또한 else 절을 빠뜨려서 예상치 못한 입력에 대응하지 못하는 경우도 많습니다. 항상 기본 처리 경로를 마련해두어야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 조언을 듣고 조건부 실행을 적용한 후, 고객 만족도가 눈에 띄게 올랐습니다.

"이제야 제대로 된 답변을 받는 것 같아요!"라는 피드백이 쏟아졌습니다.

실전 팁

💡 - 조건 검사는 구체적인 것부터 일반적인 것 순으로 배치하세요

• 항상 else 절로 예외 상황을 처리하는 습관을 들이세요
• 조건이 복잡해지면 별도 함수로 분리하여 가독성을 높이세요

---

2. if-else 패턴

김개발 씨가 조건부 실행의 기본을 익힌 후, 박시니어 씨가 새로운 과제를 던졌습니다. "이제 LLM 응답의 신뢰도에 따라 다르게 처리해볼까?

신뢰도가 낮으면 사람이 검토해야 하거든." 김개발 씨는 고개를 끄덕이며 코드 에디터를 열었습니다.

if-else 패턴은 참과 거짓, 두 가지 경우를 처리하는 가장 기본적인 조건 분기입니다. LLM 워크플로에서는 응답 품질 검증, 사용자 권한 확인, 데이터 유효성 검사 등 이분법적 판단이 필요한 모든 곳에 활용됩니다.

단순해 보이지만 이 패턴을 제대로 이해하면 복잡한 분기 로직의 기초를 다질 수 있습니다.

다음 코드를 살펴봅시다.

# LLM 응답 신뢰도에 따른 if-else 분기
def process_llm_response(response, confidence_score):
    # 신뢰도 임계값 설정
    CONFIDENCE_THRESHOLD = 0.85

    if confidence_score >= CONFIDENCE_THRESHOLD:
        # 신뢰도가 높으면 자동 응답
        return {"status": "approved", "response": response}
    else:
        # 신뢰도가 낮으면 사람 검토 요청
        return {"status": "review_needed", "response": response}

# 사용 예시
result = process_llm_response("환불 처리 완료되었습니다.", 0.72)

김개발 씨는 이제 LLM 시스템의 다음 단계를 고민하고 있었습니다. 아무리 좋은 LLM이라도 때때로 엉뚱한 답변을 내놓을 수 있습니다.

이런 답변이 그대로 고객에게 전달되면 큰 문제가 됩니다. 박시니어 씨가 화이트보드에 그림을 그리며 설명했습니다.

"LLM은 응답과 함께 신뢰도 점수를 제공해. 이 점수가 일정 기준 이상이면 자동으로 보내고, 그렇지 않으면 사람이 확인하는 거지." if-else 패턴은 마치 놀이공원의 키 제한과 같습니다.

140cm 이상이면 롤러코스터를 탈 수 있고, 그렇지 않으면 탈 수 없습니다. 중간은 없습니다.

타거나, 못 타거나. 이처럼 if-else는 명확하게 두 가지 경우로 나누는 상황에 적합합니다.

LLM 워크플로에서 if-else가 필요한 이유는 무엇일까요? 첫째, 품질 관리입니다.

신뢰도가 낮은 응답을 걸러내어 서비스 품질을 유지할 수 있습니다. 둘째, 비용 최적화입니다.

모든 응답을 사람이 검토하면 비용이 많이 들지만, 신뢰도가 높은 응답은 자동 처리하면 효율적입니다. 셋째, 리스크 관리입니다.

민감한 내용이나 불확실한 응답은 사람의 판단을 거치게 하여 위험을 줄입니다. 코드를 자세히 들여다보겠습니다.

CONFIDENCE_THRESHOLD는 임계값으로, 0.85로 설정되어 있습니다. 이는 85% 이상의 신뢰도를 가진 응답만 자동 승인한다는 의미입니다.

이 값은 비즈니스 요구사항에 따라 조정할 수 있습니다. 고객 서비스처럼 정확도가 중요한 경우 더 높게, 일반적인 정보 제공의 경우 조금 낮게 설정할 수 있습니다.

if 문에서는 >= 연산자를 사용했습니다. 이는 "이상"을 의미하므로 0.85도 포함됩니다.

만약 **>**를 사용했다면 0.85는 포함되지 않습니다. 이런 세부사항이 실제 서비스에서는 큰 차이를 만들 수 있습니다.

실무에서 흔히 볼 수 있는 if-else 활용 사례를 더 살펴보겠습니다. 사용자 인증 여부에 따른 분기가 있습니다.

로그인한 사용자에게는 개인화된 응답을, 그렇지 않은 사용자에게는 일반적인 응답을 제공합니다. 또한 입력 데이터의 유효성 검사도 있습니다.

필수 필드가 모두 채워졌는지 확인하고, 그렇지 않으면 에러 메시지를 반환합니다. 주의해야 할 점도 있습니다.

if-else가 중첩되면 코드가 복잡해집니다. 세 단계 이상 중첩되면 다른 패턴을 고려해보세요.

또한 조건문 안에서 부작용이 있는 코드를 실행하면 디버깅이 어려워집니다. 가능하면 조건 검사와 실제 처리를 분리하는 것이 좋습니다.

김개발 씨는 이제 LLM 응답에 신뢰도 기반 검증을 추가했습니다. 덕분에 품질이 의심스러운 응답은 자동으로 검토 대기열에 들어가고, 고객에게는 항상 검증된 답변만 전달되었습니다.

실전 팁

💡 - 임계값은 상수로 정의하여 나중에 쉽게 조정할 수 있게 하세요

• 조건문의 결과를 변수에 담아 반환하면 디버깅이 쉬워집니다
• 중첩 if-else는 세 단계를 넘지 않도록 주의하세요

---

3. Switch-case 패턴

고객 문의 유형이 점점 늘어나면서 김개발 씨의 코드에는 elif가 줄줄이 이어지기 시작했습니다. 환불, 배송, 제품문의, 불만접수, 칭찬, 제휴문의...

박시니어 씨가 코드를 보더니 혀를 찼습니다. "이건 switch-case로 정리해야겠는데.

파이썬에서는 match-case를 쓰면 돼."

Switch-case 패턴은 하나의 변수가 여러 값 중 하나일 때 각각에 대해 다른 처리를 하는 패턴입니다. 파이썬 3.10부터는 match-case 문법으로 이를 지원합니다.

여러 개의 elif를 나열하는 것보다 가독성이 좋고, 새로운 케이스를 추가하기도 쉽습니다. LLM 워크플로에서 다양한 의도 분류를 처리할 때 특히 유용합니다.

다음 코드를 살펴봅시다.

# match-case를 활용한 의도 분류 처리
def route_by_intent(intent, message):
    match intent:
        case "refund":
            return process_refund(message)
        case "shipping":
            return check_shipping_status(message)
        case "product_inquiry":
            return answer_product_question(message)
        case "complaint":
            return handle_complaint(message)
        case "praise":
            return thank_customer(message)
        case _:
            # 기본 처리 (와일드카드 패턴)
            return handle_general_inquiry(message)

김개발 씨의 코드는 어느새 괴물이 되어 있었습니다. if로 시작해서 elif가 열 개가 넘게 이어지고, 새로운 문의 유형이 추가될 때마다 또 하나의 elif가 붙었습니다.

코드를 읽는 것만으로도 머리가 아팠습니다. 박시니어 씨가 옆에 앉으며 말했습니다.

"이런 상황에서는 match-case가 정답이야. 마치 우체국의 분류 작업처럼 생각하면 돼." 우체국에서 편지를 분류하는 모습을 상상해보세요.

직원이 편지를 집어들고 우편번호를 확인합니다. 서울이면 서울 바구니로, 부산이면 부산 바구니로, 대구면 대구 바구니로.

각 지역에 해당하는 바구니가 명확하게 나뉘어 있어서 빠르게 분류할 수 있습니다. match-case도 똑같습니다.

왜 elif를 쭉 나열하는 것보다 match-case가 나을까요? 첫째, 가독성입니다.

match-case는 "이 값이 무엇이냐에 따라 분기한다"는 의도를 명확히 드러냅니다. 둘째, 유지보수성입니다.

새로운 케이스를 추가할 때 다른 케이스에 영향을 주지 않고 독립적으로 추가할 수 있습니다. 셋째, 패턴 매칭입니다.

단순한 값 비교를 넘어 구조 분해, 가드 조건 등 고급 기능을 활용할 수 있습니다. 코드의 핵심 부분을 살펴보겠습니다.

match intent 구문에서 intent 변수의 값을 검사합니다. 각 case 절은 특정 값과 일치할 때 실행될 코드를 정의합니다.

마지막의 case _는 와일드카드 패턴으로, 위의 어떤 케이스에도 해당하지 않을 때 실행됩니다. 이는 다른 언어의 default와 같은 역할을 합니다.

LLM 워크플로에서 match-case는 특히 의도 분류 결과를 처리할 때 빛을 발합니다. LLM에게 사용자의 메시지를 분석하여 의도를 분류하도록 하면 "refund", "shipping" 같은 레이블이 반환됩니다.

이 레이블에 따라 각기 다른 처리 파이프라인으로 연결하는 것이 바로 match-case의 전형적인 활용입니다. 실무에서 주의할 점이 있습니다.

파이썬 3.10 이상에서만 match-case를 사용할 수 있습니다. 하위 버전 호환이 필요하다면 딕셔너리 기반 디스패치 패턴을 사용해야 합니다.

또한 case 절의 순서도 중요합니다. 더 구체적인 패턴을 먼저 배치하고, 와일드카드는 항상 마지막에 둬야 합니다.

김개발 씨는 열 개가 넘는 elif를 match-case로 정리했습니다. 코드 라인 수는 비슷했지만, 각 케이스가 명확히 분리되어 읽기가 훨씬 수월해졌습니다.

새로운 문의 유형이 추가되어도 해당 케이스만 추가하면 되었습니다.

실전 팁

💡 - 와일드카드 패턴 case _는 항상 마지막에 배치하세요

• 파이썬 3.10 미만에서는 딕셔너리 디스패치 패턴을 활용하세요
• 복잡한 조건이 필요하면 가드 절(case x if condition:)을 활용하세요

---

4. 실습: 라우팅 워크플로

이론은 충분합니다. 박시니어 씨가 말했습니다.

"이제 실제 LLM 라우팅 시스템을 만들어볼까? 사용자 메시지를 분석해서 적절한 처리 경로로 보내는 거야." 김개발 씨는 노트북을 열고 실전 코드를 작성하기 시작했습니다.

라우팅 워크플로는 입력을 분석하여 적절한 처리 경로로 전달하는 시스템입니다. LLM 애플리케이션에서는 사용자의 의도를 파악하고 그에 맞는 전문화된 에이전트나 프롬프트로 연결하는 역할을 합니다.

잘 설계된 라우팅 시스템은 응답 품질을 높이고 처리 효율을 극대화합니다.

다음 코드를 살펴봅시다.

# LLM 기반 라우팅 워크플로 구현
class IntentRouter:
    def __init__(self, llm_client):
        self.llm = llm_client
        self.handlers = {
            "technical": self.handle_technical,
            "billing": self.handle_billing,
            "general": self.handle_general
        }

    def classify_intent(self, message):
        # LLM으로 의도 분류
        prompt = f"다음 메시지의 의도를 분류하세요: {message}"
        return self.llm.classify(prompt)

    def route(self, message):
        intent = self.classify_intent(message)
        handler = self.handlers.get(intent, self.handle_general)
        return handler(message)

김개발 씨는 드디어 실전 프로젝트에 돌입했습니다. 지금까지 배운 조건 분기의 모든 것을 하나의 시스템으로 통합해야 합니다.

박시니어 씨가 요구사항을 정리해주었습니다. "고객 메시지가 들어오면 먼저 LLM이 의도를 분류해.

기술 지원인지, 요금 문의인지, 아니면 일반 문의인지. 그리고 각 의도에 맞는 전문 처리기로 보내는 거야." 이것은 마치 대형 콜센터의 ARS 시스템과 같습니다.

"기술 지원은 1번, 요금 문의는 2번, 상담원 연결은 0번을 눌러주세요." 고객의 선택에 따라 적합한 부서로 연결되는 것처럼, 라우팅 워크플로도 메시지의 의도에 따라 적합한 처리기로 연결합니다. 코드의 구조를 살펴보겠습니다.

IntentRouter 클래스는 세 가지 핵심 요소를 가집니다. 첫째, llm_client는 의도 분류에 사용할 LLM 클라이언트입니다.

둘째, handlers 딕셔너리는 각 의도와 그에 대응하는 처리 함수를 매핑합니다. 셋째, route 메서드는 전체 플로우를 조율하는 메인 로직입니다.

classify_intent 메서드를 주목해주세요. 이 메서드는 사용자 메시지를 받아 LLM에게 의도 분류를 요청합니다.

LLM은 미리 정의된 카테고리 중 하나를 반환합니다. 이 과정이 바로 자연어를 구조화된 데이터로 변환하는 핵심 단계입니다.

route 메서드의 동작 방식도 중요합니다. 먼저 classify_intent를 호출하여 의도를 파악합니다.

그 다음 handlers 딕셔너리에서 해당 의도에 맞는 핸들러를 가져옵니다. get 메서드의 두 번째 인자는 기본값으로, 매핑되지 않은 의도가 들어오면 handle_general이 실행됩니다.

이렇게 하면 예상치 못한 의도에도 안전하게 대응할 수 있습니다. 왜 딕셔너리 기반 디스패치를 사용할까요?

if-elif를 사용해도 동일한 기능을 구현할 수 있습니다. 하지만 딕셔너리 방식은 새로운 핸들러를 추가할 때 handlers에만 등록하면 됩니다.

route 메서드의 로직은 전혀 건드릴 필요가 없습니다. 이것이 바로 개방-폐쇄 원칙의 실천입니다.

실무에서 이 패턴을 확장하는 방법도 알아두면 좋습니다. 각 핸들러에 우선순위를 부여할 수 있습니다.

여러 의도가 동시에 감지되면 우선순위가 높은 핸들러가 처리합니다. 또한 핸들러 체인을 구성하여 하나의 메시지를 여러 핸들러가 순차적으로 처리하게 할 수도 있습니다.

김개발 씨는 라우팅 워크플로를 완성했습니다. 이제 고객의 다양한 문의가 각각 최적화된 경로로 처리되었습니다.

기술 문의는 기술 전문 프롬프트로, 요금 문의는 결제 시스템과 연동된 응답으로, 일반 문의는 친절한 안내 메시지로 이어졌습니다.

실전 팁

💡 - 핸들러 함수는 동일한 인터페이스(입력과 출력 형식)를 유지하세요

• 딕셔너리의 get 메서드로 기본 핸들러를 지정하면 예외 처리가 간단해집니다
• 의도 분류 결과를 로깅하여 시스템 개선에 활용하세요

---

5. 실습: 동적 경로 선택

라우팅 시스템이 잘 동작하자 새로운 요구사항이 들어왔습니다. "고객 등급에 따라 다른 LLM 모델을 사용하고 싶어.

VIP 고객은 더 좋은 모델로." 박시니어 씨의 말에 김개발 씨는 고민에 빠졌습니다. 의도뿐 아니라 고객 정보까지 고려해야 하는 다중 조건 라우팅이 필요한 상황이었습니다.

동적 경로 선택은 여러 조건을 종합적으로 고려하여 실행 경로를 결정하는 고급 패턴입니다. 단일 조건이 아닌 복합 조건을 평가하고, 런타임에 최적의 경로를 선택합니다.

LLM 워크플로에서는 사용자 속성, 메시지 특성, 시스템 상태 등을 조합하여 가장 적합한 처리 전략을 동적으로 결정합니다.

다음 코드를 살펴봅시다.

# 다중 조건 기반 동적 경로 선택
class DynamicRouter:
    def __init__(self, models):
        self.models = models

    def select_route(self, user_tier, message_complexity, urgency):
        # 복합 조건으로 모델 선택
        if user_tier == "vip" and urgency == "high":
            return self.models["premium"]
        elif message_complexity > 0.8:
            return self.models["advanced"]
        elif user_tier == "free":
            return self.models["basic"]
        else:
            return self.models["standard"]

    def process(self, user, message):
        complexity = self.analyze_complexity(message)
        model = self.select_route(user.tier, complexity, user.urgency)
        return model.generate(message)

김개발 씨는 새로운 도전 앞에 섰습니다. 지금까지는 메시지의 의도 하나만 보고 경로를 결정했습니다.

하지만 현실은 더 복잡합니다. 같은 기술 문의라도 VIP 고객에게는 더 정교한 답변을, 무료 사용자에게는 기본적인 답변을 제공해야 할 수 있습니다.

박시니어 씨가 비유를 들어 설명했습니다. "비행기 좌석 배정을 생각해봐.

마일리지 등급, 결제 클래스, 좌석 선호도, 동반자 여부... 여러 조건을 종합해서 최적의 좌석을 배정하잖아.

우리 시스템도 마찬가지야." 동적 경로 선택의 핵심은 조건의 우선순위입니다. 코드를 보면 조건 검사의 순서가 있습니다.

가장 먼저 VIP이면서 긴급한 경우를 처리합니다. 이것이 최우선 조건입니다.

그 다음은 메시지 복잡도가 높은 경우, 그 다음은 무료 사용자, 마지막으로 나머지 모든 경우입니다. 이 순서가 바뀌면 결과도 달라집니다.

select_route 메서드를 자세히 분석해보겠습니다. 세 개의 매개변수를 받습니다.

user_tier는 사용자 등급, message_complexity는 0에서 1 사이의 복잡도 점수, urgency는 긴급도입니다. 이들을 조합하여 네 가지 모델 중 하나를 반환합니다.

각 모델은 성능과 비용이 다르므로 상황에 맞게 선택해야 합니다. 복잡도 분석은 어떻게 할까요?

analyze_complexity 메서드는 메시지를 분석하여 복잡도 점수를 산출합니다. 문장의 길이, 전문 용어의 사용 빈도, 질문의 중첩 수준 등을 고려할 수 있습니다.

간단한 "안녕하세요"는 복잡도가 낮고, 여러 기술적 개념이 얽힌 질문은 복잡도가 높습니다. 실무에서 동적 라우팅을 설계할 때 고려할 점이 있습니다.

첫째, 성능과 비용의 균형입니다. 좋은 모델일수록 비용이 높습니다.

모든 요청에 최고급 모델을 사용하면 비용이 감당이 안 됩니다. 둘째, 공정성입니다.

무료 사용자에게도 최소한의 품질은 보장해야 합니다. 셋째, 투명성입니다.

어떤 기준으로 라우팅되는지 사용자가 이해할 수 있어야 합니다. 조건이 복잡해지면 어떻게 관리해야 할까요?

조건 로직을 별도의 설정 파일이나 규칙 엔진으로 분리하는 것이 좋습니다. 코드에 하드코딩된 조건은 수정할 때마다 배포가 필요하지만, 외부 설정은 실시간으로 변경할 수 있습니다.

A/B 테스트를 통해 어떤 라우팅 전략이 더 효과적인지 검증하는 것도 중요합니다. 김개발 씨는 동적 라우팅 시스템을 구축했습니다.

이제 VIP 고객의 긴급 문의는 최고급 모델이 처리하고, 간단한 일반 문의는 경량 모델이 빠르게 처리합니다. 비용은 최적화되고, 고객 만족도는 높아졌습니다.

박시니어 씨가 흡족한 표정으로 말했습니다. "이제 진짜 프로덕션 레벨이네."

실전 팁

💡 - 조건의 우선순위를 명확히 문서화하세요

• 라우팅 결정 로그를 남겨 나중에 분석할 수 있게 하세요
• 조건 로직은 가능하면 외부 설정으로 분리하여 유연성을 확보하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!