# AI 시대의 프로그래머: 코드 생성에서 비결정성 통제로의 역할 전환 > Clean Markdown view of GeekNews topic #30711. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30711](https://news.hada.io/topic?id=30711) - GeekNews Markdown: [https://news.hada.io/topic/30711.md](https://news.hada.io/topic/30711.md) - Type: news - Author: [baeba](https://news.hada.io/@baeba) - Published: 2026-06-22T10:32:20+09:00 - Updated: 2026-06-22T10:32:20+09:00 - Original source: [velog.io](https://velog.io/@teo/we-programmer) - Points: 6 - Comments: 0 ## Topic Body #### 요약 개요 * AI가 코드 작성의 상당 부분을 자동화하면서 개발자의 핵심 역할은 직접 구현에서 **설계·검증·통제**로 이동하고 있음. * 프로그래머의 본질은 코드를 많이 입력하는 것이 아니라, 모호한 요구사항의 디테일을 채우고 이를 재사용 가능한 형태로 추상화하는 데 있음. * AI에게 세부 구현 방법을 지시하기보다 **목표와 맥락을 제시하고 판단을 위임하는 방식**이 더 효과적임. * AI 작업은 한 번에 처리하기보다 명세, 테스트, 구현, 리팩터링, 검증으로 산출물을 분리해야 품질을 높일 수 있음. * AI의 출력은 비결정적이므로 테스트, 컴파일러, 린터, 검증 게이트 등의 **결정적 하네스**가 필요함. * 미래 개발자는 단순 코드 작성자가 아니라 AI 에이전트와 검증 체계를 연결하는 **시스템 설계자·하네스 엔지니어**에 가까워질 것으로 전망됨. --- #### 서론 ##### AI가 흔든 개발자의 정체성 * AI가 자연어 지시만으로 수백 줄의 코드를 생성하면서 기존의 개발 역량에 대한 기준이 변화하고 있음. * 과거에는 빈 에디터에서 빠르게 코드를 작성하는 능력이 개발자의 주요 경쟁력으로 평가되었음. * 현재는 지식과 구현 방법을 AI가 제공하면서 다음과 같은 의문이 발생함. * 직접 코드를 작성하지 않아도 개발이라고 할 수 있는가. * AI가 구현의 디테일을 처리하면 개발자에게 어떤 역할이 남는가. * 전통적인 컴퓨터과학 지식과 프로그래밍 역사는 현재에도 필요한가. * 게시글은 이 문제를 **디테일, 추상화, 비결정성, 하네스**라는 개념을 중심으로 설명함. ##### 프로그래밍 역사의 의미 * 과거의 프로그래밍 지식은 단순한 기술 목록이 아니라 당시 개발자들이 문제를 해결하고 새로운 추상화 계층을 만든 과정임. * 기계어, 어셈블리어, 구조적 프로그래밍, 객체지향, 프레임워크는 하위 계층의 복잡성을 감추기 위해 만들어진 결과임. * 오래된 기술을 직접 사용하지 않더라도 그 역사를 이해하면 개발자의 역할이 반복적으로 어떻게 변화해 왔는지 파악할 수 있음. --- #### 본론 ##### 1. 개발자는 디테일을 구체화하는 사람이다 * 기획은 일반적으로 제품의 목적과 큰 방향을 제시하지만 실제 구현에 필요한 모든 조건을 명시하지는 않음. * 예를 들어 ‘닉네임 수정’이라는 단순한 기능에도 다음과 같은 세부 조건이 존재함. * 빈 문자열을 허용할 것인지 여부 * 특수문자와 이모지 처리 방식 * 네트워크 오류와 응답 지연 처리 * 수정 중 화면을 벗어났을 때의 동작 * 오류 메시지의 위치와 표현 방식 * 개발자의 업무는 이러한 빈틈을 논리적인 규칙과 예외 처리로 구체화하는 과정임. * 따라서 개발자의 전문성은 단순 기능 구현보다 **모호한 요구사항을 완결된 시스템 동작으로 전환하는 능력**에 있음. ##### 2. 추상화는 해결한 디테일을 감추는 과정이다 * 개발자는 반복 작업을 줄이기 위해 한 번 해결한 문제를 함수, 모듈, 라이브러리, 프레임워크 등으로 포장함. * 추상화의 핵심은 다음과 같음. * 반복되는 내부 동작을 감춤. * 외부에서 필요한 기능만 노출함. * 변경 가능한 부분과 고정할 부분의 경계를 설정함. * 견고한 추상화가 축적되면 새로운 계층이 형성되고, 상위 계층의 개발자는 하위 구현을 모두 알지 않아도 작업할 수 있음. * 현재의 개발 환경은 이전 세대 개발자들이 구축한 추상화 계층 위에서 작동함. ##### 3. 개발자에게 필요한 깊이는 위치에 따라 달라진다 * 모든 추상화가 완성된 것은 아님. * 안정적으로 내부 구현을 감추는 계층은 ‘완료된 추상화’로 볼 수 있음. * 내부 디테일이 성능 문제나 오류의 형태로 계속 노출되는 계층은 ‘진행 중인 추상화’에 해당함. * 동일한 기술도 개발자의 역할에 따라 상태가 달라짐. * 일반 웹 개발자에게 브라우저는 비교적 완성된 계층임. * 브라우저 엔진 개발자에게 렌더링 과정은 직접 다뤄야 하는 세부 문제임. * 개발자에게 필요한 깊이는 모든 기술을 아는 것이 아니라 **자신이 담당하는 계층의 누수와 한계를 파악할 수 있는 수준**임. ##### 4. AI가 새로운 추상화 계층으로 등장했다 * AI는 기존에 개발자가 직접 처리하던 코드 작성과 반복 구현을 빠르게 수행함. * 이에 따라 AI는 단순한 생산성 도구를 넘어 개발 과정 자체를 추상화하는 새로운 계층으로 작동하기 시작함. * 그러나 AI가 코드를 생성한다고 해서 요구사항 해석, 구조 설계, 품질 검증, 운영 책임까지 자동으로 해결되는 것은 아님. * 오히려 구현 비용이 낮아지면서 생성된 코드를 조립하고 검증하는 비용의 중요성이 커짐. ##### 5. 세부 지시는 AI의 성능을 제한할 수 있다 * 작성자는 접근성 UI 사이드 프로젝트에서 코드를 직접 입력하지 않고 AI만으로 개발을 시도함. * 초기에는 AI에게 구체적인 구현 방법을 제시했으나, AI가 제시된 방법에 고착되어 예외 처리를 반복적으로 추가하는 문제가 발생함. * 결과적으로 코드는 복잡해지고 여러 부작용이 발생했으며, 더 적절한 표준 방식은 뒤늦게 적용됨. * 이 사례는 사용자가 제시한 초기 방법이 AI의 판단을 제한하는 **앵커**로 작용할 수 있음을 보여줌. * 해결 방법과 코드 구조를 지나치게 지시하기보다 다음을 제공하는 것이 효과적임. * 문제의 배경과 목적 * 현재 시스템의 맥락 * 반드시 만족해야 할 결과 * 변경해서는 안 되는 제약 조건 ##### 6. 지시보다 목표와 맥락을 위임해야 한다 * AI의 성능이 높아질수록 세부 절차를 직접 지정하는 방식보다 목표 중심의 위임이 효과적일 수 있음. * 위임 방식에서는 개발자가 ‘어떻게 구현할지’를 모두 정하는 대신 ‘왜 필요한지’와 ‘무엇을 달성해야 하는지’를 명확하게 전달함. * 다만 완전한 자율성을 부여하면 AI가 사용자의 의도보다 코드 수정 자체에 집중할 수 있음. * 따라서 AI가 먼저 다음 행동을 수행하도록 작업 절차를 제한할 필요가 있음. * 요청 의도 분석 * 부족한 정보에 대한 질문 * 해결 계획 제시 * 사용자 승인 이후 실행 * 핵심은 단순한 금지 명령보다 **현재 단계에서 허용되는 산출물을 명확하게 지정하는 것**임. ##### 7. 한 번의 작업에는 하나의 산출물만 지정해야 한다 * LLM은 한 번의 응답에서 처리할 수 있는 출력량과 사고 범위가 제한됨. * 테스트 작성과 구현을 동시에 지시하면 최종 목표인 코드 완성에 자원이 집중되어 테스트 품질이 낮아질 수 있음. * 작성자는 TDD 작업을 다음과 같이 분리함. * `/red`: 실패하는 테스트만 작성 * `/green`: 테스트를 통과하는 최소 구현 작성 * `/refactor`: 테스트를 유지하면서 코드 구조 개선 * 각 단계의 산출물을 하나로 제한하면 AI가 중간 절차를 생략하거나 형식적으로 처리하는 문제를 줄일 수 있음. * 이는 프롬프트 설계의 핵심이 행동을 장황하게 설명하는 것이 아니라 **한 번의 작업에서 생성해야 할 결과물을 정의하는 것**임을 의미함. ##### 8. 마크다운 문서와 스킬이 새로운 코드가 된다 * 명세, 테스트, 구현, 검증, 커밋 작업을 각각의 스킬로 분리하면 다음과 같은 파이프라인을 구성할 수 있음. * 명세 작성 * 실패 테스트 생성 * 기능 구현 * 리팩터링 * 검증 * 커밋 * 각 스킬은 입력, 출력, 제약 조건을 가지므로 함수와 유사하게 작동함. * 스킬과 규칙을 기록한 마크다운 문서는 단순 설명서가 아니라 AI의 행동을 결정하는 실행 규칙으로 기능함. * 이 과정에는 기존 소프트웨어 설계 원칙도 적용할 수 있음. * 하나의 스킬에 하나의 책임만 부여하는 단일 책임 원칙 * 지식과 규칙을 별도 파일로 분리하는 모듈화 * 핵심 스킬을 변경하지 않고 외부 지식 파일로 확장하는 개방-폐쇄 원칙 * 플랫폼이 IDE에서 마크다운 문서로 바뀌었을 뿐, 작업을 분해하고 연결하는 행위는 여전히 프로그래밍에 해당함. ##### 9. AI 코딩의 핵심 위험은 비결정성이다 * 전통적인 프로그램은 동일한 입력에 대해 대체로 동일한 출력을 반환함. * AI는 동일한 요청에도 서로 다른 코드와 판단을 생성할 수 있음. * AI가 대규모 리팩터링을 수행하면 기능이 작동하더라도 다음 문제들이 남음. * 변경된 코드의 정확성 검토 * 삭제된 코드가 불필요했는지에 대한 판단 * 새로운 부작용 발생 가능성 * 유지보수와 배포 책임 * AI는 코드 생성 속도를 높이지만, 결과의 안정성과 책임까지 자동으로 제공하지는 않음. * 프로덕션 환경에서는 생성 능력보다 **변경 범위를 통제하고 결과를 검증하는 능력**이 중요함. ##### 10. AI는 천장이 낮은 문제에 강하다 * AI가 손쉽게 처리하는 문제는 대체로 요구사항과 해결 방식이 충분히 알려진 ‘잘 정의된 문제’임. * 이러한 문제는 기존 라이브러리, 프레임워크, 패턴 등 이미 완성된 추상화 요소를 조합하여 해결할 수 있음. * AI는 인류가 축적한 코드와 문제 해결 패턴을 확률적으로 조합하는 데 강점을 가짐. * 반면 다음과 같은 높은 난도의 문제에는 추가적인 인간 판단이 필요함. * 요구사항이 불완전한 문제 * 복잡한 도메인 규칙 * 대규모 시스템의 상호작용 * 운영 환경의 예외 상황 * 보안, 성능, 규제, 책임이 결합된 문제 * 단순 구현의 가치가 사라지는 것은 아니지만, 구현 자체는 점차 일반 사용자도 수행할 수 있는 영역으로 이동할 가능성이 있음. ##### 11. 개발자의 디테일은 AI 통제로 이동한다 * 과거 개발자는 결정적인 코드를 작성해 예측하기 어려운 사용자 입력과 운영 환경을 방어했음. * AI 시대에는 비결정적인 AI를 이용해 결정적인 제품을 만들어야 함. * 개발자가 처리해야 할 디테일은 다음 영역으로 이동함. * AI가 잘못된 목표에 고착되지 않도록 작업 범위 설정 * 단계별 입력과 출력의 형식 정의 * 컨텍스트와 지식 문서 관리 * 대규모 변경의 범위 제한 * 오류 발생 시 복구 절차 설계 * 결과의 품질과 안전성 검증 * 단순 구현 업무가 자동화될수록 개발 업무는 예외 처리와 통제 문제의 비중이 높아질 수 있음. ##### 12. AI의 결과는 결정적 도구로 검증해야 한다 * AI가 생성한 결과를 다른 AI에게 검증시키는 방법만으로는 충분한 신뢰성을 확보하기 어려움. * 시스템의 출력이 올바른지를 판단하려면 명확한 정답 기준, 즉 오라클이 필요함. * 비결정적인 AI가 검증 기준까지 임의로 생성하면 올바른 결과를 잘못 수정하거나 검증 기준을 왜곡할 가능성이 있음. * 따라서 검증 기준은 가능한 한 결정적인 도구로 구성해야 함. * 컴파일러와 타입 검사기 * 자동화된 테스트 * 린터와 정적 분석 * 스키마 검사 * 성능·보안 기준 * 승인 절차와 변경 범위 제한 * AI의 판단은 보조 수단으로 사용할 수 있지만, 최종 통과 여부는 재현 가능한 기준에 연결해야 함. ##### 13. 하네스가 AI 개발의 핵심 인프라가 된다 * 하네스는 AI가 작업 과정에서 오류를 누적하거나 범위를 벗어나지 못하도록 단계별로 배치하는 검증 장치임. * 주요 구성 요소는 다음과 같음. * 작업 단계를 분리하는 파이프라인 * 단계별 입출력 형식 * 자동 테스트와 정적 분석 * 실패 시 중단되는 검증 게이트 * 변경 가능한 파일과 범위의 제한 * 사람의 승인과 리뷰 절차 * 하네스는 한 단계의 작은 오류가 다음 단계에서 확대되는 것을 방지함. * AI 활용 능력은 단순히 좋은 프롬프트를 작성하는 능력보다 **예측 불가능한 출력을 안정적인 시스템 안에 묶는 능력**으로 평가될 가능성이 있음. --- #### 결론 ##### 개발자는 사라지는 것이 아니라 역할이 이동한다 * AI는 단순한 코드 작성과 반복 구현을 빠르게 자동화하고 있음. * 그러나 제품 수준의 결과를 만들기 위해서는 여전히 다음 역할이 필요함. * 문제와 목표 정의 * 시스템 구조 설계 * 작업 단계와 산출물 분리 * AI 에이전트 간 흐름 조율 * 검증 기준과 하네스 구축 * 운영 결과에 대한 최종 책임 * 개발자의 업무는 직접 코드를 입력하는 비중이 줄고, AI가 생성한 코드를 시스템으로 조직하고 통제하는 방향으로 변화할 가능성이 높음. ##### 프롬프트 작성은 새로운 형태의 프로그래밍이다 * 반복적으로 사용하는 지시를 스킬과 규칙으로 만들고 파이프라인으로 연결하는 과정은 함수와 모듈을 설계하는 것과 유사함. * 마크다운 문서는 AI의 맥락, 행동, 출력 형식을 정의하는 새로운 코드 계층으로 기능할 수 있음. * 개발자는 자신의 경험과 암묵적인 판단 기준을 문서화해 AI가 재사용할 수 있는 형태로 추상화해야 함. * 이는 기존 시스템을 추상화하는 것을 넘어 **개발자 자신의 작업 방식과 판단 과정까지 추상화하는 작업**임. ##### 미래 개발자의 핵심 역량 * 문제를 정확하게 정의하는 능력 * 목표와 맥락 중심으로 업무를 위임하는 능력 * 복잡한 작업을 작은 산출물로 분해하는 능력 * 스킬과 에이전트를 파이프라인으로 구성하는 능력 * 결정적인 검증 기준을 설계하는 능력 * 비결정적 결과의 위험을 통제하는 하네스 구축 능력 * AI가 생성한 결과를 이해하고 최종 책임을 질 수 있는 기술적 깊이 ##### 종합 평가 * AI는 개발의 본질을 제거하기보다 개발자가 다뤄야 할 추상화 계층을 변화시키고 있음. * 이전의 개발자가 코드와 시스템의 디테일을 처리했다면, 미래의 개발자는 AI의 행동과 출력에서 발생하는 디테일을 처리해야 함. * 코드를 생성하는 비용은 낮아지지만 검증, 조립, 운영, 통제의 중요성은 더욱 커질 가능성이 있음. * 프로그래머의 본질은 타이핑 자체가 아니라 **디테일을 발견하고, 이를 추상화하며, 신뢰할 수 있는 시스템으로 구성하는 능력**에 있음. ## Comments _No public comments on this page._