cogito architecture
cogito는 PDF·Markdown, 정리 안 된 노트까지 어떤 파일이든 LLM으로 분류해 whoami가 쓸 수 있는 엔티티로 바꾸는 ingest 파이프라인입니다. whoami의 정형 디렉터리 구조 제약을 없애기 위해 별도 gRPC 서비스로 분리했고, jaso(자기소개서)·bizplan·company 등 리포트 파이프라인의 공통 기반이기도 합니다 — 이 사이트의 이력서 PDF 콘텐츠도 이 파이프라인의 산출물입니다.
왜 필요한가
LLM을 활용해 응답을 만들어봤을 때 결과물 품질이 생각보다 좋지 않았고, 균일하지 않은 경우도 발생했습니다. 이런 품질과 균일성 문제를 해결하기 위해 질문 파이프라인·검증 파이프라인·조합 파이프라인까지 통합해, 응답 품질과 균일성을 통한 신뢰성 향상을 목표로 만든 프로젝트입니다.
01
내부는 어떻게 나뉘는가
cogito-structure.yaml
whoami가 gRPC(cogito_service·prechunk_sink)로 진입하면 worker(runner·sink_coordinator·sweeper)가 비동기로 pipelines(taxonomy·jaso·bizplan·company)에 넘기고, agents가 LLM을 호출합니다. 처리 상태는 Postgres 기반 registry가 추적합니다.
cogito / structure.yaml
02
어떻게 배포되고 무엇에 의존하는가
cogito-infra.yaml
평상시 replicas 0으로 유지되다 ArgoCD Image Updater가 레지스트리 digest 변경을 감지하면 자동으로 스케일됩니다. LLM 추론은 베어메탈 GPU 노드의 Ollama를, 지식 검색은 gopedia-svc를, 엔티티 저장은 whoami-api를 호출합니다.
cogito / infra.yaml
03
파일 하나가 어떤 경로로 처리되는가
cogito-what.yaml
업로드된 파일에서 텍스트를 추출하고, LLM이 selector를 판단해 분류한 뒤 frontmatter를 생성·병합합니다. content-hash 기반이라 재업로드해도 중복 없이 whoami에 upsert됩니다.
cogito / what.yaml
04
커밋이 어떻게 배포로 이어지는가
cogito-ops.yaml
git push가 toji-ci(Tekton)를 웹훅으로 트리거해 dagger-engine이 빌드하고 이미지를 레지스트리에 올립니다. ArgoCD Image Updater가 digest 변경을 직접 폴링해 감지하므로, goquest/lymphhub의 manifest-writeback 방식과 달리 별도 PR 없이 자동으로 배포됩니다.
cogito / ops.yaml
rendered via archview · d2lang/d2 · ELK layout