AI로 만든 앱에서 개발자와 함께 일하는 법

AI로 만든 앱을 개발자와 잘 함께 작업하려면, 코드를 Git 저장소에 넣어 주고, 앱이 무엇을 하고 왜 존재하는지 한 페이지로 요약하고, 완료 기준이 분명한 범위가 정해진 작업을 주세요. 나와 AI가 개발자의 작업을 덮어쓰지 않도록 누가 어느 부분을 바꿀지 합의하고, 저장소와 호스팅 계정은 내 이름으로 유지하며, 비밀 값은 메시지가 아니라 제대로 된 설정을 통해 공유하세요.

많은 사람이 AI로 앱의 첫 버전을 만든 뒤 개발자를 참여시킵니다. 결제를 추가하거나, AI가 계속 틀리는 부분을 고치거나, 보안을 검토하거나, 앱이 커지면서 코드를 넘겨받게 하려는 경우입니다. 아직 개발자를 고용할지 고민 중이라면 개발자를 고용할지, AI로 만들지를 먼저 보세요. 이 가이드는 이미 결정했고, 협업이 순조롭게 되기를 바라는 분을 위한 것입니다.

개발자가 가치 있는 경우

사람을 참여시키는 흔한 이유는 다음과 같습니다.

• AI가 여러 번 명확하게 시도하고 되돌린 뒤에도 해결하지 못하는 문제.
• 위험한 영역: 결제, 권한, 민감한 데이터, 데이터베이스 마이그레이션.
• 출시 전이나 더 큰 고객을 받기 전의 보안 또는 코드 검토.
• 실제 트래픽이 들어온 뒤의 성능 문제.
• 성장: 앱이 사업이 되어 코드를 책임질 사람이 필요해진 경우.

어떤 이유인지 분명히 하면 아래 모든 과정이 수월해집니다.

1단계: 코드를 공유 가능한 곳에 두기

개발자는 Git 저장소를 기준으로 작업합니다. 누군가에게 연락하기 전에 다음을 하세요.

1. 프로젝트를 비공개 GitHub(또는 비슷한 서비스) 저장소에 연결하거나, 프로젝트를 내보내세요.
2. 코드나 기록에 비밀 값이 없는지 확인하세요. API 키를 안전하게 보관하는 법을 참고하세요.
3. 새로 받은 사본에서 프로젝트가 실행되는지 확인하세요. 설치 단계를 AI에게 작성해 달라고 하면 됩니다.

이 프로젝트에 합류하는 개발자를 위한 README를 작성해 줘. 앱이 무엇을 하는지, 사용한 기술 스택, 로컬에서 설치하고 실행하는 방법, 필요한 환경 변수(이름만), 폴더 구조, 그리고 취약하거나 특이한 부분을 포함해 줘.

Git이 낯설다면 AI로 만든 앱에서 Git 사용하는 법에서 기본을 다룹니다.

2단계: 한 페이지짜리 브리프 쓰기

개발자는 내 채팅 기록을 함께 보지 않았습니다. 한 페이지로 맥락을 전달하세요.

• 앱이 무엇을 하는지, 누구를 위한 것인지, 몇 명이 사용하는지.
• 가장 중요한 것 — 절대 깨지면 안 되는 흐름.
• 알려진 문제와 이미 시도한 것.
• 작업 내용과 완료되었다고 판단할 기준.
• 제약 조건: 예산, 기한, 건드리면 안 되는 것.

좋은 "완료 기준"은 테스트할 수 있는 것입니다. "결제를 처리해 줘"가 아니라, "로그인한 사용자가 Stripe Checkout으로 월간 요금제를 결제할 수 있고, 요금제가 계정 페이지에 나타나며, 고객 포털에서 해지하면 기간이 끝날 때 다운그레이드된다"처럼 쓰세요.

3단계: 안전하게 접근 권한 주기

• 코드: 저장소의 협업자로 추가하세요. 작업이 시작된 뒤에는 ZIP 파일을 주고받지 마세요.
• 빌더: AI 앱 빌더가 팀원을 지원한다면, 이 프로젝트만 들어 있는 작업공간에 초대하세요.
• 비밀 값: 호스트의 설정에 추가하거나 비밀번호 관리자로 공유하세요. 키를 이메일이나 채팅에 붙여 넣지 마세요.
• 테스트 계정: 내 로그인 정보를 공유하지 말고, 테스트 데이터를 가진 계정을 새로 만드세요.
• 운영 데이터: 정말 필요한 경우에만, 필요한 만큼만 공유하세요.

저장소, 도메인, 호스팅 계정은 내 이름으로 유지하세요. 사람을 추가하고, 계정 자체를 넘기지 마세요.

4단계: 누가 무엇을 바꿀지 합의하기

가장 큰 마찰은 나와 AI, 그리고 개발자, 두 주체가 같은 코드를 동시에 바꾸는 데서 나옵니다. 규칙을 하나 정하세요.

무엇을 고르든, 프롬프트 작업을 시작할 때마다 최신 코드를 pull 하고, 큰 변경은 상대가 검토할 수 있는 브랜치에서 하세요.

5단계: 글로 소통하기

• 문제는 단계, 기대한 결과, 실제 결과와 함께 보고하세요. 좋은 버그 리포트 작성법을 참고하세요.
• 결정 사항은 한 곳에 모으세요. 이슈 트래커, 공유 문서, 또는 풀 리퀘스트 댓글 등입니다.
• 개발자에게 각 풀 리퀘스트에서 변경 사항을 쉬운 말로 설명해 달라고 요청하세요.
• 얼마나 자주 확인할지 합의하세요.

6단계: 작업 검토하기

작업을 검토하는 데 코드를 읽을 필요는 없습니다. 다음을 확인하세요.

• 브리프대로 동작하는가? 미리보기나 스테이징 사본에서 확인하세요.
• 다른 것이 깨지지 않았는가? 중요한 흐름을 실행해 보세요.
• 무엇을 왜 바꿨는지 설명했는가?
• 코드에 비밀 값이 나타나지 않았는가?

더 자세히 보고 싶다면 AI가 만든 코드를 검토하는 법에 있는 체크리스트를 보세요. 사람이 쓴 코드에도 적용됩니다. 또한 AI 빌더에게 개발자의 풀 리퀘스트를 쉬운 말로 설명해 달라고 요청할 수도 있습니다.

7단계: 소유권을 분명히 하기

• 저장소, 호스팅, 도메인, 제3자 계정은 계속 내 것으로 남아야 합니다.
• 작업을 시작하기 전에, 개발자가 작성하는 코드의 소유권을 서면으로 정하세요. 계약 관련 질문은 현지 법규나 전문가에게 확인하세요.
• 작업이 끝나면 개발자의 접근 권한을 제거하고, 그들이 본 키는 모두 재발급하세요.

예시 프롬프트

개발자가 마지막 풀 리퀘스트에서 결제 코드를 바꿨어. 무엇을 바꿨는지 쉬운 말로 설명하고, 앱의 다른 부분이 이 변경에 의존하는지도 알려 줘.

이 앱에서 가장 복잡하거나 위험한 부분을 나열해 줘. 개발자에게 검토를 어디에 집중할지 알려 줄 수 있게.

이제부터 결제를 개발자에게 넘길 거야. src/payments 아래 파일이나 /api/billing 경로는 건드리지 마. 변경이 필요하다면 나에게 먼저 알려 줘.

흔한 실수

• 브리프가 없음. 개발자가 유료 시간을 들여 내가 원했던 것을 역으로 추적하게 됩니다.
• "버그를 고쳐 줘"나 "출시할 수 있게 만들어 줘" 같은 모호한 범위.
• 먼저 pull 하지 않고 둘이 동시에 편집해서 충돌로 작업을 잃는 경우.
• 내 로그인 정보를 공유하거나 채팅에 키를 붙여 넣는 경우.
• 계정을 개발자의 이름으로 만들어서, 나중에 관계를 정리하기 어려운 경우.
• 작업이 끝난 뒤 접근 권한을 제거하고 키를 재발급하는 것을 잊는 경우.

체크리스트

• 코드는 내 이름으로 된 비공개 저장소에 있고, 비밀 값은 없습니다.
• README가 설치 방법을 설명하고, 한 페이지짜리 브리프가 앱과 작업을 설명합니다.
• 작업에는 테스트 가능한 완료 기준이 있습니다.
• 접근 권한은 협업자 초대로, 비밀 값은 설정이나 비밀번호 관리자로 전달합니다.
• 누가 무엇을 바꿀지 합의했고, 프롬프트 전에 pull 합니다.
• 작업은 브리프와 중요한 흐름에 맞춰 검토합니다.
• 소유권은 서면으로 정해져 있고, 작업이 끝나면 접근 권한을 제거하고 키를 재발급합니다.

Mythex에서 개발자와 함께 작업하기

• 작업공간에 초대하세요. 소유자는 좌석당 요금 없이 협업자를 무제한으로 초대할 수 있고, 구성원은 작업공간의 프로젝트에서 일합니다. 이 프로젝트만 보이도록 별도의 작업공간을 쓰세요. 게시된 앱의 크레딧은 작업공간 소유자에게 청구됩니다. 초대를 참고하세요.
• GitHub 동기화와 내보내기(Pro). 저장소를 연결해 push와 pull을 하거나, 비밀 값을 제외하고 프로젝트를 내보낼 수 있습니다. GitHub, 내보내기, 가져오기를 참고하세요.
• 미리보기 링크 공유. Mythex 계정이 없는 사람에게도 진행 중인 작업을 보여 줄 수 있습니다. 끝나면 링크를 삭제하세요.
• 질문 모드는 코드를 바꾸지 않고 코드에 대한 질문에 답합니다. 개발자의 변경을 이해하는 데 유용합니다.

개발자가 다른 곳에서 앱을 실행할 예정이라면 AI로 만든 앱을 내보내고 직접 호스팅하는 법을 보세요.

자주 묻는 질문