유용한 소프트웨어를 작성하는 것이 항상 어려운 이유

역사는 우리에게 유용한 소프트웨어를 쓰는 것이 얼마나 어려운지 가르쳐줍니다. 그것은 코드와 거의 관련이 없어서, 인공지능은 그것을 고칠 수 없을 것입니다.

저는 효율적인 소프트웨어 엔지니어링과 효과적인 소프트웨어 엔지니어링의 차이, 그리고 나서 그것이 우발적인 것과 본질적인 복잡성 사이의 관계에 대해 이전 두 번의 게시물을 썼습니다. AI가 향후 수십 년 동안 프로그래밍 직업을 어떻게 바꿀지 궁금하지만, 단기적으로 과대 주입된 예측에 비판적입니다. AI는 수십 년 동안 가치가 있는 소프트웨어를 꿈꾸지는 않을 것입니다. 그것은 정말 어려운 문제로 남아 있습니다. 그것은 우리가 더 효율적인 것은 잘 할 수 있지만 효과적인 것은 잘 하지 못합니다.

신뢰할 수 없는 직업으로 다시 표현하는 것이 좋습니다. 효율성은 올바른 것을 만드는 것입니다. 우리의 인간 이익과 일치하고 우리에게 해를 끼치지 않는 것입니다. 다른 차나 보행자와 충돌하지 않도록 설계된 자율 주행 자동차는 기껏해야 신뢰할 수 없습니다. 안전 장치를 명시하는 것이 더 쉽지만 구현하기가 엄청나게 어렵습니다. 그리고 그것은 더욱 어려워집니다. 일단 수백만 대의 자동차가 도로에 있으면, 매일 이들 중 일부는 두 가지 악 중 작은 것 사이에서 생사를 가르는 결정을 내릴 것입니다. 그 기계는 순식간에 그리고 벌컨 분리로 다른 인간에게 무엇이 최선인지 판단해야 합니다. 많은 것의 요구가 요구보다 더 크다고 주장할 것입니다. 그러한 실존적 결정에 있어서 우리는 우리가 원하는 종류의 기계 미래를 형성하기 위해 운전석에 확고히 머물러야 합니다.

현재의 인공지능은 효율성 향상들을 다루기 위해 훨씬 더 잘 갖추어 졌습니다. 그것은 대안들을 교환할 수 있고, 그것들의 상대적인 장점들을 따져보고, 가장 효율적인 해결책에 이르게 하는 조합을 제안할 수 있습니다. 그러나 그것이 똑똑해질수록, 우리는 판단을 필요로 하는 논란이 많은 주제들과 그것을 덜 신뢰해야 합니다. 왜냐하면 일들이 무서운 방향으로 진행될지도 모르기 때문입니다. 닉 보스트롬의 유명한 종이클립 극대화기는 중요한 경고와 함께 하는 재미있는 사고 실험입니다: 인공지능은 당신이 그것을 지시하는 모든 것에 최적화 할 것입니다. 만일 종이클립을 만들고 그것이 무한히 강력하고 무한히 이타적이라면, 그것은 더 쓸모없는 문구류를 만들기 위해 은하계 전체를 그것들의 금속으로부터 떼어낼 것입니다.

인공지능이 의식을 갖게 되더라도, 어두운 계획이 있든 없든, 그것은 여전히 외계인일 것이고, 정의상으로는 그렇게 될 것입니다. 아이작 아시모프는 개별 기관을 가진 인간 창조물은 아마도 몇몇 하드 코드화된 안전장치를 가지고 있어야 한다고 예측했습니다. 그의 세 가지 로봇공학 법칙은 에니악보다 단지 3년 앞섰습니다. 하지만 그는 첫 번째 로보캅 영화에서처럼 교활한 펌웨어 업그레이드를 통해 "해를 가하지 않는다" 원칙에 약간의 사적인 예외를 추가한 사악한 천재를 예측할 수 없었습니다.

음울한 눈빛으로 팔랑티르를 바라보는 것만으로도 충분합니다.  예측하는 것은 프로그래밍 기술이 필요한 것을 명확하고 명확하게 표현하는 기술로 바뀔 것이라는 것입니다. 개발자들은 궁극적인 고급 프로그래밍 언어, 즉 영어를 사용하여 AI와 대화하는 데 익숙해져 AI에 정통한 비즈니스 분석가가 될 것입니다. 항상 작동하는 소프트웨어를 구축할 것이며 운이 좋으면 유용할 것입니다.

 

 

유용한 소프트웨어를 작성하는 것이 항상 어려운 이유

 

 

작동하는 소프트웨어가 충분하지 않음

애자일 매니페스토가 작동하는 소프트웨어를 요구한 것이 이상하지 않나요? 마치 고장난 소프트웨어가 결코 용납할 수 있는 대안이었던 것처럼 말입니다! 신속하게 생성된 코드가 유용하고 가치가 있다고 묻는 것이 지나친 건가요? 네, 아마도 너무 지나친 요구일 것입니다. 작동하는 소프트웨어와 가치 있는 소프트웨어 사이의 차이는 그 가치가 무형적이고 예측할 수 없기 때문에 엄청납니다. 완벽하게 훌륭한 소프트웨어는 자신의 잘못이 없고 어떤 업그레이드도 고칠 수 없는 방식으로 관련성을 잃을 수 있습니다. 다음은 몇 가지 예입니다.

오랫동안 잊혀졌던 OS 프로젝트 챈들러에 대해 언급한 것이 이번이 처음은 아닙니다. 버전 1.0으로 가는 험난한 여정은 스콧 로젠버그의 2007년 저서 '드림 인 코드'(Dreaming in Code)에 잘 나타나 있습니다. 최고의 의도, 헌신적인 최고 수준의 개발자들로 구성된 팀, 그리고 관대한 후원자(로터스 1-2-3을 만든 미치 카퍼)가 성공을 보장하지 않는다는 것은 영원한 깨우침입니다.

챈들러는 마이크로소프트 아웃룩과 익스체인지의 자유로운 대안이 되기로 결심했습니다. 이는 완전히 다른 사용자 경험을 약속했습니다. 이는 메시지, 의제 및 할 일 목록을 처리하는 방식에 혼란을 줄 것이었습니다. 그리고 이는 데스크톱 앱에서 피어투피어 프로토콜을 통해 소통하는 것을 의미했습니다.

하지만 그 팀은 아키텍처 로드맵에서 너무 많은 방향을 잘못 잡았습니다. 더 강력한 브라우저 기능 덕분에 파이썬 기반 데스크톱 앱은 좋지 않은 선택이 되었습니다. 저렴하고 간편한 자체 서버 호스팅으로 인해 피어투피어 프로토콜, 즉 우연한 복잡성을 쏟아낸 설계 선택의 필요성이 없어졌습니다. 커뮤니티가 원한다면 이 모든 것을 해결할 수 있었지만, 본질적인 문제는 사용자 경험에 있었습니다. 보통 직장인들이 필요로 하는 아이디어가 아니었습니다. 어떤 것도 다른 제품에서 구현된 것을 보지 못했습니다. 사람들은 1995년에 했던 것처럼 지금도 여전히 메일과 안건을 사용하고 있습니다. 지금에서야 전화기에 문제를 해결할 수 있었습니다.

 

GWT의 계획되지 않은 노후화

때때로 훌륭한 도구는 원래 고유한 판매 포인트가 더 이상 팔리지 않기 때문에 더 이상 쓸모가 없게 될 수도 있습니다. 2006년 구글 웹 툴킷(GWT)은 강력한 제안을 했습니다. 데스크톱 컴퓨터는 브라우저를 애플리케이션 플랫폼으로 지원하기에 충분한 마력을 가지고 있었습니다. 당신은 아무것도 설치하지 않고도 세금을 낼 수 있었습니다. 하지만 드래그 앤 드롭이나 더블 클릭과 같은 고급 도구에서는 브라우저 호환성이 만연했습니다.

GWT를 사용하면 동일한 프로젝트에서 데이터 전송 및 검증을 위해 공유 개체로 백엔드 및 프론트엔드 코드를 작성하고 단일 웹 아카이브에 배포할 수 있습니다. GWT는 자바를 자바스크립트로 컴파일하고 로컬 개발 서버로 클라이언트 측 자바 코드를 디버그할 수도 있습니다. 한동안 꽤 많은 돈을 벌었어요.

하지만 컴파일 비용이 꽤 많이 들었습니다. 브라우저 공급업체들은 그들의 기발함을 조정했습니다. 앵글과 리액트 같은 프런트 엔드 플랫폼은 빠르게 성숙해졌습니다. 프런트 엔드를 구축하는 것이 중요한 직업이 되었고, 이 개발자들은 프로그래밍 플랫폼으로서 자바스크립트를 기피하는 것처럼 보이지 않았습니다. GWT는 관련성을 상실했으며, AI가 이를 예측하거나 수정할 수 있는 방법은 없었습니다. 문제는 코드가 아니라 주변 세계와의 불일치였습니다.