Appendix 04. 소프트웨어의 위기와 AI 코딩

윤희빈·2026년 7월 23일

1. 요구사항과 결과물의 차이

소프트웨어 개발에서 가장 큰 문제는 요구사항이 정확히 프로그램으로 이어지지 않는 것이다.

  • 고객이 설명한 것
  • 프로젝트 리더가 이해한 것
  • 분석가가 설계한 것
  • 프로그래머가 구현한 것
  • 비즈니스 컨설턴트가 설명한 것
  • 실제 설치된 것
  • 고객이 진짜 원했던 것

즉, 같은 요구사항이라도 사람마다 다르게 이해하고, 결과물은 더 달라질 수 있다.


2. 요구사항은 프로그램 그 자체가 아니다

  • 프로그램: 컴퓨터에게 “명확하게” 지시사항을 명세한 것
  • 요구사항: 어떤 프로그램이 만들어져야 하는지에 대한 명세
  • 흐름이 반복되면서
    • 요구사항 → 프로그램
    • 요구사항’ → 프로그램’’
    • …
    • 요구사항n → 쓰레기
      같은 식으로 요구가 바뀌고 산출물이 누적되면 감당이 어려워짐

3. 바이브코딩의 문제점

바이브코딩은 요구사항을 대략 설명하고 AI에게 코드를 만들게 하는 방식이다.

하지만 다음과 같은 문제가 생긴다.

  • 무엇으로 짜여 있는지 모른다.
  • 어떻게 짜여 있는지 모른다.
  • 제대로 검증했는지 모른다.
  • 나중에 확장할 수 있는지 모른다.
  • 런타임 오류가 나면 고칠 수 있는지 모른다.

즉, 처음에는 결과가 빨리 나오는 것처럼 보이지만 나중에는 유지보수와 확장이 어려워진다.

복잡성(complexity)이란 소프트웨어 시스템의 구조와 관련된 것들 중, 그 시스템을 이해하고 수정하는 일을 어렵게 만드는 모든 것이다.”


4. 토큰을 더 쓰는 것으로 해결되지 않는다

AI가 잘못된 결과를 만들었을 때 단순히 토큰을 더 쓰거나 다시 시키는 방식은 근본적인 해결책이 아니다.

  • 중간에 하네스(harness) 등 추가 비용 발생
  • 중복이 늘면
    • 일관성 유지
    • 병행처리 안전성
      이 악몽이 됨(품질/유지보수 난이도 급증)

5. 중복 코드와 일관성 문제

AI가 만든 코드는 중복이 많아질 수 있다.

중복이 많아지면 다음 문제가 생긴다.

  • 코드 일관성 유지가 어려움
  • 병행 처리에서 안전성 문제 발생
  • 수정 시 여러 곳을 동시에 고쳐야 함
  • 버그 발생 가능성 증가

그래서 단순히 “작동하는 코드”보다

좋은 코드베이스가 더 중요하다.


6. 코딩은 싸졌지만 좋은 코드베이스는 더 중요해졌다

강의 핵심 문장:

코딩은 싸졌다?

코드는 싸졌다 X

좋은 코드베이스는 더 가치가 높아졌다 O

AI 때문에 코드를 생성하는 비용은 낮아졌다.

하지만 좋은 구조, 유지보수성, 확장성, 일관성을 가진 코드베이스의 가치는 오히려 더 높아졌다.


7. AI 코딩 시대에도 소프트웨어공학이 필요한 이유

AI가 코드를 만들어줄 수 있어도 다음 요소들은 여전히 중요하다.

  • 요구사항 분석
  • 설계
  • 모듈화
  • 인터페이스 정의
  • 결합도와 응집도 관리
  • 객체지향 설계 원리
  • 아키텍처 패턴
  • 테스트와 검증
  • 유지보수 가능성

AI는 코드를 생성할 수 있지만,

전체 구조를 책임지고 판단하는 것은 개발자의 역할이다.


8. 결합도와 응집도

좋은 소프트웨어 설계를 위해서는 다음을 고려해야 한다.

결합도

모듈끼리 얼마나 강하게 연결되어 있는지를 의미한다.

  • 결합도가 높으면 한 부분을 수정할 때 다른 부분도 영향을 받는다.
  • 결합도가 낮을수록 유지보수가 쉽다.

응집도

하나의 모듈이 하나의 책임에 얼마나 집중하는지를 의미한다.

  • 응집도가 높으면 모듈의 역할이 명확하다.
  • 응집도가 낮으면 모듈이 여러 일을 섞어서 하게 된다.

좋은 설계는

낮은 결합도 + 높은 응집도를 목표로 한다.


9. “만들어줘”만 반복하면 안 되는 이유

AI에게 단순히 “만들어줘”라고만 하면

처음에는 결과가 나올 수 있다.


하지만 구조 없이 계속 기능을 추가하면 다음 문제가 생긴다.

  • 코드가 점점 복잡해짐
  • 기능 간 의존성이 꼬임
  • 수정하기 어려워짐
  • 전체 아키텍처가 무너짐
  • 나중에 리팩토링 비용이 커짐

따라서 AI에게 코딩을 맡기더라도 먼저 구조와 설계 원칙을 정해야 한다.

10. AI 코딩의 원칙

AI 코딩을 할 때는 다음 원칙이 필요하다.

1) 작은 단위로 시키기

한 번에 전체 시스템을 만들게 하지 말고

작은 기능 단위로 나누어 요청해야 한다.

2) 도메인 언어를 명확히 하기

프로젝트에서 사용하는 용어를 명확히 해야 한다.

예를 들어 DDD에서는 Ubiquitous Language가 중요하다.

이는 개발자와 사용자, 기획자가 같은 용어를 사용하도록 하는 것이다.

3) 설계 문서를 먼저 만들기

AI에게 바로 코딩을 시키기보다 다음을 먼저 정리해야 한다.

  • 요구사항
  • 유스케이스 다이어그램
  • UML
  • 인터페이스
  • 모듈 구조
  • 데이터 흐름

4) AI가 너무 많은 일을 하지 않게 하기

AI에게 모든 것을 한 번에 맡기면

개발자가 구조를 이해하지 못하게 된다.

결국 AI가 만든 코드를 사람이 통제하지 못하는 상황이 생긴다.


11. 너무 급하게 개발하면 생기는 문제

강의에서는 “너무 급해”라는 표현이 나온다.

이는 빠르게 결과물을 만들려는 태도가

오히려 장기적으로 문제를 만든다는 의미이다.

특히 한국식 개발 문화에서는

선행 작업보다 빠른 구현을 우선하는 경향이 있다.

하지만 요구사항 분석과 설계를 건너뛰면

나중에 더 큰 비용을 치르게 된다.


12. Efficiency와 Effectiveness

Peter Drucker의 말:

Efficiency is doing things right.

Effectiveness is doing the right things.

Efficiency

일을 효율적으로 하는 것

즉, 빠르고 적은 비용으로 수행하는 것.

Effectiveness

올바른 일을 하는 것

즉, 진짜 필요한 문제를 해결하는 것.

AI 코딩은 효율성은 높일 수 있다.

하지만 올바른 방향으로 개발하고 있는지는 사람이 판단해야 한다.


13. 인간 컴파일러 vs 전략적 엔지니어

AI 시대에 개발자는 단순히 코드를 읽고 수정하는

“인간 컴파일러”가 되어서는 안 된다.

필요한 것은 전략적 엔지니어이다.

전략적 엔지니어는 다음을 이해해야 한다.

  • 전체 시스템 구조
  • 요구사항의 의도
  • 기술 선택의 이유
  • 유지보수 가능성
  • 조직과 개발 프로세스
  • 장기적인 확장 방향

14. 계산기가 계산한다고 수학을 몰라도 되는가?

강의에서는 다음 질문이 나온다.

계산기가 계산하는데, 코딩의 자세한 면을 알아야 하나요?

프롬프팅만 잘하면 그만이지 않나요?

이에 대한 답은 “아니다”이다.

계산기가 있어도 수학적 개념을 알아야 하듯이,

AI가 코딩해도 개발자는 코드와 구조를 이해해야 한다.

프롬프트만 잘 쓰는 것으로는

복잡한 소프트웨어를 안정적으로 만들 수 없다.


15. Code Monkey vs Strategic Engineer

AI에게 풀스택 개발 경험을 모두 위임하면

개발자는 코드 작성 경험을 잃게 될 수 있다.

그러면 단기적으로는 효율적일 수 있지만

장기적으로는 전략적 엔지니어링 능력이 약해진다.

결국 개발 조직 자체가 흔들릴 수 있다.


16. 최종 핵심 정리

AI 코딩 시대의 핵심은

“AI가 코드를 짜주니까 개발자가 필요 없다”가 아니다.

오히려 개발자는 더 깊고 넓은 지식을 가져야 한다.

중요한 것은 다음과 같다.

  • 지금 당장 돌아가는 코드만 보지 말 것
  • 미래의 유지보수와 확장을 고려할 것
  • 요구사항을 명확히 할 것
  • 구조와 설계를 먼저 잡을 것
  • AI가 만든 코드를 이해하고 검증할 것
  • 좋은 코드베이스를 만드는 능력을 기를 것

결론적으로,

AI는 개발을 도와주는 도구이지만

좋은 소프트웨어를 만드는 책임은 여전히 개발자에게 있다.


Structured Prompt-Driven Development, SPDD

SPDD란?

SPDD는 Structured Prompt-Driven Development의 약자로, 구조화된 프롬프트 기반 개발을 의미한다.

AI에게 단순히 “코드 짜줘”라고 요청하는 것이 아니라, 요구사항과 분석 내용을 먼저 정리하고, 이를 바탕으로 구조화된 프롬프트를 만들어 코드를 생성하는 개발 방식이다.

즉, SPDD는 AI 코딩을 즉흥적인 바이브코딩이 아니라 체계적인 소프트웨어 개발 프로세스 안에서 활용하는 방법이다.


SPDD의 기본 흐름

  1. 초기 요구사항을 작성한다.
  2. 요구사항을 분석하고 명확히 한다.
  3. AI가 이해할 수 있는 분석 맥락을 만든다.
  4. 구조화된 프롬프트를 작성한다.
  5. 프롬프트를 기반으로 코드를 생성한다.
  6. 생성된 코드에 대한 단위 테스트를 만든다.
  7. 결과물을 검토하고 반복적으로 개선한다.

바이브코딩과의 차이

바이브코딩

요구사항을 대략 설명하고 AI에게 바로 코드를 생성하게 하는 방식이다.

빠르게 결과를 얻을 수 있지만, 요구사항이 불명확하거나 구조가 부족하면 유지보수와 확장이 어려워질 수 있다.

SPDD

요구사항, 분석, 설계, 프롬프트를 구조화한 뒤 AI를 활용하는 방식이다.

초반에는 시간이 더 걸리지만, 코드의 일관성, 추적 가능성, 테스트 가능성, 유지보수성이 높아진다.


핵심 정리

SPDD는 AI에게 코드를 대신 쓰게 하는 기술이 아니라, AI가 따라야 할 요구사항과 설계 기준을 명확히 만들어주는 개발 방식이다.

따라서 AI 코딩 시대에도 요구사항 분석, 설계, 테스트, 검토 같은 소프트웨어공학 지식이 여전히 중요하다.


바이브코딩과 실제 서비스 운영의 차이

핵심 메시지

AI 코딩 도구를 사용하면 빠르게 앱의 초기 형태, 즉 MVP를 만들 수 있다.

하지만 MVP가 만들어졌다고 해서 실제 운영 가능한 서비스가 완성된 것은 아니다.

실제 서비스에는 코드 작성 외에도 보안, 테스트, 배포, 로그, 장애 대응, 확장성, 데이터 무결성, 권한 관리, 비용 관리 등 많은 요소가 필요하다.


1. AI-generated code의 문제

CodeRabbit 분석에 따르면 AI-generated code는 다음과 같은 문제를 더 많이 유발할 수 있다.

  • 더 많은 버그
  • 더 많은 critical issue
  • 더 많은 logic error
  • 더 많은 security vulnerability

AI가 코드를 많이 생성할수록 사람이 직접 리뷰해야 할 코드도 많아진다.

하지만 생성되는 코드의 양이 사람이 현실적으로 리뷰할 수 있는 속도보다 빠르게 증가하면 품질 관리가 어려워진다.

따라서 AI가 만든 코드를 다시 AI에게만 리뷰시키는 방식이 항상 안전한지는 의문이다.


2. “일단 만들고 나중에 확인”의 위험성

바이브코딩은 종종 “일단 앱을 만들어줘. 나중에 확인할게.”라는 방식으로 진행된다.

이 방식은 초기 결과물을 빠르게 얻을 수 있다는 장점이 있지만, 다음과 같은 위험이 있다.

  • 요구사항 반영 여부를 확인하기 어렵다.
  • 예외 처리가 부족할 수 있다.
  • 보안 취약점이 숨어 있을 수 있다.
  • 테스트가 충분하지 않을 수 있다.
  • 운영 환경에서 장애가 발생할 수 있다.
  • 유지보수와 확장이 어려울 수 있다.

즉, 빠르게 만든 코드가 반드시 좋은 코드나 운영 가능한 코드를 의미하지는 않는다.


3. 완료된 것처럼 보여도 숨은 작업이 많다

개발 업무는 겉으로 보기에는 완료된 것처럼 보여도, 실제로는 많은 숨은 작업이 존재한다.

예를 들어 다음과 같은 일이 남아 있을 수 있다.

  • 심각한 버그 수정
  • 전체 재테스트
  • 요구사항 재확인
  • 디버깅
  • 문서 수정
  • 피드백 대기
  • 다른 부서와의 협업 지연

따라서 관리자는 단순히 “다 끝났나요?”라고 묻는 것보다

“어디에서 막혔나요?”, “협업 과정에서 병목이 있나요?”라고 물어야 한다.


4. 바이브코더가 생각하는 풀스택과 실제 풀스택

바이브코더는 풀스택을 단순히 프론트엔드와 백엔드 정도로 생각할 수 있다.

하지만 실제 운영 환경의 풀스택은 훨씬 복잡하다.

실제 서비스에는 다음 요소들이 필요하다.

  • Frontend
  • API와 backend logic
  • Database와 storage
  • Authentication과 permissions
  • Hosting과 deployment 등등..

즉, 실제 풀스택 개발은 단순히 화면과 서버를 만드는 것이 아니라,

서비스가 안정적으로 운영될 수 있도록 전체 시스템을 설계하고 관리하는 것이다.


5. MVP와 Production Ready의 차이

AI 코딩으로 빠르게 만든 앱은 MVP 수준일 수 있다.

MVP는 아이디어를 검증하기 위한 최소 기능 제품이다.

반면 Production Ready 앱은 실제 사용자에게 안정적으로 제공할 수 있는 운영 가능한 서비스이다.

Production Ready 앱에는 다음과 같은 요소가 필요하다.

  • 인증과 권한 관리
  • 결제와 구독 상태 관리
  • 데이터 무결성
  • 보안
  • 확장성
  • 성능 최적화 등등

따라서 MVP를 만드는 것과 Production Ready 서비스를 만드는 것은 완전히 다른 수준의 작업이다.


핵심 정리

바이브코딩은 빠르게 결과물을 만드는 데에는 유용하다.

하지만 실제 서비스 운영에는 보이지 않는 복잡한 요소들이 많다.

AI가 코드를 생성해도 개발자는 다음을 판단해야 한다.

  • 요구사항이 제대로 반영되었는가?
  • 코드가 안전한가?
  • 테스트가 충분한가?
  • 배포 가능한가?
  • 장애 상황에 대응할 수 있는가?
  • 유지보수와 확장이 가능한가?

결론적으로 AI 코딩은 개발을 빠르게 도와주는 도구이지만,

좋은 소프트웨어를 만들기 위해서는 여전히 소프트웨어공학적 사고와 운영 관점이 필요하다.

profile
비니비니히비니의 정리블로그

0개의 댓글