Synology Calendar 업데이트 후 로그인 오류 해결

Synology Calendar를 외부 도메인으로 사용하던 중 업데이트 이후 로그인 문제가 발생했습니다.

외부 Calendar 주소에서 계정 정보를 입력하면 Calendar 화면까지는 열렸지만, ‘나의 캘린더’와 기존 일정이 처음부터 표시되지 않았습니다. 계정 화면에서는 “로그인이 잘못되었습니다. 다시 로그인하십시오.”라는 메시지가 나타났고 로그인 상태도 정상적으로 유지되지 않았습니다.

특이했던 점은 모든 환경에서 동일한 문제가 생긴 것은 아니었다는 것입니다.
회사 네트워크에서 Cloudflare Proxied를 거쳐 일반 Chrome으로 접속할 때 문제가 발생했지만, 모바일 LTE나 다른 네트워크에서는 같은 Proxied 상태에서도 정상적으로 사용할 수 있었습니다.

Chrome 개발자 도구를 확인해보니 문제가 발생할 때 Socket.IO의 HTTP polling 요청에서 HTTP 400 Bad Request와 Session ID unknown 오류도 나타났습니다.

여러 환경을 비교한 뒤에는 Calendar 3.0.3 업데이트가 문제 발생과 관련됐을 가능성이 있다고 보고 3.0.2-21433으로 롤백했습니다. 하지만 다운그레이드 직후에도 기존 Chrome 일반 모드에서는 문제가 남아 있었습니다.

반면 시크릿 모드에서는 정상적으로 접속됐고, 마지막으로 Chrome의 인터넷 사용 기록을 정리한 뒤 일반 모드에서도 정상적으로 사용할 수 있게 됐습니다.

결과적으로 이번 조치는 근본적인 원인을 찾아 해결했다기보다, 문제가 발생하기 전 버전으로 되돌리고 브라우저 데이터를 정리해 다시 사용할 수 있는 상태로 만든 것에 가깝습니다.

문제 발생 환경

제가 사용한 환경은 다음과 같습니다.

항목	환경
NAS	Synology DS423+
외부 접속	Synology Calendar 별도 외부 도메인
접속 방식	DSM 로그인 포털의 응용 프로그램
예시 주소	https://calendar.example.com
DNS/CDN	Cloudflare
Cloudflare SSL/TLS	Full (strict)
WebSockets	ON
문제 발생 버전	Synology Calendar 3.0.3-21434
다운그레이드 버전	Synology Calendar 3.0.2-21433

실제로 사용하는 Calendar 외부 주소는 보안을 위해 공개하지 않고 calendar.example.com이라는 가상 주소로 표시했습니다.

업데이트 전까지는 같은 방식으로 외부에서 Calendar를 사용하고 있었습니다. 그런데 Calendar 3.0.3-21434 업데이트 이후 회사 네트워크에서 접속할 때 이전에는 없던 문제가 나타나기 시작했습니다.

Synology 공식 릴리스 노트에 따르면 3.0.3-21434는 2026년 8월 4일 공개됐으며 여러 보안 취약점을 수정한 버전입니다.

로그인 오류 증상

외부 Calendar 주소에서 계정 정보를 입력하면 Calendar 화면 자체는 열렸습니다.

하지만 ‘나의 캘린더’와 기존 일정이 처음부터 표시되지 않았습니다.

계정 관리 화면에서는 다음 메시지도 확인했습니다.

로그인이 잘못되었습니다. 다시 로그인하십시오.

처음에는 정상적으로 로그인된 뒤 다시 풀리는 문제라고 생각했습니다.
하지만 실제 화면과 이후 테스트를 다시 보면 로그인 또는 로그인 후 세션 인증 과정이 정상적으로 이어지지 않는 문제 같았습니다.

반면, DSM에 로그인한 뒤 내부에서 Synology Calendar를 직접 실행해보니 기존 캘린더와 일정은 모두 정상적으로 표시됐습니다.

따라서 적어도 Calendar에 저장된 일정 자체가 삭제되거나 손상된 문제는 아니었습니다. 같은 계정으로 DSM 내부 Calendar를 정상적으로 사용할 수 있었기 때문에 단순한 계정이나 비밀번호 오류도 아니었습니다.

접속 환경별 테스트 결과

실제로 테스트한 순서는 다음과 같습니다.

순서	Calendar 버전	테스트 조건	결과
1	3.0.3-21434	DSM 내부 Calendar	정상
2	3.0.3-21434	회사망 + Cloudflare Proxied	로그인 오류, 캘린더·일정 미표시
3	3.0.3-21434	/socket.io/ polling 확인	HTTP 400, Session ID unknown
4	3.0.3-21434	모바일 LTE + Proxied	정상
5	3.0.3-21434	다른 사외망 PC + Proxied	정상
6	3.0.3-21434	홈 VPN + Proxied	정상
7	3.0.3-21434	회사망 + DNS only	정상
8	3.0.2-21433	Calendar 다운그레이드	완료
9	3.0.2-21433	회사 PC Chrome 시크릿 모드 + Proxied	정상
10	3.0.2-21433	회사 PC Chrome 일반 모드 + Proxied	비정상
11	3.0.2-21433	인터넷 사용 기록 삭제 후 일반 모드 + Proxied	정상

이 결과를 순서대로 보면 몇 가지 특징이 보였습니다.

먼저 Calendar 3.0.3 상태에서는 회사 네트워크와 Cloudflare Proxied를 함께 사용할 때 문제가 발생했습니다.

하지만 같은 버전이라도 모바일 LTE, 다른 사외망 PC, 홈 VPN에서는 Proxied 상태로 정상적으로 접속됐습니다. 회사 네트워크에서도 Cloudflare를 DNS only로 바꾸면 정상적으로 사용할 수 있었습니다.

이후 Calendar를 3.0.2로 다운그레이드했는데, 여기서 문제가 끝난 것도 아니었습니다.

3.0.2 상태에서 Chrome 시크릿 모드는 정상적으로 동작했지만 기존 일반 모드에서는 여전히 문제가 남아 있었습니다.
마지막으로 Chrome의 인터넷 사용 기록을 정리한 뒤에야 일반 모드까지 정상으로 돌아왔습니다.

Cloudflare Proxied와 DNS only 비교

회사 네트워크에서 Calendar 3.0.3과 Cloudflare Proxied를 함께 사용할 때 문제가 발생했고, DNS only로 바꾸면 정상적으로 접속됐습니다.

여기까지만 보면 Cloudflare Proxy가 원인이라고 생각하기 쉽습니다.

하지만 같은 Calendar 3.0.3과 Cloudflare Proxied 상태에서도 모바일 LTE, 다른 사외망 PC, 홈 VPN에서는 Calendar가 정상적으로 동작했습니다.

따라서 Cloudflare Proxied를 사용하면 Synology Calendar가 작동하지 않는다고 확신할 수 없었습니다.

확인할 수 있었던 것은 회사 네트워크와 Cloudflare Proxied를 함께 사용하는 조건에서 문제가 반복된다는 정도였습니다.

이전에도 Synology 앱의 외부 접속 문제를 확인하면서 Cloudflare Proxied와 DNS only를 비교한 경험이 있습니다.

Synology DS audio 앱 로그인 오류 해결기: Cloudflare Proxied와 DNS only 차이

DS audio와 이번 Calendar 문제는 증상이 다르지만, 외부 접속 문제에서 Cloudflare를 경유할 때와 경유하지 않을 때를 비교하는 방법은 이번에도 문제 범위를 좁히는 데 도움이 됐습니다.

Cloudflare 설정 확인

Cloudflare에 Calendar 통신을 방해할 만한 별도 설정이 있는지도 확인했습니다.

당시 확인한 내용은 다음과 같습니다.

WebSockets: ON
SSL/TLS: Full (strict)
Calendar에 별도로 적용한 Redirect Rule 없음
Calendar에 별도로 적용한 Origin Rule 없음
Calendar에 별도로 적용한 Transform Rule 없음
/socket.io/에 직접 적용되는 별도 Cache Rule을 발견하지 못함

또한 LTE와 다른 사외망에서는 같은 Cloudflare Proxied 설정으로 정상적으로 접속됐습니다.

그래서 Cloudflare 자체의 문제라고 보기는 어려웠습니다.

그렇다고 회사 방화벽이나 보안 장비를 원인이라고 단정할 수도 없었습니다. 회사 네트워크 내부에서 실제로 어떤 처리가 이루어지는지는 직접 확인할 수 없었기 때문입니다.

결국 이 단계에서는 특정 회사 네트워크에서 Cloudflare Proxied를 함께 사용할 때 문제가 재현된다는 것까지만 확인했습니다.

Chrome 개발자 도구 오류 확인

화면에 표시되는 로그인 오류만 보고서는 어느 통신 과정에서 문제가 생겼는지 알기 어려웠습니다.

그래서 문제가 발생하는 회사 PC에서 Chrome 개발자 도구의 Network 항목을 확인했습니다.

확인 경로는 다음과 같습니다.

Chrome 개발자 도구 → Network → socket.io

문제가 발생할 때 /socket.io/ 요청 가운데 transport=polling이 포함된 요청에서 오류가 나타났습니다.

HTTP 상태는 400 Bad Request였습니다.

응답에는 다음 내용이 표시됐습니다.

{“code”:1,”message”:”Session ID unknown”}

그리고 이 오류가 확인되는 시점에 Calendar에서도 로그인 실패 메시지가 나타났고 로그인 상태가 정상적으로 유지되지 않았습니다.

화면에 보이는 로그인 오류 외에도 실제 통신 과정에서 세션과 관련된 오류가 함께 발생하고 있다는 것을 확인할 수 있었습니다.

Session ID unknown 오류의 의미

Socket.IO의 세부 구조를 모두 알아야 할 필요는 없지만, 세션 ID가 어떤 역할을 하는지만 알아두면 이 오류를 이해하기 쉽습니다.

브라우저와 서버가 연결되면 그 연결을 구분하기 위한 세션 ID가 만들어지고, HTTP polling을 사용하는 동안 이후 요청에서도 같은 연결을 이어가기 위해 이 ID를 사용합니다.

쉽게 보면 다음과 같은 흐름입니다.

브라우저가 서버에 연결합니다.
연결을 구분할 세션 ID가 만들어집니다.
이후 요청에서도 같은 세션 ID를 사용합니다.
서버는 그 ID를 이용해 앞서 만들어진 연결을 이어갑니다.

이번 문제에서는 이후 HTTP polling 요청 과정에서 Session ID unknown이라는 응답이 나타났습니다.

Socket.IO 공식 문서에서도 Session ID unknown은 오류 코드 1로 설명하고 있습니다.

다만 이 오류의 일반적인 설명을 이번 Synology Calendar 문제의 직접적인 원인이라고 보기는 어렵습니다.

Synology Calendar 내부에서 Socket.IO가 정확히 어떤 구조로 동작하는지, Calendar 3.0.3에서 관련 부분에 어떤 변경이 있었는지는 공개 자료만으로 확인하지 못했습니다.

따라서 이번에 직접 확인한 것은 다음 정도입니다.

회사 네트워크의 일반 Chrome에서 문제가 발생할 때 Socket.IO의 HTTP polling 요청에서 HTTP 400과 Session ID unknown 오류가 나타났고, 같은 시점에 Calendar에서도 로그인 오류와 로그인 상태 유지 문제가 나타났습니다.

둘이 같은 시점에 나타난 것은 확인했지만, Session ID unknown 오류가 직접적인 원인이라고까지 단정하지는 않았습니다.

WebSocket과 HTTP polling 구분

Cloudflare를 이용하고 있었기 때문에 처음에는 WebSocket 쪽 문제도 생각했습니다.

그런데 Chrome 개발자 도구에서 실제로 오류가 발생한 요청에는 transport=polling이 표시돼 있었습니다.

그래서 이번에 직접 확인한 오류는 단순한 WebSocket 오류라기보다 Socket.IO의 HTTP polling 과정에서 나타난 세션 오류라고 표현하는 편이 더 정확합니다.

Socket.IO는 연결 과정에서 HTTP polling을 사용할 수 있고 이후 다른 전송 방식으로 전환될 수도 있습니다.

하지만 이번 테스트에서는 WebSocket으로 전환되는 과정이 실제 문제와 어떤 관계가 있었는지까지는 확인하지 못했습니다.

Calendar 3.0.3 업데이트 이후 문제 발생

문제가 시작된 시점이 Calendar 업데이트 이후였기 때문에 버전 변경 내용도 확인했습니다.

Calendar 3.0.2-21433

Synology 공식 릴리스 노트에서 Calendar 3.0.2-21433은 2026년 1월 27일 공개된 것으로 확인됩니다.

이 버전에서는 반복 일정 종료를 Never로 지정할 때 발생할 수 있는 문제와 기타 사소한 버그가 수정됐습니다.

Calendar 3.0.3-21434

Calendar 3.0.3-21434는 2026년 8월 4일 공개됐으며 여러 보안 취약점을 수정한 버전입니다.

다만 공개된 릴리스 노트에서는 다음 부분까지는 알 수 없었습니다.

Socket.IO 내부 동작
HTTP polling 처리 방식
세션 인증이나 유지 방식
Cloudflare와의 호환성
WebSocket 관련 내부 처리

제 환경에서는 분명히 3.0.3 업데이트 이후 문제가 시작됐습니다.

그래서 여러 테스트를 마친 뒤에는 업데이트의 영향을 의심하고 이전 버전으로 되돌려보는 방향을 선택했습니다.

하지만 업데이트 이후 문제가 시작됐다는 사실은 맞지만 3.0.3 자체가 원인이라고 확신할 수 없었습니다.

공개된 자료와 이번 테스트만으로는 “Synology Calendar 3.0.3 버그”라고 단정할 수 없었고, 보안 업데이트의 어떤 변경 때문에 문제가 발생했다고 말할 근거도 찾지 못했습니다.

Calendar 3.0.2 롤백

여러 네트워크를 바꿔가며 테스트했지만 정확한 원인까지는 찾지 못했고, 회사에서는 계속 Calendar를 정상적으로 사용할 수 없었습니다.

문제가 Calendar 3.0.3 업데이트 이후 시작됐기 때문에 이전 버전에서는 같은 문제가 발생하지 않는지 확인하기 위해 3.0.2로 롤백했습니다.

변경한 버전은 다음과 같습니다.

3.0.3-21434 → 3.0.2-21433

DS423+에서 제가 실제로 사용한 패키지는 다음 파일입니다.

Calendar-x86_64-3.0.2-21433.spk

해당 패키지는 Synology 공식 패키지 아카이브에서 내려받았습니다.

또 Calendar처럼 실제 데이터를 사용하는 패키지의 버전을 되돌릴 때는 중요한 일정이 백업돼 있는지, 문제가 생겼을 때 복구할 수 있는지를 먼저 확인하는 편이 좋습니다.

다운그레이드 이후 Chrome 테스트

Calendar를 3.0.2-21433으로 되돌린 뒤 회사 PC에서 다시 테스트했습니다.

먼저 Chrome 시크릿 모드에서는 Cloudflare Proxied 상태에서도 나의 캘린더와 일정이 정상적으로 표시됐고 로그인 상태도 정상적으로 유지됐습니다.

그런데 기존 Chrome 일반 모드로 다시 접속하자 문제가 남아 있었습니다.

이 결과를 보면 Calendar 버전을 낮추는 것만으로 기존 일반 Chrome 환경까지 바로 정상화된 것은 아니었습니다.

다운그레이드 이후 시크릿 모드는 정상이고 기존 일반 모드에서만 문제가 계속됐기 때문에 Chrome에 남아 있던 기존 사이트 데이터나 세션 상태도 이번 현상과 관련돼 있을 가능성을 생각하게 됐습니다.

Chrome 인터넷 사용 기록 삭제 후 정상화

마지막으로 문제가 남아 있던 Chrome 일반 모드의 인터넷 사용 기록을 정리했습니다.

삭제한 항목은 다음 두 가지였습니다.

쿠키 및 기타 사이트 데이터
캐시된 이미지 및 파일

그 뒤 같은 회사 PC의 일반 Chrome에서 다시 외부 Calendar에 접속했습니다.

이번에는 정상적으로 동작했습니다.

로그인 정상
‘나의 캘린더’ 정상 표시
기존 일정 정상 표시
로그인 상태 정상 유지

결국 실제 정상화 과정은 단순한 Calendar 다운그레이드 → 해결이 아니었습니다.

실제로는 다음 순서였습니다.

Calendar 3.0.3에서 문제 확인 → 3.0.2로 롤백 → 시크릿 모드 정상 → 일반 모드는 계속 비정상 → Chrome 인터넷 사용 기록 삭제 → 일반 모드 정상화

이 과정 때문에 Calendar 버전과 Chrome 상태를 함께 봐야 했습니다.

문제 원인과 확인 범위

이번 테스트를 마친 뒤에도 정확한 원인을 하나로 특정하기는 어려웠습니다.

Calendar 3.0.3에서는 회사망 + Cloudflare Proxied 조건에서 문제가 발생했지만 다른 네트워크에서는 Proxied 상태로 정상적으로 사용할 수 있었습니다.

회사망에서도 DNS only로 바꾸면 정상적으로 동작했습니다.

Calendar를 3.0.2로 되돌린 뒤에는 시크릿 모드가 정상인 반면 기존 일반 Chrome에서는 문제가 남아 있었고, 인터넷 사용 기록을 정리한 뒤 일반 모드까지 정상으로 돌아왔습니다.

이 결과를 보면 Chrome에 남아 있던 사이트 데이터나 세션 상태도 문제와 관련됐을 가능성이 있습니다.

하지만 브라우저 상태만으로 모든 현상을 설명할 수도 없습니다. 3.0.3 상태에서 회사 네트워크와 Cloudflare Proxied를 함께 사용할 때 문제가 반복됐기 때문입니다.

결국 이번 경험은 한 가지 원인을 정확히 찾아낸 사례라기보다, Calendar 3.0.3 업데이트 이후 문제가 시작된 것을 계기로 이전 버전으로 롤백하고 브라우저 상태까지 정리해 정상 사용이 가능하도록 만든 과정으로 보는 편이 맞습니다.

3.0.2 롤백의 한계

Calendar는 다시 정상적으로 사용할 수 있게 됐지만 아쉬운 점도 있습니다.

제가 되돌린 3.0.2-21433은 3.0.3-21434보다 이전 버전입니다.

Synology는 Calendar 3.0.3-21434에서 여러 보안 취약점을 수정했다고 공식적으로 안내하고 있습니다.

따라서 3.0.2로 되돌리면 3.0.3에 포함된 보안 수정이 적용되지 않은 이전 버전을 사용하는 것입니다.

이번 롤백은 문제의 근본적인 해결책이라기보다 정상 사용을 위해 선택한 임시 우회 방법입니다.

새로운 Calendar 수정 버전이 나오면 릴리스 내용을 확인하고 같은 문제가 해결됐는지 다시 테스트한 뒤, 가능하면 보안 업데이트가 포함된 최신 버전으로 돌아갈 생각입니다.

마무리

이번 문제는 Synology Calendar 3.0.3 업데이트 이후 시작됐고, 업데이트의 영향을 의심해 3.0.2로 롤백한 뒤 Chrome의 쿠키와 캐시를 정리하면서 정상화됐습니다.

하지만 3.0.3에서 정확히 무엇이 문제였는지는 확인하지 못했습니다.
따라서 이번 방법은 근본적인 해결이라기보다 이전 버전으로 돌아가 문제를 피한 임시 조치에 가깝습니다.

Calendar를 다시 사용할 수 있게 된 것은 다행이지만, 보안 수정이 포함된 최신 버전을 사용하지 못하고 있다는 점은 아쉽습니다.
새로운 버전에서 문제가 해결되면 다시 최신 버전으로 업데이트해 확인할 예정입니다.

참고 자료

Synology Calendar 공식 Release Notes
Calendar 3.0.2-21433과 3.0.3-21434의 공개일 및 변경 사항을 확인했습니다.

Synology 공식 Package Archive – Calendar 3.0.2-21433
DS423+ 환경에서 사용한 Calendar-x86_64-3.0.2-21433.spk 패키지를 확인했습니다.

Socket.IO 공식 Troubleshooting – Connection issues
HTTP polling 연결과 Session ID unknown 오류에 대한 일반적인 설명을 확인했습니다.