병렬로 빌드하기

한 번에 여러 작업을 처리하는 능력은 훌륭한 빌더와 탁월한 빌더를 가르는 스킬 중 하나입니다. 이 페이지에서는 이런 방식으로 작업해 본 적이 없더라도, 여러 기능을 안전하게 동시에 빌드하는 방법을 알려드립니다.

​

Agent와 함께 일하는 새로운 방식

지금까지는 아마 옆에 앉은 파트너처럼 Agent와 작업했을 것입니다: 질문하고, 지켜보고, 응답하는 방식이죠. 병렬로 빌드하는 것은 다른 관계입니다. 기능을 **작업(task)**으로 Agent에게 넘기면, Agent는 당신이 다른 일을 하는 동안 백그라운드에서 그것을 빌드합니다. 사실 일상생활에서도 이미 이런 방식으로 일하고 있습니다. 세탁기가 끝날 때까지 그 앞에 서 있지는 않죠. 빨래를 시작하고, 요리를 하러 갑니다. 작업도 마찬가지로 동작합니다: 하나를 시작하고, 그것이 실행되는 동안 다른 것을 시작하거나, 다른 것을 검토하거나, 메인 대화에서 Agent와 계속 채팅할 수 있습니다. 이는 당신의 역할을 바꿔놓습니다. 하나의 빌드를 지켜보는 승객에서, 여러 빌드를 지휘하는 감독이 되는 것입니다.

​

작업이 실행되는 동안 앱은 안전합니다

모두가 가장 먼저 묻는 질문: 보고 있지 않는 사이 백그라운드 작업이 내 앱을 망가뜨리지는 않을까? 아닙니다. 각 작업은 프로젝트의 자체 복사본에서 작업합니다. 작업의 결과물을 검토하고 적용하기로 선택하기 전까지는 앱이 변경되지 않습니다. 각 작업은 또한 자체 Agent를 가지며 프로젝트의 전체 컨텍스트를 물려받으므로, 같은 설명을 반복할 필요가 없습니다. 작업은 서로 독립적이므로, 첫 번째 작업이 실행 중인 순간에도 바로 다음 작업을 시작할 수 있습니다.

​

실제 예시: 세 가지 기능을 동시에

이미 예약과 로그인을 처리하는 렌터카 앱을 상상해 보세요. 여기에 세 가지 기능을 추가하고 싶습니다:

• 이벤트 페이지
• 이벤트 등록
• 문의 양식

하나씩 순서대로 빌드하면 각각 약 5분씩 걸려 총 15분입니다. 병렬로 빌드하면 약 5분이면 됩니다. 각 기능마다 작업을 만듭니다. 작업은 Plan 모드로 시작하므로, 각각 빌드 전에 계획을 보여줍니다. 계획을 승인하고 무슨 일이 일어나는지 지켜보세요: 이벤트 페이지와 문의 양식은 즉시 빌드를 시작하지만, 이벤트 등록은 대기합니다. 이벤트 페이지가 아직 존재하지 않으면 방문자는 이벤트에 등록할 수 없기 때문입니다. Agent는 이 의존성을 스스로 파악하고 프로젝트 매니저처럼 행동하여, 의존하는 작업이 끝난 뒤에 해당 작업을 실행합니다. 한눈에 모든 것을 확인하려면 작업 보드를 여세요. 여기서는 모든 작업이 초안부터 완료까지 실시간으로 열을 이동합니다.

​

작업을 작게 나누기

병렬 빌드를 가능하게 하는 스킬은 기능을 작고 독립적인 작업으로 나누는 것입니다. 작은 작업은 더 빨리 끝나고, 검토하기 쉬우며, 서로 간섭할 가능성도 낮습니다. 유용한 규칙: 작업 설명에 “그리고”가 들어간다면 분할을 고려하세요.

• 좋은 예: “이벤트 페이지 추가”, “문의 양식 추가”
• 너무 큰 예: “이벤트와 등록과 이메일 알림과 관리자 화면 추가”

큰 버전이 틀린 것은 아니지만, 하나의 Agent가 모든 것을 순차적으로 처리하게 만듭니다. 네 개의 작은 작업으로 나누면 Agent가 그것들을 함께 실행할 기회가 생깁니다. 직접 시험해 보세요. 다음 중 병렬로 실행할 수 있는 것은 무엇일까요?

1. 다크 모드 토글 추가
2. 고객 리뷰 섹션 추가
3. 고객이 리뷰에 답글을 달 수 있게 하기
4. 앱을 프랑스어로 번역

정답

작업 1, 2, 4는 서로 독립적이며 모두 동시에 실행할 수 있습니다. 작업 3은 작업 2에 의존합니다: 리뷰가 존재하지 않으면 답글을 달 대상이 없기 때문입니다. 이를 직접 알아챌 필요는 없습니다. Agent가 의존성을 감지해서 두 작업의 순서를 대신 정해줍니다.

​

적용하기 전에 업데이트해야 하는 이유

여기가 모두가 걸려 넘어지는 유일한 개념이니, 천천히 살펴보겠습니다. 두 친구가 각자 같은 파티 초대장 사본을 집으로 가져가 개선한다고 해봅시다. 한 명은 지도를 추가하고, 다른 한 명은 일정을 다시 씁니다. 첫 번째 친구의 버전을 받아들이면 그것이 진짜 초대장이 됩니다. 이제 두 번째 친구의 사본에 문제가 생깁니다: 그의 수정본은 더 이상 존재하지 않는 초대장을 기반으로 하고 있으니까요. 그의 작업을 받아들이기 전에, 그는 최신 버전을 기반으로 다시 작업해야 합니다. 작업도 정확히 이렇게 동작합니다. 각 작업은 시작될 때 프로젝트를 복사했습니다. 한 작업의 변경사항을 적용하는 순간, 다른 모든 작업의 사본은 한 버전 뒤처지게 됩니다. 관련 없는 기능이라면 대개 문제가 없지만, 코드를 직접 읽고 있는 것이 아니므로 두 작업이 같은 부분을 건드리지 않았다고 확신할 수는 없습니다.

​

매니저처럼 검토하기

병렬 빌드는 당신을 매니저로 만들며, 매니저가 흔히 저지르는 실수는 확인하지 않은 작업을 승인하는 것입니다. 지켜야 할 규율은 한 번에 하나씩 진행하는 단순한 루프입니다: 절대 한꺼번에 승인하지 마세요. 검토하지 않은 세 가지 기능을 한 번에 적용하면, 뭔가 이상할 때 용의자가 세 명이 됩니다.

​

순차적으로 진행해야 할 때

병렬 빌드는 도구이지 규칙이 아닙니다. 다음과 같은 경우에는 메인 대화에서 한 번에 하나씩 진행하세요:

• 두 아이디어가 같은 화면을 다룰 때. “홈페이지 재설계”와 “내비게이션 변경”은 충돌합니다. 순서대로 진행하세요.
• 탐색 중일 때. 디자인 작업에서는 한 번의 시도 결과가 다음에 원하는 것을 바꿔놓습니다. 탐색은 작업 지시가 아니라 대화입니다.
• 작업을 한 문장으로 설명할 수 없을 때. 간단히 표현할 수 없다면, 아직 위임할 준비가 되지 않은 것입니다.

​

나만의 한계 찾기

병렬 빌드의 한계를 정하는 것은 Replit이 아닙니다. 바로 당신의 주의력입니다. 작업 사이를 전환할 때마다 집중력이라는 작은 비용을 치르게 되며, 그 예산은 사람마다 다릅니다. 작업 두 개로 시작하세요. 검토가 편하게 느껴지면 세 개를 시도해 보세요. Agent는 충분히 훌륭하게 빌드하므로 모든 단계를 감독할 필요는 없으며, 대부분의 빌더는 전환에 드는 비용보다 속도가 더 가치 있다고 느낍니다. 하지만 이것은 켜고 끄는 설정이 아니라 연습으로 익히는 스킬입니다.

​

다음 단계

• 작업 시스템: 작업이 동작하는 방식에 대한 전체 참조.
• Plan 및 Build 모드: 작업이 계획으로 시작하는 이유.
• 바이브 코딩 101: 작업을 나누는 것을 자연스럽게 만드는, 작게 나누어 빌드하는 마인드셋.