![[개발 일지] 소스와 기획을 나눴더니 헷갈림이 없어졌다: 무엇의 기준인지 정하기](https://blogger.googleusercontent.com/img/a/AVvXsEhuaieOQg7Xv4UZcNV57b1mwt9qPztgQlSN4EsHrI2Dtavo2YRE-VMms_3eak0dZoNYTimQpAcEfmwioWo3O8QyxJU1ELPjUE7SCZOrpQXRUo3JTTSoDJIZq5_cAqrBfEKelrrx0X7AlIA-QlQ04KKs0GFr2bnSi908YouAEfxKO_BblAJil7ytSWufEEs=rw "[개발 일지] 소스와 기획을 나눴더니 헷갈림이 없어졌다: 무엇의 기준인지 정하기")
한 줄 요약: 같은 프로젝트를 로컬과 클라우드 양쪽에 두면 어느 쪽이 맞는지 헷갈립니다. 무엇의 기준인지를 나눠 정하니 그 혼란이 없어졌습니다.
기록 성격: 개발 기록. 원본 문서·계정·내부 경로는 공개하지 않습니다.
무엇의 기준인지를 나눈다
- 로컬 저장소 — 소스와 실행의 기준입니다. 돌아가는 코드는 여기 있습니다.
- 클라우드 폴더 — 기획·결정·기록의 기준입니다. 왜 그렇게 했는지는 여기 있습니다.
- 비밀키 — 어느 쪽에도 올리지 않습니다. 별도로 둡니다.
"어디에 두는가"가 아니라 "무엇의 기준인가"로 나누면 중복이 있어도 헷갈리지 않습니다.
문서와 실제가 다를 때
시간이 지나면 반드시 어긋납니다. 그때 규칙은 하나입니다. 실제 상태를 우선하고 차이를 기록합니다.
- 문서에 있는데 코드에 없으면 — 계획이었거나 지워진 것입니다.
- 코드에 있는데 문서에 없으면 — 급하게 넣고 안 적은 것입니다. 이쪽이 더 많습니다.
- 둘 다 있는데 내용이 다르면 — 코드를 믿고 문서를 고칩니다.
차이를 발견했을 때 조용히 문서만 고치지 않고 무엇이 달랐는지 남깁니다. 같은 어긋남이 반복되면 기록 습관에 문제가 있다는 뜻이기 때문입니다.
비밀키를 따로 두는 것만으로 부족한 이유
- 저장소에 올리지 않는 것과 화면에 안 띄우는 것은 다릅니다.
- 로그에 남지 않는지도 따로 확인해야 합니다.
- 대화나 캡처에 섞여 나가는 경우가 실제로 가장 많습니다.
- 한 번이라도 노출 가능성이 있었다면 새로 발급하는 편이 안전합니다.
어긋남을 줄이는 작업 마무리 순서
작업을 끝낼 때 순서를 정해 두면 문서와 실제가 벌어지는 폭이 줄어듭니다.
- 로컬 테스트와 저장소 상태를 먼저 확인합니다.
- 기획 쪽 문서에 상태·개발·테스트 기록을 갱신합니다.
- 갱신한 문서를 다시 읽어 실제와 맞는지 확인합니다. 쓰고 나서 안 읽으면 틀린 채로 남습니다.
- 다음에 할 일을 한 문장 적습니다.
세 번째를 건너뛰기 쉬운데, 여기서 대부분의 어긋남이 걸립니다.
두 곳에 두는 비용
한 곳으로 합치면 간단합니다. 그런데도 나눠 두는 이유가 있습니다.
- 소스는 버전 관리와 실행이 붙어 있어야 합니다.
- 기획과 결정은 검색과 공유가 쉬워야 합니다.
- 둘의 요구가 달라서 한쪽에 맞추면 다른 쪽이 불편해집니다.
대신 비용을 치릅니다. 동기화가 어긋날 수 있고, 어느 쪽이 맞는지 매번 판단해야 합니다. 그 비용을 줄이는 것이 "무엇의 기준인가"를 미리 정해 두는 일입니다.
어느 쪽도 기준이 아닌 것
소스와 기획 말고도 파일은 계속 생깁니다. 어느 쪽 기준도 아닌 것들은 따로 처리합니다.
- 빌드 결과물 — 언제든 다시 만들 수 있으니 보관하지 않습니다.
- 임시 실험 — 결론만 기록에 남기고 파일은 지웁니다.
- 받은 자료 — 원본 위치를 적어 두고 복사본은 두지 않습니다.
- 비밀 정보 — 어느 쪽에도 두지 않습니다.
정리 규칙이 없으면 두 곳 모두 잡동사니가 쌓이고, 그러면 어느 쪽이 기준인지 따지는 것 자체가 무의미해집니다.
읽고 나서 확인할 것
이 글은 게시 시점의 진행 상태를 정리한 것입니다. 이후 바뀐 내용은 다음 기록에서 다시 적습니다.