1. 단위가 끝날때마다 git 저장을 생활화 하자
2. 설계를 제대로 안하면 처음부터 다시 코드를 짜야한다
- 서비스 설계를 gpt, claude, gemini 등 활용할수 있는 모든걸 활용해서 구체화하며 이를 md파일에 저장하자
- 그이후에 나의 상황을 설명하며(예상 사용인원, 현상황등) md파일의 설계를 신랄하게 비판하라고 하면 지가 만들었으면서 눈물 쏙빠지게 개박살 내놓는데 그 단계를 수십번 진행하면 어느정도 진행할만한 구상이 나온다.
- 나는 프론트, 백엔드, 보안, 테스트 등 각 전문가 입장에서 돌아가며 수십번 비판시키고 했는데도 부족하게 나왔다.
3. md파일을 활용하라
좋은 코드는 코드만 읽어도 이해가 된다고하지만 코들르 많이 읽게하면 토큰이 박살난다. md를 활용해야한다. READEME.md 든 Claude.md든 시작하는 md파일에는 먼저 규칙을 넣는다.
1) README.md에 들어갈내용
- 코드표기법 (다중 작업시 camlCase, snake_case가 혼용되어 고치느라 토큰과 시간이 박살난적이 있음)
- 타입 헌팅 하도록 명시 (입출력에 어떤 데이터가 오는지 당신은 알수 있으나 LLM은 항상 초면이다. 타입 힌팅을 안한다면 유지보수가 토큰과 시간 낭비의 지옥이된다.)
- md파일 저장법
2) ARCHITECTURE.md
2번에서 만들어놓은 전체적인 설계를 반드시 이 파일 하나에 저장하고 바뀔때마다 업데이트할것
3) 각 모듈의 md파일
4. 잘게 조깨라
좋은 코드는 하나의 코드에 하나의 기능이라고하는데 난 완전히 자잘하게 쪼개지는 않고 큰 기능별로 쪼갰다.
기능별로 완결성 있게 설계하면 테스트도 쉽고 수정도 쉽다.
코드를 작성후에는 동일한 명칭으로 md파일을 생성해서 간략한 설명과 데이터 플로우를 기입하게 시켜라 (ex. BACKEND_middle category_function name.md)그러면 나중에 유지보수 할때 docs폴더에서 제목만으로 파악이 가능하고, llm에 전체 흐름을 던져주지 않고도 버그 코드 관련 md파일을 몇개 던져주면 적은양의 토큰으로도 수정이 가능하다. (근데 너무 잘게 쪼개면 그냥 코드 읽게하는게 더 토큰이 적게먹으니 적절하게 쪼개야함)
5. 자동 테스트가 가능해야한다.
클로드 코드든 코덱스든 한쪽을 막으면 다른쪽이 터지는 경우가 진짜 많다. LLM얘들은 악마들이다. 본인 생각에 필요없으면 마음대로 수정한다. 때문에 자동화 테스트를 만들어 놓지 않으면 복잡해질수록 유지보수가 지옥이된다. 패치 이후에 한동안 밝혀지지 않고 시간이 지난다면 원상 복구하는것도 힘들어지고 아예 코드를 새로 만든 경우도 있다. 코드를 만들었다면 반드시 자동화 테스트도 만들어야한다. 그래야 업데이트 하기전에 한바퀴 테스트를 진행해서 이 악마가 헛짓거리 한게 없는지 확인 할수 있다.
6. 모든 코드 생성전에는 무조건 설계를 시키고 md파일을 먼저 생성하게하라
코드 생성후에 md파일과 비교하게하면 분명히 20%이상 빼먹었을 것이다.
7. 제안하는 코드를 보는데 뭔가 이상하면 당신말이 맞다. 바로 esc를 누르고 즉각적으로 질문하라
8. 하드코딩은 지양한다.
변수하나 바꾸는일이 지옥이 되며 토큰낭비가 심해진다.
9. 쉽게 확장 가능하도록 구조를 짜달라고해야한다.
기능 추가할때마다 모두 새로만들면 토큰낭비가 심해지고 통일성도 해친다.
출처: thread hankyeol_90
'일기 > 회사 일기' 카테고리의 다른 글
| 알파카-fㅏkㅏ (0) | 2025.09.05 |
|---|---|
| 회사 프로젝트를 시작하기 전 (0) | 2025.06.02 |
| 중국 출장 (0) | 2024.01.24 |