요즘엔 코딩 에이전트들이 자신의 부족한 부분을 보완해줄 수 있어서 자신의 강점을 확실히 알고 그걸 살릴 수 있으면 문턱이 낮아질 수도 있다고 생각합니다.
저도 항상 문서화가 문제였는데 그걸 코딩 에이전트에게 어느 정도 위임하니까 부담도 줄고 또 그 문서화된 자료를 검토하다 보니 문서화에 대한 안목도 생기고 있는 거 같습니다.
이런 도구에서 제일 어려운 건 쌓는 쪽이 아니라 버리는 쪽인데, garden을 별도 라이프사이클로 분리해둔 게 눈에 띕니다.
에이전트에게 주는 맥락은 오래되면 그냥 무용한 게 아니라 해롭습니다. 사람은 문서를 보면 "이거 옛날 얘기 같은데" 하는 감이 오는데 모델은 그 감이 없어서, 3개월 전에 참이었던 불변 조건을 지금도 참인 것처럼 그대로 받아 씁니다. 코드는 컴파일이라도 깨지지만 위키는 조용히 틀립니다.
그래서 페이지에 언제 기준인지, 무엇을 근거로 쓰였는지가 붙는지 궁금합니다. 마크다운으로 저장소에 두고 Git에서 리뷰하게 한 선택은 그 점에서 맞다고 보는데, diff에 남는 건 문서가 바뀐 시점이지 그 내용이 여전히 유효한 시점은 아니라서요.
1,700건이면 성능 얘기는 사실상 의미가 없는 규모라, 프론트에서 직접 처리하든 백엔드를 두든 둘 다 즉시 뜹니다. 그래서 판단 기준은 속도가 아니라 이미 있는 Python 로직을 다시 짜느냐 마느냐가 되는 게 맞다고 봅니다.
그 기준이면 Streamlit이 제일 잘 맞습니다. 매칭 로직을 그대로 import해서 쓰고 화면은 selectbox 5개랑 결과 테이블이면 끝이라 프론트 코드를 안 짜도 됩니다. Streamlit Community Cloud에 올리면 공유 가능한 링크도 무료로 나오고, JSON을 런타임에 읽게 해두면 파일만 갈아끼워도 최신 데이터가 반영됩니다.
정적 HTML은 배포가 더 간단한 대신 Python 로직을 JS로 옮겨야 해서, 점수 계산이 조금이라도 복잡하면 그 포팅에서 며칠이 다 갑니다. 목표가 이번 주 안에 동작을 보여주는 거라면 그 리스크는 안 지는 쪽이 나아 보입니다.
한 가지, Streamlit은 아무래도 제품보다 도구처럼 보입니다. 내부 의사결정권자 시연이고 목적이 "입력하면 실제로 뜬다"를 확인하는 거라면 상관없지만, 외부 고객 시연이면 그 점은 감안하셔야 합니다.
저는 대 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 방식과도 잘 맞을 것 같고요.
다시 한 번 한계를 말씀드리면, 위 숫자는 전부 벤치마크 트레이스라 실제 운영 환경에서 같은 비율일지는 모릅니다. 혹시 트레이스를 돌려보실 일이 생기면 결과가 어떻게 다른지 궁금합니다.
윈도우의 기본 기능이랑 비슷한걸까요? 윈도우 + V
와 이거하나면 역할극같은건 걱정하지 않아도 괜찮겠네요
엇 수정해두었습니다
요즘엔 코딩 에이전트들이 자신의 부족한 부분을 보완해줄 수 있어서 자신의 강점을 확실히 알고 그걸 살릴 수 있으면 문턱이 낮아질 수도 있다고 생각합니다.
저도 항상 문서화가 문제였는데 그걸 코딩 에이전트에게 어느 정도 위임하니까 부담도 줄고 또 그 문서화된 자료를 검토하다 보니 문서화에 대한 안목도 생기고 있는 거 같습니다.
읽어주셔서 감사합니다! 과거에는 문서나 테스트케이스, 검증 등등 사람이 직접 신경쓸 내용들이 많았는데 이제는 꽤 많은 부분을 AI 코딩 에이전트와 함께 할 수 있다보니 생각보다 오픈소스도 전보다 훨씬 운영 난이도가 내려가긴 한 것 같습니다!
@xguru 링크가 잘못된거 같네요~
맞아요, 클립보드 히스토리만 놓고 보면 겹치는 게 많습니다. 그런데 Raycast 는 클립보드 뿐만아니라 다른 기능이 많아서 과하게 느껴졌었어요.
제가 신경 쓴 건 이런 것들이에요.
우선 가볍고 클립보드 히스토리에 대해서만 관리하게 합니다 현재 2메가 정도네요
그리고 저장된 내용을 상세에서 고쳐넣을수 있습니다. 여러 프롬프트들을 검토하고 미리 조금씩 손보거나할 때 편햇어요
검색과 폴더링도 신경썻습니다. 일하면서 필요한 정보들 1회성이나 다시찾기 귀찮은것들을 해소하려고 노력햇습니다
본문, 태그, 제목등으로 검색되게 햇어요
나중에는 플러그인으로 기능이나 배치를 직접 붙일 수 있게 하고 싶은데, 요건 아직 구체화하진 못햇습니다.
Raycast 도 좋은 앱이라고 생각하고 있구요 취향에 따른 선택이 될수있게 노력해보고자 합니다
의견 감사드려요
이런 도구에서 제일 어려운 건 쌓는 쪽이 아니라 버리는 쪽인데, garden을 별도 라이프사이클로 분리해둔 게 눈에 띕니다.
에이전트에게 주는 맥락은 오래되면 그냥 무용한 게 아니라 해롭습니다. 사람은 문서를 보면 "이거 옛날 얘기 같은데" 하는 감이 오는데 모델은 그 감이 없어서, 3개월 전에 참이었던 불변 조건을 지금도 참인 것처럼 그대로 받아 씁니다. 코드는 컴파일이라도 깨지지만 위키는 조용히 틀립니다.
그래서 페이지에 언제 기준인지, 무엇을 근거로 쓰였는지가 붙는지 궁금합니다. 마크다운으로 저장소에 두고 Git에서 리뷰하게 한 선택은 그 점에서 맞다고 보는데, diff에 남는 건 문서가 바뀐 시점이지 그 내용이 여전히 유효한 시점은 아니라서요.
1,700건이면 성능 얘기는 사실상 의미가 없는 규모라, 프론트에서 직접 처리하든 백엔드를 두든 둘 다 즉시 뜹니다. 그래서 판단 기준은 속도가 아니라 이미 있는 Python 로직을 다시 짜느냐 마느냐가 되는 게 맞다고 봅니다.
그 기준이면 Streamlit이 제일 잘 맞습니다. 매칭 로직을 그대로 import해서 쓰고 화면은 selectbox 5개랑 결과 테이블이면 끝이라 프론트 코드를 안 짜도 됩니다. Streamlit Community Cloud에 올리면 공유 가능한 링크도 무료로 나오고, JSON을 런타임에 읽게 해두면 파일만 갈아끼워도 최신 데이터가 반영됩니다.
정적 HTML은 배포가 더 간단한 대신 Python 로직을 JS로 옮겨야 해서, 점수 계산이 조금이라도 복잡하면 그 포팅에서 며칠이 다 갑니다. 목표가 이번 주 안에 동작을 보여주는 거라면 그 리스크는 안 지는 쪽이 나아 보입니다.
한 가지, Streamlit은 아무래도 제품보다 도구처럼 보입니다. 내부 의사결정권자 시연이고 목적이 "입력하면 실제로 뜬다"를 확인하는 거라면 상관없지만, 외부 고객 시연이면 그 점은 감안하셔야 합니다.
Raycast에 있는 기능이 거의 다 지원되는것 같은데 혹시 어떤 점이 다를까요?
오... Show GN 글에서 항상 '뭐 만들었다'를 넘어서 이런 인사이트를 함께 보고 싶었는데, 그런 글을 보게 되니 흥분됩니다 ㅋㅋㅋ
각 사건별 전문가를 찾아서 업무 범위만 맡기는 거보다 한사람한테 주면 알아서 다 잘 처리해주는걸 원하는게 사람 심리긴 하죠
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 방식과도 잘 맞을 것 같고요.
다시 한 번 한계를 말씀드리면, 위 숫자는 전부 벤치마크 트레이스라 실제 운영 환경에서 같은 비율일지는 모릅니다. 혹시 트레이스를 돌려보실 일이 생기면 결과가 어떻게 다른지 궁금합니다.
스크린샷을 담는 소쿠리네요