제보 감사합니다!
해당 섹션의 라벨/제목/설명 색상을 다크모드에 맞게 수정했습니다.

좋은 질문 감사합니다!

현재 챗은 “전체 공고 원문을 매번 RAG로 검색”하는 방식이라기보다는, 먼저 공고문을 AI로 분석해서 만든 구조화 데이터(JSON)를 기반 컨텍스트로 넣고 질문에 답하게 하는 방식입니다.

흐름은 대략 이렇습니다.

  1. 공고 수집 단계에서 PDF/HWP/Excel/본문 텍스트를 추출
  2. LLM으로 신청 자격, 소득/자산 기준, 일정, 임대 조건, 주택 정보 등을 구조화된 JSON으로 저장
  3. 사용자가 특정 공고 상세 화면에서 질문하면, 해당 공고의 분석 JSON + 최근 대화 히스토리만 프롬프트에 넣음
  4. OpenAI Chat Completions API로 스트리밍 응답
  5. 대화 내용은 사용자별/공고별 세션으로 저장

즉, 챗봇이 매번 긴 PDF 전체를 다시 읽는 구조는 아니고, “이미 분석해 둔 공고 데이터에 대해 질의응답하는 UI”에 가깝습니다.

프롬프트에서는 공고 데이터에 없는 내용은 추측하지 말고 원문 확인을 안내하도록 제한했습니다.

google geo 가이드에서도 llms를 다른 회사의 서비스를 위해 추가하고 있다고 하니 필요한 것 같아요

내용이 재밌네요. 구형 제온 시스템이 있는데 한번 시도해봐야겠습니다.

네. 맞는 말씀입니다. 오케스트레이션 부분을 뺀 부분은 여전히 가치 있습니다.

공감합니다. 같이 대응개발해야해요

Show GN 가이드라인 보면 깃헙 스타까지 이야기는 안되어있지만, 게시글에는 지인에게 업보트를 하지 말라는 내용이 있고,
해당 맥락에서 보면 보는 사용자들이 충분히 거부감을 가질만하다고는 생각되네요

최근에 Lighthouse 지표에 llms.txt가 들어가긴 했어요.

그런데, 자주 구글이 그렇듯이. 다른 문서에는 굳이 하지 말라고 👀

가치있는 레포는 아니라고 생각하지만...
이걸 어뷰징이라고 보기엔 무리가 있지 않나요?
별 한번 부탁한다- 정도의 이야기를 하기는 했지만, 품앗이를 한 것도 아니고, 금전적 댓가를 지급한 것도 아닌 것 같구요.

동의합니다. 저도 4.7용 수제 오케스트레이션이나 장황한 플래닝 강제는 4.8에선 방해라 들어냈어요.
다만 수십만 줄을 수년 유지보수한 코드베이스에선 하네스의 진짜 가치가 오케스트레이션이 아니라 ultracode가 대체 못 하는 층(지식그래프,도메인 컨벤션,검증 불변식)에 있어서, 그 컨텍스트 층은 남기고 정말 독립적인 구간만 workflow로 병렬화했습니다.
반대로 신규 프로젝트라면 굳이 하네스 없이 ultracode가 맞다고 보고요 결국 "지운다 vs 남긴다"가 아니라 코드베이스 나이, 결합도에 따라 갈리는 문제 같습니다.

저한텐 1주 같이 일하기 좋은 것 같아요

라는 글도 AI로 썼겠지 ㅋㅋ

어짜피 업무할때 AI를 쓸텐데 그걸 배제하는건 의미가 있나 싶네요, 차라리 원격 면접을 없애고, 현장으로만 운영하며, 현장에서 어떻게 AI를 쓰고 사고하는지 잘 설계된 질문들과 모니터링으로 판단하는게 AI시대에 더 맞지 않을까요?

같은 문제라도 어떻게 프롬프트를 보내는지 보면 그 사람에 대해서 많은걸 알수 있지요.

맥도 결국 같은 이슈를 안고있지 않나요?

claude도 비슷하더군요. 뭔가 docker로 우회하는 방법을 학습한 것 같습니다.
최근에 AMD GPU툴을 만들 필요가 있었는데, 리눅스 환경에서 AMD GPU는 사용자가 render 혹은 video 그룹에 들어가 있어야 사용할 수 있습니다. 호스트에서 사용자가 해당 그룹에 들어가 있지 않을때, claude가 스스로 방법을 찾아보겠다고 하더니...

"ROCm docker 이미지가 설치된 것을 확인 > 컨테이너에 /dev 를 마운트 && 컨테이너 내에 render/video 그룹에 사용자 추가 > 컨테이너 상에서 GPU 접근" 으로 해결하더군요. 잘 못 사용하면 큰일날 수 있겠다 싶었습니다.

제가 찾던 SDK 여기있네요

근데 큰 문제 없다면 넣어두는게 나쁘지 않다고 생각합니다.
어차피 llm 이 정리해주면 편해서 만들기 어려운 것도 아니고, 구글만 상대할 껀 아니니까요.