> ## Content Index > Fetch the complete content index at: https://blog.sorune.org/llms.txt > Use this file to discover other available public pages before exploring further. # 프로젝트가 많아서 힘든 게 아니었다 — 아키텍처를 그려보고 알게 된 인지 부하의 정체 - URL: https://blog.sorune.org/architecture-diagrams-exposed-cognitive-load/ - Published: 2026-09-14T01:10:57.000Z - Updated: 2026-09-14T01:10:57.000Z - Description: PaaS, PhotoGram, CharaWeave, Workspace Ops를 한꺼번에 아키텍처로 펼쳐보니 문제는 프로젝트 개수가 아니었다. 서로 다른 상태 모델과 authority를 머릿속에서 반복해 재구성하던 비용이 실제 병목이었다. - Author: Sorune — Engineering, Photography & Lab Notes - Tags: Engineering, AI-Native Engineering, Architecture, Cognitive Load, Developer Tools, Provenance 최근 내가 동시에 다루는 시스템을 한 번에 아키텍처 다이어그램으로 펼쳐봤다. PaaS, PhotoGram, CharaWeave, Workspace Ops / WSP. 네 개라고 적어놓으면 생각보다 단순해 보인다. 그래서 한동안은 그냥 프로젝트가 많아서 머리가 복잡한 것이라고 생각했다. 그런데 각 시스템의 실제 경계와 상태를 다이어그램으로 옮기고 나니 다른 그림이 보였다. 문제는 프로젝트 **개수**가 아니었다. ```text COGNITIVE OVERLOAD != TOO MANY PROJECTS COGNITIVE OVERLOAD = TOO MANY INTERDEPENDENT STATE MODELS HELD AND RECONSTRUCTED IN HUMAN MEMORY ``` 내가 계속 기억하려 했던 것은 네 개의 TODO 목록이 아니었다. 서로 다른 이유로 변하는 여러 상태를 동시에 추적하고, 작업을 다시 시작할 때마다 그 관계를 머릿속에서 복원하고 있었다. ## 네 프로젝트는 사실 네 종류의 문제였다 현재 개인 개발 활동을 크게 나누면 다음 네 축에 가깝다. ```text PaaS → 서비스가 어디서 어떻게 실행되는가 PhotoGram → 사용자-facing Product가 어떻게 동작하고 진화하는가 CharaWeave → 재사용 가능한 Character Runtime / SDK가 의미를 어떻게 소유하는가 Workspace Ops / WSP → 개발 작업 자체의 상태와 경계를 어떻게 관찰하고 운영하는가 ``` 각각만 놓고 봐도 다루는 상태의 종류가 다르다. PhotoGram에서는 Identity, Session, Content, Media, Realtime, Frontend 같은 product/domain state를 구분해야 한다. CharaWeave에서는 Host가 제공하는 사실, Character가 소유하는 의미, 선택을 담당하는 decision semantics, 실제 동작을 수행하는 Runtime, 표현을 담당하는 Presentation을 섞지 않아야 한다. PaaS에서는 코드가 끝났다는 것과 실제 서비스가 배포되고, 연결되고, 정상 운영되는 것이 서로 다른 상태다. Workspace 쪽으로 가면 한 단계 더 복잡해진다. Project, Repository, Worktree, Session, Revision, Evidence, Review, Acceptance, Promotion, Deployment 같은 개발 행위 자체의 meta-state를 다룬다. 즉 `현재 상태가 어디까지 왔는가?`라는 질문에도 답이 하나가 아니다. ```text IMPLEMENTED != VERIFIED != REVIEWED != ACCEPTED != PROMOTED != DEPLOYED ``` 한 단계가 끝났다고 다음 단계까지 자동으로 끝난 것은 아니다. ## 같은 파일 하나도 여러 상태를 가진다 이 문제가 실제로 부담스러웠던 이유는 상태들이 서로 독립적이면서도 연결되어 있기 때문이다. 예를 들어 PhotoGram의 이미지 하나를 생각해도 다음 질문이 따로 존재한다. ```text 파일 resource는 무엇인가? 어느 Product 기능에서 사용하는가? 어떤 processing을 허용하는가? 어떤 metadata를 노출하는가? 검색/탐색용 materialization 대상인가? 사용자에게 어떤 representation으로 전달하는가? ``` 같은 이미지라고 해서 Photo와 Profile Avatar가 같은 lifecycle을 가져야 하는 것도 아니다. CharaWeave에서도 비슷하다. 캐릭터가 움직였다는 사실과 왜 그 행동을 선택했는지는 다른 책임이다. Personality가 어떤 행동에 영향을 줬다고 해서 Runtime이 Personality의 의미를 소유하는 것도 아니다. PaaS에서도 Product가 완료됐다는 사실은 다음을 보장하지 않는다. ```text PRODUCT COMPLETE != DEPLOYED != REACHABLE != OPERATIONALLY HEALTHY ``` 이런 구분은 각각 합리적이다. 문제는 이 합리적인 구분을 전부 Human memory로 유지하고 있었다는 데 있었다. ## Git SHA 하나를 기억한다고 현재 상태를 아는 것이 아니었다 처음에는 repository와 commit을 잘 관리하면 대부분 해결될 것이라고 생각했다. Git은 실제로 많은 것을 잘 해결한다. 하지만 프로젝트가 커지고 AI session과 worktree가 늘어나면서 Git만으로는 답하기 어려운 질문이 생겼다. ```text 이 commit은 구현 후보인가, accepted state인가? 이 branch의 검증은 끝났는가? 이 문서는 현재 authority인가, historical record인가? 이 worktree는 어느 logical work를 위한 것인가? 이 변경은 현재 scope 안인가? 테스트 PASS가 acceptance까지 의미하는가? 이 session이 끝났다면 resource도 지워도 되는가? ``` 이 질문들은 Git의 부족함이라기보다 Git이 원래 소유하지 않는 문제다. 그래서 실제로 내가 반복하던 작업은 코드를 읽는 것뿐 아니라 **현재 의미를 재구성하는 일**이었다. ```text repository state + runtime state + product state + authority state + historical provenance → current working model ``` session이 바뀌거나 며칠 뒤 작업을 다시 열면 이 조립을 다시 했다. 프로젝트가 네 개라는 숫자보다 이 재조립 횟수가 훨씬 큰 비용이었다. ## 아키텍처 다이어그램은 설명 자료가 아니라 외부 기억 장치가 됐다 이번에 각 시스템을 diagram과 atlas로 펼치면서 가장 크게 느낀 것은 “그림이 예쁘다”가 아니었다. 그동안 대화와 코드 사이에 흩어져 있던 경계가 동시에 보였다. ```text PhotoGram → domain / transaction / media lifecycle CharaWeave → meaning / decision / runtime / presentation Workspace → authority / execution / acceptance / promotion / closure PaaS → host / network / deployment / runtime / operations ``` 각 그림은 별개의 시스템 설명이지만, 한꺼번에 놓으면 내가 왜 계속 context를 잃고 다시 복원했는지가 보인다. 내 머릿속에는 단순히 네 프로젝트가 있었던 것이 아니다. ```text semantic state runtime state repository / branch / worktree state current vs historical state design vs implementation verification vs acceptance public vs private boundary Human authority vs Executor capability ``` 같은 축들이 프로젝트마다 반복되고 있었다. 다이어그램은 이 복잡성을 새로 만든 것이 아니라 이미 있던 복잡성을 밖으로 꺼냈다. ## 그래서 History와 Workspace tooling이 커졌던 이유도 다시 보였다 한동안은 History나 Workspace Ops 같은 도구가 오히려 개발 과정을 복잡하게 만드는 것은 아닌지 의심한 적도 있었다. 실제로 governance나 문서가 과해지면 충분히 그럴 수 있다. 하지만 architecture를 펼쳐놓고 보니 적어도 출발점은 반대였다. 이 도구들이 복잡성을 만들어낸 것이 아니라, 이미 사람 머릿속에 있던 coordination complexity를 외부화하려고 생긴 것이었다. History는 현재 상태의 authority가 아니다. 대신 과거에 무엇이 있었고 왜 그렇게 판단했는지 매번 기억하지 않아도 되게 한다. ```text HISTORY != CURRENT AUTHORITY HISTORY = PROVENANCE FOR RECONSTRUCTION ``` Workspace Ops와 WSP도 비슷하다. 새로운 Git을 만들려던 것이 아니라 Git 사이에 빠져 있던 의미를 표현하려고 했다. ```text 이 repository는 어느 Project에 속하는가? 이 physical worktree는 어떤 logical work를 의미하는가? 현재 관측한 사실과 변경 권한은 같은 것인가? UNKNOWN은 오류인가, 아직 모르는 상태인가? ``` 이런 질문을 매번 Human이 문맥으로 추론하는 대신 일부를 기계가 읽을 수 있는 형태로 밖에 두려는 시도였다. ## 외부화만 하면 끝나는 것도 아니었다 여기에는 역설이 하나 있다. 머릿속 context를 Git과 문서로 옮기면 Human memory 부담은 줄어든다. 그런데 AI에게 그 문서를 전부 매번 읽히기 시작하면 context cost가 다른 곳에서 다시 커진다. ```text CONTEXT MOVED TO GIT != CONTEXT COST ELIMINATED ``` History가 많아질수록 모든 문서를 한 번에 읽는 것도 답이 아니었다. 그래서 목표는 “더 많이 기록하기”에서 한 단계 더 나아갔다. ```text Compact overview ↓ question-specific detail ↓ accepted baseline / evidence ↓ raw source when needed ``` 정보를 버리는 것이 아니라 기본 retrieval surface를 작게 만드는 것이다. 사람에게도, AI에게도 같은 원칙이 적용됐다. ## 이제 목표는 더 잘 기억하는 것이 아니다 이번 정리에서 가장 유용했던 결론은 이것이었다. ```text GOAL != INCREASE HUMAN MEMORY CAPACITY GOAL = REDUCE REQUIRED ACTIVE HUMAN CONTEXT ``` 좋은 개발자가 모든 상태를 머릿속에 오래 유지하는 사람일 필요는 없다. 적어도 내 작업 방식에서는, 중요한 state와 provenance를 외부에 정확히 남기고 필요할 때만 다시 가져오는 편이 훨씬 안정적이었다. 그렇다고 모든 불편을 새로운 도구로 해결하겠다는 뜻도 아니다. 한 번 불편했다고 abstraction을 추가하면 또 다른 복잡성을 만든다. 내가 지금 적용하려는 기준은 오히려 단순하다. ```text 반복해서 같은 문맥을 재구성한다 + 그 정보에 provenance 가치가 있다 → source는 보존하고 retrieval / projection을 추가한다 일회성 불편이다 → 새 tooling을 만들지 않는다 ``` 이 기준이 모든 팀의 정답이라고 생각하지는 않는다. 다만 여러 프로젝트와 여러 AI가 동시에 움직이는 내 개발 환경에서는 같은 패턴이 반복해서 나타났다. ## 네 프로젝트를 정리했더니 하나의 문제가 보였다 PaaS, PhotoGram, CharaWeave, Workspace Ops / WSP는 서로 다른 제품과 시스템이다. 그런데 이들을 한 번에 그려보면서 하나의 공통 문제가 보였다. **시스템의 복잡성보다 더 위험했던 것은 그 복잡성의 중요한 부분을 계속 Human memory 안에서만 재구성하고 있었다는 점이었다.** 그래서 앞으로의 방향도 더 명확해졌다. ```text 기억해야 할 것을 늘리는 대신 외부화할 수 있는 것을 외부화한다. 모든 정보를 읽는 대신 필요한 view부터 본다. 현재 상태와 History를 섞지 않고 필요할 때 provenance로 내려간다. ``` 아키텍처 다이어그램을 그린 날 얻은 가장 큰 결과는 새로운 설계가 아니었다. **왜 내가 계속 머릿속이 포화되는 느낌을 받았는지, 그리고 왜 그 복잡성을 밖으로 꺼내는 도구를 만들기 시작했는지가 구조로 보이기 시작했다는 것**이었다.