두 프로젝트를 접하면서 몇 년 후 우리가 '소프트웨어'라고 무엇을 의미하게 될지 궁금해졌습니다.
REA는 에이전트(agent)가 애플리케이션과 바이너리를 검사하기 위한 도구에 연결되도록 합니다. 이 워크플로우를 통해 에이전트는 특정 기능이 어떻게 작동하는지 조사하고, 증거를 수집하며, 그 증거를 사용하여 구현을 작성하고 테스트할 수 있습니다.
PhotoCraft는 Rust로 포토샵(Photoshop)의 클린룸 재구현이라고 설명합니다. 아직 초기 알파 단계이지만, 이미 흥미로운 설계 선택을 보여줍니다: 인터페이스와 에이전트가 명령어를 통해 동일한 편집 엔진을 작동할 수 있다는 것입니다.
제가 이 프로젝트들에서 흥미를 느끼는 부분은 애플리케이션 자체에 무슨 일이 일어나는지입니다. 에이전트는 그것이 어떻게 작동하는지 연구하고, 배운 것을 바탕으로 무언가를 만들거나, 그 구성 요소들을 호출하여 작업을 수행하게 할 수 있습니다. 애플리케이션 자체가 다른 무언가의 재료처럼 보이게 됩니다.
우리가 알고 있는 소프트웨어의 상당 부분은 미리 작성된 규칙들로 이루어져 있습니다. 동일한 조건에서는 동일한 입력이 동일한 출력을 생성합니다. 우리는 이 점을 신뢰할 수 있도록 만드는 데 많은 노력을 기울여 왔습니다. 프로그램을 사용하려면, 그 명령어들을 배우고 원하는 것을 얻기 위해 어떤 명령어들을 사용할지 알아내야 합니다.
또한 그것이 어디서 멈추는지도 배웁니다. 만약 필요한 것이 그 규칙들 밖에 있다면, 다른 프로그램을 찾거나, 기존 프로그램을 변경하거나, 직접 작업을 수행해야 합니다. 이미지 편집기는 왜 사진을 크기를 조정해야 하는지, 또는 다음에 무엇을 할 것인지 알 필요 없이 단순히 크기만 조정할 수 있습니다.
그 예측 가능한 동작 방식은 에이전트가 연구할 무언가를 제공합니다. 입력을 변경하고, 출력을 관찰하고, 설명을 제안하며, 구현을 원본과 비교하는 것입니다. 프로그램의 동작 방식은 다른 프로그램을 만드는 예시의 원천이 됩니다.
저는 AI가 발전함에 따라 이러한 종류의 재구성이 쉬워질 것이라고 예상합니다. 제가 탐구하고 싶은 질문을 위해, 우리는 그렇게 될 수 있다고 가정할 수 있습니다. 친숙한 도구를 만드는 것이 평범하게 요청되는 일이 된다면 무슨 일이 벌어질까요?
에이전트를 사용하면 더 큰 작업을 설명하고 에이전트가 그 단계들을 스스로 해결하도록 할 수 있습니다. 에이전트는 어떤 도구를 사용할지, 그리고 그 결과로 무엇을 할지 결정합니다. 이는 부분적으로 모든 연산을 명시할 필요가 없다는 점에서 유용합니다. 또한 다시 요청했을 때 다른 행동 순서나 다른 결과를 얻을 수도 있다는 의미입니다.
여기에는 또 다른 어색한 가능성이 있습니다. 현재 AI가 스스로 처리할 수 없는 작업에 맞춰 에이전트를 구축했지만, 다음 세대에서는 그 작업을 할 수 있게 되어버리는 경우입니다. 별도의 프롬프트와 도구 배열로 이루어졌던 것이 평범한 요청으로 변해버립니다.
그리하여 고정된 프로그램은 재현하기 쉬워지는 반면, 에이전트의 능력은 의존하는 AI 자체의 일부가 될 수 있습니다. 소프트웨어가 독립적인 존재로서 존재할 이유를 잃어가는 것처럼 보이기 시작합니다. 우리는 도구를 요청하고, 그것을 얻고, 사용한 다음, 다음으로 넘어갑니다. 그렇다면 소프트웨어 엔지니어링이나 소프트웨어 산업은 어디로 가게 될까요?
잠시 컴퓨터는 제외하고 철에 대해 생각해 보는 것이 유용하다고 생각했습니다.
쟁기, 검, 또는 호미를 만드는 작업장을 상상해 보세요. 각 물체는 완전한 도구입니다. 그 금속이 사람이 집어 들고 사용할 수 있는 무언가로 모양을 갖추었습니다. 그것을 보고 무엇에 사용되는지 대략적으로 이해할 수 있습니다.
이제 전기 모터 내부의 금속 부품이나 다른 금속 부품을 자르는 기계를 생각해 보세요. 일부는 작아서 정밀하게 맞춰져야 합니다. 축(shaft) 자체만으로는 전체 기계가 할 수 있는 작업에 대해 훨씬 적게 알려줍니다. 부품들 간의 연결이 더 중요합니다.
대장장이의 도구와 공작 기계의 도구는 익숙한 재료로 만들어집니다. 하지만 작업 자체가 충분히 변해서, 그 부품들을 만드는 것은 다른 장비를 요구하게 됩니다. 단순히 누군가 호미를 얼마나 더 빨리 만들 수 있는지 묻는 것만으로는 변화에 대한 유용한 그림을 얻을 수 없습니다.
전기는 이러한 장치들에 새로운 용도를 부여합니다. 여기에 전자 제어와 소프트웨어를 더하면, 우리가 만들 수 있는 것들은 다시 변화할 것입니다. 시계는 기계 부품들이 암시하는 것보다 더 많은 것을 할 수 있습니다. 휴대폰이나 컴퓨터는 그 유용성이 내부에서 실행되는 명령어에 달려있는 물리적 구성 요소를 담고 있습니다.
이 비교에서 제가 빌려오고 싶은 것은, 각 추가 요소가 다음 요소에게 나아갈 곳을 제공한다는 방식입니다. 금속 부품들은 전기를 운반하고 기계를 가능하게 합니다. 전자 장비는 소프트웨어가 실행될 공간을 제공합니다. 소프트웨어는 AI가 파일과 기계에 접근할 수 있게 하고, 이를 통해 사람들이 수행하는 작업까지 연결해 줍니다.
이전 요소들은 새로운 사물들 안에 남아 있습니다. 우리는 그것들을 완전한 제품으로서 덜 주의 깊게 살펴봅니다. 우리는 전체적인 것이 우리에게 무엇을 할 수 있게 하는지에 관심을 갖습니다.
AI가 이 과정에 합류하면 어떤 일이 일어날까요?
오래된 게임이나 이미지 편집기를 재현하는 것은 이해할 만한 시작점입니다. 우리는 그것들이 무엇인지 알고 있습니다. 우리는 성공을 인식할 수 있습니다. 그러나 전기를 가진 사람들은 또 다른 쟁기질만 만드는 것에 만족하지 않았고, 소프트웨어를 가진 사람들도 오래된 발전기의 제어 장치를 복제하는 데 모든 노력을 쏟지 않았습니다. 만들 다른 것들이 있었습니다.
저 역시 우리가 이미 가지고 있는 소프트웨어를 재현하는 것에 만족할 것이라고는 의심합니다.
작은 전시회를 준비한다고 가정해 봅시다. 사진 폴더, 캡션 스프레드시트, 액자 치수 측정이 있습니다. 당신은 사진들이 어떻게 배치될지 보고, 다른 크롭이 필요한 것을 찾고, 인쇄할 라벨을 준비하고 싶습니다. 에이전트는 이미지 작업을 위해 기존 편집기를 사용하고, 파일 이름을 스프레드시트에 맞추는 작은 프로그램을 만들 수 있습니다. 액자 크기가 변경되면, 영향을 받은 단계를 다시 실행할 수 있습니다.
이것은 이미 스크립트로 할 수 있습니다. 제가 흥미를 느끼는 부분은 다른 일을 하는 도중에 그것들을 요청하는 것이 평범해질 때 무슨 일이 일어나는가입니다. 캡션과 일치하는 프로그램을 절대 열지 않을 수도 있고, 심지어 이름을 붙여주지도 않을 수 있습니다. 이 프로그램은 특정 전시회에 필요하기 때문에 존재합니다. 작품 속에는 애플리케이션처럼 보이지 않는 소프트웨어가 엄청나게 많을 수 있습니다.
전시회는 이해하기 쉬운 예시입니다. 왜냐하면 우리는 이미 그 작업을 알고 있기 때문입니다. 저는 사람들이 도중에 도구를 만들 수 있게 된 후에 시도할 만한 프로젝트에 더 궁금합니다. 처음부터 전체 프로젝트가 어떤 애플리케이션 안에 들어가야 하는지 선택해야 할 필요가 없다면 사람들은 무엇을 시도할까요?
작은 조각들도 여전히 까다로운 작업을 가질 수 있습니다. 전시회에서 '크롭(crop)'은 다른 도구가 정확하게 해석해야 하는 좌표 집합입니다. 두 도구 모두 그 좌표가 어떤 이미지에 해당하는지, 그리고 픽셀 단위로 측정되는지 아니면 다른 단위로 측정되는지에 대해 동의해야 합니다. 만약 한 도구가 원본 이미지에서 측정하고 다른 도구가 크기 조정된 복사본에서 측정한다면, 크롭은 잘못된 위치에 놓이게 됩니다.
제가 염두에 두고 있는 바로 이런 종류의 정밀성입니다. 소프트웨어 조각은 주변의 조각들에 맞아야 합니다. 만약 에이전트가 사람의 감시 없이 이 많은 조각들을 조립할 계획이라면, 각 조각이 무엇을 하는지에 대한 느슨한 설명은 덜 유용해질 것입니다. 우리는 명시적인 입력과 출력, 그리고 그 조각들이 함께 작동하는지 확인할 방법들을 원하게 될 것입니다.
이는 우리가 처음에 시작했던 예측 가능한 행동으로 돌아옵니다. 이는 에이전트에게 재현할 무언가를 주고, 다음 프로그램에게 의존할 무언가를 줍니다. 소프트웨어 조각은 교체하기 더 쉬워질 수 있는 동시에, 그것이 유용하게 쓰일 훨씬 더 많은 장소들을 찾게 될 것입니다.
이는 저를 기계 공방으로 되돌아갑니다. 충분한 부품을 만들게 되면, 그것들을 만들고 검사하는 장비에 더 많은 노력을 기울이게 됩니다. 저는 소프트웨어에서도 비슷한 일이 있을 것이라고 예상합니다. 프로그래머는 에이전트가 도구를 지정하는 방식에 대해 작업하고, 의도된 사용 사례를 기반으로 테스트할 수 있습니다. 여기서 개선 사항은 그것이 만드는 모든 도구로 이어질 수 있습니다. 각각을 손으로 작성하는 것은 점점 노력을 쏟기에는 어색한 일이 될 것입니다.
그리고 그보다 훨씬 더 많은 것들이 있을 수 있습니다. 전시회는 작은 작업입니다. 아마도 이를 위해 애플리케이션을 의뢰하지 않을 것입니다. 파일 이름을 바꾸고, 캡션을 복사하고, 사진들을 직접 확인하는 식일 겁니다. 우리가 컴퓨터에서 하는 일 중 상당 부분은 이러한 특성을 가집니다. 짜증 날 정도로 반복적이지만, 소프트웨어를 작성할 만큼은 부족한 정도입니다.
만들고 검사하는 도구가 충분히 저렴해지면, 그 작업의 일부는 자동화할 가치가 생깁니다. 어느 오후에 사용되는 도구라도 제값을 할 수 있습니다. 이것이 제가 AI가 소프트웨어의 수요를 증가시킬 것이라고 예상하는 이유입니다. 이는 현재 도구를 만드는 비용이 작업을 수행하는 것보다 더 많이 들기 때문에, 우리가 사람에게 맡기는 일들에 소프트웨어를 사용할 수 있게 해줄 것입니다.
저는 처음에 소프트웨어가 사라질 가능성에서 출발했습니다. 하지만 이제는 그 반대를 기대하게 되었습니다. 즉, 이전에 제품을 지원하기에는 너무 특정한 용도를 위해 더 많은 작은 조각들로 만들어지는 소프트웨어 말입니다. 오늘날 우리가 인식하는 애플리케이션들은 과정에서 상당히 많이 바뀔 수 있습니다.
그렇다면 그것들을 만드는 사람들에 대한 이야기가 남습니다. 대장간 작업장에서 기계 공방으로의 이동은 장비와 사용에 필요한 기술을 변화시켰습니다. 한 사람은 여전히 금속으로 물건을 만들면서도, 그 일이 대장장이가 거의 인식하지 못할 만한 일을 하고 있을 수 있었습니다.
프로그래머 역시 비슷한 변화를 겪을 수 있습니다. 직업의 더 많은 부분이 소프트웨어를 만드는 기계를 조작하고 개선하는 것을 포함하게 될 것입니다. 여전히 무엇이 만들어질 가치가 있는지, 그리고 그 결과가 작업을 수행하는지 어떻게 판단해야 하는지를 결정할 누군가가 있어야 할 것입니다. 배울 것이 많겠지만, 이 모든 것을 프로그래밍이라고 부르는 것이 이상하게 느껴질 수도 있습니다.
워크숍 비교가 얼마나 오래 지속될지는 모르겠습니다. 하지만 이는 오늘날 우리가 수작업으로 하는 작업에 대해 의문을 품게 합니다. 왜냐하면 이를 위한 프로그램을 작성하는 것이 너무 큰 노력이 될 것이기 때문입니다. 만약 그러한 업무들이 자체적인 소프트웨어를 갖기 시작한다면, 우리는 얼마나 많은 소프트웨어를 가지게 될까요? 그리고 프로그래머의 하루 중 얼마나 많은 시간이 여전히 그것을 작성하는 데 쓰일까요?
AI가 영어 초안 작성 및 편집에 도움을 주었습니다.
StratCraft에서 저를 찾아주세요 | GitHub