AI가 코드를 쓰는 시대, 개발자는 무엇을 설계해야 할까

구현보다 설계에 더 많은 시간을 쓰게 된 AI 코딩 개발 방식

몇 년 전까지만 해도 소프트웨어 개발에서 가장 많은 시간이 들어가는 일은 코드를 작성하는 것이었다.

요구사항을 확인하고, 적절한 라이브러리를 찾고, 함수를 만들고, 오류를 수정하고, 테스트를 작성했다. 설계가 중요하다는 사실은 모두 알고 있었지만, 실제 업무 시간의 상당 부분은 결국 구현에 사용됐다.

AI 코딩 에이전트를 본격적으로 사용하기 시작하면서 이 흐름이 달라졌다.

지금은 내가 직접 코드를 작성하는 일이 거의 없다. 그렇다고 개발에 사용하는 시간이 줄어든 것은 아니다. 오히려 AI와 설계를 논의하고, 작업을 독립적인 단위로 나누고, 여러 에이전트가 동시에 작업할 수 있도록 환경을 만드는 데 더 많은 시간을 쓰고 있다.

개발의 중심이 구현에서 설계로 이동하고 있는 것이다.

---

AI 코딩의 시작은 프롬프트가 아니라 설계다

최근 내가 사용하는 개발 흐름은 대략 다음과 같다.

먼저 AI와 충분한 설계 세션을 진행한다.
그다음 설계를 바탕으로 작업을 여러 개의 독립적인 태스크로 나눈다.
각 태스크는 Git worktree로 분리한 뒤 여러 AI 세션에서 병렬로 구현한다.
구현이 끝나면 AI가 테스트와 실제 동작을 검증한다.
마지막으로 구현을 담당하지 않은 별도의 AI 세션에서 코드 리뷰를 진행한다.

이 과정에서 가장 중요한 단계는 첫 번째인 설계다.

여러 AI 에이전트를 동시에 움직이려면 각 에이전트가 무엇을 해야 하는지 명확하게 이해해야 한다. 설계가 모호한 상태에서 병렬 작업을 시작하면, 각각의 에이전트가 서로 다른 방향으로 코드를 작성할 가능성이 커진다.

문제는 작업이 끝난 뒤에야 드러난다.

API는 한 가지 데이터 구조를 기대하고 있는데 프런트엔드는 다른 구조를 사용하고 있거나, 비슷한 기능이 서로 다른 방식으로 중복 구현될 수도 있다. 책임의 경계가 잘못 나뉘면 여러 에이전트가 같은 파일을 동시에 수정하는 상황도 발생한다.

AI가 더 자율적으로 일할수록 사람은 구현 과정을 일일이 감시하기 어렵다. 그래서 구현을 시작하기 전에 사람과 AI가 같은 그림을 보고 있는지 확인하는 일이 중요해진다.

AI 코딩에서 설계는 단순한 준비 단계가 아니다.

설계가 곧 실행 계획이고, 여러 에이전트를 움직이는 공통 언어다.

---

작업 방법보다 목표를 먼저 공유한다

AI에게 일을 맡길 때 파일별 수정 방법이나 함수 내부의 구현 방식까지 지나치게 자세히 지시하지 않는다.

예를 들어 다음과 같은 방식이다.

“이 파일을 열고, 세 번째 함수에 조건문을 추가한 다음, 새로운 타입을 만든 뒤, 이 함수에서 호출하세요.”

이렇게 세세한 작업 절차를 제공하면 AI는 지시된 순서를 정확하게 수행하는 데 집중한다. 문제는 사람이 생각하지 못했던 더 나은 방법을 AI가 발견할 가능성도 함께 줄어든다는 점이다.

그렇다고 “적당히 잘 만들어줘”라고 요청하는 것도 아니다.

AI에게 맡기기 전에 다음 내용을 충분히 논의한다.

• 왜 이 변경이 필요한가
• 어떤 상태가 되면 작업이 완료된 것인가
• 반드시 지켜야 하는 도메인 규칙은 무엇인가
• 각 컴포넌트의 책임을 어떻게 나눌 것인가
• 어떤 동작을 확인해야 올바르게 구현됐다고 판단할 수 있는가

여기서 중요한 것은 설계를 구체화하는 것과 작업 순서를 세세하게 지시하는 것을 구분하는 일이다.

목표, 제약 조건, 책임의 경계, 인터페이스, 검증해야 할 동작은 구현 전에 충분히 정리해야 한다. 반면 어떤 파일부터 수정할지, 함수 안에서 어떤 문법을 사용할지는 AI가 판단하도록 맡길 수 있다.

예전에는 TypeScript에서 interface와 type 중 무엇을 사용할지, let을 피하기 위해 삼항 연산자를 사용할지 같은 세부 구현에 신경을 많이 썼다.

지금은 그보다 더 큰 질문에 집중한다.

이 타입은 어느 레이어가 소유해야 하는가.
이 변경의 영향 범위를 어디까지 제한할 수 있는가.
이 컴포넌트가 정말 이 책임을 가져야 하는가.

AI가 코드를 작성하는 속도는 매우 빠르다. 그래서 사람은 코드 한 줄의 모양보다 시스템 전체의 일관성을 살피는 데 집중해야 한다.

---

구현 전에 AI에게 질문을 받는다

AI와의 설계 세션에서는 내가 질문을 던지는 것만큼 AI에게 질문을 받는 과정도 중요하다.

나는 구현을 시작하기 전에 AI가 설계에 관한 질문을 하나씩 던지도록 한다. 질문을 통해 설계 의사결정 트리의 분기를 차례대로 해결하는 방식이다.

예를 들어 인증 기능을 추가한다면 다음과 같은 질문이 나올 수 있다.

• 세션 방식인가, 토큰 방식인가
• 토큰 만료 시 자동 갱신이 필요한가
• 여러 기기에서 동시에 로그인할 수 있는가
• 관리자와 일반 사용자의 권한은 어디에서 구분하는가
• 인증 실패 기록을 저장해야 하는가

사람이 처음부터 모든 예외 상황을 떠올리기는 어렵다. AI가 질문을 던지면 미처 생각하지 못한 설계 분기를 발견할 수 있다.

다만 AI의 제안을 무조건 받아들이면 안 된다.

AI가 추천안을 제시할 때마다 “좋아, 그렇게 하자”라고 답한다면 설계를 AI에 전적으로 맡기는 것과 다르지 않다. 기존 아키텍처를 선택한 이유, 반드시 지켜야 하는 비즈니스 규칙, 제안에서 느껴지는 불편함을 사람이 직접 설명해야 한다.

설계 세션에서 필요한 능력은 새로운 것이 아니다.

책임을 어디에서 나눌 것인지, 의존 관계를 어느 방향으로 둘 것인지, 미래의 변경을 어느 정도까지 고려할 것인지 판단하는 능력이다. 전통적인 소프트웨어 엔지니어링에서 중요하다고 배워온 능력이 AI 시대에도 그대로 사용된다.

AI가 아무것도 없는 상태에서 완벽한 설계를 만들어주는 것은 아니다.

AI는 선택지를 넓혀주고 질문을 던져준다. 최종 판단은 여전히 사람이 해야 한다.

---

설계 결정은 남기고, 작업 절차는 버린다

설계 세션에는 중요한 판단이 많이 포함된다.

왜 이 구조를 선택했는지, 어떤 대안을 검토했는지, 어떤 제약 때문에 특정 방식을 포기했는지 같은 정보다. 이 내용은 이후 여러 구현 세션에서 공통으로 참고할 수 있는 가치 높은 컨텍스트다.

그래서 설계 결과를 채팅 기록에만 남겨두지 않는다.

현재는 GitHub Issue의 댓글에 설계 내용을 정리하는 방식을 자주 사용한다. Issue는 작업 진행 상황과 연결돼 있고 수정 기록이 남기 때문에 의사결정 과정을 추적하기 좋다.

AI가 쉽게 읽도록 저장소 안에 Markdown 파일로 작성하는 방법도 유용하다.

다만 모든 내용을 영구 문서로 남길 필요는 없다. 이번 구현에서만 필요한 세부 작업 순서까지 문서화하면, 시간이 지나면서 업데이트되지 않는 오래된 문서가 쌓인다.

나는 설계 문서를 두 가지로 나누어 생각한다.

첫 번째는 오래 남아야 하는 설계 결정이다.

아키텍처의 방향, 데이터 모델의 원칙, 패키지 간 의존 관계와 같이 장기적으로 유효한 내용은 ADR이나 별도의 설계 문서로 남긴다.

두 번째는 이번 작업에서만 필요한 실행 절차다.

태스크 분할, 작업 순서, 임시 체크리스트 등은 Issue 댓글이나 작업용 문서에 작성하고 구현이 끝나면 폐기한다.

한 문장으로 정리하면 이렇다.

의사결정은 남기고, 작업 절차는 사용한 뒤 버린다.

---

하나의 설계를 여러 AI가 동시에 구현한다

설계가 끝나면 작업을 독립적으로 실행할 수 있는 단위로 분리한다.

예를 들어 하나의 기능을 다음과 같이 나눌 수 있다.

• 데이터베이스 스키마와 마이그레이션
• 백엔드 API
• 프런트엔드 화면
• 권한 검증
• 테스트와 문서화

각 작업은 Git worktree를 이용해 별도의 작업 디렉터리로 분리한다. 그리고 각 worktree를 서로 다른 AI 세션에 연결한다.

이 방식의 장점은 여러 에이전트가 동시에 작업하더라도 파일 충돌을 줄일 수 있다는 것이다. 설계 세션과 구현 세션을 분리할 수 있고, 각 태스크의 진행 상황도 개별적으로 확인할 수 있다.

하지만 병렬 작업이 가능한 경계를 찾는 것 자체가 하나의 설계 문제다.

책임이 제대로 나뉘어 있지 않은 코드베이스에서는 여러 작업을 안전하게 분리하기 어렵다. 하나의 기능을 수정하기 위해 수십 개 파일이 동시에 바뀌거나, 서로 다른 모듈이 같은 상태를 직접 수정한다면 에이전트 간 충돌이 자주 발생한다.

반대로 책임과 의존 관계가 명확한 코드베이스에서는 작업을 여러 에이전트에게 쉽게 나눌 수 있다.

즉, AI 병렬 개발의 효율은 사용하는 모델의 성능만으로 결정되지 않는다.

코드베이스의 구조가 얼마나 명확한지가 더 중요할 수 있다.

---

AI가 헤매지 않도록 개발 환경을 준비한다

worktree를 만들었다고 해서 바로 병렬 개발이 가능해지는 것은 아니다.

새로운 worktree에 node_modules가 없거나 환경변수가 설정되지 않았다면 AI는 애플리케이션을 실행하지 못한다. 의존성 설치에 실패하면 AI는 원인을 찾기 위해 여러 번 명령을 실행하고, 예상하지 못한 방향으로 문제를 해결하려 할 수 있다.

그래서 worktree가 생성되는 순간 기본적인 개발 환경이 자동으로 준비되도록 구성하는 것이 좋다.

예를 들어 다음 작업을 자동화할 수 있다.

• 의존성 디렉터리 연결
• 환경변수 파일 생성
• 로컬 데이터베이스 준비
• 필요한 포트 할당
• 테스트 데이터 초기화
• 개발 서버 실행 방법 안내

AI를 잘 활용하려면 좋은 프롬프트만 작성해서는 부족하다.

AI가 실패하지 않고 작업할 수 있는 환경을 함께 설계해야 한다.

---

AI가 자신의 코드를 직접 검증하게 한다

AI에게 구현을 맡기려면 AI가 자신의 변경 결과를 확인할 수 있어야 한다.

코드를 수정하고도 결과가 올바른지 판단할 방법이 없다면 AI는 사실상 눈을 감고 개발하는 것과 같다.

그래서 테스트, 타입 검사, Lint 같은 정적 검증뿐 아니라 실제 동작 확인까지 AI가 수행하도록 한다.

프런트엔드 변경이라면 브라우저를 직접 조작한다.

페이지가 정상적으로 열리는지 확인하고, 버튼을 누르고, 폼에 값을 입력하고, 오류 메시지가 올바르게 표시되는지 확인한다.

API 변경이라면 curl이나 API 테스트 도구를 사용한다.

요청을 보내고, 응답 코드와 데이터 구조를 확인하고, 잘못된 입력에 대한 오류 처리도 검증한다.

중요한 것은 무엇을 검증할지 설계 단계에서 정해두는 것이다.

“로그인 기능을 구현한다”는 설명만으로는 부족하다.

• 올바른 계정으로 로그인할 수 있는가
• 비밀번호가 틀리면 적절한 오류가 표시되는가
• 로그인 후 새로고침해도 세션이 유지되는가
• 권한이 없는 사용자가 관리자 페이지에 접근하지 못하는가

이처럼 기대하는 행동을 명확하게 정의해야 AI도 완료 여부를 스스로 판단할 수 있다.

---

피드백을 빠르게 받을 수 있는 환경이 중요하다

AI가 코드를 수정한 뒤 결과를 확인하기까지 걸리는 시간이 짧을수록 개발 속도는 빨라진다.

개발 서버를 실행하는 데 몇 분이 걸리고 테스트가 끝나는 데 오랜 시간이 필요하다면, AI의 피드백 루프도 느려진다. 에이전트는 기다리거나 불완전한 정보로 다음 판단을 내려야 한다.

그래서 로컬 개발 환경과 CI 속도를 개선하는 일의 중요성이 커지고 있다.

TypeScript 프로젝트에서는 Vite, Vitest, Oxlint, Oxfmt, 새로운 TypeScript 도구 체인처럼 빠른 실행 속도를 목표로 하는 도구들이 사용되고 있다.

어떤 도구를 선택하느냐보다 중요한 것은 기준이다.

AI가 변경한 결과를 얼마나 빠르게 확인할 수 있는가.

AI 개발 환경에서는 모델과 프롬프트뿐 아니라 테스트 실행 시간, 서버 시작 시간, 브라우저 자동화 속도도 핵심 성능 지표가 된다.

---

구현한 AI와 리뷰하는 AI를 분리한다

구현이 끝나고 Pull Request를 만들면 별도의 AI 세션에서 코드 리뷰를 진행한다.

구현을 담당한 AI에게 자신의 코드를 다시 검토하게 할 수도 있다. 하지만 같은 세션은 자신이 내린 결정을 정당화하는 방향으로 판단할 가능성이 있다.

그래서 구현 과정에 대한 컨텍스트가 없는 새로운 세션을 열어 리뷰를 요청한다.

리뷰 AI에는 다음 내용을 확인하도록 한다.

• 설계 요구사항을 충족하는가
• 논리적인 오류가 있는가
• 예외 처리가 빠져 있지 않은가
• 테스트가 부족하지 않은가
• 기존 기능에 영향을 줄 가능성이 있는가
• 권한이나 데이터 처리에 위험이 없는가
• 불필요하게 복잡한 구현은 없는가

물론 AI가 리뷰한다고 해서 사람이 코드를 전혀 확인하지 않아도 되는 것은 아니다.

인증, 결제, 개인정보, 데이터 마이그레이션처럼 오류의 영향이 큰 변경은 사람이 직접 집중해서 확인해야 한다.

다만 모든 코드를 같은 강도로 읽을 필요는 줄어들 수 있다.

AI는 반복적이고 국소적인 문제를 먼저 확인하고, 사람은 설계와 고위험 영역에 집중하는 방식으로 역할을 나눌 수 있다.

---

프로젝트의 암묵지를 문서와 스킬로 만든다

AI가 프로젝트를 처음 접할 때 가장 어려워하는 것은 문서에 적혀 있지 않은 규칙이다.

“우리 프로젝트에서는 이 모듈에서 데이터베이스에 직접 접근하면 안 된다.”

“API 응답은 반드시 이 형식을 사용한다.”

“이 테스트는 특정 명령으로 실행해야 한다.”

사람은 팀에서 일하면서 자연스럽게 익히지만 AI는 매번 코드와 문서를 탐색하며 규칙을 추론해야 한다.

이러한 반복을 줄이기 위해 프로젝트 규칙을 CLAUDE.md나 에이전트 스킬로 정리할 수 있다.

역할은 다음처럼 나눌 수 있다.

CLAUDE.md에는 저장소 구조, 기본 명령어, 공통 원칙, 프로젝트의 암묵지를 간결하게 기록한다.

프로젝트 스킬에는 브라우저 검증, API 테스트, 데이터베이스 마이그레이션처럼 여러 태스크에서 반복되는 작업 방법을 기록한다.

개인 스킬에는 설계 인터뷰, 코드 리뷰, 문서 작성처럼 여러 프로젝트에서 공통으로 사용하는 작업 방식을 기록한다.

같은 지시를 매번 프롬프트에 반복하고 있다면 문서나 스킬로 옮길 시점이다.

AI가 작업하는 로그를 살펴보면 어떤 부분에서 자주 망설였는지 확인할 수 있다. 반복적으로 잘못된 파일을 탐색하거나 같은 명령을 여러 번 실행한다면, 그 부분이 문서화가 필요한 지점이다.

---

좋은 프롬프트보다 좋은 아키텍처가 먼저다

문서와 스킬을 아무리 잘 정리해도 코드베이스의 구조가 복잡하면 한계가 있다.

“이 의존 방향을 지켜라”라고 문서에 반복해서 적는 것보다, 패키지 구조와 Lint 규칙을 통해 잘못된 의존 자체가 불가능하도록 만드는 편이 더 확실하다.

하나의 변경이 여러 영역으로 무분별하게 퍼지는 코드, 책임이 얽힌 코드, 인터페이스만 보고 동작을 이해하기 어려운 코드는 AI에게도 다루기 어렵다.

AI는 기존 코드에서 패턴을 찾고 그 패턴을 따라 변경하는 데 강하다.

따라서 코드베이스에 잘못된 패턴이 많으면 AI도 그 패턴을 재생산할 가능성이 있다.

AI가 다루기 좋은 아키텍처에 완전히 새로운 원칙이 필요한 것은 아니다.

• 책임의 경계가 명확하다
• 의존 방향이 일관돼 있다
• 변경의 영향 범위를 제한할 수 있다
• 인터페이스만으로 동작을 이해할 수 있다
• 테스트로 경계의 동작을 확인할 수 있다
• 이름과 디렉터리 구조를 통해 필요한 코드를 찾을 수 있다

이 원칙들은 오래전부터 유지보수하기 좋은 소프트웨어의 조건으로 이야기돼 왔다.

좋은 아키텍처는 사람만을 위한 것이 아니다. AI가 코드를 탐색하고, 작업을 분리하고, 스스로 검증하는 데도 도움이 된다.

---

코드를 쓰는 능력보다 전체를 보는 능력

AI에게 구현을 맡기기 시작하면 직접 코드를 작성하는 시간은 줄어든다.

나 역시 특정 문법이나 세부 구현 패턴을 즉시 떠올리는 능력이 예전보다 약해졌다고 느낀다. 코드 한 줄의 아름다움이나 작은 리팩터링에 집중하는 시간도 줄었다.

대신 시스템 전체를 바라보는 시간이 늘었다.

책임의 경계가 올바른지, 의존 관계가 복잡해지고 있지 않은지, 여러 변경을 통합했을 때 일관성이 유지되는지 고민한다.

능력이 단순히 좋아졌다거나 나빠졌다고 보기는 어렵다.

주의력을 사용하는 위치가 달라진 것이다.

다만 현재 사용하는 설계 능력 역시 과거에 직접 코드를 작성하고 실패했던 경험에서 나온다.

처음부터 모든 구현을 AI에게 맡긴 개발자가 같은 설계 능력을 어떻게 습득할 수 있을지는 아직 분명하지 않다. AI 시대의 주니어 개발자 교육과 학습 방법은 앞으로 별도로 고민해야 할 문제다.

---

구현 다음의 병목은 코드 리뷰다

AI가 여러 개의 PR을 동시에 만들 수 있게 되면 새로운 문제가 생긴다.

사람의 리뷰 속도가 AI의 구현 속도를 따라가지 못한다.

예전에는 코드를 작성하는 데 시간이 오래 걸렸고, 숙련된 개발자가 코드를 읽는 속도는 상대적으로 빨랐다. 그래서 리뷰 과정이 자연스럽게 개발 속도를 따라갈 수 있었다.

하지만 AI가 짧은 시간 안에 여러 변경을 만들어내면 리뷰 대기열이 길어진다.

이 문제를 해결하려면 모든 코드를 사람이 같은 수준으로 검토하는 방식을 바꿔야 한다.

리뷰를 계층화할 수 있다.

AI는 로직 오류, 테스트 누락, 코드 가독성, 기존 패턴 위반 같은 일차적인 문제를 확인한다.

사람은 다음과 같은 부분에 집중한다.

• 요구사항을 제대로 충족하는가
• 설계의 책임 경계와 일치하는가
• API와 데이터 모델 변경이 적절한가
• 권한과 보안에 문제가 없는가
• 장기적으로 유지 가능한 구조인가
• 서비스에 큰 영향을 줄 위험이 있는가

한 걸음 더 나아가면 구현 전에 설계 자체를 사람끼리 리뷰할 수도 있다.

사람이 합의한 설계를 기준으로 AI가 구현하고, 개별 구현은 자동 검증과 AI 리뷰를 중심으로 통과시키는 방식이다.

이 구조에서는 사람이 가장 중요한 판단에 집중할 수 있다.

---

PR은 작게 나눠야 한다

AI 에이전트는 짧은 시간 안에 큰 변경을 만들 수 있다.

아무 제한 없이 작업을 맡기면 하나의 PR에 수십 개 파일과 여러 기능이 함께 포함되기 쉽다. PR이 커질수록 리뷰어의 부담은 커지고, 중요한 문제를 놓칠 가능성도 높아진다.

그래서 AI에게 처음부터 PR을 작은 단위로 분리하도록 요청하는 것이 좋다.

예를 들어 다음처럼 나눌 수 있다.

1. 데이터 모델과 마이그레이션
2. 핵심 도메인 로직
3. API 엔드포인트
4. 프런트엔드 연동
5. 테스트와 문서

AI에게 어떤 기준으로 PR을 나누는 것이 좋은지 제안하게 할 수도 있다. 브랜치 분리나 커밋 이동처럼 번거로운 Git 작업도 AI가 처리할 수 있다.

다만 AI가 작성한 PR이라도 작성자인 사람은 변경 내용을 설명할 수 있어야 한다.

“AI가 만들어서 잘 모릅니다”라는 설명은 리뷰어에게 이해 비용과 책임을 떠넘기는 일이다.

설계 의도와 변경 이유를 설명할 수 없다면 아직 그 PR을 제출할 준비가 되지 않은 것이다.

---

승인 요청을 늘린다고 더 안전해지는 것은 아니다

AI가 파일을 수정하거나 명령을 실행할 때마다 사람의 승인을 요구하도록 설정하면 자율적인 작업이 어렵다.

승인 단계가 많을수록 안전해 보일 수 있지만 반드시 그렇지는 않다.

사람이 너무 많은 승인 요청을 받으면 승인 피로가 발생한다. 처음에는 내용을 자세히 확인하지만, 시간이 지나면 습관적으로 승인 버튼을 누르게 된다.

결국 정말 위험한 작업도 놓칠 수 있다.

더 나은 방법은 AI가 안전하게 실패할 수 있는 환경을 만드는 것이다.

• 중요한 시스템과 분리된 샌드박스
• 삭제해도 복구할 수 있는 worktree
• 제한된 권한의 개발용 계정
• 테스트용 데이터베이스
• 외부 서비스 호출 제한
• 비밀정보에 접근할 수 없는 환경

모든 행동을 사람에게 확인받는 대신, 문제가 생겨도 피해가 제한되는 구조를 만들어야 한다.

AI의 자율성을 높이는 일과 안전성을 높이는 일은 서로 반대되는 목표가 아니다.

환경을 제대로 설계하면 두 가지를 함께 추구할 수 있다.

---

가장 싼 모델이 가장 경제적인 것은 아니다

AI 개발 비용을 줄이기 위해 단순 작업은 저렴한 모델에 맡기고, 복잡한 작업은 고성능 모델에 맡기는 방식이 자주 제안된다.

하지만 모델의 토큰 가격만으로 비용을 비교해서는 안 된다.

저렴한 모델이 설계를 잘못 이해해 구현을 다시 해야 하거나, 리뷰와 수정이 반복된다면 전체 비용은 오히려 커질 수 있다.

중요한 기준은 하나의 변경을 완료하기까지 드는 총비용이다.

특히 설계 단계에서 잘못된 결정이 내려지면 이후 병렬로 실행되는 모든 태스크가 잘못된 방향으로 진행될 수 있다. 따라서 설계 세션에서는 가능한 한 충분한 추론 능력을 가진 모델을 사용하는 편이 합리적일 수 있다.

반면 기존 패턴을 그대로 따르는 단순 수정이나 반복 작업은 더 가벼운 모델로 처리할 수 있다.

앞으로는 모델 종류뿐 아니라 추론 강도를 조절하는 방식도 중요해질 가능성이 있다.

결국 필요한 것은 감에 의존한 모델 선택이 아니라 태스크의 복잡도, 실패 가능성, 재작업 비용을 함께 고려하는 기준이다.

---

AI가 계속 일하고 있어야 안심되는 감각

여러 AI 에이전트를 사용하다 보면 항상 무언가를 실행하고 있어야 한다는 압박을 느낄 수 있다.

사용량 제한이 있는 구독 서비스를 이용하면 남은 사용량을 쓰지 못하는 것이 손해처럼 느껴지기도 한다. AI가 멈춰 있는 시간이 곧 생산성 손실처럼 보일 수도 있다.

AI의 결과는 매번 조금씩 다르다. 어떤 결과가 나올지 기다리는 과정이 일종의 뽑기처럼 느껴질 때도 있다.

하지만 AI가 계속 실행되고 있다는 사실과 가치 있는 일이 진행되고 있다는 사실은 다르다.

병렬 작업을 늘리면 구현량은 증가하지만 리뷰와 통합 부담도 함께 늘어난다. 필요하지 않은 태스크를 만들고 AI의 가동률 자체를 목표로 삼는 순간, 개발은 오히려 복잡해질 수 있다.

앞으로의 설계에는 AI에게 무엇을 시킬 것인지뿐 아니라 무엇을 시키지 않을 것인지를 판단하는 일도 포함될 것이다.

---

AI 시대에도 결국 중요한 것은 설계다

AI 코딩이 발전할수록 개발자의 역할이 사라진다고 단정하기는 어렵다.

다만 개발자가 시간을 사용하는 방식은 분명히 달라지고 있다.

직접 코드를 작성하는 시간은 줄어들고, 다음과 같은 일에 더 많은 시간이 사용된다.

• 문제를 명확하게 정의하는 일
• 목표와 제약 조건을 정리하는 일
• 책임과 의존 관계를 설계하는 일
• 작업을 독립적인 단위로 나누는 일
• AI가 스스로 검증할 수 있는 환경을 만드는 일
• 여러 변경을 통합하고 위험을 판단하는 일
• AI가 만든 결과를 설명하고 책임지는 일

AI가 더 많은 코드를 작성할수록 사람은 더 큰 그림을 봐야 한다.

좋은 결과는 좋은 프롬프트 하나에서 나오지 않는다.

명확한 설계, 정돈된 아키텍처, 빠른 피드백, 자동화된 검증, 안전한 실행 환경이 함께 있어야 한다.

결국 AI 코딩 시대에도 변하지 않는 사실이 있다.

좋은 소프트웨어는 코드를 많이 작성해서 만들어지는 것이 아니라, 중요한 결정을 올바르게 내려서 만들어진다.

AI가 구현을 담당하게 된 지금, 개발자의 가장 중요한 코드는 어쩌면 실제 코드가 아닐지도 모른다.

문제를 정의하고, 경계를 나누고, 검증 기준을 세우는 설계 자체가 개발자가 작성해야 할 새로운 코드인지도 모른다.

最近の AI コーディングで実践している、設計を中心とした開発の進め方