AI 에이전트 루프 설계: 툴 호출부터 종료 조건까지

다음 행동은 모델이 제안합니다. 그 행동을 실행해도 되는지 판단하고, 실행 결과를 기록하고, 모델을 다시 호출할지 결정하는 주체는 애플리케이션입니다. 처음 에이전트를 만들 때도, 멈추지 않은 에이전트의 원인을 조사할 때도 이 역할 구분부터 분명히 해야 합니다.

아래에 설명한 프레임워크 동작은 2026년 10월 24일 각 개발사의 공식 문서를 기준으로 확인했습니다. 프레임워크마다 무엇을 세고 어느 시점에 제어하는지 비교할 수 있도록 기준을 맞췄습니다. 고객 지원 티켓 사례와 제안하는 운영 정책은 이해를 돕기 위한 예시이며, 실제 운영 환경에서 측정한 결과가 아닙니다.

AI 에이전트 루프는 어떻게 동작합니까?

실용적인 루프의 흐름은 모델 호출 → 툴 호출 → 관찰 → 반복입니다. 더 진행할 필요가 없거나 진행이 허용되지 않으면 그 시점에 빠져나옵니다.

작업을 배정하는 담당자와 현장 기술자를 떠올리면 이해하기 쉽습니다. 담당자는 다음 작업을 정하고, 기술자는 작업을 수행하며, 돌아온 작업 보고서는 다음 판단의 근거가 됩니다. 기계를 점검하라는 요청 자체가 점검은 아닙니다. 안심시키는 말만으로 수리가 성공했다고 볼 수도 없습니다.

소프트웨어에서 작업을 배정하는 역할은 대규모 언어 모델, 즉 LLM이 맡습니다. 기술자 역할은 툴이 맡습니다. 데이터베이스를 읽거나, 문서를 검색하거나, 명령을 실행하거나, 레코드를 변경하는 함수가 여기에 해당합니다. 둘을 연결하는 코드는 런타임입니다.

가상의 티켓 답변 초안 작성 작업을 추적하면 다음과 같을 수 있습니다. 첫 번째 모델 호출에서 티켓을 요청하고, 두 번째 호출에서 관련 정책을 요청하며, 세 번째 호출에서 둘을 근거로 초안을 반환합니다. 애플리케이션 요청 하나 안에서 모델 호출 3회와 툴 실행 2회가 일어난 것입니다. 답변 전송에 승인이 필요하다면, 초안 작성은 완료하되 전송은 대기 상태로 남길 수 있습니다.

작업 상태는 대화 기록과 별도로 관리합니다. 어떤 티켓을 처리 중인지, 어떤 정책을 적용하기로 했는지, 초안이 존재하는지, 전송이 승인되었는지를 상태에 담아야 합니다. 대화 기록은 그 상태에 이른 과정을 설명합니다. 길어지는 대화에서 모델이 매번 이 정보를 모두 추론하게 하면 작업을 감독하기 어려워집니다.

반복형 에이전트는 고정 워크플로와 무엇이 다릅니까?

반복형 에이전트는 최신 결과에 따라 다음 행동을 선택할 수 있습니다. 고정 워크플로는 티켓 조회, 정책 조회, 초안 작성이라는 순서를 이미 알고 있습니다. 앞선 행동에서 알아낸 내용에 따라 다음으로 유용한 행동이 달라진다면 적응형 루프를 사용합니다. 그런 불확실성이 없다면 정해진 순서대로 실행하면 됩니다.

ReAct 에이전트 루프는 어디에 해당합니까?

ReAct 에이전트 루프는 추론과 행동을 연결합니다. 모델은 관찰 결과를 바탕으로 이후 행동을 결정합니다. ReAct 원본 프로젝트는 환경 안에서 추론과 행동을 번갈아 수행하는 방식을 설명합니다. 애플리케이션을 모니터링할 때는 요청한 행동, 관찰 결과, 최종 성과를 기록합니다. 진행 상황을 설명하는 문장이 실행 확인 기록을 대신할 수는 없습니다.

운영 환경에 필요한 종료 조건 세 가지

루프를 빠져나올 경로를 세 가지로 설계합니다. 작업 완료, 한도 소진, 사람의 입력 필요입니다. 이는 엔지니어링 관점의 분류이지, 모든 SDK가 동일한 스위치 세 개를 제공한다는 뜻은 아닙니다. 비정상 종료, 취소, 복구할 수 없는 오류에도 명시적인 실패 처리가 필요합니다.

작업이 완료되면 종료합니다

첫 모델 호출 전에 무엇을 완료로 볼지 정의합니다. 초안 작성 도우미라면 관련 출처를 명시한 유효한 초안이 완료 조건일 수 있습니다. 실제 행동을 수행하는 도우미라면 쓰기 작업이 확인되었다는 기록까지 필요할 수 있습니다.

“모델이 더 이상 툴을 요청하지 않는다”와 “요청한 작업이 성공했다”는 구분해야 합니다. 전자는 런타임 신호이고, 후자는 작업에 맞는 증거가 있어야 판단할 수 있습니다. 모델은 더 진행할 수 없어서 멈출 수도 있습니다. 이때 애플리케이션은 작업을 성공으로 표시하지 말고, 진행 불가 또는 미완료로 기록해야 합니다.

답변 검증에 실패할 때마다 루프를 자동으로 재가동하지 않습니다. 수정 시도도 같은 작업에 배정된 한도를 사용해야 합니다. 그렇지 않으면 검증기 자체가 끝없는 재시도의 원인이 될 수 있습니다.

한도에 도달하면 종료합니다

단계 수, 자원 사용량, 경과 시간에 각각 독립적인 한도를 둡니다. 단계 수 제한은 반복을 제어하고, 토큰 또는 비용 예산은 자원 소비를 제어합니다. 마감 시간은 느린 모델이나 툴 때문에 작업이 무기한 열린 상태로 남는 것을 막습니다. 어느 하나가 다른 것을 대신할 수는 없습니다.

새 작업을 허용하기 전에 한도를 확인하고, 작업이 끝나면 사용량을 갱신합니다. 완료된 호출 수만 세어서는 이미 실행 중인 요청의 자원 소비를 막을 수 없습니다. 애플리케이션이 엄격한 상한을 보장한다면 다음 작업에 필요한 용량을 미리 확보하고, 시작 전에 동시 실행 중인 작업도 계산에 포함해야 합니다.

한도는 SDK 호출 한 번이 아니라 업무 전체를 기준으로 설정합니다. 재시도, 승인 후 재개, 하위 에이전트 실행 때문에 한도가 조용히 새로 부여되어서는 안 됩니다. 추가 작업이 타당하다면 애플리케이션이 명시적으로 판단해 한도를 늘립니다.

휴먼 인 더 루프: 행동에 앞서 승인을 기다립니다

사람이 판단 과정에 참여하는 AI 에이전트는 승인이 필요한 작업을 실행하기 전에 일시 중지해야 합니다. 실행하려는 행동, 대상, 관련 인수를 보여줍니다. 대기 중인 호출과 현재 작업 상태를 저장한 뒤 명시적인 결정을 기다립니다.

티켓 도우미에서는 특정 수신자에게 보낼 특정 답변을 승인합니다. 초안 하나를 승인했다고 이후 메시지까지 포괄적으로 허용해서는 안 됩니다. 승인 후 모델이 수신자나 내용을 바꾸면 해당 행동을 다시 검토해야 합니다.

일시 중지는 completed가 아니라 awaiting_approval로 기록합니다. 승인이 거절되면 미리 정한 대안으로 진행하거나 멈춰야 합니다. 같은 작업을 다른 툴로 실행하려는 시도를 반복해서는 안 됩니다. 승인 대기열과 에스컬레이션은 휴먼 인 더 루프 가이드에서 다룹니다.

AI 에이전트 구현을 위한 최소 루프 의사 코드

각 작업의 앞뒤에 정책 검사를 배치하면 루프를 간결하게 유지할 수 있습니다. 다음은 실행 가능한 SDK 코드가 아닌 의사 코드입니다. 모델 호출 8회라는 상한은 애플리케이션이 선택할 수 있는 예시일 뿐입니다. 실제 한도는 작업의 특성과 관찰한 실행 기록을 바탕으로 정해야 합니다.

state = new_job(task, max_model_calls=8, budget, deadline)

while true:
    if limit_reached(state):
        return stop("limit", partial_result=state)

    reserve_capacity_or_stop(state, next_model_call)
    response = call_model_with_deadline(state)
    record_model_call_usage_and_response(state, response)

    if response.is_final and not response.tool_calls:
        return validate_and_finish_or_stop_incomplete(response, state)

    if not response.tool_calls:
        return stop("no_action", partial_result=state)

    for index, call in enumerate(response.tool_calls):
        decision = validate_and_authorize(call, state)
        if decision == "denied":
            return stop("denied", partial_result=state)
        if decision == "needs_human":
            return pause_and_save(state, response.tool_calls[index:])

        reserve_capacity_or_stop(state, call)
        observation = execute_with_timeout_and_retry_cap(call)
        record_tool_usage(state, observation)
        append_matching_tool_result(state, call, bounded(observation))

    if no_progress(state):
        return stop("stalled", partial_result=state)

보조 함수의 이름에는 중요한 구현 책임이 담겨 있습니다. 용량을 확보할 때는 이미 진행 중인 작업을 계산에 넣어야 합니다. 툴 재시도에는 한도가 있어야 합니다. 시간 초과로 쓰기 결과를 알 수 없다면 재시도 전에 멈추거나 실제 처리 상태를 확인해 맞춰야 합니다. 치명적인 모델 오류나 툴 오류가 발생하면 실패를 기록하고 종료해야 하며, 그대로 다음 반복으로 넘어가서는 안 됩니다.

일시 중지 상태를 저장할 때는 남은 툴 호출, 완료된 결과, 이미 사용한 한도를 함께 보존해야 합니다. 재개할 때는 저장한 작업을 이어가되 권한과 한도를 다시 확인합니다. 처음부터 전체 작업을 다시 시작하면 앞서 발생한 변경이나 행동을 반복할 수 있습니다.

검사 위치에 주목할 필요가 있습니다. 승인은 툴 실행 전에 확인하고, 사용량은 작업 완료 후 기록합니다. 모델이 요청했다는 이유만으로 다음 반복을 시작할 수는 없습니다.

프레임워크별 루프 제어 방식

OpenAI Agents SDK, Claude Agent SDK, Vercel AI SDK, LangGraph는 루프를 서로 다른 방식으로 제공합니다. 옵션 이름을 비교하기 전에 무엇을 세는지, 어느 시점에서 멈추는지부터 비교해야 합니다.

이 이름들은 각각 OpenAI 루프 문서, Claude 루프 문서, Vercel 루프 문서, LangGraph Graph API를 따릅니다. 승인 동작에 관한 문서는 아래 각 절에 연결했습니다.

OpenAI Agents SDK: 실행을 이어가는 주체는 Runner입니다

OpenAI Agents SDK에서는 Runner가 모델을 호출하고, 요청된 툴을 실행하고, 결과를 추가한 뒤 실행을 이어갑니다. 핸드오프가 발생하면 활성 에이전트를 바꾸고 실행을 계속합니다. 문서상 정상 종료는 툴 호출 없이 예상한 타입의 출력이 나오는 경우입니다. max_turns를 초과하면 별도로 처리하지 않는 한 MaxTurnsExceeded가 발생합니다. OpenAI 에이전트 실행 문서.

티켓 도우미에서는 이 구조를 통해 모델 턴 수에 간단히 상한을 둘 수 있습니다. 다만 실행이 끝난 것과 실제 업무가 완료된 것은 다릅니다. 출력이 충족해야 할 조건을 설정하고, 해당 작업에 필요한 증거를 확인해야 합니다.

승인이 필요하면 Python 툴에 needs_approval을 선언할 수 있으며, 대기 중인 호출은 interruptions에 나타납니다. RunState를 저장하고 승인 또는 거절 결정을 반영한 뒤 재개합니다. 일시 중지된 실행은 새로운 사용자 요청이 아닙니다. OpenAI 휴먼 인 더 루프 문서.

Claude 에이전트 루프: 턴 수와 비용 한도를 함께 설정합니다

Claude Agent SDK는 파일 및 명령 툴을 포함해 Claude Code를 구동하는 루프를 내장합니다. maxTurns는 툴 사용 턴을 세고, maxBudgetUsd는 예상 비용의 임계값을 설정합니다. 설정하지 않으면 둘 다 무제한입니다. Python에서는 max_turns와 max_budget_usd를 사용합니다. Claude 에이전트 루프 문서.

결과의 하위 유형을 확인해야 합니다. success, error_max_turns, error_max_budget_usd는 서로 다른 결과입니다. 단일 실행 모드에서는 오류 결과 뒤에 예외가 발생하므로 결과와 실패 경로를 모두 처리해야 합니다. Claude 결과 처리.

권한 경계도 같은 수준으로 주의해야 합니다. allowedTools는 목록에 있는 툴을 자동 승인합니다. 목록에서 빠졌다고 해당 툴이 제거되는 것은 아닙니다. 기본 권한 모드에서는 승인이 필요하면서 어떤 허용 규칙에도 해당하지 않는 호출이 canUseTool로 전달됩니다. 이 SDK로 사람의 개입 없이 쓰기 작업을 수행하려면 먼저 전체 권한 정책을 확인해야 합니다. Claude 권한.

하위 에이전트까지 사용량을 계산할 때 Claude는 메인 루프의 usage와 전체 에이전트 트리의 modelUsage, 또는 Python의 model_usage를 구분합니다. 작업의 자원 소비를 조사할 때는 목적에 맞는 합계를 사용합니다. Claude 비용 및 사용량 문서.

구현 과정을 따라가려면 이 사이트의 Claude Agent SDK 가이드부터 읽어보면 됩니다.

Vercel AI SDK: stopWhen은 다음 단계로 진행할지를 제어합니다

Vercel AI SDK에서는 stopWhen으로 실행을 계속할지 제어합니다. 현재 문서는 단계 수 제한에 isStepCount를 사용하며, 여러 조건을 지정해 어느 하나라도 충족하면 중단할 수 있도록 합니다. ToolLoopAgent의 기본값은 20단계이고, generateText와 streamText의 기본값은 한 번의 생성입니다. 어떤 진입점을 사용하는지가 중요합니다. Vercel 루프 제어, 툴 호출 문서.

한 단계에는 생성과 그에 수반되는 로컬 툴 실행이 포함됩니다. 핵심은 마지막 단계에 툴 결과가 있을 때 stopWhen을 평가한다는 점입니다. 이미 그 결과를 만들어낸 툴 작업을 되돌릴 수는 없습니다. 따라서 이는 행동 전 승인 장치가 아니라 실행을 계속할지 결정하는 장치입니다. Vercel 다단계 호출.

사용자의 명시적인 승인에는 문서에 설명된 toolApproval을 사용합니다. 현재 문서에서 이전 툴 속성인 needsApproval은 사용 중단 예정으로 표시되어 있습니다. Vercel 툴 승인.

컨텍스트를 관리하는 prepareStep은 각 단계 전에 실행되며 메시지나 설정을 바꿀 수 있습니다. 이 시점을 활용해 매번 모든 원본 결과를 전달하는 대신 관련 상태를 제공할 수 있습니다. Vercel prepareStep.

LangGraph와 LangChain 에이전트 루프

LangGraph는 그래프 런타임입니다. 작업을 수행하는 노드를, 다음 실행 대상을 결정하는 엣지로 연결합니다. 그래프로 LangChain 에이전트 루프를 구성한다면 모델로 돌아가는 경로와 END로 향하는 경로를 명확히 지정합니다. Python의 recursion_limit는 그래프의 슈퍼스텝 수를 제한하며, 병렬 노드들은 하나의 슈퍼스텝을 공유합니다. 툴 호출 횟수를 세는 옵션이 아닙니다. LangGraph Graph API.

recursion_limit는 configurable 내부가 아니라 호출 설정의 최상위 수준에 둡니다. 한도에 도달하면 GraphRecursionError가 발생합니다. 정상적인 완료 경로는 대체로 이 비상 종료 지점에 닿기 전에 끝나도록 설계해야 합니다. LangGraph 재귀 한도.

사람의 검토가 필요할 때는 interrupt()로 그래프를 일시 중지합니다. 체크포인터와 유지되는 thread_id를 사용하고, Command(resume=...)로 재개합니다. 이때 중요한 제약이 있습니다. 재개하면 중단되었던 노드의 처음부터 다시 실행합니다. 중단 지점 앞의 코드도 다시 실행될 수 있습니다. 외부에 영향을 주는 작업은 승인 뒤에 배치하거나, 반복 실행해도 추가 효과가 발생하지 않는 멱등성을 갖추도록 만듭니다. LangGraph 중단.

분기와 재개 가능한 상태가 작업의 핵심이라면 이런 명시적인 그래프 구조를 선택합니다. 단순한 툴 순환으로 동작하는 첫 읽기 전용 도우미라면 요구사항을 충족하는 가장 작은 런타임부터 시작합니다.

실행이 40단계까지 이어지는 이유

상한을 늘리기 전에 단계 사이에 무엇이 달라졌는지 진단합니다. 오래 실행되는 동안 유용한 작업이 진행되고 있을 수도 있고, 같은 실패를 반복할 수도 있으며, 재시작하면서 이미 완료한 일을 잊었을 수도 있습니다. 숫자만으로는 이 경우들을 구분할 수 없습니다.

무한 루프: 새로운 근거 없이 같은 행동을 반복합니다

티켓 에이전트가 정책을 검색하고 빈 결과를 받은 뒤 같은 검색을 반복할 수 있습니다. 다음 관찰에서 새로 얻은 정보가 없으므로 다음 판단도 같은 행동으로 이어질 수 있습니다.

툴 이름과 인수를 정규화해 기록하고, 결과를 식별할 수 있는 지문과 작업 진척도를 나타내는 지표도 남깁니다. 상태 변화 없이 반복되면 진행 정체 여부를 검사해야 합니다. 정상적인 폴링도 같은 호출을 반복할 수 있으므로, 모든 중복을 오류로 취급하기보다 폴링에 별도의 한도 정책을 둡니다.

재시도 전에 무엇이든 바꿔야 합니다. 검색어, 누락된 식별자, 사용할 데이터 소스, 작업 범위 등이 대상입니다. 유의미하게 바꿀 수 있는 것이 없다면 해결되지 않은 요구사항을 반환하거나 도움을 요청합니다. “다시 시도”만으로는 복구 전략이 되지 않습니다.

툴 오류: 복구 가능한 실패와 결과를 모르는 상태를 구분합니다

형식이 잘못된 인수, 권한 거부, 일시적인 서비스 장애는 각각 다르게 대응해야 합니다. 모델이 다음 행동을 결정할 수 있도록 간결한 오류를 반환합니다. 복구 가능한 오류의 재시도에는 한도를 두고, 해당 작업의 권한 안에서 해결할 수 없는 오류라면 즉시 멈춥니다.

쓰기 중 발생한 시간 초과는 더 까다롭습니다. 응답이 도착하지 않았어도 쓰기는 성공했을 수 있습니다. 고객 메시지를 다시 보내거나 레코드를 또 만들기 전에 작업 상태를 조회하거나 멱등성 키를 사용합니다. 멱등성 키는 서비스가 동일한 의도의 작업임을 알아볼 수 있도록 유지하는 식별자입니다.

복구 과정에서도 성공한 작업은 보존합니다. 티켓 읽기는 성공하고 정책 조회만 실패했다면 전체 작업을 다시 실행할수록 불필요한 일이 늘어나며, 이미 발생한 변경이나 행동을 반복할 수 있습니다.

컨텍스트 증가: 모든 원본 대신 결정 사항을 유지합니다

각 관찰 결과는 다음 모델 호출에서 작업 지침 및 앞서 확보한 근거와 모델의 주의를 나눠 갖습니다. 큰 툴 응답은 기술적으로 유효하더라도 다음 판단의 초점을 흐릴 수 있습니다.

툴 출력의 크기에 한도를 두고, 큰 산출물은 프롬프트 밖에 저장하며, 다시 조회할 수 있는 참조를 포함한 간결한 결과를 반환합니다. 확정한 제약 조건, 승인, 확인된 행동은 영속적인 애플리케이션 상태에 보관합니다. 요약문으로 이 기록을 설명할 수는 있어도, 요약문이 유일한 사본이 되어서는 안 됩니다.

Claude SDK 문서는 컨텍스트 한도 부근에서 자동 압축이 수행된다고 설명하며, 요약 과정에서 초기 지침이 사라질 수 있다고 경고합니다. 중요한 상태를 의도적으로 보존해야 하는 이유입니다. Claude 컨텍스트 압축. 컨텍스트 품질 저하 설명에서는 컨텍스트 윈도 안에 들어간다고 필요한 정보를 잘 떠올릴 수 있는 것은 아닌 이유를 다룹니다.

실행 기록으로 운영자의 질문에 답할 수 있어야 합니다

각 작업에는 식별자, 모델 호출 횟수, 툴 실행 시도, 사용량, 경과 시간, 대기 중인 승인, 종료 사유를 기록합니다. 각 실행에는 무엇을 요청했고, 무엇이 완료되었으며, 작업 상태가 바뀌었는지를 기록합니다.

모델 요청, 툴 실행, 런타임 단계의 카운터를 따로 유지합니다. 대시보드에 단위 없이 “40단계”라고만 표시하면 실행 내용을 설명할 수 없습니다. 하위 작업과 재시도도 상위 작업의 사용량 계산에 포함합니다. 에이전트 사이로 작업이 넘어갈 때의 책임 소재는 AI 에이전트 오케스트레이션 가이드에서 설명합니다.

에이전트 루프에 대한 과도한 기대는 무엇입니까?

반복 횟수가 많다고 진척이 크다는 뜻은 아닙니다. 루프는 피드백을 활용할 기회를 반복해서 제공합니다. 그 반복이 유용한지는 피드백의 품질과 성공을 어떻게 정의했는지에 달려 있습니다.

모델이 “완료”라고 말하면 상호작용에서 자신의 역할을 끝낸 것입니다. 단계 수 상한이 있다는 것은 실행에 한도가 있었음을 보여줍니다. 어느 쪽도 고객 지원 답변이 정확하다거나 요청한 변경이 실제로 이루어졌다는 증거는 아닙니다.

프레임워크를 사용해도 권한, 상태 보존, 복구 방식을 정의해야 합니다. 프레임워크는 실행 수단을 제공합니다. 무엇을 성공으로 보고 어떤 행동을 허용할지는 애플리케이션이 정합니다.

에이전트 테스트 루프는 별도의 작업입니다

에이전트 테스트 루프는 사례와 수용 기준에 비추어 동작을 평가합니다. 실행 루프 바깥에 검사기를 두어 결과를 승인하거나, 다시 시도하도록 피드백을 보낼 수 있습니다. LangChain의 루프 엔지니어링 설명은 실행, 검증, 이벤트로 시작되는 작업을 구분합니다.

검사기에도 한도가 필요합니다. 다른 모델에게 답변의 품질을 반복해서 물으면 결정적인 증거는 얻지 못한 채 한도만 소모할 수 있습니다. 가능하면 구체적인 검사 방식을 우선합니다. 필수 필드가 있는지, 인용한 레코드가 일치하는지, 쓰기 확인 기록이 존재하는지, 예상한 테스트가 통과하는지 등을 확인합니다.

개발자와 운영자가 다음으로 할 일

첫 에이전트를 만드는 개발자: 범위가 좁은 읽기 전용 작업, 명시적인 완료 조건, 한도가 있는 실행부터 시작합니다. 제안한 행동을 보여주고, 권한을 강제하며, 결과가 불분명한 상황에서 복구할 수 있을 때 쓰기 기능을 추가합니다. 실행 순서를 이미 알고 있다면 고정 워크플로만으로 충분할 수 있습니다.

비용이 많이 든 실행을 조사하는 운영자: 모델을 바꾸거나 한도를 높이기 전에 반복 호출, 연쇄 재시도, 점점 커지는 관찰 결과를 살펴봅니다. 어느 단계가 유용한 근거를 더했는지, 실제로 어떤 카운터가 작업을 멈췄는지 확인합니다.

신뢰할 만한 고정 워크플로를 갖춘 팀: 상황에 따라 툴을 선택하는 방식이 구체적인 문제를 해결해줄 때까지 기존 워크플로를 유지합니다. 중간 결과가 다음 행동을 결정할 때 루프의 가치가 생깁니다. 반복 자체는 다시 구축할 이유가 아닙니다.

다음 업무일에 바로 해볼 일은 이렇습니다. 대표 작업 하나를 골라 완료 경로, 한도 도달에 따른 종료, 승인 대기, 행동 거부, 툴 실패 경로를 실행해 봅니다. 각 경로가 분명한 상태를 남기는지, 재개할 때 완료한 작업과 남은 한도가 모두 유지되는지 확인합니다.

에이전트 루프 자주 묻는 질문

AI 시스템을 만들고 운영하는 실용적인 가이드를 받아보려면 뉴스레터를 구독하세요.