juxtapose

아무래도 네임사일로의 API 보안 모형이 끔찍하다는 것은 확실해 보인다. 어휴 진짜 생산적인 일 좀 하려고 했더니 이런 게 발목을… 빨리 탈출하자. 어디로 탈출하면 좋을까? 어떤 도메인 네임 레지스트라가 좋은 도메인 네임 레지스트라인가?

내 기억으로는 엔지니어들의 레지스트라 평판에서 한쪽 극단에 있는 것이 GoDaddy 이고 반대쪽 극단에 있는 것이 Gandi 이다. (어느 쪽이 어느 쪽이라고는 하지 않았습니다.) 아무튼 한번 최신화를 해 보자.

이런 것은 보통 나 같은 가짜 광기가 흉내낼 수 없는 훌륭한 진정한 광인들께서 조사해 주신 바가 있게 마련인데, 예를 들어 FSF 나 EFF 같은 데서 옥음을 내리신 게 없는가 기웃거려 본다. EFF 에서 Which Internet Registries Offer the Best Protection for Domain Owners? 라는 자료를 발표한 바가 있긴 하다.

근데 이건 레지스트라(registrar)가 아니라 레지스트리(registry)에 관한 이야기다. 물론 이것도 중요하고 알찬 이야기이긴 한데, 이건 새로운 도메인 네임을 등록할 때 참고할 이야기이고, 나는 이미 있는 도메인 네임을 들고 나가려는 거라서…

하지만 웃기게도 이게 도메인 네임 문제이다 보니 정보가 있는데, 바로 fsf.org 와 eff.org 라는 도메인 네임은 어디서 등록되어 있는지 (ㅋㅋㅋㅋㅋㅋㅋㅋ) WHOIS 찍어 볼 수 있다는 것이다. 아니 이럴 수가 두 군데 다 Gandi 쓰는군요!

그러자 갑자기 뇌리를 스치는 생각이 있었다. 이거 이거 왠지… 끼리끼리 놀 것 같은 그분들 도메인 네임 레지스트라 어디인지 다 찍어 보자

• fsf.org
• fsfe.org
• gnu.org
• eff.org
• sfconservancy.org
• softwarefreedom.org

이분들 다 레지스트라가 Gandi 이다. 아니. 그밖에 openwrt.org 도, mastodon.social 이나 joinmastodon.org 도…

NameSilo API 옛날부터 생각만 하다가 방금 처음 써 봤는데, 생각보다 너무 쉽고 간단해서 깜짝 놀랐다.

문제가 심각하다.

아니, 그냥 API 키 발급 누르면 즉시 나오고, 그걸로 내 계정의 모든 것을 다 할 수 있으며, 심지어 연장이나 신규 구입 등 카드 결제 일으키는 행위도 할 수 있다고. 있는 거라고는 API 키를 읽기 전용으로 하는 거랑, "Block Restorations" 뿐이다. 도메인 네임을 제때 연장 못해서 소유권 잃은 경우, 좀 더 큰 돈을 내고 소유권을 회복할 수 있는데 이걸 restoration 이라고 한다. 이건 돈이 많이 들고 환불도 어려운 행위이기 때문에, 이것만 API 키로 못하도록 설정하게 해 준다는 것이다.

그러니까 이거 말고는 권한 관리도 없고, 여러 개의 API 키 중에서 하나만 폐지(revoke)하는 기능도 없고, 모든 API 키를 폐지하는 기능도 안 보이고, 이 API 키를 최근에 사용한 IP 주소는 어디냐 같은 기록도 아무 데도 안 보이고, 하다못해 이 API 키로 행할 수 있는 결제액의 상한 같은 것도 설정할 수 없고, 아무것도 없어!

나는 나 자신을 믿지 않는다. 나는 반드시 사고를 칠 것이다. 엔지니어라면 당연히 그렇게 가정해야 한다! 더구나 이 API 키는 내 도메인 네임의 소유권을 다 상실시킬 수도 있는 물건...? 내가 뭔가 잘못 이해하고 있는 건가? 멀쩡한 관리 페이지가 따로 있는데 네임사일로가 꽁꽁 숨겨 놔서 못 찾고 있는 건가?

거의 10년 넘게 쓰던 서비스인데 진지하게 탈출 고민이 생겼다.

여러분은 서비스가 "쓰기 쉽다는 이유로" 탈출을 고려하는 장면을 보고 계십니다. 이것이 2025년이다.

장렬한 삽질 끝에 라즈베리 파이 컴퓨트 모듈 4 에다가 DFR0767 붙이고 Pi OS + nftables + dnsmasq + hostapd + unbound + Pi-hole 해서 완전한 유무선 공유기의 설정을 끝냈다…

도대체 왜 이렇게 해야 하는가? 이렇게 해서 얻는 장점이 무엇인가? unattended-upgrades 됩니다. 그밖의 장점은 나중에 시간과 여력이 있으면 글로 쓰겠습니다.

RE: https://mitir.social/notes/ad1bbm9x87

블링크: 동물이 아님
웹킷: 동물이 아님
게코: 동물임

yt-dlp 쓰려다가 403 Forbidden 떠서 이슈 트래커 가 보니 원 세상에 이런 전쟁통이 있나. 혀를 내두름 https://github.com/yt-dlp/yt-dlp/issues/3766

웃긴짤을봤다

@hongminhee洪 民憙 (Hong Minhee) 이슈로 만들지 않을 거예요

저는기 어다닐 거예요

@hongminhee洪 民憙 (Hong Minhee) 첨부된 그림과 대체 문구가 있을 경우 본문이 비어 있어도 글을 올릴 수 있게 해 주세요

@xiniha @hongminhee洪 民憙 (Hong Minhee) 학대, 괴롭힘 행위 신고·제재하는 기능 만들어주세요

@pbzweihander쯔방 @chalk초크 거덜냅시다! (초당 10억 개의 IPv6 주소를 생성하는 것을 100억 년 동안 계속하더라도 IPv6 주소 공간의 100만 분의 1도 채울 수 없음) 거덜내자!

@xtjuxtapose 해귀즈 퍼브

쉽게 제 호감도 올리시는 법: "해커즈 퍼브"

쉽게 제 호감도 조금 내리시는 법: "해커스 펍"

쉽게 제 호감도 많이 내리시는 법: "해커스펍"

〈내가 LLM과 함께 코딩하는 방식〉이라는 글을 써 봤습니다…만 이미 LLM 많이 활용하는 분들은 잘 알고 계실 내용들이긴 합니다.

@hongminhee洪 民憙 (Hong Minhee) 음… 코딩이 막힐 때는 코딩 말고 잡담을 써 보시는 건 어떨까요? 개인적으로는 LLM 도움 받는 코딩 환경을 어떻게 설정해서 쓰고 계신지, 에디터와 개발 환경 등의 연동은 어떻게 해 두고 사용 중이신지가 궁금합니다. 글로 써 주시면 감사할 듯…

yes let's review some criteria for good consumer electronics:

• follows industry standards
• normal operation does not constantly produce stinky fecal waste
• standard procedure for maintenance works (instead of "0.01% chance of violent delirium/seizure")
• parts are replaceable and interoperable
• repair does not cause bloodshed
• source code is known and mostly understandable (not interdependent instructions forming Lovecraftian spaghetti horror)

breaking all of this would result in the worst nightmare of consumer electronics

lucky we don't have to deal with anything that horrifying in the real world

이거 아무리 봐도 옛날에 본 심리검사 문항 같다. 이런 느낌으로

비슷하게 "짭"도 흥미롭다고 생각.

가짜 ← 假(거짓 가)에서 나온 것이 확실
짜가 ← 글자를 뒤집어서 더 모욕적인 멸칭
짝퉁 ← 더 모욕적인 멸칭. 아마도 미련퉁이, 눈퉁이(눈탱이) 등과 비슷한 조어 원리. *표준국어대사전에 실렸다.*
짭퉁 ← 더 변형됨
짭 ← 더 줄어듦

원래 "가짜"는 한국어에서 "그 한자를 써야 할 대상"을 표현할 때 자주 쓰이는 "-짜" 조어다. 이런 조어는 수두룩하다. (진짜, 공짜, 괴짜, 대짜, 퇴짜, 초짜, 생짜, 등등.) 음식점에서 주문할 때 "대짜, 중짜, 소짜" 하는 것도 정확히 여기 해당한다.

즉, 의미를 담고 있는 부분은 '가' 부분이다. 그런데 "짭"에서는 그 부분이 완전히 소멸해 버렸다. 그러면서도 인터넷 세대라면 누구나 "짭"이 뭔지 알아듣는 데에 아무 문제가 없다. "짤"이 원래 의미에서 완전히 이탈한 것과 비슷하다. 흥미롭죠. #사립언어원

RE: https://buttersc.one/notes/acpg9z3oec

What? I have forty followers?

Why are you following me

"삼가 고인의 명복을 빕니다"라는 관용구에서, 유독 "삼가 고인" 부분만 "삼가고인"으로 붙여서 잘못 쓰는 경우를 많이 봤다.

다 붙여 쓰는 것도 아니고 왜 "삼가고인"만 붙여 쓸까? 이해가 안 됐는데 어느 날 깨달았다. 이 사람들 "삼가"가 뭔지 몰라서, 한자어라고 생각하는 거다.

즉 마치 "임대 주택"을 "임대주택"으로 적듯이 "삼가 고인"도 "삼가고인"으로 적어도 된다고 생각하는 것이다.

안 됩니다. "삼가"는 "삼가다"의 "삼가"입니다. "삼가고인" 표기를 삼가십시오. "삼가다"는 "몸가짐이나 언행을 조심하다."라는 뜻입니다. "삼가고인"과 같이 고인을 능욕하는 표기를 삼가라. #사립언어원

@akamig

---BEGIN AWKWARD JOKE---

Welcome Akamig!!1!

At last, we have you here on the Resistance Engineers' Pubescence. This will finally let me shamelessly steal share your priceless gems of crazy delicious ahem diverse insight!

This is the ecosystem we've been waiting for. This is where the rules are not at the mercy of some billionaire I don't want to name. Despite hating him, I still have to visit that unholy den of coin scammers from time to time, because I'm still a fan of some of its contents, including your witty engineering comments. So, welcome AKAMIG A.K.A. МиГ! We hope to see you here often!

Now write post here. One post per day. At least. Otherwise someone will sneak into your workshop and rig your soldering iron be sad :(

---END AWKWARD JOKE---

@hongminhee洪 民憙 (Hong Minhee) Minhee, please come back home. You can't just abandon your child like this. We will forgive everything. The baby needs you. Little Haskell is crying and starving.

단체 메일에서 BCC로 리스트를 넣어 보내야 할걸 TO에 넣어서 보낸걸 받고서 이제 이건 사람이 실수하기 너무 쉬운 구조가 아닌걸까 싶은 생각이 들었다. 차라리 이메일 서버 혹은 서비스에서 TO나 CC 목록에 수신인이 10명 이상이 있는데도 BCC가 아예 비어있다면 메일을 보내기 전에 경고를 띄워서 실수를 시스템적으로 막아야 하지 않을까하는 생각이 들었다.

‘앞/전’과 ‘뒤/후’의 비대칭성은 한국어 학습자들에게 지옥을 선사할 것이다.

참고로 이거 다 국립국어원의 잘못이 아니라 한국어의 잘못임. 이건 표준국어대사전이 그냥 현실을 반영했을 뿐이다. 즉 이 글을 읽고 있는 당신도 0.000001% 정도 잘못이 있다.

- ‘앞일’은 미래인데(예: 앞일을 예측하다), ‘뒷일’도 미래다(예: 뒷일을 부탁하네). 맞죠?

- 마찬가지로, ‘앞길’은 미래다(예: 앞길이 창창한 젊은이). 그런데 ‘뒷길’도 미래다(예: 자식의 뒷길을 생각하면 걱정이 앞선다).

- ‘뒷날’도 미래고(예: 우리는 뒷날 또 만나게 되었다), ‘훗날’도 미래다(예: 훗날을 기약하다). 그런데 ‘앞날’도 미래다(예: 앞날이 창창하다). 희한하게 ‘전날’만 과거이다.

- 그런데 ‘앞날’은 간혹 과거를 가리킬 수도 있다(예: 일찍이 앞날의 폭군은 있었고…).

- 관형사형에 ‘뒤’나 ‘후’를 붙여서 시점을 나타낼 수 있다(예: “고친 뒤의 모습” 또는 “고친 후의 모습”). 그런데 반대로 하려면 관형사형이 아니라 명사형을 써야 한다(예: “고치기 전의 모습”). 그리고, ‘전’만 쓸 수 있다. ‘앞’은 여기서 아예 쓸 수 없다.

- ‘후일’은 미래의 아무 날이나 다 가리키며, 특정한 날을 가리킬 수 없다. 반면 ‘전일’은 직전, 즉 인접한 과거의 1일만 가리킨다.

- 그런데 또 ‘전날’은 인접한 과거의 1일을 가리킬 수도 있고, 과거의 아무 날을 가리킬 수도 있다.

- 그런데 또 ‘훗날’은 미래의 아무 날을 뜻하며, 인접한 미래의 1일을 가리킬 수 없다.

- ‘전년’과 ‘후년’은 각각 과거의 아무 해, 또는 미래의 아무 해를 가리킬 수 있다. 대, 대칭인가?!

- 하지만 특정한 해를 가리키는 경우, ‘전년’은 인접한 과거의 해를 가리킨다. 반면 ‘후년’은 ‘올해의 다음다음 해’이다.

- …뭐라고? 왜냐하면 미래의 해들은 순서대로 ‘내년’-‘후년’-‘내후년’이기 때문이다. 책상 엎어버리고 싶죠?

- 참고로 ‘내후년’은 동음이의어이다. 올해가 2025년이라면 내후년은 2027년을 가리킬 수도 있고 2028년을 가리킬 수도 있다. (이게 언어냐?)

- ‘후년’이 ‘올해의 다음다음 해’가 되는 이 원리는 오직 ‘년’에만 적용된다. 예를 들어 ‘후일’, ‘후주’, ‘후월’ 등에는 그런 의미가 없다.

- ‘후일’은 미래의 아무 날이다. 하지만 ‘후주’와 ‘후월’은 인접한 미래의 것 하나만 가리킨다.

- ‘전년’은 인접한 과거의 해이지만, 과거의 모든 해를 다 가리킬 수도 있다(예: 우리는 전년의 기록들을 검토하여 그 사람의 행적을 조사해 보기로 했다).

- 반면 ‘전일’, ‘전주’, ‘전월’은 오직 인접한 과거의 하나만 가리킬 수 있다.

- ‘전달’과 ‘훗달’도 비대칭이다.

도대체 이걸 어떻게 배워서 쓰라는 것인지. 생각해 보면 나도 실제로 이렇게 쓰고 있다는 것도 기가 찬다.

그밖에:

- ‘지난날’에는 특정한 날을 가리키는 뜻이 전혀 없다. 반면 ‘지난주’, ‘지난달’, ‘지난해’는 모두 과거의 인접한 하나만 가리킨다.

- ‘다음 날’과 ‘다음날’은 의미가 완전히 다르다. ‘다음날’은 ‘정하여지지 아니한 미래의 어떤 날’이다. 따라서 인접한 미래의 1일을 가리킬 때에는 ‘다음 날’만 쓸 수 있다. (도저히 못 외우시겠으면 그냥 ‘이튿날’로 피신하시라…)

@hongminhee洪 民憙 (Hong Minhee) Termianl

@hongminhee洪 民憙 (Hong Minhee) https://www.spacecloud.kr/

이준석 제명 청원이 52만명을 돌파했습니다. (2025년 6월 10일 23시 0분 현재 520015 명)
동의 종료까지 24일 0시간 59분 남았습니다.
https://petitions.assembly.go.kr/proceed/onGoingAll/327534C853DF2656E064B49691C1987F

이준석 제명 청원 동의 수는 현재 470018명입니다. (2025년 6월 9일 23시 7분 기준)
https://petitions.assembly.go.kr/proceed/onGoingAll/327534C853DF2656E064B49691C1987F

7월 4일까지, 이 계정은 이준석 제명 청원 동의 수를 보고하는 봇을 겸하도록 하겠습니다

1만 단위로 보고합니다 (47만 돌파하면 보고, 48만 돌파하면 보고, 등등)

팔로하시면

- 혐오를 거부하는 시민 동지들의 숫자에서 위로와 격려를 받으실 수 있습니다
- 주변을 한 명이라도 더 설득해 청원에 동참하게 하자는 리마인더를 받으실 수 있습니다

가자!

@hongminhee洪 民憙 (Hong Minhee) 으악... 안 돼요... 프로토콜에 없는 제약을 플랫폼이 걸면 해커들은 플랫폼을 탈출하려 듭니다.

"linked"를 표기에 이끌려 "링크드"로 잘못 적는 경우가 많은데, "링크트"입니다. IPA 로 [líŋkt].

무성 자음으로 끝나는 동사의 과거형 "-ed"는 /t/ 음가로 실현되기 때문입니다.

If a module defines a custom exception type and throws that exception within the module, it absolutely must export that exception type as well. I'd think this is basic, but it seems a surprising number of packages declare exception types without exporting them.

@reiver@reiver ⊼ (Charles) Your reply makes me realize that we need a new property in ActivityPub, like isNotSerious or isJoke that I can mark on posts.

By the way, in case you didn't notice, the previous sentence is not serious.

I mean you've done all the hard work for free open decentralized social networking platform right?

and you're like one inch centimeter away from branding yourself this

I'm not happy with how Mastodon abbreviates Mastodon to mstdn. For me it looks like Microsoft Technical Developer Network or something

사람들이 서비스형 LLM에게 자기 내밀한 이야기 등 모든 것을 털어놓고 있다. 이게 <del>클라우드</del> 남의 컴퓨터 에 저장된다는 인식 자체가 없는 이용자가 90% 이상이 아닐까 싶다.

예상: 이러다가 어느 업체가 유출 사고 한번 거하게 칠 것이다. 절대 노출되어서는 안 되는, 한 인간에게 회복이 불가능한 피해를 입히는 심각한 비밀이 공개되어 비극적 결말로 치닫는 경우가 반드시 발생할 것이다.

참사가 예상되지만 막을 수 없다. 가까운 이들에게 경고하고 주의를 당부하는 정도가 우리의 한계다.

이이이얏호우우우!

가자! 댓글 없는 청정 사회로!

フトスト!

@hongminhee洪 民憙 (Hong Minhee) 댓글 막는 기능은 언제 들어올까요

제가 생각하는 해커즈 퍼브 기능 우선순위

1. 글 올리면서 "댓글 안 받기" 설정 (트위터 킬러 피처, 트위터 역사상 가장 훌륭한 기능 추가라고 생각)
2. 인용 (quote) 금지 설정
3. 공유 (renote) 금지 설정

😅

악용 사례가 발견되어 긴급 패치: 실존하는 위협에 벌벌 떨어야 함
악용 사례는 발견되지 않음: 존재가 확인되지 않은 위협에 벌벌 떨어야 함

해커즈 퍼브의 favicon 이야기가 나왔을 때 잠깐 생각나는 대로 대충 낙서해 본 것이 있습니다. (말 그대로 대충 낙서입니다. 이대로 쓰자는 뜻은 아닙니다. 너무 진지하게 받아들이지는 마시고, 브레인스토밍 정도로 생각해 주시길...)

• 퍼브 간판의 일반적인 형상을 가져왔습니다.
• 마실 것을 파는 장소의 간판 같은 느낌을 유지하면서, 정확히 어떤 음료인지는 의도적으로 알 수 없게 했습니다. ("퍼브"는 맥주를 주력으로 하는 장소라는 인식이 있는 것 같습니다만, 법적·의료적·종교적 여러 가지 이유로 알코올을 음용할 수 없는 사람들이 세상에는 아주 많기 때문에, 일부러 "맥주"의 이미지를 배제했습니다. 해커즈 퍼브는 술 안/못 마시는 사람도 편하게 올 수 있는 장소가 되는 것이, 행동 강령의 취지에도 부합한다는 생각이었습니다.)
• 간판 부분은 잘 보시면 "퍼브"라는 한글 표기에서 "ㅍ"와 "ㅂ"를 담고 있습니다. 가로대와 간판이 이어지는 부분이 "ㅍ"의 형상이고, 물잔이 "ㅂ"의 형상입니다. 물론 해커즈 퍼브는 한국어 전용 커뮤니티도 아니고 한글 전용 커뮤니티는 더더욱 아닙니다. 한글이 꼭 들어가야 할 이유는 없습니다. 하지만 반대로 한글을 안 쓸 이유도 없지 않은가? 뭔가를 모티브로 쓰긴 써야 하는데 그게 한글일 수도 있는 것 아닌가? 그래서 넣어 봤습니다. 😅
• "Hacker's Pub"를 구성하는 글자들을 그대로 집어넣는 것을 일부러 피했습니다. 우선, 아이콘은 "Hackers' Pub"이라는 텍스트와 병치될 가능성이 높은데, 그렇다면 "H"나 "P"가 들어 있는 것은 중복이 되고 정보 전달의 낭비가 됩니다. 그리고, favicon 으로 쓰일 가능성이 높은데, 다른 사이트들에도 알파벳을 형상화한 아이콘이 많습니다. 추상적 형상으로서 다른 아이콘들과 겹칠 여지가 적을수록 식별자로서의 기능과 효용이 극대화될 것이라는 생각이었습니다. (물론, 엄밀히 따지면, 이 아이콘도 전체 형상에는 알파벳 "h"의 구조가 숨어 있고, 그것을 의도하긴 했습니다만, 가장 먼저 눈에 들어오는 특징은 아니죠.)

다른 분들이 여러 가지 말씀을 해 주셨습니다만 저도 첨언하자면,

"의업과 약업의 현실적 관계"도 한 가지 중대한 이유입니다. 제약회사 직원이 의사에게 굽실거리다 못해 예비군 훈련을 대신 가거나, 수술을 대신 한다는 기상천외한 뉴스 다들 한번쯤 보셨을 텐데요.

원론적으로는 의사가 약에도 빠삭해야 하지만, 현실적으로는 자기 전공분야도 너무 방대하고 약학도 너무 방대해서 그러기 어렵습니다. 마치 소프트웨어 엔지니어 중에 하드웨어 덕질까지 하는 경우는 소수이고 대부분은 그냥 맥북 사는 것과 비슷하게, 의사들의 약 지식도 한계가 있는 거죠. 어떤 약을 안 쓰는 게 무슨 이유가 있어서가 아니라 진짜로 그 약의 존재를 몰라서인 경우가 허다합니다. 그러니 약 성능 똑같아도 영업에 따라 억 단위가 왔다갔다 하고, 그러니 제약회사의 영업이 엽기뉴스의 영역으로 가는 것이죠.

이런 시장환경에서 의사들에게 약 이름과 성분 이름의 대조표를 매년 새로 외우라고 하면 망하겠죠? 그래서 어떻게든 이름만 보면 성분을 알게 하려고 발버둥치는 것입니다.

그러면 반대로 성분명과 전혀 무관한 약 이름은 어떻게 나오는지도 짐작이 되시죠? 그렇습니다. "처방전 필요없는" 약은 성분명 쿨하게 버리고 일반소비자에게 호소하는 작명을 하는 경향이 있습니다. 그리고, 처방전이 필요하더라도 동일성분의 약이 많거나 저네릭 경쟁이 벌어지는 경우에도 튀는 이름으로 차별화를 꾀하는 경향이 있죠.

RE: https://serafuku.moe/notes/a6lapo16c2

저도 두 가지 쟁점 모두 동의하는 편입니다. 그리고, 별개의 이야기입니다만, $ 를 가르칠 때에는 그냥 문법이라고 가르치는 게 학습자의 이해와 응용이 압도적으로 빠르고 좋았습니다.

"이건 여기서부터 뒤로는 다 괄호로 감싸겠다는 뜻이라고 생각하세요."

이러면 한 방에 설명이 끝나고, 필요성이나 편리성에 대해서도 알아서들 납득하는 것이죠. 연산자 우선순위나 좌결합 우결합 등은 그게 되고 나서 얘기하고요. 그러면 "아, 이게 그래서 이렇게 되는 거였군요?" 하면서, 훨씬 쉽게 이해합니다. 이걸 거꾸로 좌결합 우결합 어쩌고부터 가르치려고 하면 다들 꾸벅꾸벅 졸아요... ㅋㅋ ㅠㅠ

(결국 "모나드란 무엇인가"부터 배우면/가르치면 안 된다는 주장과 같은 맥락입니다.)

RE: https://hackers.pub/@bgl/01963c3b-98fa-7432-a62f-0d2dfc0691bf

@hongminhee洪 民憙 (Hong Minhee)

@hongminhee洪 民憙 (Hong Minhee) 저는 부족하다고 생각합니다...! ㅋㅋㅋㅋㅋ 유저들이(저는) 그냥 일반적인 Yes/No 다이얼로그는 조건반사적으로 Yes 해 버리는 실수를 많이 한다고 생각합니다... ㅋㅋ ㅠㅠ

@hongminhee洪 民憙 (Hong Minhee) 방금 신기능 확인하러 들어가 봤는데, 실제 렌더링 결과를 보니 드는 생각이 있어 의견 드립니다. 그냥 🗙 를 쓰는 것은 좀 위험하지 않을까 하는... 🗙 는 단순한 "창 닫기"의 의미로도 많이 쓰이기 때문에, 팔로어 목록도 일종의 인박스("이 사람이 당신을 팔로했습니다" 같은)로 여겨서, 각각의 상자를 대수롭지 않게 🗙 를 눌러서 없애 버리려고 하는 일이 발생하지 않을까 싶습니다.

"블언블"에 해당하는 강력한 조치이니만큼, 함부로 누를 수 없게 "빨간 버튼" 급의 경고가 있어야 하지 않나 하는 생각입니다. 이상적으로는 ellipsis 메뉴 안에 숨기고, ellipsis 눌러서 메뉴를 띄우면 적어도 "빨간 버튼"에 준하는 (즉 딱 봐도 위험해 보이는) 항목으로 등장하면 좋겠네요.

읔ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

@hongminhee洪 民憙 (Hong Minhee) 트위터 같은 경우는 내가 차단한 사용자의 페이지를 퍼머링크 등으로 굳이 찾아 들어갔을 때 경고 다이얼로그 형태의 UI 를 띄우고, 거기서 확인을 누르면 비로소 내용을 보여주는 식으로 동작하더군요. 괜찮은 해법이라고 생각했었습니다.