> ## Documentation Index
> Fetch the complete documentation index at: https://docs.replit.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 병렬로 빌드하기
> 병렬 작업으로 여러 기능을 동시에 빌드하는 방법을 알아보세요: 안전하게 위임하고, 작업을 작게 나누고, 예상치 못한 문제 없이 변경사항을 적용합니다.
한 번에 여러 작업을 처리하는 능력은 훌륭한 빌더와 탁월한 빌더를 가르는 스킬 중 하나입니다. 이 페이지에서는 이런 방식으로 작업해 본 적이 없더라도, 여러 기능을 안전하게 동시에 빌드하는 방법을 알려드립니다.
## 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는 충분히 훌륭하게 빌드하므로 모든 단계를 감독할 필요는 없으며, 대부분의 빌더는 전환에 드는 비용보다 속도가 더 가치 있다고 느낍니다. 하지만 이것은 켜고 끄는 설정이 아니라 연습으로 익히는 스킬입니다.
## 다음 단계
* [작업 시스템](/ko/core-concepts/agent/task-system): 작업이 동작하는 방식에 대한 전체 참조.
* [Plan 및 Build 모드](/ko/learn/plan-vs-build-mode): 작업이 계획으로 시작하는 이유.
* [바이브 코딩 101](/ko/learn/foundations/vibe-coding-101): 작업을 나누는 것을 자연스럽게 만드는, 작게 나누어 빌드하는 마인드셋.