개인용 소프트웨어 공장, 그거 시간 낭비다

그가 맞다고 생각한다. 소프트웨어 공장은 어느 정도 자연스럽게 생겨나야 한다. 프로젝트를 시작할 때 "음, 이걸 더 빠르게 하려면 먼저 소프트웨어 공장을 만들어야지"라고 말해서는 안 된다. 에이전트를 지시하면서 물건을 만드는 것부터 시작하라. 같은 것을 계속 반복해서 쓰고 있는 자신을 발견하면, 그것을 스킬로 만들고 매크로처럼 생각하고 다루어야 한다. 어떤 스킬이 언제 호출되는지에 대한 명확한 패턴이 발전하고 있는 자신을 발견하면, 본질적으로 그 결정들과 관련 정보들을 예쁜 인터페이스 뒤에 두는 소프트웨어 공장을 시작할 때일지도 모른다.

내 소프트웨어 공장은 그런 식으로 생겨났고, 내가 작업하는 더 단순한 작업의 50-70%에 대해 이것은 나에게 엄청난 시간을 절약해 주며, 더 중요하게는 정신적 부담을 덜어 준다.

블로그 글 내용에서 내가 얻은 것은, 저자가 자기 독자와 끊임없이 싸우고 있다는 것이다. 나는 그것을 이렇게 요약하겠다. "나는 당신의 시도가 어리석다고 생각하고 당신은 그걸 하지 말아야 하지만, 나는 당신의 상사가 아니니 누가 신경 쓰겠는가, 하지만 그것은 나쁜 생각이다, 하지만 유용할 수도 있다, 하지만 당신은 그걸 하지 말아야 한다."

소프트웨어 공장(다시 말해, 작업을 코드/기능으로 바꾸는 루프를 위한 일종의 개념적 프레임워크)에 대한 계획이 있다면, 시도해 봐야 한다고 생각한다. 내 의견은, 당신의 구현이 완전히 실패하거나 개념 증명 단계를 넘어서지 못하더라도, 적어도 세상에 무엇이 있는지 그리고 당신이 무엇을 시도했는지에 대해 스스로를 알게 하는 무언가를 해본 것이다.

[이번 분기의 최전선 모델]이 Marvel + Bioshock + Ted Lasso + Command and Conquer, 또는 Nikita Bier 같은 사람들이 그토록 좋아하는 그 무시무시한 Consumptionslop™ 같은 걸 할 수 있다는 이유로 프롬프트 노예 신세로 전락하기보다는, 당신의 지식에 깊이를 더해 주는 겨우 시작만 한 프로젝트들의 묘지를 남기는 편이 낫다.

내가 듣기로는 사람들이 소프트웨어 공장이라는 말 아래 서로 다른 것을 이해하고 있는 것 같다.

나는 소프트웨어 공장이 '모든 것은 코드다'라는 주문의 다음 단계일 뿐이라고 믿는다.

사람들은 기능 설명과 인수 기준을 가능한 한 모호하고 세부 사항이 적게 "상자" 안에 쓰고 싶어 한다.

이를 가능하게 하려면, 환경이 요구하는 대로 도메인, 요구 사항, 소프트웨어 스택에 대한 정보 접근 권한을 공장에 만들어 준다.

그리고 이것을 모두 AI에 최적화된 도구, 문서, 프로세스로 시도한다.

모두 토큰과 컨텍스트를 덜 쓰고 에이전트가 취하는 모든 행동을 가능한 한 빠르게 하려는 목표를 가지고.

그래서 이것을 독단적인 해법으로 자동화하려는 플러그인 기반의 자기 진화형 하네스에 대한 트렌드가 있는 것이다.

따라서 더 쉬운 테스트와 더 적은 토큰 사용을 위한 도구를 만드는 것이 시간 낭비라고 볼 이유가 없다. 특히 자신의 업무에서 자동화할 수 있는 영역을 점점 더 많이 배우게 되고, 도구 선택에 따라 당신의 입력 없이도 가능할 수 있으며, 그런 점에서 당신의 입력이 공장을 개선할지 아닐지를 실험할 기회를 놓치기 때문이다.

그 정서에는 전적으로 동의하지만, 이건 허수아비를 공격하는 건가, 아니면 사람들이 정말로 "소프트웨어 공장"을 만들고 있는 건가? LLM 맥락에서 이 용어를 본 것은 이번이 처음이다. LLM 위에 소프트웨어 공장이라니, 대체 어떤 모습일까?