TIL: 세션이 너무 길면 압축해도 토큰 효율에 별 도움이 안 됨

그게 문제야. 시작부터 끝까지 일주일이 걸리는 "새로운 작업"이 있거든. 이건 돈이랑 그 뒤에 숨은 로직을 다루는 거라, 내 생각엔 로직을 적어둘 치트 시트를 만드는 게 유일한 방법인 것 같아. 안 그러면 Claude가 이 특정 구현을 위해 의도적으로 뭔가를 바꿔버려서, 내가 눈치채지 못하면 재앙이 일어날 수도 있거든. 문제는 클라이언트 A와 B와의 통합을 보고 C도 같은 로직을 써야 한다고 생각하는데, C는 커스텀 요구사항이 따로 있다는 거야...

모든 아키텍처 질문이랑 작업을 한 세션에 다 때려 넣는 대신, 나 자신을 위해 메모하는 습관을 들여야 할 것 같아. 어딘가에 항상 적어두면 다음 세션에서 잊어버리지 않을 테니까.

좋은 생각이야.

참고로, 아키텍처 질문은 작업 세션과 분리해야 해. 그리고 각 작업도 자기만의 세션을 가져야 하고.

각 세션은 프로젝트의 특정 영역에만 집중해야 해.

행운을 빌어, 계속 만들어 나가자!!

정말 고마워, 큰 도움이 됐어.

Claude한테 노트 관리 시키고 코딩 전에 리스트 정리하게 할 수 있다는 거 알지? 내 작업 방식 중 하나는 Claude한테 아키텍처나 기능 같은 걸 명확하게 문서화하게 하는 거야. 어시스턴트가 있는데 왜 굳이 수동으로 관리해? 이 강력한 툴을 어떻게 써야 더 잘할 수 있는지 좀 배워야 할 듯.

만약 "새로운 작업"이 일주일이나 걸린다면, 수십 개의 더 작은 작업으로 쪼개야 해.

나라면 Claude에게 해당 세션의 로그를 확인하게 해서 어떻게 하면 더 토큰 효율적으로 작업할 수 있을지 제안해달라고 할 것 같아.

그 치트 시트는 그냥 기능 구현을 위한 계획표일 뿐임. 그게 평소 워크플로우의 일부가 되어야 하고, 기반을 탄탄하게 다져놨다면 별다른 준비 없이도 새 세션에서 바로 이어서 작업할 수 있어야 함. 툴을 제대로 쓰는 법부터 좀 배워야 할 듯.

맞아, 이건 여러 독립적인 서비스(내 서비스들이기도 함)와 통신하는 GO 백엔드라서, 여기서 기능을 추가하고 다른 프로젝트 세션들과 소통해서 API를 올바르게 구현하고 테스트하도록 조정해야 할 일이 많거든.