# Stash - AI 에이전트를 위한 지속형 메모리 계층 > Clean Markdown view of GeekNews topic #28917. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28917](https://news.hada.io/topic?id=28917) - GeekNews Markdown: [https://news.hada.io/topic/28917.md](https://news.hada.io/topic/28917.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-27T08:34:31+09:00 - Updated: 2026-04-27T08:34:31+09:00 - Original source: [alash3al.github.io](https://alash3al.github.io/stash?_v01) - Points: 1 - Comments: 1 ## Topic Body - 세션이 바뀌어도 대화와 작업 맥락을 이어가는 **지속형 메모리 계층**으로, 원시 관찰을 episodes로 저장한 뒤 구조화된 지식으로 누적함 - **모델 비종속적 구조**를 사용해 Claude, GPT, 로컬 LLM, 커스텀 에이전트까지 같은 메모리 계층에 붙일 수 있으며, 저장소는 PostgreSQL과 pgvector를 기반으로 동작함 - **RAG와 다른 역할**을 맡아 문서 검색에 머무르지 않고, 대화에서 새 사실과 관계, 목표, 실패, 가설까지 축적하며 RAG와 함께 사용할 수 있음 - namespace와 계층형 경로로 사용자, 프로젝트, 에이전트 자기지식을 분리하고, consolidation 파이프라인으로 facts, relationships, causal links, patterns, contradictions를 계속 합성함 - **MCP 네이티브 통합**과 `/self` 기반 자기 모델, 반복 연구 루프까지 포함해 기억이 없는 세션형 에이전트를 장기적 연속성을 가진 작업 주체로 바꾸려 함 --- ### Stash 개요 - **지속형 메모리 계층**으로 AI 에이전트와 외부 세계 사이에 놓이며, 세션이 바뀌어도 이전 맥락을 이어가게 만듦 - 원시 관찰을 **episodes**로 저장하고, 이를 facts, relationships, patterns, goals, failures, hypotheses 같은 구조화된 지식으로 누적함 - 모델 자체를 대체하지 않고 연속성을 보강하며, Claude, GPT, 로컬 모델 등 **어떤 에이전트에도** 붙일 수 있게 설계됨 - 저장 기반으로는 **PostgreSQL + pgvector**를 사용함 - [GitHub](https://github.com/alash3al/stash) ### 메모리 구성 방식 - **namespace**로 사용자, 프로젝트, 에이전트 자기지식 같은 메모리를 분리함 - 각 namespace는 **계층형 경로**로 구성되며, `/projects`를 읽으면 `/projects/stash`, `/projects/cartona` 같은 하위 경로까지 함께 포함됨 - 쓰기는 하나의 정확한 namespace에만 기록돼 **메모리 오염**을 막음 - 사용자 관련 메모리와 프로젝트 메모리, `/self` 아래의 자기지식은 서로 섞이지 않게 유지됨 - 예시 구조로 `/users/alice`, `/projects/restaurant-saas`, `/projects/mobile-app`, `/self/capabilities`, `/self/limits`, `/self/preferences`를 둠 ### RAG와의 차이 - **RAG**는 문서에서 관련 내용을 찾아오는 검색 계층에 가깝고, 대화 자체를 기억하거나 학습하지 않음 - RAG는 문서에 이미 들어 있는 내용만 다룰 수 있으며, **대화에서 새 지식**을 만들지 못함 - 목표 추적, 의도 파악, 시간에 따른 모순 탐지, 원인과 결과에 대한 추론은 RAG 범위 밖으로 제시됨 - **Stash**는 대화, 결정, 성공, 실패에서 자동으로 학습하고 지식 그래프를 쌓아 감 - 문서 검색과 경험 기억은 서로 다른 문제를 다루므로, RAG와 Stash를 **함께 사용할 수 있음** ### 기존 AI 메모리와 다른 점 - Claude.ai와 ChatGPT에도 메모리가 있지만, 해당 기능은 **자기 플랫폼과 자기 모델**에 묶여 있음 - Stash는 **모델 비종속적**으로 동작하며, 로컬 모델과 프라이빗 모델에도 붙일 수 있음 - 데이터 소유권을 사용자 쪽에 두고, **오픈소스**로 제공됨 - 백그라운드 consolidation, goals 및 intent 추적, failures 학습, causal reasoning, agent self-model 같은 항목을 포함함 - 비교표 기준으로 ChatGPT Memory와 Claude.ai Memory는 “notepad”, Stash는 “**mind**”로 구분됨 ### 해결하려는 문제 - 현재 AI 모델은 추론은 잘해도 **세션 간 기억**이 없어, 사용자가 매번 자신과 프로젝트 배경을 다시 설명하게 됨 - 긴 대화 기록을 매번 프롬프트에 넣는 방식은 **느리고 비싸며**, context window 한계도 남아 있음 - 실패한 시도를 다음 세션에서 다시 반복하지 않게 막아 줄 **교훈 전달 메커니즘**이 부족함 - 메모리 기능이 일부 플랫폼의 전용 기능으로만 제공돼, 커스텀 에이전트나 로컬 LLM은 처음부터 맥락 없이 시작하게 됨 ### 통합 파이프라인 - 백그라운드 프로세스가 경험을 계속 합성해 **원시 메모리**를 구조화된 지식으로 바꿈 - **Episodes** 단계에서 관찰을 append-only로 저장함 - **Facts** 단계에서 episode 묶음을 LLM으로 합성함 - **Relationships** 단계에서 fact 사이의 엔티티 관계를 추출함 - **Causal Links** 단계에서 fact 간 원인-결과 쌍을 연결함 - **Patterns** 단계에서 더 높은 수준의 추상 패턴을 도출함 - **Contradictions** 단계에서 자기 수정과 confidence decay를 수행함 - **Goal Inference**로 활성 목표에 대한 사실을 자동 추적하고 진행 상황과 충돌을 드러냄 - **Failure Patterns**로 반복 실수를 감지하고 새로운 사실로 추출해 같은 실패 반복을 줄임 - **Hypothesis Scan**으로 새로운 증거가 열린 가설을 수동 개입 없이 확인하거나 기각하게 함 ### MCP 통합 - **MCP 네이티브**로 동작하며 Claude Desktop, Cursor, OpenCode, 커스텀 에이전트, 로컬 LLM, 기타 MCP 클라이언트에 붙일 수 있음 - SDK 없이 연결할 수 있고, **vendor lock-in** 없이 어디서든 같은 메모리 계층을 쓰게 함 - 총 **28개 도구**를 제공하며 remember, recall, forget, init부터 causal links, contradictions, hypotheses까지 포함함 - `./stash mcp execute --with-consolidation`으로 stdio MCP 서버와 consolidation을 함께 시작할 수 있음 - `./stash mcp serve --port 8080 --with-consolidation`으로 원격 에이전트용 SSE 서버를 띄울 수 있음 ### 에이전트 자기 모델 - `init` 호출 시 `/self` namespace 뼈대를 만들어 **자기 모델** 구성을 시작함 - `/self/capabilities`에는 에이전트가 잘하는 일을 기억해 작업 계획에 활용함 - `/self/limits`에는 실패 기록과 약점을 저장해 **같은 실수 반복**을 막게 함 - `/self/preferences`에는 가장 잘 작동하는 운영 방식을 학습해 장기적으로 작업 스타일을 형성함 ### 자율 학습 루프 - 5분 단위 **research loop**를 돌리면 과거 메모리에서 현재 맥락을 잡고, 스스로 주제를 골라 조사하고, 새 연결을 만들고, 다시 통합한 뒤 종료함 - **Orient** 단계에서 과거 맥락, 활성 목표, 열린 가설, 과거 실패를 불러옴 - **Research** 단계에서 에이전트가 직접 고른 주제로 웹 검색을 수행함 - **Think** 단계에서 현재 아는 내용 안의 긴장, 빈틈, 모순을 드러냄 - **Invent** 단계에서 가설, 패턴, 발견 같은 새 산출물을 만듦 - **Consolidate** 단계에서 파이프라인을 실행해 원시 episode를 구조화된 지식으로 합성함 - **Reflect + Sleep** 단계에서 세션 요약을 남기고 다음 실행을 위한 맥락을 설정한 뒤 멈춤 - [루프 프롬프트 보기](https://github.com/alash3al/stash) ### 모델 및 인프라 호환성 - embedding과 reasoning 모두에 **OpenAI 호환 API**를 사용하는 하나의 provider 구성을 전제로 함 - 클라우드, 로컬, self-hosted 구성을 모두 지원하며 **vendor lock-in**이 없다고 밝힘 - OpenRouter를 로컬에서 연결해 사용 중이라고 적고, 수백 개 모델을 하나의 API 키로 접근할 수 있게 함 - Ollama와도 바로 동작하며, Qwen, Llama, Mistral 같은 로컬 모델로 **오프라인 메모리** 구성이 가능함 - vLLM, LM Studio, llama.cpp server, Together AI, Groq처럼 OpenAI API 형식을 쓰는 백엔드도 지원 대상으로 적음 - 기본 embedding 모델은 `openai/text-embedding-3-small`이고, 그 조합에서 `STASH_VECTOR_DIM=1536`을 사용함 - `STASH_VECTOR_DIM`은 **첫 실행 전에만** 설정할 수 있으며, 초기화 후 바꾸면 전체 데이터베이스 재설정이 필요함 ### 배포 및 사용 정보 - Docker Compose로 **Postgres, pgvector, Stash**를 함께 올리는 구성을 제공함 - 실행 절차는 저장소 clone, `.env.example`을 `.env`로 복사한 뒤 API 키와 모델을 설정하고 `docker compose up`을 실행하는 3단계로 제시됨 - 초기 실행 후 postgres + pgvector 준비, migration 적용, MCP 서버 대기, 백그라운드 consolidation 실행 상태를 기대함 - 프로젝트는 **Apache 2.0** 라이선스로 공개됨 - [GitHub Repository](https://github.com/alash3al/stash) - [alash3al.com](https://alash3al.com/) ## Comments ### Comment 56347 - Author: neo - Created: 2026-04-27T08:34:38+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47897790) - **Claude.ai 메모리 시스템** 같은 걸 드디어 portable하게 만든 줄 알고 눌렀는데, 전혀 그게 아니었음 여기 있는 건 그냥 `store`/`remember` 방식이고, 내가 더 낫다고 느낀 건 백그라운드 모델이 **채팅 기록을 요약**해서 메모리를 만드는 방식임 그쪽은 모델이 직접 메모리를 써야 하지 않아서 훨씬 잘 작동했고, 그래서 이걸 Claude.ai와 같은 수준으로 소개하는 건 다소 misleading하게 보임 나도 **LibreChat** 같은 쪽으로 옮기려고 같은 방식의 메모리 시스템을 계속 찾는 중인데 아직 못 찾았고, 지금 Claude.ai에 남아 있는 거의 유일한 이유가 그 기능임 참고로 그 시스템은 Claude.ai에만 있고 **Claude Code**에는 없음 - 최근 **Claude Code leak**에 따르면 `autoDream`이라는 게 있었고, 여기서는 **background memory consolidation engine**이라고 설명함: [https://kuber.studio/blog/AI/Claude-Code's-Entire-Source-Code-Got-Leaked-via-a-Sourcemap-in-npm,-Let's-Talk-About-it](https://kuber.studio/blog/AI/Claude-Code's-Entire-Source-Code-Got-Leaked-via-a-Sourcemap-in-npm,-Let's-Talk-About-it) - 이 접근은 정말 써보고 싶음 내 경험은 정반대라서, 나는 [https://github.com/flippyhead/ai-brain](https://github.com/flippyhead/ai-brain)을 주로 나 자신을 위해 만들었고 친구 몇 명도 씀 지금까지는 `CLAUDE.md`를 통해 AI에게 **관련 메모리를 찾고**, 언제 어떻게 저장할지 생각하게 하는 방식이 꽤 잘 먹혔음 이 방식은 우선순위에 따라 구조를 만들고 미래를 위한 노트도 남길 수 있어서, 단순히 전부 요약하는 방식과는 꽤 다르게 느껴짐 - 나는 **자동 recall**이 에이전트에게 보이지 않게 동작하는 쪽을 선호함 메모리 생성은 tool call도 꽤 잘하고, 컨텍스트 압축 시 자동으로 메모리를 만드는 방식도 괜찮다고 봄 다만 자동 생성이라면 비동기 **consolidation**이 필요하고, 그걸 dreaming이라고 부르는 건 좀 과장처럼 느껴짐 내 구현은 Elroy.bot에 있고, 여러 접근은 여기 정리해 뒀음: [https://tombedor.dev/approaches-to-agent-memory/](https://tombedor.dev/approaches-to-agent-memory/) - 그걸 **어떻게 벤치마크**하는지가 궁금함 백그라운드에서 메모리를 추출하면 **prefix cache**와 잘 맞추기 어려운 게 문제임 단순한 2단계 `LOG.md`(작업과 교훈의 상세 로그) + `MEMORY.md`(로그가 잘릴 때 승격된 항목 기록) + 턴 종료 시 실행되는 stop hook만으로도 꽤 멀리 갈 수 있음 - 이 개념은 꽤 흥미로움 사용자와 대화하는 에이전트 뒤에서 보조 인력들이 대화를 엿듣고 중요한 사실을 기록하거나, 관련 사실을 DB에서 찾아보다가 `이 메모리 X가 관련 있어 보인다`며 끼어드는 구조처럼 느껴짐 토큰이 공짜라면 쉬워 보이지만, 이걸 **효율적으로** 만드는 건 꽤 재미있는 문제임 - 구현 방식을 거의 안 밝힌 채 뭔가를 약속하는 프로젝트는 늘 **큰 red flag**로 보임 더 파보면 사실상 `pg_vector`에 `mcp`, 그리고 `recall`/`remember` 두 함수가 붙은 구조임 결국 **RAG**에 가깝고, 데이터 구조가 중요하다고 주장할 수는 있어도 지금까지 나온 이런 메모리 시스템들은 거의 다 비슷하게 동작했음 아직은 기본적인 **vector DB search**보다 검색이 더 좋아졌다는 걸 입증한 사례를 못 봤음 - 사이트는 멋지고, `memory`라고 쓰여 있고, LLM은 형편없지만 이 제품은 마법처럼 해결한다고 보여줌 정말 그게 된다면, 결국 **vectordb**를 그럴듯하게 포장한 것에 가깝기도 함 - 이미 리뷰가 있음: [https://zby.github.io/commonplace/agent-memory-systems/reviews/stash/](https://zby.github.io/commonplace/agent-memory-systems/reviews/stash/) 다른 수많은 **LLM memory systems**도 여기 모여 있음: [https://zby.github.io/commonplace/agent-memory-systems/](https://zby.github.io/commonplace/agent-memory-systems/) 그리고 이런 시스템에 바라는 점도 정리해 둠: [https://zby.github.io/commonplace/notes/designing-agent-memory-systems/](https://zby.github.io/commonplace/notes/designing-agent-memory-systems/) - 이런 **agent memory systems**는 과하게 설계된 것 같으면서도 동시에 덜 설계된 것 같고, 꽤 막다른 길처럼 보임 최신 모델이 필요로 하는 것과 금방 어긋나고 썩어버리지 않을 현실이 잘 상상되지 않음 예를 들어 결제 기능을 한 번 만들었다고 해서 `don't use stripe` 같은 메모리 때문에 이후 여러 세션이 자꾸 결제 쪽으로 기울어질 수 있음 - 더 나쁜 건 작성자 본인도 직접 써본 흔적이 너무 없다는 점임 완전히 **unproven memory layer**이고, 실사도 없이 화려한 마케팅 사이트에 과장된 주장만 올린 느낌임 - 나는 이걸 **정보 문제**로 보고, 대부분을 저장하지 않도록 의도한 작은 유틸을 만들었음: [https://github.com/skorokithakis/gnosis](https://github.com/skorokithakis/gnosis) 전제는 단순함. LLM이 원래 아는 내용은 계속 알 테니 LLM이 말한 건 저장하지 않고, 코드 관련 내용은 코드와 주석에 남기면 됨 대신 둘 다 아닌데도 절대 캡처되지 않는 것들이 있음 뭔가를 만들 때는 실제로 한 것보다 **하지 않기로 한 것**이 더 중요할 때가 많고, 이 유틸은 세션 끝에서 기각한 대안들과 그 이유를 잡아내 **system knowledge**로 저장함 결국 코드 grep만으로는 찾을 수 없는, 동료들 머릿속에만 있는 정보를 남기고 싶은 거고 지금까지는 꽤 잘 작동하지만 아직 이르긴 함 - 나는 직접 만든 **bespoke memory system**을 쓰는데, 모든 메모리를 맥락별 검색 공간으로 만들어서 이 문제를 피함 `don't use stripe` 같은 메모리는 모델이 **payment processing** 관련 작업을 하라는 프롬프트를 받았을 때만 컨텍스트로 들어옴 - 이런 걸 계속 찾고 있었고, 계정이 **LLM 붐 이전**부터 소프트웨어를 공개해 온 것도 보여서 반가움 다만 프로젝트마다 `LLM 사용 내역` 같은 게 붙었으면 좋겠음 LLM으로 생성했는지, 했다면 얼마나 했는지, 어느 단계에서 썼는지, 출력은 얼마나 꼼꼼히 검토했는지, 품질이 혼자 만들었을 때보다 최소한 같거나 더 낫다고 느끼는지 같은 정보가 있으면 좋겠음 특정 개인을 의심하려는 게 아니라 모든 프로젝트에 공통으로 있었으면 하고, 나도 그렇게 할 생각임 - 솔직히 이건 좀 **entitled**하게 들림 누가 억지로 이 프로젝트를 쓰라고 하는 것도 아니고, 코드는 직접 읽고 검토한 뒤 쓸지 말지 스스로 판단하면 됨 - 질문 자체는 타당하지만, 당사자 **자기신고**만으로 답하게 둘 수는 없다고 봄 설계도 테스트도 거의 안 했고 코드 품질도 별로라고 솔직히 인정할 사람이 많을 것 같지 않음 오히려 이런 질문에 답하려는 제3자 시스템이 필요할지도 모르겠는데, 물론 그것도 LLM 기반이면 꽤 주관적일 수 있음 - LLM으로 소프트웨어를 만드는 방식은 정말 다양함 나는 요즘 대부분의 프로젝트를 여러 **Markdown 파일** 중심으로 굴리는데, AI로 먼저 조사하고 계획 세우고 구현 진행을 추적함 구현은 계획에 따라 단계적으로 하고 매 단계 검토도 계속함 내 워크플로를 문서화하라고 하면 그 파일들이 바로 그것임 코드의 99%는 생성되지만, 내가 만족하는 방식으로 생성되도록 신경 쓰고 있고 결과도 종종 혼자 만들었을 때보다 더 낫다고 느낌 - 그게 왜 중요한지 잘 모르겠음 **좋은 소프트웨어**도 나쁜 소프트웨어도 LLM 없이도, LLM과 함께도 만들 수 있음 목수에게 망치를 썼는지 nail gun을 썼는지, 지붕과 데크에는 각각 뭘 썼는지 묻지는 않음 신뢰 기반이 없다면 결국 직접 품질을 검증하거나 아예 스스로 만들어야 하고, 그 외에는 희망 섞인 기대에 가깝다고 봄 - 아직 쓸만한 **memory**를 못 찾았음 하나는 `agents.md`처럼 높은 수준 요약만 남겨서 구체적인 디테일, 예를 들면 `이 요소를 수정하면 저 요소를 draft로 표시해야 한다` 같은 정보에는 별 도움이 안 됨 반대로 너무 상세한 방식은 세부가 지나쳐서 무시되거나, 한 기능 영역의 디테일이 다른 영역 변경에까지 오염을 일으킴 결국 지금까지 제일 잘 먹힌 건 **메모리 없이**, 해당 세션/프롬프트에 중요한 컨텍스트만 수동으로 고르는 방식이었음 - 메모리에 관심이 큰 편이지만, 적어도 **코딩용 도구**로는 그다지 유용하다고 보지 않음 저장소가 무엇을 하는지, 무엇을 해야 하는지의 source of truth는 결국 **repo itself**임 지금 말한 건 차라리 코드 리뷰 가이드라인에 가깝고, 그런 건 변경 시점에 맞춰 명시적으로 컨텍스트에 넣으면 됨 메모리 시스템은 여기에 비해 너무 복잡하고 정확성도 떨어짐 - 이런 시스템에 대한 위시리스트는 여기 있음: [https://zby.github.io/commonplace/notes/designing-agent-memory-systems/](https://zby.github.io/commonplace/notes/designing-agent-memory-systems/) - 나도 비슷하게 느낌 언젠가 이런 모델들이 **continual learning**을 갖게 될지 궁금함 이미 충분히 똑똑한데 진짜 메모리가 없어서 다루기 번거롭게 느껴짐 - Claude가 만들어 준 메모리는 거의 전부 **remember-to-not-forget**류라서, 결국 기능을 꺼버렸음 - 내게는 몇 가지 단순한 것들이 꽤 잘 먹힘, 도구는 **Codex** 기준임 1) 항상 최신인 상세 **functional specification** 2) 여러 프로젝트로 구조화된 코드베이스 3) 좋은 네이밍과 문서화가 된 코드. 클래스, 변수, 함수 이름은 아무리 길고 우스워 보여도 목적이 명확해야 하고, 이런 규칙은 `Agent.md`의 코딩 가이드라인에 넣어 둠 내 functional spec은 에이전트에게 `Project.md` 역할을 함 그리고 매번 agentic code review 전에 프로젝트 디렉터리 트리를 만들고, 코드베이스와 합쳐서 단일 파일로 만든 뒤 파일명에 **timestamp**를 붙임 이게 의외로 중요해서 LLM이 오래된 버전을 참조하는 걸 줄여주고, git을 굳이 보내지 않아도 빠르게 diff 보기에도 좋음 지금까지는 큰 규모의 복잡한 코드베이스에서도 이 단순한 워크플로가 꽤 잘 작동했음 토큰 효율은 별로지만 그냥 잘 됨 매번 전체 코드베이스를 다 합칠 필요는 없고, 이미 끝났거나 테스트됐거나 지금 작업과 무관한 프로젝트는 뺄 수 있음 그래도 **printed directory tree**에는 넣어서, 에이전트가 적어도 그 존재를 알고 필요하면 특정 파일을 요청할 수 있게 함 - 흥미로운 접근임 그 **병합 작업**은 어떻게 하는지 궁금함 수동인지, 변경 파일만 합치는지, 아니면 혼합형인지 알고 싶음 - **LLM memory**는 이론상 좋지만, 실제로는 커질수록 메모리 없이 굴릴 때만큼이나 지저분해짐 첫 화면 예시처럼 `내 프로젝트 계속 작업해줘`라고 해도, 현실에서는 프로젝트 하나만 하는 경우가 드묾 5개, 10개쯤 메모리에 들어갈 수 있고, 각각 저장 당시에는 다 의미 있었을 것임 결국 `sass 프로젝트 계속해줘`처럼 다시 특정해야 하고, 세부 컨텍스트는 조금 얻는 대신 **LLM context**를 채우고 추가 **MCP calls** 비용도 내게 됨 - 맞는 말이지만, 이건 너무 **naive implementation**임 제대로 만든 구현이라면 이런 한계를 넘어설 수도 있음 - 결국 뭘 기억해야 하는지 구체적으로 지정하기 시작하면, 사실상 AI에게 파일로 **write/read**하게 시키는 것과 거의 다를 바 없어짐 - 이건 혼자 일하는 **vibecoder**만을 위한 건가 싶음 실제 사람들과 실제 프로젝트를 하면, 이 시스템은 프로젝트 전체 메모리를 가질 수도 없고 나 역시 전체 메모리를 갖고 있지 않음 다른 PR이 머지되면 내가 가진 기억은 바로 낡아지고, 내가 신경 쓰는 건 내 티켓뿐임 그래서 점점 이런 건 그런 종류의 협업 작업을 위한 도구가 아닐 수도 있겠다고 느껴짐 - 이제 소프트웨어를 만드는 비용이 사실상 거의 0에 가까워졌는데도, 아직 이런 걸 **vibe-coded 마케팅 사이트**로 팔려는 게 놀라움 누가 이런 걸 써보고 몇 주, 몇 달 기다리면서 실제로 되는지 확인할 시간이 있겠나 싶음 사이트 어디에도 **RAG**보다 낫다거나, 그냥 메모리 파일 폴더와 grep보다 낫다는 증거가 없음 그런데도 환상적인 주장만 늘어놓고 있고, 스크롤도 14fps로 버벅임 이건 24시간 전에 코딩한 수준으로 보이는데, 솔직히 너무 게으르게 느껴짐