소프트웨어 엔지니어링은 복잡성 관리다

첫 번째 가정에서 실망했습니다. 사람들은 AI가 얼마나 유용한지에 대해 논쟁할 수 있지만, AI가 필수적이지 않다는 것은 분명합니다. 왜냐하면 우리는 몇 년 전에도 AI 없이 코드를 작성할 수 있었기 때문입니다. 오히려 그때 코드가 더 나았다고 말하고 싶습니다.

코드 작성과 소프트웨어 엔지니어링이라는 두 작업은 엔지니어의 정신 모델의 무결성을 손상시키지 않고는 분리할 수 없습니다. 코드와 상호작용하지 않는 아키텍트는 항상 지도와 실제 영토의 불일치를 만들어 냈습니다.

AI는 또한 요구사항을 기반으로 아키텍처를 생성하고 필요한 명확화 질문을 할 수 있습니다.

시스템 설계는 아직 코드 작성만큼 능숙하지는 않지만, 대부분의 동료들보다는 낫다고 느껴집니다.

몇 달 안에 시스템 아키텍처도 클로드 코드의 순간을 맞이하고, 인간은 능가당할 것이라고 생각합니다.

소프트웨어 복잡성은 구성 요소를 추가할수록 초선형적으로, 아니면 지수적으로 증가합니다.

엔지니어가 곡선을 평평하게 만들 수 있는 방법이 있습니다 - 그것이 OP의 복잡성 관리 아이디어입니다 - 하지만 소프트웨어에 무언가를 추가하는 한 복잡성 증가는 결코 선형적일 수 없습니다.

저는 이에 대한 모델/정리를 만들어 X에 게시했습니다: https://x.com/i/status/2027771813346820349

코드 생성은 검증이 소프트웨어 엔지니어링의 핵심 문제임을 드러냈습니다. 그리고 저는 그것이 항상 그래왔다고 생각합니다.

"올바른" 것이 무엇인지 정의하는 것조차 어려울 수 있으며, 검증에 적합한 시스템을 구축하는 것은 말할 것도 없고, 검증에 시간을 투자하는 것은 더욱 어렵습니다. 따라서 소프트웨어를 출시하고 사용자가 버그를 찾게 하는 것은 매우 효율적인 전략입니다. 왜냐하면 그 부담을 분산시키기 때문입니다. 그러나 사용자를 잃는 것과 중요한 버그를 찾고 수정할 충분한 피드백을 얻는 것 사이의 균형을 유지해야 합니다.

AI가 우리의 일자리를 빼앗을지도 모른다는 문제에 직면하면서, 저는 세상이 우리가 상상할 수 있는 가장 크고 가장 잘 훈련된 AI조차 감당하기에는 너무 복잡할지도 모른다는 생각에서 약간의 위안을 얻습니다. 어떤 지점에서는 전 세계(또는 그 상당 부분)를 시뮬레이션해야 하며, 컴퓨팅으로 그 모든 것을 시도하는 비용 대비 이점은 실제 세계(즉, 인간)를 검증자로 사용하는 것보다 가치가 없을 수 있습니다.

때때로 이러한 트레이드오프는 몇 줄의 코드에 대해 여섯 가지 이상을 포함합니다. 그리고 그 점에서 저는 에이전트가 작업하도록 하는 것을 주저합니다. 올바른 코드를 만드는 데는 잘 할 것입니다. 그리고 다른 한 가지를 생각하도록 어느 정도 제한할 수도 있습니다. 그러나 그것은 추적을 잃고, 제약을 무시하고, 속임수를 쓰며, 이를 방지하기 위해 복잡성을 겹겹이 쌓을 것인지, 아니면 수십 줄의 코드를 보고 고칠 것인지 선택해야 합니다.