개발자를 위한 프로젝트

개발자를 위한 AI 프로젝트

코드, 문서, 스크린샷, 티켓을 연결해 AI가 답변하기 전에 저장소를 이해하도록 하세요.

핵심 아이디어

AI가 여러분의 업무를 짐작하게 하지 마세요. 프로젝트를 통째로 건네세요.

개발자라면 이미 아는 문제입니다. AI는 독립된 함수 하나는 그럭저럭 잘 작성하지만, 답이 프로젝트 아키텍처, 코딩 규칙, 기존 파일, 패키지 선택, 과거 결정에 좌우될 때는 실패합니다.

MultipleChat 프로젝트에서는 GitHub에서 저장소 파일을 가져오고, 문서를 업로드하고, 스크린샷이나 오류 로그를 추가하고, 기술 스택을 설명하는 프로젝트 지침을 만들 수 있습니다. 그러면 AI는 모호한 프롬프트로 짐작하는 대신, 답변하기 전에 관련 청크를 검색합니다.

무엇을 업로드할까

답변에 꼭 필요한 파일부터 시작하세요.

AI 프로젝트가 실패하는 흔한 이유는 업로드한 자료가 너무 적기 때문입니다. 사람 전문가에게 원자료가 필요하다면, 프로젝트에도 필요합니다.

GitHub 저장소 파일, 중요한 모듈과 설정 파일

README 파일, 아키텍처 노트, API 문서

오류 로그, 스택 트레이스, 실패한 테스트 출력

UI 버그 스크린샷, 제품 요구 사항, Figma 노트

데이터베이스 스키마, SQL 파일, JSON 예시, 연동 문서

프로젝트 지침

여러분의 직군이 어떻게 생각하는지 프로젝트에 알려 주세요.

같은 파일이라도 지침에 따라 답변이 크게 달라질 수 있습니다. 기대 사항을 한 번만 설정해 두면 모든 모델이 소스, 불확실성, 형식을 어떻게 다룰지 알게 됩니다.

기존 아키텍처와 명명 규칙을 따르세요.

파일이나 API를 지어내지 마세요. 저장소 맥락이 부족하면 질문하세요.

작은 패치를 우선하고, 대규모 리팩터링 전에는 장단점을 설명하세요.

확실하지 않을 때는 어떤 소스 파일이나 설정을 확인해야 하는지 밝히세요.

빠른 수정, 견고한 수정, 장기적 리팩터링 옵션을 구분해 제시하세요.

플레이북

가장 먼저 실행해 볼 다섯 가지 워크플로.

이론적인 기능 설명이 아닙니다. 개발자가 프로젝트를 만든 뒤 가장 먼저 시도해 볼 실용적인 워크플로입니다.

워크플로 1

코드베이스 프로젝트 만들기

README, 핵심 모듈, 패키지 파일, 설정, 아키텍처 문서부터 시작하세요. GitHub를 연결한다면 가져온 저장소 파일을 해당 프로젝트 범위로 한정하세요.

추천 프롬프트

프로젝트 파일을 읽고 아키텍처를 요약해 주세요. 프레임워크, 주요 데이터 흐름, 중요한 디렉터리, 외부 서비스, 위험 가능성이 있는 영역을 파악해 주세요.

워크플로 2

로그와 소스 파일로 디버깅하기

오류 로그와 관련 파일을 함께 업로드하세요. 프로젝트가 코드와 로그를 함께 검색할 수 있으므로, 스택 트레이스만 붙여 넣는 것보다 훨씬 효과적입니다.

추천 프롬프트

프로젝트 파일과 이 스택 트레이스를 바탕으로 가능성이 높은 근본 원인을 찾아 주세요. 최소한의 패치, 영향을 받는 파일, 변경 후 실행해야 할 테스트 하나를 알려 주세요.

워크플로 3

낯선 코드 설명받기

새 저장소에 합류하거나 예전 작업을 다시 볼 때는 먼저 코드베이스 지도를 요청한 다음, 특정 모듈로 깊이 들어가세요.

추천 프롬프트

이 프로젝트에서 인증이 어떻게 작동하는지 설명해 주세요. 관련 파일을 인용하고, 요청 수명 주기를 설명하고, 보안 위험이나 불분명한 가정이 있으면 모두 나열해 주세요.

워크플로 4

구현 방안 비교하기

프로젝트 안에서 AI Comparison이나 AI Collaboration을 사용해 같은 코드베이스에 기반한 다양한 구현 전략을 받아 보세요.

추천 프롬프트

역할 기반 권한을 추가해야 합니다. 이 코드베이스에 대해 최소 변경, 클린 아키텍처, 마이그레이션 친화적 방식의 세 가지 구현 방안을 비교해 주세요. 위험 요소와 영향을 받는 파일도 포함해 주세요.

워크플로 5

요구 사항을 개발 계획으로 바꾸기

제품 노트, 스크린샷, 문서를 업로드한 다음 티켓, 파일 단위 구현 단계, 엣지 케이스를 요청하세요.

추천 프롬프트

업로드한 기능 브리프를 구현 계획으로 바꿔 주세요. 작업, 영향을 받는 파일, 데이터 모델 변경, API 변경, UI 상태, 테스트, 배포 위험을 포함해 주세요.
피해야 할 실수

대부분의 사람들은 프로젝트를 너무 막연하게 사용합니다.

해결책은 간단합니다. 프로젝트의 범위를 좁히고, 실제 원자료를 업로드하고, 출처에 근거한 결과를 요청하세요.

1.버그가 import나 설정에 따라 달라진다면 파일 하나만 업로드하지 마세요.

2.AI가 기존 패턴을 먼저 설명하지 않은 채 모듈을 다시 작성하게 두지 마세요.

3.서로 관련 없는 여러 저장소를 한 프로젝트에 섞지 마세요.

4.테스트를 무시하지 마세요. 변경할 때마다 무엇을 실행해야 하는지 AI에게 물어보세요.

5.생성된 코드가 여러분이 쓰는 프레임워크 버전과 맞는다고 가정하지 마세요.

자주 묻는 질문

개발자들이 자주 묻는 질문.

프로젝트에서 GitHub 파일을 가져올 수 있나요?

네. 프로젝트는 GitHub에서 저장소 파일을 가져오고, 저장소/경로/브랜치 정보 같은 메타데이터를 저장하며, 프로젝트 검색을 위해 내용을 인덱싱합니다.

프로젝트가 코드베이스 전체를 이해할 수 있나요?

중요한 파일을 가져올 때 가장 잘 작동합니다. README, 패키지/설정 파일, 핵심 모듈, 스키마, 문서, 작업과 관련된 파일 등입니다. 그러면 질문할 때 검색 기능이 관련 청크를 찾아 줍니다.

UI 버그 스크린샷을 업로드할 수 있나요?

네. 지원되는 이미지 파일에는 검색 가능한 설명이 생성되므로, 스크린샷과 시각 자료를 프로젝트와 연결된 상태로 유지할 수 있습니다.

개발자는 프로젝트 안에서 어떤 모델을 써야 하나요?

비교를 활용하세요. 어떤 모델은 아키텍처에, 어떤 모델은 패치 스타일에, 또 어떤 모델은 비평에 더 뛰어날 수 있습니다. 프로젝트는 모든 모델에 같은 코드 맥락을 제공하므로 공정하게 비교할 수 있습니다.

올바르게 시작하기

어려운 질문을 하기 전에 프로젝트부터 만드세요.

자료를 업로드하고 규칙을 정한 다음, MultipleChat이 ChatGPT, Claude, Gemini, Grok 또는 AI Collaboration에 필요한 맥락을 검색하도록 맡기세요.