저는 대 claude 시대가 오기 전에도 Rust로 api도 만들고 cli도 만들고 하면서 Rust에 꽤 많은 시간을 투자했었습니다!
tmux를 대체해야겠다는 생각을 꽤 최근에 해서, tmux 자체를 대체한지는 얼마 되지 않았으나 멀티플렉서도 만들고 이틀차부터 tmux 사용을 최소화했었습니다!
여긴 완성도 뿐만 아니라, 제가 만든 툴이 아닌 다른 툴로 fallback이 있으면 오히려 그게 도피처가 되어 개발을 열심히 안하는 것도 크지 않았나 싶습니다.
그러고 4개월이란 시간이 걸린 건, 말씀주신 것처럼 제 취향의 기능을 여러 사람이 쓸 수 있는 형태로 확징 가능하게 만드는 데도 오랜 세월이 걸린 것 같고, 이걸 대중에게 공개하려는 데도 꽤 용기가 필요해서 그랬던 게 아닐까 합니다.
그러고 orca 같은 프로그램은 기업의 후원을 받는데 반해 개인적으로 진행하는 프로젝트의 동기부여에 관해서는, 전 오히려 긍정적인 생각입니다.
물론 금전적 부담이 생긴 것만큼 큰 동기부여도 없겠지만, 전 모든 워크플로우를 제가 쓰는 툴로 맞춰둬서, 당장 제가 일하려면 이 툴을 개선해야하는 입장이라, 개인 시간도 최대한 쪼개서 이 툴들을 개선하는 데 투자하고 있습니다.
물론 제 동기부여가 떨어지는 순간 끝나는 문제가 있지만, 그 상황을 방지하려고 의도적으로 제 워크플로우를 제 툴들에 최적화해둬서 그런 상황을 방지하려 하고 있습니다!
개인적으론 지금 당장도 경쟁 툴들에 비해 부족한 건 기술적인 게 아닌 마케팅 뿐이란 생각이라, 피드백을 받아보고자 공개한 것도 꽤 큰 것 같습니다.
GPU 렌더링을 한 건 Windows에 대한 지원 보다는, 기술적 도전과 터미널 화면을 꽉 채우는 프로그램들에 대한 최적화였습니다.
개인적으로 Windows를 개발 용도로 안 쓴지 오래 되어 해당 OS에 대한 지원을 깊이 생각해보지 못했는데, 이제 기반이 꽤 생긴 것 같아 한 번 도전해볼만한가 싶긴 하네요.
저의 목표는 그냥 제 개발하는 전반에 copad 하나면 끝나는 것이고, 그걸 위해 plugin 시스템도 만들어뒀습니다!
그래서 GUI가 필요한 기능은 최대한 copad에 구현하려 하는 편입니다.
실서비스 적용은 아직 못 해봤습니다. 이 숫자들은 전부 공개 벤치마크 트레이스에서 나온 것이라, 그 한계를 먼저 말씀드리는 게 맞을 것 같습니다.
다만 idempotency key 설계에 참고가 될 만한 관측이 하나 있습니다.
"호출 두 번" vs "실행 두 번"을 구분해보려고, 응답에 들어있는 엔티티 ID를 비교해봤습니다. 같은 인자로 두 번 호출됐을 때 응답 ID가 다르면 실제로 두 개가 생긴 거고, 같으면 API가 알아서 걸러준 거니까요.
Toolathlon 벤치마크 기준으로 상태 변경 도구의 중복 호출 중:
ID가 달랐던 것(실제 중복 생성): 159건
ID가 같았던 것(API가 dedup): 76건
ID 자체가 없어서 판정 불가: 3,197건
여기서 구조가 하나 보였습니다. ID가 다른 159건이 전부 생성 계열 도구였습니다(문서 생성, 스프레드시트 생성, 파일 업로드, 퀴즈 생성). 반대로 갱신 계열(patch, update, enroll)에서는 ID가 다른 사례가 하나도 없었습니다 같은 대상을 가리킨 것이라 새로 생성되지는 않았던 거죠.
즉 idempotency key를 붙이신다면 생성(POST) 쪽이 우선순위일 것 같습니다. 갱신 쪽은 이미 자연스럽게 멱등인 경우가 많아 보였습니다.
그리고 아까 말씀드린 이메일 문제가 여기서 다시 걸립니다. 이메일 발송은 응답이 "성공" 문자열뿐이라 ID 비교가 불가능했습니다. idempotency key를 붙여도 그게 실제로 작동했는지 트레이스만으로는 확인할 방법이 없습니다. 내부 도구를 설계하신다면 발송 결과에 message ID를 돌려주게 하는 것만으로 감사 로그에서 검증이 됩니다. 말씀하신 hash chain 방식과도 잘 맞을 것 같고요.
다시 한 번 한계를 말씀드리면, 위 숫자는 전부 벤치마크 트레이스라 실제 운영 환경에서 같은 비율일지는 모릅니다. 혹시 트레이스를 돌려보실 일이 생기면 결과가 어떻게 다른지 궁금합니다.
그래서 폐쇄형 LLM을 최대한 저렴하게 시중에 공급하는 것이 최선입니다. 고성능 지능에 대한 접근성이 높으면, 자연히 오픈웨이트 모델에 대한 개발 유인이 줄어들고, 기술적 리더쉽도 일반 기관이 갖고 있을 수 있어요. 근데 정작 앤트로픽은 시장에서 제일 배타적인 공급자란 말이죠?
각 사건별 전문가를 찾아서 업무 범위만 맡기는 거보다 한사람한테 주면 알아서 다 잘 처리해주는걸 원하는게 사람 심리긴 하죠
LLM도 뭐든 아무거나 던지면 다 받아주는 식으로 보상함수가 짜여질 수밖에 없지 않을까요
공개 벤치마크여도 이 정도로 구체적인 숫자는 처음 봤습니다. 감사합니다.
159건 / 76건 / 3,197건 비율이 특히 눈에 들어왔습니다. 판정 불가(ID 없음)가 압도적으로 많다는 게 — 결국 대부분의 중복이 추적 자체가 안 되는 구간에 있다는 뜻이고, "감사 로그가 있으면 된다"고 안심하면 안 된다는 걸 다시 확인했습니다.
생성(POST) 우선이라는 방향은 저희 설계와 정확히 맞닿아 있습니다. 저희 hash chain에서 idempotency key를 생성 이벤트에 먼저 붙이려던 이유가 정확히 여기였습니다.
이메일 message ID 제안은 바로 반영하겠습니다. 내부 도구 스펙에 "응답에 엔티티 ID 필수"를 추가하는 것만으로 감사 로그의 검증 가능성이 달라지더라고요. hash chain에 ID를 앵커로 쓰면 중복 여부를 계산만으로 확인할 수 있고요.
혹시 3,197건의 "ID 없음" 케이스가 어떤 도구 유형에 몰려있었는지 파악이 되셨나요? 이메일 외에 "성공/실패"만 돌려주는 도구가 얼마나 되는지 궁금합니다.
현재는 최적화 중이라 금주 내로 마무리되면 더 깔끔히 보실 수 있을 것 같습니다 :)
벌써 한국어 전환 기능을 추가해주셨네요 :)
정말 감사합니다
저도 비슷한 걸 만드는 분을 만나니 꽤 반가운 느낌이네요!
저는 대 claude 시대가 오기 전에도 Rust로 api도 만들고 cli도 만들고 하면서 Rust에 꽤 많은 시간을 투자했었습니다!
tmux를 대체해야겠다는 생각을 꽤 최근에 해서, tmux 자체를 대체한지는 얼마 되지 않았으나 멀티플렉서도 만들고 이틀차부터 tmux 사용을 최소화했었습니다!
여긴 완성도 뿐만 아니라, 제가 만든 툴이 아닌 다른 툴로 fallback이 있으면 오히려 그게 도피처가 되어 개발을 열심히 안하는 것도 크지 않았나 싶습니다.
그러고 4개월이란 시간이 걸린 건, 말씀주신 것처럼 제 취향의 기능을 여러 사람이 쓸 수 있는 형태로 확징 가능하게 만드는 데도 오랜 세월이 걸린 것 같고, 이걸 대중에게 공개하려는 데도 꽤 용기가 필요해서 그랬던 게 아닐까 합니다.
그러고 orca 같은 프로그램은 기업의 후원을 받는데 반해 개인적으로 진행하는 프로젝트의 동기부여에 관해서는, 전 오히려 긍정적인 생각입니다.
물론 금전적 부담이 생긴 것만큼 큰 동기부여도 없겠지만, 전 모든 워크플로우를 제가 쓰는 툴로 맞춰둬서, 당장 제가 일하려면 이 툴을 개선해야하는 입장이라, 개인 시간도 최대한 쪼개서 이 툴들을 개선하는 데 투자하고 있습니다.
물론 제 동기부여가 떨어지는 순간 끝나는 문제가 있지만, 그 상황을 방지하려고 의도적으로 제 워크플로우를 제 툴들에 최적화해둬서 그런 상황을 방지하려 하고 있습니다!
개인적으론 지금 당장도 경쟁 툴들에 비해 부족한 건 기술적인 게 아닌 마케팅 뿐이란 생각이라, 피드백을 받아보고자 공개한 것도 꽤 큰 것 같습니다.
GPU 렌더링을 한 건 Windows에 대한 지원 보다는, 기술적 도전과 터미널 화면을 꽉 채우는 프로그램들에 대한 최적화였습니다.
개인적으로 Windows를 개발 용도로 안 쓴지 오래 되어 해당 OS에 대한 지원을 깊이 생각해보지 못했는데, 이제 기반이 꽤 생긴 것 같아 한 번 도전해볼만한가 싶긴 하네요.
저의 목표는 그냥 제 개발하는 전반에 copad 하나면 끝나는 것이고, 그걸 위해 plugin 시스템도 만들어뒀습니다!
그래서 GUI가 필요한 기능은 최대한 copad에 구현하려 하는 편입니다.
렌더링 방식에서 꽤 큰 차이가 있는데, 사실 엔드 유저 입장에서 느끼기 큰 차이는 아니라서 자세히 소개드리긴 다소 머쓱하네요. 말씀주신 것처럼 생산 비용이 낮아지면서 손에 맞는 게 최고가 된 세상이 아닌가 싶습니다..!
사내 상담기록 인사과 징계폴더에 수집하던 삼성은 역시 글로벌 선도기업
실서비스 적용은 아직 못 해봤습니다. 이 숫자들은 전부 공개 벤치마크 트레이스에서 나온 것이라, 그 한계를 먼저 말씀드리는 게 맞을 것 같습니다.
다만 idempotency key 설계에 참고가 될 만한 관측이 하나 있습니다.
"호출 두 번" vs "실행 두 번"을 구분해보려고, 응답에 들어있는 엔티티 ID를 비교해봤습니다. 같은 인자로 두 번 호출됐을 때 응답 ID가 다르면 실제로 두 개가 생긴 거고, 같으면 API가 알아서 걸러준 거니까요.
Toolathlon 벤치마크 기준으로 상태 변경 도구의 중복 호출 중:
ID가 달랐던 것(실제 중복 생성): 159건
ID가 같았던 것(API가 dedup): 76건
ID 자체가 없어서 판정 불가: 3,197건
여기서 구조가 하나 보였습니다. ID가 다른 159건이 전부 생성 계열 도구였습니다(문서 생성, 스프레드시트 생성, 파일 업로드, 퀴즈 생성). 반대로 갱신 계열(patch, update, enroll)에서는 ID가 다른 사례가 하나도 없었습니다 같은 대상을 가리킨 것이라 새로 생성되지는 않았던 거죠.
즉 idempotency key를 붙이신다면 생성(POST) 쪽이 우선순위일 것 같습니다. 갱신 쪽은 이미 자연스럽게 멱등인 경우가 많아 보였습니다.
그리고 아까 말씀드린 이메일 문제가 여기서 다시 걸립니다. 이메일 발송은 응답이 "성공" 문자열뿐이라 ID 비교가 불가능했습니다. idempotency key를 붙여도 그게 실제로 작동했는지 트레이스만으로는 확인할 방법이 없습니다. 내부 도구를 설계하신다면 발송 결과에 message ID를 돌려주게 하는 것만으로 감사 로그에서 검증이 됩니다. 말씀하신 hash chain 방식과도 잘 맞을 것 같고요.
다시 한 번 한계를 말씀드리면, 위 숫자는 전부 벤치마크 트레이스라 실제 운영 환경에서 같은 비율일지는 모릅니다. 혹시 트레이스를 돌려보실 일이 생기면 결과가 어떻게 다른지 궁금합니다.
스크린샷을 담는 소쿠리네요
비슷한 아이디어의 JIT 컴파일 접근으로 numba가 있는데 커버리지가 더 큰 느낌이네요
gps oss 120b 같은 걸 내놓기만 하면 그나마 설득력이 있어보일 것 같은데 글쎄요
그래서 폐쇄형 LLM을 최대한 저렴하게 시중에 공급하는 것이 최선입니다. 고성능 지능에 대한 접근성이 높으면, 자연히 오픈웨이트 모델에 대한 개발 유인이 줄어들고, 기술적 리더쉽도 일반 기관이 갖고 있을 수 있어요. 근데 정작 앤트로픽은 시장에서 제일 배타적인 공급자란 말이죠?
멋지네요, herdr이랑 유사해보이는데 어떤 차이점이 있는지 궁금하군요~
참고로 저는 GUI와 PTY를 동시에 지원하면서 칸반보드로 매니징하는게 편해서 https://github.com/horang-labs/tessera 를 만들었습니다ㅎㅎ자기 손에 편한게 최고의 툴이죠
스크린샷용 폴더를 만들어놓고, 다운로드 폴더 옆에 하나 더 추가해서 사용 중인데,
별도의 앱으로 관리하는 분들도 계셨군요
바른말하면 밉보이는것하고 비슷한듯.
보안과 똑같이 뚫려서 피해받는 순간 끝나는데
지금은 아니니까 안일하게 다들 대응하는것같음
당장 내일 좀비바이러스 푸는 AI가 나올지 어떻게 알까
좋은 글 감사합니다
IDE 수준이라고 하지만 터미널 폼을 유지하고 있는 것이 너무 깜찍한 듯 합니다 예쁘네요
전 도구를 분리하는게 도움이 된다고 생각합니다. 서재라는 공간이 없어도 책을 읽을 수 있지만 그럼에도 서재가 나름의 기능이 있듯이... 그러나 그것과 별개로 글의 예시들은 조금 억지스러워 보이긴 하네요
잘못 올리면 덮어쓰곤 했는데 이젠 못하겠네요 하핫
cmd+z 를 누르면 기존 상태가 되고, cmd+shift+z 를 누르면 살아난 내용이 다시 이후 상태가 되어야 하는데, 이 상식이 지켜지지 않는 경우가 더러 있더군요. 굉장히 짜증나는 상황..