> ## 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.

# AI와 개발하면서 내가 직접 코드를 덜 쓰게 된 대신 더 많이 하게 된 일들
- URL: https://blog.sorune.org/ai-native-development-boundaries/
- Published: 2026-09-11T22:37:11.000Z
- Updated: 2026-09-22T10:15:18.000Z
- Description: 코드를 직접 쓰는 시간은 줄었는데 개발한다는 감각은 오히려 강해졌다. CharaWeave와 workspace-ops를 만들던 하루를 돌아보며 AI가 구현량을 맡은 뒤 내가 더 많이 하게 된 일을 정리했다.
- Author: Sorune — Engineering, Photography & Lab Notes
- Tags: Engineering, AI-Native Engineering, Architecture, Developer Tools, Human-in-the-loop

2026년 9월 4일에는 개발이 이상하게 재미있었다.

그날 내가 직접 쓴 코드의 양이 많았던 것은 아니다. 오히려 반대였다. workspace-ops와 CharaWeave 모두 구현의 상당 부분을 AI가 맡고 있었다.

그런데도 하루가 끝났을 때는 예전보다 더 많이 개발한 느낌이 들었다.

본업과 생활, 서버 관리, 여러 개인 프로젝트를 같이 돌리다 보니 직접 boilerplate와 adapter를 오래 붙잡고 있을 시간은 줄었다. 예전 같으면 아이디어를 정리하다가 “언젠가 구현해야지” 하고 끝났을 일이 많았다.

AI를 쓰고 달라진 것은 그 생각과 실제 시스템 사이의 거리가 짧아졌다는 점이었다.

아이디어를 말하고 몇 분 뒤 코드를 볼 수 있다는 사실보다 더 크게 느껴진 변화가 있었다.

**구현이 빨라지자 내가 무엇을 결정해야 하는지가 훨씬 선명하게 보이기 시작했다.**

그날 두 프로젝트에서 계속 했던 일은 코딩보다 “이 책임이 정말 여기 있어야 하는가?”를 묻는 일이었다.

## 작은 Toolkit이 갑자기 workspace control plane처럼 보이기 시작했다

workspace-ops는 처음부터 큰 제품으로 시작하지 않았다.

여러 개발 환경에서 공통으로 쓸 Toolkit 정도를 원했다. repository와 worktree를 다루고, 반복되는 명령을 줄이고, 서버에서 위험한 조작을 막는 정도였다.

그런데 실제로 사용하기 시작하니 질문이 계속 늘어났다.

이 worktree는 왜 만들어졌는가. 어느 AI session이 지금 이 repository를 작업하고 있는가. 현재 HEAD가 accepted state인가. 작업이 끝난 worktree를 지워도 되는가. 같은 프로젝트에서 파생된 여러 repository를 어떻게 한눈에 볼 것인가.

Git은 branch와 commit, worktree를 잘 관리한다.

하지만 Git이 관리하는 것은 주로 코드의 상태다.

내가 점점 필요로 하게 된 것은 그 코드 주변의 **작업 문맥**이었다.

당시에는 orchestration session에서 worktree를 여덟 개 정도 동시에 돌리는 경우도 있었고, Codex가 붙은 physical worktree와 내가 머릿속에서 생각하는 논리적 작업 단위가 항상 일치하지도 않았다.

그래서 상태를 적어보면 이런 관계가 나왔다.

```text
Project
Repository
Worktree
Session
Machine
Accepted Commit
Authority
Acceptance

```

처음에는 “도구가 너무 커지는 것 아닌가?”라는 생각이 들었다.

실제로 커지고 있었다.

다만 AI가 마음대로 기능을 붙여서 커진 것과는 조금 달랐다. 내가 실제 작업에서 겪는 불편을 하나씩 해결하다 보니, shell script가 다루던 대상보다 문제의 범위가 컸던 것이다.

그 순간 workspace-ops를 보는 관점도 바뀌었다.

repository를 관리하는 툴보다 **physical Git state와 logical development context 사이를 연결하는 시스템**에 가까웠다.

AI가 빠르게 구현해주지 않았다면 아마 이 문제를 여기까지 따라가보기도 전에 시간이 부족했을 것이다.

## 경계를 나누면 끝날 줄 알았는데 이번에는 접시가 너무 많아졌다

나는 프로젝트 안에서 의미가 독립된 기능을 별도 package나 repository로 빼는 편이다.

처음에는 재사용 때문이라고 생각했다.

그런데 AI가 큰 codebase를 다루는 모습을 보면서 이유를 조금 다르게 보게 됐다.

AI는 큰 repository 안에서 필요한 helper를 찾는 데 꽤 능숙하다. 가까운 type을 가져오고, 기존 구현을 참고해 현재 task를 해결한다.

문제는 그 선택 하나하나가 충분히 합리적이라는 점이다.

한 번의 구현에서는 자연스러운 참조였는데 비슷한 선택이 여러 번 누적되면 사람이 보는 구조는 쉽게 흐려진다. “왜 이 모듈이 저 모듈을 아는가?”라는 질문에 답하기 어려워진다.

그래서 어떤 기능이 독립적인 semantic contract를 가지고 있고 상위 product를 몰라도 설명할 수 있다면 물리적인 경계까지 강화하는 쪽을 선택했다.

repository extraction이 내게는 packaging보다 architecture enforcement에 가깝다는 걸 그날 명확히 자각했다.

하지만 당연히 대가가 있었다.

한 repository의 spaghetti를 정리하려고 여러 repository로 나누고 나니, 이제는 그 repository들을 누가 어떤 문맥에서 작업하는지 관리해야 했다.

그날 history에 적어둔 문장이 아직도 제일 정확하다.

> 스파게티를 해결하려고 접시를 여러 개로 나눴더니, 이제 접시 관리 시스템을 만들고 있다.

workspace-ops가 생긴 이유를 이보다 짧게 설명하기 어렵다.

## CharaWeave에서는 한 축으로 설명하던 모델이 먼저 깨졌다

같은 날 CharaWeave에서는 전혀 다른 문제를 보고 있었다.

초기 구조는 비교적 단순했다.

```text
Core
→ Runtime
→ Adapter
→ Host

```

어디에서 실행되는지와 dependency direction을 설명하기에는 좋은 모델이었다.

그런데 기능이 늘자 같은 Runtime 안에 전혀 다른 의미가 들어오기 시작했다.

Definition, Behavior, Target Policy, Lifecycle, Presentation, Host interaction 같은 것들이 같은 실행 계층에 있다는 이유만으로 서로를 알아도 되는 것처럼 보였다.

여기서 기존 모델을 더 세분화하는 방법도 있었다.

대신 질문을 하나 추가했다.

**어디에서 실행되는가와 무엇을 의미하는가는 다른 축 아닌가?**

그 질문을 기준으로 CharaWeave를 다시 보니 실행 위치를 설명하는 구조와 character semantics를 설명하는 구조를 동시에 유지할 수 있었다.

이 결정은 코드보다 모델에서 먼저 나왔다.

AI가 제안한 여러 구조 중 무엇을 채택할지 결정할 때도 “구현 가능한가?”보다는 “이 변화 이유가 같은가?”를 기준으로 봤다.

결과적으로 Application / Instance / Pod라는 primitive도 그 과정에서 정리됐다.

- Application은 어떤 세계와 규칙의 장인지
- Instance는 지속되는 존재가 누구인지
- Pod는 그 존재가 지금 어디에서 어떤 실행 상태로 나타나는지

중요했던 것은 이름 자체보다 서로 다른 질문을 한 타입 안에 다시 합치지 않는 것이었다.

## 그리고 AI가 만들어줄 수 있는 기능 하나를 일부러 잘랐다

CharaWeave에서 같은 character를 여러 host에 띄운다면 자연스럽게 synchronization 문제가 나온다.

기술적으로 구현할 수 있다.

persistent state를 두고 network sync를 만들고 account와 identity를 연결하면 된다. 더 가면 discovery나 marketplace까지 이어질 수 있다.

AI도 이런 확장을 구현할 수 있다.

하지만 그날은 오히려 여기서 STOP을 걸었다.

CharaWeave library가 책임질 것은 character definition과 runtime primitive, behavior, host adapter까지라고 봤다.

cross-host global state authority, account, ownership, network persistence까지 들어가면 library가 서비스 플랫폼으로 바뀐다.

가능하다는 사실이 책임의 근거가 되지는 않는다.

이 경험 이후 AI와 작업할 때 내가 가장 자주 묻는 질문도 바뀌었다.

“이거 만들 수 있어?”보다 “이 책임이 정말 이 repository에 있어야 해?”를 먼저 보게 됐다.

## 구현량이 줄어든 대신 판단이 더 자주 필요해졌다

AI가 구현을 맡으면 사람이 architecture만 하면 된다는 말은 너무 단순하다.

실제로는 구현이 빨라진 만큼 판단 횟수가 늘었다.

예전에는 기능 하나를 직접 만드는 데 시간이 오래 걸렸기 때문에 잘못된 방향으로 가더라도 생성되는 코드의 양 자체가 제한적이었다.

지금은 그렇지 않다.

boundary를 잘못 잡은 상태에서도 controller, adapter, test, documentation이 매우 빠르게 완성된다. 그리고 테스트까지 통과하면 그 구조는 다음 작업의 “기존 선례”가 된다.

그래서 구현을 맡긴 뒤 내가 하는 일은 결과를 승인하는 것만이 아니다.

어떤 source가 canonical인지 확인하고, 변경 가능한 범위를 정하고, 테스트가 실제로 무엇을 증명하는지 보고, 잘못된 책임이 섞이면 다시 잘라낸다.

필요하면 구현을 버리는 결정도 한다.

이 과정에서 STOP 권한이 생각보다 중요했다.

AI는 요청한 기능을 끝까지 구현하는 데 유리하다. 반면 제품 전체에서 “여기부터는 다른 시스템의 책임이다”라고 끊는 판단은 별도로 줘야 한다.

## Git이 충분하지 않았던 이유도 결국 같은 문제였다

workspace-ops를 만들면서 Git의 한계를 느꼈다고 쓰면 Git이 부족한 도구처럼 들릴 수 있다.

실제로는 반대다.

Git은 content state를 아주 잘 관리한다.

내가 필요했던 것은 Git이 원래 해결하려 하지 않았던 coordination state였다.

```text
Git
→ commit / branch / worktree / content history

workspace context
→ project relation / session ownership / authority / acceptance

```

둘을 억지로 하나로 합칠 필요는 없었다.

CharaWeave에서도 마찬가지였다.

runtime layer 하나로 execution과 semantics를 모두 설명하려다 문제가 생겼고, 서로 다른 축으로 두자 구조가 더 단순해졌다.

그날 두 프로젝트는 전혀 다른 코드를 다루고 있었지만 내가 복잡성을 푸는 방식은 비슷했다.

한 축으로 설명되지 않는 문제가 생기면 layer를 하나 더 쌓기 전에 **서로 다른 질문을 같은 축에 올려놓은 것은 아닌지** 먼저 보는 것이다.

## 코드를 덜 쓰는데 왜 더 개발하고 있다고 느꼈을까

이 질문이 그날 가장 오래 남았다.

workspace-ops 코드의 대부분을 AI가 작성했고 CharaWeave도 AI 구현 비중이 높았다.

그런데 개발한다는 감각은 줄지 않았다.

내가 재미있어하던 부분이 구현 타이핑 자체보다 문제를 정의하고, 의미를 나누고, 결과를 실제 시스템으로 확인하는 데 더 가까웠기 때문인 것 같다.

예전에는 이 사이에 반복 구현 비용이 컸다.

```text
아이디어
→ 설계
→ boilerplate
→ adapter
→ tests
→ docs
→ refactor
→ 시간 부족

```

지금은 같은 날에도 모델을 하나 세우고, 실제 구현을 본 뒤, 틀리면 다시 경계를 바꾸는 사이클을 여러 번 돌릴 수 있다.

AI가 내게 준 가장 큰 변화는 “코드를 안 써도 된다”가 아니었다.

**생각을 실제 시스템으로 검증하는 비용이 낮아졌다**는 쪽에 가깝다.

물론 그만큼 잘못된 생각도 더 빨리 구현된다.

그래서 throughput이 늘수록 architecture와 contract, validation scope가 덜 중요해지는 게 아니라 오히려 더 중요해졌다.

## 지금 남아 있는 기준

그날 기록의 마지막에는 몇 문장을 적어뒀다.

그중 지금도 가장 자주 쓰는 기준은 이것이다.

> AI가 만들 수 있다 != 만들어야 한다.

코드를 누가 작성했는지보다 중요한 것은 어떤 책임을 어디에 둘지, 무엇을 현재 source of truth로 인정할지, 어디에서 STOP할지를 누가 결정하는가다.

AI가 구현량을 많이 맡더라도 그 결정과 검증을 계속 내가 소유한다면, 내가 직접 코드를 쓰는 시간이 줄었다는 사실과 개발자의 역할이 줄었다는 사실은 같은 말이 아니다.

적어도 내 작업에서는 오히려 반대였다.

코드를 덜 쓰게 된 뒤에야 내가 실제로 어떤 개발을 좋아했는지가 더 잘 보이기 시작했다.