# v3.4.0에서 v2026.7.2로 업그레이드하기 전에 알아야 할 사항
**URL:** https://meta.discourse.org/t/what-to-know-before-upgrading-from-v3-4-0-to-v2026-7-2/411291
**Category:** Self-hosting
**Tags:** hosting
**Created:** [8월 31, 2026, 1:17오후 UTC](https://meta.discourse.org/t/what-to-know-before-upgrading-from-v3-4-0-to-v2026-7-2/411291 "2026-08-31T13:17:57Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@corywright](https://meta.discourse.org/u/corywright)
#### Post date: [8월 31, 2026, 1:17오후 UTC](https://meta.discourse.org/t/what-to-know-before-upgrading-from-v3-4-0-to-v2026-7-2/411291/1 "2026-08-31T13:17:57Z")
저는 오픈 소스 프로젝트의 일환으로 인수받은, Ubuntu에서 Docker 기반으로 실행되는 Discourse 설치 환경을 관리하고 있습니다. 수년 동안 `git pull && ./launcher rebuild app` 명령을 실행한 뒤 `/admin/update`의 관리자 UI를 통해 업그레이드를 진행해 왔습니다. 그러나 2024년 1월 docker\_manager로 인해 발생한 파괴적 업그레이드(breaking upgrade) 과정에서 고통스러운 경험을 한 후로, 더 이상 이렇게 가볍게 업그레이드를 진행하지는 않고 있습니다. (해당 커밋에 대한 코멘트는 [여기](https://github.com/discourse/docker_manager/commit/5a0499af2911bcda043c613cbf7048158114725b)에서, 되돌려진 커밋은 [여기](https://github.com/discourse/docker_manager/commit/e480ca103ce85db1145ab22f3a526e8f356579ce)에서 확인하실 수 있습니다.)
지금은 2년 반이 지났고, 다시 업그레이드 리듬을 찾아야 하지만, 이전의 실패한 업그레이드 경험 때문에 여전히 조금은 긴장된 상태입니다. 제가 이해하고 싶은 것은 v3.4.0에서 v2026.7.2로 업그레이드를 시도하기 전에 알아야 할 사항이 무엇인지입니다. 저희 사이트는 추가 플러그인을 사용하지 않으며, 제가 인지하고 있는 유일한 특수 설정은 메인 커뮤니티 사이트와 SSO를 위해 [Discourse Connect](https://meta.discourse.org/t/13045?silent=true) URL을 사용하고 있다는 점입니다.
그냥 아래처럼 단순한가요?
```plaintext
cd /var/discourse
git pull
./launcher rebuild app
```
그리고 관리자 UI를 통해 업데이트를 하는 것 말입니다. v3.4.0에서 v2026.7.2로 넘어갈 때 주의해야 할 중간 단계가 있을까요?
감사합니다,
Cory
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [8월 31, 2026, 1:23오후 UTC](https://meta.discourse.org/t/what-to-know-before-upgrading-from-v3-4-0-to-v2026-7-2/411291/2 "2026-08-31T13:23:43Z")
아니면 …(긴장되고 있다면) … 백업(어쨌든 필수)을 만들어 완전히 새로운 서버를 설정하고 백업을 복원한 후, 완료되면 도메인을 새 서버로 전환하는 방법도 있습니다.
직면하게 될 가장 큰 문제는 [Postgres의 주요 업그레이드(18 버전으로의 업데이트)](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/1)입니다. 새 서버를 구축하면 이 업그레이드 과정을 거치지 않아도 됩니다.
또한, 의존하고 있는 플러그인이나 테마 컴포넌트가 유지보수되지 않았을 가능성도 있습니다. 특히 덜 활동적인 제3자가 작성한 경우 더욱 그렇습니다.
경험이 많은 Discourse SA(시스템 관리자)들이 업데이트를 커밋하기 전에 부트스트랩할 수 있도록 두 개의 컨테이너를 설정하는 이유가 바로 이 긴장감 때문입니다. (다만, Postgres의 대규모 업데이트 상황에서는 그 효과가 크지 않지만, 이런 업데이트는 드물게 발생합니다.)
---
### Author:  [@corywright](https://meta.discourse.org/u/corywright)
#### Post date: [9월 1, 2026, 5:52오후 UTC](https://meta.discourse.org/t/what-to-know-before-upgrading-from-v3-4-0-to-v2026-7-2/411291/3 "2026-09-01T17:52:13Z")
답변해 주셔서 감사합니다. 이 아이디어가 마음에 들고, 이 방향으로 한번 시도해 볼게요!
---
### Author:  [@corywright](https://meta.discourse.org/u/corywright)
#### Post date: [9월 7, 2026, 12:27오전 UTC](https://meta.discourse.org/t/what-to-know-before-upgrading-from-v3-4-0-to-v2026-7-2/411291/4 "2026-09-07T00:27:36Z")
오늘 마이그레이션을 시도했는데, discourse\_docker의 main 브랜치에서 또다시 즉시 호환성 깨짐(breaking change) 문제를 겪었습니다:
>
>
> Run asset:precompile:pretty\_text alongside precompile:build during build time.
> …
> Ensures that the prebuilt prettytext cache is present in /tmp after build time.
이 커밋은 빌드를 실패시키고 설치/세팅을 깨뜨리지만, 그래도 main 브랜치에 병합되었습니다. 제가 걱정했던 바로 그 상황이었습니다.
`./launcher bootstrap app`를 실행하면 다음과 같은 결과가 나옵니다:
```plaintext
rake aborted!
Don't know how to build task 'assets:precompile:pretty_text' (See the list of available tasks with `rake --tasks`)
Did you mean? assets:precompile
```
공식 설치 지침의 일부로 제공되는 main 브랜치에 이런 호환성 깨짐 변경 사항이 어떻게 병합될 수 있는 걸까요? 빌드 실패는 무시되고 있는 건가요? 제가 보고 있는 동일한 오류가 실패 로그에 그대로 적혀 있습니다:
>
이전 커밋으로 체크아웃하여 마이그레이션 단계를 계속 진행할 수는 있었지만, 이제 테스트되지 않은 커밋이 main에 병합되어 업그레이드가 깨지는 경우가 2번 연속으로 발생했습니다.
---
### Author:  [@featheredtoast](https://meta.discourse.org/u/featheredtoast)
#### Post date: [9월 7, 2026, 1:40오전 UTC](https://meta.discourse.org/t/what-to-know-before-upgrading-from-v3-4-0-to-v2026-7-2/411291/5 "2026-09-07T01:40:22Z")
안녕하세요 @corywright, 죄송합니다 - 현재 ESR에는 해당 작업이 없으며, 패치는 [여기](https://github.com/discourse/discourse_docker/pull/1126)에서 진행 중입니다.
조금만 있으면 수정할 수 있을 것이며, 향후 회귀를 방지하기 위해 ESR 타깃을 스모크 테스트 타깃으로 추가하겠습니다.
---
### Author:  [@corywright](https://meta.discourse.org/u/corywright)
#### Post date: [9월 7, 2026, 4:47오후 UTC](https://meta.discourse.org/t/what-to-know-before-upgrading-from-v3-4-0-to-v2026-7-2/411291/6 "2026-09-07T16:47:00Z")
장소에 대한 업그레이드 대신 이 옵션을 제안해 주셔서 다시 한번 감사드립니다. 이 방법이 훨씬 더 잘 작동했으며, 새 OS의 깨끗한 복사본으로 시작할 수 있었습니다.