프론트엔드와 백엔드를 별도의 리포지토리 (Repository)로 관리하는 프로젝트는 많을 것이라고 생각합니다.

저도 처음에는 AI에게 구현을 요청할 때 "먼저 프론트엔드를 보여준다", "필요해지면 백엔드 쪽 리포지토리로 이동한다"라는 흐름으로 작업했습니다. 하지만 매번 리포지토리를 오가는 것이 은근히 번거로웠습니다.

어떻게든 양쪽 리포지토리를 함께 열어서 AI가 동시에 읽을 수 있는 상태로 만들 수 없을까 고민하던 차에, VS Code의 .code-workspace를 알게 되었습니다.

실제로 사용해 보니 개발 경험 (DX)이 상당히 좋아졌기에, 이 기사에서는 최소 구성의 .code-workspace와 AI에게 양쪽 리포지토리를 보여주면 무엇이 좋은지를 정리하겠습니다.

.code-workspace는 VS Code에서 여러 폴더를 하나의 워크스페이스 (Workspace)로 열기 위한 설정 파일입니다.

보통은 하나의 리포지토리를 하나의 창으로 여는 경우가 많지만, .code-workspace를 사용하면 서로 다른 위치에 있는 폴더를 묶어서 하나의 창에서 다룰 수 있습니다.

이번 사례처럼 프론트엔드와 백엔드가 별개의 리포지토리로 되어 있는 경우라도, 같은 워크스페이스에 넣어두면 AI 에이전트 (AI Agent)가 양쪽 코드를 동시에 참조하기 쉬워집니다.

예를 들어, 다음과 같은 구성을 생각합니다.

my-app/
├── backend-test/
│ ├── backend-frontend.code-workspace
...

backend-test와 frontend-test는 별개의 리포지토리입니다.

이 두 개를 VS Code에서 동시에 열 수 있도록 만듭니다.

backend-test/backend-frontend.code-workspace를 만듭니다.

이번에는 동시에 열고 싶은 폴더만 설정합니다.

{
"folders": [
{
...

VS Code에서는 다음과 같이 열 수 있습니다.

code backend-test/backend-frontend.code-workspace

Cursor를 사용하고 있는 경우에는 다음과 같이 열 수 있습니다.

cursor backend-test/backend-frontend.code-workspace

가장 큰 장점은 AI가 "화면에서 DB까지의 흐름"을 추적하기 쉬워진다는 점입니다.

화면 컴포넌트 (Component)
↓
API 호출 처리
...

프론트엔드만 열어두고 있으면, AI는 API의 내용을 추측할 수밖에 없습니다.

백엔드만 열어두고 있으면, API의 변경이 화면에 어떤 영향을 미치는지 보이지 않습니다.

양쪽을 동시에 열어두면, AI가 이 사이를 오가며 생각할 수 있습니다.

예를 들어, 프론트엔드에 다음과 같은 API 호출이 있다고 가정합니다.

fetch("/api/tasks");

프론트엔드 리포지토리만 보고 있는 경우, 이 API가 어떤 값을 반환하는지는 코드만으로는 알 수 없습니다.

하지만 같은 워크스페이스에 백엔드도 들어있다면, AI는 라우트 (Route)를 확인하러 갈 수 있습니다.

Route::get('/tasks', [TaskController::class, 'index']);

나아가 Controller, Model, migration까지 추적할 수 있습니다.

그 결과, 다음과 같은 사항들을 판단하기 쉬워집니다.

• 이 API는 무엇을 반환하고 있는가
• 프론트엔드 측의 타입 (Type)과 응답 (Response) 형식이 일치하는가
• 화면에 표시되지 않는 값은 어디에서 누락되었는가

사람이 조사할 때 자연스럽게 수행하는 "호출부로부터 구현부까지 따라가는" 작업을 AI에게도 시키기 쉬워지는 이미지입니다.

백엔드만 보고 있으면, API 응답을 변경한 뒤에 프론트엔드 측의 타입이나 표시 처리를 수정하는 것을 잊어버릴 때가 있습니다.

반대로 프론트엔드만 보고 있으면, "화면에서는 이 값이 필요할 것 같은데, 애초에 API가 반환하지 않고 있다"라는 사실을 알아차리기 어렵습니다.

예를 들어 백엔드가 다음과 같은 응답을 반환한다고 가정합니다.

return [
'id' => $task->id,
'title' => $task->title,
...

프론트엔드 측에서는 다음 타입으로 받고 있다고 가정합니다.

type Task = {
id: number;
title: string;
...

여기서 title을 name으로 바꾼다면, 백엔드 (Backend)의 반환값뿐만 아니라 프론트엔드 (Frontend)의 타입, API 호출, 표시되는 부분도 함께 수정해야 합니다.

양쪽 리포지토리 (Repository)가 모두 보인다면, AI에게 "화면 쪽도 함께 봐줘"라고 말하기가 훨씬 쉬워집니다.

예를 들어, "태스크 이름이 화면에 나오지 않는다"라는 버그를 조사한다고 가정해 봅시다.

프론트엔드만 보고 있다면 컴포넌트 (Component)나 API 호출까지는 추적할 수 있습니다. 하지만 그 API가 백엔드에서 어떻게 처리되고 있는지, DB에서 어떤 컬럼 (Column)을 읽고 있는지까지는 보이지 않습니다.

백엔드도 같은 워크스페이스 (Workspace)에 들어있다면, 다음과 같이 한 번에 추적할 수 있습니다.

화면 컴포넌트
↓
API 호출 처리
...

원인이 프론트엔드 측의 표시 실수인지, API의 반환 누락인지, 아니면 DB 컬럼명의 차이인지 후보를 좁히는 시간이 단축됩니다.

프론트엔드와 백엔드를 따로 보고 있으면 은근히 놓치기 쉬운 것이 바로 명명 (Naming)의 불일치입니다.

예를 들어, 백엔드가 다음과 같은 JSON을 반환한다고 가정해 봅시다.

{
"is_completed": false
}

반면, 프론트엔드는 다음과 같은 이름을 기대하고 있을지도 모릅니다.

isCompleted

한쪽만 보고 있으면 이러한 차이를 의외로 놓치기 쉽습니다.

양쪽을 같은 워크스페이스에 넣어두면, AI가 "백엔드는 snake_case, 프론트엔드는 camelCase를 기대하고 있다"는 것을 알아차리기 쉬워집니다.

예를 들어, "태스크에 기한을 추가한다"라는 변경 사항을 생각해 봅시다.

이 변경은 백엔드만으로도, 혹은 프론트엔드만으로도 완결되지 않습니다.

• 마이그레이션 (Migration)
• 모델 (Model)
• 컨트롤러 (Controller)
• API 응답 (Response)
• 프론트엔드 타입
• 목록 화면
• 기한 입력 폼
• 기한 표시
• 테스트 (Test)

화면에서 DB까지 여러 곳에 수정 사항이 퍼지게 됩니다.

이러한 변경을 AI에게 부탁할 때, 한쪽 리포지토리만 보인다면 아무래도 도중에 정보가 부족해질 수밖에 없습니다.

.code-workspace로 양쪽을 모두 열어두면 다음과 같이 부탁할 수 있습니다.

태스크에 기한을 추가해 주세요.
화면, API, DB까지 필요한 수정을 한꺼번에 확인해 주세요.

AI가 프론트엔드와 백엔드를 동시에 참조할 수 있으므로, 화면만, API만, 혹은 DB만 수정하고 멈추는 일이 줄어듭니다.

.code-workspace를 사용하면 서로 다른 리포지토리인 프론트엔드와 백엔드를 하나의 워크스페이스로 열 수 있습니다.

설정은 최소한의 folders만으로도 충분합니다.

프론트엔드와 백엔드를 동시에 AI에게 보여주면, AI가 화면에서 DB까지의 흐름을 추적하기 쉬워집니다.

그 결과, 다음과 같은 장점이 있습니다.

• API와 화면의 연결 고리를 추적하기 쉽다
• 수정 누락을 알아차리기 쉽다
• 버그 조사가 빨라진다
• 명명 (Naming)의 불일치를 찾기 쉽다
• 조금 규모가 큰 변경을 부탁하기 쉽다

실제로 .code-workspace를 사용하여 프론트엔드와 백엔드를 동시에 열도록 한 이후로, AI 에이전트 (AI Agent)를 통한 개발 경험이 상당히 좋아졌습니다.

설정 자체는 매우 가볍기 때문에, 프론트엔드와 백엔드를 별도의 리포지토리로 관리하면서 AI 에이전트를 사용하여 개발하고 있다면 꼭 도입해 보시는 것을 추천합니다.