💣 프로젝트 트러블슈팅 및 삽질 기록

 

프로젝트를 진행하며 마주쳤던 주요 이슈들과 해결 과정을 공유한다.

세번째 회고록에 다 작성하기엔 내용이 너무 많아 따로 정리한다.

https://cord-ai.tistory.com/252

Sense Stock 개발 회고, 세 번째

 

모든 과정이 순탄하지만은 않았고, 오히려 이런 문제들을 해결하면서 더 많이 배울 수 있었다.

1. 데이터 소스의 신뢰도 문제

• 문제점
  investing.com에서 S&P500 기업 리스트를 스크래핑했는데, 편입된 종목의 업데이트가 실시간으로 반영되지 않는 것을 발견했다. 이는 곧 퇴출된 종목도 그대로 남아있을 수 있다는 의미였다.
• 교훈
  역시 공짜는 이유가 있다. 데이터의 정확성과 최신성이 중요한 금융 프로젝트에서 무료 스크래핑 데이터는 명확한 한계를 가진다. 당장은 이 이슈를 인지하고 넘어갔지만, 장기적으로는 신뢰할 수 있는 유료 API를 도입해야 한다는 결론을 내렸다.

---

2. Slack Bot의 무한 응답 루프

• 문제점
  Slack App 채널(DM)에서 봇에게 질문하면, 봇이 답변으로 보낸 Block Kit(선택 버튼) 메시지를 다시 자기 자신이 보낸 새 메시지로 인식하여 또다시 똑같은 Block Kit를 보내는 무한 루프에 빠졌다.
• 분석
  원인은 간단했다. 봇이 자기 자신의 메시지(bot_id가 있는 메시지)에도 반응하고 있었기 때문이다. if 노드를 사용해 bot_id가 존재하면 워크플로우를 멈추게 할 수도 있었지만, 이는 모든 메시지마다 불필요한 트리거 실행을 유발하여 비효율적이었다.
• 해결책
  결국 App 채널(DM)에서의 사용은 비활성화했다. 대신 사용자가 개인 비공개 채널을 만들어 봇을 초대하여 사용하도록 가이드했다. 이 방식이 더 깔끔하고 확실한 해결책이었다.

---

3. n8n 워크플로우의 실행 순서 보장

• 문제점
  n8n 워크플로우에서 여러 브랜치(흐름)가 동시에 진행될 때, 내가 의도한 순서대로 실행되지 않았다. 특정 브랜치가 모두 실행된 후 다음 브랜치가 실행될 것이라고 예상했지만, 실제로는 실행 순서가 보장되지 않았다.
• 해결책
  Merge 노드가 해답이었다. Merge 노드는 여러 개의 입력이 모두 도착할 때까지 실행을 대기했다가, 모든 데이터가 준비되면 다음 단계로 넘어간다. 이를 통해 데이터 처리 흐름의 동기화를 맞추고 실행 순서를 명확하게 제어할 수 있었다.

---

4. 유지보수성의 저주

• 문제점
  코드나 데이터의 컬럼명을 하나 바꿨을 뿐인데, 거미줄처럼 얽혀있는 수많은 노드들에서 연쇄적으로 오류가 발생했다. 간단한 수정이 거대한 나비효과를 불러왔다.
• 교훈
  프로젝트 초기에 데이터 구조를 명확하게 정의하는 것이 얼마나 중요한지 뼈저리게 느꼈다. 중간에 구조를 변경하는 것은 엄청난 비용을 초래한다. 유지보수하기 쉬운 구조를 설계하는 것 자체가 핵심적인 능력이라는 것을 깨달았다. 처음부터 잘 설계하자. 제발.