Transcript
00:00:00이것은 OpenAI의 Symphony입니다. 장기 실행 에이전트를 오케스트레이션하기 위한 오픈 소스 도구로,
00:00:05Linear와 같은 기존 이슈 트래커를 사용하여 에이전트가 사람의 감독 없이
00:00:10자율적으로 작업을 완료하도록 돕습니다. 그런데 왜 사용하기 전에 에이전트가 직접 구축해야 할까요?
00:00:14Codex CLI만 지원하는 걸까요? 그리고 이것이 OpenAI가 내놓을
00:00:18더 많은 오픈 소스 도구의 시작일까요? 구독을 누르고 함께 알아봅시다.
00:00:25Symphony가 탄생한 이유는 OpenAI가 '인간의 주의력 병목 현상'에 직면했기 때문입니다.
00:00:30즉, 엔지니어들이 생산성에 부정적인 영향을 주는 컨텍스트 스위칭이 발생하기 전까지
00:00:35동시에 감독할 수 있는 Codex 세션이 3~5개뿐이었다는 뜻이죠. 당연히 확장이 불가능했습니다.
00:00:41그렇다면 OpenAI는 이 '빠른 에이전트와 느린 인간 관리자' 문제를 어떻게 해결했을까요?
00:00:47인간 관리자를 없애버렸습니다. 어느 정도는요. Symphony를 사용하면 인간은 보드에 작업을 올리고,
00:00:52새로운 에이전트가 생성되어 작업을 완료하며, 검토가 필요한 경우에만 인간을 부릅니다.
00:00:55하지만 Symphony는 Multica나 Conductor 같은 유사 도구와 어떻게 다를까요?
00:00:58데모를 보시면 아주 명확해질 겁니다. 시작하기 전에 한 말씀 드리자면,
00:01:03Symphony는 제 평생 본 것 중 가장 이상한 설치 과정을 가지고 있습니다. 아니면
00:01:07가장 천재적인 설치 방법일 수도 있죠. 그건 나중에 다루겠습니다.
00:01:10우선 기본적인 예시부터 살펴보죠. Symphony를 실행하여
00:01:14Linear에서 처리할 작업을 폴링하고 있습니다. 이제 Linear에서 새 이슈를 생성하겠습니다.
00:01:18내용은 TypeScript와 BUN을 사용하여 Hello World 앱을 빌드하는 것입니다.
00:01:22현재 Symphony는 백로그 작업을 처리하도록 설정되지 않았습니다. 상태를 To-Do로 바꾸고
00:01:27이슈 생성을 누릅니다. 작업 ID인 SYN7을 기억해 두세요.
00:01:31잠시 후 Symphony가 해당 작업의 ID를 감지합니다. 그리고 몇 초 후,
00:01:36GraphQL 유효성 검사 오류가 발생하지만, 큰 문제는 아니며 Codex가 쉽게 수정할 수 있습니다.
00:01:41수정 후에는 Codex가 작업을 완료하고, 이슈 상태를
00:01:45To-Do에서 Done으로 변경했으며, Symphony에서 남긴 코멘트를 볼 수 있습니다. 즉,
00:01:49Symphony 워크스페이스 디렉토리로 이동하면 (이에 대해선 나중에 더 자세히 설명하죠),
00:01:53이슈와 동일한 ID의 새 워크스페이스를 볼 수 있습니다. 그 워크스페이스 안에는
00:01:58Hello World TypeScript BUN 앱을 위해 생성된 파일 목록이 있습니다. source 디렉토리로 가면
00:02:04앱 코드가 여기 있는 것을 확인할 수 있죠. 이것이 Symphony의 핵심입니다.
00:02:08이제 설정 방법을 살펴보겠습니다. 해당 레포지토리에 따르면
00:02:12Symphony를 설치하는 두 가지 방법이 있습니다. 옵션 2는 우리에게 익숙한 방식으로, Elixir를 설정하고
00:02:16레포를 클론한 뒤, 기존 워크플로우 파일을 사용하여 코드를 빌드하고 실행하는 것입니다.
00:02:20하지만 옵션 1은 아마도 가장 이상하거나 혹은 가장 미래 지향적인 설치 방식일 것입니다.
00:02:25기본적으로 코딩 에이전트에게 이 프롬프트를 주기만 하면 됩니다. 그러면 에이전트가 스펙 파일을 읽는데,
00:02:30이 파일은 2,000행이 넘습니다. 하지만 여기에는 에이전트가 Symphony를 빌드하는 데 필요한
00:02:34상세 지침이 담겨 있습니다. 이는 놀라운 일인데, 모든 사람이 이 방식을 따른다면
00:02:39똑같이 생긴 Symphony 버전은 하나도 없을 것이기 때문입니다. 사람마다 서로 다른 언어로
00:02:43서로 다른 기능을 가질 것이고, OpenAI가 이를 유지보수하고 지원하기엔 혼란스럽겠죠.
00:02:47하지만 한편으로는 천재적입니다. 자신만의 Symphony 버전을 직접 빌드했다면
00:02:51책임감을 느낄 테니까요. 버그를 고치고 기능을 추가하며 직접 유지보수하게 될 겁니다.
00:02:55만약 Symphony가 Linear나 Codex를 사용하지 않기를 원한다면 그것도 자유입니다.
00:02:59누군가는 Charm CLI에서 실행되는 Go 버전의 Symphony를 빌드했고,
00:03:04다른 이는 Claude SDK로 구동되는 버전을 만들었습니다. 저는 그렇게 창의적이지 못해서
00:03:09GPT 5.5 Low Effort를 사용하는 Codex에 기본 프롬프트를 넣었고, Python 버전의
00:03:15Symphony를 얻었습니다. LLM이 Python에 매우 능숙하니 당연한 결과죠. 빌드가 완료되면
00:03:19Linear 개인 API 키가 필요한데, 보안 및 액세스 메뉴에서 가져올 수 있습니다.
00:03:23여기를 클릭하여 생성할 수 있죠. 그다음 해당 키를 워크 프로필에 추가해야 합니다.
00:03:28워크 프로필은 Symphony가 작업을 수행하는 법을 알려주는 파일로, YAML 프런트 매터를 포함하며
00:03:32당연히 API 키, 에이전트가 작업 가능 여부를 알 수 있는 활성 상태값,
00:03:37그리고 워크스페이스 루트와 Codex 명령어가 들어갑니다. Codex 명령어는 Symphony가
00:03:42코딩 에이전트를 실행하는 쉘 명령어입니다. 그 아래에는 각 이슈마다
00:03:46코딩 에이전트에게 보낼 마크다운 프롬프트가 있습니다. 관심 있다면 OpenAI 레포에서 해당 파일을 볼 수 있습니다.
00:03:51하지만 현재로선 이 워크플로우가 실제 프로젝트에 적합하진 않습니다. 가령 제가 작업 중인
00:03:56필름 에뮬레이션 앱을 수정하고 싶다고 합시다. Symphony가 이슈용 워크스페이스를 생성한 후 실행되는
00:04:01create-after 훅을 추가해야 합니다. 이 훅은 먼저 레포지토리를 워크스페이스 디렉토리로
00:04:06클론한 뒤, 새 브랜치를 체크아웃합니다. 또한 run-after 훅도 추가했습니다.
00:04:10이 훅은 Codex가 이슈 작업을 마친 후 실행됩니다. 파일들을 스테이징하고
00:04:15새 커밋을 생성한 뒤 브랜치를 푸시하고, 지정된 값으로 새 풀 리퀘스트를 생성합니다.
00:04:20이제 OpenAI가 인수한 UV(이건 나중에 다루죠)를 사용하여 Symphony를 실행하면,
00:04:25새 이슈를 폴링하기 시작합니다. 여기서 리드미 파일을 업데이트하는 새 이슈를 만들어 보겠습니다.
00:04:30일괄 처리 섹션에서 여러 파일을 보여주는 대신 와일드카드를 사용하도록 수정하는 내용입니다.
00:04:35다시 상태를 백로그에서 To-Do로 바꾸고 이슈 생성을 누릅니다. 이제 Symphony가 해당 이슈를
00:04:40가져왔습니다. Symphony 워크스페이스 디렉토리를 보면 이슈 ID와 일치하며
00:04:45프로젝트가 클론된 새 폴더가 보입니다. Symphony가 이슈 작업을 마친 후에는
00:04:49상태를 Done으로 변경하고, Linear 티켓 링크와 요청한 수정 사항이 포함된 새 PR을 생성했습니다.
00:04:54물론 Symphony 코드를 수정하여 더 나은 PR 설명을 추가하거나 코멘트에 PR 링크를 넣을 수도 있지만,
00:04:59그건 Codex가 아주 쉽게 할 수 있는 일입니다. 지금까지 Symphony에 대한 간략한 개요였습니다.
00:05:04이미 Linear를 사용 중인 회사의 개발자라면 이 인터페이스가 매우 익숙할 것입니다.
00:05:08또한 Codex 사용자라면 기존에 설치된 기술, MCP 도구, 플러그인을 그대로 사용할 수 있습니다.
00:05:13저는 개인적으로 Codex를 쓰지 않지만, OpenAI가 Symphony를 통해 그리려는 비전은 확실히 보입니다.
00:05:18AI와 함께 동일 프로젝트를 진행하는 개발팀이 있다고 상상해 보세요. 개별적인 워크플로우를
00:05:22가진 각자의 도구 대신, 중앙화된 기술과 도구, 워크플로우, 플러그인을 갖춘
00:05:28중앙 에이전트가 존재할 수 있습니다. 각 개발자는 에이전트에게 작업을 주며 소통할 수 있고,
00:05:33다른 개발자가 무엇을 하는지, 어떤 프롬프트를 썼는지 확인하며 자신이 작업 중인 기능에
00:05:37영향을 줄 수 있는 다른 요소들을 한눈에 파악할 수 있습니다. 사실 다른 사람이 작업 중인 코드에
00:05:41영향을 주지 않는 기능을 만드는 것은 매우 어려운 일이니까요. 하지만 Symphony가 멋지긴 해도,
00:05:46제 생각에 Multica가 더 낫습니다. 설정이 더 쉽고 에이전트를 추가하기 용이하며
00:05:49작업 예약도 가능하기 때문입니다. 그럼에도 불구하고 Symphony의 자리는 분명히 있습니다.
00:05:54이미 만들어진 제품 대신 원하는 기능을 정확히 추가할 수 있는 Multica의 뼈대 버전 같으니까요.
00:05:59Symphony를 Pi harness라고 생각한다면, Multica나 Conductor는 Claude Code 같은 도구로
00:06:04비유할 수 있겠네요. 만약 Multica에 대해 전혀 모르신다면, 모든 정보를 다룬
00:06:08그러니 Symphony를 파이 하네스로, Multica나 Conductor 같은 도구들은 기성 코드로 생각하세요.
00:06:13Multica에 대해 전혀 모르신다면, 모든 필수 정보를 다룬
00:06:18이 영상을 확인해 보세요.