TL;DR

  • “코드는 지우고 명세는 남기라”는 말은 프로그래밍 전에 명세를 먼저 완성하라는 규칙이 아니라, 구현 과정에서 배운 내용을 보존하라는 뜻임.
  • 첫 시스템 명세는 늘 틀리며, 구현은 실제로 원하는 바를 발견하고 요구사항을 구체화하는 중요한 수단임.
  • Matteo Paltenghi와 Satish Chandra의 연구는 AI 코딩 세션이 끝난 뒤 코드 변경에서 명세를 추출하고, 다른 에이전트가 이를 바탕으로 같은 변경을 재현하는 방식을 살핌.
  • 먼저 작동하는 것을 만들고 이후 명세를 작성한 다음 재생성하면, 명세가 실제로 보존한 내용이 무엇인지 확인할 수 있음.
  • 재생성 결과를 요구사항으로 삼을지는 여전히 사람의 판단에 달렸으며, 발견한 내용을 버리지 않는 일이 중요함.

“명세를 남기라”는 말의 의미

  • “코드는 지우고 명세는 남기라”는 표현을 프로그래밍 전에 명세를 작성해야 한다는 규칙으로 받아들이는 경우가 많음. 그러나 그런 뜻이 아니며, 실제 소프트웨어 개발도 그렇게 진행되지 않음.
  • 이런 오해가 지난 몇 년 사이 등장한 다양한 명세 주도 개발(spec-driven development) 접근법뿐 아니라 이와 관련한 아이디어 전반에 대한 반발의 한 원인이라고 봄.

구현은 원하는 것을 발견하는 과정

  • 경험 많은 개발자는 프로그래밍이 실제로 원하는 것을 알아내는 가장 중요한 방법 가운데 하나라는 점을 잘 알고 있음. 무언가를 시도하고, 잘못되면 생각을 바꾸며, 일부 요구사항은 구현이 이를 깨뜨릴 때 비로소 생김.
  • 시스템을 처음 명세할 때의 시도는 늘 틀림. 1990년대에 본격적으로 프로그래밍을 시작한 뒤 이 점을 규칙처럼 여겨 왔으며, 이것이 익스트림 프로그래밍(eXtreme Programming)에 곧바로 끌린 이유라고 봄.

“사용자 스토리는 대화의 약속이다.”

  • 그 대화는 비즈니스 책임자와 나눌 수도 있고, 단위 테스트(unit test) 및 컴파일러와 나눌 수도 있음.

구현 이후 명세를 추출하는 연구

  • Matteo Paltenghi와 Satish Chandra도 같은 직관을 가진 것으로 보임. 이들의 연구 「AfterVibe: 대화가 끝난 뒤 남는 것」은 이 접근을 과학적으로 살핌.
  • 완성된 AI 코딩 세션과 해당 세션에서 나온 코드 변경을 바탕으로 명세를 추출함. 이어 복구한 명세를 다른 에이전트에 전달하고, 기존 저장소에서 같은 변경을 재구축하도록 요청함.
  • 핵심은 첫 번째 구현으로 의도를 발견하고, 두 번째 구현으로 그 의도를 명세에 제대로 기록했는지 확인하는 과정임.

순서를 뒤집는 개발 방식

  • 막연한 아이디어에서 출발해 작동하는 무언가가 나올 때까지 빠르게 구현함. 그 과정이 끝나면 첫날에는 작성할 수 없었던 명세를 얻게 됨.
  • 이후 다시 생성해 명세가 실제로 무엇을 보존했는지 확인함. 시간과 비용이 충분하다면 지금까지 만들어진 모든 소프트웨어 프로젝트가 이런 과정을 통해 이점을 얻을 수 있으며, 생성형 인공지능으로 이제 하루에도 여러 번 반복할 수 있음.

판단은 여전히 필요함

  • 이 과정이 판단을 없애지는 않음. 버그를 충실하게 재생성하면 출처가 더 잘 기록된 버그가 생길 뿐임.
  • 어떤 발견을 요구사항으로 채택하고 어떤 발견을 우연으로 볼지는 여전히 누군가 결정해야 함.
  • 시작하기 전에 모든 것을 알 필요는 없음. 배운 내용을 버리지 않는 것이 중요함.
  • 논문을 소개한 Codeplain의 최고경영자 Dusan Omercevic에게 감사를 전함.