"코드 리뷰는 죽고, 터미널도 사라진다" - 해외 유명 엔지니어가 예측하는 AI 시대 소프트웨어 개발의 미래

AI는 소프트웨어 개발을 효율화할 뿐일까? 아니면 소프트웨어 엔지니어링이라는 직업 자체를 근본적으로 변화시킬까.

2026년 9월 19일, 소프트웨어 엔지니어인 Thorsten Ball 씨가 X(구 Twitter)에 "What I believe about the future of software development (제가 생각하는 소프트웨어 개발의 미래)"라는 글을 공개했습니다.

그 내용은 기존의 개발 상식을 뒤엎는 매우 대담한 예측들로 가득합니다.

예를 들어, 다음과 같은 예측들이 제시되었습니다.

• 코드 리뷰(Code Review)는 사라질 것이다
• 유닛 테스트(Unit Test)도 필요 없어질 수 있다
• 코드를 작성하는 기술 자체의 가치는 하락할 것이다
• 터미널이나 CLI(Command Line Interface)를 사람이 조작하는 시대는 끝난다
• PM, 디자이너, 엔지니어라는 역할 분담은 붕괴될 것이다
• AI의 토큰이 새로운 컴퓨팅의 중심이 될 것이다
• UI는 AI가 실시간으로 생성하게 될 것이다

이 예측들은 자극적이지만, 단순히 "프로그래머의 일이 AI에게 빼앗긴다"는 이야기만은 아닙니다.

오히려 핵심에 놓인 생각은 다음과 같습니다.

코드를 작성하는 것의 가치는 낮아지더라도, 소프트웨어로 문제를 해결하는 능력의 가치는 그 어느 때보다 높아진다.

본 기사에서는 Thorsten Ball 씨의 16가지 예측을 정리하고, 현장에서 시스템 개발을 하는 엔지니어의 시점에서 그 의미와 과제를 고찰합니다.

참고로, 아래 내용은 원문의 직역이 아니라 논점을 정리한 요약과 필자의 기술적 고찰입니다. 또한, 해당 씨의 주장은 미래 예측이며, 아직 업계 전체에서 실현되거나 입증된 사실은 아닙니다.

먼저 16가지 예측을 목록으로 살펴보겠습니다.

AI가 코드를 생성할 수 있게 되면, 코드 리뷰의 역할이 바뀝니다. 코드 리뷰가 바뀌면, 테스트의 위치 설정도 달라집니다. 구현 비용이 낮아지면, 조직 구조나 개발 프로세스에도 변화가 생깁니다.

즉, AI에 의한 코드 생성의 진화가 소프트웨어 개발 라이프사이클 전체에 연쇄적인 영향을 미친다는 것이 이 글의 본질이라고 생각됩니다.

일반적인 Git 기반 개발에서는 다음과 같은 플로우(Flow)가 채택되고 있습니다.

개발자가 코드를 작성한다
↓
Pull Request를 생성한다
... 

이 개발 플로우는 인간이 코드를 만들고, 인간이 변경 내용을 이해할 수 있다는 전제 하에 이루어집니다.

하지만 AI 에이전트가 짧은 시간에 수천 줄, 수만 줄의 코드를 생성하게 되면, 모든 것을 사람이 읽고 확인하는 방식은 비효율적이게 됩니다.

Thorsten Ball 씨는 장기적으로 인간이 모델이 생성한 코드의 결함을 합리적인 시간 내에 발견하기 어려워지며, 리뷰 대상이 개별 코드에서 시스템 전체 구성으로 이동할 것이라고 예측합니다.

예를 들어, EC(전자상거래) 사이트에 쿠폰 기능을 추가하는 경우를 생각해 봅시다.

기존의 리뷰에서는 다음과 같은 사항을 확인합니다.

• SQL 쿼리가 적절한가
• 조건 분기가 올바른가
• 코딩 규약을 지켰는가
• 예외 처리가 구현되었는가

AI 주도의 개발에서는, 리뷰 대상이 다음과 같이 변화할 가능성이 있습니다.

• 쿠폰 적용 조건은 업무 요구사항과 일치하는가
• 병용 금지 규칙이 지켜졌는가
• 부정 이용이 가능한 설계는 아닌가
• 결제 시스템과의 정합성은 보장되는가
• 장애 발생 시 안전하게 복구할 수 있는가

즉, 중요한 것은 '어떻게 구현했는지'뿐만 아니라, '시스템이 기대대로 작동하는지'입니다.

코드 리뷰 자체가 완전히 불필요해진다고는 할 수 없습니다. 특히 인증/인가(Authentication/Authorization), 결제, 개인정보 처리, 암호 처리, 인프라 설정 등에서는 코드나 설정의 구체적인 검증이 필요한 상황이 남을 것입니다.

반면, 모든 차분(Diff)을 사람이 계속 읽어 내려가는 방식에서, 변경 위험도에 따라 아키텍처, 계약(Contract), 보안, 실행 결과를 검증하는 방식으로의 전환은 충분히 현실적입니다.

Thorsten Ball 씨는 AI가 약 900줄 분량의 Arduino용 C 코드를 생성하여 컴파일 에러 없이 장치 위에서 정상적으로 작동시킨 경험을 소개했습니다.

이 경험으로부터, AI의 구현 정밀도가 더욱 향상된다면 기존 유닛 테스트의 필요성도 저하되지 않을까라는 질문을 던지고 있습니다.

다만, 이 예측에는 신중한 검토가 필요합니다.

예를 들어, 할인 금액을 계산하는 함수가 있다고 가정해 봅시다.

def calculate_discount(price, discount_rate):
return price * discount_rate

이 코드는 구문적으로는 올바르고 정상적으로 실행할 수 있습니다.

하지만 업무 사양이 '할인 후 판매 가격을 반환'하는 것이라면, 구현은 잘못된 것입니다.

정확하게는 다음과 같습니다.

def calculate_discount(price, discount_rate):
return price * (1 - discount_rate)

AI가 고도화되어도 사양이 모호하다면, 틀린 구현을 올바르게 생성해 버릴 가능성이 있습니다.

전통적으로는 함수 단위의 Unit Test(단위 테스트)가 품질 보증의 중심이 되는 경우가 많았습니다.

그러나 AI가 대량으로 구현체를 생성하는 시대에는 다음과 같은 테스트의 중요성이 더욱 높아질 것이라고 생각됩니다.

AI가 코드와 테스트를 동시에 생성할 경우, 둘 다 같은 사양의 오해를 포함하고 있을 가능성에도 주의해야 합니다.

테스트는 단순히 프로그램이 작동하는지 확인하는 것이 아니라, 비즈니스상의 약속을 검증하는 메커니즘이기 때문입니다.

이는 16가지 예측 중에서도 특히 중요한 주장입니다.

Thorsten Ball은 코드를 작성하는 장인 기술의 가치는 희미해지는 반면, 소프트웨어를 구축하는 능력은 그 어느 때보다 중요해질 것이라고 생각합니다.

이 둘은 같은 것이 아닙니다.

코딩(Coding)이란 사양에 기반하여 프로그램을 구현하는 활동입니다.

반면, 소프트웨어 엔지니어링(Software Engineering)에는 훨씬 더 넓은 활동들이 포함됩니다.

비즈니스 과제 발견
↓
요구 정의
...

AI가 구현의 대부분을 담당하게 되더라도, 다음 판단들은 중요합니다.

• 어떤 과제를 해결해야 하는지
• 정말 시스템화가 필요한지
• 어떤 데이터를 관리할 것인지
• 기존 시스템과 어떻게 연동할 것인지
• 언제 출시해야 하는지
• 무엇을 성공으로 판단할 것인지

예를 들어, Laravel로 관리 화면을 만드는 것 자체는 AI에 의해 대폭 빠르게 할 수 있습니다.

하지만 관리 화면에서 구현되어야 할 업무 플로우, 권한 설계, 데이터 무결성(data integrity), 승인 프로세스까지 자동으로 정답이 결정되는 것은 아닙니다.

AI가 '만드는 방법'을 지원할수록, 인간에게는 '무엇을, 왜 만들 것인지'를 판단하는 능력이 요구됩니다.

전통적인 개발에서는 다음과 같은 결함들이 일상적으로 발생해 왔습니다.

• Null 참조(Null reference)
• 타입 불일치(Type mismatch)
• SQL 구문 오류
• 조건 분기 오류
• 메모리 관리 미흡
• API 응답 처리 누락

AI가 진화하면, 이러한 구현상의 실수는 감소할 가능성이 있습니다.

하지만 더 근본적인 문제가 남아있습니다.

그것은 AI에게 무엇을 구현하게 해야 하는지에 대한 요구 자체가 틀린 경우입니다.

AI에게 다음과 같은 지시를 내렸다고 가정해 봅시다.

회원용 쿠폰 기능을 구현해주세요.
쿠폰 코드를 입력하면 10% 할인해주세요.

AI는 단시간에 작동하는 기능을 구현할 수 있을 것입니다.

하지만 이 지시에는 많은 미정 사항이 있습니다.

• 유효 기간은 있는지
• 한 사람당 몇 번까지 사용 가능한지
• 다른 쿠폰과의 중복 사용이 가능한지
• 환불 시 어떻게 처리할 것인지
• 이용 기록을 저장하는지
• 최소 구매 금액 조건은 있는지
• 여러 요청이 동시에 들어오면 어떻게 할 것인지

AI가 지시대로 코드를 생성하더라도, 비즈니스적으로 올바른 시스템이 완성된다고는 할 수 없습니다.

AI 시대에는 모호한 자연어 요구사항을 검증 가능한 사양으로 구체화하는 능력이 중요해집니다.

예를 들어 다음과 같이 기술합니다.

feature: member_coupon
rules:
discount_rate: 0.10
...

※이는 사양 기술의 한 예시이며, 실제로는 유효 기간 정의나 환불 정책 등도 별도로 명확히 할 필요가 있습니다.

이렇게 요구사항을 기계가 검증하기 쉬운 형태로 변환함으로써, AI 에이전트(AI agent)에 의한 구현과 자동 테스트를 연결하기 쉬워집니다.

Thorsten Ball은 자신 역시 터미널이나 개발 도구를 애용하고 있다고 하면서도, 장기적으로는 인간이 셸(shell)이나 CLI(Command Line Interface)를 직접 조작하는 기회는 크게 줄어들 것이라고 예측합니다.

예를 들어, 전통적인 인프라 운영에서는 다음과 같은 명령어를 사용합니다.

docker ps
docker logs --tail 100 app
kubectl get pods
...
이러한 명령어들을 조합하여 엔지니어가 상황을 조사합니다.

하지만 AI 에이전트가 도구를 사용할 수 있게 되면, 자연어 기반의 조작이 가능해집니다.

운영 환경 API 응답 속도가 느려지고 있습니다.
최근 30분간의 메트릭과 로그를 확인하고,
원인 후보들을 우선순위별로 보고해 주세요.
...

AI 에이전트는 허용된 범위 내에서 로그나 메트릭을 수집하고, 조사 결과를 정리할 수 있습니다.

여기서 중요한 것은 CLI 자체의 소멸과 인간이 CLI를 직접 조작하지 않게 되는 것은 별개의 문제라는 점입니다.

AI 에이전트 내부에서는 여전히 셸(Shell), API, 데이터베이스 클라이언트 등이 활용될 가능성이 있습니다.

반면에 운영 권한을 AI에게 부여할 경우에는 또 다른 문제가 발생합니다.

• 오작동 방지 (Misoperation prevention)
• 실행 가능한 명령어 제한 (Restriction of executable commands)
• 프로덕션 변경 승인 (Approval for production changes)
• 기밀 정보 접근 관리 (Access management to confidential information)
• 조작 이력 감사 (Audit of operation history)
• 장애 발생 시 롤백 (Rollback during failure)

AI가 인프라를 조작하게 되더라도, 권한 설계와 운영 통제의 중요성이 사라지는 것은 아닙니다.

오히려 자동화할 수 있는 범위가 넓어질수록, 이러한 중요성은 더욱 높아질 것입니다.

Thorsten Ball은 토큰(Token)을 새로운 계산 패러다임으로 위치시키고 있습니다.

기존 컴퓨팅에서는 CPU, 메모리, 스토리지, 네트워크 대역폭 등이 중심적인 계산 자원이었습니다.

AI 에이전트를 이용하는 시스템에서는 이들 외에도 모델의 추론 능력과 토큰 소비량이 중요한 설계 요소가 됩니다.

사용자
↓
웹 애플리케이션
...

사용자
↓
요구사항 해석
...

전통적으로는 개발자가 처리 흐름(Process Flow)을 명시적으로 구현했습니다.

하지만 AI 에이전트 형태의 시스템에서는 모델이 실행 시점에 처리의 일부를 판단하게 됩니다.

예를 들어, 은행 잔액 업데이트나 재고 할당, 결제 금액 확정 등은 여전히 엄격한 일관성과 재현성이 필요합니다.

AI에 의한 추론을 이용하는 경우에도, 최종적인 상태 변경은 검증 가능하고 결정적인 처리에 맡기는 설계가 합리적입니다.

AI: 사용자의 의도를 이해한다
↓
AI: 필요한 조치를 제안한다
...

AI 추론은 기존 컴퓨팅을 완전히 대체하기보다는, 기존의 계산 기반 위에 새로운 판단 계층(Decision Layer)을 추가하는 것으로 보는 것이 현시점에서는 실무적일 것입니다.

8. PM·디자이너·엔지니어의 분업은 붕괴할까?

전통적인 소프트웨어 개발에서는 주로 다음 역할들로 분업해 왔습니다.

하지만 AI 에이전트가 요구사항 정리, UI 설계, 구현, 테스트까지 담당할 수 있게 되면, 역할의 경계가 모호해집니다.

전통적인 개발 플로우는 다음과 같습니다.

한편, AI를 중심으로 하는 개발에서는 다음과 같은 구성도 고려될 수 있습니다.

이 구성에서는 인간이 각 공정의 작업을 세밀하게 분담할 필요성이 낮아집니다.

한 명의 엔지니어가 여러 전문 에이전트를 활용하면서 프로덕트 개발 전체를 진행할 가능성이 있습니다.

Thorsten Ball은 Agile이나 Scrum과 같은 기존의 개발 프로세스에 대해서도 상당히 부정적인 견해를 보이고 있습니다.

기존의 스크럼(Scrum)은 인간 팀이 일정 기간 동안 개발할 수 있는 작업량을 예측하고 조정하는 것을 전제로 합니다.

하지만 AI로 인해 구현 속도가 극적으로 빨라진다면, 2주 단위의 스프린트나 티켓 관리가 반드시 최적의 방법이 아닐 수도 있습니다.

다만, 개발 속도가 빨라지더라도 이해관계자들과의 합의 형성이나 비즈니스상의 우선순위 지정이 불필요해지는 것은 아닙니다.

변화하는 것은 인간의 구현 작업을 관리하는 프로세스에서, AI를 포함한 시스템의 결과와 품질을 관리하는 프로세스로의 이행이라고 생각됩니다.

Thorsten Ball은 대기업과 소규모 조직 간의 소프트웨어 개발 차이가 앞으로 더욱 커질 것이라고 예측합니다.

대기업에서는 일반적으로 다음과 같은 프로세스가 필요합니다.

• 여러 부서와의 조정 (Coordination with multiple departments)
• 보안 검토 (Security review)
• 승인 프로세스 (Approval process)
• 시스템 간 의존성 관리 (Management of inter-system dependencies)
• 규정 준수 대응 (Compliance response)
• 기존 시스템과의 호환성 유지 (Maintenance of compatibility with existing systems)

반면, 소규모 팀에서는 AI 에이전트를 활용함으로써 적은 인원으로도 큰 개발 성과를 낼 수 있는 가능성이 있습니다.

예를 들어, 기존에는 프론트엔드, 백엔드, 인프라, QA 담당자가 필요했던 프로젝트라도, AI를 활용할 수 있는 엔지니어가 여러 영역을 가로질러 개발할 수 있게 될 수도 있습니다.
AI에 의해 코드 생성 비용이 낮아진다면, 개발의 병목 지점(bottleneck)은 다른 곳으로 이동하게 됩니다.

기존의 병목 지점
↓
구현 공수・개발자 인원
...

이러한 변화는 소규모 개발 팀에게 큰 기회가 될 것입니다.

다만, 대기업의 프로세스를 단순히 줄이면 된다는 이야기는 아닙니다. 시스템의 영향 범위나 리스크에 따라 필요한 통제(control)를 유지하는 것이 중요합니다.

지금까지의 소프트웨어 개발에서는 읽기 쉽고 유지보수하기 쉬운 코드가 높이 평가되어 왔습니다.

예를 들어, 다음과 같은 원칙들이 있습니다.

• DRY (Don't Repeat Yourself)
• KISS (Keep It Simple, Stupid)
• SOLID 원칙
• Clean Architecture
• 코딩 규약 통일
• 적절한 명명 규칙(naming)
• 일관성 있는 코드 포맷터

이러한 것들 대부분은 인간이 코드를 이해하고 수정하며 유지보수하는 것을 전제로 합니다.

하지만, 장래에 코드의 대부분을 AI가 생성하고 변경하게 될 경우, 인간의 가독성이 최우선 평가 기준이 계속될 것이라고 단정할 수는 없습니다.
예를 들어, 다음과 같은 평가 축(evaluation axis)이 고려될 수 있습니다.

가독성이 좋은 코드는 인간만을 위한 것이 아닙니다. 명확한 모듈 경계, 단순한 제어 흐름(control flow), 적절한 타입 정의 등은 AI가 코드를 분석하고 변경할 때에도 도움이 될 수 있습니다.

따라서 '좋은 코드'의 기준이 완전히 사라지는 것이 아니라, 인간 중심의 유지보수성에서 인간과 AI 모두가 안전하게 수정할 수 있는 구조로 평가 축이 확장될 것이라고 생각하는 것이 타당합니다.

오픈 소스 소프트웨어(OSS)는 많은 개발자가 코드를 공개하고 개선하며 공동으로 유지보수하는 문화에 의해 발전해 왔습니다.
하지만, AI 에이전트에 의해 코드를 대량으로 생성할 수 있게 되면, 기존의 기여 모델(contribution model)이 변화할 가능성이 있습니다.

예를 들어, 다음과 같은 변화가 고려될 수 있습니다.

• AI에 의한 Pull Request 대량 생성
• AI에 의한 취약점 조사
• 자동적인 의존 라이브러리 업데이트
• 프로젝트 고유 기능 추가
• AI에 의한 코드 리뷰
• AI를 활용한 문서 정비

AI가 코드를 생성할 수 있어도, 그것만으로 OSS 프로젝트가 성립되는 것은 아닙니다.
여전히 다음과 같은 문제가 존재합니다.

• 누가 유지보수 책임을 질 것인가
• 취약점이 발견되었을 때, 누가 대응할 것인가
• 라이선스 조건을 어떻게 지킬 것인가
• 의존 라이브러리의 신뢰성을 어떻게 확보할 것인가
• AI가 생성한 대량의 변경 사항을 어떻게 관리할 것인가

AI 시대의 OSS에서는 코드를 작성하는 기여 외에도, 사양 정의(specification definition), 호환성 유지(compatibility maintenance), 품질 보증(quality assurance), 신뢰할 수 있는 배포 기반의 가치가 높아질 가능성이 있습니다.

전통적으로 성능 최적화(performance optimization)는 경험이 풍부한 엔지니어의 전문 영역이었습니다.
예를 들어, 웹 시스템의 응답 속도가 느린 경우, 다음과 같은 조사를 수행합니다.

EXPLAIN
SELECT *
FROM orders
...

실행 계획을 확인하고, 필요에 따라 인덱스를 추가합니다.

CREATE INDEX idx_orders_user_created
ON orders (user_id, created_at);

※실제로는 기존 인덱스, 데이터 분포, 업데이트 부하, 락(lock), 실행 계획 등을 확인하여 판단해야 합니다.

이러한 조사에 대해서도, AI 에이전트가 메트릭스나 쿼리의 실행 계획을 분석하고 개선안을 제시할 수 있게 되었습니다.
장래에는 부하 테스트(load testing), 실행 계획 비교, 개선안 구현까지 자동화가 진행될 것입니다.

다만, Thorsten Ball 씨가 지적하는 중요한 점은 모든 소프트웨어가 최고 수준의 성능을 필요로 하는 것은 아니라는 것입니다.
사용자가 적은 시스템에서 극단적인 최적화에 시간을 들여도 비즈니스 가치로 이어지지는 않습니다.
중요한 것은 최적화 그 자체가 아니라, 필요한 성능을 적절한 비용으로 구현하는 것입니다.

AI 에이전트 중심의 개발에서는 모델의 성능뿐만 아니라, 얼마나 많은 추론 처리(Inference processing)를 활용할 수 있는지도 중요해집니다.

Thorsten Ball 씨는 충분한 토큰을 사용할 수 없는 개발자나 조직은 경쟁에서 불리할 가능성이 있다고 지적합니다. 이는 과거에 컴퓨터를 소유할 수 있는 사람과 그렇지 못한 사람 사이에 존재했던 격차와 유사합니다.

AI 에이전트를 활용하여 개발하는 경우, 예를 들어 다음과 같은 비용이 발생합니다.

AI 개발 비용
├── 입력 토큰(Input token)
├── 출력 토큰(Output token)
...

하지만 단순히 토큰량만으로 생산성이 결정되는 것은 아닙니다. 프롬프트 설계, 컨텍스트 관리(Context management), 도구 연동(Tool linking), 테스트 환경, 모델 선정에 따라 동일한 처리라도 비용이나 성공률이 크게 달라집니다.

예를 들어, 다음과 같은 가상의 사례를 생각해 봅시다.

단순히 API 요금만 비교하면 Model A가 저렴합니다. 그러나 실패로 인해 사람이 확인하는 공수가 늘어나거나, 잘못된 코드 수정이 필요해지면 총비용은 변화합니다.

위의 계산은 각 시도의 성공률이 일정하고 독립적이며, 성공할 때까지 재시도한다는 단순화된 모델입니다. 실제 업무에서는 다음과 같은 지표를 조합하여 평가하는 것이 좋습니다.

총 비용 = API 이용료 + 도구 실행 비용 + 검증 비용 + 실패 시 수정 비용

단가뿐만 아니라 태스크 완료율과 총비용으로 모델을 평가하는 것이 중요합니다.

Thorsten Ball 씨의 예측 중 특히 흥미로운 부분은 UI의 변화입니다. 현재 웹 애플리케이션에서는 개발자가 사전에 화면을 설계합니다. 예를 들어, 매출 분석 시스템에는 다음과 같은 UI가 준비됩니다.

• 날짜 범위 필터
• 매장 선택
• 매출 그래프
• CSV 다운로드
• 정렬 기능
• 각종 설정 화면

하지만 AI가 사용자의 목적을 이해할 수 있다면, 모든 UI를 사전에 설계할 필요는 없을 수도 있습니다.

사용자
↓
매출 분석 화면 열기
...

사용자가 다음과 같이 지시합니다.

지난달과 이번 달의 매장별 매출을 비교하여,
매출이 크게 감소한 매장을
그래프로 표시해 주세요.

AI는 요구사항을 이해하고 필요한 데이터를 가져와, 그 목적에 맞는 UI를 생성합니다. 예를 들어 React를 사용한 시스템이라면, AI에게 임의의 HTML이나 JavaScript를 직접 실행시키기보다는 정의된 컴포넌트의 구성 데이터(JSON)를 생성하도록 하는 방법이 고려될 수 있습니다.

{
"type": "dashboard",
"title": "매장별 매출 비교",
...
}

이 JSON은 AI가 화면 구조를 지정하기 위한 예시입니다. 실제로는 JSON Schema 등을 통한 검증, 승인된 데이터 소스에 대한 접근 제한, 컴포넌트의 화이트리스트화가 필요합니다.

동적 UI는 큰 잠재력을 가지고 있지만, 모든 상황에 적합한 것은 아닙니다. 예를 들어 결제 확인, 본인 인증, 중요한 설정 변경 등에서는 매번 동일한 UI가 표시되는 것에서 오는 안정감이나 조작의 재현성이 중요합니다.

또한 접근성(Accessibility), 조작의 일관성, 감사 가능성(Auditability) 등도 고려해야 합니다. 따라서 장기적으로는 다음과 같은 사용처 분리가 예상됩니다.

• 정형 업무: 고정 UI
• 데이터 분석: 동적 UI
• 탐색적인 작업: 자연어 인터페이스(NLI)
• 중요한 승인 작업: 검증된 고정 UI

Thorsten Ball 씨는 이러한 변화가 하룻밤 사이에 실현되는 것은 아니라는 점도 인정합니다. 기존 소프트웨어가 새로운 소프트웨어로 대체되기 위해서는 세대 단위의 시간이 필요하다는 관점입니다.

이는 실제 시스템 개발을 고려할 때 중요한 지적입니다. 기업에는 현재에도 다양한 기술로 구축된 시스템이 남아 있습니다.

• 레거시 PHP(Legacy PHP)
• Java 업무 시스템
• ASP / ASP.NET
• COBOL
• 오래된 ERP
• 독자 프레임워크

이러한 시스템들은 기술적으로 오래되었다는 이유만으로 쉽게 대체될 수 없습니다. 업무 프로세스, 데이터, 외부 연동, 마이그레이션 비용 등의 제약이 존재하기 때문입니다.

기존 시스템을 전면적으로 AI 네이티브 구조로 전환하는 것이 아니라, 단계적으로 도입하는 방법이 현실적입니다.

기존 시스템
↓
API 및 데이터 접근 정리
...

이는 기존 시스템을 유지하면서 AI의 능력을 활용할 수 있는 접근 방식입니다.

중요한 것은, AI 시대라고 해서 기존 시스템을 전부 다시 만들 필요는 없다는 점입니다.

지금까지의 예측을 정리하면, 앞으로 엔지니어에게 요구되는 역량이 보입니다.

코드가 어떻게 작동하는지 이해하고 있지 않으면, AI가 생성한 시스템의 문제점을 평가하기 어려워집니다.

다만, 구현 능력만으로 다른 엔지니어와 차별화를 두는 것은 앞으로 더욱 어려워질 것입니다.

AI 에이전트(Agent)를 활용하는 엔지니어의 역할은 다음과 같이 변화할 수 있습니다.

단순히 AI에게 프롬프트(Prompt)를 전송할 수만으로는 충분하지 않습니다.

AI가 생성한 결과물을 평가하고, 실패했을 때 원인을 분리하며, 적절한 제약 조건을 설계하는 능력이 요구됩니다.

지금까지의 예측은 매우 대담하지만, 모든 것이 실현될 것을 전제로 개발 프로세스를 변경하는 것은 위험합니다.

중요한 것은 이미 상용화할 수 있는 기술과 아직 검증이 필요한 미래 예측을 구분하는 것입니다.

현재 시점에서 착수할 가치가 높은 방안들을 정리합니다.

모호한 사양서뿐만 아니라, 인수 조건(Acceptance Criteria), 입력/출력, 제약 조건, 에러 조건을 명확히 합니다.

특히, 업무 규칙을 테스트 가능한 형태로 기술하는 것이 중요합니다.

AI 에이전트가 안전하게 코드를 생성하고 검증할 수 있는 환경을 마련합니다.

예를 들어 다음과 같은 환경입니다.

Git Repository
↓
AI Coding Agent
...

사람이 모든 줄을 리뷰할 수 없을 때라도, 검증 가능한 프로세스를 유지하는 것이 중요합니다.

AI가 조작 가능한 범위를 명확하게 분리합니다.

예를 들어, 운영(Production) DB의 참조 권한과 업데이트 권한을 나누고, 파괴적인 변경에는 인간의 승인을 필요로 합니다.

AI를 이용할 때도 최소 권한의 원칙(Principle of Least Privilege)은 변하지 않습니다.

AI 도입 효과를 생성 코드량이나 프롬프트 횟수만으로 평가해서는 안 됩니다.

중요한 것은 실제 개발 성과입니다.

예를 들어 다음과 같은 지표가 생각해 볼 수 있습니다.

처음부터 운영 시스템 전체를 AI가 조작하게 할 필요는 없습니다.

예를 들어 다음과 같은 작업부터 시작하는 것이 현실적입니다.

• 로그 분석이나 SQL 조사 지원
• 테스트 코드나 문서 생성
• 기존 기능의 리팩토링(Refactoring)
• 모니터링 알림의 1차 분석
• 스테이징 환경에서의 한정적인 자동 수정

이러한 소규모 도입으로 정확도, 비용, 위험을 확인하고 적용 범위를 넓혀가는 방법이 합리적입니다.

Thorsten Ball 씨의 예측은 현재 개발 문화에 대한 매우 대담한 문제 제기입니다.

특히 주목해야 할 것은 코드 리뷰나 터미널이 정말 사라지는가 여부가 아닙니다.

소프트웨어 개발의 가치가 코드를 생산하는 것에서, 올바른 시스템을 구축하는 것으로 더욱 이동한다는 시점입니다.

AI로 인해 구현 비용이 저하되면서, 지금까지 간과되어 왔던 과제들이 중요해집니다.

• 무엇을 만들어야 하는가
• 요구사항은 정말 올바른가
• 시스템은 안전하게 작동하는가
• 비즈니스상의 가치를 제공할 수 있는가
• AI가 만든 결과물을 어떻게 검증할 것인가
• 어디까지 자동화하고, 어느 곳에 인간의 판단을 남길 것인가

이러한 문제들은 프로그래밍 언어나 프레임워크만으로는 해결할 수 없는 문제입니다.

앞으로 소프트웨어 엔지니어에게 중요한 것은 코드를 작성하는 속도뿐만 아니라, AI를 적절히 활용하여 신뢰할 수 있는 시스템을 설계·구축·운영하는 능력이 될 것입니다.

물론 미래가 원문의 예측대로 될 것이라고 단정할 수는 없습니다.

하지만, AI로 인해 구현 방식과 개발 프로세스가 변화하고 있는 이상, 지금까지의 개발 상식을 주기적으로 재검토할 필요가 있다는 것은 확실합니다.

앞으로 엔지니어에게 요구되는 것은 '얼마나 코드를 많이 쓸 수 있느냐'뿐만 아니라, 'AI를 사용해서 얼마나 가치 있는 소프트웨어를 만들어낼 수 있느냐'라고 생각합니다.

• Thorsten Ball — What I believe about the future of software development (2026년 9월 19일)
• Thorsten Ball의 X 게시물
• Thorsten Ball 공식 웹사이트
• Amp — AI 코딩 에이전트

본 기사는 Thorsten Ball 씨가 공개한 미래 예측을 바탕으로 소프트웨어 개발 실무에 미치는 영향을 고찰한 것입니다. 원문의 예측과 필자의 해석이 반드시 일치하는 것은 아니며, 미래 기술 동향을 보장하는 것이 아닙니다.