견적서 앱은 이미 UI와 PDF를 다듬고 ERP 직접 연동까지 반영하는 단계로 움직이고 있었습니다. 그런데 예전 기억을 바탕으로 상태를 설명하면 아직 PDF를 조금 조정하는 작업처럼 보였습니다.
2026년 4월 15일의 기록에서 가장 중요한 부분은 이 차이였습니다. 작업이 멈춘 것이 아니라, 진행된 작업과 그것을 설명하는 기록의 시점이 달랐습니다.
AI와 여러 프로젝트를 함께 다루면 이런 일이 생길 수 있습니다. 이전 대화는 맥락을 잘 보존하지만 현재 상태까지 보장하지는 않습니다. 이 글은 그날 프로젝트 보드와 상태 정보를 맞춘 경험을 바탕으로, AI에게 일을 다시 맡기기 전에 확인할 기준을 정리한 글입니다.
기억은 작업을 찾는 데 쓰고, 상태는 근거로 확인합니다
예전 기록은 왜 이 일을 시작했는지, 어떤 선택을 했는지 알려줍니다. 하지만 “이미 배포했다”거나 “아직 작업 중이다”라는 설명은 시간이 지나면 달라질 수 있습니다.
반대로 프로젝트 보드라고 해서 항상 맞는 것도 아닙니다. 보드를 최우선으로 읽더라도, 그 안의 내용이 오래됐다면 같은 문제가 반복됩니다. 기준 문서를 하나 정하는 것과 그 문서가 사실을 반영하게 만드는 것은 별개의 작업입니다.
그래서 기록을 읽을 때는 결론 옆의 근거를 같이 봐야 합니다.
| 기록 | 그 기록으로 확인할 수 있는 범위 |
|---|---|
| 이전 대화와 메모리 | 당시의 목표, 결정, 해결한 문제 |
| 프로젝트 보드 | 정리된 현재 상태와 다음 작업 |
| 로컬 코드와 테스트 결과 | 해당 시점의 로컬 구현과 테스트 범위 |
| 운영 상태 파일과 API 응답 | 조회한 환경에서 실제 노출되는 상태 |
예를 들어 로컬 테스트가 통과했다면 로컬 구현의 근거는 됩니다. 그것만으로 운영 배포까지 완료됐다고 적어서는 안 됩니다.
그날 맞춘 것은 보드와 운영 표시였습니다
당시에는 견적서 앱과 ERP 자동화의 프로젝트 보드를 최신 로컬 진행 상태에 맞춰 정리했습니다. 이어 OCI의 상태 파일과 API 응답도 같은 기준으로 동기화했다고 기록되어 있습니다.
그 결과, 견적서 앱의 진행 범위를 단순 PDF 조정으로 축소해 설명하던 문제를 바로잡을 수 있었습니다. 무엇이 이미 반영됐고, 어디까지 이어진 작업인지를 더 정확히 전달하게 된 것입니다.
다만 공개 원문에는 당시 코드 변경 내역과 API 원본 응답이 붙어 있지 않습니다. 여기서 확인할 수 있는 것은 상태 기록을 정리한 사례이지, ERP 연동 기능 전체의 정상 동작이나 현재 배포 상태까지는 아닙니다.
이 한계를 함께 적는 것이 오히려 상태 문서의 역할에 맞습니다. 모르는 범위를 완료로 채우지 않아야 다음 판단이 틀어지지 않습니다.
보드를 늘리기 전에 상태 한 줄을 바꿉니다
같은 문제를 줄이기 위해 거대한 관리 시스템부터 만들 필요는 없습니다. 기존 보드에 아래 항목을 붙이는 것부터 시작할 수 있습니다.
작업:
확인한 환경: 로컬 / 테스트 / 운영
현재 상태: 진행 중 / 검증 대기 / 확인 완료 / 차단됨
근거: 변경 내역, 테스트 결과 또는 조회한 화면
확인 시각:
아직 확인하지 못한 범위:
다음 작업과 담당자:
이는 제안하는 기록 양식입니다. 당시 사용한 상태 파일의 실제 스키마는 아닙니다. 공개할 때는 내부 경로와 접근 주소, 고객 정보 등을 제거해야 합니다.
“완료”를 쓰기 전에 확인한 환경을 먼저 적으면 모호함이 줄어듭니다. 로컬 구현 완료와 운영 검증 완료를 같은 칸에 섞지 않을 수 있기 때문입니다.
서로 다른 기록이 나오면 합의보다 재확인이 먼저입니다
두 기록이 충돌한다고 해서 더 최근에 작성된 문장을 곧바로 믿지는 않습니다. 문서는 새로 저장됐어도 그 안의 근거는 오래된 것일 수 있습니다.
- 같은 작업과 같은 환경을 말하는지 확인합니다.
- 각 기록의 확인 시각과 근거를 비교합니다.
- 확인할 수 있는 실행 결과나 화면을 다시 조회합니다.
- 확인된 범위만 보드에 반영하고, 나머지는 미확인으로 남깁니다.
API가 보드 내용을 그대로 보여주는 구조라면 보드와 API가 일치한다는 것만으로 독립적인 검증이 되지는 않습니다. 같은 내용을 두 군데에서 읽은 것일 수 있습니다. 실제 구현 결과를 별도로 확인해야 하는 이유입니다.
충돌이 해소되지 않으면 상태를 둘로 남깁니다
예를 들어 이 사례를 다시 인계한다면 “보드와 운영 표시의 동기화는 당시 기록에 있음”과 “ERP 연동 기능 전체의 현재 동작은 미확인”을 분리해 적겠습니다. 서로 다른 범위의 설명을 하나의 완료 상태로 합치지 않는 것입니다. 최신 저장 시각보다 무엇을 실제로 확인한 기록인지가 우선입니다.
상태를 확인할 기준 문서가 흩어져 있다면 Obsidian 운영 위키의 메타데이터·인덱스 구성이 다음 단계입니다. 기억을 더 많이 주입하기보다, 현재 상태를 찾을 문서와 그 근거를 먼저 정리하는 방향입니다.
다음 작업자가 추측하지 않게 남깁니다
프로젝트 보드를 기준점으로 삼는 목적은 AI에게 외울 문서를 하나 더 주는 데 있지 않습니다. 다음 작업자가 이전 대화를 모두 읽지 않아도 현재 위치와 남은 확인을 알아보게 만드는 데 있습니다.
보드에 근거와 확인 시점이 있으면 AI의 기억은 길잡이로 쓸 수 있습니다. 없으면 기억도 보드도 서로 다른 시점의 주장에 그칩니다. 상태 보고를 다시 쓸 때는 “무엇을 기억하는가”보다 “무엇을 언제 확인했는가”가 먼저였습니다.
사례 기준일: 2026-04-15. 기존 프로젝트 상태 정리 기록을 2026-09-03에 재구성했습니다. 당시의 동기화 기록과 현재 운영 기능의 검증을 구분합니다.
편집 메모: 2026-09-10. 당시 경험과 수치를 보존하고 판단 기준과 관련 글 연결을 보완했습니다. 새 설치·성능 시험이나 현재 운영 상태의 재검증을 한 것은 아닙니다.