GeekNews의 xguru님께 허락을 받고 GN에 올라온 글들 중에 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가 몇가지 놀라운 일을 할 수는 있지만, 당신의 마음을 읽거나 당신이 원하는 것을 말해주지는 않음