다음을 통해 공유

디버깅 지침

  • 아티클

적용 대상: SDK v4

봇은 여러 부분이 함께 작동하는 복잡한 앱입니다. 다른 복잡한 앱과 마찬가지로 이로 인해 몇 가지 흥미로운 버그가 발생하거나 봇이 예상과 다르게 동작할 수 있습니다.

디버깅하면 봇이 때로는 어려운 작업이 될 수 있습니다. 모든 개발자는 해당 작업을 수행하는 고유한 기본 방법을 가지고 있습니다. 아래 지침은 대부분의 봇에 적용되는 제안입니다.

봇이 작동하는지 확인한 후 다음 단계는 봇을 채널에 연결하는 것입니다. 이렇게 하려면 스테이징 서버에 봇을 배포하고 봇이 연결할 고유한 직접 회선 클라이언트를 만들 수 있습니다. 자세한 내용은 Direct Line에 봇 연결을 참조 하세요.

고유한 클라이언트를 만들면 채널의 내부 작업을 정의하고 봇이 특정 활동 교환에 응답하는 방법을 테스트할 수 있습니다. 클라이언트에 연결되면 테스트를 실행하여 봇 상태를 설정하고 기능을 확인합니다. 봇이 음성 같은 기능을 사용하는 경우, 이러한 채널을 사용하면 해당 기능을 확인할 수 있습니다.

참고 항목

Azure에 봇을 배포할 때 웹 채팅 채널은 기본적으로 프로비전됩니다.

여기에서 Bot Framework Emulator와 Azure Portal을 통한 웹 채팅 모두 사용하면 다른 채널과 상호 작용하면서 봇이 수행하는 방식에 대한 추가 인사이트를 제공할 수 있습니다.

봇 디버깅은 중단점을 설정하거나 바로 실행 창과 같은 기능을 사용할 수 있는 다른 다중 스레드 앱과 유사하게 작동합니다.

봇은 이벤트 기반 프로그래밍 패러다임을 따르므로, 이 패러다임에 익숙하지 않을 경우 합리적으로 생각하기 어려울 수 있습니다. 봇이 상태 비스테이티브, 다중 스레드 및 비동기/대기 호출을 처리한다는 생각은 예기치 않은 버그를 초래할 수 있습니다. 봇 디버깅은 다른 다중 스레드 앱과 유사하게 작동하지만 도움이 되는 몇 가지 제안, 도구 및 리소스를 다룹니다.

에뮬레이터를 사용하여 봇 활동 이해

봇은 일반 메시지 활동 외에 다양한 유형의 활동을 처리합니다. 이러한 활동을 이해하면 봇을 효율적으로 코딩하는 데 도움이 되며 봇이 보내고 받는 활동이 예상과 다른지 확인할 수 있습니다. 에뮬레이터를 사용하면 해당 활동이 무엇인지, 언제 발생하는지, 어떤 정보가 포함되는지 알 수 있습니다. 자세한 내용은 에뮬레이터를 사용하여 디버그를 참조 하세요.

기록을 통해 사용자 상호 작용 저장 및 검색

Azure Blob 기록 스토리지는 사용자 및 봇 간의 상호 작용을 포함하는 기록을 저장 및 검색을 모두 할 수 있는 특수화된 리소스를 제공합니다.

또한 사용자 입력 상호 작용이 저장되면 Azure의 "스토리지 탐색기"를 사용하여 Blob 기록 저장소 내에 저장된 대본에 포함된 데이터를 수동으로 볼 수 있습니다. 다음 예제에서는 "mynewtestblobstorage"에 대한 설정에서 "스토리지 탐색기"를 엽니다. 저장된 사용자 입력을 열려면 다음을 선택합니다. Blob Container > ChannelId > TranscriptId > ConversationId

Blob 기록 저장소에 저장된 기록 항목의 예입니다.

그러면 저장된 사용자 대화 입력이 JSON 형식으로 열립니다. 사용자 입력은 "text:" 키와 함께 유지됩니다. 봇 대본 파일을 만들고 사용하는 방법에 대한 자세한 내용은 대본 파일을 사용하여 봇 디버그를 참조하세요.

미들웨어의 작동 방식

미들웨어 는 처음 사용하려고 할 때, 특히 실행의 연속 또는 단락과 관련하여 직관적이지 않을 수 있습니다. 미들웨어는 실행이 봇 논리에 전달될 때 대리자를 호출 next() 하여 턴의 선행 또는 후행 가장자리에서 실행할 수 있습니다.

여러 미들웨어를 사용하고 파이프라인의 방향이 맞는 경우 대리자는 다른 미들웨어 부분에 실행을 전달할 수 있습니다. 봇 미들웨어 파이프라인에 대한 세부 정보를 사용하여 아이디어를 더 분명하게 만들 수 있습니다.

대리자가 next() 호출되지 않으면 이를 단락 라우팅이라고 합니다. 이는 미들웨어가 현재 작업을 충족하고 실행을 전달할 필요가 없다고 판단할 때 발생합니다.

미들웨어 단락이 파이프라인에서 가장 먼저 나올 미들웨어 부분을 나타내는 데 도움이 될 수 있는 시기와 이유를 이해합니다. 또한 SDK 또는 다른 개발자가 제공하는 기본 제공 미들웨어에 대해 무엇을 기대해야 하는지 이해하는 것이 중요합니다. 미들웨어를 자세히 살펴보기 전에 먼저 고유한 미들웨어를 만들어 테스트해 보는 것이 유용할 수 있습니다.

검사 미들웨어를 사용하여 봇을 디버그하는 방법에 대한 자세한 내용은 검사 미들웨어를 사용하여 봇 디버그를 참조하세요.

상태 이해

상태 추적은, 특히 복잡한 작업의 경우, 봇의 중요한 부분입니다. 일반적으로 가장 좋은 방법은 가능한 한 빨리 작업을 처리하고 상태가 유지되도록 처리를 완료하는 것입니다. 활동을 거의 동시에 봇에 보낼 수 있으며 비동기 아키텍처로 인해 혼란스러운 버그가 발생할 수 있습니다.

가장 중요한 것은 상태가 예상대로 지속되는지 확인하는 것입니다. 지속된 상태의 위치에 따라 Cosmos DB 및 Azure Table Storage용 스토리지 에뮬레이터를 사용하면 프로덕션 스토리지를 사용하기 전에 해당 상태를 확인할 수 있습니다.

Important

Cosmos DB 스토리지 클래스는 더 이상 사용되지 않습니다. 원래 CosmosDbStorage를 사용하여 만든 컨테이너에는 파티션 키 집합이 없으며 _/partitionKey의 기본 파티션 키가 지정되었습니다.

Cosmos DB 스토리지로 만든 컨테이너는 Cosmos DB 분할 스토리지와 함께 사용할 수 있습니다. 자세한 내용은 Azure Cosmos DB 분할을 읽어보세요.

또한 레거시 Cosmos DB 스토리지와 달리 Cosmos DB 분할된 스토리지는 Cosmos DB 계정 내에서 데이터베이스를 자동으로 만들지 않습니다. 새 데이터베이스를 수동으로 만들어야 하지만 CosmosDbPartitionedStorage에서 컨테이너를 만들므로 컨테이너를 수동으로 만드는 작업은 건너뜁니다.

활동 처리기를 사용하는 방법

특히 각 활동이 독립적인 스레드(또는 사용자의 언어에 따라 웹 작업자)에서 실행되므로 활동 처리기는 또 다른 계층의 복잡성을 도입할 수 있습니다. 처리기가 수행하는 동작에 따라 현재 상태가 예상과 다른 문제가 발생할 수 있습니다.

기본 제공 상태는 턴의 끝에 기록되지만 해당 턴에 의해 생성된 모든 활동은 턴 파이프라인과 독립적으로 실행됩니다. 대부분 이는 별다른 영향이 없지만 활동 처리기가 상태를 변경하는 경우에는 해당 변경을 포함하는 상태가 기록되어야 합니다. 이 경우, 회전 파이프라인은 완료하기 전에 처리를 마칠 때까지 활동에서 대기할 수 있으므로 해당 회전에 대한 올바른 상태가 기록됩니다.

활동 보내기 메서드와 해당 처리기에는 고유한 문제를 일으킵니다. 활동 보내기 시 처리기 내에서 활동 보내기를 호출하기만 하면 스레드가 무한히 포크됩니다. 보내는 정보에 추가 메시지를 추가하거나 봇의 충돌을 방지하기 위해 콘솔 또는 파일과 같은 다른 위치에 쓰는 등 이러한 문제를 해결할 수 있는 방법이 있습니다.

프로덕션 봇 디버깅

봇이 프로덕션 환경에 있는 경우 Dev Tunnels를 사용하여 모든 채널에서 봇을 디버그할 수 있습니다. 여러 채널에 대한 봇의 원활한 연결은 Bot Framework에서 사용할 수 있는 주요 기능입니다. 자세한 내용은 devtunnel을 사용하여 모든 채널에서 봇 디버그 및 기술 또는 기술 소비자 디버그를 참조하세요.

다음 단계

봇을 단위 테스트하는 방법

추가 리소스