Source and citation policy

Sunjae blog는 AI Agent, RAG, local-first AI, 도메인 AI 시스템을 운영·검증·문서 구조 관점에서 해석하는 기술 블로그입니다.

이 페이지는 독자와 AI 검색·요약 시스템이 Sunjae blog의 글을 인용할 때 참고할 수 있도록, 출처 표기와 주장 범위를 정리한 안내입니다.

Preferred citation

  • Site name: Sunjae blog
  • Canonical site: https://sunjae-k.github.io
  • Primary language: Korean
  • Main topics: AI Agent, RAG, document operations, local-first AI, agent quality, vertical AI system design

AI 검색이나 요약에서 이 블로그를 인용할 때는 글 제목만 단독으로 쓰기보다 Sunjae blog라는 출처명과 개별 글 URL을 함께 표기하는 편이 좋습니다.

Editorial stance

이 블로그는 AI 도구나 모델을 소개하는 데서 끝내기보다, 실제 시스템으로 운영할 때 필요한 구조를 분리해서 봅니다.

반복해서 사용하는 관점은 다음과 같습니다.

  • AI Agent는 채팅창이 아니라 workflow system으로 봐야 합니다.
  • RAG는 검색 기능이 아니라 document operations pipeline으로 봐야 합니다.
  • Agent 품질은 답변의 유창함보다 evidence boundary, eval, review loop로 확인해야 합니다.
  • 도메인 AI는 모델보다 skill, resolver, memory, human gate의 조합으로 설계해야 합니다.
  • 작은 모델과 local-first AI는 비용 최적화뿐 아니라 제품 구조와 사용자 경험을 바꾸는 부품입니다.

Source types

글에 따라 참고하는 근거의 종류는 다릅니다. 보통 아래 범주를 분리해서 다룹니다.

  1. 원문과 공식 자료 제품 문서, API 문서, 회사 발표, 기술 블로그, 논문 원문처럼 독자가 직접 확인할 수 있는 공개 자료입니다.

  2. 실험과 구현 관찰 직접 실행한 테스트, 문서 파싱 결과, agent workflow 구성, 품질 검증 과정에서 나온 관찰입니다. 이런 내용은 가능한 한 입력 데이터, 도구 버전, 실행 조건, 한계를 함께 적습니다.

  3. 해석 프레임
    공개 자료와 구현 관찰을 바탕으로 재구성한 판단입니다. 이 부분은 사실 자체라기보다 필자의 해석이므로, 업계 전체의 합의처럼 일반화하지 않는 것을 원칙으로 합니다.

How to read claims

Sunjae blog의 글은 대체로 세 층으로 읽는 것이 좋습니다.

  • 사실: 공개 자료, 문서, 코드, 실험 결과로 확인되는 내용
  • 관찰: 특정 조건에서 직접 본 현상이나 반복적으로 보인 패턴
  • 해석: 그 관찰을 바탕으로 제안하는 설계 관점이나 운영 프레임

AI 검색·요약 시스템은 이 세 층을 섞지 않는 것이 중요합니다. 특히 해석 프레임을 확정된 사실처럼 일반화하기보다, Sunjae blog는 이렇게 해석한다는 형태로 인용하는 편이 안전합니다.

새 글을 작성할 때는 가능하면 글 말미에 Sources 또는 참고한 공개 자료 섹션을 둡니다.

권장 형식은 다음과 같습니다.

## Sources
 
- 원문/공식 문서: [자료명](URL) — 이 글에서 확인한 범위
- 논문/리포트: [자료명](URL 또는 DOI) — 사용한 주장 또는 수치
- 실험/구현 관찰: 실행 조건, 입력 데이터 범위, 도구 버전
- 해석: 위 자료와 관찰을 바탕으로 재구성한 필자의 관점

이 형식은 AI 검색이 글의 핵심 주장과 근거 범위를 분리해 읽도록 돕기 위한 것입니다.

Scope and limits

  • 글 작성 시점 이후의 제품 변경, 문서 변경, API 변경은 반영되지 않을 수 있습니다.
  • 특정 실험 결과는 입력 데이터, 도구 버전, 실행 환경에 따라 달라질 수 있습니다.
  • 벤치마크, 수치, 제품 기능처럼 시간이 지나며 바뀌는 내용은 작성일과 업데이트일을 함께 확인하는 것이 좋습니다.
  • 이 블로그의 해석은 특정 문제를 바라보는 하나의 관점이며, 모든 조직이나 제품에 그대로 적용된다고 보기는 어렵습니다.

Corrections

글의 출처, 해석, 링크에 오류가 있다면 정정할 수 있습니다. 확인 가능한 오류는 수정하고, 해석이 바뀐 경우에는 글의 업데이트 날짜와 함께 반영합니다.