개발 공부를 하다 보면 새로운 단어가 끝없이 쏟아지죠. Monolith, Microservices, Hexagonal, DDD, CQRS, Event Sourcing, Serverless, Service Mesh… 누군가는 "요즘은 다 마이크로서비스"라고 하고, 또 누군가는 "Amazon이 모놀리스로 돌아갔다더라"라고 해요. 결론부터 말하면 패턴에는 정답이 없어요. 모든 패턴은 그 시대의 특정한 문제에 대한 답이고, 새 패턴은 이전 패턴의 한계 위에서 태어나거든요. 그래서 봐야 할 건 "최신"이 아니라 "왜"예요. 패턴이 진화하는 네 가지 압력 새 패턴은 "더 멋있어서" 나오지 않아요. 항상 네 가지 압력이 동시에 작용해요. 하드웨어와 인프라의 변화 서버가 비쌌던 시절에는 하나의 머신에 모든 걸 욱여넣을 수밖에 없었어요. 클라우드가 등장하면서 서버는 일회용품이 됐고, 컨테이너와 쿠버네티스가 보편화되면서 배포 비용은 거의 0에 수렴했죠. 할 수 있게 된 것은 곧 해야 하는 것으로 바뀌어요. 인프라가 가능하게 만든 일은 결국 누군가 시도하고, 그게 패턴이 돼요. 조직 규모의 변화 (Conway's Law) 1968년 Melvin Conway는 이렇게 썼어요. "시스템 구조는 그것을 만든 조직의 의사소통 구조를 닮는다." 5명짜리 팀이 만드는 시스템과 500명짜리 회사가 만드는 시스템은 절대 같을 수 없어요. 5명은 한 코드베이스에서 충돌 없이 일할 수 있지만, 500명은 불가능하거든요. Microservices는 기술적 결정이기 전에 조직적 결정이에요. 이전 패턴의 약점이 드러난다 새 패턴은 항상 이전 패턴이 일정 규모를 넘었을 때 터지는 지점에서 태어나요. Monolith → (배포가 무서워진다) → Microservices → (서비스 간 통신 지옥) → Service Mesh, Event-Driven → (분산 트랜잭션 문제) → Saga, Eventual Consistency 모든 처방은 새로운 부작용을 낳고, 그 부작용이 다음 패턴의 출발점이 돼요. 비즈니스 요구사항의 변화 예전에는 "내일까지 처리되면 됐던" 일이, 이제는 "1초 안에 알림이 와야 하는" 일이 됐어요. 한국에서만 팔던 서비스가 글로벌이 되기도 하죠. 비즈니스의 속도와 범위가 바뀌면 시스템도 따라가요. 시대별로 따라가 보는 아키텍처의 역사 각 시대가 어떤 문제에 직면했고 어떻게 풀었는지를 보면 흐름이 잡혀요. 1970~80년대: 절차적 시대 메모리는 KB 단위, CPU는 MHz, 프로그램은 한 사람이 다 짜던 시절이에요. 문제는 "어떻게 하면 자원을 아끼면서 동작하는 프로그램을 만들까"였고, 답은 절차적 프로그래밍과 구조적 프로그래밍이었어요. 이 시대의 코드는 본질적으로 함수의 나열이었어요. C언어가 대표적이죠. "GOTO를 쓰지 말고 함수로 나누자"는 게 당대의 큰 진보였어요(Dijkstra의 그 유명한 "GOTO Considered Harmful", 1968). 1990년대: 객체지향과 MVC의 시대 PC가 보급되고 GUI가 등장하면서 프로그램이 점점 커져요. 코드가 1만 줄을 넘어가면 함수만으로는 관리가 안 되고, UI까지 붙으니 더 복잡해지죠. 답은 객체지향 프로그래밍(OOP)과 MVC(Model-View-Controller)였어요. OOP는 데이터와 그것을 다루는 동작을 묶어서 "객체"로 보자는 발상이에요. Smalltalk가 시작이었지만 Java(1995)가 대중화시켰죠. MVC는 Trygve Reenskaug가 1979년에 제안했지만, 본격적으로 쓰인 건 GUI와 웹이 보편화된 90~2000년대예요. 2000년대 초반: 엔터프라이즈와 Layered Architecture 닷컴 버블 이후 은행, 보험사, 대기업이 본격적으로 웹 기반 시스템을 구축해요. 비즈니스 로직은 거대해지고, 수십 명의 개발자가 같은 시스템에 손을 대죠. 답은 Layered Architecture(N-tier)였어요. Controller → Service → Repository → DB. 이 구조는 지금도 압도적으로 많이 쓰이고, Java EE와 Spring이 표준이 됐어요. 이 시대의 또 하나의 큰 사건은 DDD(Domain-Driven Design)의 등장이에요. Eric Evans가 2003년에 책을 출간하며 정립했는데, 핵심은 "비즈니스 도메인을 코드 구조의 중심에 두자"는 거예요. Aggregate, Bounded Context 같은 개념이 여기서 나왔어요. DDD는 Layered/Clean Architecture와 결합해서 써요. Layered가 "그릇의 모양"이라면, DDD는 "그릇 안에 담길 객체를 어떻게 빚을 것인가"에 대한 답이거든요. 2000년대 중후반: SOA의 실험 회사 안에 시스템이 너무 많아져요. 결제, 회원, 상품 시스템이 따로 도는데 서로 데이터를 주고받아야 하죠. 여기서 나온 답이 SOA(Service-Oriented Architecture)예요. SOA는 Microservices의 조상이에요. 다만 당시엔 ESB(Enterprise Service Bus)라는 무거운 미들웨어를 통해 통신했어요. 이게 너무 무겁고 복잡해서 SOA는 결국 "이론은 좋지만 실패한 실험"으로 평가받게 되죠. 그래도 그 정신은 살아남아 2010년대에 다른 형태로 부활해요. 2010년대 초반: 클라우드와 Microservices의 시대 AWS가 자리를 잡고(EC2는 2006년 출시지만 대중화는 2010년대), 컨테이너가 등장하고(Docker, 2013), 스마트폰이 폭발하며 트래픽이 수천 배로 늘어나요. Monolith로는 더 이상 안 되는 순간이 와요. 한 줄 고치면 전체를 배포해야 하고, 한 부분이 죽으면 전체가 죽거든요. 팀은 100명, 1000명으로 커지는데 한 코드베이스를 같이 만지려니 지옥이고요. Netflix가 이 흐름의 대표 주자예요. 2008년 데이터센터 장애로 며칠 동안 서비스가 멈춘 사건을 계기로, 모놀리스를 버리고 AWS 위에서 마이크로서비스로 전환했어요. 그 과정에서 만들어진 도구들(Eureka, Hystrix, Zuul)은 OSS로 공개되어 업계 표준이 됐죠. Amazon은 그보다 일찍, 2002년 Jeff Bezos의 유명한 "API Mandate"로 내부 시스템을 모두 API로 통신하게 만들었고, 이게 결과적으로 AWS의 탄생으로 이어졌어요. 이 시대의 부산물로 나온 패턴들도 같이 보면 좋아요. API Gateway — 클라이언트가 수십 개의 마이크로서비스를 다 알 수는 없으니 하나의 입구를 만들자 BFF (Backend For Frontend) — 모바일과 웹은 필요한 데이터가 다르니 클라이언트별로 게이트웨이를 따로 두자. Netflix와 SoundCloud가 선도했어요 Circuit Breaker — 한 서비스가 죽었을 때 다른 서비스가 끝없이 기다리지 않게 차단하자. Netflix의 Hystrix가 대표예요 2010년대 중반: 비동기와 Event-Driven 마이크로서비스가 늘어나면서 동기 통신의 한계가 드러나요. A → B → C → D를 순서대로 호출하면 D가 느릴 때 전체가 느려지거든요. 그래서 나온 답이 Event-Driven Architecture, 그리고 Kafka예요. LinkedIn에서 시작한 Kafka(2011)는 이 시대의 가장 중요한 인프라예요. "이벤트를 로그로 저장하고 누구든 구독할 수 있게 한다"는 단순한 발상이 분산 시스템의 통신 방식을 바꿨죠. 이 흐름에서 같이 떠오른 패턴들이에요. CQRS (Command Query Responsibility Segregation) — 읽기와 쓰기를 다른 모델로 분리. 읽기 트래픽이 압도적으로 많은 시스템(예: 트위터 타임라인)에서 유용해요 Event Sourcing — 상태를 저장하지 않고 이벤트의 흐름을 저장. 모든 변경이 추적되니 감사가 중요한 도메인(은행, 보험)에 적합해요 Saga Pattern — 분산 트랜잭션을 보상 트랜잭션으로 처리. 주문이 실패하면 결제 취소를 자동으로 트리거하는 식이에요 2010년대 후반: Container, Kubernetes, Service Mesh 마이크로서비스가 100개, 1000개씩 되면서 운영 복잡도가 폭발해요. 답은 Kubernetes(2014, Google이 OSS로 공개)와 Service Mesh(Istio 2017, Linkerd 등)였어요. Kubernetes는 "컨테이너 오케스트레이션"의 표준이 됐어요. 여러 머신에 흩어진 컨테이너를 자동으로 배치하고, 복구하고, 확장해요. Service Mesh는 한 단계 더 나아가서 서비스 간 통신 자체를 인프라 레벨에서 처리해요. 재시도, 인증, 트래픽 분산 같은 걸 애플리케이션 코드에서 빼서 사이드카 프록시(Envoy)로 옮기는 거죠. 2010년대 후반~2020년대: Serverless AWS Lambda(2014)가 등장하면서 "서버를 관리할 필요가 없다"는 발상이 나와요. 트래픽이 들쭉날쭉한 워크로드나, 한 달에 몇 번 도는 배치 작업에 24시간 서버를 띄워두는 건 낭비였거든요. Serverless/FaaS(Function as a Service)는 함수 단위로 배포하고, 호출될 때만 비용이 발생해요. 이미지가 업로드되면 썸네일을 만들고 결제가 들어오면 알림을 보내는 식의 이벤트 기반 워크로드에 특히 잘 맞아요. AWS Lambda, Vercel, Cloudflare Workers가 대표적이에요. 2020년대: 회귀와 재평가 여기서부터 흥미로워요. 유행이 돌고 있거든요. Modular Monolith의 부활 — "마이크로서비스 가기 전에 모놀리스를 잘 모듈화하자"는 흐름. Shopify가 대표적이에요 Amazon Prime Video의 회귀(2023) — 마이크로서비스로 만든 비디오 모니터링 시스템을 다시 모놀리스로 합쳐서 비용을 90% 줄였다는 글이 화제가 됐어요 DHH(Basecamp/Hey 창업자)의 "Majestic Monolith" — 작은 팀에는 모놀리스가 답이라는 주장이에요 핵심은 이거예요. 마이크로서비스가 틀린 게 아니라, 모든 곳에 마이크로서비스를 적용한 것이 틀렸던 거죠. 한 장으로 압축한 흐름 [1970s] 절차적 ↓ (프로그램이 커진다) [1990s] OOP, MVC ↓ (엔터프라이즈 시스템이 거대해진다) [2000s] Layered, DDD, SOA ↓ (클라우드와 모바일이 폭발한다) [2010s] Microservices, Event-Driven, Kubernetes ↓ (운영 복잡도가 폭발한다) [2020s] Modular Monolith, Serverless, "필요한 만큼만" 각 화살표를 보면 알 수 있어요. 새 패턴은 이전 패턴이 부족해서가 아니라 환경이 바뀌어서 등장해요. 그리고 환경이 다시 바뀌면, 옛 패턴이 새 옷을 입고 돌아와요. 회사마다 선택이 다른 이유 같은 시대에도 회사마다 다른 패턴을 써요. 각자의 문제가 다르기 때문이에요. 회사 주요 패턴 이유 Netflix Microservices, BFF, Circuit Breaker 글로벌 스트리밍, 장애 회복력이 생명 Amazon Microservices(API Mandate), Event-Driven 거대한 조직, 독립 배포 필수 Uber Event-Driven, DDD 실시간 매칭, 복잡한 도메인 LinkedIn Kafka 기반 Event Streaming 대규모 데이터 파이프라인 Shopify Modular Monolith 빠른 개발, 명확한 도메인 분리 Basecamp/Hey Majestic Monolith 작은 팀, 빠른 의사결정 Stack Overflow Monolith(여전히!) 단순한 도메인, 비용 효율 Discord Elixir 기반, 일부 Rust 마이크로서비스 동시성, 성능 핫스팟 특히 Stack Overflow가 인상 깊어요. 전 세계 톱 50 사이트인데 여전히 모놀리스거든요. 마이크로서비스를 몰라서가 아니라, 자기 문제에 모놀리스가 더 적합하다고 판단했기 때문이에요. 패턴을 대하는 자세 "최신"보다 "왜"를 보기 새 패턴이 나왔다고 무조건 따라가면 안 돼요. 그 패턴이 어떤 문제를 풀려고 만들어졌는지를 먼저 물어야 해요. 내 시스템에 그 문제가 없다면, 그 패턴은 오버엔지니어링이에요. 패턴은 트레이드오프의 모음 모든 패턴은 무언가를 얻고 무언가를 잃어요. Microservices — 독립 배포 ↔ 분산 시스템 복잡도 Event-Driven — 느슨한 결합 ↔ 디버깅 어려움, 일관성 문제 CQRS — 읽기 성능 ↔ 코드 복잡도, 일관성 지연 Serverless — 운영 부담 감소 ↔ 콜드 스타트, 벤더 종속 공짜 점심은 없어요. 무엇을 얻기 위해 무엇을 포기할 것인가가 항상 핵심이에요. 조직과 비즈니스를 보기 기술적 패턴 선택은 항상 조직과 비즈니스의 함수예요. 아래 질문에 답하지 않고 패턴을 고르면 반드시 후회해요. 팀이 5명인가, 500명인가? 트래픽이 안정적인가, 들쭉날쭉한가? 도메인이 단순한 CRUD인가, 복잡한 비즈니스 규칙인가? 비용 민감도가 높은가, 성능이 우선인가? 점진적으로 가기 모든 글로벌 기업은 모놀리스로 시작했어요. Amazon도, Netflix도, Uber도요. 그들은 문제가 생긴 후에야 마이크로서비스로 갔어요. 처음부터 마이크로서비스로 시작한 스타트업의 80%는 인프라 복잡도에 발목이 잡혀요. Start with a monolith. Extract services when the pain is real. 그래서 지금 뭘 공부하면 좋을까 백엔드 개발자가 학습 순서를 정한다면 이런 흐름을 추천해요. Layered Architecture를 진짜로 짜보기 — Spring Boot든 Django든 Express든 상관없어요 그 코드를 Hexagonal로 리팩토링해보기 — 의존성 역전이 몸으로 와닿을 때까지 간단한 DDD 개념을 적용해보기 — Aggregate, Value Object 정도면 충분해요 이벤트 기반 통신을 한 번 써보기 — Kafka든 RabbitMQ든 그다음에 Microservices, CQRS, Event Sourcing 보기 — 아마 그때쯤이면 왜 필요한지가 보일 거예요 나머지는 그 패턴이 필요한 순간이 올 때 공부하면 돼요. 미리 다 배우려고 하면 깊이 없는 지식만 쌓이거든요. 마치며 아키텍처 패턴의 역사는 결국 "우리는 점점 더 큰 시스템을, 점점 더 큰 조직으로, 점점 더 빠르게 만들어야 한다"는 압력의 역사예요. 패턴은 그 압력에 대한 답이고, 압력이 바뀌면 답도 바뀌죠. 그러니 "이게 정답이다"라고 말하는 사람은 경계하는 게 좋아요. 정답은 항상 "무엇에 대한 답인가?"라는 질문 뒤에만 존재하거든요. 다음에 새로운 패턴 이름을 들었을 때, 이렇게 물어보세요. "이 패턴은 어떤 문제를 풀려고 나왔는가? 내게 그 문제가 있는가?" 그 질문이 기술 트렌드의 파도 속에서 길을 잃지 않게 해줄 거예요. 더 읽어볼 자료 Domain-Driven Design — Eric Evans (2003) Building Microservices — Sam Newman Designing Data-Intensive Applications — Martin Kleppmann Martin Fowler 블로그 — 패턴의 정의와 트레이드오프 Software Architecture: The Hard Parts — Neal Ford et al. Amazon Prime Video의 모놀리스 회귀 글 (2023) DHH의 "The Majestic Monolith" 블로그 It isn't what happens to us that causes us to suffer; it's what we say to ourselves about what happens.— Pema Chodron

"내가 왜 사는지, 내 인생의 의미가 뭔지부터 알아야겠어." 이런 마음으로 한참을 멈춰 서 있어 본 적 있으실 거예요. 저도 그랬어요. 그런데 요즘은 이 순서가 거꾸로가 아닐까 하는 생각이 들어요. 『진격의 거인』을 보다가 문득 이런 메모를 남겼어요. 제목 그대로 "진격", 그러니까 앞으로 나아간다는 말이 계속 마음에 남았거든요. 의미를 다 알고 나서 움직이는 게 아니라, 일단 나아가는 사람들의 이야기였어요. 의미는 시작 조건이 아니라 결과예요 우리는 보통 의미를 먼저 찾아야 움직일 수 있다고 생각해요. 이게 내 길이 맞는지, 이 일이 나한테 무슨 뜻인지 확실해진 다음에야 발을 떼려고 하죠. 그런데 순서를 뒤집어 보면 이렇게 돼요. 의미는 시작 조건이 아니라 결과일 수 있다고요. 먼저 살아내고, 관계를 맺고, 책임을 지고, 뭔가를 해내는 과정 속에서 나중에 "아, 이게 내 의미였구나" 하는 게 따라오는 구조인 거예요. 그래서 존재를 의미보다 앞에 둔다는 건, 이런 태도에 가까워요. 완벽한 의미를 찾을 때까지 멈춰 있기보다 불완전해도 지금 살아서 해보기를 택하는 것 의미를 찾으려고 아무것도 하지 않으면, 오히려 의미를 찾기가 더 어려워져요. 살아야 의미가 생기고, 움직여야 이유가 보이거든요. 사랑도 비슷하게 움직여요 이 이야기는 사랑에서도 똑같이 반복돼요. 에리히 프롬의 『사랑의 기술』을 보면, 성숙한 사랑은 감정의 강도에서 오는 게 아니라고 해요. 우리는 흔히 사랑을 느낌이라고 생각하잖아요. 심장이 뛰고, 설레고, 상대에게 온통 마음이 쏠리는 그 강렬함이 사랑의 크기라고요. 그런데 그 강도는 시간이 지나면 옅어지기 마련이에요. 성숙한 사랑은 감정보다 반복되는 선택에서 만들어져요. 존중하고, 책임지고, 배려하고, 인내하는 태도를 매일 다시 고르는 거죠. 그래서 사랑은 저절로 주어지는 느낌이 아니라, 훈련된 태도에 가까워요. 정리하면 메모를 남기고 나서 제 안에 남은 문장은 세 개예요. 의미는 발견물이 아니라, 실행의 부산물일 수 있어요. 살아야 의미가 생기고, 움직여야 이유가 보여요. 사랑은 느낌이 아니라 훈련된 태도예요. 세 문장 모두 결국 같은 이야기를 하고 있어요. 완벽한 답을 손에 쥔 다음에 살려고 하면, 그 답은 좀처럼 오지 않아요. 반대로 불완전한 채로 한 걸음 내딛으면, 살아내는 과정 자체가 답을 데려와요. 그러니 지금 의미가 흐릿하다고 멈춰 있을 필요는 없어요. 오늘 할 수 있는 걸 하나 해보는 게, 의미를 찾는 가장 빠른 길일지도 몰라요. Life can only be understood backwards; but it must be lived forwards.— Søren Kierkegaard

솔직히 말하면, 저도 이런 질문을 품은 적이 있어요. 은둔·고립 청년 이야기를 들으면 이런 생각이 먼저 들잖아요. 집에서 유튜브 보고, 릴스 넘기고, 게임하고, 웹툰 정주행하고. 배가 고프면 배달을 시키고, 필요한 건 쿠팡으로 받고. 이제는 굳이 밖에 나가지 않아도 웬만한 생활이 다 되는 세상이니까요. 세상이 그만큼 좋아진 거죠. 그러다 보면 생각이 이런 데까지 흘러가요. 자기만의 공간에서, 하고 싶은 걸 최대한 자유롭게 하고 있는 사람을 왜 굳이 "우울하고 도와줘야 하는 사람"으로 봐야 하지? 돈을 안 벌어서? 요즘은 게임 안에서 돈을 버는 사람도 있는데. 오히려 도와준다는 명목으로 그 사람이 지금 하고 싶은 걸 못 하게 막고, 생활을 통째로 바꾸려는 거 아닌가? 부끄럽지만 저는 여기까지 생각이 닿은 적이 있어요. 그리고 이 질문은, 아마 많은 사람이 입 밖으로 꺼내지 않을 뿐 속으로는 한 번쯤 해봤을 질문이라고 생각해요. 그런데 얼마 전에 서울청년기지개센터에 다녀왔어요. 그러고 나서 질문이 조금 바뀌었어요. "집에서도 살 만해진 것"이 위로가 아닐 수도 있어요 가장 먼저 흔들린 건 "세상이 좋아져서 집에서도 살 만하잖아"라는 전제였어요. 맞아요. 배달앱, 스트리밍, 게임, 온라인 쇼핑. 예전 같으면 밖에 나가야만 해결됐던 일들이 이제 문 안에서 다 끝나요. 그런데 곰곰이 생각해보면, 예전에 사람을 다시 세상으로 끌어내던 건 대단한 계기가 아니었어요. 밥을 사러 나가다 마주친 편의점 알바, 물건을 사며 나눈 몇 마디, 어쩔 수 없이 나가야 했던 사소한 마찰들. 그런 작은 접촉들이 사람을 계속 세상에 붙들어 두고 있었던 거예요. 기술은 그 마찰을 전부 없앴어요. 편리해진 거죠. 그런데 같은 이유로, 이제는 누군가 세상에서 조용히 사라져도 당장은 아무 일도 일어나지 않게 됐어요. 굶지도 않고, 크게 불편하지도 않게. 죽지 않고도 사라질 수 있게 된 거예요. 그래서 "집에서도 살 만해졌다"는 말은, 이제 저한테는 위로처럼 안 들려요. 오히려 가장 조용한 위험 신호처럼 들려요. '자유롭게 하고 싶은 걸 한다'는 착시 두 번째로 걸린 건 "하고 싶은 걸 자유롭게 하는 건데 왜 막냐"는 부분이었어요. 이 논리에는 사실 제가 놓친 구멍이 하나 있었어요. 은둔·고립을 이야기할 때 거의 빠지지 않는 말이 있거든요. 본인들도 이러면 안 된다는 걸 안다는 거예요. 여기서 앞뒤가 안 맞아요. 정말 자유로운 선택이라면, 이러면 안 된다는 마음이 들 이유가 없잖아요. 나오고 싶은데 나올 방법을 잃은 상태, 매일 "내일은 다르게 살아야지" 하면서 그 문턱을 못 넘는 상태. 그건 자유가 아니라 갇힘에 가까워요. 그러니까 정확히는, 하고 싶은 걸 하는 게 아니라 할 수 있는 게 그것밖에 남지 않은 거예요. 선택지가 하나로 줄어든 걸 두고 "자유"라고 부르면 안 되는 거였어요. '내부 노숙자'라는 말을 다시 읽으면 한때 저는 은둔 청년을 '내부 노숙자' 같은 거라고 삐딱하게 생각한 적도 있어요. 집 안에 있을 뿐, 사회에서 떨어져 나온 건 비슷하지 않냐고요. 그런데 이 말을 뒤집어 보면 오히려 핵심이 보여요. 노숙자는 집을 잃은 사람이에요. 은둔 청년은 집은 있는데 문 밖의 세상을 잃은 사람이고요. 잃어버린 게 달라 보이지만, 결국 둘 다 잃은 건 같아요. 세상과의 연결이요. 노숙자에게 필요한 게 비난이 아니라 다시 몸 누일 자리이듯, 은둔 청년에게 필요한 것도 "왜 그러고 사냐"는 낙인이 아니라 다시 이어질 자리예요. 사실 낙인이 문제라는 처음의 제 생각은 반쯤은 맞았어요. 도와줘야 할 불쌍한 사람으로 규정하는 순간, 나오기가 더 어려워지거든요. 다만 낙인을 걷어낸 자리에 필요한 건 방치가 아니라 열린 문이었어요. 방향이 틀렸을 뿐이에요. 그래서 '돕는다'는 건 이제 처음 질문으로 돌아가 볼게요. "왜 도와줘야 하냐, 강제로 생활을 바꾸는 거 아니냐." 기지개센터에서 제가 본 건 누군가를 억지로 끌어내는 모습이 아니었어요. 오히려 반대였어요. 기지개라는 이름부터가 그래요. 기지개는 남이 억지로 일으켜 세우는 게 아니잖아요. 잠에서 깰 때, 자기 몸이 준비됐을 때 스스로 켜는 거예요. 옆에서 할 수 있는 건 그때까지 방을 너무 춥지 않게 해두고, 깼을 때 나올 수 있는 문을 열어두는 정도예요. 돕는다는 건 그 사람의 지금을 부정하고 뜯어고치는 게 아니었어요. 나오고 싶어졌을 때 나올 다리를 놓아두는 것, 돌아올 자리를 비워두는 것. 그게 도움이었어요. 그리고 이건 은둔·고립 청년만을 위한 이야기가 아니에요. 한때 "왜 도와줘야 하냐"고 물었던 저 같은 사람을 위한 이야기이기도 해요. 우리가 조금 덜 낙인찍고, 자리를 조금 더 비워두면. 지금 문 안에 있는 누군가는, 자기가 준비됐을 때 그 문이 아직 열려 있다는 걸 알게 될 테니까요. 집이 있는데 갈 곳이 없다는 건, 갈 곳을 영영 잃었다는 뜻이 아니에요. 아직 그 문을 안 열었을 뿐이에요. 그러니 우리가 할 일은 그 문을 대신 부수는 게 아니라, 잠그지 않고 두는 거예요. Without some goals and some efforts to reach it, no man can live.— John Dewey