하네스 엔지니어링은 어떻게 개발을 설계 문제로 바꾸는가: 토이 프로젝트를 진행하며

최근 AI 코딩 도구를 둘러싼 관심은 조금씩 프롬프트 자체에서 작업 시스템으로 이동하고 있다. 한 번 잘 답하게 만드는 것보다, 여러 번의 작업에서도 맥락을 잃지 않게 하고, 결과를 검증하고, 다시 다음 변경으로 안전하게 이어 붙이는 구조가 더 중요해졌기 때문이다.

나는 이 변화를 단순한 생산성 향상보다는 개발의 무게중심이 이동하는 현상으로 보고 있다. 예전에는 구현 세부사항을 얼마나 빠르게 손으로 밀어 넣느냐가 개발자의 핵심 역량처럼 보였다면, 지금은 점점 더 “문제를 어떻게 구조화하고, AI가 일할 경계를 어떻게 설계하며, 그 결과를 어떤 단위로 검증할 것인가”가 중요해지고 있다.

이번 글은 그 변화를 가볍게 실험해 본 기록이다. 프로젝트는 스핔이 뽀모도로 펫. 트릭컬의 밈 캐릭터인 스핔이에서 모티브를 가져온 비공식 팬 프로젝트로, macOS와 Windows 위에서 항상 떠 있는 데스크톱 오버레이 펫이자 뽀모도로 타이머다.

그런데 이 글의 핵심은 캐릭터 앱 자체보다, 그 앱을 만든 방식에 있다.

이번 프로젝트에서 사용하는 데 들어간 기술 스택은 Tauri 2와 TypeScript, 단 둘뿐이었다. 서버도 없고, 인증도 없고, 클라우드도 없고, 거대한 프레임워크도 없다. 대신 내가 집중한 것은 구현보다 하네스 설계였다. 다시 말해, Codex가 코드를 잘 작성하도록 만드는 문맥, phase, 검증 기준, ship 단위를 설계하는 일이었다.

그래서 이 글은 “AI로 앱 만들어봄”에 대한 후기가 아니다. 오히려 그 반대다. AI 코딩이 본격적으로 실전 도구가 되기 시작할수록, 개발자는 더 이상 단순 구현자가 아니라 문제 구조 설계자에 가까워진다는 점을 정리해 보고 싶었다.

왜 하필 스핔이 뽀모도로 펫이었나

토이 프로젝트를 고를 때는 일부러 기준을 두었다.

• 결과가 바로 눈에 보여야 한다.
• 너무 큰 서비스면 안 된다.
• UI 감각과 상태 설계가 동시에 들어가야 한다.
• 멀티 플랫폼 제약이 있어야 한다.
• 하지만 서버, 인증, 운영 인프라 같은 잡음은 최대한 배제해야 한다.

스핔이 뽀모도로 펫은 이 조건에 잘 맞았다.

겉으로 보면 단순하다. 작은 캐릭터가 바탕화면 위를 돌아다니고, 클릭하면 반응하고, 타이머가 끝나면 상태가 바뀌고 소리가 난다. 하지만 실제로는 생각보다 많은 층위의 문제가 겹쳐 있다.

• transparent overlay window
• always-on-top 동작
• macOS / Windows 공통 동작
• 캐릭터 이동과 방향 전환
• 클릭 반응과 오디오 큐
• 타이머 상태 전이
• 경량 데스크톱 유틸리티로서의 제약

이런 문제는 AI에게 막연하게 “귀여운 데스크톱 펫 만들어줘”라고 던지면 오히려 망가지기 쉽다. 이유는 간단하다. 문제의 종류가 하나가 아니라, window shell, timer domain, visual state, audio, packaging 같은 서로 다른 책임이 얽혀 있기 때문이다.

즉, 이 프로젝트는 기능 규모는 작지만 설계 밀도는 낮지 않았다. 그래서 오히려 하네스 엔지니어링을 실험하기에 좋은 대상이었다.

이번 프로젝트를 개발이 아니라 설계 문제로 본 이유

이번 프로젝트를 하며 가장 흥미로웠던 지점은, AI를 쓰는 순간 개발이 사라진 것이 아니라 개발의 병목이 이동했다는 사실이었다.

예전에는 새로운 데스크톱 앱을 만들겠다고 하면 보통 이런 식으로 접근했다.

• 프레임워크를 공부한다.
• 예제를 따라친다.
• 직접 구조를 잡는다.
• 기능을 구현한다.
• 중간에 아키텍처를 다시 정리한다.

이번에는 접근 순서가 달랐다.

• 제품의 중심 경험이 무엇인지 정한다.
• 무엇을 만들지보다 무엇을 만들지 않을지를 먼저 정한다.
• 기능을 phase 단위로 나눈다.
• 각 phase의 완료 조건을 문서화한다.
• AI에게 실행을 맡기되 verify와 ship 기준은 사람이 쥔다.

즉, 내 역할은 “코드를 많이 쓰는 사람”보다는 “문제를 분해하고 경계를 명확히 하는 사람”에 더 가까웠다.

이 변화는 꽤 크다. AI가 구현 속도를 끌어올리는 만큼, 사람은 더 높은 층위에서 설계를 맡게 된다. 그 설계에는 아키텍처만 포함되지 않는다. 범위 정의, 검증 전략, 세션 분리, 회귀 방지, 배포 가능 단위까지 함께 들어간다.

그래서 나는 하네스 엔지니어링을 단순히 “AI 잘 쓰는 법”으로 보지 않는다. 오히려 AI 시대에 개발을 다시 설계 문제로 복원하는 방식에 가깝다고 생각한다.

GSD는 라이브러리보다 워크플로우에 가깝다

이 프로젝트는 GSD(Get Shit Done) 흐름을 바탕으로 진행했다. 처음에는 이걸 라이브러리라고 불러야 하나 잠깐 고민했는데, 결론부터 말하면 라이브러리보다는 워크플로우, 방법론, 혹은 툴링 세트에 가깝다고 보는 편이 맞다.

이유는 명확하다.

• 애플리케이션 코드에 import 해서 쓰는 구조가 아니다.
• 프로젝트 상태를 문서와 디렉터리 구조로 외부화한다.
• plan, execute, verify, ship 같은 개발 단위를 강하게 분리한다.
• 구현보다 문맥 유지와 상태 관리에 더 큰 비중을 둔다.

실제로 프로젝트 루트에는 .planning/ 아래에 꽤 많은 문서가 쌓여 있다.

• .planning/PROJECT.md
• .planning/REQUIREMENTS.md
• .planning/ROADMAP.md
• .planning/STATE.md
• .planning/phases/...

여기서 중요한 점은 이 문서들이 회고록이 아니라는 것이다. 이 문서들은 다음 Codex 세션이 이어서 작업할 수 있게 만드는 지속 가능한 컨텍스트 저장소였고, 동시에 내가 지금 무엇을 검증했고 무엇이 아직 미완인지 파악하는 운영 기준이었다.

즉, GSD는 기능을 추가하는 코드 라이브러리라기보다, AI 코딩이 컨텍스트를 잃지 않도록 프로젝트를 운영하는 하네스에 더 가깝다.

실제로는 이렇게 phase를 나눴다

이번 프로젝트의 roadmap은 아래처럼 구성했다.

• Phase 1: Overlay Shell Foundation — 오버레이 셸의 기초를 잡는 단계
• Phase 2: Pet Motion & Click Personality — 캐릭터가 살아 있는 것처럼 보이도록 움직임과 클릭 반응을 붙이는 단계
• Phase 3: Pomodoro Feedback Loop — 타이머 흐름과 완료 피드백을 연결해 제품 경험을 완성하는 단계
• Phase 4: Cross-Platform Hardening — macOS와 Windows에서 실제 배포 가능 수준으로 안정화를 진행하는 단계

겉보기에 평범한 순서처럼 보이지만, 이 phase 분리는 꽤 의도적이었다.

이 프로젝트의 핵심 가치는 “귀여운 캐릭터”가 아니라, 방해되지 않으면서도 집중 상태를 가볍게 시각화하는 데스크톱 동반자를 만드는 데 있었다. 그래서 구현 순서도 그 가치에 맞게 정리할 필요가 있었다.

• 먼저 창이 올바르게 떠야 한다.
• 그다음 캐릭터가 살아 있는 것처럼 보여야 한다.
• 그다음 타이머와 완료 피드백이 붙어야 한다.
• 마지막으로 플랫폼 안정화와 packaging을 다듬어야 한다.

이 순서를 지키면 “보여주기 좋은 기능”보다 “제품이 성립하는 조건”을 먼저 확보하게 된다. 개인적으로 AI 코딩에서 가장 위험한 패턴 중 하나가, 인상적인 기능부터 쌓다가 나중에 기반이 흔들리는 경우라고 생각한다. 이번에는 그 유혹을 phase 구조로 차단하려 했다.

plan: 요구사항보다 먼저 경계를 설계하기

이번 프로젝트에서 가장 먼저 한 일은 구현이 아니라 경계 설정이었다. 이는 곧 무엇을 만들지와 무엇을 만들지 않을지를 동시에 정의하는 일이었다.

처음부터 내가 생각한 방향은 분명했다. 스핔이는 거대한 생산성 앱이 아니라, 바탕화면 위에서 가볍게 집중 흐름을 함께하는 캐릭터여야 했다. 그래서 “이랬으면 좋겠다”고 생각한 경험을 먼저 정리하고, 그 경험을 성립시키기 위해 필요한 요구사항만 남기려 했다. 반대로 지금 당장 없어도 되는 기능은 초반부터 과감히 범위 밖으로 밀어냈다. 그런 가이드가 있어야 AI도 흔들리지 않고, 구현 결과도 제품의 중심을 벗어나지 않기 때문이다.

그 결과 요구사항은 대략 아래처럼 정리됐다.

• transparent, always-on-top desktop overlay
• compact top control dock
• browser-style scrollbar 비노출
• idle / clicked / timer_finished 상태 분리
• bounded horizontal walking
• click audio non-overlap
• local-only 동작

동시에 out of scope도 아주 명시적으로 적어두었다.

• LLM integration 제외
• backend / online API 제외
• login / auth 제외
• cloud sync 제외
• mobile 제외
• 과한 physics / 복잡한 gamification 제외

이런 문서화가 왜 중요했는지는 AI와 같이 일할 때 더 분명하게 드러난다. AI는 사용자가 말하지 않은 확장을 선의로 제안하고 구현하는 경향이 있다. 그런데 토이 프로젝트는 바로 그런 “좋은 의도” 때문에 더 쉽게 흐려진다.

이번 프로젝트에서 내가 특히 중요하게 본 것은, 기능 목록보다 관심사 분리 규칙이었다. 실제로 docs/architecture-rules.md에는 아래 같은 원칙을 잡아두었다.

• Tauri 창/쉘 동작
• UI 렌더링
• 타이머 도메인 로직
• 캐릭터 시각 상태 전환
• 오디오 재생
• 에셋 경로 관리

그리고 더 중요한 규칙도 있었다.

• UI가 타이머 비즈니스 로직을 직접 소유하지 않도록 할 것
• 타이머 상태가 시각 상태를 유도해야 하며 반대로는 안 될 것
• 오디오는 명확한 인터페이스를 통해 완료 이벤트에 반응할 것
• 에셋 식별자와 경로는 중앙집중적으로 관리할 것

이런 규칙은 작은 프로젝트에는 과한 것처럼 보일 수 있다. 하지만 AI와 함께 작업할 때는 오히려 이런 제약이 있어야 결과가 덜 흔들린다. 하네스 엔지니어링은 결국 자유도를 높이는 일이 아니라, 올바른 제약을 먼저 설계하는 일에 가깝다.

execute: 긴 세션 하나보다 작고 검토 가능한 단위

실제 구현은 대부분 Codex가 맡았다. 하지만 그렇다고 하나의 긴 세션에 모든 걸 밀어 넣지는 않았다. 오히려 그 반대로, worktree와 phase 기준을 두고 작고 검토 가능한 실행 단위로 쪼개는 방식이 훨씬 안정적이었다.

이 방식의 장점은 생각보다 분명했다.

• phase 간 문맥이 섞이지 않는다.
• 회귀가 생겨도 영향 범위를 좁히기 쉽다.
• ship 직전 리뷰 기준이 선명하다.
• 커밋과 PR이 의사결정 로그 역할을 한다.

실제 커밋 로그를 보면 이런 흐름이 드러난다.

• overlay 표시 문제 수정
• 시작 표시와 드래그 경로 회귀 해결
• 종료 레이아웃 전환 안정화
• unsigned 배포와 아이콘 정리
• Windows unsigned installer workflow 추가

이런 흔적이 의미하는 바는 분명하다. 이번 프로젝트는 “AI가 코드 써줌”에서 끝난 것이 아니라, 작은 설계 결정을 계속 ship 가능한 단위로 축적한 과정이었다.

그리고 이건 채용 관점에서도 꽤 중요하다고 생각한다. 단순히 무언가를 만들었다는 사실보다, 그 결과물이 어떤 단위로 쪼개졌고 어떤 기준으로 검토됐는지가 더 많은 걸 보여주기 때문이다. 특히 AI를 쓰는 시대에는 “직접 구현했다”보다 “복잡한 변경을 어떻게 통제했는가”가 더 강한 신호가 될 수 있다.

verify: 하네스 엔지니어링의 중심은 결국 검증 전략

개인적으로 이번 프로젝트에서 가장 중요하다고 느낀 단계는 verify였다.

많은 AI 코딩 데모는 결과 화면이 보이면 성공처럼 말한다. 하지만 실제 개발은 거기서부터 시작된다. 특히 데스크톱 앱은 브라우저 화면 한 장으로 판단하기 어렵다. 창 상태, 오디오 상태, 타이머 상태, interaction state, packaging 상태까지 함께 봐야 한다.

그래서 이번 프로젝트는 요구사항 추적을 꽤 엄격하게 잡았다.

• 데스크톱 오버레이 셸, 상단 컨트롤 도크, 스크롤바 비노출: Phase 1
• 기본 상태 노출, 캐릭터 이동, 클릭 반응, 클릭 사운드: Phase 1~2
• 타이머 시작/일시정지/리셋, 남은 시간 표시, 종료 상태 전환, 완료 사운드: Phase 3
• macOS / Windows 공통 동작 검증과 패키징 안정화: Phase 4

이렇게 매핑을 해두면 “뭔가 꽤 됐다”가 아니라, “어떤 요구사항이 완료됐고 무엇이 아직 남았는지”를 말할 수 있다.

지금 상태만 봐도 그렇다. overlay shell, 기본 상태 노출, bounded walking, click reaction 같은 기반 경험은 꽤 정리됐다. 반면 Pomodoro feedback loop 전체와 cross-platform hardening은 아직 후속 phase의 몫이다. 즉, 이 프로젝트를 과장해서 말하면 앱을 완성했다고 할 수도 있겠지만, 정확하게 말하면 핵심 경험의 절반 이상을 검증 가능한 상태로 만든 단계라고 표현하는 편이 맞다.

나는 이런 표현 정확도가 시니어 엔지니어링의 중요한 일부라고 생각한다. 잘 된 것과 아직 안 된 것을 구분할 줄 아는 감각, 그리고 그것을 낙관이나 과장 없이 설명할 수 있는 태도 말이다.

ship: PR을 만드는 행위보다 배포 가능한 단위를 만드는 일

이번 프로젝트에서 ship은 마지막에 PR 하나 만드는 버튼이 아니었다. 오히려 “지금 이 변경을 밖으로 내보낼 수 있는 상태인가”를 점검하는 관문에 더 가까웠다.

이 단계에서 중요했던 것은 세 가지였다.

• phase 결과를 리뷰 가능한 범위로 묶을 수 있는가
• 기능 추가와 회귀 수정이 섞여 있지 않은가
• 배포와 설치 관점의 후속 작업이 보이는가

그래서 실제로는 구현과 동시에 packaging 관점의 작업도 함께 진행됐다.

• app icon 정리
• unsigned 배포 정리
• GitHub Releases 기준의 설치 흐름 설계
• GitHub Actions 기반 Windows unsigned installer workflow 추가
• tauri.conf.json 기준의 bundle / icon / windows installer 설정 정리

예전 같으면 데스크톱 앱을 만들기 위해 Electron 공식 문서를 보고, 빌드와 패키징을 공부하고, 플랫폼별 배포 이슈를 익히는 데 꽤 긴 러닝커브가 필요했다. 이번에는 Tauri를 거의 처음 쓰는 수준이었는데도, 적어도 MVP 범위에서는 그 학습 자체가 병목이 되지 않았다.

하지만 이걸 “이제 프레임워크를 몰라도 된다”로 해석하면 곤란하다. 더 정확한 해석은 이렇다.

러닝커브의 일부가 구현 문법에서 설계 판단으로 이동했다.

문서를 처음부터 끝까지 다 외우지 않아도, 어떤 문제를 어떤 순서로 풀고, 무엇을 phase 밖으로 밀어내고, 무엇을 ship 단위로 묶을지 아는 사람은 훨씬 빠르게 앞으로 갈 수 있다.

Tauri를 처음 써도 진입장벽이 낮았던 이유

예전에 회사에서 데스크톱 애플리케이션을 준비할 때, Electron을 익히는 데 며칠 정도를 꽤 집중해서 썼던 기억이 있다. 공식 문서를 따라가며 메인/렌더러 모델을 이해하고, 패키징 방식과 플랫폼별 이슈를 익히는 과정 자체가 하나의 러닝커브였다.

이번에는 달랐다. Tauri를 거의 모르는 상태로 시작했는데도, 최소한 이 프로젝트 범위에서는 프레임워크 학습 자체가 병목으로 느껴지지 않았다.

이유는 단순히 AI가 코드를 써줬기 때문만은 아니다.

• 문서 탐색 비용이 크게 줄었다.
• 첫 번째 초안과 시행착오를 AI가 빠르게 제시했다.
• 플랫폼/API 표면을 짧은 피드백 루프로 확인할 수 있었다.
• 아키텍처 규칙을 먼저 잡아둔 덕분에 수정 방향이 비교적 선명했다.

예를 들어 현재 구조를 보면 src/app, features, shared, src-tauri가 각자의 책임을 가진 채 비교적 단순하게 유지되고 있다. Rust는 최소화하고, 상호작용 로직은 프론트엔드에서 소유하며, 창 제어가 필요한 부분만 native shell로 넘기는 식이다. 이런 경계 감각이 먼저 있었기 때문에, 기술 자체를 잘 모르는 상태에서도 구현을 계속 밀어갈 수 있었다.

즉, 기술의 진입장벽이 사라진 것이 아니라 진입장벽이 더 고차원적인 판단 문제로 바뀐 것에 가깝다. 이제는 API를 몰라서 막히는 일보다, 무엇을 먼저 만들고 무엇을 미룰지, 어디까지를 MVP로 인정할지, 어떤 회귀는 절대 허용하지 않을지를 결정하는 일이 더 중요해졌다.

바이브코딩 시대에도 왜 여전히 개발자는 중요한가

이런 경험을 하면 “이제 개발자는 필요 없는 것 아닌가”라는 질문보다, 오히려 “개발자에게 남는 핵심 역량이 더 선명해진 것 아닌가”라는 생각이 먼저 든다.

이번 프로젝트에서 AI가 잘한 것은 이런 부분이었다.

• 반복적인 코드 작성
• 익숙한 구조의 빠른 초안 제시
• 작은 수정의 즉시 반영
• 특정 기능 조합의 구현 가속

반대로 사람이 계속 쥐고 있어야 했던 것은 아래였다.

• 제품 범위 정의
• 핵심 경험의 해상도 설정
• phase 분리와 우선순위 설정
• 완료 조건과 회귀 기준 정의
• 플랫폼 리스크 판단
• ship 가능한 단위에 대한 책임 있는 결정

결국 개발자의 중요성은 타이핑 속도에서만 오지 않는다. 오히려 이제는 불확실한 문제를 구조화하고, 적절한 제약을 걸고, 실행 결과를 검증 가능한 단위로 바꾸는 능력이 더 중요해졌다.

이 점에서 하네스 엔지니어링은 꽤 실무적인 개념이다. AI는 강력한 실행기지만, 방향과 경계가 없으면 쉽게 산만해진다. 그리고 그 방향과 경계를 설계하는 일은 여전히 엔지니어의 몫이다.

채용 관점에서 더 중요해질 신호는 무엇인가

개인적으로 앞으로는 “이 사람이 코드를 얼마나 많이 직접 썼는가”보다, 아래 같은 질문이 더 중요해질 가능성이 크다고 본다.

• AI와 함께 일할 때도 제품 범위를 명확히 정의할 수 있는가
• 복잡한 요구사항을 phase와 verification unit으로 분해할 수 있는가
• 기술적 선택과 비선택을 설명할 수 있는가
• 구현 결과를 과장 없이 검증 가능한 언어로 표현할 수 있는가
• ship 가능한 단위로 팀의 속도를 유지할 수 있는가

이런 관점에서 보면, 하네스 엔지니어링을 잘하는 개발자는 단순히 AI 툴을 잘 쓰는 사람이 아니다. 오히려 문제의 shape을 바르게 잡고, 실행기를 안전하게 다루고, 결과를 조직이 소비 가능한 형태로 만드는 사람에 더 가깝다.

이번 프로젝트를 굳이 블로그에 남기는 이유도 여기에 있다. 토이 프로젝트 자체보다, 그 프로젝트를 어떤 구조와 태도로 진행했는지가 지금 시점에는 더 강한 포트폴리오가 될 수 있다고 봤기 때문이다.

이번 프로젝트에서 남은 실무적 교훈

토이 프로젝트였지만 생각보다 실무적인 교훈이 많이 남았다.

첫째, 작은 프로젝트일수록 phase를 강제하는 편이 낫다. 토이 프로젝트는 가볍게 시작해서 가볍게 흐려지기 쉽다. 기능을 이것저것 붙이다 보면 결국 완성도도 메시지도 애매해진다. 이번에는 phase를 먼저 고정해 두니 오히려 끝까지 밀고 가기 쉬웠다.

둘째, AI 코딩의 병목은 구현보다 컨텍스트 관리다. 긴 문맥 하나에 모든 걸 태우는 방식보다, 문서화된 상태를 중심으로 세션을 분리하는 방식이 훨씬 안정적이었다.

셋째, verify 없는 execute는 데모일 뿐이다. 결과 화면은 빠르게 나오지만, 요구사항 추적과 회귀 기준이 없으면 제품이 아니라 우연한 스냅샷이 된다.

넷째, ship 가능한 단위가 속도를 만든다. 모든 걸 다 완성한 뒤 한 번에 정리하려고 하면 AI도 사람도 금방 지친다. 반대로 작은 단위로 ship하면 의사결정과 배포 흔적이 함께 남는다.

다섯째, 새로운 기술 스택의 진입장벽은 낮아졌지만 설계 감각의 중요성은 더 커졌다. Tauri와 TypeScript만으로도 충분히 빠르게 앞으로 갈 수 있었던 이유는 기술을 몰라도 돼서가 아니라, 문제를 구조적으로 다뤘기 때문이다.

마무리: AI 시대에 개발자는 구현자보다 설계자에 가까워진다

이번 스핔이 뽀모도로 펫 프로젝트를 하며 가장 크게 느낀 것은 이것이다.

AI 덕분에 구현 속도는 빨라졌지만, 좋은 결과를 만들기 위해 필요한 엔지니어링의 총량은 줄지 않았다.

대신 그 엔지니어링의 위치가 달라졌다.

예전에는 구현 세부사항을 직접 다루는 시간이 훨씬 길었다면, 이번에는 요구사항 정의, 경계 설계, phase 분리, 검증 루프, ship 단위 관리가 훨씬 중요했다. 그리고 이상하게도, 그게 더 본질적인 개발처럼 느껴졌다. 단순히 빨리 만드는 것이 아니라, 흔들리지 않게 만들기 위한 구조를 세우는 일이기 때문이다.

하네스 엔지니어링이 유행하는 이유도 비슷하다고 생각한다. 이제 중요한 것은 AI에게 한 번 잘 말하는 법이 아니라, AI가 여러 번의 작업에서도 맥락을 잃지 않도록 시스템을 설계하는 법이다.

이번 프로젝트는 완전 자율 에이전트의 승리라기보다, 사람과 에이전트의 역할을 다시 분해해 본 실험에 가까웠다. 100% 자동화의 환상보다는, plan → execute → verify → ship 구조 안에서 사람의 판단과 AI의 실행력을 어떻게 결합할지 보는 쪽이 훨씬 현실적이었고, 결과도 더 좋았다.

적어도 지금의 내 결론은 이렇다.

• AI 코딩은 이미 충분히 강력하다.
• 하지만 강한 실행기일수록 더 좋은 하네스가 필요하다.
• 그리고 그 하네스를 설계하는 일은 여전히 개발자의 영역이다.

앞으로 직접 코드를 많이 쓰는 날은 줄어들 수 있다. 하지만 무엇을 만들고, 무엇을 만들지 않고, 어떤 기준으로 검증하고, 어떤 단위로 내보낼지 고민하는 일은 오히려 더 많아질 것이다.

나는 그 변화가 개발자의 역할을 약하게 만든다고 생각하지 않는다. 오히려 더 선명하게 만든다고 본다.