@[email protected] · 20 following · 16 followers
여행과 고양이를 좋아하는 오타쿠 프로그래머.
연합우주 변두리에서 Hollo 기반의 수제 원룸 인스턴스 운영중
| 블로그 | 日本語アカウント | |
|---|---|---|
📌
여행과 고양이를 좋아하는 오타쿠 프로그래머입니다. 다른 곳에서는 주로 @hellodhlyn 아이디로 활동하고 있습니다.
🔗 트위터 : https://twitter.com/hellodhlyn 🔗 깃허브 : https://github.com/hellodhlyn 🔗 블로그 : https://lynlab.co.kr/blog
금융부터 전자상거래까지 확산된 일본의 FIDO2 패스키 전략, 한국은 ‘간편 인증’에 머무른 채 방향성조차 흐릿합니다
2025년 상반기, 일본 증권 업계를 강타한 대규모 불법 로그인 및 부정 거래 사태는 단순한 해킹 사건을 넘어, 디지털 인증 체계에 대한 신뢰 자체를 뒤흔드는 사건이었습니다. 수천 건의 계좌 탈취와 수백억 엔 규모의 시장 조작 시도가 이어지자, 일본 금융청과 증권업협회는 즉각적으로 움직였고, 주요 증권사들은 FIDO2 기반의 패스키 인증 시스템을 도입하겠다고 발표했습니다.
웰스나비, 모넥스, SBI 증권, PayPay 증권 등 주요 업체들이 빠르게 패스키 로그인 방식을 적용했고, 기존의 SMS나 OTP 인증보다 몇 배 빠르면서도 피싱에 강한 패스키의 특성은 사용성과 보안성 양면에서 효과를 입증했습니다.
실제로 메르카리, 야후재팬, au ID, 도코모 등 주요 전자상거래 및 플랫폼 기업에서도 패스키 도입이 확산되면서, 로그인 속도 향상, 성공률 증가, 고객센터 문의 감소 등 긍정적인 결과를 수치로 입증하고 있습니다. 특히 대형 중고거래 사이트인 메르카리는 월등히 높은 로그인 성공률, 4배 가까운 속도 감소 등을 보였습니다.
이는 정책, 업계, 기술이 유기적으로 맞물려 이루어진 결과라고 볼 수 있습니다. 일본 금융청은 패스키를 “피싱 저항 인증의 기본”으로 명시하며 업계 전반에 도입을 권고했고, FIDO Alliance Japan Working Group은 기술 보급과 사례 공유를 통해 확산을 이끌었습니다.
반면 한국의 상황은 정반대입니다. 소비자 대상 FIDO2 패스키 도입을 완료한 금융기관은 현재까지 단 한 곳도 없습니다.
신한은행이나 우리은행 등 일부 은행에서 FIDO 기반 생체 인증을 도입한 사례는 존재하지만, 이는 FIDO2 패스키 방식과는 다르며, 주로 내부 인증이나 보조 로그인 수단으로 제한적으로 활용되고 있습니다. 고객용 인터넷 뱅킹이나 모바일 앱에서 비밀번호 없이 완전히 로그인할 수 있는 구조는 아직 갖춰지지 않았습니다.
IT 업계에서도 사정은 비슷합니다. 카카오, 네이버, SK텔레콤, KT 등 일부 대기업에서 패스키를 도입하긴 했지만, 적용 범위는 제한적이며, 사용자 기반 확산도 매우 미미한 수준입니다. 생태계 차원의 연동성이나 범용 인증 체계 구축도 이뤄지지 않고 있습니다.
이미 일본에서 효과를 본 패스키입니다만, 한국에서 이를 실행에 옮기려는 업계의 움직임은 매우 소극적입니다. 한국은 보안 사고에 대한 대응 속도는 빠른 편이지만, 인증 기술을 선제적으로 고도화하려는 전략적인 의지나 비전은 부족한 상황입니다. 공인인증서가 폐지된 이후에도 여전히 휴대폰 본인확인, 공동인증서, 일회용 비밀번호(OTP) 등 기존의 불편한 방식을 그대로 유지하고 있습니다.
정부나 금융당국 차원에서도 FIDO2 패스키를 채택하도록 유도하거나, 업계 협업을 통해 표준을 만들려는 노력이 거의 없습니다. ‘간편 인증’이 곧 사용자 경험 개선이라고 착각하는 단편적인 인식이 시장 전체를 가로막고 있는 현실입니다.
결국 일본과 한국의 차이는 인증에 대한 관점의 차이에서 비롯된다고 볼 수 있습니다. 일본은 패스키를 단순한 편의 기능이 아니라, 신뢰 가능한 보안 인프라의 핵심 기술로 보고 전방위적으로 투자하고 있습니다. 반면 한국은 여전히 ‘편한 인증 수단’ 정도로만 이해하고 있으며, 보안에 미치는 영향에 대해서는 소극적인 태도를 보이고 있습니다.
패스키는 단순한 로그인 도구가 아니라, 사용자 식별과 신뢰 기반을 재정립하는 차세대 인증 기술입니다. 일본은 이를 과감히 수용했지만, 한국은 기술이 있음에도 불구하고 실행력과 추진 의지가 부족한 상황입니다.
지금도 많은 금융기관은 ‘비밀번호 + OTP’ 혹은 ‘비밀번호 + 인증서’ 방식에 의존하고 있습니다. 하지만 점점 더 교묘해지는 피싱과 계정 탈취 수법을 고려할 때, 더 이상 구식 인증 방식에 의존할 수는 없습니다.
“패스워드 없는 세상”은 기술의 문제가 아니라 의지의 문제입니다. 일본은 보안 사고를 계기로 신속하게 움직였고, 지금은 눈에 보이는 성과를 만들어내고 있습니다. 한국은 언제까지 사용자에게 불편을 강요하면서, 보안을 지키고 있다고 착각하는 구조에 머무를 것인지 되묻고 싶습니다.
이제는 질문을 던져야 할 시점입니다.
“한국의 디지털 보안은 앞으로 10년 동안도 여전히 비밀번호에 기대야 할까요?”
웬만한 AI 툴들은 적응했는데 Warp 같은 터미널 계열은 도저히 적응이 안돼서 그냥 iTerm으로 돌아왔다. 터미널은 여러 명령어를 연쇄적으로 입력해야하는데 AI 기능을 쓰면 명령어 하나에 몇 초씩 잡아먹으니까 답답해서 잘 안쓰게 되는듯
오늘 간만에 코드 작업 했는데 20개 파일 고치면서 이 테스트는 깨지겠군 했던거만 정확히 깨져서 기분이 좋다
Go 1.25 출시
------------------------------
!Overview
Go 1.25 버전이 정식으로 출시되었습니다. 이번 버전은 툴, 런타임, 컴파일러, 표준 라이브러리 전반에 걸친 개선 사항을 포함하며, 특히 사용자가 미리 체험하고 피드백을 제공할 수 있는 중요한 실험적 기능들을 선보입니다.
…
------------------------------
https://news.hada.io/topic?id=22493&utm_source=googlechat&utm_medium=bot&utm_campaign=1834
맥에 애플 페이 카드 등록 안해놔도 아이폰에 등록된 카드로 Face ID 한 번에 결제할 수 있구나. 애플이 요즘 욕 많이 먹어도 진짜 이런 자잘한 디테일은 이길 수가 없네
난 어릴 때 내가 앞/뒤를 구분 못하는게 내 인지능력 문제인줄 알았는데 그냥 한국어가 이상한 거였음
‘앞/전’과 ‘뒤/후’의 비대칭성은 한국어 학습자들에게 지옥을 선사할 것이다.
참고로 이거 다 국립국어원의 잘못이 아니라 한국어의 잘못임. 이건 표준국어대사전이 그냥 현실을 반영했을 뿐이다. 즉 이 글을 읽고 있는 당신도 0.000001% 정도 잘못이 있다.
- ‘앞일’은 미래인데(예: 앞일을 예측하다), ‘뒷일’도 미래다(예: 뒷일을 부탁하네). 맞죠?
- 마찬가지로, ‘앞길’은 미래다(예: 앞길이 창창한 젊은이). 그런데 ‘뒷길’도 미래다(예: 자식의 뒷길을 생각하면 걱정이 앞선다).
- ‘뒷날’도 미래고(예: 우리는 뒷날 또 만나게 되었다), ‘훗날’도 미래다(예: 훗날을 기약하다). 그런데 ‘앞날’도 미래다(예: 앞날이 창창하다). 희한하게 ‘전날’만 과거이다.
- 그런데 ‘앞날’은 간혹 과거를 가리킬 수도 있다(예: 일찍이 앞날의 폭군은 있었고…).
- 관형사형에 ‘뒤’나 ‘후’를 붙여서 시점을 나타낼 수 있다(예: “고친 뒤의 모습” 또는 “고친 후의 모습”). 그런데 반대로 하려면 관형사형이 아니라 명사형을 써야 한다(예: “고치기 전의 모습”). 그리고, ‘전’만 쓸 수 있다. ‘앞’은 여기서 아예 쓸 수 없다.
- ‘후일’은 미래의 아무 날이나 다 가리키며, 특정한 날을 가리킬 수 없다. 반면 ‘전일’은 직전, 즉 인접한 과거의 1일만 가리킨다.
- 그런데 또 ‘전날’은 인접한 과거의 1일을 가리킬 수도 있고, 과거의 아무 날을 가리킬 수도 있다.
- 그런데 또 ‘훗날’은 미래의 아무 날을 뜻하며, 인접한 미래의 1일을 가리킬 수 없다.
- ‘전년’과 ‘후년’은 각각 과거의 아무 해, 또는 미래의 아무 해를 가리킬 수 있다. 대, 대칭인가?!
- 하지만 특정한 해를 가리키는 경우, ‘전년’은 인접한 과거의 해를 가리킨다. 반면 ‘후년’은 ‘올해의 다음다음 해’이다.
- …뭐라고? 왜냐하면 미래의 해들은 순서대로 ‘내년’-‘후년’-‘내후년’이기 때문이다. 책상 엎어버리고 싶죠?
- 참고로 ‘내후년’은 동음이의어이다. 올해가 2025년이라면 내후년은 2027년을 가리킬 수도 있고 2028년을 가리킬 수도 있다. (이게 언어냐?)
- ‘후년’이 ‘올해의 다음다음 해’가 되는 이 원리는 오직 ‘년’에만 적용된다. 예를 들어 ‘후일’, ‘후주’, ‘후월’ 등에는 그런 의미가 없다.
- ‘후일’은 미래의 아무 날이다. 하지만 ‘후주’와 ‘후월’은 인접한 미래의 것 하나만 가리킨다.
- ‘전년’은 인접한 과거의 해이지만, 과거의 모든 해를 다 가리킬 수도 있다(예: 우리는 전년의 기록들을 검토하여 그 사람의 행적을 조사해 보기로 했다).
- 반면 ‘전일’, ‘전주’, ‘전월’은 오직 인접한 과거의 하나만 가리킬 수 있다.
- ‘전달’과 ‘훗달’도 비대칭이다.
도대체 이걸 어떻게 배워서 쓰라는 것인지. 생각해 보면 나도 실제로 이렇게 쓰고 있다는 것도 기가 찬다.
그밖에:
- ‘지난날’에는 특정한 날을 가리키는 뜻이 전혀 없다. 반면 ‘지난주’, ‘지난달’, ‘지난해’는 모두 과거의 인접한 하나만 가리킨다.
- ‘다음 날’과 ‘다음날’은 의미가 완전히 다르다. ‘다음날’은 ‘정하여지지 아니한 미래의 어떤 날’이다. 따라서 인접한 미래의 1일을 가리킬 때에는 ‘다음 날’만 쓸 수 있다. (도저히 못 외우시겠으면 그냥 ‘이튿날’로 피신하시라…)
@[email protected] · Reply to 월간집사 ☄️'s post
이 생각이 들게 만들었던 내 대화 문장 쓸 때는 몰랐는데 나중에 보니까 "우리"라는 표현을 두 번이나 썼다
시간이 지날 수록 Cursor랑 대화할 때 사용하는 주어가 바뀌는게 재밌네.
안녕하세요.
저는 한국에 사는 취미 프로그래머이고, Haskell로 코딩하는 것을 즐깁니다.
우연히 Matrix Haskell에 올리신 글(https://storytotell.org/smalltalk-haskell-and-lisp)을 읽게 되었는데, NRAO라는 곳에서 일하고 계시다는 것을 알게 되었습니다.
이름만 들어도 NRAO는 정말 흥미로운 곳처럼 들립니다! 혹시 그곳에서 Haskell 기반 프로그램을 사용하고 계신가요?
감사합니다!
좋은 하루 되세요.
박준규 드림.
준규님께.
편지를 받게 되어 정말 기쁩니다! Haskell을 사용하는 취미 프로그래머라는 말씀을 듣고 무척 반가웠습니다. 혹시 현재 진행 중인 프로젝트나 공유해주실 수 있는 코드가 있으신가요? Haskell 공부는 어느 정도까지 하셨나요? H-99 문제는 풀어보셨는지요? 또는 Advent of Code, Project Euler 같은 문제 풀이도 해보셨나요? 공부하시는 데 필요한 자료나 지원은 충분하신지도 궁금합니다.
제 블로그를 읽어주셔서 진심으로 감사드립니다. 요즘은 Haskell을 많이 다루고 있진 않지만, Haskell은 제 프로그래밍 이해에 깊은 영향을 주었습니다. 저는 지금도 Haskell에서 얻은 아이디어를 자주 활용하고 있고, 업무에서 프로젝트 프로토타입을 만들 때 사용하기도 했습니다. 다만, 아쉽게도 현재 제가 맡은 업무 프로젝트 중에는 Haskell로 작성된 것은 없습니다.
하지만 NRAO에는 Haskell을 사용한 이력이 조금 있습니다. 지금도 Green Bank Observatory에서 사용되고 있는 프로젝트가 하나 있는데, 망원경 스케줄링 프로그램인 “antioch”입니다. 소스 코드는 다음에서 보실 수 있습니다.
https://github.com/nrao/antioch
보시다시피 한동안 유지 관리가 되지 않고 있습니다. 코드를 읽어보시면 두 가지를 금방 눈치채실 겁니다. 1) 전체가 “Bird 스타일”로 작성되어 있어서 코드가 설명 사이에 주석처럼 들어가 있다는 점, 2) 작성자들이 Haskell에 대해 그렇게 깊은 이해를 갖고 있진 않았다는 점입니다. :) 제가 이 프로그램을 좀 더 현대적으로 바꿔보려고 시도한 브랜치가 어딘가에 있긴 한데, 내부에만 있는 것인지 저도 잘 모르겠습니다.
물론, 우리가 Haskell 기반 프로그램을 사용하면서도 크게 의식하지 않는 경우도 있습니다. 예를 들어 Pandoc은 아마 이미 알고 계실 텐데, 그런 도구 중 하나입니다. 개인적으로는 “reldiagram”이라는 프로그램을 가끔 사용하는데요.
https://github.com/fusiongyro/reldiagram
이 프로그램은 PostgreSQL 데이터베이스를 읽어서 테이블 간의 관계를 도식화해줍니다. 제가 만든 Haskell 저장소는 이 외에도 몇 개 더 있지만, 가족과 함께하는 삶의 시기라 취미에 많은 시간을 쓰지 못해 대부분 좀 오래된 것들입니다. 언젠가는 여유가 생기면 더 많은 결과물을 만들 수 있으리라 생각합니다.
가끔은 Haskell이 아닌 다른 기이한(?) 것들도 시도하곤 했습니다. 예를 들어 Subversion에서 Git으로 대규모 마이그레이션을 할 때는 Prolog로 변환을 돕는 프로그램을 작성하기도 했습니다! 아마 지금 다 기억나지 않는 것도 있을 거예요.
NRAO는 정말 훌륭한 직장입니다. 제가 처음 입사했을 때는 모든 것이 C++와 Java로 되어 있었어요. 지금은 대부분 Python으로 작업하지만, Go도 있고 Julia나 Rust를 쓰기 시작한 동료들도 있습니다. 점점 더 새로운 기술을 시도하려는 분위기로 바뀌고 있지요.(아마 J 언어는 당분간 안 쓰겠지만요! 😊)
제 블로그를 보시면 아시겠지만 저는 그냥 프로그래머일 뿐입니다. 하지만 NRAO에는 과학자, 실제 천문학자들도 많이 있습니다. 그중 한 명인 Emmanuel Momjian 박사는 최근 한국에 다녀왔는데, 한국의 아름다움과 음식에 대해 끊임없이 이야기하더군요. 저도 언젠가는 꼭 한국을 방문하고 싶습니다! 혹시 미국 뉴멕시코에 오실 일이 있다면 꼭 연락 주세요. 만나서 VLA(초거대 전파 망원경) 현장 투어도 안내해드릴 수 있습니다!
늘 좋은 일 가득하시길 바랍니다.
진심을 담아.
다니엘 님께.
정성스럽고 친절한 답변 진심으로 감사드립니다.
제가 공유드릴 수 있는 프로젝트들을 몇 가지 소개해드리겠습니다.
먼저, 제가 유지 관리자로 등록된 Hackage 패키지입니다.
align-equal은 Gabriela 님의 블로그 글에 소개된 프로그램을 바탕으로 연습 삼아 만든 프로젝트입니다. webfinger-client는 원래 다른 분이 시작했다가 중단한 프로젝트를 최근에 제가 이어받은 것입니다. 두 프로젝트 모두 처음부터 제가 시작한 것은 아니라 조금 부끄럽기도 합니다.
저는 몇 년째 꾸준히 Haskell을 공부해왔지만, 아직 monad transformer를 능숙하게 다루지는 못합니다. H-99나 Project Euler 같은 문제들을 훑어보긴 했지만 실제로 풀지는 못했습니다. Advent of Code는 매년 1~2일 차 문제 정도는 시도해보지만 완주한 적은 없습니다. 또한 Exercism에 올라온 Haskell 문제도 몇 가지 풀어보았습니다.
https://exercism.org/profiles/nattybear
그리고 다음은 제가 Protohackers에서 푼 0~2번 문제입니다.
대체로 저는 Haskell로 출판된 책들을 읽는 것을 즐깁니다.
소개해주신 antioch 프로젝트도 흥미로웠습니다. 꽤 오래된 프로젝트이긴 하지만요. 저도 Pandoc을 자주 사용합니다. 별건 아니지만 Hakyll을 이용해 정적 블로그도 운영하고 있습니다.
reldiagram 프로젝트도 흥미롭네요. 저도 Graphviz를 좋아해서 반갑게 느껴집니다. 개인적인 프로젝트에 Prolog를 사용해본 적은 없지만, 《Logic Programming with Prolog》라는 책을 재미있게 읽고 예제도 따라 해 본 기억이 있습니다.
사실 저는 한 번도 미국 본토에 가본 적이 없습니다.(괌은 여행으로 간 적이 있습니다.) 앞으로 방문할 기회가 생길지는 모르겠지만, 언젠가 기회가 된다면 영화에서만 보던 그 거대한 전파망원경을 꼭 보고 싶습니다.
저도 요즘은 가족과 함께 보내는 시간이 많아 취미에 많은 시간을 쓰지는 못하고 있습니다. 언젠가 조금 더 여유로워지면, Haskell 생태계에 좀 더 활발히 기여할 수 있으면 좋겠습니다.
제 간단한 질문에 정성껏 길게 답변해주셔서 다시 한 번 감사드립니다.
혹시 이 대화를 트위터나 한국 디스코드 서버 ‘하스켈 학교’ 같은 소셜 미디어에 공유해도 괜찮을까요?
다시 한 번 감사드리며, 언제나 건강하시기를 바랍니다.
진심을 담아.
박준규 드림.
준규 님께.
유지 관리하고 계신 프로젝트들을 공유해주셔서 감사합니다. 저는 WebFinger라는 것을 이번에 처음 들었는데요, 아마도 Fediverse에 대해 잘 몰라서 그럴 것 같습니다. 반면에 준규 님께서는 이쪽에 대해 어느 정도 알고 계신 것 같네요.
절대 부끄러워하지 마시고, Haskell 세계에 무언가를 돌려주고 계시다는 점에 자부심을 느끼셔야 합니다! 제 아내가 자주 하는 말이 있는데요, “비교는 기쁨의 도둑”이라는 말이 있어요. :)
저도 Exercism을 한 번 확인해봐야겠네요. 아직 사용해본 적이 없고, Protohackers는 아예 처음 듣습니다. Advent of Code는 저도 보통 이틀쯤 하면 포기하게 됩니다. 문제 난이도가 금방 아주 높아지죠. 연말 휴일에 하루에 몇 시간씩 쓰고 싶진 않으니까요. 그래도 가끔은 연중에 돌아가서 한두 문제씩 풀어보곤 합니다. 어떤 분께서 언어를 배우기에 좋은 방법이라고 추천해주셔서, 저도 요즘 J를 공부하면서 따라 해보려고 하고 있습니다.
블로그도 공유해주셔서 감사합니다. Google Translate의 도움을 받아서 즐겁게 읽었습니다! 준규 님께서 스스로 시간을 내어 Haskell과 Lisp, 그리고 수학적 증명에 대해 공부해오신 점은 정말 자랑스러우신 일이라고 생각합니다. 저도 꾸준히 블로그를 구독할 수 있도록 좋은 RSS 리더를 찾아봐야겠네요. Lisp에 대해서도 흥미를 느끼고 계신 걸 보았는데, 저도 약간은 다뤄보았지만 Haskell만큼 깊이 있게 하지는 못했고, 공개 저장소에 올린 코드도 없는 것 같습니다. 개인적으로는 Lisp과 Haskell 사이에 깊고 아름다운 대칭성이 있다고 생각합니다. Haskell의 게으름(laziness)을 잘 활용하면, Lisp의 매크로와 비슷한 효과를 얻을 수 있다고도 생각하고요.
혹시 아직 안 읽어보셨다면, Typeclassopedia를 꼭 읽어보시길 추천드립니다.
https://wiki.haskell.org/Typeclassopedia
이 문서는 제가 Haskell을 이해하는 데 정말 많은 도움을 주었습니다. 물론 아직도 comonad는 잘 이해하지 못했지만요! 한국어 번역본이 있다면, Haskell을 공부하는 다른 친구분들께도 아주 유용할 것 같습니다.
또한 아직 접해보지 않으셨다면 “free monad”에 대해서도 알아보시는 걸 추천드립니다. 제가 이해한 바로는, free monad는 절차적인(action-based) 방식으로 작성된 동작들을 구조화된 데이터로 만들기 쉽게 해주고, 그 구조를 함수형으로 다룰 수 있게 해주는 개념입니다. 즉, 절차적으로 보이는 문제를 함수형으로 전환할 수 있는 다리 역할을 해준다고 할 수 있습니다. 저 자신이 직접 써본 적은 없지만, 매우 강력한 아이디어라고 생각합니다.
그리고, 제가 드린 편지는 어떤 방식으로든 자유롭게 공유하셔도 괜찮습니다! 혹시 Haskell 관련해서 흥미로운 문제를 만나게 된다면 언제든지 제게 질문해 주세요. 저도 그걸 핑계로 다시 Haskell을 손에 잡을 수 있을지도 모르니까요. :)
다시 한 번 감사드리며.
@[email protected] · Reply to 월간집사 ☄️'s post
클라우드후레아는 매번 포스트모템이 투명한건 좋은데 일단 장애 자체가 줄었으면 좋겠어... 믿고 쓰기엔 큼직한 이슈가 너무 잦음
어제 아침에 집 인터넷이 안되길래 통신사 문젠가? 그렇다기엔 tailscale + exit node 지정한 상태에서는 잘 되는데? 했는데 클라우드플레어 DNS 문제였군 DNS도 이중화 해놔야겠다
https://blog.cloudflare.com/cloudflare-1-1-1-1-incident-on-july-14-2025/
그동안 사이드 프로젝트 홈페이지로 유입이 많았던 검색어의 SEO를 신경썼더니 포지션이 첫 번째로 올라가고 인입량도 급증했다. 며칠 전까지 평균 위치 4.0 정도에다가 더 위에 있는게 대형 커뮤니티라서 묻히는 감이 있었는데, 위로 올라가자마자 트래픽이 유의미하게 증가하네.
간만에, 진짜 몇 개월만에 일찍 퇴근했더니 집에서 뭘 하면서 쉬어야할지 모르겠다... (일찍이라고 해도 9시 쯤이지만) 멍하니 유튜브 보다가 트위터 보다가 하면서 시간만 태우는중
@[email protected] · Reply to 월간집사 ☄️'s post
tooot이 정말 마음에 들었고 한국어 번역 기여까지도 했었는데 개발이 중단된게 안타깝다 😢
Phanpy만한 사용성을 가진 프론트를 못찾겠다 DAWN도 많이 발전하긴 했는데 리포스트 안묶어 보여주는게 좀 치명적임
일 년의 절반이 지났다는 사람이 속출하겠군 이라는 말을 한게 엊그제 같은데, 진짜 일 년의 절반이 지나버렸다
[단독] 카드번호·현관 비밀번호 줄줄…파파존스 무슨 일
https://mnews.sbs.co.kr/news/endPage.do?newsId=N1008152918&plink=ORI&cooper=NAVER&plink=ORI&cooper=NAVER
자신의 이름과 전화번호, 배달 주소가 적혀 있었는데, 9자리 숫자로 이뤄진 주문번호를 임의로 바꿔 입력했더니 다른 사람의 주문 정보가 고스란히 나왔습니다.
취재진이 제보자와 함께 직접 확인해 본 결과, 주문자가 결제한 카드번호와 유효 기간, 심지어 공동 현관 비밀번호까지 마음만 먹으면 알 수 있는 상태였습니다.
...이거 예전에 KT 놈들 짓이랑 비슷하네 ㅋ
오늘도 특별 대우 받는 한국의 네트워크 비용
요즘 Kindle Unlimited로 전자책을 읽고 있다. 시리즈 서적은 대부분 1권이 무료로 풀려있는데, 나는 이후 시리즈를 구매할지 말지 판단하기 좋고 아마존은 전환율이 올라가서 좋고 공급자와 소비자 모두에게 괜찮은 방식 같다.
개인 프로젝트의 모니터링 도구로 New Relic을 쓰고 있는데 점점 사용성이 나빠진다 Datadog APM이 무료 플랜이 있다면 참 좋았을텐데
개인 인스턴스로 돌아온 트잉여!
@[email protected] · Reply to sapphire's post
@sapphire 어서오세요 ㅋㅋ
Cloudflare는 Pages 쓰랬다가 Workers 쓰랬다가 장기적인 로드맵이 확실하지가 않네 기껏 Pages로 다 옮겨놨더니 이젠 다시 Workers로 돌아오란다 ㅠ
https://developers.cloudflare.com/workers/static-assets/migration-guides/migrate-from-pages/
루비온레일즈에서는 CoC라는 게 있습니다.
Convention over Configuration.
그러니까 설정보다 컨벤션을 더 중시하게 본다는 겁니다.
설정 파일에다가 이것저것 적는 것이 아니라 그저 관행대로 하면 알아서 동작하는 거.
예를 들어서 라우트에 articles란 이름의 경로를 만들면, 이 경로는 articles_controller.rb 와 자동으로 매핑이 됩니다.
그리고 articles_controller의 index 액션은 views/articles/index.html.erb 을 자동으로 찾아서 렌더링 합니다.
이를 위한 어떤 설정도 필요 없습니다. 그저 관행일 뿐입니다.
DB 의 테이블 이름과 모델 클래스의 이름이 항상 동일하다는 것도 CoC의 한 예입니다.
처음엔 이런 관행이 짜증 나기도 했습니다.
왜 모든 테이블 이름이 복수형이어야만 하지?
Person 모델이 있으면 당연히 테이블 이름도 person이어야 직관적이지 않나? 왜 people이라는 복수형을 강제하는 거지?
이런 생각으로 반항하며 대들 때마다 레일즈는 고통을 돌려주었습니다.
초반에는 Rails와 많이 다투면서 이런 고집스러운 녀석과는 같이 못 살겠다 생각을 했었습니다만...
그 장점을 받아들이고 나서 드디어 친하게 지낼 수 있게 되었습니다.
오히려 제약하고 강제하면서 코딩이 만사 편해질 수 있구나 하는 걸 배웠습니다.
그런데 이게 꼭 코딩 시에만 적용되는 것은 아니었습니다.
사내 문화에 이런 걸 적용한 회사도 있었습니다.
카카오에 처음 들어갔을 때 영어 닉네임을 정해야만 했습니다.
그 영어 닉네임은 사람들에게 불리는 내 호칭이기도 했지만, 내 이메일 주소가 되기도 했습니다. 사내 github 주소가 되었고 사내 게시판의 닉네임이 되었습니다.
동료의 메일 주소를 물어볼 필요가 없었습니다. 부르는 이름이 메일 주소니까.
저는 Windows 컴퓨터를 사용해왔지만 얄짤없었습니다. 모든 사람들에게 맥북이 지급되었습니다.
사람들의 자유를 너무 제약하고 강제하는 것 아닌가?
돌아보니 이런 문화들이 마치 레일즈의 CoC처럼 느껴집니다.
회사 문화를 처음 만든 사람들이 레일즈를 워낙 좋아해서 영향을 받은 거 아닌가 하는 의심마저 들었습니다.(웃음)
엄격하게 강제하지만 구성원들이 잘 따르기만 하면 모두가 편해지는 관례.
이런 것이 좋을 때도 있다는 사실을 이제는 받아들입니다.
@[email protected] · Reply to Perlmint's post
@perlmint 컨텐츠를 UI 설정 언어와 자동으로 맞춰서 보여주는 서비스들은 기술적으로는 신경써서 구현한 것 같은데 막상 실사용할 때는 불편하더라구요 ㅋㅋ 특히 저는 게임은 한국어로 하는데, 켜자마자 영어로 뜨는데 언어 설정창이 튜토리얼이 끝나야 뜨는 경우가 많았던...
에어팟 노캔 켜면 이상한 바람 소리가 나서 뭐가 문제인가 했더니 이어팁이 찢어졌네ㅠ
📌
여행과 고양이를 좋아하는 오타쿠 프로그래머입니다. 다른 곳에서는 주로 @hellodhlyn 아이디로 활동하고 있습니다.
🔗 트위터 : https://twitter.com/hellodhlyn 🔗 깃허브 : https://github.com/hellodhlyn 🔗 블로그 : https://lynlab.co.kr/blog
으악 옆집 해커스 펍이 흥하니까 우리 집 Hollo S3 저장량이...!
또 슬슬 SNS 계정 파편화가 일어나고 있는데 날 잡고 병합해야겠다