콘텐츠로 건너뛰기

n8n 사용법, 세 단계 워크플로가 0.51초에 답했다

웹훅에서 깃허브 조회와 필드 고르기까지, 엔에이트엔 2.41.7 n8n 사용법을 2026-10-06 기준으로 처음부터 따라가 보니 주소 하나를 부르면 깃허브 저장소의 별 수를 0.51초 만에 돌려주는 워크플로가 만들어졌는데요, 게시 명령을 넣은 뒤에도 재시작 전까지는 찾을 수 없다는 응답만 돌아와서 한참 헤맸습니다. 앞 글 n8n 설치, 도커로 30초에 받고 2초 만에 떴다에서는 도커로 띄우는 데까지 적었습니다. 안녕하세요? 정리하는 개발자 워니즈입니다.
  • 한 일: 엔에이트엔(n8n)은 여러 서비스를 이어 일을 자동으로 돌리는 도구이고, 저는 웹훅(주소로 부르면 일을 시작하는 입구)과 깃허브 조회와 필드 고르기 세 단계짜리 워크플로(자동화 순서도)를 만들어 불러 봤습니다
  • 결과: 별 206,737개가 0.51초 만에 왔고 실패는 재시작 전 404 와 없는 저장소 이름의 500 두 가지였습니다
  • 쓸모: 엔에이트엔을 깔아 두고 첫 워크플로를 무엇으로 만들지 막막한 분께 맞습니다
확인한 것2026-10-06 직접 확인한 결과
만든 워크플로웹훅, HTTP 요청, 필드 고르기 3단계
게시 전 운영 주소404 “not registered”
게시 직후, 재시작 전같은 404
재시작 뒤 n8n-io/n8n별 206,737, 라이선스 NOASSERTION, 0.51초
재시작 뒤 ollama/ollama별 182,298, 라이선스 MIT
없는 저장소 이름HTTP 500 “Error in workflow”

1. n8n 사용법, 무슨 일이 있었나요?

앞 글에서 띄워 둔 엔에이트엔 2.41.7 컨테이너(실행 중인 상자)에 첫 워크플로를 넣어 봤는데요, 예제는 저장소 이름을 주소 뒤에 붙여 부르면 별 수와 라이선스만 골라 돌려주는 일로 정했습니다. 깃허브 공개 API(프로그램끼리 데이터를 주고받는 창구)만 써서 따로 가입하거나 키를 받을 일이 없으니 처음 해 보는 분도 같은 결과를 그대로 받아 볼 수 있을 것 같습니다.
이 글 다음에 읽을 글
편집 화면은 첫 방문에 이 컴퓨터 안에서 관리자 계정을 만드는 단계부터 띄우도록 설정돼 있었습니다(설정 주소의 showSetupOnFirstLoad 값이 True). 외부 서비스 가입이 아니라 내 컴퓨터 안에만 생기는 계정인데, 이번에는 그 화면을 열지 않고 워크플로 파일을 명령줄로 넣는 길을 택했습니다.

2. 무슨 문제가 생겼나요?

n8n 사용법을 처음 따라 하는 사람이 가장 당황할 곳은 게시까지 했는데 주소가 안 열리는 순간일 것 같은데요, 이번에 실제로 걸린 곳은 두 군데였습니다.
  1. 게시 전에도, 게시 직후에도 운영 주소가 404 였습니다. 응답 원문은 “The requested webhook “GET repo-stars” is not registered.” 였고 편집 화면 오른쪽 위 스위치로 켜라는 안내가 붙어 있었습니다. 게시 명령의 출력에는 “Please restart n8n for changes to take effect if n8n is currently running.” 이라는 줄이 있었는데 성공 메시지 아래에 섞여 있어서 지나치기 쉽습니다
  2. 없는 저장소 이름을 넣으면 워크플로 전체가 500 으로 끝났습니다. 부른 쪽이 받은 것은 “Error in workflow” 한 줄뿐이었고 원인인 깃허브 404 는 컨테이너 로그의 “AxiosError: Request failed with status code 404” 에만 남아 있었습니다
n8n 사용법으로 게시 전과 게시 직후는 404 그대로였다가 재시작 뒤에야 0.51초 만에 200 으로 바뀌는 세 번의 호출 결과

3. n8n 사용법, 어떻게 풀었나요?

단계를 다섯 개로 나누니 다시 해도 같은 결과가 나왔고, 실제로 친 명령과 출력은 끝의 부록에 모았습니다.
  1. 세 단계를 먼저 정합니다. 아래 표처럼 입구, 조회, 고르기 세 칸만 두고 칸끼리는 앞 칸의 결과를 다음 칸이 받도록 이었습니다
  2. 파일로 넣습니다. 워크플로 파일을 컨테이너에 넣자 “Successfully imported 1 workflow.” 가 찍혔고 목록에 “저장소 별 수 알려 주기” 가 보였습니다
  3. 게시한 다음 재시작합니다. 게시만 하면 404 가 그대로였고 컨테이너를 재시작해 상태 확인 주소가 정상이라고 답한 뒤에야 운영 주소가 열렸습니다
  4. 두 저장소로 불러 봅니다. n8n-io/n8n 은 별 206,737개를 0.51초 만에, ollama/ollama 는 별 182,298개와 라이선스 MIT 를 돌려줬습니다(2026-10-06 16시 기준 값이라 지금 부르면 숫자가 다를 수 있습니다)
  5. 실패 입력도 한 번 넣어 봅니다. 없는 이름은 500 이었고, 이번에는 이 실패를 막는 설정까지 시험하지 않아서 오류 처리 방법은 미확인으로 남깁니다
칸하는 일넣은 값
웹훅주소로 부르면 시작GET, 경로 repo-stars, 마지막 칸 결과로 응답
HTTP 요청깃허브 저장소 정보 조회https://api.github.com/repos/ 뒤에 받은 repo 값
필드 고르기필요한 값만 남김fullname, stargazerscount, license.spdx_id
명령줄로 넣은 워크플로에서만 재시작이 필요했는지, 편집 화면의 스위치로 켜면 재시작 없이 바로 열리는지는 이번에 시험하지 않았습니다. 명령줄 명령 목록은 n8n 공식 CLI 문서에, 조회한 응답의 칸 이름은 깃허브 저장소 조회 API 문서에 있습니다. n8n 사용법 세 단계 워크플로, 웹훅에서 HTTP 요청을 거쳐 필드 고르기로 값이 넘어가는 흐름

4. 누구에게 도움이 되나요?

n8n 사용법을 찾아 첫 워크플로를 만들고 게시까지 했는데 주소가 404 로만 답해 막힌 분이라면 읽어 보세요. 이미 잘 돌고 있다면 없는 값을 한 번 넣어 보고 500 이 나는지만 확인해 두면 됩니다. 주소가 200 으로 답했다고 일이 맞게 끝났다는 뜻은 아닙니다. 자동화가 끝났다고 볼 기준은 AI 자동화 완료 조건에 적었고, 검사는 통과했는데 실제 데이터에서 틀렸던 기록은 바이브 코딩 현실, 테스트는 통과했는데 261편 중 6편만 맞았다에 있습니다.

5. 한 줄 정리

필자의 결론

n8n 사용법에서 첫 워크플로는 웹훅, HTTP 요청, 필드 고르기 세 칸이면 충분하고, 명령줄로 넣었다면 게시 뒤 재시작해야 운영 주소가 열립니다. 재시작 전에는 게시 전과 게시 직후 두 번 모두 404 였고 재시작 뒤에는 0.51초 만에 답이 왔습니다. 그래서 필자는 앞으로 워크플로를 넣으면 게시, 재시작, 운영 주소 한 번 부르기를 한 묶음으로 끝내기로 했습니다.
그래서 당신은 이것만 하면 됩니다. 게시한 뒤 404 가 나오면 게시 출력의 재시작 안내를 읽고 컨테이너를 재시작한 다음 운영 주소를 다시 불러 보세요.
오늘은 저장소 이름 하나를 받아 별 수를 돌려주는 세 칸 워크플로부터 만들어 보세요. 여러분은 엔에이트엔으로 처음 무엇을 자동화하셨는지 댓글로 들려주세요.

자주 나는 오류

이번에 직접 재현한 오류만 문구 그대로 적습니다. 지어낸 오류는 없습니다.

{“code”:404,”message”:”The requested webhook \”GET repo-stars\” is not registered.”}

명령줄로 워크플로를 넣고 게시까지 했어도 n8n을 재시작하기 전까지는 운영 주소가 이 404를 냅니다. 컨테이너를 재시작하면 사라집니다.

{“message”:”Error in workflow”}

워크플로 안 HTTP 요청이 실패(이번엔 없는 저장소 이름으로 깃허브 404)하면 부른 쪽은 이 500 한 줄만 받습니다. 진짜 원인은 컨테이너 로그의 AxiosError 줄에 있습니다.
이 글 다음에 읽을 글

부록: 재현 명령과 출력

이 n8n 사용법 예제는 2026-10-06 macOS 27.0, Docker 29.8.0, n8n 2.41.7 컨테이너에서 돌렸습니다. 컨테이너 이름은 읽기 쉽게 n8n 으로 바꿔 적었고, 워크플로 파일은 위 표의 세 칸을 담은 JSON 입니다.
docker cp workflow.json n8n:/tmp/wf.json
docker exec n8n n8n import:workflow --input=/tmp/wf.json
docker exec n8n n8n publish:workflow --id=wzRepoStars01
docker restart n8n
curl -s "http://localhost:5678/webhook/repo-stars?repo=n8n-io/n8n"
게시 전과 게시 직후(재시작 전)에 같은 주소를 부르면 둘 다 아래 첫 줄의 404 였고, 게시 명령은 그 아래 세 줄을 찍었습니다. 404 응답 뒤에 붙는 hint 칸은 길어서 뺐습니다.
{"code":404,"message":"The requested webhook \"GET repo-stars\" is not registered."}
Publishing workflow with ID: wzRepoStars01 (current version)
Note: Changes will not take effect if n8n is running.
Please restart n8n for changes to take effect if n8n is currently running.
재시작 뒤 n8n-io/n8n, ollama/ollama, 없는 이름 no-such/repo-xyz 순서로 부른 결과입니다. 첫 줄은 time 으로 잰 0.51초였고 마지막 줄은 컨테이너 로그에서 찾은 원인입니다.
{"repo":"n8n-io/n8n","stars":206737,"license":"NOASSERTION"}
{"repo":"ollama/ollama","stars":182298,"license":"MIT"}
{"message":"Error in workflow"}
HTTP 500
AxiosError: Request failed with status code 404
시험이 끝난 컨테이너는 지우지 않고 멈춰만 뒀습니다. 내려받은 이미지가 디스크를 많이 차지한다면 도커 이미지 용량 정리를 참고하세요.

이 글을 쓴 사람

인프라와 DevOps를 실무로 다루면서 겪은 것을 기록합니다. Docker, Kubernetes, AWS, 그리고 AI 도구를 실제로 써 보고 남기는 로그입니다.

Threads·X

새 글이 올라오면 Threads @wonizz.ai 에도 올립니다. 팔로우해 두면 피드에서 바로 볼 수 있습니다.

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다