아참, 그래서 차를 타는 게 너무 고역이고 그 시간동안은 듣는 것 외에 아무것도 할 수 없어서 괴로웠는데 애플에게 진지하게 처음으로 감사함을 느꼈어요.

음? 광고 회사니까 광고 차단기를 앲애는게 합리적이라는 느낌인데, 양키들 감성은 다른가봅니다

이거 꽤 최근에 우연히 접근성 메뉴 뒤지다가 발견했는데요, 효과가 있습니다. 생각외로 도움이 되어서 당황했어요.
참고로 저는 웬만한 대중교통(지하철 포함)에서 멀미를 하고, 컨디션이 안 좋으면 엘리베이터에서도 멀미를 하는 수준이에요.
휴대폰을 보면서 버스를 타는 것에 무리가 없었습니다. 완전히 없애주진 않지만 견딜 정도까지 낮춰줍니다.
별개로 멀미를 없애주는 주파수(진짜)를 이용하는 것도 도움이 된다고는 하던데 그건 잘 모르겠어요.

DDR3+i5 내장그래픽PC에서 qwen3.6 27b를 초당 1토큰으로 돌리고 있습니다.
옛날엔 이런식으로 기다려도 엉망인 결과물만 나왔지만, 이젠 그래도 쓸수있는게 나오더라고요.
6개월 전 80~120B급 크기가 필요했던 성능이 30B급이면 충분한 정도로 발전했고 1년쯤 뒤면 opus4.8, gpt5.5급 코드 성능도 30B에서 보게되지 않을까 싶습니다.
그러면 이렇게 하루동안 5~7만 토큰씩 짜내는 로컬모델도 충분히 서브로 선택할만한 옵션이 될거라 믿어요

맥북에서도 되는걸 보고 놀랐던 기억이 있네요.
노트북에 가속도 센서는 왜 넣어놓은건데... ㅋㅋㅋㅋㅋㅋㅋ

이런 기능이 있는 줄 몰랐네요ㄷㄷ..
바로 적용해 봐야 겠네용

shj5508 | | parent | on: JWT 사용을 중단하라 (gist.github.com/samsch)
  1. JWT는 토큰 암호화 및 DB 질의를 줄이는 방식이지, 쿠키 인증과 대척점에 있는 개념이 아닙니다. JWT를 secure 쿠키에 저장하면 탈취 위험이 레거시 쿠키 인증 방식과 같습니다

  2. JWT expired 를 시키려고 만료 목록을 관리하는게 성능 측면에서 이점이 있습니다. 만료 정보만 redis에서 질의하는 것과 전 회원을 DB 질의 하는것의 비용차이가 존재합니다.

수만번의 횟수로 10만 회원 row의 index 기반 질의 (레거시 쿠키 방식)
vs
수만번의 횟수로 redis에서 만료 목록 50개 질의 (JWT 즉시 expire 방식)

JWT의 이점이 있긴 합니다. 소규모 환경에서 차이가 덜 날 뿐입니다

네네 학습 자체를 목소리로 한건 아니어서, 모든 Sound to Sound가 가능할 것 같아요. 그래도 포켓몬 소리로 테스트해본 적은 없긴합니다ㅎㅎ

toss ux writing도 문서화 되면 좋겠네요

최근에 오랜만에 텍스트로만 이루어진 메일을 받았어요.
제 깃허브 레포를 언급하는 마케팅 메일이긴 했는데, 사람이 작성한 흔적이 보여서 간단한 회신이라도 해볼까 싶네요 ㅎㅎ

뭔가 당연한거같기도한데 생각지못했던 부분이라 적용하면 많이 개선될거같아서 기대되네요

로컬 모델을 제대로 사용하려면 그만한 하드웨어가 뒷바침되어야 하는데, 하드웨어도 너무 비싸서 보안 같은 특별한 이유가 없다면 아직은 구독이나 API 호출이 가성비가 더 높은것 같아요

안녕하세요. 관심 감사합니다.
제가 Codex을 많이 써본게 아니라, 아는 선에서 답변드리겠습니다. 틀릴 수도 있습니다.

일단 Mweft는 작업 결과물을 공유하는게 아닙니다.
중간 중간 AI와의 대화로 나온 내용을 공유합니다. 작업 결과물은 GIT과 같은 다른 툴을 사용해야합니다. 결과가 아닌 중간 내용을 공유하는 것이기에 작업흐름을 쫓을 수 있습니다.
그리고 graph + rag를 사용해서 이 기능을 보조합니다.
Mweft는 Claude, Codex, Gemini CLI간 작업 공유도 가능합니다.

감사합니다.

claude에게 이렇게 요청할 수도 있는 거군요 ㅎㅎ (p50, p99의 정의도 같이 확인했습니다) 답변 감사드립니다!

저는 claude 에 p50 10ms, p99 15ms 맞춰달라고 합니다 ㅎㅎ

신기하네용 혹시 입력으로 목소리 말고 약간 포켓몬? R2D2? 같은 소리도 가능할까요?

웹 개발은 조금의 경험도 없다 보니 ㅎㅎ 알려주신 내용 기반으로 또 찾아보도록 하겠습니다 답변 정말 감사드립니다! 🙇🏻

엇 정말 별거 없습니다. 조금 경험 있는 웹 개발자분들은 다 아실 만한 내용이에요 ㅠ

핵심은 “매번 서버와 DB까지 깊게 가지 않게 한다”입니다.

  • CDN과 nginx 마이크로 캐시를 활용해서 공개 페이지 응답 자체를 짧게 캐시합니다.
  • 자주 반복되는 조회는 쿼리 캐시나 HTML 렌더링 캐시로 DB와 렌더링 부담을 줄입니다.
  • 오래된 글처럼 자주 바뀌지 않는 페이지는 파일 캐시도 활용합니다.
  • 로그인 여부나 추천/댓글 액션처럼 사용자별로 달라지는 부분은 서버 HTML에 섞지 않고, 하이드레이션으로 나중에 붙입니다.

그래서 대부분의 공개 페이지는 아주 짧은 시간이라도 캐시된 응답을 공유하고, 꼭 필요한 개인화 데이터만 별도로 가져오는 구조입니다.
특별한 기술이라기보다는, 여러 캐시 레이어를 겹쳐서 원점 서버가 할 일을 줄인 쪽에 가깝습니다.

어마어마 하네요..

답변해 주신 내용에 대해 공개적으로 포스팅 해주실 의향은 없으신지요? (궁금합니다 ㅎㅎ)