AI가 바뀌어도, 프로젝트의 결정은 남도록

AI와 개발하다 보면 코드를 작성하는 시간 외에도 반복되는 일이 있다. 서비스 방향을 다시 설명하고, 다른 작업자에게 결과를 옮기고, 완료됐다는 답변 뒤에 실제 상태를 확인하는 일이다. Stackcord는 이 연결을 프로젝트 안에 남기기 위해 시작했다.

숨길에서는 Markdown 문서로 AI가 참고할 작업 기준을 관리했다. 도움이 됐지만 새 프로젝트마다 다시 만들고 갱신하기 번거로웠다. 이 경험을 바탕으로 공통 서비스 결정과 작업 맥락을 관리하는 Skills, 실제 코드 상태를 확인하는 Go CLI를 하나의 플러그인으로 개발했다.

대화 대신, 이어갈 기준을 남기기

대화가 길어지거나 새 AI로 바뀌면 이전에 내린 결정을 다시 설명해야 했다. 요약을 남겨도 그 내용이 현재 코드와 맞는지는 별도의 문제였다.

그래서 서비스 목적, 정책, 결정, 미해결 질문을 Git에 저장하는 방식을 택했다. 새 작업자는 문서만 읽는 데서 멈추지 않고 실제 코드와 진행 상태를 대조한다. 확인된 사실과 오래된 기록, 아직 모르는 부분을 구분하기 위해서다.

이어서 일하는 데 필요한 것은 모든 대화의 기억보다, 지금도 유효한 기준이었다.

미리 정할 것과 다시 승인할 것을 나누기

영향이 큰 변경마다 승인을 요청하게 만들었더니, 일상적인 구현 중에도 결정이 반복되는 문제가 있었다. 초기 기획에서 서비스 정책과 작업 기준을 더 구체적으로 정리한 뒤에는 반복 승인 요청이 거의 없어졌다고 느꼈다. 사용 중의 관찰이며 시간 절감률을 측정한 것은 아니다.

그렇다고 이후의 모든 변경을 맡기는 것은 아니다. 정해진 범위 안에서 구현하는 일과 서비스의 정책·계약 자체를 바꾸는 일은 구분한다. 후자는 현재 변경에 유효한 사람의 승인을 확인하도록 구성했다.

완료 메시지와 검증된 결과를 구분하기

‘시험 통과’라는 기록도 어떤 코드의 시험인지 알아야 쓸 수 있다. 커밋 A를 시험한 뒤 코드가 B로 바뀌었다면 A의 기록만으로 B를 검증했다고 할 수 없다.

Stackcord는 시험 결과를 코드와 계약·정책의 특정 조합에 연결하는 구조를 둔다. 다음 작업이나 최종 확인에서 현재 입력과 대조하고, 입력이 바뀌었으면 다시 검증한다.

남기는 것	다음 작업에서 확인할 것
서비스 결정	지금도 적용되는 기준인가?
작업 결과	실제로 이어받을 코드가 무엇인가?
시험·승인 근거	현재 변경에 대한 근거인가?

도구가 맡는 범위

Stackcord에서 Skills는 질문과 작업 흐름을 안내하고, CLI는 실제 상태와 근거를 검사한다. 승인 절차는 합의된 기준을 확인하는 장치이지, 로컬 파일 편집 자체를 막는 보안 격리는 아니다.

직접 사용하며 관찰한 변화는 초기 기획을 구체화한 뒤 반복 승인 요청이 줄었다는 점이다. 모든 AI와의 호환이나 모든 통합 경로의 성공을 검증한 것은 아니다. 구체적인 실행 방법과 현재 구현은 저장소에서 관리한다.

---

Stackcord 저장소에서 설치와 사용법 보기