n8n 운영에 대한 질문 - 18기 CTO 오프모임 후기

9월 6일 18기 CTO 오프모임에서 나눈 의미있는 이야기를 휘발되기 전에 몇 개 적어 둡니다.
모임 참가 전에 n8n 운영에 대한 몇 가지 질문 사항이 있어서 질문을 했습니다.

ALT

개발자 프로젝트의 단계를 보여주는 다이어그램

❓Q1 : 코드로 개발할 때는 DEV(개발환경), Staging (Product 환경과 같지만 Product로 반영하기 전의 테스트 환경), Product (실제 real 서비스)환경으로 구분되지만, Nocode Make나 n8n으로 개발, 반영할 때는 이런 환경을 구성하기가 쉽지 않다. n8n을 실제로 서비스할 때는 어떠한가?

✅️ A: 실제 GPTers에서 n8n을 사용하여 서비스 할 때도 개발환경은 따로 있지 않고, 혹여라도 실수할 사항을 대비하여, 문자 발송 같은 경우 5분의 시간지연을 두고, 관리자가 중지하지 않으면 발송되도록 중간에 안전장치를 두고 있다.

ALT

오류 처리기 - 한국

❓Q2. n8n으로 작업할 때 제일 먼저 에러 처리 로직 먼저 하신다 하셨는데, 그 방법 다시 안내해 주세요.
✅️ A:
1. Error Handeler workflow를 정의 한다.
에러가 났을 때 어떻게 할지를 처리하는 workflow를 만든다.
에러 처리 방법은 DB에 저장하는 방법, 메일이나, 텔레그램, slack 등으로 모니터링 할 수 있는 방법으로 알림 등을 처리할 수 있다.

ALT

사람의 이미지와 버튼이있는 웹 페이지의 스크린 샷

이름은 편하게 정하시되, 에러처리 로직이라는 걸 명시적으로.
시작 노드는 Error Trigger로 시작해야 error가 발생했을 때 받을 수 있다.
많은 정보를 받을 수 있다. 에러가 발생한 서비스 구분이나 명칭, 에러 메세지 등등


2. workflow 작업시에 설정에서 Error Workflow 설정

ALT

버튼이있는 페이지의 스크린 샷

다른 workflow 작업을 할 때 save한 후 오른쪽 상단 점3개 누르고, Settings 클릭하면 아래의 화면이 보이는데, 여기에서 Error Workflow를 선택할 때 1번에서 만든 Error Handeller 를 선택해주면 설정 끝~!

ALT

WordPress 설정 페이지의 스크린 샷

여러 SUB 노드들이 연결되었을 경우에도 각 노드마다 에러 발생을 보내는 것이 아니라 가장 마지막 노드에 대해서 Error를 보낸다고 함. (이건 좀 사용해 봐야 장점을 분명히 알 수 있을 듯 함)

ALT

N8 사용자 정의 노드

❓Q3: n8n으로 고객사 로직을 구현해야 하는데, Community Node를 사용했다가 n8n 버전 upgrade 시에 혹여라도 정상 동작을 안하거나 지원하지 않는 경우는 없었는지요?
✅️ A: Community Custom Node는 그런 경우가 발생할 가능성이 있어서, 가능하면 리얼 서비스에는 사용하지 않는 것이 좋다.
아직까지 n8n 버전 업그레이드시에 이미 사용하고 있는 서비스에 영향이 있었던 적은 없다. 안심하고 업그레이드 해도 됨.

최근에 n8n으로 로직을 만들면서 완전 Cloud 기반인 make와 다르게 Self-Hosting이 가능한 n8n을 사용하면서 대비해야 하는 것들에 대한 궁금증을 해결해서 저에게는 큰 도움이 되었습니다.

같이 나눈 이야기 중에 흥미로웠던 것을 정리했습니다.

⚙️ 프랑스에 '에꼴42'가 있다면 한국에는 '42서울'이 있다.
유명한 IT 인재양성 아카데미, 에꼴42를 그대로 한국에 들여와 만든 '42서울' 이노베이션 아카데미에 대해 들었다.

어쩐지 기술을 바라보는 깊이와 원리를 짚어가는 설명이 남다르다 했는데, 교육을 받았던 history를 들었는데, 정말 어마어마했다.
나는 Shell명령어 쓰는 것만 알았는데, 42서울 들어가면 첫번째 과제가 본인이 사용할 Shell 명령어를 C언어로 직접 만드는 것이라고, 심지어 코드 규칙들도 극악인 상황.
그런 SW 교육기관이 있었다니, 놀랍기도, 부럽기도 했다.

https://www.donga.com/news/Economy/article/all/20230525/119467641/1

💻 Code is Debt ( 기술 부채)
Vibe 코딩이 진행하다가 무지성으로 OK를 하다보면, 어느새 똑같은 로직을 짜고있고, 오류 수정하라고 했더니, 잘 되던 로직이나 디자인까지 건들여서 육두문자가 절로 나오는 상황들이 있다.
이전에도 급하게 만든 개발의 결과물들이 사업의 확장성과 유연성을 따라가지 못해 기술 부채라는 말이 있었는데, AI가 도입되면서 점점 심해지고 있다.
AI가 싼 Poop💩은 누가 치워야 하나.
예전에는 코드리뷰가 있었는데, 이제는 프롬프트 리뷰를 해야 할 것 같다고.
https://news.hada.io/topic?id=22871

실제 서비스를 개발하고 운영하시는 다양한 분들이 스터디에 있다보니, 만든다의 차원을 넘어 그 이후의 고민과 실질적인 이야기를 들을 수 있었습니다.