9 한계와 리스크
바이브 코딩의 약속 뒤에는 계산서가 있다. 이 장은 그 계산서를 정직하게 편다. 이해의 공동화(블랙박스가 되어가는 코드베이스), 보안, 품질 부채, 전문가 양성 경로의 단절, 그리고 책임의 문제까지. 낙관도 공포도 아닌 근거가 기준이다.
9.1 블랙박스가 되어가는 코드베이스
초안 전. 담당·상태는 저장소 루트의 TOPICS.md에서 확인.
브리프. AI가 빠르게 짜는 코드는 그만큼 빠르게, 아무도 전체를 이해하지 못하는 상태로 쌓인다. 이 꼭지는 이해의 공동화 문제를 다룬다. 개별 커밋은 동작하지만 전체 아키텍처를 파악하고 있는 사람이 조직에서 사라지는 과정, 그리고 그런 코드베이스 위에 다시 AI가 코드를 얹을 때 무슨 일이 일어나는지를 살핀다. “이해 없이 동작하는 코드”가 언제 문제가 되고 언제 그렇지 않은지 구분하는 기준을 세우는 것이 이 꼭지의 핵심 논증이다. 9장 전체(한계와 리스크)의 도입에 해당한다.
시드 질문
- “이해 없이 동작하는 코드”가 실제로 사고나 장애로 이어진 사례가 보고되어 있는가?
- 코드베이스 이해도와 유지보수 비용의 관계를 다룬 실증 연구는 무엇을 보여주는가?
- AI가 이미 AI가 짠 코드 위에 다시 코드를 얹을 때, 오류나 스타일 불일치가 누적되는 현상은 확인되는가?
- 조직은 “아무도 전체를 모르는” 상태를 어떻게 측정하거나 완화하려 하는가, 문서화 의무나 온보딩 관행이 실제로 바뀌었는가?
- 개인 프로젝트(1인 개발)와 팀 코드베이스에서 이 문제의 양상은 어떻게 다르게 나타나는가?
조사 포인터
- 프로그램 이해 가능성(program comprehension), 코드베이스 복잡도를 다룬 학술 논문을 우선 찾을 것
- 장애 부검(postmortem) 보고서, 유지보수 경험담 등 실무 현장 보고를 수집할 것
- Parnas(1972)의 모듈 분해 논거를 다루는 §11.1과 교차 참조할 것
9.2 보안: 새로운 공격면
초안 전. 담당·상태는 저장소 루트의 TOPICS.md에서 확인.
브리프. AI가 생성한 코드는 사람이 짠 코드와 다른 종류의, 혹은 다른 빈도의 취약점을 만드는가. 이 꼭지는 생성 코드의 보안 취약점을 다룬 실증 연구, 에이전트가 외부 콘텐츠(검색 결과, 문서, 이슈 코멘트)를 읽다가 악성 지시를 실행하게 되는 프롬프트 인젝션, 그리고 모델이 존재하지 않는 패키지 이름을 지어내고 공격자가 그 이름을 먼저 등록하는 slopsquatting을 다룬다. 수치와 사례는 반드시 1차 출처로 확인한 뒤 인용한다.
시드 질문
- AI 생성 코드의 취약점 비율을 사람이 짠 코드와 비교한 실증 연구는 무엇이 있고, 방법론은 신뢰할 만한가?
- 프롬프트 인젝션은 코딩 에이전트 맥락에서 구체적으로 어떤 공격 경로를 만드는가?
- slopsquatting은 실제로 보고된 사례가 있는가, 피해 규모는 어느 정도로 추정되는가?
- 코딩 에이전트에 부여되는 실행 권한(셸 명령, 파일 쓰기, 네트워크 접근)은 보안 모델을 어떻게 바꾸는가?
- 벤더(Anthropic, GitHub 등)는 이런 공격면에 대해 어떤 완화책을 공식 문서로 제시하고 있는가?
조사 포인터
- 생성 코드 보안 취약점을 정량 분석한 학술 논문을 우선 검색할 것
- 프롬프트 인젝션, slopsquatting을 다룬 보안 업체·연구자의 실증 보고서를 확인할 것
- glossary의 slopsquatting 항목(G14)과 교차 참조하되 역할을 나눠 중복을 피할 것
9.3 품질 부채와 유지보수
초안 전. 담당·상태는 저장소 루트의 TOPICS.md에서 확인.
브리프. 빠르게 생성된 코드는 종종 동작은 하지만 고치기는 어렵다. 이 꼭지는 품질 부채가 기존 기술 부채 개념과 어떻게 같고 다른지, AI의 생성 속도가 부채 누적 속도를 어떻게 바꾸는지, 그리고 처음부터 다시 짜는 편이 언제 더 싼 선택이 되는지를 다룬다. 리라이트 비용을 재무적으로 따지는 시도가 있다면 확인해 소개한다. §11.2(기술 부채, 재발견 관점)와 짝을 이루되 이 꼭지는 실무·재무 관점에 무게를 둔다.
시드 질문
- AI가 생성한 코드는 사람이 짠 코드에 비해 유지보수 비용이 다르다는 실증 연구가 있는가?
- 기술 부채 은유를 AI 생성 코드에 적용할 때 무엇이 맞고 무엇이 맞지 않는가?
- “동작하지만 고칠 수 없는 코드”를 판별하는 구체적 기준(복잡도 지표, 리뷰 소요 시간 등)은 실무에서 무엇이 쓰이는가?
- 리라이트와 점진적 리팩토링 중 어느 쪽이 더 싼지 판단하는 재무적 프레임은 무엇이 제안되어 있는가?
- 코드 생성 속도의 증가는 리뷰·테스트 역량의 증가 속도를 앞지르고 있는가, 데이터로 확인되는가?
조사 포인터
- Cunningham(1992)의 기술 부채 원 발표(OOPSLA experience report)를 원문으로 확인할 것
- 소프트웨어 유지보수 비용, 리팩토링 대 재작성 판단에 관한 학술 논문을 우선 검색할 것
- §11.2와 역할을 나눌 것: 이 꼭지는 실무·재무 관점, §11.2는 개념사 관점
9.4 주니어의 역설: 사다리가 사라진다
초안 전. 담당·상태는 저장소 루트의 TOPICS.md에서 확인.
브리프. AI가 가장 잘 대신해주는 업무는 대개 주니어가 맡아 성장하던 업무다. 이 꼭지는 초급 업무의 자동화가 전문가로 가는 사다리를 끊는다는 우려를 다룬다. 주니어 개발자 채용 데이터, 인턴십과 신입 공고의 변화를 찾아, 이 문제가 실제로 데이터로 확인되는지 아니면 과장된 서사인지를 가른다. §13.3(전문성의 사다리)과 짝을 이루되 이 꼭지는 노동시장·채용 데이터 쪽에 무게를 둔다. 수치는 반드시 원 데이터로 확인한 뒤 인용한다.
시드 질문
- 주니어 개발자 채용 공고 수, 인턴십 규모는 최근 실제로 어떻게 변했는가, 신뢰할 만한 데이터 출처는 어디인가?
- “주니어가 AI로 더 빨라졌다”는 관찰과 “주니어 채용이 줄었다”는 관찰은 같은 현상의 다른 면인가, 별개의 현상인가?
- 기업들은 신입 채용 감소를 AI 때문이라고 공식적으로 인정한 적이 있는가, 아니면 경기나 과잉 채용 조정 같은 다른 요인이 더 크게 작용하는가?
- “사다리가 사라진다”는 우려를 반박하거나 다른 설명을 제시하는 연구는 무엇이 있는가?
- 신입 채용 감소에 대한 기업·업계 차원의 대응(주니어 전담 프로젝트 유지, 멘토링 재설계 등) 사례가 보고되어 있는가?
조사 포인터
- 채용 공고와 고용 통계를 다루는 노동경제학 실증 연구를 우선 검색할 것, 수치는 반드시 원 데이터로 확인한 뒤 인용할 것
- 업계 서베이(개발자 채용 동향 보고서 등)와 학술 연구를 구분해 신뢰도를 다르게 취급할 것
- §13.3(전문성의 사다리), §14.2(직업 지형의 변화)와 역할을 나눌 것: 이 꼭지는 코딩 사다리에 한정
9.5 책임과 서명: 누가 이 코드에 사인하는가
초안 전. 담당·상태는 저장소 루트의 TOPICS.md에서 확인.
브리프. AI가 짠 코드에서 사고가 났을 때 책임은 누구에게 있는가. 이 꼭지는 코드 리뷰와 배포 승인이라는 전통적 서명 관행이 AI 생성 코드 앞에서 어떻게 재정의되는지, 실제 기업·기관이 도입한 AI 코드 거버넌스 정책(리뷰 의무, 생성 코드 표기, 책임자 지정)이 무엇인지, 그리고 사고 사례에서 책임이 실제로 어떻게 배분되었는지를 다룬다. 9장의 마지막 꼭지로 앞선 문제들(이해의 공동화, 보안, 품질 부채)이 조직 차원에서 누구의 책임으로 귀결되는지 묻는다.
시드 질문
- AI 생성 코드로 인한 장애나 사고에서 책임이 실제로 어떻게 귀속되었는가, 공개된 사례가 있는가?
- 기업·기관이 공식화한 AI 코드 거버넌스 정책은 리뷰 의무, 승인 절차, 생성 코드 표기와 관련해 구체적으로 무엇을 요구하는가?
- 전통적 코드 리뷰의 승인이라는 관행은 AI 생성 코드 앞에서 형식적으로만 유지되고 실질은 비어가는가?
- 오픈소스 프로젝트는 AI 생성 기여물에 대해 어떤 표기·심사 규칙을 도입하고 있는가?
- 법적·계약적 책임 논의(제조물 책임과의 유비 등)는 어느 수준까지 진행되어 있는가?
조사 포인터
- 기업·정부 기관이 발표한 AI 코드 거버넌스 정책 문서를 1차 출처로 수집할 것
- 오픈소스 프로젝트의 AI 기여 정책(컨트리뷰션 가이드라인)에서 실제 사례를 확인할 것
- 코드 리뷰의 목적론을 다루는 §10.3과 교차 참조하되 역할을 나눌 것: 이 꼭지는 책임·거버넌스에 한정