잘 짠 기획이 잘 짠 코드를 만든다

AI한테 "회원 관리 페이지 만들어줘" 하면 코드가 척척 나오는 시대예요. 그런데 같은 도구를 써도 누구는 바로 쓸 만한 결과를 얻고, 누구는 그럴듯해 보이는 쓰레기를 빠르게 쌓아요. 이 차이는 도구가 아니라 그 도구를 사용하는 사람에게서 갈려요. AI는 잘 짜인 기획과 설계를 빠르게 구현해주지만, 무엇을 어떻게 만들지까지 대신 정해주진 않거든요.

AI는 문제를 해결할 뿐, 정의하지 못한다

AI가 내놓는 코드의 질은 결국 사람이 건넨 기획의 질을 따라가요. 좋은 기획을 주면 좋은 코드가 나오고, 막연한 요청을 주면 막연한 코드가 나와요. 프롬프트(AI에게 건네는 요청문)는 단순한 명령어가 아니라 사실상 문제 정의서거든요.

사실 "짜기 전에 먼저 생각한다"는 원칙은 AI 이전에도 늘 있었어요. 예전 개발팀도 코드 한 줄 짜기 전에 요구사항 정의서, 화면 밑그림인 와이어프레임, 작동 순서를 그린 순서도부터 만들었어요. 구현이 느리고 비쌌으니 앞단에서 신중할 수밖에 없었죠. AI가 바꾼 건 구현 속도지 기획의 무게가 아니에요. 오히려 구현이 빨라진 만큼, 병목은 "무엇을 만들지 정하는 일"로 옮겨왔어요.

차이는 프롬프트 한 줄에서 바로 드러나요. "회원가입 폼 만들어줘"라고 던지면 어디서나 볼 평범한 폼이 나와요. 반면 이메일 중복을 실시간으로 확인하고, 비밀번호는 8자 이상에 특수문자를 받고, 재입력 검증까지 넣으라고 정의하면 결과물이 완전히 달라져요. 잘못 정의한 문제 앞에서는 AI도 무력해요. 세션 관리나 보안 정책이 빠진 코드를 받아 뜯어고치는 시간이, 처음부터 제대로 정의하는 시간보다 훨씬 길어요.

GitHub의 공식 연구를 보면, 코딩 보조 도구 코파일럿(Copilot)을 쓴 개발자가 작업을 55% 빠르게 끝냈어요. 더 중요한 건 그다음이에요. 줄어든 시간을 반복적인 문법 찾기가 아니라 비즈니스 문제를 정의하고 전체 구조를 결정하는 데 썼다고 해요. AI가 단순 작업을 덜어줄수록, 사람은 "무슨 문제를 풀 것인가"라는 본질에 집중하게 되는 거예요. 그렇다면 문제를 또렷하게 정의한다는 건 구체적으로 어떤 작업일까요.

막막한 일을 잘게 쪼개는 게 기획의 절반이다

좋은 기획은 타고난 감각이 아니에요. 막막한 덩어리를 작은 조각으로 쪼개는 순서를 따르는 일이에요.

이걸 문제 분해(problem decomposition)라고 불러요. 큰 문제를 작은 하위 문제로 나눠 하나씩 푸는 방식이에요. 흥미롭게도 AI도 같은 방식을 좋아해요. 큰 문제를 작은 단위로 나눠 차례로 풀게 하면 AI의 정답률이 올라가요. 이걸 다룬 arXiv 프롬프트 엔지니어링 보고서는 프롬프트를 잘 쓰는 일 자체가 문제를 잘게 쪼개는 컴퓨팅 사고와 같다고 정리해요. 개발 지식이 없어도 괜찮아요. 이 쪼개기는 코딩 실력이 아니라 생각의 순서거든요.

쪼갤 때는 왜 → 무엇 → 어떻게 순서로 내려가면 쉬워요. 예를 들어 "고객 문의가 쌓여 답을 자꾸 놓친다"는 상황을 풀어볼게요.

1. 왜(목적): 급한 문의를 놓쳐 고객이 떠나요.

2. 무엇(기능): 새 문의가 오면 급한 것부터 위에 보여줘요.

3. 어떻게(단계): 문의 수집 → 키워드로 급함 판별 → 목록 정렬 → 알림 순이에요. 이 단계가 AI에게 맡길 일이에요.

여기서 한 가지가 더 필요해요. 정상적인 흐름만 떠올리면 AI도 정상 흐름만 만들어요. 그래서 예외를 먼저 떠올려야 해요. "문의가 비어 있으면?", "스팸이면?", "같은 사람이 열 번 보내면?" 이런 엣지케이스(예외 상황)를 미리 적어두면 AI가 그 처리까지 넣어줘요.

마지막은 "이번엔 안 만들 것"을 정하는 거예요. 욕심내면 끝이 없거든요. "자동 답변은 이번 범위에서 뺀다"처럼 선을 그어두면 AI도 딱 그만큼만 깔끔하게 만들어요. 이렇게 쪼갠 조각이 서넛을 넘어가면, 이제 조각끼리 어떻게 맞물릴지가 새 고민이 돼요. 그게 바로 설계예요.

구조를 안 그리면 AI를 써도 더 느려진다

기능이 하나면 문제 정의만으로 충분해요. 그런데 화면과 기능이 여러 개로 엮이면 전체 구조를 그리는 설계가 반드시 필요해요. AI는 주어진 설계는 충실히 구현하지만, 그 설계도 자체를 대신 그려주진 않아요.

집 짓기에 비유하면 쉬워요. AI는 솜씨 좋은 시공팀이고, 사람은 설계도를 그리는 건축가예요. 설계도 없이 "방 만들어줘", "주방도 만들어줘"라고 따로 시키면, 각 공간은 그럴듯해도 벽과 배관이 서로 안 맞아요. 데이터를 어디에 저장할지, 기능을 어떻게 연결할지를 먼저 그려야 조각들이 하나로 맞물려요.

이 설계를 건너뛰면 속도가 오히려 느려져요. METR의 2025년 연구에서, 경험 많은 개발자들이 AI 코딩 도구를 썼는데 본인은 20% 빨라졌다고 느꼈지만 실제로는 19% 더 느렸어요. 큰 구조를 먼저 잡지 않고 AI 출력을 조각조각 받아 매번 검증하고 맥락을 다시 맞추느라 시간이 샌 거예요.

비용으로 봐도 설계가 먼저예요. 소프트웨어 공학의 고전적 수치를 정리한 Black Duck을 보면, 설계 단계에서 잡으면 1이던 오류 수정 비용이 구현 단계에선 6배로 뛰어요. 테스트에선 15배, 출시 뒤 유지보수 단계에선 100배까지 커져요. AI가 구현을 싸게 만들었을 뿐, 설계 없이 기운 코드를 고치는 값은 여전히 비싸요. 이 비싼 청구서에는 이름이 있어요. 바로 기술 부채예요.

기술 부채라는 청구서, 빌더가 진짜 키워야 할 무기

기획이 촘촘하고 설계가 탄탄하면 코드도 기능별로 깔끔하게 나뉘어요. 결제는 결제대로, 알림은 알림대로 독립된 모듈(기능 단위로 분리된 코드 덩어리)로 작동해요. 반대로 막연한 기획에서 나온 코드는 한 덩어리로 엉켜요. 알림 하나 바꿨는데 결제가 멈추는 일이 그래서 생겨요. 이렇게 급하게 짜서 나중에 갚아야 하는 부실 코드를 기술 부채(technical debt)라고 불러요.

기술 부채는 생각보다 비쌉니다. 이 주제를 정리한 Brights 자료에 따르면, Stack Overflow 2024 개발자 설문에서 62%가 기술 부채를 업무에서 가장 큰 스트레스로 꼽았어요. 같은 자료에 인용된 Deloitte Tech Trends 2024 기준으로, 개발자는 업무 시간의 약 33%를 이 기술 부채에 시간을 써요. AI로 빨리 찍어낸다고 안전한 것도 아니에요. 코드 변화 2억 1천만 줄을 분석한 GitClear에 따르면, 2024년 한 해 중복된 코드 덩어리가 8배로 늘었어요. 빌더가 체감하는 불편도 비슷해요. Stack Overflow 2025 설문에서 개발자들이 꼽은 가장 큰 불만은 "AI가 거의 맞지만 살짝 틀린 코드"(66%)였어요. 그런 코드를 다시 디버깅하느라 시간이 더 든다는 답이 그 뒤를 이었고요.

같은 기능이라도 기획의 밀도에 따라 결과 코드가 이렇게 달라져요.

결국 AI 시대에 희소해지는 능력은 코드를 직접 타이핑하는 실력이 아니에요. 문제를 정의하고 구조를 설계하는 힘이에요. 타이핑은 AI가 대신하지만, "무엇을 왜 어떤 구조로 만들지"는 사람만 정할 수 있거든요.

도구를 쓰는 사람은 이미 많아요. Stack Overflow 2025 개발자 설문에서 개발자의 84%가 AI 도구를 쓰지만, AI를 신뢰한다는 응답은 29%로 1년 전보다 오히려 떨어졌어요. 다들 쓰지만 잘 쓰는 사람은 드물다는 뜻이에요. 그 격차를 만드는 게 바로 기획과 설계력이에요.

오늘부터 한 가지만 바꿔보면 돼요. 프롬프트를 던지기 전에 5분만 멈추고 "이게 왜 필요한지, 어떤 단계로 나눌지, 전체를 어떤 구조로 짤지"를 한 줄씩 적어보세요. 이 5분이 나중에 몇 시간을 아껴줘요. 관련해서 AI가 코드는 빨리 만들어주는데, 어디서 병목이 터질까?와 AI 직원 10명을 고용했는데, 일이 더 많아진 이유도 같이 보면 도움이 돼요. AI는 실행 속도를 끌어올리는 강력한 엔진이지만, 운전대는 사람이 쥐어요.

한 번 더, 빠르게 짚고 갈게요

Q. AI 코딩 도구를 쓰면 기획 없이도 빠르게 만들 수 있지 않나요?

A. 빠르게 만들 수는 있지만, 기획이 없으면 빠르게 쓸모없는 걸 만들어요. 프롬프트가 곧 문제 정의라서, 문제를 또렷하게 정의하지 않으면 AI도 엉뚱한 걸 그럴듯하게 만들어줘요. 나중에 뜯어고치는 시간이 처음부터 제대로 정의하는 시간보다 더 걸려요.

Q. 개발을 모르는데도 기획·설계를 할 수 있나요?

A. 개발 지식보다 "무엇이 불편한지", "어떤 순서로 풀지", "무엇과 무엇을 연결할지"를 또렷하게 설명하는 능력이 더 중요해요. "로그인 만들어줘" 대신 "이메일·비밀번호를 받고, 로그인하면 토큰을 발급하고, 3일 유지하다 자동 로그아웃"처럼 단계로 설명하면 AI가 정확히 구현해줘요.

Q. AI가 코드를 짜주는데 왜 오히려 느려질 수 있나요?

A. 전체 구조를 먼저 잡지 않고 조각조각 맡기면, 매번 출력을 확인하고 맥락을 다시 맞추느라 시간이 새요. METR 2025년 연구에서도 경험 많은 개발자가 AI를 쓰고 19% 느려졌어요. 설계도를 먼저 그려두면 이 낭비가 줄어들어요.

Q. AI가 나오기 전과 기획하는 방식이 많이 달라졌나요?

A. 도구는 달라졌지만 본질은 같아요. 예전에도 요구사항 정의서나 순서도로 "짜기 전에 먼저 생각"했어요. 달라진 건 구현 속도뿐이에요. 오히려 구현이 빨라지면서, 무엇을 만들지 정하는 기획이 더 중요한 병목이 됐어요.

Q. 기획·설계 능력은 어떻게 키우나요?

A. 문제를 한 문장으로 정의하고 작은 단위로 쪼개는 연습이 가장 빨라요. "회원가입 만들어줘" 대신 "이메일 중복 확인 → 비밀번호 규칙 검증 → 재입력 확인"처럼 단계로 적어보세요. 프롬프트 하나를 던지기 전에 5분 정리하는 습관이 핵심이에요.