터미널 프로토콜은 이번에 개발하면서 처음 접하신걸로 읽었는데,
궁금한건 개발 전에, 러스트에 대한 지식이 어느정도 있었는지도 궁금해요.
저는 지그로 개발했는데, 사실 지그는 손으로 써본 경험이 없고,
터미널 프로토콜이나 문법, 구조도 마찬가지로 지식이 전혀 없는 상태에서 제로베이스에서 공부하자는 느낌으로 도전한 케이스거든요.
그래서 외부라이브러리 의존성을 더 회피한거이기도 했습니다.
어떻게 만들어지는지를 좀 더 질문을 통해, AI랑 함꼐 트러블 슈팅을 하는걸 자연스레 의도해서, 통제하지 못하는데 실행은 되는, 그런 경우를 막고 싶었거든요
4개월 정도 걸리셨다고 하셨는데,
저도 원격으로 집에 있는 맥을 켜놓고 개발하다보니, ssh 에서 클로드나 코덱스 CLI에서 이미지 업로드 가능하게 프로토콜을 개발하고 나서 기존에 쓰던 터미널 앱 사실상 레퍼런스용도로 가끔 키는거 빼고는 아예 안 쓰기 시작했었습니다.
개인적으로 저는 터미널 한 2주차? 3주차쯔음이였던것 같아요.
답변 주신것처럼, 바로 쓰쎴다고 하는데, 그럼 그때 바로 tmux도 탈출이 진행되신걸까요?
그리고 4개월이나 걸린건 제 생각이지만, 계속 기능 추가나 편의성을 붙이는게, 오히려 코어 기능 개발보다 더 오래 걸리지 않았을까하는데 제가 생각한게 맞을지 궁금해요.
저는 그랬는데, 다른 사람들도 비슷한 제품 개발할때 비슷한 흐름인지 개인적으로 늘 궁금한 사항이였어서.. 실례가 아니라면 답변 해주시면 감사하겠습니다(__).
또, tmux에 비해 압도적으로 편해진 시기는 언제쯤부터 이신지도 궁금해요
하나 더, 저도 사실 비슷한 주제로 터미널 개발하고 만족하고 있긴 하지만, 어쩄든 계속 꾸준히 유지보수해야지만 하는 성격의 프로그램인데,
블로그에서 쓰신것처럼 Ocra, cmux, heder 등 비슷한 목적의 툴이 쏟아져나오고 있고, 대부분 유명한 라이브러리들은 기업이든 후원이든, 기여든 속도가 어쩔 수 없이 개인에 비해 압도적으로 빠르고 그만큼 피드백 잘 받는 프로그램이다보니,
경쟁(?) 하는 입장에서 한글 ime를 제외하면 사실상 디테일 한 편의성이나 UX 개선 속도에 비해서 압도적으로 뒤쳐질 수 밖에 없다는 생각이 드는데,
유지보수는 위에서 말한 비슷한 성격의 앱들에 비해 어디까지 하면 괜찮다라고 느끼시는도 궁금합니다.
그리고 러스트로 gpu를 선택하신 만큼 윈도우까지도 어느정도 염두에 두시는걸까요??
저도 개인 프로그램 개발이긴 하지만, 생태계는 발려도(?) 언급한 앱들의 퀄리티정도는 되는게 목표긴 하거든요.
그리구 copad는 Ocra 같지만 일렉트론 베이스가 아닌 터미널 베이스의 ADE가 최종 목표이신걸까요?
비슷한 목적의 앱 개발하는 한국인을 처음 보다보니 마구 질문을 쏟아내버렸는데, 모든 질문에 다 답변 안 주셔도 됩니다..!
물론 코드를 생산하는 단가가 낮아지면서 자체 제작에 대한 길이 열리긴 했으나, 개인적으로는 AI 시대가 온 것과 무관하게 외부 라이브러리를 도입하는 것을 바라보고 있습니다.
나의 요구사항을 만족하는 라이브러리가 없다
비슷한 툴을 내가 개조하는 것보다 다시 만드는 것이 저렴하다
이 두 가지가 참일 것으로 생각되는 경우에만 제가 직접 제작하곤 합니다.
다양한 이유가 있지만, 결국 아무리 작은 코드조각도 제가 관리하기 시작하면 결국 제가 검수, 테스트, 유지보수 등을 해야하는 영역에 들어오고, 단순히 코드를 작성하는 것 이상의 비용이 항상 따라온다고 생각해서입니다.
개발 과정에서도 있었던 이슈들은, window manager같은 꽤 코어한 프로그램과의 충돌이 많았어서, 만약 이것까지 전부 build from scratch한다면 외부 의존성과의 충돌로 디버깅하고 테스트하는 기간보다 훨씬 많은 시간을 구현과 검증에 들였어야 했을 것이라고 생각합니다.
추가로, 저는 개발에 들어가고부터 계속 고통스럽지만 제가 만든 툴을 사용했는데, 그것이 가능했던 이유도 어느정도 의존성들 위에서 개발을 시작해서 그런게 아닐까 싶기도 합니다.
MacOS에서 SwiftTerm을 걷어낸 사례처럼, 일단 외부 의존성을 들여와서 제가 원하는 컨셉이 동작하는지 확인하고, 제가 구현해야할 게 생기면 직접 구현을 시작하지만, 이 시점에도 외부 의존성으로 일단 제 프로그램들은 돌아가고 있으니 그 위에서 계속 안정화 및 기능 추가에 힘을 쏟을 수 있었습니다.
추가로 webkit을 들이면 대부분의 웹앱은 일반적인 브라우저를 띄웠을 때와 동일하게 동작합니다!
최근에 headless browser를 cli로 제어할 수 있는 도구랑, claude in chrome도 적극적으로 활용하고 있는데다, 터미널에까지 chromium을 얹어 메모리를 과도하게 사용하는 건 막고 싶어서, 큰 일이 없으면 터미널 내부의 웹뷰의 기술 스택은 크게 바꾸지 않을 것 같긴 합니다.
LLM 분석치곤 드럽게 비싸군요
감사합니다.
이번 주 내로 사이트 내 언어 설정 기능을 구현해 두겠습니다:)
답변 감사합니다!!
질문 또 여러개 드릴 것 같은데..
터미널 프로토콜은 이번에 개발하면서 처음 접하신걸로 읽었는데,
궁금한건 개발 전에, 러스트에 대한 지식이 어느정도 있었는지도 궁금해요.
저는 지그로 개발했는데, 사실 지그는 손으로 써본 경험이 없고,
터미널 프로토콜이나 문법, 구조도 마찬가지로 지식이 전혀 없는 상태에서 제로베이스에서 공부하자는 느낌으로 도전한 케이스거든요.
그래서 외부라이브러리 의존성을 더 회피한거이기도 했습니다.
어떻게 만들어지는지를 좀 더 질문을 통해, AI랑 함꼐 트러블 슈팅을 하는걸 자연스레 의도해서, 통제하지 못하는데 실행은 되는, 그런 경우를 막고 싶었거든요
4개월 정도 걸리셨다고 하셨는데,
저도 원격으로 집에 있는 맥을 켜놓고 개발하다보니, ssh 에서 클로드나 코덱스 CLI에서 이미지 업로드 가능하게 프로토콜을 개발하고 나서 기존에 쓰던 터미널 앱 사실상 레퍼런스용도로 가끔 키는거 빼고는 아예 안 쓰기 시작했었습니다.
개인적으로 저는 터미널 한 2주차? 3주차쯔음이였던것 같아요.
답변 주신것처럼, 바로 쓰쎴다고 하는데, 그럼 그때 바로 tmux도 탈출이 진행되신걸까요?
그리고 4개월이나 걸린건 제 생각이지만, 계속 기능 추가나 편의성을 붙이는게, 오히려 코어 기능 개발보다 더 오래 걸리지 않았을까하는데 제가 생각한게 맞을지 궁금해요.
저는 그랬는데, 다른 사람들도 비슷한 제품 개발할때 비슷한 흐름인지 개인적으로 늘 궁금한 사항이였어서.. 실례가 아니라면 답변 해주시면 감사하겠습니다(__).
또, tmux에 비해 압도적으로 편해진 시기는 언제쯤부터 이신지도 궁금해요
하나 더, 저도 사실 비슷한 주제로 터미널 개발하고 만족하고 있긴 하지만, 어쩄든 계속 꾸준히 유지보수해야지만 하는 성격의 프로그램인데,
블로그에서 쓰신것처럼 Ocra, cmux, heder 등 비슷한 목적의 툴이 쏟아져나오고 있고, 대부분 유명한 라이브러리들은 기업이든 후원이든, 기여든 속도가 어쩔 수 없이 개인에 비해 압도적으로 빠르고 그만큼 피드백 잘 받는 프로그램이다보니,
경쟁(?) 하는 입장에서 한글 ime를 제외하면 사실상 디테일 한 편의성이나 UX 개선 속도에 비해서 압도적으로 뒤쳐질 수 밖에 없다는 생각이 드는데,
유지보수는 위에서 말한 비슷한 성격의 앱들에 비해 어디까지 하면 괜찮다라고 느끼시는도 궁금합니다.
그리고 러스트로 gpu를 선택하신 만큼 윈도우까지도 어느정도 염두에 두시는걸까요??
저도 개인 프로그램 개발이긴 하지만, 생태계는 발려도(?) 언급한 앱들의 퀄리티정도는 되는게 목표긴 하거든요.
그리구 copad는 Ocra 같지만 일렉트론 베이스가 아닌 터미널 베이스의 ADE가 최종 목표이신걸까요?
비슷한 목적의 앱 개발하는 한국인을 처음 보다보니 마구 질문을 쏟아내버렸는데, 모든 질문에 다 답변 안 주셔도 됩니다..!
댓글들을 보면서 이불킥의 순간이 떠오르네요.
사실 왠만한 개발에는 슈퍼 개발자가 필요 없긴해요. 그냥 보통의 사람들이 모여서 무언가 만들어가는 과정이라 봐요.
Openweight랑 opensource를 구별하는 글은 굉장히 간만에 보는 느낌
전 반대로 그에 대한 앤드류 응의 반응이 더 인상깊었네요.
아! 따로 올릴수 있는 카테고리가 있었군요! 알려 주셔서 감사합니다!
옛날에 곰플레이어 게임이 생각나는군요..
👍 이런거 너무 좋습니다..
다른 2FA보다는 확실히 전 편하던데, 불편한 분들도 계신가 보네요. 스펙상으로 그 어떤 보안보다 안전하기도 하고요.
한국 보안 규정이 페이스ID나 지문인식 같은 개인을 정보로 하는 인증을 배제하는 방향으로 가고 있는 느낌도 있는데요, 패스키는 그런 우려도 없고요.
애플이 하니까 페이스ID가 좋구나 하지, 신생 스타트업이 한다면 애초에 얼굴을 찍는다는 자체가 거부감이 들 수도 있을 것 같고요.
애초에 사용자들이 2FA를 안쓰거나 인지를 못하기 때문에 생긴 해프닝 같아요.
예를 들어서 은행 OTP를 쓸래? 패스키를 쓸래? 하면 패스키가 압도적으로 편할 것 같아요.
안녕하세요!
좋은 경험과 생각 공유해 주셔서 감사합니다.
물론 코드를 생산하는 단가가 낮아지면서 자체 제작에 대한 길이 열리긴 했으나, 개인적으로는 AI 시대가 온 것과 무관하게 외부 라이브러리를 도입하는 것을 바라보고 있습니다.
이 두 가지가 참일 것으로 생각되는 경우에만 제가 직접 제작하곤 합니다.
다양한 이유가 있지만, 결국 아무리 작은 코드조각도 제가 관리하기 시작하면 결국 제가 검수, 테스트, 유지보수 등을 해야하는 영역에 들어오고, 단순히 코드를 작성하는 것 이상의 비용이 항상 따라온다고 생각해서입니다.
개발 과정에서도 있었던 이슈들은, window manager같은 꽤 코어한 프로그램과의 충돌이 많았어서, 만약 이것까지 전부 build from scratch한다면 외부 의존성과의 충돌로 디버깅하고 테스트하는 기간보다 훨씬 많은 시간을 구현과 검증에 들였어야 했을 것이라고 생각합니다.
추가로, 저는 개발에 들어가고부터 계속 고통스럽지만 제가 만든 툴을 사용했는데, 그것이 가능했던 이유도 어느정도 의존성들 위에서 개발을 시작해서 그런게 아닐까 싶기도 합니다.
MacOS에서 SwiftTerm을 걷어낸 사례처럼, 일단 외부 의존성을 들여와서 제가 원하는 컨셉이 동작하는지 확인하고, 제가 구현해야할 게 생기면 직접 구현을 시작하지만, 이 시점에도 외부 의존성으로 일단 제 프로그램들은 돌아가고 있으니 그 위에서 계속 안정화 및 기능 추가에 힘을 쏟을 수 있었습니다.
추가로 webkit을 들이면 대부분의 웹앱은 일반적인 브라우저를 띄웠을 때와 동일하게 동작합니다!
최근에 headless browser를 cli로 제어할 수 있는 도구랑, claude in chrome도 적극적으로 활용하고 있는데다, 터미널에까지 chromium을 얹어 메모리를 과도하게 사용하는 건 막고 싶어서, 큰 일이 없으면 터미널 내부의 웹뷰의 기술 스택은 크게 바꾸지 않을 것 같긴 합니다.
읽어주셔서 감사합니다!
저희 데모가 딱 정적 HTML 한 파일이라 잘 맞을 것 같습니다. 링크 고정이면 공유하기도 좋겠네요. 알려주셔서 감사합니다, 시연 끝나고 적용해보겠습니다. 감사합니다!
지금은 로직의 정교함보다 "입력하면 맞는 공고가 실제로 뜬다"를 보여주는 게 목적입니다. 비개발자인 내부 의사결정권자께 시연하는 자리라, 완성도보다 동작을 확인하는 쪽에 무게를 두고 있어요. 로직 고도화는 그다음 단계로 생각하고 있습니다.
지금은 마치 스마트폰 보급 당시, 모바일퍼스트 UX로 막 변화하던 때처럼 느껴집니다. 아직 체계는 덜 잡혀있지만 흥미로운 변화들이 곳곳에서 보여요.
바로 즐겨찾기 했습니다. 아마도 매일 들여다볼 것 같네요.
혹시 한국어 지원을 고려하고 계신지 여쭤보고 싶습니다 :)
과거의 나보다 지금의 내가 더 나아지고 있는지에만 집중하기
Slack 대화를 어떻게 필터링하여 지식 베이스에 포함시키는지, 그 실구현체가 궁금하네요.
블로그 글도 잘 읽었습니다.
저도 비슷한 동기로 터미널을 개발하고 있는 입장에서 궁금점이 생겼어요
개인적으로 요즘처럼 DX 환경이 빨리 바뀌고, 개발자마다 다른 시대가 있었나 싶은데,
제작자분도 느끼셨는지 모르겠지만, 이럴 때 일수록 제어권이 저한테 있는게 더 유리하다고 생각했고,
AI 시대의 DX의 근간은 무엇이냐?라고 생각했을 때 터미널 베이스라고 생각했습니다.
최근에 유행하는 터미널들 다 써보았지만, 한글 입력도 대부분의 터미널에서 부실하고, 에이전트를 쓰는데는 DX, UX가 불편했기에 저도 직접 개발하자라는 결론을 얻어서 진행하고 저도 제 터미널로 다른 사람보다 더 좋은 생산성을 확보했다고 생각하는데요.
저 같은 경우 제어권을 완전히 얻기 위해서
외부 라이브러리 의존성도 최소화 해야한다는 생각에 지그 다 자체개발을 선택했는데(부득이한 웹뷰같은 경우 제외)
블로그글이랑 코드 보니까 rust를 선택하시고, rataui 등 자체 개발보다는, 러스트에 존재하는 외부라이브러리를 선택하신 이유가 궁금합니다.
글에서도 보면 외부 라이브러리 의존성으로 인한 이슈들이 있었던것 같아서요
그리고 웹뷰가 네이티브 웹뷰인만큼 대부분의 웹환경은 사파리 환경이 아니여서 완전한 E2E 테스트는 어려울것 같은데 이 부분은 그냥 외부테스팅 도구로 넘기시는걸까요? 아니면 추후 CEF도 넣으실 계획이 있으신건지도 궁금해요.
저도 이제 터미널 어느정도 쓰면서 안정화 단계에 들어서서 기능 추가나 기획, 또는 UX 고민을 많이 하는 단계에 들어섰지만, 개발 중에는 크래쉬나 이것저것 버그가 많았을텐데,
개발 시작 후 언제쯤 실행도 외부 터미널이 아닌 자체 개발하신 터미널로 진입 할 정도로 안정화가 되었었는지도 궁금합니다.
실력 없는 사람이 항상 하는 이야기가 협업 능력이던데…
멀티플렉서 설치 링크가 잘리네요.. README의 이 항목을 확인해 주시면 멀티플렉서만 설치할 수 있습니다.