Claude Code에서 Plugin을 발표했는데, Agent + Workflow(Custome Command)에 Skill (RAG의 Knowledge를 추가하는 것으로 이해하고 있다.)을 지원하는 것이다. 여기서는 동일한 PRD를 기지고 유사한 기능을 수행해보았다. workflow는 [1]의 "/feature-workflow"를 사용하였고, 이를 plugin으로 구현한 [2]의 "/product-design-toolkit:feature-workflow"를 사용하였다.

테스트 케이스

프로젝트: Task Management Dashboard
규모: 40시간 (2주)
복잡도: 중간 (표준 CRUD 애플리케이션)
팀 크기: 1명

핵심 결과

토큰 사용량 비교 (40시간 프로젝트)

핵심 발견

1. Plugin은 Manual 대비 6.9배 토큰 사용
2. 토큰 낭비의 62%는 중복 컨텍스트 로딩
   • Plugin: PRD 60회 로드 (900K tokens)
   • Manual: PRD 1회 로드 (15K tokens)
3. Break-even point: 150-200시간 프로젝트

프로젝트 규모별 권장

Plugin은 어디에 써야 할까? : Plugin이 강점을 보이는 시나리오

1. 엔터프라이즈 프로젝트 (1000시간+)

팀: 12명+
규모: 50+ 마이크로서비스
복잡도: 매우 높음

Manual: 3,500K tokens (컨텍스트 관리 불가)
Plugin: 2,700K tokens (23% 절감) ✅

가치:
- 팀 간 일관된 패턴 강제
- 자동화된 품질 게이트
- 컨텍스트 서비스별 분산

2. 반복 작업 자동화 (API 100개 생성)

Manual: 302K tokens
Plugin: 65K tokens (78% 절감) ✅

이유:
- 템플릿 기반 자동 생성
- 초기 설정 후 재사용
- 일관된 코드 품질

3. 레거시 마이그레이션 (100,000 LoC)

Manual: 불가능 (컨텍스트 한계 초과)
Plugin: 가능 ✅

가치:
- Code Explorer: 구조 분석
- Impact Analyzer: 변경 영향도 자동 평가
- Migration Planner: 단계별 계획
- 컨텍스트 분산으로 대규모 처리

Break-even Point

Hybrid 구조:

Planning (Plugin): 50K
Implementation (Manual): 80K  
Critical Review (Plugin): 30K
Final QA (Plugin): 20K
──────────────────────────
총 180K tokens (예산 90% 사용)

핵심 결론

1. Anthropic 주장에 따르면...
   • 전제: 대규모/복잡한 프로젝트
   • 우리 실험: 중소규모 프로젝트
   • → 결론이 다를 수밖에 없음
2. 규모가 모든 것을 결정
   • 작은 프로젝트: Manual 압도적 효율
   • 큰 프로젝트: Plugin 필수 도구
3. 대부분의 실무는 Hybrid가 최적
   • Planning 구조화 (Plugin)
   • Implementation 속도 (Manual)
   • QA 품질 보증 (Plugin)

참고 문서

[1] claude-coade-agents-workflow: https://github.com/omersaraf/claude-code-agents-workflow

[2] claude-dev-agent-toolkit: https://github.com/blcktgr73/claude-dev-agent-toolkit

나는 이제, 누군가의 칭찬보다 내가 나 자신을 인정해주는 일이 더 중요하다고 믿는다. 최근 그 믿음을 다시 떠올리게 된 계기가 있었다. 바로 드라마 스물다섯 스물하나의 한 장면이다.

이 드라마의 주인공 나희도는 성인이 된 후, 발레를 그만두려는 딸에게 위로와 조언을 건넨다. 딸이 “요즘 내가 뭘 좋아하는지도 모르겠어”라고 말하자, 나희도는 이렇게 답한다.

“실력은 비탈처럼 늘지 않아. 계단처럼 느는 거야. … 발레가 좋다면 다시 생각해.”

이 말이 유독 인상 깊었던 이유는, 제럴드 와인버그의 『테크니컬 리더』에서 본 성장에 대한 통찰과 맞닿아 있었기 때문이다. 그 장면을 보며, 나 역시 배움과 성장을 위해 애썼던 시기를 떠올렸다. 동시에, 왜 그토록 타인의 칭찬과 인정을 갈망했는지에 대해서도 스스로 묻게 되었다.

꽤 오래전의 일이다. 어느 순간부터 회사에서의 위치나 다른 사람들의 인정이 점점 더 중요해졌다. 하지만 그런 인정이 점차 줄어들면서 나는 지치고 흔들리기 시작했다. 그리고 그제야 깨달았다 — 내가 너무 바깥의 시선에 의존하고 있었다는 것을.

그 무렵부터 나는 내면의 성장에 집중하기 시작했고, 블로그도 그때 시작했다.

나는 여전히 내가 하는 일을 좋아한다. 그리고 그런 나를 지키기 위해, 이제는 타인보다 내 스스로의 인정이 더 중요하다고 느낀다.

지금, 왜 David Bohm인가?

요즘 나는 바이브 코딩에 푹 빠져 있다. 마치 평생 매달려 있는 컴퓨터를 처음 발견한 어린 시절 같다. 하지만, 사람들과 공동 작업을 하면서, 나 혼자 몰입해서 작업하는 것과는 다른 것을 느끼며 '무언가 더 깊은 것이 필요하구나'하는 느낌이 들었다. 그 무언가에 대해 실마리를 준 책이 바로 데이비드 봄의 『대화에 관하여(On Dialogue)』였다. 이 책을 읽다 보니, 다음과 같은 생각이 들었다.

우리는 지금 "코드보다 대화", "속도보다 공감", "기능보다 의미"를 고민해야 한다.

이 말은 단순한 감상이 아니라, 지금 우리가 기술을 넘어 ‘존재’와 ‘의미’를 다뤄야 할 시점에 도달했다는 것이다. 그리고 이런 변화의 흐름 속에서 David Bohm은 다시 주목받아야 할 사상가라는 것이다.

David Bohm: 물리학자를 넘어선 사유의 흐름

David Bohm는 세계적인 양자물리학자이지만, 그의 사고는 단지 과학에 머물지 않았다. "대화에 관해서"에서도 알 수 있지만, 그는 점점 물질 너머의 의식(Consciousness), 대화(Dialogue), 전체성(Wholeness), 질서(Order)로 사유를 확장해나갔고, 이로 인해 철학자, 심리학자, 심지어 종교가들과도 깊은 대화를 나누게 되었다.

그의 대표작인 _전체와 접힌 질서(Wholeness and the Implicate Order)_와 _대화에 대하여(On Dialogue)_는 과학적 언어로 표현된 존재와 사고, 인간 간의 관계에 대한 본질적인 탐구이다.

Bohm의 주요 사상 – 흐름, 의미, 대화

Bohm은 우리가 일상적으로 쓰는 사고(thought), 언어(language), 시간(time), 질서(order) 같은 개념이 실은 전체성(wholeness)을 파편화시키는 방식으로 작동한다고 보았다. 그는 인간 사고가 현실을 구성하면서도 스스로를 되돌아보지 않는 자기강화적 시스템이라며, 진정한 변화는 사고의 시스템 자체를 보는 메타 인식에서 시작된다고 말한다. 그는 이런 전환을 위해 “대화(Dialogue)”를 제안한다. 그는 대화가 단순한 정보 전달이 아니라, 서로의 가정을 보류(suspension)하고, 의미의 흐름(field of meaning)을 함께 따라가는 참여형 사고(participatory thought)의 장이라고 설명한다.

“In dialogue, a new kind of mind begins to come into being — based on the development of common meaning.”
(On Dialogue, David Bohm)

소프트웨어 개발과의 관계

흥미로운 점은, Bohm이 소프트웨어 개발에 직접적인 영향을 준 기록은 거의 없다는 점이다. 그럼에도 불구하고, 우리가 소프트웨어의 역사에서 매우 중요한 인물들 — 예를 들어 Kent Beck, Ward Cunningham — 의 실천 속에서 Bohm의 사상과 이어진 부분이 있다.

Ward Cunningham은 Wiki를 만든 인물이며, 공동 지식의 장(Field of Shared Knowledge)을 실현하고자 했다. 이는 Bohm이 말한 “field of meaning” 개념과 매우 유사해 보인다. Kent Beck의 테스트 주도 개발(Test-Driven Development)이나 익스트림 프로그래밍(XP) 철학은, 코드 품질 이전에 개발자들 간의 신뢰와 대화의 흐름을 중요시하는 접근이다. 이는 Bohm이 말한 “사고 흐름의 공유”와 맥락을 같이하고 있다.

비록 그들이 Bohm을 직접 인용하지는 않았지만, 그들의 철학적 기반은 Bohm의 사유 구조와 깊이 연결되어 있다고 볼 수 있어 마치 공명하고 있는 것 같다.

건축가 Christopher Alexander와의 연결: 질서의 펼침

대화에 관하여를 읽으면서, 나에게 가장 흥미로웠던 점은 Christopher Alexander가 사용하는 용어를 많이 공유하고 있다는 점이다. Alexander는 『The Nature of Order』에서 살아있는 구조(Living Structure), 중심(Center), 생성 순서(Generative Sequence), 구조보존변형(Structure-Preserving Transformations)을 이야기하며, 공간이 단지 물리적 배열이 아니라 전체 속에서 드러나는 질서(odder)의 펼침(unfolding)이라고 주장한다.

Bohm의 Implicate Order(암묵적 질서) → Explicate Order(명시적 질서) 흐름은 Alexander의 전체로부터 드러나는 중심들의 전개 개념과 유사해 보인다. 이 두 사람은 다음과 같이 이야기 한다.

• 전체는 항상 존재하며, 부분은 그로부터 살아나야 한다.
• 진정한 창조는 전체성을 해치지 않으면서 발생하는 변화다.
• 디자인은 절차가 아니라 살아있는 흐름이다.

Alexander는 이런 사유를 통해 소프트웨어 개발자들에게도 막대한 영향을 미쳤다. 그의 _A Pattern Language_는 소프트웨어 디자인 패턴, 도메인 주도 설계(DDD), 애자일 방법론 등에 깊이 들어가 있으며, 이는 실질적 도구와 이론으로 이어졌다. 반면 Bohm은 Framework나 Tool을 제공하진 않았지만, 그런 흐름의 사유적 바탕을 제공한 존재볼 수 있다.

인공지능시대에서 다시 돌아보는 Bohm

AI가 인간 언어를 모방하고, 의미를 요약하고, 인간의 역할을 대체해 나가려는 지금, 우리는 Bohm이 제공하는 통찰을 다시 살펴 보게 된다.

• 의미(Meaning)는 고정된 것이 아니라, 사람과 사람 사이의 장(field) 속에서 공명하며 살아나는 것이다.
• 사고(Thought)는 자기강화적이며, 의식되지 않으면 무의식적으로 현실을 구성하고 왜곡한다.
• 진정한 대화는 “나는 옳다”의 공간이 아니라, “무엇이 나타나는가”를 함께 듣는 공간이다
• 창조란 새로운 것을 만들기보다, 이미 존재하는 전체의 흐름을 따르고 드러내는 것이다.

이것은 우리가 AI를 통한 생산성과 변화도 중요하지만, 협업을 통한 대화, 공감 그리고 의미에 대해서 다시 생각하게 하는 화두라고 생각된다.

마무리: 공명의 시대, 다시 Bohm으로 돌아가야 할 때

David Bohm은 직접적으로 코드 한 줄 쓰지 않았고, 툴이나 패턴을 만들지 않았다. 그는 조용히, 그러나 깊이 있게 질문을 던졌습니다:

“What is the nature of thought itself?”
“How can we participate in the unfolding of meaning?”
“Can we think together, instead of alone?”

지금 우리는 기술로 너무 멀리 왔고, 이제 다시 그 기술을 움직이는 인간의 ‘사고의 흐름’으로 돌아가야 할 때가 아닐까? 우리가 진짜 협업과 의미의 시대를 살아가려면, 그가 말한 ‘사고의 장(field of thought)’과 ‘대화의 질서(order of dialogue)’를 다시 열어야 할 때이다.

📚 PDF 책 읽기 앱: 기능 요약

기능 설명

• 📖 책 목록 화면 등록된 PDF 책들의 표지를 보여주고, 읽은 비율을 ProgressBar로 표시
• ➕ 등록 기능 파일 선택(File Picker)으로 PDF를 등록
• 🗑 삭제 기능 등록된 책을 삭제할 수 있음
• 📄 책 읽기 화면 선택한 책의 내용을 페이지 단위로 표시, 이전/다음 페이지 이동 가능
• 🔊 TTS 기능 현재 페이지 내용을 TTS로 읽어줌 (기기 TTS or 온라인 TTS 선택 가능)
• ⚙️ 설정 메뉴 사용자가 TTS 엔진을 기기용/온라인용으로 선택 가능

🧱 프로젝트 폴더 및 파일 구조 (패키지 기준)

com.example.pdfreader
├── MainActivity.kt                  // 책 목록 UI (RecyclerView)
│
├── adapter
│   └── BookListAdapter.kt          // RecyclerView Adapter
│
├── data
│   ├── Book.kt                     // Room Entity
│   ├── BookDao.kt                  // Room DAO
│   └── BookDatabase.kt             // Room DB 생성
│
├── tts
│   ├── TtsService.kt            // TTS 호출 (기기/온라인 선택)
│   └── OpenAiTts.kt             // Open AI TTS 통신 API
│
├── ui
│   └── SettingsFragment.kt         // TTS 설정 메뉴
│   └── PdfReaderActivity.kt        // PDF 페이지 보기 + TTS
│
└── res
    ├── xml/preferences.xml         // TTS 선택 Preference 정의
    └── values/arrays.xml           // TTS 옵션 배열 정의

🛠️ Empty Project에서 단계별 구현 순서

🔹 1단계: 기본 구성 (Empty Project → 책 목록 화면 만들기)

• MainActivity.kt 생성
  • RecyclerView 추가하여 등록된 책 표시
  • Book.kt, BookDao.kt, BookDatabase.kt 구성
  • BookListAdapter.kt 작성
  • 책 등록 버튼 → FilePicker 구현
  • PDF 썸네일 추출 (PdfRenderer) → Room에 저장

📦 관련 기술: Room, RecyclerView, PdfRenderer, ActivityResultContracts.OpenDocument

🔹 2단계: 책 읽기 화면 구성

• PdfReaderActivity.kt 생성
• PDF 페이지 표시 (AndroidPdfViewer 또는 PdfRenderer)
• 페이지 이동 버튼 추가 (이전/다음)
• 읽은 페이지 비율 저장 → Book.progress 업데이트

📦 관련 기술: PdfRenderer, Intent 전달, 상태 저장

🔹 3단계: TTS 기능 연결

• PdfReaderActivity에서 진행하면, Background 재생이 안됨. Foreground Service를 이용해서 TtsService.kt 생성
• 현재 페이지의 텍스트 추출 (PdfTextStripper 또는 PdfBox-Android)
• TextToSpeech 기본 연동
• 테스트용 더미 온라인 TTS 연동 (나중에 실제 API로 교체 가능)

📦 관련 기술: TextToSpeech, Coroutine, MediaPlayer (온라인 TTS 음성 재생)

🔹 4단계: 설정 화면 구성

• SettingsFragment.kt 생성
  • preferences.xml에 ListPreference 구성
  • SharedPreferences를 통해 tts_engine 설정값 저장
  • TtsService.kt와 OpenAiTts.kt의 연동

📦 관련 기술: PreferenceFragmentCompat, SharedPreferences, OpenAiTts 연동

📎 참고 라이브러리

참고링크

https://github.com/blcktgr73/BookPlay
https://www.facebook.com/share/v/162RyBjF7A/

Vibe coding으로 웹 기반의 응용을 많이 만들지만 Android 앱도 만들 수 있다.

- PRD 작성: PRD라고 적었지만, Product라기 보다는 기능이 가져야 하는 요구 사항을 정리한다. PRD는 사실 이 보다는 더 넓은 개념에서 제품에 대해 정리한 부분이기는 하다.

- Empy Project 만들기

- PRD 전달하고 코드 생성하기

- 테스트가 가능해지는 시점에서 빌드하면서 Feedback하고 수정

PRD 작성

위와 같은 UI Flow 혹은 Wireframe을 손으로 그렸다. 이 부분에 대한 설명은 다음과 같이 했다.

Android로 첨부한 Wireframe의 앱의 PRD를 작성해줘.
- 첫 화면에서는 버튼이 있어서, 클릭하면 Video Picker가 실행이 돼.
- Video Picker에서 비디오를 선택하면, 가로 화면으로 비디오를 재생해줘.
- 비디오 재생 화면의 오른쪽 상단에 X표 버튼이 있어서, 누르면 첫 화면으로 돌아가.
- 첫 화면에서는 기존에 재생한 비디오 목록을 보여줘. 최대 10개까지 보여줘.

아래는 생성된 PRD에서 일부 수정한 내용이다. 예를 들면, 단순화 하기 이해 Room DB와 SharedPreference 중에서 후자를 선택해서 단순화 하고, Thumbnail 추출은 MediaExtractor로 변경하였다.

# 📄 Product Requirements Document (PRD)

📱 App Name: VideoPlay

## 🎯 목적 (Purpose)
사용자가 휴대폰에 저장된 비디오를 선택해 전체화면(가로모드)으로 재생하고, 최근 재생한 비디오 목록을 쉽게 다시 접근할 수 있도록 하는 Android 앱.

## 🧑‍💻 주요 기능 (Key Features)
1. 홈 화면 (Home Screen)
구성 요소:
[재생 시작 버튼] : 비디오 선택을 위한 버튼
[최근 재생 목록] : 최대 10개의 최근 재생한 비디오 파일 표시

기능:
사용자가 버튼을 누르면 시스템 Video Picker 호출
최근 재생 목록은 가장 최근 것이 상단에 표시되며, 최대 10개 저장
각 목록은 썸네일 + 파일명 표시

2. 비디오 선택 (Video Picker)
Android 시스템의 파일 선택기 사용 (Intent.ACTION_PICK or Intent.ACTION_OPEN_DOCUMENT)
비디오 MIME 타입 필터링 (video/*)
사용자가 선택한 파일 URI를 앱으로 반환

3. 비디오 재생 화면 (Video Player Screen)
가로 화면 고정 (Landscape)
전체 화면 비디오 재생
오른쪽 상단에 [X] 버튼 배치
누르면 재생 중단 및 홈 화면으로 복귀
재생된 파일은 최근 재생 목록에 추가
기존 목록에 이미 있는 경우, 맨 앞으로 이동

10개를 초과하면 가장 오래된 항목 제거

## 🔁 사용자 흐름 (User Flow)
앱 시작
→ 홈 화면 표시

[재생 시작] 버튼 클릭
→ 시스템 Video Picker 실행

비디오 선택
→ 비디오 재생 화면 전환 (가로 모드)

비디오 재생
→ [X] 버튼 클릭 시 홈으로 복귀

홈화면
→ 최근 재생한 목록에 새 항목 반영됨

## 📱 UI 구성 (UI Components)
### 📄 홈 화면
Button - "비디오 선택"
RecyclerView (수직 스크롤)
아이템 구성: 썸네일, 파일명

### 🎞️ 비디오 재생 화면
VideoView or ExoPlayer
전체 화면 (Landscape)
ImageButton (오른쪽 상단) - X 아이콘

### 💾 데이터 저장 (Storage)
최근 재생한 비디오 리스트
최대 10개
SharedPreferences
저장 항목: URI, 파일명, 썸네일 경로(optional)

### ⚙️ 기술 스택 (Tech Stack)
Language: Kotlin
UI Framework: Android View System / Jetpack Compose (선택)
Media Player: ExoPlayer
저장소: SharedPreferences

### 📝 비고 (Notes)
썸네일은 MediaExtractor에서 추출
재생 중 화면 회전은 고정 (android:screenOrientation="landscape")

Cursor로 작업

이 후 작업은 Cursor에서 작업하기 위한 준비 작업과 코드 생성 및 테스트 방법이다. 물론, Cursor에서도 CLI로 gradle build하고 adb로 설치하여 테스트하는 것도 가능하겠지만, Android Studio가 이 작업을 GUI로 처리해 주므로 더 편리할 수도 있다.

- Android Studio에 빈 Project를 만든다.

- Cursor에서 이 Project Folder를 연다.

- PRD 전달하고 코드 생성하기

- 테스트가 가능해지는 시점에서 빌드하면서 Feedback하고 수정

테스트 시점에서는 Android Studio의 logcat의 경우, App과 관련된 log만 필터 하기 때문에 정말 필요한 정보를 Cursor에 피드백하기 좋다. 아래는 완료된 Video Player 구현 데모 영상이다.

마무리

ChatGPT와 같은 LLM으로 코드를 생성하면서 작업도 충분히 가능하지만, Cursor와 같은 IDE의 경우는 피드백 루프를 단순화 해주어 생산성을 더 높여 준다. 여기서 생성한 코드는 아니지만, 유사한 작업을 한 결과물을 github 링크도 남겨 둔다.

https://github.com/blcktgr73/ExoVibe

Claude를 이용해서 AI Coding 도구를 상세 비교해봤어요. 2025년 9월 말 기준 Claude에서도 Open AI Codex가 가장 좋다고 하네요.

AI 코딩 도구 상세 비교

기본 정보 비교

접근 방식 및 플랫폼

핵심 기능 비교

성능 벤치마크

*추정치 (공식 벤치마크 미공개)

가격 정책

지원 언어 및 프레임워크

장단점 요약

GPT-5-Codex

장점: 최고 성능, 동적 작업 시간, 강력한 코드 리뷰 단점: 상대적으로 높은 비용, API 제한

Claude Code

장점: 터미널 특화, 자연어 처리 우수, 단계별 설명 단점: CLI만 지원, IDE 통합 없음

GitHub Copilot

장점: 광범위한 IDE 지원, Git 통합, 큰 커뮤니티 단점: 실시간 완성 위주, 복잡한 프로젝트 구축 제한

Gemini CLI

장점: Google 생태계 통합, 최신 AI 기술 단점: 상대적으로 새로움, 제한적인 문서

Cursor

장점: 올인원 에디터, 실시간 협업, 직관적 UI 단점: 새로운 에디터 학습 필요, 플랫폼 의존성

Windsurf

장점: 통합 개발 환경, 웹 개발 특화 단점: 상대적으로 새로움, 제한적인 언어 지원

선택 가이드

• 최고 성능 원할 때: GPT-5-Codex
• 터미널 작업 중심: Claude Code
• 기존 IDE 계속 사용: GitHub Copilot
• Google 생태계 사용자: Gemini CLI
• 올인원 솔루션: Cursor
• 웹 개발 중심: Windsurf
• 예산 고려: Codeium (무료)

들어가며

소프트웨어 개발자에게는 디자인 패턴으로 잘 알려져 있는 Christopher Alexander(CA)는 건축가이다. 그는 수많은 프로젝트에 참여했으며, 사후에도 Center for Environmental Structure(CES)를 통해 그의 사상은 Building Beauty 프로그램 등을 통해 교육적으로 계승되고 있다. Alexander의 중심 개념들은 고정된 형태를 설계하는 것이 아니라, 사용자의 참여와 환경의 변화에 따라 '살아있는 구조(living structure)' 로 점진적으로 키워가는 과정이라는 철학을 담고 있다.

적용 사례: Eishin 학교와 University of Oregon

Alexander의 철학은 다양한 프로젝트에 적용되었다. 그중 대표적인 두 사례는 일본의 Eishin 학교 캠퍼스와 미국 University of Oregon 이다.

• Eishin 학교는 Alexander가 직접 설계한 유일한 고등학교 캠퍼스이며, Generative Sequence와 Pattern Language가 매우 충실히 구현된 사례로 알려져 있다. 학생, 교사, 설계자 모두가 참여하여 하나의 생명 있는 공간을 창조했다. 이 과정이 "The Battle for the Life and Beauty of the Earth: A Struggle Between Two World-Systems"에 잘 설명되어 있다.
• University of Oregon은 1975년에 시작되어 University of Oregon이 고정된 마스터플랜 대신 참여 중심의 계획과 점진적인 변화 방식을 도입한 장기 프로젝트이다. 이 실험은 이후 공식적인 Campus Plan의 철학적 기반이 되었다. 이 내용은 "The Oregon Experiment"에 잘 설명되어 있다.

2025 Campus Plan의 핵심 원칙 세 가지

특히 이번 2025 개정판에서는 CA의 철학과 밀접하게 연결되는 세 가지 원칙이 보인다.

1. 원칙 1: Process and Participation

   • “의미 있는 참여 기회를 제공해야 한다.”
   • 사용자 그룹과 전문가, 위원회가 협력하여 계획을 수립하며, 누구나 프로세스에 참여할 수 있는 구조가 마련되어 있다.

2. 원칙 4: Space Use and Organization

   • “공간은 기능적이고 유연하며 조화롭게 조직되어야 한다.”
   • 사람 중심의 배치와 10분 도보권 안에서의 공간 설계를 기본으로 하여, 생명력 있는 물리적 질서를 만들고자 한다.

3. 원칙 11: Patterns

   • “패턴은 문장의 단어처럼 함께 작동해 하나의 전체를 만든다.”
   • CA의 Pattern Language를 실무에 적용하며, 모든 설계 프로젝트는 관련 패턴을 선택하고 검토하는 절차를 따라야 한다.

이 세 가지 원칙은 Generative Sequence의 실행 조건이기도 하며, Oregon 대학이 단순한 철학을 넘어 실천으로 전환하고 있다는 증거로 볼 수 있다.

마무리

"The Nature of Order"를 통해, CA는 설계가 단순히 '형태를 만드는 프로세스'가 아니라 '살아있음을 향상시키는 형태를 만드는 과정'이어야 한다고 말한다. Eishin 학교가 그 이상을 구체적으로 구현한 시도였다면, University of Oregon의 Campus Plan은 그 철학을 수십 년간 유지하며 제도화해 온 실천 모델이라고 할 수 있다.

한편, Hatfield‑Dowlin Complex와 같은 대형 기부 프로젝트는 설계의 방향이 기부자의 의사에 의해 결정되었으며, 사용자 참여는 거의 이루어지지 않았다는 점에서 비판의 여지가 크다. 이는 Alexander의 사상과 반대되는 것으로, 현실적 타협의 산물이라 할 수 있다. 다만, 이 건물이 메인 캠퍼스와 물리적으로 분리된 위치에 있다는 점에서 그 영향은 제한적이라 볼 수 있다.

다시 말하자면, 완전하지는 않지만 여전히 ‘살아있는 캠퍼스’를 만들어가고 있는 보기 드문 사례이다.

참고문헌

• Christopher Alexander, "The Nature of Order: Book 2 – The Process of Creating Life" (2002)
• Christopher Alexander et al., "The Battle for the Life and Beauty of the Earth: A Struggle Between Two World-Systems", (2012) Center for Environmental Structure, 16
• Christopher Alexander et al., "The Oregon Experiment", 1975
• University of Oregon, Campus Plan 2025 (공식 웹사이트 cpfm.uoregon.edu)

2025년 9월 20일 신사동에서 Claude Code Meetup이 있었고, 많은 사람들이 지원했음에도 운좋게 선정되어 다녀왔다. 짧게 요약 가능한 내용들을 정리해 본다.

Claude Code Meetup 발표

① 최흥민 — 오프닝 & 커뮤니티 맥락

• 한국 내 Claude 사용자 점유율 소개 (세계 3위, 3.7%).
• 바이브 코딩 → 에이전트 코딩 → AI 협업 코딩 흐름 강조.

② Dickson Tsai (Anthropic, Claude Code 팀) — Agents/Subagents, Hooks, Agentic RAG

• Agents 정의: LLM + Tool Call + Environment.
• Subagents: 병렬 작업 분산.
• Hooks: Claude Code 실행 지점에 동작 삽입 (lint/test/build 등).
• Slash Commands: Git workflow 자동화.
• Agentic RAG: 단순 검색을 넘은 실행 기반 Retrieval.

③ Daniel Avila (Claude Code Template 개발자) — 템플릿/도구 시연 및 Q&A

• 주요 질의응답
  • MCP 동적 로드/해제: 초기 단계라 미지원, 향후 확장 예정.
  • 특정 도메인 지식 부족 → 특화 모델 발전 방향 논의.
  • VS Code 플러그인(Carrot)과 Claude API 연동 가능 여부 → SDK 활용 권장.
  • 모바일 UI 기능 요청: 현재 미지원, hook 기반 확장 가능성.
  • LM OS(LLM 운영체제) 비전에 대한 질의 → 장기적 비전 속에 포함되어 있음을 언급.

④ 박진영 (사이오리아 엔지니어, ‘부타탱크’) — 컨텍스트·워크플로우·오케스트레이션·MCP/리뷰 루프

• Claude Code Context: Prompt · CLAUDE.md · Project Files · System Prompt · API/Tools.
• Workflow(YAML): multi-agent 워크플로우 자동화.
• Core Philosophy: 여러 모델 오케스트레이션으로 최적 결과 달성.
  • Tech Spec 작성 → PLAN.md 작성 → Compiler-in-the-loop.
• 실천 지침:
  • CLAUDE.md → PLAN.md 지침 기반 task 실행, TECHSPEC.md 참조.
  • CLI Agent로 코드 수정 + TODO.md 자동 업데이트.
  • Python 루프: Pyright · Ruff 활용.
• Agent in the Loop:
  • Serena MCP (심볼 단위 코드 수정).
  • Zen MCP (멀티모델 코드 리뷰 → 자동 리뷰 트리거).

✅ 왜 Cross-platform 개발이 필요한가?

Cross-platform 개발은 한번의 개발로 여러 플랫폼에 적용 가능한 것을 이야기 한다.

무엇 보다도 비싼 개발 리소스 절감이 가능하다. 모바일도 크게는 Android와 iOS로 나뉘어 있어서 각각 따로 개발해야 한다. 개발 인력만 봐도 최소 2배가 필요하다. 개발도 효율화가 되지만, 유지보수 효율도 높아 진다. 공통 코드이므로 한번만 수정하면 된다. 또한, 일부 플랫폼 특화 기능만 분기 처리 (예: Platform.OS === 'ios')도 가능하다.

스타트업 같은 경우는 시장 대응 속도도 빠르게 가능하다. 특히, 초기 MVP 또는 실험적 서비스는 짧은 시간에 양 플랫폼에 출시하는 것이 중요할 수 있다. 이 때, Cross-platform은 런칭 시간 단축, 빠른 배포 가능하다.

무엇 보다도 중요한 것 중에 하나는 일관된 사용자 경험 이라고 할 수 있겠다. 동일한 UI 구성 요소와 로직을 공유함으로써 Android/iOS 간 UI/UX의 일관성 확보하고, 디자인 시스템이나 UI 패턴을 통합하여 관리할 수 있다.

하지만, Cross-platform이 만능은 아니다. 다음과 같은 지적도 있다. 그래서 많은 기업들이 "핵심 기능은 Native, 나머지는 Cross-platform" 구조를 도입한다. "Cross-platform은 하나의 기술 방식이고, Hybrid는 이를 Native와 조합하는 전략이라고 할 수 있다.

이러한 Cross-platform 전략에는 Flutter, React Native 등이 있다. React Native의 경우는 기존의 Web 개발자들이 접근이 용이하여 많이 채용되고 있는 상황이다. 위에서 언급한 것처럼 Native도 일부 적용하고 있으므로 기존 iOS, Android 개발 경험도 도움이 될 수 있겠다.

React Native로 사용할 수 있는 옵션은 크게 세 가지 범주로 나뉘며, 개발 목적과 프로젝트 규모, 유지보수 편의성에 따라 적절한 선택이 필요합니다:

✅ 1. 기본 React Native (Bare React Native)

✦ 설명:

• Facebook에서 만든 기본 react-native 프레임워크
• Native 모듈(Android/iOS) 직접 개발 가능

✦ 장점:

• Native 기능에 가장 직접적으로 접근 가능
• 필요한 라이브러리만 선택해서 구성 가능 (유연함)
• EAS Build 또는 Xcode/Android Studio 사용 가능

✦ 단점:

• 환경 설정 복잡 (Xcode, Android SDK, CocoaPods 등)
• 초기 설정과 유지보수 부담 큼

✅ 2. Expo (Managed Workflow)

✦ 설명:

• React Native 위에 구축된 프레임워크
• 설정, 빌드, 배포까지 쉽게 만들어주는 도구 포함 (Expo Go, EAS Build)

✦ 장점:

• 개발 시작이 매우 빠름 (npx create-expo-app)
• Hot Reload, Expo Go로 실시간 테스트 가능
• 다수의 기본 API 내장 (카메라, 위치, 센서 등)

✦ 단점:

• Expo SDK에 없는 기능은 eject 필요
• 네이티브 코드 직접 수정이 어려움 (Managed Workflow 기준)

✅ 3. Expo Bare Workflow (또는 Ejected Workflow)

✦ 설명:

• Expo의 유용한 기능은 유지하면서도 native code 수정이 가능하도록 한 방식
• expo eject 명령으로 전환 가능

✦ 장점:

• Expo SDK의 일부 기능 사용 가능
• Native 모듈 직접 커스터마이징 가능

✦ 단점:

• Expo 관리형 워크플로우의 간편함은 일부 상실됨
• Native 설정 및 빌드 환경 세팅 필요

✅ 주요 선택 기준 비교

![[react_native_workflows.png]]

✅ 사용 예시

• 간단한 앱 + 빠른 배포가 목적: Expo Managed Workflow
• 카메라, Bluetooth, Background task 등 Native 기능 필요: Expo Bare 또는 Bare React Native
• 기업 앱, 고성능/맞춤형 기능이 많은 앱: Bare React Native

대표적인 사례로 React Native는 Facebook, Instagram, Discord 등에서 채용하고 있다고 한다. 하지만, React Native만 쓴다기 보다는 Native도 활용하는 Hybrid가 대세라고 하겠다. 보안이나 HW와 연동하는 부분에서는 특히 이러한 것들이 필요하겠다.

다음은 React Native에서도 접근 가능한 전략이라고 하겠다. Native와 연동은 모두 가능하다고 하겠다.

당신의 목표는?
├── 빠르게 MVP 출시 or 간단한 앱 → Expo Managed Workflow
│
├── 네이티브 기능이 일부 필요하다면? (카메라, Bluetooth 등)
│   ├── Expo 기능도 일부 쓰고 싶다 → Expo Bare Workflow
│   └── Expo 없이 완전한 커스터마이징 원함 → Bare React Native
│
└── 고성능 앱 or 대규모 앱 (예: 게임, 복잡한 비즈니스 로직)
    → Bare React Native 권장

✅ 마무리

이 글은 React Native로 간단한 구현을 하면서 검토하기 시작했고, 마무리 단계에서 다시 정리해 본 글이다. Android가 주된 개발 경험인 입장에서 이러한 설계에 가까운 개념 검토와 정리는 향후 어려 설계 및 구현에도 도움이 될 것이라 기대해 본다.

올해 일어나고 있는 변화들을 늦게나마 살펴보며, 계속 놀라고 있다. 특히 아래 영상은 그 흐름을 잘 정리해 주셔서, 흥미롭게 볼 수 있었다.

Claude Code 스터디를 하며 처음엔, 단지 에이전트에게 일을 시키는 정도로 생각했다. 하지만 간단한 YouTube 콘텐츠 분석 요약만 시켜봐도, 지금은 수준 자체가 달라졌음을 금방 체감할 수 있었다. 영상에서 언급하는 많은 내용에 공감했고, 특히 이제는 10x, 100x 엔지니어라는 표현조차 무색할 정도라는 생각이 들었다.

그럼에도 불구하고, 미래에 대한 전망은 조금 다른 관점에서 보고 싶다. 특히 “협업은 필요 없다”, “소통은 비용이다”라는 메시지에는 질문이 생긴다.

AI가 잘하는 건 여전히 수학과 프로그래밍 같은 명확한 문제들이다. 하지만 사람을 다루는 일, 인간 사이의 관계 형성과 의미 조율은 다르다. 커뮤니케이션의 본질은 그 ‘모호함’을 다루는 데 있다.

AI 덕분에 솔로프리너의 시대가 열린 건 분명하다. 하지만 조직이 성장하는 단계에서는, 협업의 역할은 여전히 중요하다고 생각한다. 1000x 엔지니어가 등장해서 이 문제마저 해결할지도 모르지만, 스케일의 법칙에는 늘 한계가 있었다. 그렇기에 협업은 완전히 사라지지는 않을 것이다.

짧게 요약하자면:

사람이 다루는 문제에 어찌 0과 1만 존재하겠는가?
1도 들여다봐야겠지만, 0과 1사이의 세계야말로 우리가 더 탐구해야 할 영역 아닐까?