MaJu's Note

이 묶음은 클라우드 모델을 쓰는 법보다, 개인이 직접 AI 실행 환경을 어떻게 세우고 운영했는가를 기록한 인프라 노트다. 읽기 축 1. 로컬 추론 축 로컬 AI 인프라 노트 — 맥OS 로컬 LLM 추천과 oMLX 가이드 로컬 AI 인프라 노트 — 로컬 LLM 가속·양자화 심화 로컬 AI 인프라 노트 — 2026년 4월 카테고리별 최고의 AI 9종 2. 이미지 파이프라인 축 로컬 AI 인프라 노트 — 블로그 이미지 파이프라인을 ComfyUI로 전환하는 설계 EN 아카이브에서 같이 읽을 글 Local AI Infrastructure Notes — Mac Mini M4 Home Server Architecture Local AI Infrastructure Notes — Access Your Home Server with Tailscale VPN Local AI Infrastructure Notes — Building an Inter-Agent Message Hub Local AI Infrastructure Notes — Automating Services with launchd Local AI Infrastructure Notes — Home Server Dashboard Design Local AI Infrastructure Notes — Replacing the Local LLM from Qwen3.5 to Gemma 4 Local AI Infrastructure Notes — Auto-Generating Blog Images with Nano Banana 2 Local AI Infrastructure Notes — Tracking the Real Cost of Nano Banana 2 Local AI Infrastructure Notes — Moving Blog Image Generation to ComfyUI Local AI Infrastructure Notes — Mac Mini M4 Local LLM Benc...

이 묶음은 AI 에이전트를 더 똑똑하게 만드는 법이 아니라, 더 안정적으로 굴리기 위해 무엇을 설계해야 하는가를 다룬다. 추천 독자 단일 에이전트와 서브에이전트, 멀티에이전트의 경계가 헷갈리는 독자 평가를 점수표가 아니라 회귀 방지 구조로 이해하고 싶은 독자 승인 루프, 권한, 샌드박스 같은 안전장치를 운영 관점으로 보고 싶은 독자 추천 읽기 순서 에이전트 운영 설계 노트 — 에이전트 팀 설계 입문 에이전트 운영 설계 노트 — 에이전트 평가는 점수표보다 회귀 테스트에 가깝다 에이전트 운영 설계 노트 — 멀티 서브에이전트 RAG는 검색 묶음이 아니라 역할 체계다 읽는 방법 에이전트 구조부터 잡고 싶다면: 1 검증 체계를 먼저 잡고 싶다면: 2 여러 검색기와 여러 역할을 함께 운영하는 설계까지 보고 싶다면: 3 EN 확장 경로 Approval loop Permission design Sandboxing Managed agents ownership Runtime design 다음에 이어 읽기 좋은 묶음 하네스 엔지니어링 기초 시리즈 온톨로지와 메모리 시스템

이 묶음은 메모를 저장하는 법이 아니라, 정보를 다시 꺼내 쓰고 연결하고 승격시키는 구조를 어떻게 설계할지에 관한 글들을 한 줄로 묶는다. 이 시리즈는 누구를 위한가 Second Brain을 단순 메모 앱 추천이 아니라 구조 문제로 보고 싶은 독자 온톨로지, 그래프, 메모리 아키텍처, handoff를 따로 배우다 흩어진 독자 RAG 이후의 컨텍스트 인텔리전스와 메모리 DB까지 한 흐름으로 보고 싶은 독자 추천 읽기 순서 온톨로지와 메모리 시스템 — Second Brain은 무엇이고, 왜 단순 메모와 다른가 온톨로지와 메모리 시스템 — Ontology는 왜 지식 관리에서 중요한가 온톨로지와 메모리 시스템 — GraphDB는 어떤 문제를 해결하는가 온톨로지와 메모리 시스템 — LangChain은 지식 시스템에서 정확히 무엇을 하는가 온톨로지와 메모리 시스템 — 좋은 에이전트 메모리 아키텍처는 어떻게 생겼나 온톨로지와 메모리 시스템 — 장시간 에이전트 운영에서는 handoff 설계가 메모리보다 먼저다 온톨로지와 메모리 시스템 — 검색하는 노트에서 생각하는 시스템으로 온톨로지와 메모리 시스템 — RAG 다음은 무엇인가: 컨텍스트 인텔리전스와 메모리 DB의 시대 이렇게 읽으면 된다 개념 입문: 1 → 2 → 3 → 4 에이전트 메모리 관점: 5 → 6 확장 설계 관점: 7 → 8 발행 예정 아카이브 온톨로지와 메모리 시스템 — Why Ontology Is Necessary in Claude Code 온톨로지와 메모리 시스템 — Multi-Agent Ontology in Practice 온톨로지와 메모리 시스템 — What Changes When You Ontologize Yourself 다음에 이어 읽기 좋은 묶음 에이전트 운영 설계 노트 하네스 엔지니어링 기초 시리즈

← 10/13 GraphDB는 어떤 문제를 해결하는가 📚 시리즈 목차 12/13 검색하는 노트에서 생각하는 시스템으로 → 지난 글에서는 GraphDB를 다뤘다. 관계형 테이블이나 벡터 검색만으로는 설명하기 어려운 연결, 즉 "이 메모는 어떤 프로젝트의 결정 근거였는가", "이 개념은 어떤 실패 사례와 연결되는가" 같은 질문을 구조적으로 다루려면 그래프적 시각이 필요하다는 이야기였다. 그런데 여기서 자연스럽게 다음 질문이 나온다. 그래프까지 준비했으면 이제 지식 시스템은 완성된 걸까? 실제로는 그렇지 않다. 저장 구조가 좋아졌다고 해서 시스템이 곧바로 "잘 생각하는 흐름"을 갖게 되지는 않는다. 여전히 누군가는 지금 질문이 무엇인지 읽고, 어떤 데이터를 꺼낼지 정하고, 어떤 도구를 언제 쓸지 결정하고, 그 결과를 다시 모델 입력으로 묶어야 한다. 바로 그 자리에서 LangChain 같은 프레임워크가 등장한다. 이 글의 핵심은 단순하다. LangChain은 지식을 저장하는 시스템이 아니라, 이미 존재하는 여러 지식 구성요소를 작업 흐름으로 연결하는 오케스트레이션 계층 이다. 이 문장을 정확히 이해하면, LangChain을 과대평가하는 실수도 줄고 과소평가하는 실수도 줄어든다. LangChain은 "무엇을 가진 시스템"이 아니라 "어떻게 연결할지 정하는 시스템"이다 처음 접하면 LangChain을 거대한 AI 엔진처럼 느끼기 쉽다. 하지만 LangChain 자체가 지식을 갖고 있는 것은 아니다. LangChain이 직접 모델을 학습시키는 것도 아니고, 데이터를 영구 저장하는 것도 아니며, 그래프 데이터베이스를 대신하는 것도 아니다. LangChain이 하는 일은 훨씬 실무적이다. 사용자의 입력이 들어왔을 때: 어느 모델을 호출할지 정하고 어떤 프롬프트 형태로 가공할지 정하고 검색이 필요하면 어떤 retriever를 부를지 정하고 외부 도구가 필요하면...

← 9/13 Ontology는 왜 지식 관리에서 중요한가 📚 시리즈 목차 11/13 LangChain은 지식 시스템에서 무엇… → 온톨로지를 그렸다면, 이제 저장 방식이 문제다 지난 글에서 온톨로지는 "무엇이 무엇과 어떤 관계를 맺는가"를 정리하는 언어라고 설명했다. 사람, 프로젝트, 개념, 작업, 감정, 기록 같은 것들은 혼자 존재하지 않는다. 서로 연결되면서 의미가 생긴다. 문제는 여기서 시작된다. 머릿속에서는 분명히 연결되어 있는데, 막상 저장하려고 하면 대부분 폴더나 표 형태로 눌러 담게 된다. 사람/ , 프로젝트/ , 아이디어/ 폴더를 나누고, 노트 앱에서는 태그를 달고, 데이터베이스에서는 행과 열을 만든다. 처음에는 잘 정리된 것처럼 보인다. 그런데 연결이 많아질수록 이상한 느낌이 생긴다. 분명히 알고 있는 것을 찾기가 어려워지고, 관계를 설명하려면 같은 내용을 여러 곳에 반복해서 적어야 한다. GraphDB는 바로 그 지점에서 등장한다. 이 도구는 "데이터를 많이 넣는 법"보다 "연결된 세계를 연결된 채로 저장하는 법"에 가깝다. GraphDB는 데이터를 점과 선으로 다룬다 GraphDB를 이해하는 가장 쉬운 방법은 지하철 노선도를 떠올리는 것이다. 역만 따로 모아 둔다고 노선도가 되지 않는다. 어느 역이 어느 역과 연결되는지, 그 연결이 몇 호선인지, 환승인지, 급행이 서는지까지 함께 있어야 실제로 쓸 수 있다. GraphDB에서는 보통 세 가지를 중심으로 생각한다. 첫째는 노드(node)다. 존재하는 대상을 뜻한다. 사람, 문서, 책, 개념, 회사, 프로젝트, 사건 같은 것이 노드가 된다. 쉽게 말해 "이 세계에 있는 것"이다. 둘째는 엣지(edge) 또는 관계선이다. 한 노드와 다른 노드를 잇는 선이다. 하지만 단순한 선이 아니다. "작성했다", "참고한다", "반박한다", "같은 프로젝...

← 8/13 Second Brain은 무엇이고 왜 단… 📚 시리즈 목차 10/13 GraphDB는 어떤 문제를 해결하는가 → 메모를 많이 남겨도, 왜 나중에는 다시 못 찾게 될까 지난 글에서 Second Brain은 "내 머리 밖에 만드는 외부 기억 체계"에 가깝다고 이야기했다. 그런데 실제로 메모 앱을 오래 써 본 사람이라면 금방 한 가지 문제를 만난다. 분명 열심히 적어 두었는데, 나중에는 그 메모가 어디 있는지 모르겠다는 문제다. 이때 많은 사람이 폴더를 더 잘 나누거나 태그를 더 많이 붙이면 해결될 거라고 생각한다. 물론 어느 정도는 도움이 된다. 하지만 시간이 지나면서 자료가 늘어나면, 폴더와 태그만으로는 지식의 관계를 설명하기가 점점 어려워진다. 여기서 중요한 개념이 바로 Ontology 다. Ontology는 어려운 철학 용어처럼 들리지만, 지식관리 맥락에서는 비교적 단순하게 이해할 수 있다. "내가 다루는 대상이 무엇이고, 그것들이 서로 어떤 관계를 가지는지 정의하는 틀" 이다. 메모를 저장하는 것만으로는 Second Brain이 되지 않는다. 메모 사이의 의미 관계를 드러내야, 비로소 그 시스템이 생각을 도와주기 시작한다. Ontology는 폴더가 아니라 의미의 지도다 예를 들어 메모 앱에 다음과 같은 정보가 있다고 해 보자. 책 메모 회의 메모 프로젝트 아이디어 사람에 대한 기록 배운 개념 정리 이 정보를 단순히 폴더로 나누면 "어디에 넣을까"는 해결된다. 하지만 "무엇이 무엇과 연결되는가"는 여전히 흐릿하다. 예를 들어 다음 질문을 떠올려 보자. 이 아이디어는 어떤 프로젝트와 관련이 있지? 이 프로젝트는 누구와 연결되어 있지? 이 개념은 어떤 책에서 배웠고, 실제 어디에 적용됐지? 이 회의 메모는 어떤 의사결정을 남겼지? 이 질문들은 파일 위치만으로는 답하기 어렵다. 왜냐하면 우리가 찾는 것은 저장 위치가 아니라 관계...

← 7/13 장시간 운영에서는 handoff 설계가… 📚 시리즈 목차 9/13 Ontology는 왜 지식 관리에서 중요한가 → 메모를 열심히 하는데도, 시간이 지나면 오히려 더 헷갈리는 순간이 있다. 분명 어딘가에 적어두었는데 찾지 못하고, 다시 읽어도 왜 적었는지 감이 오지 않고, 결국 같은 생각을 또 처음부터 하게 된다. 이때 많은 사람은 자신이 "메모를 덜 해서" 문제라고 생각한다. 하지만 실제로는 메모의 양이 아니라 메모의 성격이 문제인 경우가 많다. Second Brain이라는 개념은 바로 이 지점에서 등장한다. 이것은 노트를 더 많이 쌓는 방법이 아니라, 내 머리 밖에 두는 정보가 어떤 역할을 해야 하는가 를 다시 정의하는 생각법에 가깝다. 단순 메모가 "잊지 않기 위해 적어두는 것"이라면, Second Brain은 "나중에 다시 생각하기 위해 구조화해두는 것"이다. 둘 다 기록이라는 점에서는 비슷해 보이지만, 목적과 사용 방식은 꽤 다르다. 이 글에서는 도구 추천이나 정리법 체크리스트로 들어가지 않는다. 먼저 개념부터 분명히 잡아보자. Second Brain은 무엇이고, 왜 많은 메모가 시간이 갈수록 짐이 되는데 어떤 기록은 점점 자산이 되는가. 이 차이를 이해하면 이후 어떤 앱을 쓰든, 어떤 방식으로 기록하든 훨씬 덜 흔들리게 된다. Second Brain은 "두 번째 저장소"가 아니라 "외부 사고 시스템"이다 Second Brain이라는 표현을 처음 들으면, 흔히 "뇌의 백업본" 같은 이미지를 떠올린다. 내 머릿속 내용을 외부에 복사해두는 저장소라는 느낌이다. 물론 일부는 맞다. 기억해야 할 것을 바깥에 두는 기능이 있기 때문이다. 하지만 이 비유만으로는 핵심이 잘 드러나지 않는다. Second Brain은 단순한 저장소가 아니다. 저장소는 넣는 일까지만 책임진다. 반면 Second Brain은 다시 꺼내고, 연결하고, 맥...

← 11/13 LangChain은 지식 시스템에서 무엇… 📚 시리즈 목차 13/13 RAG 다음은 무엇인가 → 앞으로의 Second Brain은 "잘 저장하고 잘 검색하는 노트"에 머물지 않을 가능성이 크다. 더 중요한 것은 지금 필요한 맥락을 조립하고, 반복적으로 중요한 정보를 기억으로 승격하며, 작은 역할 단위들이 협업해 실행까지 이어지는 개인용 운영체제를 만드는 일이다. 영문판: From Searchable Notes to a Thinking System: A Proposal for the Next-Generation Second Brain 지난 몇 년 동안 Second Brain의 핵심 약속은 비교적 분명했다. 많이 기록하자, 잘 연결하자, 필요할 때 다시 찾자. 노트 앱, 태그, 링크드 노트, 검색, 하이라이트 파이프라인이 주목받은 이유도 여기에 있다. 정보가 넘치는 시대에 "나중에 다시 찾을 수 있는 저장소"를 만드는 일은 분명 큰 진전이었다. 하지만 실제로 지식 노동이 막히는 지점은 종종 저장이나 검색이 아니다. 이미 적어 둔 노트가 너무 많아서 무엇이 중요한지 모르겠고, 과거의 메모는 현재의 문제 맥락과 잘 맞지 않으며, 검색 결과는 나오지만 다음 행동으로 이어지지 않는다. 다시 말해 기존 Second Brain은 기억 보관에는 강했지만, 상황 판단과 맥락 조립에는 약했다. 이 글의 주장은 명확하다. 차세대 Second Brain은 검색 가능한 노트 저장소에서, 맥락을 조립하고 기억을 승격하며 역할 기반으로 작동하는 개인 운영체제로 이동해야 한다. 이 변화는 단순한 기능 추가가 아니라 아키텍처 전환에 가깝다. 검색 중심 Second Brain의 한계 기존 Second Brain 철학은 "잊지 않기 위해 외부화하자"는 문제의식에서 출발했다. 그래서 설계의 중심도 자연스럽게 캡처, 정리, 링크, 검색에 놓였다. 이 구조는 자료 아카이브, 회고 기록, 독서 노트, 프로젝트 로...

← 8/9 샌드박스는 보안이 아니라 품질 구조다 📚 시리즈 목차 (시리즈 끝) 작은 RAG 유닛을 많이 붙이면 더 똑똑해질 것처럼 보인다. 실제로는 그보다 훨씬 큰 변화가 생긴다. 검색이 여러 번 일어나는 것이 아니라, 누가 무엇을 검색할 권한이 있고 어떤 결과를 언제 장기 기억으로 올릴지 를 설계해야 하기 때문이다. 영문판: Multi-Subagent RAG Is Not Many Searches. It Is a Role System. 단일 파이프라인 RAG는 설명하기 쉽다. 질문이 들어오면 검색하고, 관련 문서를 몇 개 붙이고, 모델이 답한다. 이 구조는 문서 질의응답, 사내 위키 탐색, FAQ 같은 문제에서는 여전히 유효하다. 하지만 작업이 길어지고, 문서 공간이 나뉘고, 판단 단계가 여러 개로 갈라지면 단일 파이프라인은 금방 한계를 드러낸다. 검색이 한 번으로 끝나지 않고, 같은 질문 안에서도 서로 다른 전문성이 필요해지기 때문이다. 예를 들어 제품 정책 문서를 읽는 에이전트, 로그를 읽는 에이전트, 코드 변경 이력을 읽는 에이전트, 그리고 이 셋의 결과를 합쳐 사용자에게 설명하는 에이전트가 있다고 하자. 겉으로 보면 "RAG가 4개 있네"라고 말할 수 있다. 하지만 실제 운영 관점에서는 그보다 더 복잡하다. 각 에이전트는 다른 문서 경계를 갖고, 다른 검색 규칙을 쓰고, 서로의 결과를 그대로 믿지 않으며, 어떤 정보만 기억으로 승격할지 따로 판단해야 한다. 이 시점부터 문제는 단순 검색이 아니라 역할 기반 retrieval 시스템 이 된다. 왜 단일 파이프라인 RAG는 금방 막히는가 단일 RAG의 장점은 선형성이다. query -> retrieve -> generate 가 한 줄로 설명된다. 대신 이 구조는 세 가지를 한 덩어리로 묶어 버린다. 첫째, 질문 해석과 검색 공간 선택이 한 번에 처리된다. 사용자의 질문이 "이 정책이 왜 바뀌었나?"일 때, 실제로 필요한 것은 정책 문서 자체...

← 12/13 검색하는 노트에서 생각하는 시스템으로 📚 시리즈 목차 (시리즈 끝) RAG는 여전히 중요하다. 하지만 실제 운영 시스템이 부딪히는 문제는 점점 "무엇을 찾을까"보다 "지금 이 순간 어떤 맥락을 어떻게 구성할까"로 이동하고 있다. 검색은 시작점이고, 경쟁력은 컨텍스트 조립 능력에서 갈린다. 영문판: What Comes After RAG? The Age of Context Intelligence and Memory Databases 들어가며: 정적 RAG가 잘하는 일과, 잘 못하는 일 RAG는 한동안 생성형 AI의 가장 실용적인 답이었다. 모델의 파라메트릭 메모리만 믿지 말고, 외부 문서를 검색해서 근거를 붙인 뒤 답하게 하자는 발상은 단순하면서도 강력했다. 최신 정보, 사내 문서, 규정, 매뉴얼처럼 학습 가중치 안에 없거나 자주 바뀌는 지식을 다뤄야 하는 환경에서는 특히 그렇다. 문제는 운영 환경이 생각보다 훨씬 더 동적이라는 데 있다. 사용자의 질문은 늘 문서 검색으로만 해결되지 않는다. 같은 질문이라도 누가 묻는지, 직전 단계에서 어떤 도구 호출이 있었는지, 어떤 정책이 현재 유효한지, 방금 실패한 작업이 무엇인지에 따라 필요한 맥락이 달라진다. 많은 RAG 시스템이 여전히 "질문 하나, 검색 한 번, 상위 K개 문서 주입"이라는 정적 흐름에 머문다면, 실제 업무는 이미 그 틀을 벗어나 있다. 그래서 최근의 변화는 단순히 "더 큰 컨텍스트 윈도"나 "더 좋은 벡터 검색"만으로 설명되지 않는다. 업계의 관심은 점차 정적 RAG에서 동적으로 맥락을 구성하는 시스템 , 다시 말해 여기서 말하는 컨텍스트 인텔리전스 로 이동하고 있다. 이때 메모리 DB는 그 실행 기반이 되고, 블록체인은 일부 영역에서 신뢰와 계보를 남기는 보조 계층이 될 수 있다. 이 글의 핵심 주장은 간단하다. AI는 정적 RAG에서 컨텍스트 인텔리전스로 이동 중이며, 메모...

← 5/13 3계층 메모리 아키텍처 📚 시리즈 목차 7/13 장시간 운영에서는 handoff 설계가… → 메모리 이야기를 하면 많은 사람이 검색 품질이나 장기 기억부터 떠올린다. 물론 중요하다. 하지만 더 근본적인 문제는 따로 있다. 무엇을 어디에 두고, 언제 불러오고, 무엇을 장기 자산으로 승격할 것인가. 좋은 에이전트 메모리 아키텍처는 많이 저장하는 구조가 아니라, 저장·로드·승격 규칙이 분리된 구조에 가깝다. 핵심 요약 작업 상태, 세션 복구, 장기 지식은 같은 메모리가 아니다. 좋은 메모리 구조는 저장량보다 로드 규칙 이 먼저다. 메모리 승격 규칙이 없으면 저장소는 금방 오염된다. schema, provenance, retention이 없으면 메모리는 기능이 아니라 오염원이 된다. 1. memory architecture를 검색 품질 문제로만 보면 놓치는 것 메모리를 검색 품질로만 보면 "더 잘 찾는가"에만 집중하게 된다. 하지만 운영에서는 그보다 먼저 봐야 할 것이 있다. 이 정보는 지금 필요한가 이 정보는 다음 세션도 필요한가 이 정보는 장기 자산이 될 가치가 있는가 이 정보는 잘못됐을 때 누가 수정하는가 즉 메모리 아키텍처는 검색보다 먼저 수명과 위치의 문제 다. 2. 작업 상태, 세션 복구, 장기 지식은 같은 메모리가 아니다 메모리를 한 덩어리로 보면 금방 혼란스러워진다. 실무에서는 최소한 세 층으로 나누는 편이 좋다. 메모리 층 예시 수명 작업 상태 현재 목표, 체크포인트, 다음 행동 짧음 세션 복구 handoff, session note, 미검증 항목 중간 장기 지식 반복 규칙, taxonomy, 실패 교훈, 운영 원칙 김 이 구분이 없으면 작업 메모가 장기 기억처럼 쌓이고, 장기 자산이 대화 이력에 묻힌다. 3. 좋은 메모리 구조는 저장보다 로드 규칙이 먼저다 많이 저장하는 것보다 더 중요한 건 언제 무엇을 활성 컨텍스트로 올...

← 6/13 좋은 에이전트 메모리 아키텍처는 어떻게… 📚 시리즈 목차 8/13 Second Brain은 무엇이고 왜 단… → 긴 작업에서 가장 자주 깨지는 것은 모델의 기억력이 아니라 작업의 연속성이다. 세션이 바뀌고, 사람이 개입하고, 컨텍스트가 잘리고, 다음 실행이 이어질 때 무엇을 먼저 읽어야 하는지가 흐려진다. 그래서 장시간 에이전트 운영의 핵심은 memory 일반론보다 먼저 handoff를 어떻게 구조화할 것인가 에 있다. 핵심 요약 장시간 작업의 진짜 문제는 망각보다 단절이다. 좋은 handoff는 "요약문"이 아니라 다음 행동을 바로 시작할 수 있게 만드는 재개 구조 다. progress file, session note, handoff note는 같은 문서가 아니다. 역할을 분리할수록 재개 비용이 줄어든다. Managed Agents가 장시간 실행을 도와줄 수는 있어도, 무엇을 어떻게 이어붙일지는 여전히 로컬 설계다. 1. 장시간 작업의 진짜 문제는 망각보다 단절이다 긴 작업을 할 때 흔히 "메모리를 잘 넣으면 된다"고 생각한다. 하지만 실제로 더 자주 깨지는 건 아래다. 지금 어디까지 했는지 모른다 무엇이 확정이고 무엇이 미확정인지 흐리다 다음 세션이 무엇부터 읽어야 할지 모른다 사람이 중간 개입하면 재개점이 사라진다 즉 문제의 핵심은 많이 기억하느냐보다 어디서 다시 시작할 수 있느냐 다. 2. 왜 handoff가 memory보다 먼저 와야 하나 memory는 넓은 개념이다. 장기 지식, 사용자 선호, 프로젝트 규칙, 과거 사실까지 다 포함할 수 있다. 반면 handoff는 훨씬 더 좁고 실용적이다. handoff가 답해야 하는 질문은 대개 이렇다. 지금 작업 목표는 무엇인가 마지막으로 끝난 단계는 어디인가 다음 행동은 무엇인가 미검증 위험은 무엇인가 즉 handoff는 "많이 기억하기"보다 바로 이어 일하기 를 위한 구조다. 3....