Codex 및 다중 에이전트 작업 흐름: 통제력을 잃지 않고 에이전트와 작업

spinny:~/writing $ vim codex-multi-agent-workflows.md

1~
2코딩 에이전트가 처음으로 버그를 수정해 주었을 때 반응은 거의 항상 같았습니다. 열정과 의심이 뒤섞인 반응이었습니다. 물론이죠. 하지만 차이점을 보고 자문해 보세요. "좋아, 그런데 그 사람이 정확히 무엇을 만졌지? 내가 그를 믿을 수 있을까? 내일 또 같은 방식으로 할 것인가?"
3~
4흥미로운 부분이 시작되는 곳이 바로 여기라고 생각합니다. 에이전트가 함수를 작성할 때가 아니라 저장소 읽기, 패치 생성, 테스트 실행, PR 열기, 검토 의견 후 다시 돌아오는 등 전체 작업을 수행할 수 있을 만큼 충분히 능력을 갖추었을 때입니다. Codex는 백그라운드 작업, 별도의 작업 트리, 통합 브라우저, 자동화, 플러그인, 메모리 및 보다 명시적인 권한 제어와 같은 방향으로 정확하게 움직이고 있습니다.
5~
6요점은 더 이상 아무도 코드를 읽지 않는 미래를 상상하는 것이 아닙니다. 그것은 아주 순진할 뿐만 아니라 끔찍한 미래가 될 것입니다. 요점은 모든 일을 시키지 않고도 많은 일을 할 수 있는 상담원과 협력하는 방법을 알아내는 것입니다.
7~
8## 습관의 변화
9~
10기존의 자동 완성 기능을 사용하면 항상 운전대를 잡았습니다. AI가 라인을 제안하면 당신이 결정합니다. 그러나 에이전트와 함께라면 관계가 달라집니다. 에이전트에게 목표를 제시하면 에이전트는 스스로 여러 단계를 거치게 됩니다.
11~
12이는 강력하지만 문제를 전환시킵니다. 문제는 더 이상 "모델 프로그램이 가능합니까?"가 아닙니다. 질문은 다음과 같습니다.
13~
14- 내가 그에게 충분히 작은 범위를 주었나요?
15- 결과를 확인하는 방법을 알고 있나요?
16- 격리된 환경에서 일하고 있나요?
17- 최종 검토는 여전히 인도적이고 신중합니까?
18~
19건강한 작업 흐름은 마술 지팡이라기보다는 다음과 같습니다.
20~
21```mermaid
22flowchart LR
23    Idea[인간의 임무] --> Scope[작고 검증 가능한 목적]
24    Scope --> Agent[격리된 작업 트리의 에이전트]
25    Agent --> Checks[테스트, 린트, 빌드, 브라우저]
26    Checks --> Review[사람의 검토]
27    Review --> Merge[병합 또는 새 반복]
28    Review --> Iterate[차이점에 대한 정확한 설명]
29    Iterate --> Agent
30```
31~
32"에이전트가 모든 것을 구축합니다"보다 덜 낭만적으로 들리지만 훨씬 더 잘 작동합니다. 또한 명확한 작업, 빠른 피드백, 명시적인 책임 등 인간과 잘 협력하는 팀이 일하는 방식이기도 합니다.
33~
34## 좋은 프롬프트는 거의 좋은 티켓입니다
35~
36가장 위험한 프롬프트는 모호하지만 확신에 찬 프롬프트입니다. "인보이스 페이지 수정", "아키텍처 개선", "인증 모듈 정리". 이는 생산적으로 들리고 엄청난 차이를 생성하는 요청입니다. 그런데 당신은 고고학을 하고 있는 자신을 발견하게 됩니다.
37~
38유용한 프롬프트는 더 지루합니다. 예를 들어, 테이블이 `app/(dashboard)/invoices/page.tsx`에 있고 쿼리가 `src/server/invoices.ts`에 있으며 `app/(dashboard)/reports`에 이미 유사한 패턴이 있다는 것을 알고 송장 페이지에 대한 CSV 내보내기를 구현합니다.
39~
40그런 다음 명확한 제약 조건을 추가합니다. 데이터베이스 스키마를 변경하지 말고 작은 유틸리티로 충분하다면 종속성을 추가하지 말고 기존 UI 스타일을 유지하세요. 그리고 `npm test -- invoices` 및 `npm run build` 확인으로 닫습니다.
41~
42이러한 유형의 브리핑은 "AI에게 더 잘 설명"하기 위한 것이 아닙니다. 이는 무엇보다도 귀하가 위임하는 내용을 더욱 명확하게 하는 역할을 합니다. 구체적으로 기록할 수 없다면 아직 상담원이 작업을 수행할 준비가 되지 않은 것일 수 있습니다.
43~
44## 내가 기꺼이 위임하는 세 가지 직업
45~
46첫 번째는 테스트 추가, 호출을 새로운 내부 API로 마이그레이션, 가져오기 업데이트, 더 이상 사용되지 않는 구성 요소 교체, TypeScript 오류 수정 등 반복적이지만 검증 가능한 작업입니다. 여기서 상담원은 시간을 절약할 수 있으며 위험을 제어할 수 있습니다.
47~
48두 번째는 탐색 작업입니다. "이 합계가 계산되는 위치 찾기", "이 테스트가 왜 취약한지 설명하기", "버그를 재현하고 어떤 파일이 영향을 받는지 알려주기". 패치를 바로 생성하지 않더라도 유용한 정찰을 수행할 수 있습니다.
49~
50세 번째는 반복되는 유지 관리 작업입니다. 소규모 종속성 업데이트, 이전 기능 플래그 정리, 차단된 PR 요약, 잊어버린 TODO 확인 등이 있습니다. 화려하지는 않지만 정확히 쌓이는 경향이 있는 종류의 작업입니다.
51~
52## 내가 사람을 지키는 세 가지 직업
53~
54제품 결정은 인간의 손에 달려 있습니다. 변경으로 인해 사용자가 결제하는 방법, 데이터 삭제하는 방법, 가격 확인하는 방법, 권한 이해하는 방법이 변경되는 경우 책임자가 필요합니다.
55~
56인증, 역할, 토큰, 민감한 데이터 로깅, 데이터베이스 마이그레이션과 같은 보안 경계에도 주의를 기울여야 합니다. 에이전트는 구현을 도울 수 있지만 유일한 의사 결정자가 될 필요는 없습니다.
57~
58마지막으로 건축적인 취향이 필요한 모든 것을 인간적으로 유지합니다. 에이전트는 리팩터링을 제안할 수 있지만 추상화가 실제로 필요한지 또는 존재하지 않는 문제를 해결하는 것인지 이해하는 것은 여전히 작업입니다.
59~
60## 리뷰는 선택사항이 아닙니다
61~
62에이전트가 좋으면 CI의 녹색을 신뢰하고 싶은 유혹이 듭니다. 이해할 수 있습니다. 문제가 시작되는 순간이기도 합니다.
63~
64나는 항상 최소한 다섯 가지를 살펴봅니다.
65~
661. 패치는 요청한 작업만 해결합니까?
672. 관련 없는 파일을 만졌나요?
683. 테스트는 새로운 행동을 다루나요, 아니면 단지 행복한 기회를 다루나요?
694. 코드가 로컬 패턴을 따르나요?
705. 프로젝트의 나머지 부분과 마찬가지로 오류가 처리됩니까?
71~
72뭔가 잘못된 경우 피드백은 구체적이어야 합니다. "수정"은 게으른 일입니다. 더 나은 점: 이 유틸리티는 `parseMoney`을 `src/lib/money.ts`에 복제합니다. 해당 기능을 재사용하고, EUR 사례에 대한 테스트를 추가하고, 청구 모듈의 공개 API를 변경하지 마세요.
73~
74상담원은 작고 검증 가능한 댓글에 훨씬 더 잘 응답합니다. 신기하게도 사람들도 마찬가지다.
75~
76## 노력할만한 가치가 있는 난간
77~
78에이전트가 파일을 읽고, 코드를 작성하고, 명령을 실행할 수 있다면 이는 강력한 프로세스로 간주되어야 합니다. 편집증은 필요하지 않으며 위생이 필요합니다.
79~
80별도의 작업 트리 또는 분기를 사용하십시오. 따라서 차이점을 비교하고, 실패한 실험을 버리고, 에이전트의 작업을 현재 수행 중인 작업과 혼동하지 않을 수 있습니다.
81~
82권한을 제한하세요. `rg`, `git diff`, `npm test` 및 `npm run build`과 같은 명령은 매우 무료일 수 있습니다. 배포, 데이터베이스 마이그레이션, 비밀에 대한 액세스 및 파괴적인 명령은 명시적으로 유지되어야 합니다.
83~
84필요하지 않을 때는 네트워크 액세스를 줄이세요. 많은 작업의 경우 공식 문서, 패키지 레지스트리 및 특정 내부 서비스로 충분합니다. 표면적이 적고 놀라움이 적습니다.
85~
86작업을 추적합니다. 패치가 검토 중에 도착하면 프롬프트, 실행된 명령, 통과한 테스트 및 수정된 파일을 재구성할 수 있어야 합니다. 관료주의를 만들기 위해서가 아니라, 뭔가 잘못되면 무슨 일이 일어났는지 이해할 수 있기 위해서입니다.
87~
88## 팀으로 시작하는 쉬운 방법
89~
90소규모 팀에 에이전트를 도입한다면 큰 변화 없이 시작할 것입니다.
91~
92범위가 명확한 문제에 대해서는 `agent-ready` 라벨을 만들겠습니다. 컨텍스트, 제약 조건 및 확인 명령이 포함된 템플릿을 추가하겠습니다. 이상적으로는 수백 줄 미만의 작은 PR을 요청하겠습니다. 눈에 띄는 변경 사항에 대해서는 테스트나 스크린샷이 필요합니다. 그리고 무엇보다도 나는 합병을 책임지는 사람을 두겠습니다.
93~
942주 후에 저는 데이터를 살펴보았습니다. 어떤 작업이 실제로 속도가 빨라졌는지, 어떤 리뷰가 무거웠는지, 어떤 프롬프트가 혼란스러웠는지, 코드베이스의 어떤 부분이 너무 취약해서 위임할 수 없었습니다.
95~
96"오늘부터 에이전트와 함께 모든 걸 하겠다"보다는 덜 화려한 접근 방식이지만, 3주차까지 후회 없이 갈 수 있게 해주는 접근 방식이다.
97~
98## 가장 인간적인 부분
99~
100재미있는 점은 자율적인 에이전트가 많아질수록 좋은 티켓 작성, 작은 컷 만들기, 테스트 만들기, 차이점 읽기, 장단점 전달과 같은 고전적인 기술이 다시 더 중요해진다는 것입니다. 에이전트는 이미 작업 방법을 잘 알고 있는 사람들을 가속화합니다. 이는 또한 잘못 위임한 사람들의 혼란을 증폭시킵니다.
101~
102아니요, 저는 다중 에이전트 워크플로를 엔지니어링 작업을 중단하는 지름길로 보지 않습니다. 나는 이를 중요한 부분, 즉 무엇을 구축할지 결정하고, 그것이 작동하는지 확인하고, 시스템을 이해하기 쉽게 유지하는 데 더 많은 에너지를 집중시키는 방법이라고 생각합니다.
103~
104에이전트는 훌륭한 비동기식 동료가 될 수 있습니다. 그러나 비동기식 동료가 유용하려면 컨텍스트, 경계 및 검토가 필요합니다. 다른 사람들처럼.
105~
106## 유용한 소스
107~
108- [(거의) 모든 것을 위한 코덱스 - OpenAI](https://openai.com/index/codex-for-almost-everything/)
109- [OpenAI에서 Codex를 안전하게 실행](https://openai.com/index/running-codex-safely/)
110- [Codex 소개 - OpenAI](https://openai.com/index/introducing-codex/)
111- [GitHub Copilot 코딩 에이전트의 새로운 기능](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)
112~

NORMAL · codex-multi-agent-workflows.md [readonly]112 lines · :q to close

2코딩 에이전트가 처음으로 버그를 수정해 주었을 때 반응은 거의 항상 같았습니다. 열정과 의심이 뒤섞인 반응이었습니다. 물론이죠. 하지만 차이점을 보고 자문해 보세요. "좋아, 그런데 그 사람이 정확히 무엇을 만졌지? 내가 그를 믿을 수 있을까? 내일 또 같은 방식으로 할 것인가?"

4흥미로운 부분이 시작되는 곳이 바로 여기라고 생각합니다. 에이전트가 함수를 작성할 때가 아니라 저장소 읽기, 패치 생성, 테스트 실행, PR 열기, 검토 의견 후 다시 돌아오는 등 전체 작업을 수행할 수 있을 만큼 충분히 능력을 갖추었을 때입니다. Codex는 백그라운드 작업, 별도의 작업 트리, 통합 브라우저, 자동화, 플러그인, 메모리 및 보다 명시적인 권한 제어와 같은 방향으로 정확하게 움직이고 있습니다.

6요점은 더 이상 아무도 코드를 읽지 않는 미래를 상상하는 것이 아닙니다. 그것은 아주 순진할 뿐만 아니라 끔찍한 미래가 될 것입니다. 요점은 모든 일을 시키지 않고도 많은 일을 할 수 있는 상담원과 협력하는 방법을 알아내는 것입니다.

8## 습관의 변화

10기존의 자동 완성 기능을 사용하면 항상 운전대를 잡았습니다. AI가 라인을 제안하면 당신이 결정합니다. 그러나 에이전트와 함께라면 관계가 달라집니다. 에이전트에게 목표를 제시하면 에이전트는 스스로 여러 단계를 거치게 됩니다.

11~

12이는 강력하지만 문제를 전환시킵니다. 문제는 더 이상 "모델 프로그램이 가능합니까?"가 아닙니다. 질문은 다음과 같습니다.

13~

14- 내가 그에게 충분히 작은 범위를 주었나요?

15- 결과를 확인하는 방법을 알고 있나요?

16- 격리된 환경에서 일하고 있나요?

17- 최종 검토는 여전히 인도적이고 신중합니까?

18~

19건강한 작업 흐름은 마술 지팡이라기보다는 다음과 같습니다.

20~

21```mermaid

22flowchart LR

23 Idea[인간의 임무] --> Scope[작고 검증 가능한 목적]

24 Scope --> Agent[격리된 작업 트리의 에이전트]

25 Agent --> Checks[테스트, 린트, 빌드, 브라우저]

26 Checks --> Review[사람의 검토]

27 Review --> Merge[병합 또는 새 반복]

28 Review --> Iterate[차이점에 대한 정확한 설명]

29 Iterate --> Agent

30```

31~

32"에이전트가 모든 것을 구축합니다"보다 덜 낭만적으로 들리지만 훨씬 더 잘 작동합니다. 또한 명확한 작업, 빠른 피드백, 명시적인 책임 등 인간과 잘 협력하는 팀이 일하는 방식이기도 합니다.

33~

34## 좋은 프롬프트는 거의 좋은 티켓입니다

35~

36가장 위험한 프롬프트는 모호하지만 확신에 찬 프롬프트입니다. "인보이스 페이지 수정", "아키텍처 개선", "인증 모듈 정리". 이는 생산적으로 들리고 엄청난 차이를 생성하는 요청입니다. 그런데 당신은 고고학을 하고 있는 자신을 발견하게 됩니다.

37~

38유용한 프롬프트는 더 지루합니다. 예를 들어, 테이블이 `app/(dashboard)/invoices/page.tsx`에 있고 쿼리가 `src/server/invoices.ts`에 있으며 `app/(dashboard)/reports`에 이미 유사한 패턴이 있다는 것을 알고 송장 페이지에 대한 CSV 내보내기를 구현합니다.

39~

40그런 다음 명확한 제약 조건을 추가합니다. 데이터베이스 스키마를 변경하지 말고 작은 유틸리티로 충분하다면 종속성을 추가하지 말고 기존 UI 스타일을 유지하세요. 그리고 `npm test -- invoices` 및 `npm run build` 확인으로 닫습니다.

41~

42이러한 유형의 브리핑은 "AI에게 더 잘 설명"하기 위한 것이 아닙니다. 이는 무엇보다도 귀하가 위임하는 내용을 더욱 명확하게 하는 역할을 합니다. 구체적으로 기록할 수 없다면 아직 상담원이 작업을 수행할 준비가 되지 않은 것일 수 있습니다.

43~

44## 내가 기꺼이 위임하는 세 가지 직업

45~

46첫 번째는 테스트 추가, 호출을 새로운 내부 API로 마이그레이션, 가져오기 업데이트, 더 이상 사용되지 않는 구성 요소 교체, TypeScript 오류 수정 등 반복적이지만 검증 가능한 작업입니다. 여기서 상담원은 시간을 절약할 수 있으며 위험을 제어할 수 있습니다.

47~

48두 번째는 탐색 작업입니다. "이 합계가 계산되는 위치 찾기", "이 테스트가 왜 취약한지 설명하기", "버그를 재현하고 어떤 파일이 영향을 받는지 알려주기". 패치를 바로 생성하지 않더라도 유용한 정찰을 수행할 수 있습니다.

49~

50세 번째는 반복되는 유지 관리 작업입니다. 소규모 종속성 업데이트, 이전 기능 플래그 정리, 차단된 PR 요약, 잊어버린 TODO 확인 등이 있습니다. 화려하지는 않지만 정확히 쌓이는 경향이 있는 종류의 작업입니다.

51~

52## 내가 사람을 지키는 세 가지 직업

53~

54제품 결정은 인간의 손에 달려 있습니다. 변경으로 인해 사용자가 결제하는 방법, 데이터 삭제하는 방법, 가격 확인하는 방법, 권한 이해하는 방법이 변경되는 경우 책임자가 필요합니다.

55~

56인증, 역할, 토큰, 민감한 데이터 로깅, 데이터베이스 마이그레이션과 같은 보안 경계에도 주의를 기울여야 합니다. 에이전트는 구현을 도울 수 있지만 유일한 의사 결정자가 될 필요는 없습니다.

57~

58마지막으로 건축적인 취향이 필요한 모든 것을 인간적으로 유지합니다. 에이전트는 리팩터링을 제안할 수 있지만 추상화가 실제로 필요한지 또는 존재하지 않는 문제를 해결하는 것인지 이해하는 것은 여전히 작업입니다.

59~

60## 리뷰는 선택사항이 아닙니다

61~

62에이전트가 좋으면 CI의 녹색을 신뢰하고 싶은 유혹이 듭니다. 이해할 수 있습니다. 문제가 시작되는 순간이기도 합니다.

63~

64나는 항상 최소한 다섯 가지를 살펴봅니다.

65~

661. 패치는 요청한 작업만 해결합니까?

672. 관련 없는 파일을 만졌나요?

683. 테스트는 새로운 행동을 다루나요, 아니면 단지 행복한 기회를 다루나요?

694. 코드가 로컬 패턴을 따르나요?

705. 프로젝트의 나머지 부분과 마찬가지로 오류가 처리됩니까?

71~

72뭔가 잘못된 경우 피드백은 구체적이어야 합니다. "수정"은 게으른 일입니다. 더 나은 점: 이 유틸리티는 `parseMoney`을 `src/lib/money.ts`에 복제합니다. 해당 기능을 재사용하고, EUR 사례에 대한 테스트를 추가하고, 청구 모듈의 공개 API를 변경하지 마세요.

73~

74상담원은 작고 검증 가능한 댓글에 훨씬 더 잘 응답합니다. 신기하게도 사람들도 마찬가지다.

75~

76## 노력할만한 가치가 있는 난간

77~

78에이전트가 파일을 읽고, 코드를 작성하고, 명령을 실행할 수 있다면 이는 강력한 프로세스로 간주되어야 합니다. 편집증은 필요하지 않으며 위생이 필요합니다.

79~

80별도의 작업 트리 또는 분기를 사용하십시오. 따라서 차이점을 비교하고, 실패한 실험을 버리고, 에이전트의 작업을 현재 수행 중인 작업과 혼동하지 않을 수 있습니다.

81~

82권한을 제한하세요. `rg`, `git diff`, `npm test` 및 `npm run build`과 같은 명령은 매우 무료일 수 있습니다. 배포, 데이터베이스 마이그레이션, 비밀에 대한 액세스 및 파괴적인 명령은 명시적으로 유지되어야 합니다.

83~

84필요하지 않을 때는 네트워크 액세스를 줄이세요. 많은 작업의 경우 공식 문서, 패키지 레지스트리 및 특정 내부 서비스로 충분합니다. 표면적이 적고 놀라움이 적습니다.

85~

86작업을 추적합니다. 패치가 검토 중에 도착하면 프롬프트, 실행된 명령, 통과한 테스트 및 수정된 파일을 재구성할 수 있어야 합니다. 관료주의를 만들기 위해서가 아니라, 뭔가 잘못되면 무슨 일이 일어났는지 이해할 수 있기 위해서입니다.

87~

88## 팀으로 시작하는 쉬운 방법

89~

90소규모 팀에 에이전트를 도입한다면 큰 변화 없이 시작할 것입니다.

91~

92범위가 명확한 문제에 대해서는 `agent-ready` 라벨을 만들겠습니다. 컨텍스트, 제약 조건 및 확인 명령이 포함된 템플릿을 추가하겠습니다. 이상적으로는 수백 줄 미만의 작은 PR을 요청하겠습니다. 눈에 띄는 변경 사항에 대해서는 테스트나 스크린샷이 필요합니다. 그리고 무엇보다도 나는 합병을 책임지는 사람을 두겠습니다.

93~

942주 후에 저는 데이터를 살펴보았습니다. 어떤 작업이 실제로 속도가 빨라졌는지, 어떤 리뷰가 무거웠는지, 어떤 프롬프트가 혼란스러웠는지, 코드베이스의 어떤 부분이 너무 취약해서 위임할 수 없었습니다.

95~

96"오늘부터 에이전트와 함께 모든 걸 하겠다"보다는 덜 화려한 접근 방식이지만, 3주차까지 후회 없이 갈 수 있게 해주는 접근 방식이다.

97~

98## 가장 인간적인 부분

99~

100재미있는 점은 자율적인 에이전트가 많아질수록 좋은 티켓 작성, 작은 컷 만들기, 테스트 만들기, 차이점 읽기, 장단점 전달과 같은 고전적인 기술이 다시 더 중요해진다는 것입니다. 에이전트는 이미 작업 방법을 잘 알고 있는 사람들을 가속화합니다. 이는 또한 잘못 위임한 사람들의 혼란을 증폭시킵니다.

101~

102아니요, 저는 다중 에이전트 워크플로를 엔지니어링 작업을 중단하는 지름길로 보지 않습니다. 나는 이를 중요한 부분, 즉 무엇을 구축할지 결정하고, 그것이 작동하는지 확인하고, 시스템을 이해하기 쉽게 유지하는 데 더 많은 에너지를 집중시키는 방법이라고 생각합니다.

103~

104에이전트는 훌륭한 비동기식 동료가 될 수 있습니다. 그러나 비동기식 동료가 유용하려면 컨텍스트, 경계 및 검토가 필요합니다. 다른 사람들처럼.

105~

106## 유용한 소스

107~

108- [(거의) 모든 것을 위한 코덱스 - OpenAI](https://openai.com/index/codex-for-almost-everything/)

109- [OpenAI에서 Codex를 안전하게 실행](https://openai.com/index/running-codex-safely/)

110- [Codex 소개 - OpenAI](https://openai.com/index/introducing-codex/)

111- [GitHub Copilot 코딩 에이전트의 새로운 기능](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)

112~