Welcome to video number eight and our final video of the beginner course for n8n. In this video, we'll be covering how to debug workflows. So in the previous video, we talked about error handling, how sometimes workflows, when they are pushed to production, when they are activated, can encounter errors, and debugging is the process of fixing those errors and making sure that they don't uh happen again.

So let's start by talking a little bit about what debugging is and why it's an important skill uh to master.

So when workflows, or rather when specific nodes within a workflow, fail, it can be for many different reasons.

They can be configured wrong, the uh underlying service can be unavailable, for example. Um, if you are using Google Sheets or Slack, you might get a 500 error, meaning that the service is simply unavailable at the moment, or problems can be related to input data.

So let's say you're receiving a web hook, the web hook can be missing information causing the workflow or one of the specific nodes to fail.

By default, this stops the workflow from finishing its execution and it sets its status to failed.

From the execution history or execution log, we can find the list of all of the workflow executions that failed and then debug them one by one to make sure the errors don't happen again.

It is important to note that sometimes a workflow can fail from an automation standpoint without necessarily being tagged as failed, in the sense that if you are trying to automate a certain task, but no node had an error, then sometimes the task will not be automated and the workflow won't be tagged as an error.

So this is why error handling is extremely important uh to make sure that your workflows execute correctly and uh we'll be covering an example of this in just a minute the easiest way to debug your workflows is by using the debug in editor feature in n8n.

Um this is a super powerful feature that lets you pin data from an execution history into the current canvas of the workflow.

What this does is it effectively copies over whatever data was in or whatever items were in the failed execution and pins them into your current workflows editor so that then you can use this data to debug the same way that when we um used the pin feature in the web hook node uh a few videos ago.

This is the same thing, it allows you to PIN error data to uh your workflow canvas.

Pin data will have a blue or purple symbol in the bottom right corner, and workflows can only have one set of pinned data at a time, so you have to work through uh different types of bugs one by one uh making sure that um you are fixing them all and that by repairing some you aren't creating other bugs.

Once the error is fixed or handled, um we can use the retry feature to trigger again all of the failed executions.

This is a super useful feature because when um a workflow fails we might have five or 10 executions that were unsuccessful and from the execution log you can decide whether you want to retry with currently saved workflow or with the original workflow from the time of execution.

The retry is executed from the node with an error. Uh this means that if the error in your workflow comes from a wrongly configured node previous to the one with an error, you will have to use the copy to editor node to re-execute these because it only executes from the errored node.

Another useful feature when debugging is the edit output feature. The edit output feature lets you manually edit the output for a specific node while it can come in handy when testing or debugging workflows.

Um, specifically if you're using web hooks and you don't want to have to send uh many different kinds of test events um without requiring you to execute all of the past nodes and uh do all your transformations on the data.

Uh, it should be used sparingly as it is not a very scalable method. However, in cases where retrying is not possible, it can be a quick way to fix a backlog of a few executions.

Another very, very useful feature when debugging is the workflow version history.

So when making updates to workflows, error handling, or debugging, sometimes it happens we make mistakes and we can lose sight of where we started from.

Luckily, we have the version workflow version history. From here, you can see all of the previous versions of a given workflow that were saved. Uh, this can be useful if you need to revert some changes that were made to a workflow that might be causing bugs or to inspect the structure of a previous workflow version of the workflow.

Uh, this can be combined nicely with the retry feature if you need to revert to a previous version and then retry multiple executions with the currently saved version.

Let's jump into n8n and do two different examples of debugging a workflow. So here we are in n8n and uh we have this workflow that we're going to uh debug.

The first step of debugging any workflow is, well, first of all, understanding what the workflow is supposed to do when it executes properly.

So here we can see uh we have our execution logs, we have a successful execution, a failed execution, but let's first look at the successful execution to sort of figure out what the workflow does.

So here we can see we receive a web hook. In the web hook, we have an ID key with a specific identifier, then we get the user.

So this is another function of the Google Sheets. We're going to be uh getting rows, but specifically filtering on the ID column, and we're going to be uh looking pretty much for the row with the specific ID.

Uh, this returns all of the row information, uh, all of the information from the different columns in the sheet.

So we get an email, first name, last name, and a company, as well as the ID that was the same one as we filtered on.

And then we send a Slack message with info for the specific email, their first name, last name, and company.

Now we can look into the failed execution. Here we can see, uh, quickly by looking, uh, we have an error: 'Error cannot read properties of undefined reading to string.

' So clearly here it tried to read the body ID, and in uh the web hook we can see that this web hook did not have an ID.

So what we're going to do is we're going to click debugging editor to copy the data over, and we're going to deal with the different cases.

So first of all, we could say we could add an if and make sure that we have a valid uh ID.

So here we want the json.body.ID this time to exist, and if this is the case, then we can go up this path and get the user and send the Slack message.

Here there are multiple ways we could continue debugging message.

Either we could say if we don't have an ID, so here let me rename ID. If we don't have an ID, we could, for example, send a Slack message saying, um, 'Web hook received did not have ID,' uh, and that way we can look into it, but we could also be a bit smarter.

here and see the goal of this workflow is to look up a user in uh the specific database and here it's with the ID but we also saw by looking at the uh past execution that in the database we have an email, so instead of looking up the ID if we don't have an ID but we have an email, we could try looking up using the email.

So going back to the editor we have the case with a valid ID, then we could say we have the case where we have an email and this would be json.

And then all we would have to do is do the same actions. Instead of looking up the ID, we would be looking up the email json.

body.email and then we would send the same Slack message with the information from uh the contact. What we can do from here is then deal with the case where we have none of them.

This would be a great place to use the Stop and throw error um node here and a little message: no ID or email.

From here we have a fixed workflow, so first of all we can verify that with this error data it still works.

So I can test the workflow and as we can see here it didn't have an ID so it went down to the email field, it had a valid email, so it got the user and it sent the message.

In this specific case we wouldn't be able to retry this workflow because we made, we had to make the modifications before this um specific uh node.

Another case I'd like to cover is this execution.

What we can see here is we received the web hook, we tried to read the user and nothing happened here, no message was executed and what this is what I was mentioning earlier, where sometimes a workflow cannot fail but can also not be successful, and this is a very good example of this.

So what happened here? Well, clearly we tried to look up someone with an ID that we can see here in the input data, but no data was returned.

So something that we can do here is, again, this time it won't be debug in editor, but copy to editor because um it wasn't errored and what we can do this time is now deal with the case with this case.

So if we test the workflow, we can see that the updates we made still work with this execution, except we're still not getting the output we wanted.

So here something we can do is in this get user um sheet by heading over to the parameters, we can um set, sorry, by heading over to the settings, we can ask it to always output data, and this means that even if it doesn't find a contact here, we'll have um here we'll have the information of an empty item.

From here, before sending the Slack message, we can set an additional check. So here we could say, does the contact have an email?

So this would be by reading the information we would have here in slack json.email. If we have an email exists, then we send the Slack message.

Here we would have to do the same modifications, so copy this, put it here, we also check, and if we have a valid email, we send the message.

In the cases where we don't have a valid email, and so there was the lookup was unsuccessful, we could just uh drag a stop and throw error, contact not found in database, and this we can do it this way.

here we could sort of factor this a little bit better, seeing as all of these do the same thing, we could just use a single if and a single throw error by attaching this one here.

This way we have debugged the workflow and whether if we can't find the user next time we'll have an error.

Someone can hop in and deal with the case where we don't have a user. If this is usual, then we handle the case differently.

If it's not usual, we can figure out what's wrong. Thanks for listening to the eighth and final video of the n8n beginner course where we looked into debugging workflows and fixing failed executions.

In the advanced course, we'll be covering some much more advanced topics, advanced workflow building, complex data flow, those more advanced examples, as well as error handling and debugging.

Thanks for your attention, and for some of you, see you in the advanced course.

n8n Beginner Course (8/9) - Debugging

n8n 워크플로우 디버깅은 오류를 수정하고 재발을 방지하는 중요한 기술이며, 편집기 내 디버그 기능, 출력 편집, 워크플로우 버전 기록 등의 도구를 활용할 수 있습니다.

워크플로우 디버깅 시, 워크플로우가 제대로 실행될 때의 동작을 이해하고, 실패 원인을 분석하여 조건문 추가, 데이터 검증, 오류 처리 등의 방법으로 워크플로우를 수정해야 합니다.

재시도 기능은 실패한 실행을 다시 트리거하는 데 유용하지만, 오류의 원인이 되는 노드를 식별하고 필요한 경우 복사-편집 노드를 사용하여 재실행해야 합니다.

n8n 초급 과정의 8번째 비디오에서는 워크플로우 디버깅 방법을 다룹니다. 이전 비디오에서 오류 처리에 대해 다루었듯이, 프로덕션 환경에서 워크플로우가 활성화될 때 오류가 발생할 수 있으며, **디버깅은 이러한 오류를 수정하고 재발을 방지하는 필수적인 과정**입니다.

워크플로우 실패의 원인과 중요성

워크플로우 또는 특정 노드가 실패하는 데에는 여러 가지 이유가 있을 수 있습니다. 예를 들어, **잘못된 구성, 기본 서비스의 일시적인 사용 불가 (예: Google Sheets 또는 Slack의 500 오류), 또는 웹훅과 같은 입력 데이터의 누락된 정보** 등이 원인이 될 수 있습니다. 이러한 상황은 워크플로우가 실행을 완료하지 못하고 실패 상태가 되도록 만듭니다.

자동화 관점에서 볼 때, 워크플로우는 오류가 없지만 특정 작업이 자동화되지 않아 **실패로 태그되지 않고도 실패할 수 있습니다**. 따라서 오류 처리는 워크플로우의 올바른 실행을 보장하는 데 매우 중요합니다.

워크플로우를 디버깅하는 가장 쉬운 방법은 n8n 편집기 내의 **디버그 기능**을 사용하는 것입니다. 이 강력한 기능을 통해 실행 기록에서 현재 워크플로우 캔버스로 데이터를 고정할 수 있습니다. 실패한 실행의 데이터를 현재 편집기로 복사하여 고정함으로써, 이전 웹훅 노드에서 고정 기능을 사용했던 방식과 유사하게 이 데이터를 기반으로 디버깅할 수 있습니다.

고정된 데이터는 오른쪽 하단에 파란색 또는 보라색 기호로 표시되며, 워크플로우는 한 번에 하나의 고정된 데이터 세트만 가질 수 있습니다. 오류가 수정되면 **재시도 기능을 사용하여 실패한 모든 실행을 다시 트리거**할 수 있습니다. 이 기능은 워크플로우가 실패했을 때 여러 실행을 한 번에 처리할 수 있어 매우 유용합니다.

**출력 편집 기능**은 특정 노드의 출력을 수동으로 편집할 수 있게 하여, 워크플로우 테스트나 디버깅에 유용합니다. 특히 웹훅을 사용하고 다양한 테스트 이벤트를 보낼 필요가 없을 때 유용하며, 모든 과거 노드를 실행할 필요 없이 빠르게 백로그를 수정하는 방법이 될 수 있습니다.

디버깅 시 실수를 저지르고 시작점을 잃을 경우, **워크플로우 버전 기록**이 매우 유용합니다. 이 기능을 통해 저장된 워크플로우의 모든 이전 버전을 볼 수 있어, 버그를 유발하는 변경 사항을 되돌리거나 이전 버전의 구조를 검사할 수 있습니다. 이는 재시도 기능과 함께 사용하여 이전 버전으로 되돌린 후 여러 실행을 재시도할 때 특히 효과적입니다.

디버깅 실전 예시: 누락된 ID 및 사용자 조회 실패

디버깅의 첫 단계는 워크플로우가 **정상적으로 실행될 때의 동작을 이해하는 것**입니다. 성공적인 실행을 검토하여 웹훅 수신, ID 키를 통한 사용자 조회, Google Sheets에서 특정 ID로 행 필터링, 그리고 결과 데이터를 Slack 메시지로 전송하는 과정을 파악할 수 있습니다.

실패한 실행의 한 예는 '정의되지 않은 문자열을 읽을 수 없습니다'라는 오류입니다. 이는 웹훅에서 `body ID`를 읽으려 했으나 **웹훅에 ID가 누락되었기 때문에 발생**했습니다. 이 문제를 해결하기 위해 디버깅 편집기를 통해 데이터를 복사하고, 유효한 ID가 있는지 확인하는 `if` 문을 추가하여 워크플로우를 수정할 수 있습니다.

ID가 없는 경우, ID 대신 이메일을 사용하여 조회를 시도하는 등 **더 스마트한 오류 처리**를 구현할 수 있습니다. `.body.email`이 존재하는지 확인하고, 이메일을 통해 사용자를 조회한 후 동일한 Slack 메시지를 보냅니다. ID와 이메일 모두 없는 경우에는 Stop 노드를 사용하여 'ID 또는 이메일 없음' 오류를 발생시켜 워크플로우의 안정성을 높입니다.

또 다른 사례는 워크플로우가 실패로 태그되지 않았지만 원하는 작업을 수행하지 못한 경우입니다. 웹훅을 수신했으나 사용자 조회에서 **데이터가 반환되지 않아 메시지가 실행되지 않는 상황**이 발생했습니다. 이 문제는 Get User from Sheet 노드의 매개변수에서 '항상 데이터 출력' 설정을 활성화하여 해결할 수 있습니다. 이렇게 하면 연락처를 찾지 못하더라도 빈 항목 정보를 출력하여 다음 단계에서 처리할 수 있습니다.

Slack 메시지를 보내기 전에 **추가 검사를 설정하여 연락처에 이메일이 있는지 확인**합니다. 이메일이 유효한 경우에만 Slack 메시지를 보내고, 유효한 이메일이 없는 경우 (즉, 조회가 실패한 경우) Stop 노드를 사용하여 '데이터베이스에서 연락처를 찾을 수 없음'이라는 오류를 발생시킵니다. 이러한 수정으로 워크플로우는 사용자를 찾을 수 없을 때 오류를 발생시켜 문제를 명확히 하고, 잠재적인 데이터 불일치를 관리합니다.

이 비디오는 n8n 초급 과정의 마지막 부분으로, 워크플로우 디버깅 및 실패한 실행 수정 방법을 살펴보았습니다. 고급 과정에서는 **훨씬 더 복잡한 워크플로우 구축, 데이터 흐름 관리, 고급 예제, 그리고 심화된 오류 처리 및 디버깅 기법**을 다룰 예정입니다. 참여해 주셔서 감사합니다.

n8n에서 워크플로우 디버깅이 중요한 기술인 주요 이유는 무엇이며, 워크플로우 실패의 일반적인 원인은 무엇인가요?

n8n의 편집기 내 디버그 기능은 어떻게 작동하며, 실패한 실행 데이터를 현재 워크플로우 캔버스로 고정하는 과정은 무엇인가요?

디버깅 시 '재시도' 기능과 '출력 편집' 기능은 각각 어떤 상황에서 유용하며, 사용 시 주의해야 할 점은 무엇인가요?

워크플로우 버전 기록은 디버깅 과정에서 어떤 이점을 제공하며, 재시도 기능과 함께 어떻게 활용될 수 있나요?

제시된 예시 워크플로우에서 ID 또는 이메일이 없을 때 발생하는 오류를 처리하기 위해 어떤 방식의 조건부 로직과 노드 조합을 사용했나요?

n8n 초급 과정의 8번째이자 마지막 비디오에 오신 것을 환영합니다. 이번 비디오에서는 워크플로우 디버깅 방법에 대해 다룰 것입니다. 이전 비디오에서는 오류 처리에 대해 이야기했습니다. 워크플로우가 프로덕션 환경으로 푸시되어 활성화될 때 오류가 발생할 수 있으며, 디버깅은 이러한 오류를 수정하고 다시 발생하지 않도록 하는 프로세스입니다.

그럼 디버깅이 무엇인지, 왜 중요한 기술인지에 대해 이야기해 보겠습니다.

워크플로우, 더 정확히는 워크플로우 내의 특정 노드가 실패하는 데에는 여러 가지 이유가 있을 수 있습니다.

잘못 구성되었을 수도 있고, 기본 서비스가 사용 불가능할 수도 있습니다. 예를 들어 Google Sheets나 Slack을 사용하는 경우 500 오류가 발생할 수 있습니다. 이는 서비스가 현재 사용 불가능하거나 입력 데이터와 관련된 문제일 수 있음을 의미합니다.

예를 들어 웹 후크를 수신하는 경우 웹 후크에 정보가 누락되어 워크플로우 또는 특정 노드가 실패할 수 있습니다.

기본적으로 이렇게 되면 워크플로우가 실행을 완료하지 못하고 상태가 실패로 설정됩니다.

실행 기록 또는 실행 로그에서 실패한 모든 워크플로우 실행 목록을 찾은 다음, 오류가 다시 발생하지 않도록 하나씩 디버깅할 수 있습니다.

자동화 관점에서 워크플로우가 실패로 태그되지 않고 실패할 수 있다는 점에 유의하는 것이 중요합니다. 즉, 특정 작업을 자동화하려고 하지만 노드에 오류가 없는 경우 작업이 자동화되지 않고 워크플로우가 오류로 태그되지 않을 수 있습니다.

이것이 바로 오류 처리가 워크플로우가 올바르게 실행되도록 하는 데 매우 중요한 이유입니다. 이 예는 잠시 후에 다룰 것입니다. 워크플로우를 디버깅하는 가장 쉬운 방법은 n8n의 편집기 내 디버그 기능을 사용하는 것입니다.

이것은 실행 기록에서 현재 워크플로우 캔버스로 데이터를 고정할 수 있는 매우 강력한 기능입니다.

이렇게 하면 실패한 실행에 있던 데이터 또는 항목이 무엇이든 현재 워크플로우 편집기로 복사되어 고정됩니다. 따라서 몇 비디오 전에 웹 후크 노드에서 고정 기능을 사용했을 때와 같은 방식으로 이 데이터를 사용하여 디버깅할 수 있습니다.

이것은 오류 데이터를 워크플로우 캔버스에 고정할 수 있도록 하는 것과 같습니다.

고정된 데이터는 오른쪽 하단에 파란색 또는 보라색 기호가 표시되며, 워크플로는 한 번에 하나의 고정된 데이터 세트만 가질 수 있으므로, 다양한 유형의 버그를 하나씩 해결해야 합니다. 모든 버그를 수정하고 일부를 수정하여 다른 버그를 만들지 않도록 해야 합니다.

오류가 수정되거나 처리되면 재시도 기능을 사용하여 실패한 모든 실행을 다시 트리거할 수 있습니다.

이것은 매우 유용한 기능입니다. 워크플로가 실패하면 5개 또는 10개의 실행이 실패할 수 있으며, 실행 로그에서 현재 저장된 워크플로로 재시도할지 아니면 실행 당시의 원래 워크플로로 재시도할지 결정할 수 있습니다.

재시도는 오류가 있는 노드에서 실행됩니다. 즉, 워크플로의 오류가 오류가 있는 노드 이전의 잘못 구성된 노드에서 발생한 경우, 복사-편집기 노드를 사용하여 다시 실행해야 합니다. 왜냐하면 오류가 발생한 노드에서만 실행되기 때문입니다.

디버깅할 때 유용한 또 다른 기능은 출력 편집 기능입니다. 출력 편집 기능을 사용하면 특정 노드의 출력을 수동으로 편집할 수 있습니다. 이 기능은 워크플로를 테스트하거나 디버깅할 때 유용할 수 있습니다.

특히 웹훅을 사용하고 다양한 종류의 테스트 이벤트를 보낼 필요가 없는 경우, 과거 노드를 모두 실행하고 데이터에 대한 모든 변환을 수행할 필요 없이 말이죠.

확장성이 좋은 방법은 아니므로 드물게 사용해야 합니다. 그러나 재시도가 불가능한 경우, 몇 가지 실행의 백로그를 빠르게 수정하는 방법이 될 수 있습니다.

디버깅할 때 매우 유용한 또 다른 기능은 워크플로 버전 기록입니다.

워크플로 업데이트, 오류 처리 또는 디버깅을 할 때 실수를 저지르고 시작점을 잃을 수 있습니다.

다행히 워크플로 버전 기록이 있습니다. 여기에서 저장된 특정 워크플로의 이전 버전을 모두 볼 수 있습니다. 이는 버그를 일으킬 수 있는 워크플로에 대한 일부 변경 사항을 되돌리거나 이전 워크플로 버전의 구조를 검사해야 하는 경우에 유용할 수 있습니다.

이것은 이전 버전으로 되돌린 다음 현재 저장된 버전으로 여러 실행을 재시도해야 하는 경우 재시도 기능과 함께 사용할 수 있습니다.

n8n으로 들어가서 워크플로우 디버깅에 대한 두 가지 다른 예를 들어보겠습니다. 자, 여기 n8n에 있고, 어, 디버깅할 워크플로우가 있습니다.

모든 워크플로우 디버깅의 첫 번째 단계는, 워크플로우가 제대로 실행될 때 무엇을 해야 하는지 이해하는 것입니다.

여기서 실행 로그, 성공적인 실행, 실패한 실행이 있는 것을 볼 수 있지만, 먼저 성공적인 실행을 보고 워크플로우가 무엇을 하는지 파악해 보겠습니다.

여기서 웹훅을 받는 것을 볼 수 있습니다. 웹훅에는 특정 식별자가 있는 ID 키가 있습니다. 그런 다음 사용자를 가져옵니다.

이것은 Google Sheets의 또 다른 기능입니다. 행을 가져올 것이지만, 특히 ID 열에서 필터링하고 특정 ID가 있는 행을 찾을 것입니다.

어, 이것은 모든 행 정보, 어, 시트의 다른 열에서 가져온 모든 정보를 반환합니다.

이메일, 이름, 성, 회사와 필터링한 것과 동일한 ID를 가져옵니다.

그런 다음 특정 이메일, 이름, 성, 회사에 대한 정보가 포함된 Slack 메시지를 보냅니다.

이제 실패한 실행을 살펴볼 수 있습니다. 여기서 보면, 어, 오류가 있습니다. '정의되지 않은 문자열을 읽을 수 없습니다'라는 오류가 있습니다.

분명히 여기서 body ID를 읽으려고 시도했고, 어, 웹훅에서 이 웹훅에 ID가 없는 것을 볼 수 있습니다.

따라서 디버깅 편집기를 클릭하여 데이터를 복사하고 여러 가지 경우를 처리할 것입니다.

우선, 유효한 ID가 있는지 확인하기 위해 if 문을 추가할 수 있습니다.

여기서는 json.body.ID가 이번에 존재하는지 확인하고, 이 경우 이 경로를 따라 올라가서 사용자를 가져오고 Slack 메시지를 보낼 수 있습니다.

여기에는 디버깅 메시지를 계속할 수 있는 여러 가지 방법이 있습니다.

ID가 없는 경우를 생각해 볼 수 있습니다. ID 이름을 바꿔보겠습니다. ID가 없는 경우, 예를 들어 '웹훅이 ID 없이 수신되었습니다'라는 슬랙 메시지를 보내서 확인할 수 있습니다. 하지만 좀 더 스마트하게 처리할 수도 있습니다.

여기서 이 워크플로우의 목표는 특정 데이터베이스에서 사용자를 조회하는 것입니다. 여기서는 ID를 사용하지만, 과거 실행을 통해 데이터베이스에 이메일이 있다는 것을 확인했습니다. 따라서 ID가 없는 경우, ID 대신 이메일을 사용하여 조회를 시도할 수 있습니다.

편집기로 돌아가서 유효한 ID가 있는 경우를 처리하고, 이메일이 있는 경우를 처리할 수 있습니다. 이는 json.body.email이 존재하는 경우입니다.

json.body.email이 존재하는 경우입니다.

그런 다음 동일한 작업을 수행하면 됩니다. ID 대신 이메일 json.body.email을 조회하고, 연락처 정보를 사용하여 동일한 슬랙 메시지를 보냅니다. 여기서 ID와 이메일이 모두 없는 경우를 처리할 수 있습니다.

여기서 Stop 노드를 사용하여 오류를 발생시키는 것이 좋습니다. 'ID 또는 이메일 없음'이라는 메시지를 표시합니다.

여기서 수정된 워크플로우가 있습니다. 먼저 이 오류 데이터로 여전히 작동하는지 확인할 수 있습니다.

워크플로우를 테스트해 보면 ID가 없어서 이메일 필드로 이동했고, 유효한 이메일이 있어서 사용자를 가져와 메시지를 보낸 것을 확인할 수 있습니다.

이 특정 경우에는 이 특정 노드 이전에 수정해야 했기 때문에 이 워크플로우를 다시 시도할 수 없습니다.

또 다른 사례는 이 실행입니다.

여기서 웹훅을 수신했지만 사용자를 읽으려고 시도했지만 아무 일도 일어나지 않았고 메시지가 실행되지 않았습니다. 이것이 제가 앞서 언급한 워크플로우가 실패하지 않을 수도 있지만 성공하지 못할 수도 있다는 것입니다. 이것이 아주 좋은 예입니다.

여기서 무슨 일이 일어났을까요? 분명히 입력 데이터에서 볼 수 있는 ID로 누군가를 조회하려고 했지만 데이터가 반환되지 않았습니다.

여기서 할 수 있는 것은 이번에는 에디터에서 디버그하는 것이 아니라 에디터로 복사하는 것입니다. 왜냐하면 오류가 발생하지 않았고 이번에는 이 경우를 처리할 수 있기 때문입니다.

워크플로우를 테스트하면 업데이트가 이 실행에서도 여전히 작동하지만 원하는 출력을 얻지 못하고 있음을 알 수 있습니다.

여기서 할 수 있는 것은 이 사용자 가져오기 시트에서 매개변수로 이동하여 설정으로 이동하여 항상 데이터를 출력하도록 요청할 수 있습니다. 즉, 여기서 연락처를 찾지 못하더라도 여기에 빈 항목 정보가 있습니다.

여기에서 슬랙 메시지를 보내기 전에 추가 검사를 설정할 수 있습니다. 여기서 연락처에 이메일이 있는지 확인할 수 있습니다.

이것은 slack json.email에서 여기에서 얻을 수 있는 정보를 읽음으로써 가능합니다. 이메일이 있으면 슬랙 메시지를 보냅니다.

여기서도 동일한 수정을 해야 하므로 이것을 복사하여 여기에 넣고 확인합니다. 유효한 이메일이 있으면 메시지를 보냅니다.

유효한 이메일이 없는 경우, 즉 조회가 실패한 경우 중지하고 오류를 발생시켜 데이터베이스에서 연락처를 찾을 수 없다고 표시할 수 있습니다. 이렇게 할 수 있습니다.

여기서는 이것들을 좀 더 잘 정리할 수 있습니다. 이 모든 것이 동일한 작업을 수행하는 것을 감안할 때 단일 if와 단일 throw 오류를 사용하여 이것을 여기에 연결할 수 있습니다.

이렇게 하면 워크플로우를 디버깅했고 다음에 사용자를 찾을 수 없으면 오류가 발생합니다.

누군가가 뛰어들어 사용자가 없는 경우를 처리할 수 있습니다. 이것이 일반적이라면 다른 방식으로 처리합니다.

일반적이지 않다면 무엇이 잘못되었는지 알아낼 수 있습니다. 워크플로우 디버깅 및 실패한 실행 수정에 대해 살펴본 n8n 초급 과정의 8번째이자 마지막 비디오를 시청해 주셔서 감사합니다.

고급 과정에서는 훨씬 더 고급 주제, 고급 워크플로우 구축, 복잡한 데이터 흐름, 더 고급 예제는 물론 오류 처리 및 디버깅에 대해 다룰 것입니다.

관심 가져주셔서 감사합니다. 일부는 고급 과정에서 뵙겠습니다.

워크플로우 디버깅은 프로덕션 환경에서 발생할 수 있는 오류를 수정하고 재발 방지하는 과정입니다.

워크플로우 노드가 실패하는 이유는 잘못된 구성, 서비스 불가능(예: Google Sheets, Slack 500 오류), 또는 웹훅의 누락된 정보 등 다양합니다.

실행 기록에서 실패한 워크플로우 실행 목록을 확인하고 디버깅하여 오류 재발을 방지할 수 있습니다.

워크플로우가 실패로 태그되지 않고도 특정 작업이 자동화되지 않을 수 있으므로 오류 처리가 중요합니다.

n8n 편집기 내 디버그 기능 활용

n8n 편집기의 디버그 기능은 실행 기록에서 현재 워크플로우 캔버스로 데이터를 고정하는 강력한 기능입니다.

실패한 실행의 데이터를 현재 워크플로우 편집기로 복사하여 고정함으로써 데이터를 기반으로 디버깅할 수 있습니다.

고정된 데이터는 오른쪽 하단에 파란색/보라색 기호로 표시되며, 한 번에 하나의 고정된 데이터 세트만 가질 수 있습니다.

오류 수정 후 재시도 기능을 사용하여 실패한 실행을 다시 트리거할 수 있습니다. 현재 저장된 워크플로우 또는 실행 당시의 워크플로우로 재시도할지 선택할 수 있습니다.

재시도는 오류가 있는 노드에서만 실행되므로, 오류가 발생한 노드 이전의 잘못 구성된 노드 문제인 경우 복사-편집기 노드를 사용하여 다시 실행해야 합니다.

출력 편집 기능은 특정 노드의 출력을 수동으로 편집하여 워크플로우를 테스트하거나 디버깅하는 데 유용합니다.

출력 편집은 확장성이 좋지 않으므로 드물게 사용해야 하지만, 재시도가 불가능한 경우 빠른 수정 방법이 될 수 있습니다.

워크플로우 버전 기록은 저장된 워크플로우의 이전 버전을 모두 볼 수 있어 실수를 되돌리거나 이전 버전을 검사하는 데 유용합니다.

재시도 기능과 함께 사용하여 이전 버전으로 되돌린 후 여러 실행을 재시도할 수 있습니다.

n8n 워크플로우 디버깅 예시 1: 누락된 ID 처리

디버깅의 첫 단계는 워크플로우가 정상적으로 실행될 때 무엇을 하는지 이해하는 것입니다.

실패한 실행에서 '정의되지 않은 문자열을 읽을 수 없습니다' 오류가 발생했으며, 이는 웹훅에 ID가 없기 때문입니다.

디버깅 편집기를 통해 데이터를 복사하고, 유효한 ID가 있는지 확인하는 if 문을 추가하여 오류를 처리합니다.

ID가 없는 경우, ID 대신 이메일을 사용하여 조회를 시도하고, 이메일도 없는 경우 Stop 노드를 사용하여 오류를 발생시킵니다.

수정된 워크플로우를 테스트하여 ID가 없는 경우 이메일 필드로 이동하여 성공적으로 사용자를 가져오고 메시지를 보냅니다.

이 특정 노드 이전에 수정해야 했기 때문에 이 워크플로우는 재시도할 수 없습니다.

n8n 워크플로우 디버깅 예시 2: 데이터 반환 없음 처리

워크플로우가 실패하지 않았지만 성공하지 못한 경우(데이터 반환 없음)를 살펴봅니다.

웹훅을 받았지만 ID로 사용자를 조회했을 때 데이터가 반환되지 않았습니다.

에디터에서 디버그하는 대신 에디터로 복사하여 이 경우를 처리할 수 있습니다.

사용자 가져오기 시트에서 '항상 데이터 출력' 매개변수를 설정하여 연락처를 찾지 못하더라도 빈 항목 정보를 출력하도록 합니다.

Slack 메시지를 보내기 전에 추가 검사를 설정하여 연락처에 이메일이 있는지 확인합니다.

유효한 이메일이 없는 경우(조회 실패) Stop 노드를 사용하여 '데이터베이스에서 연락처를 찾을 수 없음' 오류를 발생시킵니다.

이러한 수정을 통해 워크플로우 디버깅을 완료하고, 사용자를 찾을 수 없는 경우 오류가 발생하도록 했습니다.

워크플로우 디버깅 및 실패한 실행 수정에 대한 n8n 초급 과정의 마지막 비디오를 마칩니다.

고급 과정에서는 고급 워크플로우 구축, 복잡한 데이터 흐름, 고급 예제, 오류 처리 및 디버깅과 같은 고급 주제를 다룰 예정입니다.

n8n Beginner Course (8/9) - Debugging

n8n Beginner Course (8/9) - Debugging

스크립트