IBM Bob이 국내에 처음 공개됐다. 기획·개발·테스트·배포·운영·보안까지 SDLC 전 과정을 아우르는 에이전트다. IBM 내부 적용 결과는 숫자로 말한다. 개발 생산성 평균 45% 향상, 애플리케이션 현대화 속도 최대 93% 단축, 문서화 속도 10배 이상. IBM의 선임 기술 책임자는 "Bob을 개발하는 데 Bob을 썼고, 산출물의 40%는 Bob이 스스로 만들어냈다"고 말했다. 신입 개발자가 하루 만에 생산성을 낼 수 있다는 주장도 덧붙였다.
숫자는 인상적이다. 그런데 나는 이 숫자를 볼 때마다 같은 질문이 떠오른다. AI가 짠 코드가 프로덕션에서 터지면, 누가 책임지나?
이건 철학적 질문이 아니다. dev.to에 올라온 한 20년 경력 시스템 아키텍트의 글은 이 질문에 실전 사례로 답한다. AI가 제안한 PostgreSQL 인덱스 전략을 적용했더니 리포트 성능은 올랐다. 그런데 몇 주 후 WAL bloat이 발생하고 vacuum 프로세스가 멈추기 시작했다. 디스크가 차고 I/O 레이턴시가 튀었다. AI는 해당 쿼리에 최적인 인덱스를 줬지만, PostgreSQL 내부 동작과 replication에 미치는 장기적 영향은 고려하지 못했다. 코드 한 줄의 오류가 아니라 아키텍처 판단의 부재였다. 그리고 그 판단의 공백을 메운 건 AI가 아니라 사람이었다.
그는 이렇게 단언한다. "마지막 커밋을 누가 했든, 배포를 누가 눌렀든, 책임은 그 사람에게 있다." AI가 만든 코드도 마찬가지다. 쉘 스크립트 복붙과 다르지 않다. 아니, 더 위험할 수 있다. AI는 자신감 있게 틀리기 때문이다.
그렇다면 AI가 SDLC를 실질적으로 담당하기 시작한 지금, 개발자의 역할은 어떻게 달라지나. 또 다른 dev.to 분석이 이 흐름을 잘 정리한다. 코드를 쓰는 것이 더 이상 병목이 아니다. 병목은 상류로 이동했다. 무엇을 만들지, 어떻게 구조화할지가 진짜 어려운 문제가 됐다. 개발자의 역할은 생산에서 검토로, 문법에서 시스템으로, 단독 작업에서 오케스트레이션으로 이동하고 있다.
이 변화를 팀 리드 관점에서 해석하면 세 가지 책임 레이어가 선명해진다.
첫째, 명세 책임. AI는 프롬프트가 모호하면 그럴듯한 오답을 자신 있게 낸다. IBM Bob이 조직의 규칙과 코드베이스 맥락을 학습해서 동작한다고 해도, 그 맥락을 정확하게 정의하고 유지하는 건 사람의 몫이다. 요구사항을 정밀하게 명세하는 능력이 생산성 배율을 결정한다.
둘째, 검증 책임. AI가 생성한 코드는 빠른 주니어 개발자의 PR처럼 다뤄야 한다. 유용하지만 반드시 검토해야 한다. 보안 취약점, 아키텍처 불일치, 장기 유지보수 리스크는 AI가 스스로 잡아내지 못한다. canary 배포, feature flag, sandbox 테스트가 선택이 아닌 필수가 되는 이유다.
셋째, 아키텍처 판단 책임. 마이크로서비스 분리, 이벤트 소싱 설계, 분산 트랜잭션 일관성 같은 결정은 AI가 패턴은 알지만 맥락은 모른다. eventual consistency 이슈와 transaction outbox 패턴의 필요성, 그 복잡도가 우리 팀에 감당 가능한지—이 판단은 여전히 아키텍트의 테이블 위에 있다.
실용적인 결론을 내리자면 이렇다. IBM Bob 같은 도구가 SDLC 실행을 맡을수록, 팀 리드가 설계해야 할 것은 오히려 늘어난다. AI 도입 이후 팀의 생산성이 45% 오를 수도 있다. 하지만 검증 구조 없이 그 속도를 받으면, 45%의 생산성은 45%의 부채 적립 속도가 된다.
AI가 코드를 쓰는 시대, 개발자의 가장 희소하고 가치 있는 역량은 '무엇이 좋은 코드인지 아는 눈'이다. 타이핑은 AI에게 넘겼다. 판단은 넘길 수 없다. 그 판단이 어디에 있는지 팀 구조 안에 명시적으로 설계해두지 않으면, AI가 생성한 출력물은 누구의 책임도 아닌 채로 프로덕션에 쌓인다.