Antigravity · Gemini Skills — 스킬 프로젝트 소개

“간단한 메모 앱”만으로는 정할 수 없던 것

Antigravity·Gemini 계열 워크플로의 초기 메모 앱 요구는 짧았습니다. “간단한 메모 앱 만들어줘”라는 한 문장입니다. 이 요청만으로는 브라우저에서 쓰는지 설치형 앱인지, 서버가 필요한지, 여러 기기에서 같은 메모를 보는지 알 수 없습니다. 저는 구현 전에 이 차이를 정할 질문을 남겼습니다.

질문은 주요 사용자 경험, 저장 방식, 배포 형태 세 가지였습니다. 브라우저 중심인지, 로컬 저장만으로 성립하는지, 웹 배포를 목표로 하는지를 구분했습니다. 기준 계획에는 브라우저와 로컬 저장, 웹 배포를 선택한 조건을 반영했습니다.

그 결과 구현 목표를 서버 없는 웹 메모 앱으로 좁혔습니다. 같은 “메모 앱”이어도 클라우드 동기화를 포함했다면 인증과 서버, 데이터 충돌을 다뤄야 합니다. 시작 단계에서 그 조건을 정하지 않으면 구현 담당이 임의로 기능 범위를 넓힐 수 있어, 선택 결과를 계획의 근거로 남겼습니다.

플랫폼 이름만 전달하지 않고 작업 루트까지

기준 계획에는 플랫폼, 주요 기술, 언어와 서버 필요 여부를 함께 적었습니다. 메모 앱은 TypeScript 기반 웹 구조로, 작업 루트는 웹 앱 경로로 정했습니다. 담당에게 “웹 전문가”라는 역할 이름만 주는 것보다 어떤 코드와 폴더를 다룰지 지정하는 것이 필요했습니다.

지휘 역할은 직접 모든 코드를 작성하는 대신 계획을 기준으로 분석, 구현, 검토 담당을 연결하도록 구성했습니다. 구현 담당에게 플랫폼과 언어, 작업 경로, 서버 필요 여부를 전달하고 그 범위 안에서 진행하게 했습니다. 플랫폼이 바뀌면 조용히 계속 구현하기보다 변경을 확인하도록 했습니다.

독립된 소유 경로가 정해지지 않은 경우에는 순차 실행을 기본으로 뒀습니다. UI와 서버 같은 책임을 나눌 때도 폴더 소유자를 먼저 명시하도록 했습니다. 역할 이름이 다르다는 것만으로 변경 파일이 서로 겹치지 않는 것은 아니기 때문입니다.

로컬 저장도 서비스 역할로 나눴습니다

메모 데이터는 브라우저 저장소에 남기는 구조로 만들었습니다. 별도 서버가 없더라도 저장 로직을 화면 안에 모두 넣지는 않았습니다. 읽기, 생성, 수정, 삭제를 담당하는 메모 서비스를 두고 상태 관리와 화면이 그 서비스를 사용하게 했습니다.

서비스는 저장된 메모 목록을 읽고 새 메모에 식별자와 생성·수정 시각을 붙입니다. 수정할 대상이 없으면 없는 결과를 돌려주고, 삭제는 해당 식별자를 제외한 목록을 다시 저장합니다. 브라우저가 아닌 환경에서는 저장소에 바로 접근하지 않도록 조건을 넣었습니다.

이 분리는 나중에 데이터를 서버로 옮겼다는 이야기가 아닙니다. 초기 로컬 앱에서도 데이터 접근을 하나의 책임으로 다룬 설계입니다. 화면은 사용자의 입력과 목록 표시를 맡고, 저장 방식은 서비스에서 확인할 수 있어야 같은 계획을 여러 담당이 이어 읽을 수 있습니다.

상태와 화면에서도 같은 흐름을 유지하기

상태 관리에는 목록 불러오기와 생성, 수정, 삭제 동작을 연결했습니다. 새 메모를 만들면 서비스가 반환한 메모를 상태 목록 앞에 넣고, 수정과 삭제도 식별자로 해당 항목을 반영합니다. 저장된 목록과 화면에 보이는 목록을 어떤 동작으로 맞추는지 드러내는 구조입니다.

메모 입력과 목록 화면도 이 상태 흐름을 사용하도록 구성했습니다. 검토에서는 기능 이름만 체크하기보다 서비스에서 상태를 거쳐 화면으로 이어지는 호출 경로를 살피게 했습니다. “메모 생성 기능 있음”이라는 문장보다 어느 역할에서 무엇을 담당하는지 알 수 있어야 다음 수정의 범위도 정할 수 있습니다.

기준 계획은 화면 구성과 서비스 구조를 함께 설명합니다. 담당이 바뀌어도 “서버가 없으니 상태와 저장을 구분하지 않아도 된다”는 다른 전제로 이동하지 않게 하려는 선택이었습니다. 작은 앱에서도 구조의 이유가 전달돼야 합니다.

저장 범위를 정하면 위험도 함께 남겨야 합니다

로컬 저장을 선택한 계획에는 브라우저 데이터를 지우면 메모를 잃을 수 있다는 위험을 적었습니다. 다른 기기와 자동으로 동기화되는 앱으로 소개하지 않았습니다. 저장 위치를 정하는 일은 기능의 경계와 데이터가 유지되는 조건을 정하는 일이기도 합니다.

내보내기는 후속 후보로 남겼습니다. 향후 넣을 수 있는 기능과 현재 구현할 범위를 같은 목록에서 완료한 것처럼 섞지 않기 위해서입니다. 사용자가 메모를 보존해야 하는 요구를 더했다면 이 위험과 후속 후보를 다시 판단해야 합니다.

이 선택은 저장 구조를 검수할 때도 이어집니다. 생성과 수정이 화면에 반영되는지뿐 아니라 새로 열 때 목록을 어디서 읽는지, 저장된 값이 기대한 형태인지 확인해야 합니다. 계획의 조건과 실제 기능 경로를 함께 보는 이유입니다.

기준 계획과 실행 사실을 같은 문서로 만들지 않기

지휘 흐름에는 단계 체크포인트를 별도 실행 기록으로 남기도록 했습니다. 계획은 어떤 구조로 진행할지를 정하고, 실행 기록은 어느 단계까지 확인했는지를 남깁니다. 검토 보고서는 요구마다 파일과 동작, 확인 방법을 연결하는 역할로 둡니다.

기준 계획에 빌드 가능한 상태를 요구하는 것과 실제 빌드 결과를 갖는 것은 다른 일입니다. 저는 완료를 판단할 때 기능 경로와 실행 방법, 필요한 검수 자료를 함께 확인하도록 역할 계약에 넣었습니다. 계획의 체크 표시만으로 동작 검증을 대신하지 않습니다.

이 초기 구성 뒤에는 정책과 디자인 기준, 결정 기록을 확장하는 준비 문서도 만들었습니다. 다만 초기 역할 지시와 확장 준비는 다른 단계입니다. 새로운 운영 규칙을 적용할 때는 실제 도구와 연결된 부분을 확인하며 가져와야 합니다. 문서에 목표가 적혀 있다는 이유로 자동 검증 전체가 완성됐다고 판단하지 않습니다.

작은 앱에서 남긴 조율 기준

대상과 저장 조건을 질문으로 확정하고, 그 결과를 하나의 기준 계획에 넣었습니다. 구현은 서비스와 상태, 화면으로 나눴고 검토에서는 그 경로를 다시 확인하도록 했습니다.

비슷한 요청을 다시 받으면 먼저 데이터가 어디에 남고 어떤 환경에서 쓰이는지 정합니다. 그다음 작업 루트와 담당의 범위를 알려 줍니다. 기능을 늘리는 요구가 들어오면 기존 계획의 저장 조건과 위험도 함께 바꿉니다.

역할이 달라도 같은 목표와 제약을 이어받는 것이 이 워크플로의 핵심입니다. 짧은 요청을 크게 해석해 구현하기보다, 필요한 질문으로 범위를 좁히고 그 결정을 끝까지 전달하는 쪽으로 구성했습니다.