AI 코딩 시대에도 기획이 중요한 이유: 가짜 속도보다 검증 가능한 의도
========================================

AI 코딩 도구는 아이디어를 작동하는 화면으로 옮기는 비용과 시간을 크게 낮췄지만, 명확한 가설과 검증 없는 속도는 쓸모없는 결과물을 빠르게 늘릴 뿐입니다. AI 시대의 기획은 긴 문서를 먼저 완성하는 일이 아니라, 작은 문제를 정의하고 프로토타입으로 빠르게 학습하며 의도의 방향성을 지키는 일입니다.

- AI 코딩은 MVP 제작 비용을 낮춰 사전 회의보다 빠른 실험과 피드백을 더 합리적인 선택으로 만들었습니다.
- 작동하는 프로토타입은 긴 PPT보다 팀의 이해를 빠르게 맞추고 커뮤니케이션 오류를 줄이는 기획 도구가 될 수 있습니다.
- 속도만 앞세운 AI 활용은 문제 정의가 흐릴수록 그럴듯하지만 쓸모없는 기능과 화면을 양산할 위험이 큽니다.
- AI 시대의 핵심 기획 역량은 완성본을 한 번에 요구하는 능력이 아니라 작은 가설을 세우고 결과를 검증하며 방향을 제어하는 능력입니다.
- 좋은 AI 프로토타이핑은 문제 정의, 최소 기능 범위, 검증 지표, 사용자 피드백, 폐기 또는 개선 결정을 하나의 짧은 루프로 묶습니다.

한 줄 결론
AI가 코드를 쓰고 화면을 만드는 시대에도 기획은 사라지지 않습니다. 오히려 기획의 역할은 더 선명해졌습니다. 예전의 기획이 “만들기 전에 최대한 많이 예측하는 일”에 가까웠다면, AI 코딩 시대의 기획은 “무엇을 검증할지 정하고, 작게 만들고, 빠르게 배우며, 의도의 방향을 끝까지 제어하는 일”입니다.
AI는 제작 비용을 낮춥니다. 그러나 사용자의 문제, 비즈니스 가설, 우선순위, 품질 기준, 윤리적 판단까지 대신 책임지지는 않습니다. 그래서 빠르게 만드는 능력보다 더 중요한 것은 “무엇을 왜 만들 것인가”를 끝까지 붙잡는 능력입니다.

왜 다시 기획을 말해야 하는가
생성형 AI와 AI 코딩 도구는 서비스 제작의 초기 장벽을 크게 낮췄습니다. 과거에는 아이디어를 실제 화면으로 확인하기 위해 기획 문서, 디자인 시안, 개발 스프린트, QA, 배포 준비가 필요했습니다. 지금은 간단한 웹 앱, 내부 도구, 데모 페이지, 기능 프로토타입을 몇 시간 또는 며칠 안에 만들어보는 일이 훨씬 쉬워졌습니다.
이 변화는 단순한 생산성 향상이 아닙니다. 의사결정 방식 자체를 바꿉니다.
예전에는 “이 아이디어가 성공할 가능성이 높은가?”를 문서와 회의로 설득해야 했습니다. 지금은 “작게 만들어 실제로 확인해보자”가 더 합리적인 선택이 되는 경우가 많습니다. 만들기 비용이 낮아졌기 때문에, 예측보다 실험이 싸지는 구간이 생긴 것입니다.
다만 여기에는 함정이 있습니다. 만들기가 쉬워졌다고 해서 좋은 제품을 만들기 쉬워진 것은 아닙니다. AI는 속도를 제공하지만 방향을 보장하지 않습니다. 방향이 없는 속도는 학습이 아니라 산출물의 증가일 뿐입니다.

AI 코딩이 바꾼 핵심: 만들기 비용의 하락
AI 코딩 도구가 바꾼 것은 “코드를 누가 치는가”만이 아닙니다. 더 중요한 변화는 시도 비용, 커뮤니케이션 비용, 실패 비용이 낮아졌다는 점입니다.

과거의 흐름과 현재의 흐름

구분
과거의 일반적인 흐름
AI 코딩 시대의 흐름

아이디어 표현 방식
기획서, 와이어프레임, PPT
대화형 요구사항, 즉시 생성된 화면, 작동하는 데모

초기 검증 단위
몇 주 단위 프로젝트
몇 시간 또는 며칠 단위 실험

회의의 중심
문서 해석과 의견 조율
실제 화면 조작과 피드백

실패 비용
여러 부서의 시간과 개발 리소스
작은 실험 단위의 시간 비용

기획자의 핵심 역할
사전 예측과 승인 확보
문제 정의, 가설 설계, 검증 기준 관리

이 변화가 중요한 이유는 간단합니다. 프로토타입은 설명보다 오해가 적습니다. 문서로만 논의하면 각자가 다른 화면과 사용 흐름을 상상하지만, 실제로 클릭 가능한 목업이나 MVP 앞에서는 논의가 구체화됩니다.

목업 하나가 PPT 백 장보다 강력한 이유
작동하는 프로토타입은 세 가지 점에서 강력한 기획 도구가 됩니다.

1. 상상을 같은 화면으로 맞춘다
PPT와 문서는 추상적입니다. “간단한 입력 화면”, “직관적인 분석 결과”, “빠른 온보딩” 같은 표현은 사람마다 다르게 해석됩니다. 반면 클릭 가능한 프로토타입은 팀원들이 같은 대상을 보고 말하게 만듭니다.
이때 회의의 질문도 달라집니다.

“이 기능이 필요할까요?”에서 “사용자가 이 버튼을 이해할까요?”로 바뀝니다.
“좋아 보입니다”에서 “두 번째 단계에서 이탈할 것 같습니다”로 바뀝니다.
“언젠가 만들 수 있습니다”에서 “이 가설은 오늘 테스트할 수 있습니다”로 바뀝니다.

2. 피드백을 빠르게 구체화한다
프로토타입이 있으면 추상적인 취향 논쟁이 줄어듭니다. 팀원, 고객, 이해관계자는 실제 흐름을 경험한 뒤 구체적으로 말할 수 있습니다.
예를 들어 “음성 입력 기능이 필요하다”는 문장만으로는 충분하지 않습니다. 하지만 마이크 버튼을 누르고, 음성이 텍스트로 바뀌고, 사용자가 수정하고, 저장되는 흐름을 직접 보여주면 다음 질문이 즉시 드러납니다.

사용자는 마이크 권한 요청을 자연스럽게 이해하는가?
오인식이 발생했을 때 수정이 쉬운가?
저장 전에 사용자가 확인할 수 있는가?
이 기능이 정말 기존 입력 방식보다 빠른가?

3. 실패를 학습으로 바꾼다
AI가 만든 프로토타입이 하루 만에 거절될 수도 있습니다. 하지만 이것은 나쁜 결과가 아닙니다. 오히려 “이 방향은 아니다”라는 사실을 낮은 비용으로 확인한 것입니다.
좋은 기획 조직은 실패를 피하는 조직이 아니라, 싼 실패를 많이 만들고 비싼 실패를 줄이는 조직입니다. AI 코딩은 이 구조를 가능하게 합니다.

하지만 속도만으로는 제품이 되지 않는다
AI 코딩의 가장 큰 위험은 “그럴듯함”입니다. 생성형 AI는 사용자의 지시가 모호해도 빈칸을 채워 결과물을 만듭니다. 그 결과 화면은 있어 보이지만, 실제 문제를 해결하지 못하는 경우가 생깁니다.

가짜 속도의 대표적 신호

신호
설명
왜 위험한가

기능이 빠르게 늘어난다
핵심 문제 검증 없이 화면과 메뉴가 계속 추가된다
복잡도만 증가하고 학습은 줄어든다

데모는 멋있지만 사용자가 없다
내부 회의에서는 좋아 보이지만 실제 사용자 테스트가 없다
시장 검증이 아니라 내부 만족으로 끝난다

프롬프트가 모호하다
“멋진 앱을 만들어줘”처럼 목적과 제약이 불분명하다
AI가 임의로 제품 방향을 채운다

검증 지표가 없다
성공과 실패를 판단할 기준이 없다
만들어도 배울 수 없다

코드 품질을 확인하지 않는다
보안, 예외 처리, 유지보수 구조를 보지 않는다
프로토타입이 그대로 기술 부채가 된다

가짜 속도는 빠르게 움직이는 것처럼 보이지만, 실제로는 잘못된 방향으로 더 많은 산출물을 쌓는 일입니다. AI 시대에 더 위험한 것은 느린 실행이 아니라 빠른 착각입니다.

AI 시대의 기획 정의
AI 시대의 기획은 “개발자에게 넘길 문서를 작성하는 일”로 좁게 볼 수 없습니다. 더 정확히는 다음 네 가지를 관리하는 일입니다.

문제의 정의: 어떤 사용자의 어떤 불편을 해결하는가.

가설의 설계: 무엇이 사실이면 이 아이디어가 의미 있는가.

실험의 범위: 가장 작게 무엇을 만들어 확인할 것인가.

판단의 기준: 어떤 결과가 나오면 개선, 보류, 폐기할 것인가.

AI는 이 중 일부 실행을 도와줄 수 있습니다. 하지만 문제를 선택하고, 가설의 의미를 해석하고, 사업적 우선순위를 정하고, 최종 판단을 내리는 일은 여전히 사람의 책임입니다.

실무 원칙 1: 한 번에 완성본을 요구하지 않는다
AI에게 처음부터 완벽한 제품을 만들라고 요구하면 결과가 흩어지기 쉽습니다. 특히 제품의 목적, 사용자, 데이터 구조, 화면 흐름, 예외 처리, 보안 요건이 정리되지 않은 상태라면 더 그렇습니다.
좋은 방식은 큰 제품을 작은 검증 단위로 쪼개는 것입니다.

나쁜 요청 예시
“중소기업용 회계 관리 SaaS를 만들어줘. 로그인, 대시보드, 세금 계산, 리포트, 결제, 관리자 페이지까지 다 넣어줘.”
이 요청은 너무 넓습니다. AI는 많은 기능을 만들 수는 있지만, 어떤 문제가 가장 중요한지 알 수 없습니다.

좋은 요청 예시
“프리랜서 사용자가 영수증 이미지를 업로드하면, 날짜·금액·가맹점명을 추출해 수정 가능한 표로 보여주는 단일 화면 프로토타입을 만들어줘. 이번 실험의 목적은 사용자가 수기 입력보다 빠르다고 느끼는지 확인하는 것이다.”
이 요청은 검증하려는 문제, 사용자, 핵심 기능, 화면 범위가 분명합니다.

실무 원칙 2: 검증할 문제를 작고 뾰족하게 정의한다
AI 프로토타이핑의 핵심은 “작게 만들기”가 아니라 “작게 배울 수 있게 만들기”입니다. 작은 기능이라도 무엇을 배우려는지 불분명하면 의미가 없습니다.

가설 문장 템플릿
다음 형식으로 가설을 먼저 쓰면 AI에게 지시하기가 쉬워집니다.

대상 사용자: 누가 이 문제를 겪는가?
현재 문제: 지금 어떤 불편이나 비용이 있는가?
제안 기능: 어떤 방식으로 해결하려 하는가?
기대 변화: 사용자의 행동이나 지표가 어떻게 바뀌어야 하는가?
검증 방법: 무엇을 보면 성공 또는 실패라고 판단할 수 있는가?

예시는 다음과 같습니다.

“초기 상담원이 고객 통화 내용을 수기로 요약하는 데 시간이 오래 걸린다. 음성 녹음 후 핵심 항목을 자동 요약해 수정 가능한 양식으로 보여주면, 상담 기록 작성 시간이 줄어들 것이다. 5명의 상담원이 실제 샘플로 테스트했을 때 평균 작성 시간이 30% 이상 줄고 수정 부담이 낮다고 응답하면 다음 단계로 진행한다.”

이 정도로 가설이 분명하면 AI에게 무엇을 만들게 할지도 명확해집니다.

실무 원칙 3: AI 결과물을 반드시 검증하고 제어한다
AI가 만든 화면과 코드는 초안입니다. 특히 프로토타입을 넘어 실제 서비스로 발전시키려면 다음 영역을 반드시 점검해야 합니다.

검증 체크리스트

점검 항목
질문

문제 적합성
이 기능이 처음 정의한 사용자 문제와 직접 연결되는가?

사용 흐름
사용자가 다음 행동을 자연스럽게 이해할 수 있는가?

데이터 처리
입력값, 오류, 빈 상태, 중복 데이터가 제대로 처리되는가?

보안과 개인정보
민감 정보가 불필요하게 저장되거나 노출되지 않는가?

접근성
키보드 조작, 대비, 대체 텍스트 등 기본 접근성을 고려했는가?

유지보수성
프로토타입 코드가 실제 제품 코드로 확장 가능한 구조인가?

의사결정 기준
이 실험을 계속할지 멈출지 판단할 기준이 있는가?

AI가 만든 결과를 검토하지 않고 그대로 배포하는 것은 위험합니다. 특히 인증, 결제, 의료, 금융, 개인정보, 법률 판단이 관련된 영역에서는 전문가 검토와 보안 점검이 필수입니다.

AI와 함께 일하는 기획 루프
AI 코딩 시대의 기획은 긴 선형 절차보다 짧은 반복 루프에 가깝습니다.

1단계: 문제를 한 문장으로 쓴다
“사용자 A가 상황 B에서 C 때문에 D를 하지 못한다”처럼 씁니다.
예: “신규 입사자가 사내 문서를 어디서 찾아야 할지 몰라 업무 시작 시간이 늦어진다.”

2단계: 가장 작은 해결 흐름을 정한다
처음부터 전체 시스템을 만들지 않습니다. 한 번의 사용 흐름만 고릅니다.
예: “질문을 입력하면 관련 문서 후보 3개를 보여주고, 사용자가 도움이 됐는지 평가한다.”

3단계: AI에게 제약 조건과 성공 기준을 함께 준다
AI에게는 목적뿐 아니라 만들지 말아야 할 것도 알려야 합니다.
예: “로그인과 관리자 페이지는 만들지 말고, 검색 입력창·결과 카드·피드백 버튼만 구현한다. 이번 목표는 사용자가 원하는 문서를 1분 안에 찾을 수 있는지 확인하는 것이다.”

4단계: 실제 사용자 또는 이해관계자에게 보여준다
내부 팀만 보는 데모는 충분하지 않습니다. 가능하면 실제 문제를 가진 사용자에게 보여줘야 합니다. 사용자가 말하는 의견뿐 아니라 실제 행동을 관찰해야 합니다.

5단계: 개선, 보류, 폐기를 결정한다
실험 후에는 반드시 결정을 내려야 합니다.

개선: 핵심 가설은 맞지만 사용성이나 정확도가 부족하다.
보류: 문제는 있으나 우선순위나 자원이 맞지 않는다.
폐기: 사용자가 문제를 중요하게 느끼지 않거나 해결 방식이 맞지 않는다.

폐기는 실패가 아니라 비용을 줄인 의사결정입니다.

AI 프로토타입을 위한 프롬프트 구조
아래 구조는 AI 코딩 도구에 요구사항을 전달할 때 사용할 수 있는 기본 형식입니다.
역할: 너는 초기 제품 프로토타입을 만드는 프론트엔드 개발자이자 UX 파트너다.

목표: [검증하려는 사용자 문제와 가설]
대상 사용자: [누가 사용할 것인지]
이번에 만들 범위: [단일 화면 또는 단일 흐름]
이번에 만들지 않을 것: [로그인, 결제, 관리자, 고급 설정 등 제외 범위]
필수 기능: [3개 이하]
성공 기준: [테스트 후 판단할 기준]
데이터: [샘플 데이터 또는 입력 형식]
제약 조건: [보안, 개인정보, 접근성, 기술 스택]
출력 형식: [코드, 파일 구조, 실행 방법, 테스트 방법]

이 프롬프트의 핵심은 “무엇을 만들지 않을지”를 명시하는 것입니다. AI는 빈 공간을 채우려는 경향이 있으므로, 제외 범위를 명확히 해야 결과가 과도하게 커지지 않습니다.

기획자의 역할은 줄어드는가, 바뀌는가
AI 코딩은 기획자의 역할을 줄이기보다 재배치합니다. 문서 생산의 비중은 줄어들 수 있지만, 판단의 비중은 커집니다.

줄어드는 일

반복적인 화면 설명 문서 작성
단순 와이어프레임 제작
초기 데모용 코드 작성 요청과 대기
회의용 정적 자료 제작

더 중요해지는 일

사용자 문제를 좁고 정확하게 정의하기
실험 가능한 가설로 바꾸기
AI가 만든 결과의 품질과 방향 검토하기
팀의 해석을 하나로 맞추기
출시 가능한 제품과 데모용 산출물을 구분하기
개인정보, 보안, 책임 범위 판단하기

즉, 기획자는 “문서 작성자”에서 “실험 설계자이자 의도 관리자”로 이동합니다.

AI가 만든 MVP를 평가하는 기준
AI로 만든 MVP는 빠르게 만들었다는 사실만으로 의미가 없습니다. 다음 기준으로 평가해야 합니다.

평가 기준
좋은 MVP
나쁜 MVP

가설
하나의 핵심 가설이 분명하다
여러 기능을 보여주지만 무엇을 검증하는지 모른다

범위
최소 흐름만 구현한다
처음부터 전체 제품처럼 보이려 한다

사용자 피드백
실제 사용자의 행동을 관찰한다
내부 의견만 수집한다

학습 결과
다음 결정이 명확해진다
“더 만들어보자”만 반복된다

기술 상태
데모와 제품화 범위를 구분한다
프로토타입 코드를 그대로 서비스화한다

좋은 MVP는 작고 초라해도 됩니다. 중요한 것은 멋진 데모가 아니라 의사결정에 필요한 학습을 제공하는 것입니다.

조직이 적용할 수 있는 운영 원칙
AI 프로토타이핑을 개인의 즉흥적 실험으로만 두면 산출물이 흩어집니다. 조직 차원에서는 최소한의 운영 원칙이 필요합니다.

실험 등록 양식을 만든다: 문제, 가설, 범위, 성공 기준, 담당자, 종료일을 기록합니다.

프로토타입과 제품 코드를 구분한다: 데모용 코드는 빠르게 버릴 수 있어야 합니다.

사용자 피드백 시간을 먼저 예약한다: 만들고 나서 사용자를 찾으면 검증이 늦어집니다.

보안 금지선을 정한다: 실제 개인정보, 고객 데이터, 결제 정보는 초기 실험에 넣지 않는 것이 원칙입니다.

폐기 기준을 명시한다: 무엇이 나오면 멈출지 정해야 실험이 계속 늘어지지 않습니다.

학습 기록을 남긴다: 실패한 프로토타입도 왜 실패했는지 남기면 다음 실험의 자산이 됩니다.

결론: AI 시대의 기획은 느려지는 일이 아니라 정확해지는 일
AI가 많은 것을 만들어주는 시대에 “왜 기획을 말하느냐”는 질문은 자연스럽습니다. 그러나 답은 분명합니다. 만들기가 쉬워질수록 무엇을 만들지 정하는 일이 더 중요해지기 때문입니다.
AI 코딩은 기획을 없애지 않습니다. 다만 기획의 중심을 바꿉니다. 긴 문서로 승인받는 기획에서, 작은 가설을 빠르게 검증하는 기획으로 이동합니다. 상상 속 제품을 설명하는 기획에서, 실제 화면을 통해 팀과 사용자의 반응을 확인하는 기획으로 이동합니다.
속도는 강력한 무기입니다. 하지만 방향 없는 속도는 낭비입니다. AI 시대에 지켜야 할 기획의 핵심은 의도의 방향성입니다. 어떤 문제를 풀 것인지, 무엇을 검증할 것인지, 어떤 기준으로 멈추거나 나아갈 것인지 사람이 끝까지 결정해야 합니다. 그때 AI는 단순한 자동화 도구를 넘어, 더 빠르게 배우고 더 정확하게 제품을 만드는 동료가 될 수 있습니다.

FAQ
Q. AI가 코드를 만들어주면 기획자는 필요 없어지나요?
A. 아니요. AI가 코드와 화면 제작을 빠르게 도와줄수록 기획자는 문제 정의, 가설 설계, 검증 기준, 우선순위 판단을 더 명확히 해야 합니다. AI는 실행 속도를 높일 수 있지만 어떤 사용자 문제를 풀어야 하는지와 무엇을 성공으로 볼지는 사람이 결정해야 합니다.
Q. AI 코딩 시대의 기획은 기존 기획과 무엇이 다른가요?
A. 기존 기획이 만들기 전에 문서와 회의로 최대한 예측하는 방식에 가까웠다면, AI 코딩 시대의 기획은 작게 만들고 실제 반응을 보며 빠르게 학습하는 방식에 가깝습니다. 핵심은 긴 문서를 먼저 완성하는 것이 아니라 검증 가능한 작은 가설을 정하는 것입니다.
Q. AI로 만든 MVP는 어느 정도까지 완성되어야 하나요?
A. AI로 만든 MVP는 완성도 높은 제품처럼 보일 필요가 없습니다. 사용자의 핵심 행동 하나를 검증할 수 있을 만큼만 작동하면 충분합니다. 중요한 것은 기능의 수가 아니라 실험 후에 개선, 보류, 폐기 중 하나의 결정을 내릴 수 있는지입니다.
Q. 가짜 속도란 무엇인가요?
A. 가짜 속도는 빠르게 만들고 있는 것처럼 보이지만 실제로는 사용자 문제를 검증하지 못하고 산출물만 늘어나는 상태를 뜻합니다. 명확한 가설, 사용자 피드백, 성공 기준 없이 AI로 기능을 계속 추가하면 가짜 속도에 빠지기 쉽습니다.
Q. AI에게 좋은 프로토타입을 만들게 하려면 어떻게 지시해야 하나요?
A. 대상 사용자, 해결하려는 문제, 이번에 만들 범위, 만들지 않을 범위, 필수 기능, 성공 기준, 샘플 데이터, 제약 조건을 함께 전달하는 것이 좋습니다. 특히 로그인, 결제, 관리자 기능처럼 이번 실험에 필요 없는 범위를 제외한다고 명시하면 결과가 과도하게 커지는 것을 막을 수 있습니다.
Q. AI 프로토타입을 바로 실제 서비스로 배포해도 되나요?
A. 주의해야 합니다. AI가 만든 프로토타입은 빠른 검증용 초안인 경우가 많기 때문에 보안, 개인정보, 오류 처리, 접근성, 성능, 유지보수 구조를 별도로 점검해야 합니다. 특히 금융, 의료, 법률, 결제, 개인정보가 관련된 서비스는 전문가 검토가 필요합니다.
Q. 좋은 AI MVP 실험의 성공 기준은 무엇인가요?
A. 좋은 성공 기준은 사용자 행동이나 의사결정과 연결되어야 합니다. 예를 들어 사용자가 1분 안에 원하는 정보를 찾는지, 기존 방식보다 입력 시간이 줄어드는지, 핵심 단계에서 이탈하지 않는지처럼 관찰 가능한 기준이 필요합니다.
Q. AI 코딩을 조직에 도입할 때 가장 먼저 정해야 할 것은 무엇인가요?
A. 가장 먼저 실험의 기본 양식을 정하는 것이 좋습니다. 문제, 가설, 범위, 성공 기준, 사용할 데이터, 금지 데이터, 종료일, 다음 의사결정 방식을 기록하면 AI 프로토타입이 즉흥적인 데모에 그치지 않고 조직의 학습 자산으로 남을 수 있습니다.

Sources
- The Lean Startup Principles: https://theleanstartup.com/principles
- People + AI Guidebook: https://pair.withgoogle.com/guidebook/
- GitHub Copilot documentation: https://docs.github.com/en/copilot
- Claude Code: Best practices for agentic coding: https://www.anthropic.com/engineering/claude-code-best-practices
- Exploring Generative AI: https://martinfowler.com/articles/exploring-gen-ai.html

Images
- 컨베이어 위에서 화면을 만드는 AI 로봇, 나침반, 로드맵, 체크 표시: https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzA1NSwicHVyIjoiYmxvYl9pZCJ9fQ==--b60f6fc0807ab09049a0addbf6a573d28afda6d8/ai-a6cb5742.webp
- 나침반을 든 사람과 AI 로봇이 검증, 프로토타입, 사용자 피드백 순환을 보여주는 일러스트: https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzA2MSwicHVyIjoiYmxvYl9pZCJ9fQ==--a0fa007960eb6f925e2189c8e48a5230bd2a1922/ai-0a5d3d9a.webp
- AI 코딩 시대의 기획 중요성을 네 단계와 비용, 목업, 검증 흐름으로 설명한 인포그래픽: https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzA2NywicHVyIjoiYmxvYl9pZCJ9fQ==--40ce07d9392b577bc21cf78205a1ec616fb91e9d/ai-c64e1355.webp

---
Category: 하우투
Source: https://injoys.com/ko/articles/why-planning-matters-in-ai-coding-era
License: cc_by
Translation-Status: original