디버깅 지침

  • 아티클

적용 대상: SDK v4

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

경우에 따라 봇 디버깅이 어려울 수도 있습니다. 모든 개발자는 원하는 방식으로 해당 작업을 수행할 수 있습니다. 아래 지침은 대부분의 봇에 적용되는 제안입니다.

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

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

참고

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

여기에서 Azure Portal 통해 Bot Framework Emulator 및 웹 채팅 모두 사용하면 다른 채널과 상호 작용하면서 봇의 성능에 대한 추가 인사이트를 제공할 수 있습니다.

봇 디버그는 중단점을 설정하는 기능이나 직접 실행 창 같은 기능을 통해 다중 스레드 앱과 비슷하게 이루어집니다.

봇은 이벤트 기반 프로그래밍 패러다임을 따르므로, 이 패러다임에 익숙하지 않을 경우 합리적으로 생각하기 어려울 수 있습니다. 봇이 상태 비저장, 다중 스레드로 설정되고 async/await 호출을 처리하면 예기치 않은 버그가 발생할 수 있습니다. 봇 디버그는 다른 다중 스레드 앱과 비슷하게 작동하지만 도움이 되는 몇 가지 제안 사항, 도구 및 리소스를 살펴보겠습니다.

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

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

대본을 통해 사용자 상호 작용 저장 및 검색

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

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

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

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

미들웨어의 작동 방식

미들웨어는 처음 사용할 경우, 특히 실행의 연속 또는 단락 측면에서 사용하기 쉽지 않을 수 있습니다. 미들웨어는 실행이 봇 논리에 전달되는 시기를 지정하는 next() 대리자 호출을 통해 회전의 시작 또는 종료 시 실행될 수 있습니다.

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

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

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

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

상태 이해

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

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

중요

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

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

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

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

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

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

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

프로덕션 봇 디버깅

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

다음 단계

봇을 단위 테스트하는 방법

추가 리소스