요구공학 - AI 요구사항 관리

소프트웨어 개발의 가장 어려운 점은 코딩이 아니라 요구사항

 

• 왜 개발자를 AI로 대체하는게 어려운지에 대하여
• 많은 뉴스에서 AI가 개발자를 대체하게 될 거라고 얘기하지만, 소프트웨어 구축에 있어서 가장 어려운 부분은 코딩이 아니라 명확하고 정확한 요구사항을 만드는 것
• "그거 버그 아니고 피쳐에요. 어, 잠시만 버그네요"
  • 명확하지 않은 요구사항은 버그를 만들어냄
• "AI가 개발자를 대체하려면, 클라이언트는 자신들이 원하는 것을 정확하게 설명해야함. 우린 안전해요"

AI의 현실: 체스 vs. 자율주행 자동차

• AI는 체스와 같이 규칙이 한정되고 명확한 영역에서 성공적으로 활용되었음, 하지만 자율주행 자동차는 무한한 변수와 예외 상황으로 인해 AI에게 훨씬 더 복잡한 도전
• 기술분야에서는 9 다섯개 또는 6개의 Availability(가용성)가 표준임 (99.999% 에서 99.9999%)
  • 99%에 도달하는 비용은 별로 들지 않음. 99%는 당신의 웹사이트가 1년에 3일 이하로 다운된다는 것을 의미함(87.6시간)
  • 하지만 9가 하나 붙을때 마다 거기에 도달하는 비용은 기하급수적으로 증가함
  • 99.9999%가 되려면 1년에 31.5초만 다운되어야 함(99.9%는 526분/8.76시간, 99.99%는 52분, 99.999%는 5.2분)
  • 이를 위해서는 엄청난 계획가 노력이 들어가고, 물론 비쌈
• AI가 아무리 좋아진다 한들, 항상 사고의 위험성이 있음
• 어느 정도의 사고를 허용할지 모르겠는데, 적어도 사람만큼은 되어야함

AI는 소프트웨어를 만들 수 없고, 코드만 만들 수 있음

• 소프트웨어를 만들고 유지하는 것은 체스보다 운전과 더 공통점이 많음
• 수많은 변수들이 있고, 규칙은 판단에 의해 결정됨
• 소프트웨어를 만들 때 원하는 결과가 있겠지만, 그게 체스처럼 단순하지 않음
• 소프트웨어는 완료 라는 게 거의 없음. 계속 기능이 추가되고 버그가 수정되는 지속적인 Exercise임
• 소프트웨어와 달리 체스 게임은 일단 이기거나 지면 끝임
• 소프트웨어 개발에서 우리는 소프트웨어 디자인을 체스의 규칙 엔진처럼 만드는 도구를 가지고 있음: 기술 스펙
• 최상의 상태에서 이 기술 스펙은 사용자 행동과 프로그램의 흐름을 예측함
• 하지만, 이런 경우는 거의 없음. 우리는 너무 자주 Wishlist를 기능 스펙으로 받거나, 냅킨에 적은 와이어프레임이나 불분명한 요구사항 문서를 건내 받아서 우리가 최고의 판단을 내리게 만듦
• 설상가상으로 요구사항들은 변하고 무시되기도 함
  • 불가능한 요구사항들. 원글에선 WIFI 없는데서 문자로 COVID 설문조사를 하는 프로젝트 사례를 얘기함. 안하는게 맞았음
  • AI가 과연 어런 대응이 가능할까 ?
• AI가 기능적인 소프트웨어를 만드는게 가능하려면, 원하는 것을 제대로 알고 이를 명확하고 정확하게 정의할 수 있어야 함
• 지난 10년간 소프트웨어 산업은 워터폴에서 애자일 방식으로 전환했음
  • 워터폴에선 이해관계자가 자신이 원하는 것을 알고 이를 문서화 할수 있다고 생각했지만, 최종 제품이 전달되었을때 매우 실망했기 때문에 실패했음
  • 애자일은 이 프로세스에 대한 해결책임
• AI는 우리가 이미 가지고 있는 소프트웨어를 최신 하드웨어어와 새로운 언어로 재작성하는데는 가장 적합할 수 있음
  • COBOL로 작성된 소프트웨어를 사용하는 곳은 아직 많지만, 그 언어를 배우는 사람은 거의 없으니까
• AI가 이미 만들어진 소프트웨어는 사람보다 더 빠르게 만들수 있겠지만, 그것은 누군가가 이미 소프트웨어가 어떻게 만들어져야 할지를 고민했기 때문임
• AI는 우리가 죽음의 행군이라고 부르는 폭포수 프로세스를 사용하면 소프트웨어를 꽤 잘 구축할 수 있음
  • 폭포수에서 누가 끔찍할까? 바로 인간임
  • 단지 프로그래머 팀에게 전달한 문서를 작성하는 부분만이 아니라, 그 이전의 모든 것임
• AI가 몇가지 놀라운 일을 할 수는 있지만, 당신의 마음을 읽거나 당신이 원하는 것을 말해주지는 않음

 

 

https://stackoverflow.blog/2023/06/26/the-hardest-part-of-building-software-is-not-coding-its-requirements/

The hardest part of building software is not coding, it's requirements