AI 시대의 진짜 개발 능력은 완성보다 ‘미진함’을 다루는 데 있다

Sep 06, 2026

7 min read

0 views

92%

AI가 코드를 거의 끝까지 만들어 주는 시대에, 왜 가장 뛰어난 개발자는 오히려 문제를 덜 완성된 상태로 AI에게 가져갈까?

이 질문은 겉보기에는 서로 다른 두 장면을 연결한다. 하나는 백엔드, 프론트엔드, 모바일 앱을 한곳에서 만들고, 여러 기기에서 즉시 결과를 확인하며, 대화로 앱을 수정하는 통합 개발 환경이다. 다른 하나는 거대한 자바스크립트 파일을 AST로 리팩토링하다가 잘 풀리지 않는 지점만 잘라서 AI에게 다음 시도를 묻는 협업 방식이다.

하지만 두 장면은 같은 변화를 가리킨다. AI 시대의 개발은 무엇을 만들 수 있는가의 문제가 아니라, 어디에서 인간과 AI의 경계를 설정할 것인가의 문제가 되고 있다.

AI가 개발 환경 전체에 들어오면 사람은 더 이상 모든 코드를 직접 작성하는 사람이 아니다. 그렇다고 단순히 명령을 내리는 관리자도 아니다. 사람은 문제를 적절한 크기로 나누고, 불확실성을 노출하고, 결과를 실제 환경에서 검증하며, 다음 판단에 필요한 맥락을 선택하는 역할을 맡는다.

전체를 맡기는 순간, 학습과 통제는 사라진다

새로운 통합 개발 환경은 매우 매력적이다. 환경 설정에 시간을 쓰지 않고도 작업을 시작할 수 있고, 서버와 클라이언트, 모바일 화면을 한 공간에서 연결할 수 있다. 미리보기 결과를 여러 기기에서 곧바로 확인할 수 있으며, 대화형 AI에게 앱의 특정 기능을 바꾸라고 요청할 수도 있다.

이것은 단순한 편의 기능의 집합이 아니다. 개발 도구의 기본 단위를 바꾸는 시도다. 과거에는 파일, 저장소, 로컬 실행 환경이 작업의 중심이었다. 이제는 요구사항, 코드, 실행 환경, 미리보기, 배포 설정이 하나의 연속된 작업 공간으로 묶인다.

그러나 통합은 곧바로 생산성을 보장하지 않는다. 모든 것이 한곳에 있다는 것은 모든 것을 한 번에 바꿀 수 있다는 뜻이기도 하다. AI에게 “로그인 기능을 추가하고 모바일 화면까지 다듬어 줘”라고 요청하면, 결과는 빠르게 나타날 수 있다. 하지만 무엇이 바뀌었는지, 어떤 가정이 들어갔는지, 실패가 어느 층위에서 발생했는지 추적하기 어려워질 수 있다.

개발자가 직접 설정 파일을 만들고, 의존성을 설치하고, 오류 메시지를 읽던 과정은 귀찮았지만 중요한 역할을 했다. 시스템의 구조를 머릿속에 심어 주었기 때문이다. 이 과정을 모두 제거하면 개발자는 시간을 얻는 대신 구조에 대한 감각을 잃을 수 있다.

여기서 핵심적인 긴장이 생긴다. AI 도구는 작업의 마찰을 줄인다. 하지만 모든 마찰이 나쁜 것은 아니다. 일부 마찰은 사고를 깊게 만드는 저항이며, 시스템의 경계를 알려 주는 신호다.

예를 들어 Nix처럼 개발 환경을 세밀하게 정의할 수 있는 도구는 겉으로는 AI와 반대편에 있는 것처럼 보인다. 한쪽은 대화를 통해 즉시 결과를 만들고, 다른 한쪽은 환경을 명시적으로 기술하며 재현성을 추구한다. 그러나 실제로 둘은 보완 관계에 가깝다. AI가 빠르게 코드를 생성할수록, 실행 환경을 명확하게 고정하는 일이 더 중요해진다. 생성 속도가 빨라질수록 무엇이 변하지 않아야 하는지 선언하는 능력이 필요하기 때문이다.

가장 좋은 AI 협업 단위는 ‘완성된 요청’이 아니다

거대한 자바스크립트 파일을 리팩토링하는 상황을 생각해 보자. 처음부터 파일 전체를 AI에게 넘기고 “읽기 좋게 고쳐 달라”고 요청하면 그럴듯한 결과를 받을 수 있다. 하지만 이 요청은 너무 크다. AI가 코드를 이해하고, 의도를 추정하고, 변경 전략을 선택하고, 부작용을 검사해야 하기 때문이다. 사용자는 결과를 검토하는 것 외에는 사고 과정에 개입할 지점이 거의 없다.

더 효과적인 방식은 문제를 단계적으로 축소하는 것이다. 먼저 코드와 설명, 공식 문서를 조금씩 대조하면서 Babel의 동작을 이해한다. 그다음 특정 변환을 AST로 시도한다. 오류가 나면 전체 파일을 다시 넘기지 않는다. “이 부분까지는 작동했지만, 이 노드에서 원하는 구조가 만들어지지 않는다. 다음에는 어떤 가설을 세울 수 있을까?”라고 묻는다.

이 방식의 장점은 단순히 프롬프트가 짧다는 데 있지 않다. 미진한 부분이 명확한 협업 인터페이스가 된다는 데 있다.

완성된 문제는 AI에게 정답을 요구한다. 반면 미진한 문제는 AI에게 탐색을 요청한다. 전자는 AI를 대체자로 만들지만, 후자는 AI를 사고 파트너로 만든다. 사용자는 이미 시도한 것, 확인된 것, 실패한 것, 아직 모르는 것을 구분해서 전달한다. AI는 그 경계 안에서 다음 실험을 제안한다.

이것은 과학적 방법과도 닮았다. 좋은 연구자는 “이 현상을 설명해 줘”라고 막연히 묻지 않는다. 관찰 결과를 기록하고, 통제된 조건을 만들고, 실패한 가설을 제거한 뒤, 다음 실험을 설계한다. AI 협업에서도 가장 가치 있는 입력은 완벽한 요구사항이 아니라 현재까지의 증거와 남아 있는 불확실성이다.

AI에게 가장 유용한 질문은 “전부 해 줘”가 아니라 “여기까지는 검증했다. 이제 어느 가설을 시험해야 할까?”다.

이 관점은 프롬프트 작성법을 넘어선다. 프롬프트를 잘 쓰는 사람은 말을 화려하게 만드는 사람이 아니다. 자신의 작업을 관찰 가능한 상태로 바꾸는 사람이다. 무엇을 원하는지뿐 아니라 무엇을 시도했는지, 무엇이 실패했는지, 무엇이 아직 불명확한지를 표현할 수 있어야 한다.

통합 환경은 실행 공간이 아니라 판단 루프다

여러 기기에서 즉시 미리보기를 확인할 수 있는 기능을 다시 보자. 이것은 단순히 화면을 편하게 보는 기능이 아니다. 코드 작성과 결과 확인 사이의 시간을 줄여 판단 루프를 압축한다.

전통적인 개발에서는 다음과 같은 순서가 반복된다.

코드를 작성한다.
환경을 설정한다.
빌드한다.
실행한다.
오류를 재현한다.
수정한다.

각 단계 사이의 간격이 길면 개발자는 자신의 변경과 결과 사이의 인과관계를 놓치기 쉽다. 반대로 수정 직후 여러 환경에서 결과를 볼 수 있으면, 작은 변화가 사용자 경험에 어떤 영향을 주는지 빠르게 학습할 수 있다.

이때 AI는 코드를 만드는 기계라기보다 판단 루프를 가속하는 실험 장치가 된다. 예를 들어 모바일 화면의 버튼 간격을 조정해 달라고 요청하고, 실제 미리보기에서 터치하기 어려운지 확인한 뒤, 다시 특정 부분만 수정할 수 있다. 중요한 것은 첫 결과가 완벽한가가 아니다. 결과를 관찰하고 다음 질문을 만들 수 있는가다.

이 관점에서 통합 개발 환경의 핵심 가치는 기능의 수가 아니다. 백엔드와 프론트엔드, 모바일을 모두 다룬다는 사실 자체보다, 서로 다른 층위의 결과를 한 번에 비교할 수 있다는 점이 중요하다. 데이터 구조의 변경이 화면에 어떤 영향을 주는지, 화면의 요구가 API 설계에 어떤 부담을 주는지 빠르게 왕복할 수 있기 때문이다.

다만 판단 루프가 빨라질수록 검증 기준도 정교해져야 한다. 빠른 미리보기는 빠른 착각을 만들 수도 있다. 한 기기에서 잘 보이는 화면이 다른 기기에서는 무너질 수 있고, 정상적인 입력 하나가 보안상 위험한 경로를 숨길 수 있다. 따라서 AI 개발 환경에서는 “작동한다”와 “사용할 수 있다”, “배포할 수 있다”를 분리해야 한다.

이를 위해 결과를 세 층으로 나누어 보는 것이 유용하다.

첫째, 생성 검증이다. 코드가 문법적으로 생성되었고 실행되는가를 본다. 둘째, 구조 검증이다. 의존성, 상태 관리, 데이터 흐름이 의도한 형태를 유지하는지 확인한다. 셋째, 현실 검증이다. 실제 기기, 실제 사용자 입력, 실제 실패 조건에서 기대한 경험을 제공하는지 살핀다.

AI는 첫 번째 층에서 특히 강하다. 두 번째 층에서는 인간의 설계 감각과 도구의 도움이 함께 필요하다. 세 번째 층에서는 아직도 현실 세계의 관찰이 결정적이다. 통합 환경은 이 세 검증을 빠르게 연결해 줄 수 있지만, 어느 검증도 자동으로 대신하지는 않는다.

인간의 역할은 코드 작성에서 경계 설계로 이동한다

AI가 생산하는 코드의 양이 많아질수록 인간의 경쟁력은 직접 작성한 코드의 양으로 측정하기 어려워진다. 대신 다음 네 가지 능력이 중요해진다.

1. 문제를 적절한 크기로 자르는 능력

너무 큰 문제는 AI에게도 인간에게도 불투명하다. 너무 작은 문제는 전체 목적과 연결되지 않는다. 좋은 작업 단위는 한 번의 시도로 결과를 관찰할 수 있고, 실패했을 때 원인을 좁힐 수 있어야 한다.

AST 리팩토링에서 특정 노드 변환만 분리하는 것이 좋은 예다. 전체 변환 파이프라인을 한 번에 고치지 않고, 입력 AST와 기대 출력 AST를 비교할 수 있는 작은 실험으로 바꾸면 AI의 제안도 검증하기 쉬워진다.

2. 맥락을 선택하는 능력

AI에게 모든 자료를 제공하는 것이 항상 좋은 것은 아니다. 관련 없는 코드, 오래된 문서, 추측과 사실이 섞인 설명은 오히려 판단을 흐린다. 좋은 협업자는 필요한 맥락을 세 종류로 구분한다. 현재 상태, 이미 확인된 사실, 아직 해결되지 않은 질문이다.

이 세 가지를 분리하면 AI가 빈틈을 임의의 확신으로 메우는 일을 줄일 수 있다.

3. 실패를 정보로 바꾸는 능력

실패한 시도는 버려야 할 결과가 아니다. 어떤 입력에서 어떤 변환이 실패했는지, 기대와 실제가 어떻게 달랐는지 기록하면 다음 질문의 품질이 높아진다. AI에게 실패를 숨기고 새 답을 요구하는 것보다, 실패를 구조화해 보여 주는 편이 훨씬 생산적이다.

4. 불변 조건을 선언하는 능력

AI가 자유롭게 바꿔도 되는 부분과 절대 바뀌면 안 되는 부분을 구분해야 한다. API 형식, 데이터 보존 규칙, 접근성 조건, 보안 정책, 빌드 재현성 같은 요소가 여기에 해당한다. 이 불변 조건이 명확할수록 AI는 더 넓은 탐색을 할 수 있다. 경계가 분명해야 자유도 안전해진다.

바로 적용할 수 있는 협업 프로토콜

이 원칙을 실제 작업에 적용하려면 복잡한 도구보다 일정한 순서가 필요하다. 새로운 기능을 AI와 함께 만들 때 다음 프로토콜을 사용해 보자.

먼저 목표를 기능이 아니라 관찰 가능한 결과로 표현한다. “로그인 기능을 만들어 줘” 대신 “잘못된 비밀번호를 입력하면 오류 메시지가 표시되고, 새로고침 뒤에도 인증 상태가 일관되게 유지되어야 한다”고 적는다.

다음으로 작업을 하나의 판단 단위로 줄인다. 화면 전체, 저장소 전체, 애플리케이션 전체를 한 번에 다루지 말고, 한 번의 변경 뒤 결과를 확인할 수 있는 범위로 제한한다.

그다음 AI에게 현재 상태와 미진한 부분을 함께 제공한다. “여기까지 구현했고, 정상 입력에서는 통과한다. 그러나 토큰이 만료된 뒤 화면 상태가 갱신되지 않는다. 상태 관리 계층과 라우팅 계층 중 어디부터 확인해야 하는가?”와 같은 방식이다.

AI의 제안은 즉시 적용하지 말고 가설로 취급한다. 제안이 맞다면 어떤 관찰이 나타나야 하는지 먼저 정한 뒤 실행한다. 결과가 다르면 그 차이를 다시 기록한다.

마지막으로 실행 환경을 고정한다. 로컬과 배포 환경, 데스크톱과 모바일, 개발용 데이터와 실제와 유사한 데이터 사이의 차이를 명시한다. 빠른 생성보다 재현 가능한 검증이 장기적으로 더 큰 속도를 만든다.

Key Takeaways

AI에게 완성된 문제만 주지 말고, 지금까지 검증한 사실과 미진한 부분을 함께 전달하라. 미진함은 약점이 아니라 다음 실험을 설계하는 인터페이스다.
작업을 한 번의 판단 루프로 쪼개라. 한 번에 실행하고, 관찰하고, 원인을 좁힐 수 있는 크기가 가장 좋은 협업 단위다.
생성, 구조, 현실 검증을 분리하라. 실행된다는 사실만으로 좋은 코드나 배포 가능한 제품이 되지는 않는다.
Nix와 같은 명시적 환경 설정을 활용해 불변 조건을 고정하라. AI의 생성 범위가 넓어질수록 재현성과 경계가 중요해진다.
AI의 답을 정답이 아니라 가설로 다뤄라. 좋은 협업은 한 번의 완벽한 결과가 아니라 더 나은 다음 질문을 생산한다.

AI 개발 도구의 진정한 혁신은 사람이 코드를 덜 쓰게 된다는 데 있지 않다. 더 중요한 변화는 사람이 자신의 사고 과정을 더 자주 외부화해야 한다는 데 있다. 무엇을 알고 있는지, 무엇을 시도했는지, 무엇이 실패했는지, 무엇을 보존해야 하는지를 말할 수 있어야 한다.

결국 미래의 개발자는 모든 답을 알고 있는 사람이 아닐 가능성이 크다. 그는 답이 아직 없는 상태를 잘 설계하고, 그 상태를 작고 검증 가능한 실험으로 바꾸며, 인간과 AI가 서로의 맹점을 보완하도록 경계를 조정하는 사람일 것이다.