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

(stackoverflow.blog)

66P by xguru 10달전 | favorite | 댓글 8개

왜 개발자를 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가 몇가지 놀라운 일을 할 수는 있지만, 당신의 마음을 읽거나 당신이 원하는 것을 말해주지는 않음