의도하지 않게 카페인 섭취를 4일정도 안했는데 신기하게도 개운한 느낌이 있네요.
몇 년간 평균 아아 2잔씩 먹다가 올해는 거의 불규칙한 패턴으로 3~4잔까지 늘어났었는데 카페인을 줄여야겠다는 생각이 훅 드네요.
당장 완벽하게 끊지는 못하겠지만 올해는 하루 평균 최대 아아 1잔으로 한 번 자제해봐야겠어요.
몇 년간 평균 아아 2잔씩 먹다가 올해는 거의 불규칙한 패턴으로 3~4잔까지 늘어났었는데 카페인을 줄여야겠다는 생각이 훅 드네요.
당장 완벽하게 끊지는 못하겠지만 올해는 하루 평균 최대 아아 1잔으로 한 번 자제해봐야겠어요.
👍15❤5
요새 빌더들과 만나다보면 agentic coding 시대 요새 어떻게 하고 계시나요? 라는 이야기를 하고는 합니다. 저는 크게 3가지인 것 같습니다.
1. 시스템 이해와 최적화, 그리고 기여: Harness라고 부르는 AI Agent 시스템의 이해입니다. 이것이 없다면 LLM은 좋은 1회성 질의응답기인 것이죠. 이미 Claude Code, Codex 등이 아주 좋은 버전을 제공하고 있으나, 세분화해서 본다면 Agent Loop, Tool Set, Memory System 등 여러 요소가 포함되어 있습니다. 이런 도구들은 LLM이 가지고 있는 한계를 끝까지 끌어올리는 역할을 할 수 있습니다.
그런데 이 시스템에 100% 정답은 없습니다. 뛰어난 엔지니어들이 만든 정답에 가까울 수 있는 결과물이지만 휴리스틱에서 나오는 결과물이기 때문입니다. 지난 AI의 여러 모델 발전이 그랬듯 각각의 경험에서 나온 인지과학적 선택이 우연으로 좋은 harness를 만들 수 있다고 저는 봅니다. AI 결과물을 한 번에 만족할 수 없이 여전히 깎아나가야 하는 단계가 있기에 UX 등도 다양하게 고민해볼 수 있겠죠.
근데 harness 깎기를 굳이 주변에게 추천하고 싶지는 않습니다. 왜냐면 근래 모델의 바닐라도 충분히 좋다고 생각하며 굳이 이 부분에 스트레스 받으며 팔로업을 할 필요는 없다고 봅니다. 다만 harness를 통해 많게는 10x 생산성이 나올 수 있는 부분이 있는 것 같기에 아직은 알면 좋은 영역인 것 같네요. 결론은 굳이 이걸로 성공하고 싶은 게 아니라면 여러 엔지니어들이 깎은 결과물을 가져다 쓰시는 것 추천합니다.
2. Unlearning. 저는 도파민 중독자라 컴퓨터 시작 이것저것 잡다하게 건드려서 오히려 바이브코딩 초반에는 좀 편했던 것 같습니다. 그런데 하다보니 이런 전공지식과 애매한 지식들이 저를 어떤 방법론에 묶어둔다는 결론에 최근에 도달했습니다.
예시로 저는 결과물에 대한 내용을 읽어보는 과정에서 아직도 tab을 3개 정도만 키고 개발하는데 이래서는 절대 이 시대의 속도감을 낼 수는 없겠더라구요. 그래서 최근에는 결과물들만 머리에 그리고 병렬처리하면서 스스로의 워크플로우를 타파해보려고 하고 있습니다. 기본적으로는 아에 모르는 테크스택를 선택하고, 실패에 대한 부담감을 덜어내면서 루프를 빠르게 돌리고, AI에게 최대한 위임하려는 시도를 해보고 있습니다.
누군가는 오히려 디테일한 부분에서 잘 잡는 사람이 있는 반면, 저는 고등학생 시절만 하더라도 암기력은 부족하고 추상화만 잘해서 시험은 망쳐도 친구들한테도 자료 제작과 설명만 잘하던 사람이라. 어느 순간에는 반대로 디테일을 잡는 것에 20대 많은 부분을 할애했는데 이젠 다시 추상화 레벨로 돌아가기 위해 노력중입니다.
3. 취향에 대한 집착: 저는 지난 몇 년간 적당한 난이도의 코드를 빠르게 읽고 쓰고, 대중향 리서치를 작성하는 것으로 여러 기회를 얻었던 사람으로 AI시대에 자기정체성이 좀 흔들렸던 것 같습니다.
이제는 모두가 빠르게 코드를 쓸 수 있고 그것으로 컨텐츠를 쓸 수 있는 시대가 되며 오히려 본인만의 감각이, 미감이, 취향이 좋은 사람들의 결과물이 부각되는 시대를 체감하고 있기 때문인 것 같습니다. 부끄럽지만 저는 돌이켜보면 바보같이 데이터와 기술만 뜯어보고, 독스를 보며 공부를 즐겼던 사람으로 취향이 희미해진 사람이 되었더라고요. 반골 기질이 강했던 어린 시절에는 절대 샌님처럼 살기 싫고 할 말 다하고 다르게 살아야지 했는데 결국 샌님 중 제일 덜 샌님인 그 범주에 포함되어 있는 사람이더라고요.
그래서 요새 아에 제가 좋아하는 게 뭔지, 진짜 이걸 극단으로 간다면, 이걸 업으로 삼기 위해서는 어떤 감각을 키워야할지 고민하는 시간을 많이 보내고 있습니다. 지나간 취미의 어떤 포인트가 좋았는지 회상을 하는 시간, 시간 낭비라 생각하여 놓쳤던 애니도 다시 보고, 다큐도 보고, 그러면서 새로운 것들도 하나씩 해보고 원하는 미래 모습을 다시 그려보고 있습니다.
최근에 이야기 나누면서 내린 생각 중 하나는 개발/테크/연구말고 언젠가는 지금의 Redbull 같은 회사에서 일해보거나 창업하고 싶어요. 제 시야 내에서는 인간이 보여줄 수 있는 창의와 도전을 가장 섹시하고 펑키하게 보여주는 곳이 아닐까 싶네요. 그래서 첨부이미지는 위 많은 이야기를 생각하며 만들고 있는 F1 대시보드입니다. (아직 미완이지만 궁금한 분들을 위해 링크는 댓글에 둡니다.)
글을 쓰면서도 계속 흔들립니다. 다들 각자 가는 길 모두 화이팅입니다. 글 읽어주셔서 감사합니다.
1. 시스템 이해와 최적화, 그리고 기여: Harness라고 부르는 AI Agent 시스템의 이해입니다. 이것이 없다면 LLM은 좋은 1회성 질의응답기인 것이죠. 이미 Claude Code, Codex 등이 아주 좋은 버전을 제공하고 있으나, 세분화해서 본다면 Agent Loop, Tool Set, Memory System 등 여러 요소가 포함되어 있습니다. 이런 도구들은 LLM이 가지고 있는 한계를 끝까지 끌어올리는 역할을 할 수 있습니다.
그런데 이 시스템에 100% 정답은 없습니다. 뛰어난 엔지니어들이 만든 정답에 가까울 수 있는 결과물이지만 휴리스틱에서 나오는 결과물이기 때문입니다. 지난 AI의 여러 모델 발전이 그랬듯 각각의 경험에서 나온 인지과학적 선택이 우연으로 좋은 harness를 만들 수 있다고 저는 봅니다. AI 결과물을 한 번에 만족할 수 없이 여전히 깎아나가야 하는 단계가 있기에 UX 등도 다양하게 고민해볼 수 있겠죠.
근데 harness 깎기를 굳이 주변에게 추천하고 싶지는 않습니다. 왜냐면 근래 모델의 바닐라도 충분히 좋다고 생각하며 굳이 이 부분에 스트레스 받으며 팔로업을 할 필요는 없다고 봅니다. 다만 harness를 통해 많게는 10x 생산성이 나올 수 있는 부분이 있는 것 같기에 아직은 알면 좋은 영역인 것 같네요. 결론은 굳이 이걸로 성공하고 싶은 게 아니라면 여러 엔지니어들이 깎은 결과물을 가져다 쓰시는 것 추천합니다.
2. Unlearning. 저는 도파민 중독자라 컴퓨터 시작 이것저것 잡다하게 건드려서 오히려 바이브코딩 초반에는 좀 편했던 것 같습니다. 그런데 하다보니 이런 전공지식과 애매한 지식들이 저를 어떤 방법론에 묶어둔다는 결론에 최근에 도달했습니다.
예시로 저는 결과물에 대한 내용을 읽어보는 과정에서 아직도 tab을 3개 정도만 키고 개발하는데 이래서는 절대 이 시대의 속도감을 낼 수는 없겠더라구요. 그래서 최근에는 결과물들만 머리에 그리고 병렬처리하면서 스스로의 워크플로우를 타파해보려고 하고 있습니다. 기본적으로는 아에 모르는 테크스택를 선택하고, 실패에 대한 부담감을 덜어내면서 루프를 빠르게 돌리고, AI에게 최대한 위임하려는 시도를 해보고 있습니다.
누군가는 오히려 디테일한 부분에서 잘 잡는 사람이 있는 반면, 저는 고등학생 시절만 하더라도 암기력은 부족하고 추상화만 잘해서 시험은 망쳐도 친구들한테도 자료 제작과 설명만 잘하던 사람이라. 어느 순간에는 반대로 디테일을 잡는 것에 20대 많은 부분을 할애했는데 이젠 다시 추상화 레벨로 돌아가기 위해 노력중입니다.
3. 취향에 대한 집착: 저는 지난 몇 년간 적당한 난이도의 코드를 빠르게 읽고 쓰고, 대중향 리서치를 작성하는 것으로 여러 기회를 얻었던 사람으로 AI시대에 자기정체성이 좀 흔들렸던 것 같습니다.
이제는 모두가 빠르게 코드를 쓸 수 있고 그것으로 컨텐츠를 쓸 수 있는 시대가 되며 오히려 본인만의 감각이, 미감이, 취향이 좋은 사람들의 결과물이 부각되는 시대를 체감하고 있기 때문인 것 같습니다. 부끄럽지만 저는 돌이켜보면 바보같이 데이터와 기술만 뜯어보고, 독스를 보며 공부를 즐겼던 사람으로 취향이 희미해진 사람이 되었더라고요. 반골 기질이 강했던 어린 시절에는 절대 샌님처럼 살기 싫고 할 말 다하고 다르게 살아야지 했는데 결국 샌님 중 제일 덜 샌님인 그 범주에 포함되어 있는 사람이더라고요.
그래서 요새 아에 제가 좋아하는 게 뭔지, 진짜 이걸 극단으로 간다면, 이걸 업으로 삼기 위해서는 어떤 감각을 키워야할지 고민하는 시간을 많이 보내고 있습니다. 지나간 취미의 어떤 포인트가 좋았는지 회상을 하는 시간, 시간 낭비라 생각하여 놓쳤던 애니도 다시 보고, 다큐도 보고, 그러면서 새로운 것들도 하나씩 해보고 원하는 미래 모습을 다시 그려보고 있습니다.
최근에 이야기 나누면서 내린 생각 중 하나는 개발/테크/연구말고 언젠가는 지금의 Redbull 같은 회사에서 일해보거나 창업하고 싶어요. 제 시야 내에서는 인간이 보여줄 수 있는 창의와 도전을 가장 섹시하고 펑키하게 보여주는 곳이 아닐까 싶네요. 그래서 첨부이미지는 위 많은 이야기를 생각하며 만들고 있는 F1 대시보드입니다. (아직 미완이지만 궁금한 분들을 위해 링크는 댓글에 둡니다.)
글을 쓰면서도 계속 흔들립니다. 다들 각자 가는 길 모두 화이팅입니다. 글 읽어주셔서 감사합니다.
❤25👍1
Forwarded from Simon's Rabbit Crypt - KR
해시드에서 다양한 비즈니스 업무를 서포트할 인턴을 채용합니다.
추천하실 분이 있으시면 커버레터와 레쥬메를 아래 이메일로 보내주시도록 안내 부탁드립니다. 채용은 가능한 빠른 시일 내(ASAP) 진행 예정입니다.
[email protected]
감사합니다.
추천하실 분이 있으시면 커버레터와 레쥬메를 아래 이메일로 보내주시도록 안내 부탁드립니다. 채용은 가능한 빠른 시일 내(ASAP) 진행 예정입니다.
[email protected]
감사합니다.
❤3
많은 사람이 그렇듯 Figma 없이도, 바이브코딩스럽지 않은 뷰를 만들어 낼 수 있을까에 대한 실험을 계속 해보는 중.
미드저니 초기 경험과 같이 디테일한 명령어가 점점 중요해지고 레퍼런스를 아는 게 중요했듯, 웹디자인 바이브코딩 또한 다양한 레퍼런스를 보고 디자인 용어를 살펴보는 중
이번 모델 업데이트 테스트를 위해 Codex를 사용해보긴 했는데, 명확한 요청사항이 있다면 Codex가 도움이 되긴한데 여전히 알잘딱깔센의 경험에서는 Claude Code가 우세하다고 느낌.
이번 주 F1 시작해서 일단 계속 생각했던 것 만들어보는 중. 근데 이건 오픈소스로 풀 것도 아니고 어떻게 어필하고 키우지 고민중.
https://f1thedata.com/
미드저니 초기 경험과 같이 디테일한 명령어가 점점 중요해지고 레퍼런스를 아는 게 중요했듯, 웹디자인 바이브코딩 또한 다양한 레퍼런스를 보고 디자인 용어를 살펴보는 중
이번 모델 업데이트 테스트를 위해 Codex를 사용해보긴 했는데, 명확한 요청사항이 있다면 Codex가 도움이 되긴한데 여전히 알잘딱깔센의 경험에서는 Claude Code가 우세하다고 느낌.
이번 주 F1 시작해서 일단 계속 생각했던 것 만들어보는 중. 근데 이건 오픈소스로 풀 것도 아니고 어떻게 어필하고 키우지 고민중.
https://f1thedata.com/
👍10👏3❤2
이번주에 운동갔다가 PT 선생님 만나서 기존 프로젝트 운영 물어보니 본인의 유저 피드백 바탕 수정에서 Lovable의 한계를 여러가지 말씀하셔서 이제 Claude Code로 옮기라고 말씀드렸습니다. 그리고 그날 새벽인가 연락와서 설치까지 완료하고 주무심ㄷㄷ
오늘은 물어보니 Claude Code로 기존 Lovable 프로젝트로 옮겨서 이것저것 시도해보는 중이라고 하시네요.
키워드만 알려줬는데 혼자 하는 힘이 일단 재능 of 재능이 아닐까 싶음.
* 근데 이거 하고 개발자 회원분들과 대화가 잘통한다고 하시고, 일부는 제 이름을 안다고 하는데 누굴까 ㅇㅅㅇ
오늘은 물어보니 Claude Code로 기존 Lovable 프로젝트로 옮겨서 이것저것 시도해보는 중이라고 하시네요.
키워드만 알려줬는데 혼자 하는 힘이 일단 재능 of 재능이 아닐까 싶음.
* 근데 이거 하고 개발자 회원분들과 대화가 잘통한다고 하시고, 일부는 제 이름을 안다고 하는데 누굴까 ㅇㅅㅇ
❤19
오늘 갑자기 떠올라서 AI Agent CLI 하나 만들기 시작했는데, 제 생각보다 몹시 어렵네요. 모델들 성능이 좋아 쉬울 줄 알았는데, 신경써야하는 기능과 시스템이 하나 둘이 아니었음.
- 일단 TUI 디자인에서 Ink가 진짜 무겁고 IMEInput (그 한글 조합형으로 깨지는거) 이거 수정이 잘 안됨. 괜히 Claude Code가 해당 이슈 수정이 느린 이유를 알았음
- Opencode의 위력은 물론 내부 여러 기능도 있지만 OpenTUI를 잘 만들었다는게 엄청 큰 듯. (저는 Opencode에서 좀 좋은것만 빼오는 툴을 만들기에 OpenTUI 쓰면 카피캣 될까봐 안씀.)
- Harness에서 유기적으로 Tool 연결하고 이거 루프를 잘 구성하는게 매우 까다로움. 단순히 auth 연결해서 ai를 가져와도 이게 결국 어떤 tool을 세팅하고 내부 시스템을 사용하고 컨텍스트를 유지하는 게 스킬이었음.
- 그리고 auth를 어떻게 핸들링하느냐도 어려움. 근데 이건 vercel ai sdk 쓰면 되는 듯.
아직도 AI-native Dev로 진화하지 못한 패배감 넘치는 이 느낌.
- 일단 TUI 디자인에서 Ink가 진짜 무겁고 IMEInput (그 한글 조합형으로 깨지는거) 이거 수정이 잘 안됨. 괜히 Claude Code가 해당 이슈 수정이 느린 이유를 알았음
- Opencode의 위력은 물론 내부 여러 기능도 있지만 OpenTUI를 잘 만들었다는게 엄청 큰 듯. (저는 Opencode에서 좀 좋은것만 빼오는 툴을 만들기에 OpenTUI 쓰면 카피캣 될까봐 안씀.)
- Harness에서 유기적으로 Tool 연결하고 이거 루프를 잘 구성하는게 매우 까다로움. 단순히 auth 연결해서 ai를 가져와도 이게 결국 어떤 tool을 세팅하고 내부 시스템을 사용하고 컨텍스트를 유지하는 게 스킬이었음.
- 그리고 auth를 어떻게 핸들링하느냐도 어려움. 근데 이건 vercel ai sdk 쓰면 되는 듯.
아직도 AI-native Dev로 진화하지 못한 패배감 넘치는 이 느낌.
ordinary subinium
오늘 갑자기 떠올라서 AI Agent CLI 하나 만들기 시작했는데, 제 생각보다 몹시 어렵네요. 모델들 성능이 좋아 쉬울 줄 알았는데, 신경써야하는 기능과 시스템이 하나 둘이 아니었음. - 일단 TUI 디자인에서 Ink가 진짜 무겁고 IMEInput (그 한글 조합형으로 깨지는거) 이거 수정이 잘 안됨. 괜히 Claude Code가 해당 이슈 수정이 느린 이유를 알았음 - Opencode의 위력은 물론 내부 여러 기능도 있지만 OpenTUI를 잘 만들었다는게…
컨셉 잡고 AI CLI Tool 만드는 중.
다른 툴에 비해 큰 장점은 없고 기본 루프 수정하고 있는데 아주 기본적인 동작은 하니까 설레네요.
https://github.com/subinium/ddududdudu
다른 툴에 비해 큰 장점은 없고 기본 루프 수정하고 있는데 아주 기본적인 동작은 하니까 설레네요.
https://github.com/subinium/ddududdudu
🔥6❤1👍1
ordinary subinium
컨셉 잡고 AI CLI Tool 만드는 중. 다른 툴에 비해 큰 장점은 없고 기본 루프 수정하고 있는데 아주 기본적인 동작은 하니까 설레네요. https://github.com/subinium/ddududdudu
주말동안 머릿속에 떠오른 컨셉이 있어서 재밌게 AI coding CLI를 하나 만들어보고 있습니다. 아래 이미지가 시작시 인터페이스입니다. 이름하여 DDUDU DDUDU~ 혼자서 흥얼거리다가 생각났어요.
다들 알다싶이 모델 성능만큼 그 모델을 감싸는 하네스의 중요성은 이제 많은 분들이 알고 계실 거라 생각합니다. 같은 모델이라도 어떤 하네스 위에서 돌리느냐에 따라 결과가 꽤 달라지는데, 그 설계 쪽에 더 초점을 두고 깎아보고 싶었습니다. 원래는 기존 tool에 OMO/OMC처럼 플러그인을 추가하는 방식으로 쓰고 있었는데, 어느 순간 처음부터 만들어보면 어떨까 싶었습니다. Pi처럼 커스텀 영역이 열려있는 아이디어를 기반으로 조립해볼까도 했는데, 공부 겸 저만의 UI를 가지고 해보고 싶기도 했습니다. 떠오른 컨셉에서 디자인이 제일 중요했기에 결국 처음부터 리서치하면서 직접 만들어보는 쪽으로 방향을 틀었습니다.
최근 OpenCode와 OMO의 사용 경험이 꽤 좋았고, 그런 것들이 왜 좋았는지를 분해해서 처음부터 녹여보고 싶었습니다. 지금은 제가 이미 결제해둔 서비스가 많아(Claude, Codex, Gemini) 기존 로컬 credential을 재사용하면서 그 위에 제가 원하는 맥락 관리와 tool 조합을 올리는 구조입니다. 이미 공룡과도 같은 서비스들이 쌓아둔 인프라와 그들의 설계 지식 기반에서 커스텀에 가까운 작업(심지어 제작 작업도 Codex로 하고 있고)이라 from scratch라고 하기엔 좀 그렇지만, 그 조각들을 어떤 구조로 엮을지는 직접 해봐야 감이 오는 영역이라 시작했습니다.
이미 있는 기능들이고 많은 분들이 체감하고 계신 내용이겠지만, 처음부터 하나씩 만들다 보니 이런 것들이 다 고려 요소더라고요. 정리하면 이렇습니다.
[1] 모델 호출과 라우팅. 경험적으로 아시다싶이 프로바이더마다 잘하는 영역이 다릅니다. 복잡한 판단이 필요한 오케스트레이션에는 강한 모델을, 단순 반복 실행에는 빠른 모델을, 설계나 디자인 판단에는 또 다른 모델을 쓰는 식으로 모드를 나누고 작업에 따라 라우팅하는 구조를 시도하고 있습니다.
[2] Tool 구성. 여러 coding agent들을 뜯어보면 tool 조합이 정말 다양합니다. 파일 I/O나 셸 실행 같은 기본기부터 코드베이스 검색, 심볼 탐색, 다른 에이전트에게 작업 위임까지 범위가 넓은데, 어떤 tool이 왜 필요한지를 하나씩 뜯어보게 됩니다. 어디까지를 빌트인으로 넣고 어디부터 MCP 같은 확장으로 뺄지도 계속 조율하고 있습니다.
[3] Context 관리. 제한된 컨텍스트 창에 지금 필요한 정보만 채우는 문제입니다. 대화 전체를 다 넣으면 될 것 같지만 불필요한 맥락이 쌓이면 오히려 성능이 떨어집니다. 특히 저는 이전부터 context compaction 쪽을 관심있게 보고 있는데, 언제 얼마나 압축할지, 압축 후에도 사용자가 흐름을 잃지 않으려면 어떻게 해야 하는지 같은 부분을 고민하고 있습니다.
[4] 세션과 상태 유지. 사람은 아까 하던 작업을 자연스럽게 이어가지만 모델 입장에서는 매 턴이 완전히 새로운 요청입니다. 세션을 재개하거나 분기하거나, 긴 세션을 요약해서 다음 작업으로 넘기는 흐름이 필요합니다. 위임한 작업은 git worktree로 격리해서 메인 작업을 건드리지 않게 하고, 오래 걸리는 작업은 백그라운드로 빼서 메인 흐름을 막지 않게 하는 것도 여기서 풀고 있습니다.
[5] 검증과 복구. 코드를 한 번에 잘 쓰는 것보다, 쓴 다음에 검증하고 실패하면 고치고 필요하면 다른 에이전트에게 넘기고, 통과하면 실제 워크스페이스에 apply하는 전체 루프를 만드는 쪽에 시간을 쓰고 있습니다. 검증을 통과한 결과는 메모리에 남겨서 비슷한 작업이 나왔을 때 재활용할 수 있게 하는 흐름도 시도 중입니다.
[6] 메모리. 현재 세션의 작업 맥락, 과거 세션에서 배운 것, 코드베이스에 대한 구조적 지식, 반복 사용하는 규칙과 절차를 나눠서 각각 유지 기간과 저장 방식을 다르게 가져가면 어떨까 싶어서 그 구조를 실험하고 있습니다. 아직 정답을 찾았다기보다는 이런저런 조합을 시도해보고 있는 단계입니다.
[7] 권한과 신뢰 경계. 에이전트에게 얼마나 자율성을 줄 것인가의 문제입니다. 모든 걸 다 허용하면 위험하고, 매번 물어보면 느려집니다. tool별로 허용/확인/차단을 세분화하고, 전체 권한 수준을 단계별로 전환할 수 있는 구조를 잡고 있습니다. (근데 솔직히 이건 AI가 권장해주는 방식에서 크게는 벗어나지 못하고 있어요.)
[8] UI/UX. 에이전트가 지금 뭘 하고 있는지, 백그라운드 작업 상태, 외부 tool 연결 상태가 한눈에 보여야 합니다. 처음에 TUI를 Ink로 만들었는데 너무 무거워서 Rust 기반 Ratatui로 바꿨고, IME나 사용성 등 이게 정말 좋은 선택이었습니다. (이걸로 알게 된 점은 Opencode의 강점은 단순히 그들의 설계말고도 Opentui를 잘 만들었다는 점) 개인적으로 TUI를 좋아하기도 하고 터미널 안에서의 깔끔한 디자인과 가독성에 집착하는 편이라, 정보를 색과 배치로 최대한 빠르게 혼동 없이 해석할 수 있게 작업에 집중하고 있습니다. 이건 기능과 취향의 영역을 동시에 만족하는 부분이라 제일 열심히 시간을 쓰고 있습니다.
이것 외에도 시스템 전체의 데이터 구조나 슬래시 명령어나 알림 표시 방법 등 만들수록 고려해야 할 게 계속 나오고 있어 재밌네요. 아직 기본 기능 수정부터 하고 있는 단계이고, 기존 하네스들보다 좀 더 좋은 결과가 나오면 한 번 또 공유해보겠습니다.
목표는 제 하네스를 기반으로 제 하네스를 강화하는 그 날과 모든 이들이 쉽게 본인 CLI툴을 만들 수 있는 Pi보다 나은 Modular Harness 구축까지.
https://github.com/subinium/ddududdudu
다들 알다싶이 모델 성능만큼 그 모델을 감싸는 하네스의 중요성은 이제 많은 분들이 알고 계실 거라 생각합니다. 같은 모델이라도 어떤 하네스 위에서 돌리느냐에 따라 결과가 꽤 달라지는데, 그 설계 쪽에 더 초점을 두고 깎아보고 싶었습니다. 원래는 기존 tool에 OMO/OMC처럼 플러그인을 추가하는 방식으로 쓰고 있었는데, 어느 순간 처음부터 만들어보면 어떨까 싶었습니다. Pi처럼 커스텀 영역이 열려있는 아이디어를 기반으로 조립해볼까도 했는데, 공부 겸 저만의 UI를 가지고 해보고 싶기도 했습니다. 떠오른 컨셉에서 디자인이 제일 중요했기에 결국 처음부터 리서치하면서 직접 만들어보는 쪽으로 방향을 틀었습니다.
최근 OpenCode와 OMO의 사용 경험이 꽤 좋았고, 그런 것들이 왜 좋았는지를 분해해서 처음부터 녹여보고 싶었습니다. 지금은 제가 이미 결제해둔 서비스가 많아(Claude, Codex, Gemini) 기존 로컬 credential을 재사용하면서 그 위에 제가 원하는 맥락 관리와 tool 조합을 올리는 구조입니다. 이미 공룡과도 같은 서비스들이 쌓아둔 인프라와 그들의 설계 지식 기반에서 커스텀에 가까운 작업(심지어 제작 작업도 Codex로 하고 있고)이라 from scratch라고 하기엔 좀 그렇지만, 그 조각들을 어떤 구조로 엮을지는 직접 해봐야 감이 오는 영역이라 시작했습니다.
이미 있는 기능들이고 많은 분들이 체감하고 계신 내용이겠지만, 처음부터 하나씩 만들다 보니 이런 것들이 다 고려 요소더라고요. 정리하면 이렇습니다.
[1] 모델 호출과 라우팅. 경험적으로 아시다싶이 프로바이더마다 잘하는 영역이 다릅니다. 복잡한 판단이 필요한 오케스트레이션에는 강한 모델을, 단순 반복 실행에는 빠른 모델을, 설계나 디자인 판단에는 또 다른 모델을 쓰는 식으로 모드를 나누고 작업에 따라 라우팅하는 구조를 시도하고 있습니다.
[2] Tool 구성. 여러 coding agent들을 뜯어보면 tool 조합이 정말 다양합니다. 파일 I/O나 셸 실행 같은 기본기부터 코드베이스 검색, 심볼 탐색, 다른 에이전트에게 작업 위임까지 범위가 넓은데, 어떤 tool이 왜 필요한지를 하나씩 뜯어보게 됩니다. 어디까지를 빌트인으로 넣고 어디부터 MCP 같은 확장으로 뺄지도 계속 조율하고 있습니다.
[3] Context 관리. 제한된 컨텍스트 창에 지금 필요한 정보만 채우는 문제입니다. 대화 전체를 다 넣으면 될 것 같지만 불필요한 맥락이 쌓이면 오히려 성능이 떨어집니다. 특히 저는 이전부터 context compaction 쪽을 관심있게 보고 있는데, 언제 얼마나 압축할지, 압축 후에도 사용자가 흐름을 잃지 않으려면 어떻게 해야 하는지 같은 부분을 고민하고 있습니다.
[4] 세션과 상태 유지. 사람은 아까 하던 작업을 자연스럽게 이어가지만 모델 입장에서는 매 턴이 완전히 새로운 요청입니다. 세션을 재개하거나 분기하거나, 긴 세션을 요약해서 다음 작업으로 넘기는 흐름이 필요합니다. 위임한 작업은 git worktree로 격리해서 메인 작업을 건드리지 않게 하고, 오래 걸리는 작업은 백그라운드로 빼서 메인 흐름을 막지 않게 하는 것도 여기서 풀고 있습니다.
[5] 검증과 복구. 코드를 한 번에 잘 쓰는 것보다, 쓴 다음에 검증하고 실패하면 고치고 필요하면 다른 에이전트에게 넘기고, 통과하면 실제 워크스페이스에 apply하는 전체 루프를 만드는 쪽에 시간을 쓰고 있습니다. 검증을 통과한 결과는 메모리에 남겨서 비슷한 작업이 나왔을 때 재활용할 수 있게 하는 흐름도 시도 중입니다.
[6] 메모리. 현재 세션의 작업 맥락, 과거 세션에서 배운 것, 코드베이스에 대한 구조적 지식, 반복 사용하는 규칙과 절차를 나눠서 각각 유지 기간과 저장 방식을 다르게 가져가면 어떨까 싶어서 그 구조를 실험하고 있습니다. 아직 정답을 찾았다기보다는 이런저런 조합을 시도해보고 있는 단계입니다.
[7] 권한과 신뢰 경계. 에이전트에게 얼마나 자율성을 줄 것인가의 문제입니다. 모든 걸 다 허용하면 위험하고, 매번 물어보면 느려집니다. tool별로 허용/확인/차단을 세분화하고, 전체 권한 수준을 단계별로 전환할 수 있는 구조를 잡고 있습니다. (근데 솔직히 이건 AI가 권장해주는 방식에서 크게는 벗어나지 못하고 있어요.)
[8] UI/UX. 에이전트가 지금 뭘 하고 있는지, 백그라운드 작업 상태, 외부 tool 연결 상태가 한눈에 보여야 합니다. 처음에 TUI를 Ink로 만들었는데 너무 무거워서 Rust 기반 Ratatui로 바꿨고, IME나 사용성 등 이게 정말 좋은 선택이었습니다. (이걸로 알게 된 점은 Opencode의 강점은 단순히 그들의 설계말고도 Opentui를 잘 만들었다는 점) 개인적으로 TUI를 좋아하기도 하고 터미널 안에서의 깔끔한 디자인과 가독성에 집착하는 편이라, 정보를 색과 배치로 최대한 빠르게 혼동 없이 해석할 수 있게 작업에 집중하고 있습니다. 이건 기능과 취향의 영역을 동시에 만족하는 부분이라 제일 열심히 시간을 쓰고 있습니다.
이것 외에도 시스템 전체의 데이터 구조나 슬래시 명령어나 알림 표시 방법 등 만들수록 고려해야 할 게 계속 나오고 있어 재밌네요. 아직 기본 기능 수정부터 하고 있는 단계이고, 기존 하네스들보다 좀 더 좋은 결과가 나오면 한 번 또 공유해보겠습니다.
목표는 제 하네스를 기반으로 제 하네스를 강화하는 그 날과 모든 이들이 쉽게 본인 CLI툴을 만들 수 있는 Pi보다 나은 Modular Harness 구축까지.
https://github.com/subinium/ddududdudu
❤11👍3
아 요새 AI들도 프로젝트 다 제 기준 재미가 없는데 좀 미친거 없나요. 크립토에서 뇌가 절여졌어서 뭘봐도 다 도파민이 안도네요. 잘될 프로젝트들은 꽤 보이는데 스케일이 아쉽거나 재미가 없다.
잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?
잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?잼예없?
❤9
codex --yolo
claude --dangerously-skip-permissions
어느 순간부터 ai돌릴때 권한 없애는 것에 맛들였는데, 그 속도감에 맛들리다보니 비가역적인 것 같고 프롬프트를 더 잘쓰고 에러 대비 브랜치 관리 + 커밋주기를 높이기로 점점 바뀌는 것 같아요.
그리고 근래 쭉 하다보니 속도감 측면에서 codex가 더 편한 것 같고 디자인 요청 알잘딱갈센은 cc가 조금 더 나은 듯. opencode + omo 조합은 장기작업에서 context가 넘 무거워지는 단점이 있긴 한데, 초기 생산성에서 확실히 효과가 좋음.
그리고 틈틈히 session management툴 agf 업데이트 중. 오늘 중으로 resume / new session ux 개선 예정.
claude --dangerously-skip-permissions
어느 순간부터 ai돌릴때 권한 없애는 것에 맛들였는데, 그 속도감에 맛들리다보니 비가역적인 것 같고 프롬프트를 더 잘쓰고 에러 대비 브랜치 관리 + 커밋주기를 높이기로 점점 바뀌는 것 같아요.
그리고 근래 쭉 하다보니 속도감 측면에서 codex가 더 편한 것 같고 디자인 요청 알잘딱갈센은 cc가 조금 더 나은 듯. opencode + omo 조합은 장기작업에서 context가 넘 무거워지는 단점이 있긴 한데, 초기 생산성에서 확실히 효과가 좋음.
그리고 틈틈히 session management툴 agf 업데이트 중. 오늘 중으로 resume / new session ux 개선 예정.
GitHub
GitHub - subinium/agf: Agent Finder — One TUI to find, resume, and manage AI coding agent sessions (Claude Code, Codex, Opencode…
Agent Finder — One TUI to find, resume, and manage AI coding agent sessions (Claude Code, Codex, Opencode, Gemini) - subinium/agf
❤7👍5
ordinary subinium
주말동안 머릿속에 떠오른 컨셉이 있어서 재밌게 AI coding CLI를 하나 만들어보고 있습니다. 아래 이미지가 시작시 인터페이스입니다. 이름하여 DDUDU DDUDU~ 혼자서 흥얼거리다가 생각났어요. 다들 알다싶이 모델 성능만큼 그 모델을 감싸는 하네스의 중요성은 이제 많은 분들이 알고 계실 거라 생각합니다. 같은 모델이라도 어떤 하네스 위에서 돌리느냐에 따라 결과가 꽤 달라지는데, 그 설계 쪽에 더 초점을 두고 깎아보고 싶었습니다. 원래는 기존 tool에…
예상은 했지만 Harness를 완전 밑바닥부터 설계하는 건 공수가 많이 드네요.
기본적으로 업무의 처리 루프를 적당하게 잘 끝내는 게 어려운 것 같아요. 예를 들어 <주제X>를 리서치해줘. 라고 했을 때 크게 다음과 같은 이슈가 있습니다.
- 리서치하기 위해서 서브에이전트 병렬로 분배하고 처리 한다면 task 분할을 어떻게 해야할까? 이 작업을 위해 총 몇 개의 서브에이전트가 필요할까?
- 각 서브에이전트의 결과는 어떤 것이 종료 조건인가?
- 각 에이전트의 중간 과정이 진행되고 있음을 어떻게 보여줄까.
- 잘 했다는 것에 대한 verification은 무엇일까?
- 더 들어가면 tool에서 webfetch의 범위도 있고, 실패시 다음 행동 루프 방향도 있고...
미묘한 UX에서 그 고려하는 재미가 있어서 개발자에게 재밌는 작업은 맞는 것 같아요. 근데 이제 간단하게 돌아가는 시스템은 만들었지만 아직 원래 하고 싶었던 context management와 compaction은 시도도 못해봤어요. 기본으로 구동되면 디자인도 더 컨셉잡고 업그레이드하고, 여러 메타포 넣어서 더 재밌게 만들고 싶은데 갈 길이 머네요.
그럼에도 뚜두뚜두 레츠고
https://github.com/subinium/ddududdudu
기본적으로 업무의 처리 루프를 적당하게 잘 끝내는 게 어려운 것 같아요. 예를 들어 <주제X>를 리서치해줘. 라고 했을 때 크게 다음과 같은 이슈가 있습니다.
- 리서치하기 위해서 서브에이전트 병렬로 분배하고 처리 한다면 task 분할을 어떻게 해야할까? 이 작업을 위해 총 몇 개의 서브에이전트가 필요할까?
- 각 서브에이전트의 결과는 어떤 것이 종료 조건인가?
- 각 에이전트의 중간 과정이 진행되고 있음을 어떻게 보여줄까.
- 잘 했다는 것에 대한 verification은 무엇일까?
- 더 들어가면 tool에서 webfetch의 범위도 있고, 실패시 다음 행동 루프 방향도 있고...
미묘한 UX에서 그 고려하는 재미가 있어서 개발자에게 재밌는 작업은 맞는 것 같아요. 근데 이제 간단하게 돌아가는 시스템은 만들었지만 아직 원래 하고 싶었던 context management와 compaction은 시도도 못해봤어요. 기본으로 구동되면 디자인도 더 컨셉잡고 업그레이드하고, 여러 메타포 넣어서 더 재밌게 만들고 싶은데 갈 길이 머네요.
그럼에도 뚜두뚜두 레츠고
https://github.com/subinium/ddududdudu
GitHub
GitHub - subinium/ddududdudu: DDU-DU DDU-DU AI CODING HARNESS CLI TOOL
DDU-DU DDU-DU AI CODING HARNESS CLI TOOL. Contribute to subinium/ddududdudu development by creating an account on GitHub.
❤6
언어능력이 뛰어난 사람일수록 상대방이 어리숙하게 말해도 알아서 이해한다.
그래서 회사 영어권 동료들과 이야기하면 내 부족한 영어에도 다들 찰떡같이 알아들음.
그래서 어느 순간 동료와 1:1 영어 대화에 대한 부담감은 많이 사라졌는데, 근데 동료들이 내가 개떡같이 말해도 찰떡같이 알아들으니 영어 실력이 안느는 것 같은 느낌.
실시간 번역기 나와도 영어는 중요할 것 같은데, 영어 공부는 (하기도 넘 싫은데) 언제하지ㄹㅇ
그래서 회사 영어권 동료들과 이야기하면 내 부족한 영어에도 다들 찰떡같이 알아들음.
그래서 어느 순간 동료와 1:1 영어 대화에 대한 부담감은 많이 사라졌는데, 근데 동료들이 내가 개떡같이 말해도 찰떡같이 알아들으니 영어 실력이 안느는 것 같은 느낌.
실시간 번역기 나와도 영어는 중요할 것 같은데, 영어 공부는 (하기도 넘 싫은데) 언제하지ㄹㅇ
❤11
vibenote from subinium
https://x.com/trq212/status/2031506296697131352?s=46&t=_9QK1B_9Xfb5kENxfV3x-g
아 이런거 만들려고 했던건데 추가되었네. 클로드 돌아갈때 사이드로 프롬프트해서 대화 이어가기
❤3
⚡️SuperLightTUI
CLI 도구를 만드는데 Ink는 무겁고 RataTUI는 원하는 인터랙션이나 화면 분할에서 사용성이 살짝 부족하다고 느껴 새로운 Rust기반 TUI를 만들어봤습니다.
이제 사람 손으로 코드를 쓰는 경우가 점점 적어질 것이고, 이런 라이브러리를 만들면 skills도 만들어두는 게 유의미하겠다는 생각이 드네요.
여튼 TUI 좋아하는 분들은 언제나 사용해보고 피드백 환영합니다. 데모들 이쁘게 만들어서 공유해봄.
- https://github.com/subinium/SuperLightTUI
- x post
CLI 도구를 만드는데 Ink는 무겁고 RataTUI는 원하는 인터랙션이나 화면 분할에서 사용성이 살짝 부족하다고 느껴 새로운 Rust기반 TUI를 만들어봤습니다.
이제 사람 손으로 코드를 쓰는 경우가 점점 적어질 것이고, 이런 라이브러리를 만들면 skills도 만들어두는 게 유의미하겠다는 생각이 드네요.
여튼 TUI 좋아하는 분들은 언제나 사용해보고 피드백 환영합니다. 데모들 이쁘게 만들어서 공유해봄.
- https://github.com/subinium/SuperLightTUI
- x post
❤16