LangGraph 실험일지 작성 가이드

이 가이드의 목적 "무엇을 수정했다"를 기록하는 게 아니라, 문제 발견 → 가설 → 실험 → 해석의 사고 과정을 포트폴리오에 남길 수 있는 형태로 기록하는 것.

실험일지란 무엇인가

면접관이 보고 싶은 것

💡 "이 사람이 프롬프트를 바꿨구나"가 아니라 "이 사람이 문제를 관찰하고, 원인을 가설로 세우고, 실험으로 검증하고, 결과를 해석할 줄 아는구나"

❌ 나쁜 실험일지 vs ✅ 좋은 실험일지

❌ 이렇게 끝나면 안 된다 ✅ 이렇게 읽혀야 한다
프롬프트 수정함 어떤 노드에서 문제가 발생했는지
JSON 형식으로 바꿈 어떤 데이터를 보고 문제라고 판단했는지
속도 빨라짐 왜 그런 가설을 세웠는지
반영함 무엇을 바꾸고 무엇은 유지했는지
결과가 어떻게 달라졌는지
속도·비용·품질·안정성 사이 trade-off
왜 반영 / 부분 반영 / 보류 / 폐기했는지

6가지 핵심 원칙

원칙 1 — 감이 아니라 관측으로 시작한다

❌ 나쁜 예시 ✅ 좋은 예시
questioner가 느린 것 같다. 최근 10회 실행 기준 questioner 노드의 평균 지연 시간이 34초였고, 전체 응답 시간의 약 **65%**를 차지했다. 따라서 전체 latency 개선을 위해 questioner 노드를 우선 개선 대상으로 선정했다.

관측 데이터로 쓸 수 있는 수치 (2개 이상 포함 권장)

💡 수치가 부족한 초기 단계라면? "아직 정밀한 로그는 부족하지만, 동일 입력으로 5회 실행했을 때 대부분의 지연이 questioner 단계에서 발생했다. 이후 실험부터는 노드별 latency와 token 사용량을 함께 기록한다."