jeonhada | | parent | on: Ask GN: 구글 크롬 확장 프로그램 개인적으로 만들어서 쓰고 계신것 있으신가요?

https://github.com/sjeon87/code-radio-ext

laeyoung | | parent | on: 이해가 새로운 병목이다 (geoffreylitt.com)

AI Engineer 유튜브 채널에 저자가 한 같은 내용을 발표 영상이 올라왔네요 - https://www.youtube.com/watch?v=WkBPX-oDMnA

whaletail | | parent | on: 모니터링 직접 만들지 말고 무료 SaaS에 맡겨라 — Sentry + PostHog로 0원 관측 (whale-tail.tistory.com)

답이 늦었네요, 이제 봤습니다! 제일 좋았던 건 도입이었어요
Expo라 네이티브 붙는 Firebase Analytics와 달리 순수 JS SDK라 재빌드
없이 바로 붙었고, autocapture로 초기에 이벤트를 일일이 안 심어도 돼서
1인 개발엔 부담이 적었습니다. 무료 한도 안에서 시간대별 패턴·퍼널
보기에 충분했고요.

eajrezz | | parent | on: Passkey는 소비자 심리를 전혀 이해하지 못한 엔지니어들이 만들었다 (twitter.com/nikitabier)

심지어 크롬 브라우저 자체도 passkey 자체가 햇갈리게 하는데 기여를 하는 것 같아요. 제 passkey는 1password 에있는데 자꾸 하드웨어 USB를 연결하라고 하거나 해요.

lamanus | | parent | on: Passkey는 소비자 심리를 전혀 이해하지 못한 엔지니어들이 만들었다 (twitter.com/nikitabier)

저도 같은 방식으로 사용중입니다. OS 또는 브라우저 종속되는 패스워드 매니저와 패스키는 정말로 기기 종속적이라서 사용할 수가 없겠더라고요.

julskim | | parent | on: Passkey는 소비자 심리를 전혀 이해하지 못한 엔지니어들이 만들었다 (twitter.com/nikitabier)

맞습니다. 그래서 패스키는 메인으로 쓰면 곤란하고, 정말 강력하지만 불편한 인증 수단과 결합해야 가치가 빛난다고 봅니다.

julskim | | parent | on: Passkey는 소비자 심리를 전혀 이해하지 못한 엔지니어들이 만들었다 (twitter.com/nikitabier)

글을 읽어보니 이해는 되는데 제목만 보면 미친놈이 하는 소리같았습니다. 저를 포함해 패스키 쓰는 사람은 굉장히 잘 쓰고 있거든요. Nikita Bier는 아마 패스키 이름 지정을 잘못하거나, 사용하는 서비스의 UX가 좋지않아서 그랬을거라는 판단이 듭니다.
사용자가 이해하지 못하는 인증 방식이라고 했는데, 사실 인증이라고하면 사용자가 편리하고 보안 좋으면 끝입니다. 꼭 이해를 해야할까요?

저는 이 문제는 Google이나 다른 서비스 플랫폼이 패스키를 제공하는 방식이 틀려서 느껴지는 문제라고 생각합니다. 지문이든 뭐든 사용자에게 '패스키를 어떻게 인증할 것인가'에 대한 UX를 개선해야지, 그걸 도입한 엔지니어 잘못이 아닙니다. 이름 자체가 이상하기도하구요( '온디바이스키'라고 했다면 더 직관적이었을까요?). 어쨌든 방식 자체는 보안이 좋은 인증 방식이라고 봅니다.
"패스키=생체 인증"처럼 이해하면 더 어렵습니다. 따지고보면 저도 PIN의 원리를 알기 전에는 '6자리 숫자가 뭐가 안전하다는거지?'라는 생각을 했으나 실제 키는 다른 복잡한 키이고 PIN은 그 기기내 키를 열기위한 기기 비밀번호라고 생각하니 보안이 좋구나라는 것이 이해가 되더라구요. 일반 사용자가 이걸 이해하고 쓸까요? 그걸 제안하는 OS엔지니어의 말을 믿고 쓰는거죠(Windows Hello PIN과 같은 것들).

장치 분실에 대한 경우도 그렇습니다. 2FA는 여러 기기에 설치할 수 있고 패스키는 기기를 잃으면 열쇠를 잃는데 그게 단점이다? 이 말은 '구식 집 열쇠보다 원격 도어락이 보안이 더 좋다'라는 말과 똑같습니다. 어디서든 인증이 가능한 수단과 소유 기기에서만 인증 가능한 수단을 비교하다뇨. 낭설입니다. 물론 서로 장단점이 있겠지만은, 그런식으로 비교하면 '2FA보다 비밀번호가 더 낫다'도 말이 되는거라고 봅니다. '내 기기에서만 로그인 가능하다'라는 말은 보안세계에서는 '다른 사람이 내 기기를 얻어야지만 인증이 가능하다'라는 말과 같습니다. 패스키의 장점은 거기에 있다고 봅니다. 생체인증과 같은 것은 기기에서 제공하는 키체인 인증수단에 불과합니다. 패스키의 본질을 다시 올바로 이해해야한다고 생각합니다.

sukwn5 | | parent | on: Passkey는 소비자 심리를 전혀 이해하지 못한 엔지니어들이 만들었다 (twitter.com/nikitabier)

1Password를 4년째 사용 중인데, 오히려 Passkey가 대세라 편함.
iPhone 및 Apple 생태계, 회사 컴퓨터 등에 모두 설치하고 기본 패스워드 매니저를 비활성화하면 오직 1Password로만 사용할 수 있음.
Passkey를 발급받으면 클릭 한번으로 저장되고, 사이트에서 Passkey API를 호출하면 우측 상단에 Passkey로 로그인을 물어보는 창이 나옴.
이때 Enter 한번이면, 패스워드 입력 및 Captcha 인증을 건너뛰며 로그인에 성공함.

laeyoung | | parent | on: 45권의 기술 서적에서 얻은 핵심 인사이트 (youtube.com)
  1. 목차에 있는 링크가 재귀적으로 이 페이지로 돌아옵니다.
  2. 모든 내용을 손으로 요약해 주신건지, AI로 요약한 걸 옮겨 주신 건지 모르겠지만, 유튜브에 Ask 기능이 있어서 모든 내용을 다 요약해주지 않으셔도 문제 없을 듯 합니다. 오히려 이걸 공유해 주신 이유가 제일 궁금했고, 내용은 3줄 요약으로도 충분할거 같습니다.
howudoin | | parent | on: Passkey는 소비자 심리를 전혀 이해하지 못한 엔지니어들이 만들었다 (twitter.com/nikitabier)

"passkey는 좋다. 대안 없는 비판을 하지마라!!"라고,
근데 정작 passkey가 기존 방식에 대한 대안의 위치이고, 제대로 된 대안을 제시하고 있지 못하면서 좋다고 우기는 중

null468 | | parent | on: Passkey는 소비자 심리를 전혀 이해하지 못한 엔지니어들이 만들었다 (twitter.com/nikitabier)

패스키를 편하게 쓰려면, 모든 플랫폼을 관통하는 단 하나의 패스워드 관리앱을 써야함....
그게 아니면, 내가 어디서 어떻게 패스키를 생성했는지도 모르고, 브라우저가 패스키 요청을 엉뚱한 주체에 묻고있는걸 인지하기도 힘듬. 그러다 보니 자주 쓰는 몇개 플랫폼 외에는 불편해서 패스키 안씀.
지금보니 패스워드 관리 앱 팔아먹으려고 만드는 기능같음.

baeba | | parent | on: 45권의 기술 서적에서 얻은 핵심 인사이트 (youtube.com)

사이트 주소는 아래와 같습니다.
https://bookoverflow.io/

shincad | | parent | on: Show GN: 집 근처 도서관들의 책 대출 가능 여부를 한 번에 검색하는 서비스를 만들었어요 (bookmarking.kr)

// 검색 API 상태 확인 테스트
async function testSearchAPI() {
const url = 'https://bookmarking.kr/api/search/…';

console.log('API 요청 시작:', url);

try {
const startTime = performance.now();
const response = await fetch(url);
const endTime = performance.now();

console.log(`응답 시간: ${(endTime - startTime).toFixed(0)}ms`);  
console.log(`HTTP 상태 코드: ${response.status} (${response.statusText})`);  

if (response.ok) {  
  const data = await response.json();  
  console.log('API 정상 작동중! 응답 데이터:', data);  
} else {  
  console.warn(`서버 에러 발생 (상태 코드: ${response.status})`);  
  const errorText = await response.text();  
  console.log('서버 에러 응답 내용:', errorText || '(응답 본문 없음)');  
}

} catch (err) {
console.error('네트워크 연결 불가 또는 CORS 에러:', err);
}
}

// 실행
testSearchAPI();

F12 콘솔에서 해 봤더니, 여전히 503 error이네요. 아마 백엔드 서비스가 다운되어 있는 상태인 것 같습니다.

xguru | | parent | on: Passkey는 소비자 심리를 전혀 이해하지 못한 엔지니어들이 만들었다 (twitter.com/nikitabier)

음, X의 프로덕트 헤드 Nikita Bier는 원래 말을 좀 세게 하기로 유명합니다. Elon Musk와 비슷한 듯하면서도 결은 좀 다르고요.

새로 오픈한 BeeBS는 Passkey를 지원합니다. 저는 편하다고 생각하는 편이에요.

다만 Passkey만으로 가입하고 동기화나 다른 복구 수단이 없다면, 기기를 잃어버렸을 때 계정에 접근하지 못할 수 있습니다. 그래서 BeeBS는 먼저 이메일 매직링크로 가입한 뒤 Passkey를 등록하도록 했습니다.

이 두 가지를 조합하면 사용자 비밀번호를 서버에 전혀 저장하지 않아도 되고, 기기를 바꾸거나 잃어버리더라도 이메일로 다시 로그인해 새로운 Passkey를 등록할 수 있습니다.

ggggnews | | parent | on: OmniRoute — 흩어진 무료/저가 AI 티어를 하나로 묶는 게이트웨이 (github.com/diegosouzapw)

이런거 무료 잘못쓰면 모두의 코드가 되버리긴하는데 간단한거 짤땐 유용할듯

sinbumu | | parent | on: OmniRoute — 흩어진 무료/저가 AI 티어를 하나로 묶는 게이트웨이 (github.com/diegosouzapw)

쌀먹 최적화 오픈소스 ㅗㅜㅑ

seob717 | | parent | on: Show GN: CLAUDE.md 규칙을 훅으로 "컴파일"하는 Claude Code 플러그인 (github.com/seob717)

넵 말씀하신대로 스킬이랑 겹치는 부분도 있는데요! 스킬이 트리거되지 않는 케이스도 있고, 명시적으로 강제시키기 위해 사용합니다!

추가적으로 제 플러그인은 claude.md에 있는 규칙을 읽고 룰 파일로 만들어줍니다. 그래서 트리거 시점에 어긋날 케이스도 없고 /nunchi:report 로 로그도 확인 가능합니다

그리고 claude.md에 import 시켰던 문서들을 초기 로드 하지 않으니 시작 토큰도 줄어듭니다 😊

baeba | | parent | on: Show GN: 집 근처 도서관들의 책 대출 가능 여부를 한 번에 검색하는 서비스를 만들었어요 (bookmarking.kr)

메인 화면에서..
하단 의견보내기를 선택하고..
back 버튼 누르면... 뒤로 가지가 않습니다. Firefox 사용하고 있어요.

baeba | | parent | on: Show GN: 집 근처 도서관들의 책 대출 가능 여부를 한 번에 검색하는 서비스를 만들었어요 (bookmarking.kr)

가입없이 검색하기에서

도서 데이터 제공처 요청이 일시적으로 몰렸어요. 잠시 후 다시 시도해주세요.

란 메시지가 뜹니다.....

가입을 해야 하나요?