전 반대로 그에 대한 앤드류 응의 반응이 더 인상깊었네요.

"이건 전혀 같은 경우가 아닙니다. 누구나 자신의 코드를 비공개로 둘 권리가 있습니다. 문제는 다른 사람이 코드를 오픈소스로 공개하려는 것까지 막으려 할 때입니다." (https://x.com/AndrewYNg/status/2081103828859117908)

아! 따로 올릴수 있는 카테고리가 있었군요! 알려 주셔서 감사합니다!

옛날에 곰플레이어 게임이 생각나는군요..

👍 이런거 너무 좋습니다..

다른 2FA보다는 확실히 전 편하던데, 불편한 분들도 계신가 보네요. 스펙상으로 그 어떤 보안보다 안전하기도 하고요.

한국 보안 규정이 페이스ID나 지문인식 같은 개인을 정보로 하는 인증을 배제하는 방향으로 가고 있는 느낌도 있는데요, 패스키는 그런 우려도 없고요.

애플이 하니까 페이스ID가 좋구나 하지, 신생 스타트업이 한다면 애초에 얼굴을 찍는다는 자체가 거부감이 들 수도 있을 것 같고요.

애초에 사용자들이 2FA를 안쓰거나 인지를 못하기 때문에 생긴 해프닝 같아요.

예를 들어서 은행 OTP를 쓸래? 패스키를 쓸래? 하면 패스키가 압도적으로 편할 것 같아요.

안녕하세요!
좋은 경험과 생각 공유해 주셔서 감사합니다.

물론 코드를 생산하는 단가가 낮아지면서 자체 제작에 대한 길이 열리긴 했으나, 개인적으로는 AI 시대가 온 것과 무관하게 외부 라이브러리를 도입하는 것을 바라보고 있습니다.

  1. 나의 요구사항을 만족하는 라이브러리가 없다
  2. 비슷한 툴을 내가 개조하는 것보다 다시 만드는 것이 저렴하다

이 두 가지가 참일 것으로 생각되는 경우에만 제가 직접 제작하곤 합니다.
다양한 이유가 있지만, 결국 아무리 작은 코드조각도 제가 관리하기 시작하면 결국 제가 검수, 테스트, 유지보수 등을 해야하는 영역에 들어오고, 단순히 코드를 작성하는 것 이상의 비용이 항상 따라온다고 생각해서입니다.
개발 과정에서도 있었던 이슈들은, window manager같은 꽤 코어한 프로그램과의 충돌이 많았어서, 만약 이것까지 전부 build from scratch한다면 외부 의존성과의 충돌로 디버깅하고 테스트하는 기간보다 훨씬 많은 시간을 구현과 검증에 들였어야 했을 것이라고 생각합니다.

추가로, 저는 개발에 들어가고부터 계속 고통스럽지만 제가 만든 툴을 사용했는데, 그것이 가능했던 이유도 어느정도 의존성들 위에서 개발을 시작해서 그런게 아닐까 싶기도 합니다.
MacOS에서 SwiftTerm을 걷어낸 사례처럼, 일단 외부 의존성을 들여와서 제가 원하는 컨셉이 동작하는지 확인하고, 제가 구현해야할 게 생기면 직접 구현을 시작하지만, 이 시점에도 외부 의존성으로 일단 제 프로그램들은 돌아가고 있으니 그 위에서 계속 안정화 및 기능 추가에 힘을 쏟을 수 있었습니다.

추가로 webkit을 들이면 대부분의 웹앱은 일반적인 브라우저를 띄웠을 때와 동일하게 동작합니다!
최근에 headless browser를 cli로 제어할 수 있는 도구랑, claude in chrome도 적극적으로 활용하고 있는데다, 터미널에까지 chromium을 얹어 메모리를 과도하게 사용하는 건 막고 싶어서, 큰 일이 없으면 터미널 내부의 웹뷰의 기술 스택은 크게 바꾸지 않을 것 같긴 합니다.

읽어주셔서 감사합니다!

저희 데모가 딱 정적 HTML 한 파일이라 잘 맞을 것 같습니다. 링크 고정이면 공유하기도 좋겠네요. 알려주셔서 감사합니다, 시연 끝나고 적용해보겠습니다. 감사합니다!

지금은 로직의 정교함보다 "입력하면 맞는 공고가 실제로 뜬다"를 보여주는 게 목적입니다. 비개발자인 내부 의사결정권자께 시연하는 자리라, 완성도보다 동작을 확인하는 쪽에 무게를 두고 있어요. 로직 고도화는 그다음 단계로 생각하고 있습니다.

지금은 마치 스마트폰 보급 당시, 모바일퍼스트 UX로 막 변화하던 때처럼 느껴집니다. 아직 체계는 덜 잡혀있지만 흥미로운 변화들이 곳곳에서 보여요.

바로 즐겨찾기 했습니다. 아마도 매일 들여다볼 것 같네요.
혹시 한국어 지원을 고려하고 계신지 여쭤보고 싶습니다 :)

wayden | | parent | on: 재능이라는 허상 (gwagjiug.com)

과거의 나보다 지금의 내가 더 나아지고 있는지에만 집중하기

Slack 대화를 어떻게 필터링하여 지식 베이스에 포함시키는지, 그 실구현체가 궁금하네요.

블로그 글도 잘 읽었습니다.
저도 비슷한 동기로 터미널을 개발하고 있는 입장에서 궁금점이 생겼어요

개인적으로 요즘처럼 DX 환경이 빨리 바뀌고, 개발자마다 다른 시대가 있었나 싶은데,
제작자분도 느끼셨는지 모르겠지만, 이럴 때 일수록 제어권이 저한테 있는게 더 유리하다고 생각했고,
AI 시대의 DX의 근간은 무엇이냐?라고 생각했을 때 터미널 베이스라고 생각했습니다.

최근에 유행하는 터미널들 다 써보았지만, 한글 입력도 대부분의 터미널에서 부실하고, 에이전트를 쓰는데는 DX, UX가 불편했기에 저도 직접 개발하자라는 결론을 얻어서 진행하고 저도 제 터미널로 다른 사람보다 더 좋은 생산성을 확보했다고 생각하는데요.

저 같은 경우 제어권을 완전히 얻기 위해서
외부 라이브러리 의존성도 최소화 해야한다는 생각에 지그 다 자체개발을 선택했는데(부득이한 웹뷰같은 경우 제외)

블로그글이랑 코드 보니까 rust를 선택하시고, rataui 등 자체 개발보다는, 러스트에 존재하는 외부라이브러리를 선택하신 이유가 궁금합니다.
글에서도 보면 외부 라이브러리 의존성으로 인한 이슈들이 있었던것 같아서요

그리고 웹뷰가 네이티브 웹뷰인만큼 대부분의 웹환경은 사파리 환경이 아니여서 완전한 E2E 테스트는 어려울것 같은데 이 부분은 그냥 외부테스팅 도구로 넘기시는걸까요? 아니면 추후 CEF도 넣으실 계획이 있으신건지도 궁금해요.

저도 이제 터미널 어느정도 쓰면서 안정화 단계에 들어서서 기능 추가나 기획, 또는 UX 고민을 많이 하는 단계에 들어섰지만, 개발 중에는 크래쉬나 이것저것 버그가 많았을텐데,

개발 시작 후 언제쯤 실행도 외부 터미널이 아닌 자체 개발하신 터미널로 진입 할 정도로 안정화가 되었었는지도 궁금합니다.

실력 없는 사람이 항상 하는 이야기가 협업 능력이던데…

멀티플렉서 설치 링크가 잘리네요.. README의 이 항목을 확인해 주시면 멀티플렉서만 설치할 수 있습니다.

맞아요. 면접까지가면 그런 부분을 이전 채용 단계보다는 더 크게 보는 것 같아요.
거기까지 가기는 힘들겠지만 ㅎㅎ
면접까지 갈 정도만 된다면 코딩 실력보다는 이 글의 요지대로 그 이외의 필요 능력을 기르고, 어필하는 것이 좋은 것 같습니다.

데모에서 보여주고 싶은게 매칭 로직의 뛰어남인가요? 아니면 이런게 있다 인가요?

예전에 renphy로 게임을 만들어서 배포를 할려고 했었는데
깃허브블로그라고 정적 사이트를 깃허브에서 1개인가? 무료로 호스팅을 해줍니다.
(사이트링크는 아마 고정일거에요.)
그거 사용하면 정적사이트는 쉽게 배포는 가능한거로 알고는 있습니다.

sinbumu | | parent | on: 재능이라는 허상 (gwagjiug.com)

사실 개발자 채용도 실제로 나중에 뽑는 입장이 되면, 철저하게 이성과 논리만으로 도는게 아니고 인성이나 느낌도 많이 따진단걸 알게되죠 ㅋㅋ. 의외로 특별한 분야의 천재를 모셔와야 되는게 아니면 '얘랑 같이 일할때 불필요한 스트레스 안받고 협업이 잘 될까?' 이게 제일 중대사항이다 보니

네 그 언급은 없습니다.
중국의 오픈웨이트에 찬성이 아니라는 것은 제 생각입니다.
다만 오픈웨이트를 찬성한다 가 아니라
미국이 오픈웨이트에서도 승리하길 바란다 입니다