다음 보고서는 제가 Discourse를 설치하는 과정에서 겪은 실제 경험을 바탕으로 ChatGPT가 작성해 주었습니다. (저는 기술에 밝지 않아서, 어려운 작업들은 AI의 도움을 받아 처리해 왔습니다.) 현재로써는 도움이 필요하지 않지만, 이 보고서가 3.5.0.beta2-dev에 대한 유용한 피드백이 될 수 있기를 바랍니다.
==================
Discourse 팀께,
Discourse 3.5.0.beta2-dev를 실행하는 동안 겪은 이메일 관련 문제 해결 세부 내용을 공유하고자 합니다. 3.4.0.beta4-dev로 되돌리기로 결정했으므로 직접적인 도움이 필요하지는 않지만, 최신 개발 버전의 잠재적 문제를 식별하는 데 이 보고서가 유용하길 바랍니다.
1. 문제 요약
새로운 Vultr 인스턴스에 20i의 SMTP 서비스(smtp.stackmail.com)를 사용하여 Discourse를 깨끗하게 설치(clean installation)했습니다. 그러나 다음 사항에도 불구하고 이메일이 전달되지 않았습니다:
SMTP 연결 테스트 성공 (openssl s_client -connect smtp.stackmail.com:587 -starttls smtp).
20i 메일 로그에 오류가 없음 (Discourse가 실제로 이메일을 보내지 않았음을 시사함).
Sidekiq이 이메일 작업을 처리하지 못함.
몇 주 전, 동일한 구성의 인스턴스에 Discourse 3.4.0.beta4-dev를 설치했을 때 이메일 문제가 없었으므로 이는 예상치 못한 상황이었습니다.
세심한 디버깅을 거쳐, 현재 설치 환경에서 의도치 않게 Discourse 3.5.0.beta2-dev가 설치되었음을 발견했으며, 이것이 문제의 원인이 되었을 가능성이 높습니다.
2. 식별된 주요 문제
A. 이메일이 전달되지 않음
SMTP 설정은 정확했으며, 수동 테스트(swaks 및 openssl 테스트 성공)를 통해 확인되었습니다.
이메일은 Sidekiq에 큐에 추가되었으나 수신되지 않았습니다.
20i 메일 로그에는 거부 또는 전달 시도가 기록되지 않았습니다 (메시지가 Discourse를 떠나지 않았음을 시사함).
production.log에 이메일 관련 오류가 표시되지 않았습니다 (grep "smtp" 실행 시 아무 결과도 없음).
B. Sidekiq 및 Redis 문제
초기에는 Sidekiq이 실행되지 않았습니다 (Sidekiq::Workers.new.size가 0을 반환).
Sidekiq을 수동으로 재시작(sv restart sidekiq)하려고 했으나 Sidekiq 서비스가 누락되어 실패했습니다.
Redis는 실행 중이었습니다 (redis-cli ping이 PONG을 반환) 하지만, Discourse 로그에는 여전히 Redis 연결 오류(Errno::ECONNREFUSED)가 표시되었습니다.
Redis가 활성 상태임이 확인되었음에도 불구하고, Sidekiq 로그에는 Redis 연결 문제로 인한 작업 실패가 표시되었습니다.
Sidekiq을 수동으로 시작(bundle exec sidekiq)했을 때 작업은 처리되었으나, 여전히 이메일이 전송되지 않았습니다.
C. 설치 간 버전 불일치
**이전 설치(정상 작동했던 것)**는 3.4.0.beta4-dev였습니다.
현재 설치는 동일한 설치 방법을 사용했음에도 불구하고 의도치 않게 3.5.0.beta2-dev가 설치되었습니다.
3.4.0.beta4-dev에서 이메일이 완벽하게 작동했으므로, 3.5에서 회귀(regression) 또는 호환성 깨짐(breaking change)이 발생했을 것으로 의심합니다.
3. 수행된 조치 (모두 실패)
다음 솔루션들을 체계적으로 시도했습니다:
다음으로 SMTP 연결 확인:
openssl s_client -connect smtp.stackmail.com:587 -starttls smtp # 성공
swaks --to my-email --server smtp.stackmail.com --port 587 --auth LOGIN # 성공
이메일이 큐에 추가되었는지 확인:
Jobs.enqueue(:user_email, type: :test_message, to_address: 'masden@kumagaku.ac.jp') # 작업 ID 반환
Sidekiq::Queue.new("default").size # 0 반환 (작업이 처리되었음을 의미)
Discourse 로그 확인:
grep "smtp" /shared/log/rails/production.log # SMTP 관련 오류 없음
Redis 연결 실패 (production.log에 Errno::ECONNREFUSED 발생).
서비스 재시작 및 수동 트리거:
sv restart sidekiq # 실패, 서비스 누락
redis-cli ping # 실행 중 확인
bundle exec sidekiq # 작업은 처리되었으나 이메일 미전송
20i에 의해 이메일이 차단되는지 확인:
20i 메일 로그에 거부 또는 전달 시도 기록 없음.
이메일이 거부되었다면 로그 항목이 있어야 하지만, 아무것도 표시되지 않았습니다.
4. 결론: 3.4.0.beta4-dev로 롤백
광범위한 문제 해결 과정을 거친 후, 이전 설치 환경에서 해당 버전이 완벽하게 작동했으므로 설치를 지우고 3.4.0.beta4-dev를 재설치하기로 결정했습니다.
직접적인 도움이 필요하지는 않지만, 다음 이유들로 인해 이 문제를 보고하고자 합니다:
3.5에서 이메일 처리 방식이 변경되어 SMTP 핸드오프가 방지되었을 수 있습니다.
Sidekiq 서비스 누락 및 Redis 오류는 3.5에서 백그라운드 작업 처리에 문제가 있음을 시사합니다.
3.4.0.beta4-dev를 문제없이 설치할 수 있었으므로, 이는 3.5에서 회귀가 발생했을 가능성을 시사합니다.
이 보고서가 Discourse 3.5.0.beta2-dev의 잠재적 문제를 식별하는 데 도움이 되기를 바랍니다.
AI에 대해 말씀드리자면, ChatGPT가 신뢰할 만한 가이드가 되지 못한다는 점은 명확합니다. 반면, 디버깅이 어려운 편이라 저 같은 사람에게 ChatGPT에 의존하고 싶은 유혹은 큽니다.
드디어 설치를 성공적으로 완료했습니다. ChatGPT(유료 버전)로는 목표를 달성하지 못했지만, Anthropic의 Claude(이것도 유료 버전입니다. 두 가지를 모두 사용 중)가 마침내 해결해 주었습니다. Claude는 ChatGPT가 일으킨 문제들을 수정하는 데 도움을 주었습니다.
나중에 제 경험에 대해 더 자세히 다시 말씀드리겠습니다. 도움 주신 모든 코멘트에 감사드립니다!
감사합니다! 특정 작업에서는 정말로 큰 차이가 날 수 있네요 — 마치 성격이 다른 사람들처럼요. Claude는 더 “신중하게” 생각하는 경향이 있는 반면, ChatGPT는 결론에 도달하는 속도가 빠르고 앞서 나가는 경향이 조금 더 강합니다. 물론 ChatGPT가 더 나은 경우도 있었어요. 둘 다 발전하길 바랍니다. 저는 스크립트 작성자가 아니지만, AI 덕분에 실제로 작동하는 스크립트를 많이 작성할 수 있었습니다. 저처럼 기술에 약한 사람들에게 훌륭한 도구가 될 잠재력이 있지만, 분명히 개선이 필요합니다. 막다른 골목으로 인도당하는 것은 정말 답답합니다.
최근 시도에서 SMTP 관련 문제가 발생한 이유가 여전히 명확하지 않습니다. 사실 몇 주 전 첫 번째 시도는 성공적이었습니다. 하지만 당시 저는 필요 이상으로 큰 용량의 Vultr 서버를 사용하고 있었고, 용량을 줄이려면 더 작은 새 서버를 구한 뒤 기존 큰 서버를 삭제하는 것 외에는 방법이 없었습니다.
받은 이메일에 따르면, 몇 주 전에 설치한 Discourse 버전은 3.4.0.beta4-dev였습니다. 해당 이메일에서는 3.4.0.beta4로 업그레이드할 것을 권장하고 있었습니다.
3.4.0.beta4-dev에서 SMTP 문제를 겪었기 때문에, 저는 이전의 안정판(stable) Discourse를 설치해 보려 했습니다. ChatGPT와 논의한 결과(믿을 만한 도구는 아니라는 것을 알고 있지만) 3.4.1 설치를 시도하기로 했습니다. 저는 그 버전이 안정판일 것이라고 생각했습니다. 하지만 최종적으로 설치된 내용은 다음과 같습니다:
다음으로 SMTP 연결 확인:
