정통 소프트웨어 개발 방식은 죽었다?

Boris Tane

 

AI 코딩 에이전트 시대의 “의도(Intent)–실행(Build)–관측(Observe)” 루프로 재편되는 개발 방식

Boris Tane는 2026년 2월 20일 공개한 글에서 **“AI 에이전트는 SDLC를 빠르게 만든 게 아니라, SDLC 자체를 ‘붕괴’시켰다”**고 주장합니다. 
핵심은 “단계별로 나눠진 개발 파이프라인”이 아니라, 한 덩어리의 짧은 반복 루프로 개발이 바뀐다는 관점입니다. 

아래는 원문의 논지를 단계별로 “왜 무너지는지 / 무엇이 남는지 / 실무에서 어떻게 대비할지”까지 자세히 정리한 글입니다.

---

빠른 요약

• 전통 SDLC는 “요구사항 → 설계 → 구현 → 테스트 → 코드리뷰 → 배포 → 모니터링”처럼 **단계/도구/의식(ritual)**이 분리된 흐름입니다. (SDLC 자체는 원래 소프트웨어를 구축·전달·유지하기 위한 구조화된 방법론으로 설명됩니다.)
• 하지만 코딩 에이전트와 일하면 많은 단계가 “빨라지는 게 아니라 합쳐진다”: 의도를 말하면 에이전트가 코드·테스트·배포까지 묶어 만들고, “되나?”를 확인하며 반복합니다. 
• 그 결과, 남는 승부처는 딱 두 가지:
  • 컨텍스트(맥락) 품질: 에이전트에게 “무엇을/왜/어떤 제약으로” 만들지 제대로 먹이는 능력(원문은 이를 “context engineering”으로 강조) 
  • 관측가능성(Observability): 사람이 리뷰/QA로 방어하던 걸 흡수해버리니, 운영에서 “이상 징후를 감지하고 되돌리는” 시스템이 안전망이 됨 

---

1) 우리가 배운 SDLC는 “공장 라인”이었다

SDLC(Software Development Life Cycle)는 본래 소프트웨어를 고품질로 만들기 위해 계획된 활동의 연속으로 설명됩니다. (IBM)
실무에서 많은 팀은 이를 다음처럼 “공정 라인”으로 운영해왔죠:

• 요구사항(티켓/PRD)
• 설계(아키텍처/UX)
• 구현(코드 작성)
• 테스트(QA/자동화)
• 코드리뷰(PR)
• 배포(CI/CD)
• 모니터링(대시보드/알림)

Boris Tane는 이 구조가 각 단계마다 도구와 의식이 따로 존재하고, 핸드오프(넘겨받기)와 대기열이 발생하는 방식이라고 짚습니다. 

---

2) 그런데 에이전트와 일하면 “라인”이 아니라 “주문–조리–시식–조정”이 된다

원문이 말하는 변화는 이겁니다:

• 전통 SDLC: 단계가 존재하고, 사람과 도구가 그 단계를 “통과”시킨다.
• 에이전트 개발: 단계가 아니라 **의도(의사) + 컨텍스트 + 반복(iteration)**만 남는다.

즉, “요구사항 작성 → 설계 문서 → 구현 → 테스트 작성 → PR 올림 → 리뷰 대기…” 같은 직렬 작업이 아니라,

의도 전달 → 에이전트가 코드/테스트/배포까지 생성 → 동작 확인 → 수정/반복 → 출시

이렇게 압축된 루프로 바뀐다고 주장합니다.

---

3) “AI 네이티브 엔지니어”는 SDLC를 모른다?

원문에서 가장 도발적인 대목 중 하나가 이 주장입니다.
저자는 “Cursor 같은 도구가 나온 이후 커리어를 시작한 엔지니어들”을 예로 들며, 그들이 스프린트 플래닝/스토리포인트/PR 리뷰 대기 같은 의식을 겪지 않고 바로 빌드한다고 말합니다.

여기서 포인트는 “요즘 엔지니어가 게으르다”가 아니라,
도구가 바뀌면 ‘당연하던 절차’ 자체가 학습되지 않을 수도 있다는 경고에 가깝습니다.

---

4) 단계별로 무엇이 어떻게 “붕괴”하는가 

4.1 요구사항: “동결된 스펙”이 아니라 “반복의 부산물”

예전엔 “먼저 PRD를 확정하고 → 그걸 구현”하는 흐름이 합리적이었습니다. 기능 하나에 몇 주가 걸리면, 앞단에서 결정 비용을 치러야 했으니까요. 

하지만 에이전트가 몇 분 만에 프로토타입을 만들 수 있다면, 요구사항은 미리 고정하는 문서라기보다:

• 방향만 준 뒤
• 여러 버전을 빠르게 만들어 보고
• “이게 더 낫네”를 고르면서
• 요구사항이 뒤에서 형태를 갖추는

그리고 이때 Jira 같은 티켓 시스템은 “단계를 추적하는 도구”가 아니라, 에이전트가 먹을 컨텍스트 저장소로 성격이 변하는데, 저자는 “그 용도로는 형편없다”고까지 말합니다. 

---

4.2 설계: “선언”이 아니라 “발견”

설계는 여전히 중요하지만, 코드 작성 전의 별도 단계가 아니라
에이전트와 대화하며 실시간으로 아키텍처를 탐색/수정하는 쪽으로 이동한다고 봅니다.

핵심은 “사람이 박스/화살표를 확정해 전달”이 아니라,

• 제약 조건과 목표를 제공하고
• 에이전트가 제안을 내고
• 사람이 과설계/제약 누락을 감지하며
• 설계와 구현이 동시에 진화

---

4.3 구현: “사람이 타이핑”에서 “사람이 조종”으로

원문은 구현 단계에 대해 아주 직설적입니다: **“이제 구현은 에이전트의 일”**이고, 사람은 코드를 직접 치기보다 검토/맥락 제공/방향 조정/판단이 필요한 문제에 집중한다고 말합니다.

(이건 팀/도메인/규제 환경에 따라 속도 차이는 있겠지만, ‘중심 역할이 이동한다’는 메시지는 강합니다.)

---

4.4 테스트: “나중에 붙이는 것”이 아니라 “생성과 동시에”

에이전트는 코드와 테스트를 동시에 생성합니다. 그래서 테스트가 별도 단계가 아니라 생성 과정의 일부가 되고, “QA로 던져서 검증” 같은 핸드오프가 약해진다고 주장합니다. 

---

4.5 코드리뷰(PR): “성스러운 의식”이 아니라 “가짜 병목”

저자는 PR 기반 코드리뷰 흐름을 “이제는 버려야 한다”고까지 말합니다. 이유는 간단합니다:

• 에이전트가 하루에 수백 개 변경을 만들 수 있는데
• 인간 리뷰 속도는 그걸 따라갈 수 없고
• 결국 PR 큐가 쌓이며 병목이 된다

그래서 대안으로 제시하는 건:

• 에이전트가 자기 검증(self-verify): 계획 문서/제약/테스트/회귀/보안 스캔 등 자동 검증을 통과
• 또는 두 번째 에이전트가 리뷰(일종의 “적대적 리뷰어”)
• 사람 리뷰는 “예외 상황”에만 개입

즉, “사람이 상시로 diff 읽기”에서 “자동 검증이 기본, 사람은 정말 새로운/모호한 것만”으로 바뀐다는 그림입니다.

---

4.6 배포: 더 연속적이고, 릴리스와 분리된다

원문은 에이전트가 배포 파이프라인도 빠르게 만들며, 더 중요한 변화로 배포(Deployment)와 릴리스(Release)의 분리를 강조합니다. 

이 개념은 기능 플래그(Feature Toggle/Flag)로 많이 구현됩니다. Martin Fowler는 기능 토글이 트렁크 기반 개발/지속적 전달에서 불완전한 기능을 “꺼진 채로” 프로덕션에 둘 수 있게 한다고 설명합니다. (martinfowler.com)

또 “점진적 롤아웃(카나리)” 같은 전략도 여기서 중요해집니다. 예를 들어 Google Cloud 문서에서는 카나리 배포를 트래픽을 쪼개 새 버전을 일부 사용자에게 먼저 노출하는 점진적 롤아웃으로 정의합니다. (Google Cloud Documentation)

원문이 그리는 미래는 더 과감합니다:

• 배포는 상시로 이루어지고
• 플래그/트래픽 규칙으로 릴리스 결정을 분리하며
• 장애 징후가 있으면 자동 롤백하고
• 에이전트가 원인 분석/수정까지 반복한다

---

4.7 모니터링: “마지막 남은 단계”이자 “전체 시스템의 안전망”

원문에서 모니터링은 유일하게 살아남는 단계이면서, 동시에 나머지 단계가 흡수/소멸했을 때 남는 최후의 방어선입니다.

그런데 기존 옵저버빌리티는 “사람이 대시보드를 보고 조치”하는 설계가 많죠.
원문은 여기서 한 단계 더 나아가서:

• 변화량이 인간의 주의를 초과하면
• 대시보드/알림 중심 운영은 새 병목이 되고
• 결국 “관측가능성은 저장소가 아니라 폐루프(closed-loop) 자동 조치로 가야 한다”

참고로 OpenTelemetry는 관측가능성을 이해하는 기초로 텔레메트리(트레이스/메트릭/로그) 같은 신호를 설명합니다. (원문이 말하는 “관측 → 피드백”을 구현할 때도 결국 이런 신호 품질이 중요해집니다.) (OpenTelemetry)

---

5) 새 라이프사이클: “티켓/스프린트/PR”이 아니라 “짧은 루프”

원문은 새 흐름을 이렇게 요약합니다:

• Human Intent + Context → AI Agent → Build/Test/Deploy → Observe → (문제면) 다시 Agent

그리고 “그래서 뭐가 남냐?”라는 질문에 답을 단순하게 내립니다:

• 남는 건 컨텍스트
• 새로운 핵심 스킬은 컨텍스트 엔지니어링
• 새로운 안전망은 옵저버빌리티(관측가능성)

---

6) 실무에서 “그럼 우리는 뭘 바꿔야 하나?”

원문을 그대로 받아들이든, “좀 과장됐다”고 보든, 팀이 당장 점검해볼 체크리스트는 꽤 실용적입니다. 아래는 원문 논지를 실무 액션으로 번역한 버전입니다.

6.1 티켓을 “업무 추적”이 아니라 “컨텍스트 패키지”로 만들기

에이전트가 일을 잘하려면 “해야 할 일”보다 해야 하는 이유/제약/금지사항/성공 기준이 중요합니다.
그래서 티켓 템플릿을 이런 방향으로 바꿔볼 만합니다:

• 문제 정의(왜 하는가)
• 성공 조건(무엇이 되면 끝인가)
• 제약(보안/성능/비용/컴플라이언스)
• 관련 링크(ADR/아키텍처/도메인 용어집/기존 코드 위치)
• 운영 관점(SLO/알림 기준/로그 키)

원문이 “Jira는 이제 컨텍스트 저장소가 되는데 그 용도로는 별로”라고 한 맥락이 여기랑 연결됩니다.

---

6.2 “코드리뷰”를 줄이는 대신 “자동 검증(가드레일)”을 두껍게

PR을 없애자는 결론까지 가지 않더라도, 원문이 말하는 방향은 명확합니다:
사람의 눈이 아니라 자동 검증 체계가 기본 방어선이 되어야 합니다. 

예:

• 테스트(단위/통합/스모크) 자동 실행
• 타입체크/린트/포맷 강제
• 보안 스캔/의존성 정책
• 회귀 방지(행동 기반 테스트, 계약 테스트 등)
• “실패하면 에이전트가 스스로 수정”할 수 있는 피드백 루프

---

6.3 배포와 릴리스를 분리: 플래그 + 점진 롤아웃 + 자동 롤백

원문이 말하는 “배포는 계속, 릴리스는 별도 결정”은 기능 플래그로 자주 구현됩니다.

그리고 위험을 줄이려면 카나리 같은 점진 롤아웃이 유용합니다(트래픽을 나눠 일부부터). (Google Cloud Documentation)

---

6.4 관측가능성은 “대시보드”가 아니라 “에이전트의 피드백 데이터”가 된다

원문이 가장 강하게 밀어붙이는 포인트입니다:

• 사람이 모든 이상징후를 해석할 수 없으니
• 텔레메트리(로그/메트릭/트레이스)를 에이전트 루프에 직접 연결해야 한다

실무적으로는:

• “이상징후 → 원인 후보 → 롤백/완화 → 재발 방지 PR”까지 이어지는 플레이북을 만들고
• 그 플레이북 자체를 에이전트가 실행/보완하도록 설계하는 방향이 됩니다.

---

6.5 사람의 역할이 사라지는 게 아니라 “판단의 위치”가 바뀐다

이 글을 읽고 “그럼 사람은 필요 없나?”로 가면 오해입니다.
원문도 인간의 역할을 예외 처리, 새로운 문제, 과설계/제약 누락 감지 같은 판단으로 이동시킵니다.

• 예전: 사람이 파이프라인 각 단계의 “작업자”
• 앞으로: 사람이 전체 루프의 “감독/편집자/심판”

---

7) 내 해석 한 줄: “SDLC가 죽었다”기보다 “SDLC가 접혀서 루프가 됐다”

원문 표현은 과감하지만(“죽었다”), 실무 관점에서 더 정확한 표현은 이거라고 봅니다:

• SDLC의 단계들이 사라진다기보다,
• 에이전트 중심 워크플로에서 동시에 생성되고 자동 검증되며,
• 사람은 “상시 참여”에서 “예외/판단에 집중”으로 옮겨간다

그래서 앞으로 팀의 경쟁력은 “프로세스”보다:

• 컨텍스트를 얼마나 잘 정리해 먹이느냐 
• 관측가능성과 점진 릴리스로 얼마나 안전하게 자동화하느냐 

이 두 축에서 갈릴 가능성이 큽니다.

---