matrix.ts만 추가하면 새 provider가 붙는 구조는 아니고, provider 목록, 경로 안전성, 세션 찾기, transcript/search 처리, actions, health, 테스트, 문서 생성을 같이 맞춰야 합니다.
docs/PROVIDER_SUPPORT.md는 직접 수정하는 문서가 아니라 shared contracts의 provider registry와 문서 생성 스크립트 기준으로 자동 생성됩니다. provider별 지원 범위와 실제 로직과 어긋나지 않게 하려는 목적입니다.
안 그래도 API 쪽 search/transcript 로직이 꽤 커져서 분리/정리 작업을 보고 있었는데, 이번에 provider를 추가하기 쉽게 내부 adapter 및 가이드까지 같이 정리하고 OpenCode도 안전하게 read-only 지원부터 검토해볼게요. 로컬 세션 경로나 샘플 및 관련 정보를 이슈로 남겨주시면 계속 이어서 보겠습니다!
완전한 전체 자동화 상태를 추구하기보다는 작업을 분해해서 각 작업의 담당을 정의해보는 게 그나마 현실적인 전략이라 생각합니다. 패턴 인식이나 의미 추출, 보편 지식과 연결하는 작업은 LLM에게 맡기고 의미 부여, 맥락 추가, 의사결정은 사람이 하는게 그 예시입니다. 코딩 상황에 예시를 적용하면 반복 코드 생성이나 테스트 케이스 작성은 LLM에 위임하고 아키텍처 결정과 도메인 모델링은 사람이 하게 됩니다. 그러면 문제는 의사결정을 어디까지 자동화할 수 있는가로 좁혀지게 되고 조금 더 구체적인 사례를 쉽게 찾으실 수 있을거라 생각합니다
경기때문인지는 모르겠으나 최근들어 AI 에이전트로 모든것을 해결할수 있는것처럼 이야기하는 글이나 강의들이 많지만, 아직까지는 AI로만 모든것을 100%까지 해내기는 현실적으로 어렵습니다. 분야에 따라 최대 70-80% 정도라고 보고있고, 이 이상을 위해서는 분야의 전문가가 필수라고 봅니다.
저는 trilateral-validation이라고 claude subagent(fresh context)+codex+gemini 까지 붙여서 검증 스킬 하나 만들어두고 씁니다.
자잘한 오류 말고 방향성 자체를 틀어야 하는 실험이나 설계는 메인 개발은 클로드로 하고, gpt 5.5pro에 깃허브 앱달아서 검증시키구요.(codex가 프로 모델을 지원 안해서...)
프로덕션 개발은 안하고 연구만해서 생각못했는데 git hook도 한번 걸어봐야겠네요.
@hanityx 혹시 다른 provider를 추가할 수 있는 가이드를 만들어주실 수 있을까요? (opencode나 다른걸 더 넣어보고싶은데) docs/PROVIDER_SUPPORT.md 의 정보는 직접 취합하신건가요? apps/api-ts/src/domains/providers/matrix.ts 에는 직접 추가를 해야하나요? 인터페이스를 분리한다면 조금 더 편해질 것 같아서요.
모델과 하네스는 둘 중 어느 것이 좋다라는 관점에서 한 발 물러나, 어느 모델에 어느 하네스를쓰는게 더 적합한지로 보면 어떨까요?
matrix.ts만 추가하면 새 provider가 붙는 구조는 아니고, provider 목록, 경로 안전성, 세션 찾기, transcript/search 처리, actions, health, 테스트, 문서 생성을 같이 맞춰야 합니다.docs/PROVIDER_SUPPORT.md는 직접 수정하는 문서가 아니라 shared contracts의 provider registry와 문서 생성 스크립트 기준으로 자동 생성됩니다. provider별 지원 범위와 실제 로직과 어긋나지 않게 하려는 목적입니다.안 그래도 API 쪽 search/transcript 로직이 꽤 커져서 분리/정리 작업을 보고 있었는데, 이번에 provider를 추가하기 쉽게 내부 adapter 및 가이드까지 같이 정리하고 OpenCode도 안전하게 read-only 지원부터 검토해볼게요. 로컬 세션 경로나 샘플 및 관련 정보를 이슈로 남겨주시면 계속 이어서 보겠습니다!
그럼 직접 좋은 글 한번 써주세요.
답변 감사합니다. 오리지널 포스팅에서 언급했듯, 그런글들이 눈에 뜨였지만, 구체적 방법은 논하지 안았기에 혹시나 잘 알려진 문서나 정보가 궁급했습니다.
글을 쓴 분이 어떤 분인지는 모르겠지만 개인적으로는 최근 10년간 읽은 글 중에서 가장 수준이 낮은 글이였습니다.
너무 충격을 받아서 글을 읽다가 멍해지는 느낌이 들었습니다.
완전한 전체 자동화 상태를 추구하기보다는 작업을 분해해서 각 작업의 담당을 정의해보는 게 그나마 현실적인 전략이라 생각합니다. 패턴 인식이나 의미 추출, 보편 지식과 연결하는 작업은 LLM에게 맡기고 의미 부여, 맥락 추가, 의사결정은 사람이 하는게 그 예시입니다. 코딩 상황에 예시를 적용하면 반복 코드 생성이나 테스트 케이스 작성은 LLM에 위임하고 아키텍처 결정과 도메인 모델링은 사람이 하게 됩니다. 그러면 문제는 의사결정을 어디까지 자동화할 수 있는가로 좁혀지게 되고 조금 더 구체적인 사례를 쉽게 찾으실 수 있을거라 생각합니다
경기때문인지는 모르겠으나 최근들어 AI 에이전트로 모든것을 해결할수 있는것처럼 이야기하는 글이나 강의들이 많지만, 아직까지는 AI로만 모든것을 100%까지 해내기는 현실적으로 어렵습니다. 분야에 따라 최대 70-80% 정도라고 보고있고, 이 이상을 위해서는 분야의 전문가가 필수라고 봅니다.
영화나 게임에서나 보던 군집 방어를 현실에서 보는 날이 오겠군요
잘 만든 게임이네요.
클로드면 몰라도 코파일럿은 공동 작성자 수준의 코드를 쓰는 것 같지는 않은데...
그 주장이 진짜라면 anthropic, google, openai에서 기존의 모든 소프트웨어를 대체하고도 남았겠죠
현재 LLM 수준에서 단순히 의문을 가지는것보다 중요한건 "인간의 상식"을 가지는것이곘죠.
미래에는 LLM이 순식간에 사람이 원하는 것들을 개발 가능해, SW 기업이 사라질것이라고 몇년전에 어느 유명한 사람이 예측했죠.
저도 당연한 얘기라고 생각해요.
다만, 이 글을 쓴건 제가 실제로 그리고 여러 커뮤니티에서 들은게 있어서 쓴거죠.
당연한 얘기를 길게 쓰고 여러 유명한 이름 나열하는, 별로 읽을 가치가 없다고 보입니다.
AI가 언젠가 지시문에도 없는 내용에관해서 의문을 가지고 의견을 낼수있는 날이오면
정말 인간이 대채될수도있겠지만
돈많은 사람이 자동운전이아니라 운전수를 대리고다니는것과 비슷하게
뭐 하라고 하면 일일히 확인을 대신해주는 사람이 미래의 엔지니어(나의모습) 이 되는걸까여
사실 이슈 pr 토론이 문제지 git 자체는 언제든 다른 서비스로 옮길 수 있거든요. git에 이 셋을 넣는 프로젝트도 있던데 그런 걸 사용하면 언제든 옮길 수 있겠네요
저는 trilateral-validation이라고 claude subagent(fresh context)+codex+gemini 까지 붙여서 검증 스킬 하나 만들어두고 씁니다.
자잘한 오류 말고 방향성 자체를 틀어야 하는 실험이나 설계는 메인 개발은 클로드로 하고, gpt 5.5pro에 깃허브 앱달아서 검증시키구요.(codex가 프로 모델을 지원 안해서...)
프로덕션 개발은 안하고 연구만해서 생각못했는데 git hook도 한번 걸어봐야겠네요.
@hanityx 혹시 다른 provider를 추가할 수 있는 가이드를 만들어주실 수 있을까요? (opencode나 다른걸 더 넣어보고싶은데) docs/PROVIDER_SUPPORT.md 의 정보는 직접 취합하신건가요? apps/api-ts/src/domains/providers/matrix.ts 에는 직접 추가를 해야하나요? 인터페이스를 분리한다면 조금 더 편해질 것 같아서요.
Enpass 사용해보세요 추천합니다
(Zuckerberg 본인은 다른 사람 밑에서 일한 적이 없음) ㅋㅋㅋㅋㅋㅋ