Profile img

bgl gwyng

@bgl@hackers.pub · 99 following · 124 followers

GitHub
@bglgwyng

아 그리고, 진짜로 토큰 소비를 줄이고 LLM이 일하는데 도움이 되는지는 아직 모릅니다. 실험을 해봐야아는것이니 피드백 환영합니다.

2
4
1

레포 파놨더니 모르는 사람들이 스타를 찍기 시작해서. 급하게 WIP라고 써놨다. 빨리 완성하자...

2

LLM 코딩의 부정적인 영향으로 우려하는 부분이 있는데, 점점 현실이 되어가는거 같다. 사람들이 코드를 안 읽고 너무 많이 짠다.

사실 오랫동안 많은곳에서 쓰이는 좋은 프로그램들은, 그 많은 코드를 짜서 어떻게든 동작시키게 만들었다는 것 이전에, 그냥 '뭘 만들지'에 대한 접근부터 훌륭한 경우가 많다(많은 UNIX 기본 프로그램들을 생각해보라). 옛날에는, 내가 어떤 기능 A가 필요할때, 내가 그 기능 A를 짜는게 힘든 일이니까 그 기능 A를 제공하는 프로그램을 먼저 찾게되고, 그러면 그 프로그램은 나의 근시안적인 접근보다 나은 더 좋은 개념을 갖고 있는 경우가 많았다. 그러면 나는 이제 그 개념을 익히며 내 자신을 업데이트하면 되는 것이다.

근데 자기 자신을 업데이트하는건 피곤한 일이라서, 사람들은 그걸 피할수 있는 기회를 놓치지 않는다. 그래서 현재 자기 수준에 맞는 평범한 프로그램을 만드는 길을(단돈 0.1$) 기꺼이 선택해버린다.

7
2
8
0
0

저는 유별난 Markdown 스타일을 고집하는데요, 그래서 어떠한 린트나 포매터도 제 요구 사항을 충족시키지 못해서 Markdown 문서에 한해서는 린트/포매터 없이 손으로 고치며 살고 있었습니다만… 오늘 갑자기 삘 받아서 바이브 코딩으로 markdownlint 커스텀 룰들을 구현했습니다. 아마도 이걸 필요로 하는 분들은 없겠지만…

https://github.com/dahlia/markdownlint-rules

5

LLM을 위한 cat, lat을 만들어볼까 생각이 들었다. 어떤 파일을 열던지 간에, 토큰 아끼고 LLM이 쉽게 읽도록 적당히 알아서 바꿔서 보여주는 것이다. 그리고 CLAUDE.md 같은거에 cat 대신에 쓰라고 하는거지.

처음엔 JSON 파일을 minify해서 토큰 아끼는 정도를 생각했는데, 막상 클로드한테 물어보니 자기도 들여쓰기가 있어야 읽기 편하다고 한다. 응? 그래서 쓸모있는 접근을 물어봤더니, 코드를 읽을때 앞에 함수 시그니쳐/클래스 정의 등의 요약을 달아주면 좋겠다고 한다.

쓸모있게 만드려면 좀더 고민해야할듯..

2
2

클로드 코드 쓰고있으니 더 나은 VCS에 대한 욕심이 커진다. 나는 클로드가 브랜치를 더 자주 쪼개서, 원하는 시점으로의 롤백이 더 편해졌으면 좋겠다.

하나 생각나는 아이디어는 브랜치 명을 hierachial하게 만들어서 가령 fix-bug-1/refactor-class-foo/fix-function-bar 이런식으로, 무슨 일하는지의 맥락을 브랜치명에 나타내는 것이다. 그리고 a/b 브랜치는 a 브랜치의 자식이어야 한다는 제약도 강제한다.

...는 git은 a란 브랜치가 이미 있으면a/b, a/c 같은 브랜치를 못만든다. 이유는 바로... git 브랜치가 이름 디렉토리로 관리되기 때문이다. 뭐 이런;;

1
4
0
1
1
1
2

프로그래밍 언어 문법을 만들때, 비교 연산자에 <, <=, >, >= 등이 있는데, 어차피 좌우 순서만 바꾸면 되니까, >, >= 같은걸 그냥 압수하고 <, <=만 쓰게 한다음에 >, >= 요건 다른 용도로 쓰면 어떨까하는 생각이 듬.

4

GLM-4.7의 성능이 그렇게나 좋다고 들어서 요금제를 보니 상당히 파격적인 가격이라 조금 시도해 봤다. 우선 LogTape에 있던 이슈 하나를 수행하게 했고, 혹시 몰라서 Claude Code에서 Claude 4.5 Opus로 PLAN.md 계획 파일을 꽤 꼼꼼하게 만들게 한 뒤, 그걸 참고하게 했다. 그럼에도 불구하고:

  • 모든 export되는 API에 대해서는 JSDoc 주석을 써야 한다는 당연한 절차를 수행하지 않음 (코드베이스의 다른 코드는 다 그렇게 되어 있는데도 눈치가 없음)
  • JSDoc 주석을 쓰랬더니 Python docstring 스타일로 정의부 “안쪽”에 주석을 씀…
  • Deno.env 같은 특정 런타임에 의존적인 API를 씀 (코드베이스의 다른 코드는 그런 API 안 쓰고 있음)
  • 아주 기본적인 JavaScript 구문 오류를 냄 (예를 들면 세미콜론 빼먹는 식의) → 이것 때문에 상당히 토큰 소모를 많이 함
  • 한국어가 살짝 귀여움 (“나옵니다”가 아니라 “나옴니다”라고 쓰는 식)
  • 결국에는 JavaScript 구문 오류를 못 고쳐서 테스트 스위트도 아예 못 돌리는데 전체 작업이 완료되었다고 스스로 결론 내림

소문난 잔치에 먹을 게 없다더니, 역시나 벤치마크만 보고 모델을 골라서는 안 되겠다는 교훈만 재확인 한 것 같다.

오늘은 OpenCode에서 공짜로 제공하길래 MiniMax M2.1로 코딩을 좀 해봤다. 몇 시간 정도 해본 느낌으로는 GLM-4.7보다는 훨씬 나았고, 체감상으로는 대충 Claude Sonnet 4와 비슷한 정도로 말귀를 잘 알아듣는 느낌이었다. 컨텍스트 윈도가 긴 것도 장점이었다. 다만, 컨텍스트가 좀 길어지니까 끝도 없이 삽질을 반복하게 되어서, 그 쯤에서 모델을 GPT-5.1 Codex Max로 바꿔서 진행했다. GPT-5.1 Codex Max로 삽질 구간 벗어난 뒤에 금방 다시 MiniMax M2.1로 돌아와서 계속 코딩을 했고, 전반적으로 싼 값을 감안하면 굉장히 좋다고 느꼈다.

요즘에는 평소에 Claude Opus 4.5를 주력으로 사용하니까, 아무래도 비교가 될 수밖에 없었는데:

  • 역시나 눈치라고 해야 하나, 센스는 떨어진다. Claude Sonnet 4.5보다도 떨어지는 듯. 이를테면 Markdown 문서를 수정하도록 지시하면 기존의 일관성 있게 잘 짜여 있던 문서 서식이 금방 무너지는 게 느껴진다.
  • AGENTS.md의 세세한 지시를 좀 뭉개는 느낌이 있다. 예를 들면 TypeScript 코딩할 때 any 타입을 쓰지 말라고 했음에도 무시하고 사용한다든가. Claude 계열 모델들에서는 이런 건 잘 못 겪는다.
  • 작업의 맥락보다 이미 학습되어 있는 자신의 지식을 더 따르는 느낌이 있다. 이를테면 일부러 여러 JavaScript 런타임에서 두루 돌아가게 하려고 Deno API를 안 쓰고 Node.js API를 써서 짜 둔 코드베이스에서 갑자기 Deno API를 꺼내서 쓰기 시작하는 식이다. 이것도 눈치 문제로 볼 수도 있을 듯.
  • 그렇게 중요하진 않지만 자연어 응답에 언어가 조금 섞인다. 특히 국한문혼용체가 종종 나온다. 나로서는 오히려 좋다(?). 그런데 자세히 보면 대륙에서 쓰는 간화자가 아니라서, 중국어가 섞이는 건 아닌 것 같다. 아마도 일본어 아니면 대만/홍콩의 중국어가 섞이는 것 같다. 아니면 정말로 국한문혼용체일지도? 그리고 아랍어도 한 번 섞이는 걸 봤다.
  • 속도는 그냥저냥 쓸만하지만 딱히 빠른 것도 아닌데, 이건 OpenCode에서 공짜로 제공하는 걸 써서 그럴 수도 있다. Claude Opus 4.5보다는 약간 느리다고 느꼈지만, 이것도 그냥 체감이라 정확하진 않다. 삽질하는 걸 더 많이 봐서 느리다고 착각한 걸 수도 있고.

일단은 OpenCode에서 공짜로 제공하는 동안은 좀 더 써 볼 생각이다. 돈 내고 쓸 생각이 있냐 하면, 그건 좀 고민이 된다. 코딩 요금제를 보면 5시간에 300 프롬프트짜리가 월 20불 정도 된다. 지금은 Claude Max 요금제를 쓰고 있는데, 아무래도 부담이 좀 되긴 해서, Claude Pro로 내리고 MiniMax를 섞어서 쓰면 어떨까 생각만 해보고 있다.

6

bgl gwyng shared the below article:

Hackers' Pub 신고(flag) 기능 기획서

洪 民憙 (Hong Minhee) @hongminhee@hackers.pub

개요

목적

신고 기능은 Hackers' Pub 커뮤니티의 행동 강령(code of conduct)을 위반하는 콘텐츠나 사용자를 식별하고, 관리자가 적절한 조치를 취할 수 있도록 돕는 시스템입니다.

핵심 철학

신고 기능의 궁극적인 목적은 계도와 성장입니다. 무균실처럼 완벽한 사용자만을 남기려는 것이 아니라, 신고를 통해 각자의 행동을 돌아보고 더 나은 커뮤니티 구성원으로 성장할 수 있는 기회를 제공하는 데 있습니다.

추방은 최후의 수단이며, 시스템은 다음과 같은 단계적 접근을 권장합니다:

  1. 인지 — 피신고자가 자신의 행동이 문제가 될 수 있음을 알게 됩니다
  2. 성찰 — 왜 그 행동이 문제인지 이해할 기회를 갖습니다
  3. 개선 — 행동을 수정하고 커뮤니티와 조화롭게 참여합니다
  4. 제재 — 개선 의지가 없거나 심각한 위반의 경우에만 적용됩니다

분산형 네트워크 고려

Hackers' Pub은 ActivityPub 프로토콜 기반의 분산형 소셜 네트워크입니다. 따라서 신고 기능도 다음을 고려하여 설계되었습니다:

  • 다른 서버(인스턴스)에 호스팅된 콘텐츠도 신고 가능
  • Mastodon 등 주요 ActivityPub 플랫폼과의 호환성
  • 연합(federation) 환경에서의 조치 전파

설계 원칙

신고자 보호

원칙
신고자의 신원은 철저히 비공개로 유지됩니다.
근거
신고자가 보복을 두려워하면 신고를 주저하게 되고, 이는 커뮤니티 건강성을 해칠 수 있습니다. 익명성이 보장되어야 신고 시스템이 효과적으로 작동합니다.
구현
  • 피신고자에게는 신고 사실과 사유만 전달되며, 신고자 정보는 공개되지 않습니다
  • 관리자만 신고자 정보에 접근할 수 있습니다
  • 데이터베이스 수준에서도 접근 제어가 적용됩니다

피신고자의 알 권리

원칙
피신고자는 자신이 왜 신고되었는지 알 권리가 있습니다.
근거
무엇이 문제인지 알지 못하면 개선할 수 없습니다. 계도라는 목적을 달성하려면 피신고자가 자신의 행동을 돌아볼 수 있는 충분한 정보를 제공해야 합니다.
구현
  • 신고 사유(행동 강령 위반 내용)가 피신고자에게 전달됩니다
  • 어떤 콘텐츠가 문제가 되었는지 명시됩니다
  • 단, 신고자가 누구인지는 알 수 없습니다

행동 강령의 유연한 참조

원칙
행동 강령은 살아있는 문서이며, 시간이 지남에 따라 발전하고 변화할 수 있습니다.
근거
커뮤니티가 성장하고 사회적 맥락이 변화함에 따라 행동 강령도 함께 진화해야 합니다. 신고 시스템은 이러한 변화에 유연하게 대응할 수 있어야 합니다.
구현
  • 신고 사유를 특정 조항 번호에 하드코딩하지 않습니다
  • 신고 시점의 행동 강령 버전을 기록하여 맥락을 보존합니다
  • LLM 매칭 시 현재 행동 강령 전문을 참조하여 동적으로 분석합니다
  • 신고자가 작성한 원본 사유는 항상 보존됩니다

투명한 처리 과정

원칙
신고의 처리 과정과 결과는 관련 당사자에게 투명하게 공유됩니다.
근거
신고자는 자신의 신고가 어떻게 처리되었는지 알 권리가 있으며, 피신고자도 어떤 조치가 취해졌는지 알아야 합니다.
구현
  • 신고자에게 처리 진행 상황과 최종 결과가 통보됩니다
  • 피신고자에게 조치 내용과 사유가 전달됩니다
  • 관리자의 판단 근거가 기록됩니다

단계적 제재

원칙
제재는 위반의 심각성과 빈도에 비례하여 단계적으로 적용됩니다.
근거
경미한 위반에 과도한 제재를 가하면 커뮤니티 참여를 위축시키고, 심각한 위반에 가벼운 제재를 가하면 커뮤니티 안전을 해칩니다.
구현
  • 경고 → 콘텐츠 검열 → 일시 정지 → 영구 정지의 단계적 체계
  • 위반 이력이 누적되어 다음 제재 수준에 반영됩니다
  • 심각한 위반은 단계를 건너뛰고 즉각적인 강력한 조치 가능

용어 정의

용어 정의
신고(flag/report) 행동 강령 위반으로 의심되는 콘텐츠나 사용자를 관리자에게 알리는 행위
신고자(reporter) 신고를 제출하는 사용자
피신고자(reported) 신고의 대상이 되는 사용자
신고 대상(target) 신고된 콘텐츠(게시글, 단문) 또는 사용자
관리자(moderator) 신고를 검토하고 조치를 취할 권한이 있는 사용자
조치(action) 관리자가 신고에 대해 취하는 결정 (기각, 경고, 검열, 정지 등)
이의 제기(appeal) 피신고자가 조치에 대해 재검토를 요청하는 행위
로컬 사용자 Hackers' Pub에 계정이 있는 사용자
원격 사용자 다른 ActivityPub 인스턴스의 사용자

신고 대상

콘텐츠 신고

사용자는 다음 유형의 콘텐츠를 개별적으로 신고할 수 있습니다:

게시글(article) 신고

대상
장문의 블로그 형식 게시글
표시 위치
게시글 하단 또는 더보기 메뉴에 “신고하기” 옵션
신고 시 수집 정보
  • 게시글 ID 및 영구 링크
  • 게시글 작성자 정보
  • 신고 시점의 게시글 내용 스냅샷 (증거 보존)
  • 신고자가 작성한 사유

단문(note) 신고

대상
짧은 마이크로블로그 형식 글
표시 위치
단문의 더보기 메뉴에 “신고하기” 옵션
신고 시 수집 정보
게시글과 동일

사용자 신고

특정 사용자의 전반적인 행동 패턴이 문제가 되는 경우, 개별 콘텐츠가 아닌 사용자 자체를 신고할 수 있습니다.

사용 시나리오
  • 여러 콘텐츠에 걸쳐 지속적으로 문제 행동을 보이는 경우
  • 개별 콘텐츠는 경계선상에 있지만, 전체적인 패턴이 문제인 경우
  • 프로필 자체(이름, 약력, 프로필 사진 등)가 행동 강령을 위반하는 경우
표시 위치
사용자 프로필 페이지의 더보기 메뉴에 “사용자 신고하기” 옵션
신고 시 수집 정보
  • 사용자 ID 및 프로필 링크
  • 신고 시점의 프로필 정보 스냅샷
  • 신고자가 작성한 사유
  • (선택) 관련 콘텐츠 링크 첨부 가능

원격 콘텐츠 및 사용자

다른 ActivityPub 인스턴스의 콘텐츠와 사용자도 동일하게 신고할 수 있습니다.

근거
연합 타임라인에 표시되는 모든 콘텐츠는 Hackers' Pub 사용자에게 영향을 미치므로, 원격 콘텐츠도 신고 대상이 되어야 합니다.
처리 방식
  • Hackers' Pub 내에서의 표시/연합 여부에 대한 조치
  • 원격 인스턴스로 ActivityPub Flag 액티비티 전송 (선택적)

신고 프로세스

신고 흐름도

flag_process start 사용자가 콘텐츠/사용자 신고 클릭 form 신고 양식 표시 start->form reason 사유 작성 (자유 형식) form->reason submit 신고 제출 reason->submit llm LLM이 사유를 분석 submit->llm coc 행동 강령 조항 매칭 llm->coc save 신고 저장 (대기 상태) llm->save notify_mod 관리자에게 알림 발송 save->notify_mod notify_reporter 신고자에게 접수 확인 notify_mod->notify_reporter

신고 양식

신고 양식은 간결하면서도 필요한 정보를 수집할 수 있도록 설계됩니다.

필수 입력 항목

신고 사유 (자유 형식 텍스트)

이 콘텐츠/사용자를 신고하는 이유를 설명해 주세요.
구체적인 행동 강령 조항을 알지 못해도 괜찮습니다.
어떤 점이 불편하거나 문제가 된다고 느꼈는지
자유롭게 작성해 주세요.

[                                        ]
[                                        ]
[                                        ]

최소 10자 이상 작성해 주세요.

근거:

  • 사용자가 행동 강령의 모든 조항을 숙지하고 있다고 가정하지 않습니다
  • 자유 형식으로 작성하면 더 풍부한 맥락을 수집할 수 있습니다
  • LLM이 사유를 분석하여 관련 조항을 자동으로 매칭합니다

선택 입력 항목

추가 콘텐츠 링크 (사용자 신고 시)

관련된 다른 콘텐츠가 있다면 링크를 추가해 주세요. (선택)

[링크 추가 +]

근거: 사용자 신고의 경우, 문제 행동의 패턴을 보여주는 여러 콘텐츠를 함께 제출하면 관리자가 더 정확한 판단을 내릴 수 있습니다.

LLM 기반 행동 강령 매칭

신고가 제출되면 LLM이 신고 사유를 분석하여 관련된 행동 강령 조항을 식별합니다.

매칭 프로세스

  1. 입력 구성

    • 신고자가 작성한 사유 텍스트
    • 현재 버전의 행동 강령 전문
    • 신고된 콘텐츠 내용 (있는 경우)
  2. LLM 분석

    • 신고 사유와 행동 강령 조항 간의 관련성 분석
    • 관련 조항 식별 및 신뢰도 점수 산출
    • 분석 요약 생성
  3. 결과 저장

    • 매칭된 조항 목록 (신뢰도 점수 포함)
    • LLM 분석 요약
    • 신고 시점의 행동 강령 버전 식별자

행동 강령 버전 관리

근거
행동 강령이 변경되면 과거 신고의 맥락이 불명확해질 수 있습니다. 따라서 신고 시점의 행동 강령 버전을 기록하여 맥락을 보존합니다.
구현 방식
  • 행동 강령 파일의 Git 커밋 해시를 버전 식별자로 사용
  • 신고 기록에 버전 식별자 저장
  • 관리자가 신고를 검토할 때 해당 버전의 행동 강령 참조 가능

매칭 결과 활용

관리자 검토
매칭 결과는 관리자의 참고 자료로 활용됩니다
최종 판단
관리자가 매칭 결과를 수정하거나 무시할 수 있습니다
피신고자 통보
최종 확정된 위반 조항이 피신고자에게 전달됩니다

중복 신고 처리

같은 콘텐츠나 사용자에 대해 여러 신고가 접수될 수 있습니다.

처리 방식
  • 동일 대상에 대한 신고는 하나의 “신고 케이스”로 그룹화됩니다
  • 각 신고의 사유는 개별적으로 보존됩니다
  • 관리자에게는 신고 건수와 함께 표시됩니다
  • 신고 건수가 많을수록 우선순위가 높아집니다
근거
  • 여러 사람이 독립적으로 같은 문제를 발견했다면 더 심각한 문제일 가능성이 높습니다
  • 다양한 관점의 신고 사유를 종합하면 더 정확한 판단이 가능합니다

신고 내역 조회

신고자는 자신이 제출한 신고의 상태를 확인할 수 있습니다.

확인 가능한 정보
  • 신고 대상 (콘텐츠/사용자)
  • 신고 일시
  • 자신이 작성한 신고 사유
  • 처리 상태 (대기 중 / 검토 중 / 처리 완료)
  • 처리 결과 (조치됨 / 기각됨)
확인 불가능한 정보
  • 다른 신고자의 존재 여부
  • 구체적인 제재 내용 (프라이버시 보호)
  • 피신고자의 이의 제기 내용

관리자 처리 프로세스

신고 검토 흐름도

moderation_process cluster_review 콘텐츠/사용자 검토 pending 신고 접수 (대기 상태) check 관리자가 신고 확인 pending->check reviewing 검토 시작 (검토 중) check->reviewing review1 신고된 콘텐츠 확인 review2 신고 사유 검토 review3 LLM 매칭 결과 참고 review4 사용자 이력 확인 review5 맥락 파악 decision 판단 결정 review5->decision dismiss 기각 decision->dismiss warn 경고 decision->warn action 제재 decision->action notify 조치 기록 및 알림 - 신고자에게 결과 통보 - 피신고자에게 조치 통보 - (필요시) 원격 서버 통보 dismiss->notify warn->notify action->notify

신고 상태

상태 설명
pending 신고가 접수되어 검토 대기 중
reviewing 관리자가 검토 중
resolved 처리 완료 (조치됨)
dismissed 기각됨 (위반 아님)

검토 시 확인 사항

관리자는 다음 정보를 종합적으로 검토합니다:

신고 정보

  • 신고자가 작성한 사유
  • LLM이 매칭한 행동 강령 조항
  • 신고 건수 (중복 신고의 경우)
  • 각 신고자의 사유 (중복 신고의 경우)

콘텐츠 정보

  • 신고된 콘텐츠 원문
  • 콘텐츠의 맥락 (댓글 스레드 등)
  • 신고 시점의 스냅샷 (수정/삭제된 경우)

사용자 정보

  • 피신고자의 이전 위반 이력
  • 이전 경고/제재 기록
  • 계정 생성일 및 활동 기간
  • 로컬/원격 사용자 여부

조치 옵션

관리자는 다음 조치 중 하나를 선택합니다:

조치 설명 적용 기준
기각 위반이 아니라고 판단 행동 강령 위반 사실이 없는 경우
경고 경고 메시지 발송 경미한 위반, 초범인 경우
콘텐츠 검열 해당 콘텐츠 숨김 처리 콘텐츠 자체가 문제인 경우
일시 정지 일정 기간 계정 정지 반복 위반 또는 중간 수준의 위반
영구 정지 계정 영구 정지 심각한 위반 또는 지속적 악의적 행동

조치 시 필수 입력 사항

관리자가 조치를 취할 때 다음을 기록해야 합니다:

위반 조항 (최종 확정):
[행동 강령 내 관련 조항 선택/입력]

조치 사유:
[관리자의 판단 근거를 상세히 기술]

피신고자에게 전달할 메시지:
[피신고자가 받을 통보 내용]

(일시 정지의 경우) 정지 기간:
[시작일] – [종료일]

근거:

  • 조치의 투명성을 확보합니다
  • 이의 제기 시 검토 자료로 활용됩니다
  • 일관된 판단 기준을 유지하는 데 도움이 됩니다

피신고자 프로세스

신고 통보

피신고자는 자신이 신고되었다는 사실과 사유를 알림으로 받습니다.

통보 시점

즉시 통보하지 않는 경우:

  • 신고 접수 직후에는 피신고자에게 통보하지 않습니다
  • 무분별한 신고로 인한 불필요한 스트레스 방지

통보하는 경우:

  • 관리자가 신고를 검토하고 조치를 결정한 후 통보합니다
  • 기각된 경우에도 교육적 목적으로 통보할 수 있습니다 (관리자 재량)

통보 내용

경고/제재 시:

귀하의 [콘텐츠/계정]에 대해 신고가 접수되어 검토한 결과,
행동 강령 위반으로 판단되어 다음과 같은 조치가 취해졌습니다.

위반 내용:
[행동 강령의 관련 조항]

대상 콘텐츠:
[해당되는 경우 콘텐츠 링크]

조치:
[경고 / 콘텐츠 검열 / N일 정지 / 영구 정지]

관리자 메시지:
[관리자가 작성한 설명]

이 조치에 대해 이의가 있으시면 아래 버튼을 통해
이의 제기를 하실 수 있습니다.

[이의 제기하기]

기각 통보 시 (선택적):

귀하의 [콘텐츠/계정]에 대해 신고가 접수되었으나,
검토 결과 행동 강령 위반에 해당하지 않는다고 판단되었습니다.

다만, 일부 커뮤니티 구성원이 불편함을 느꼈을 수 있으므로
참고해 주시면 감사하겠습니다.

관련 내용:
[간략한 설명]

피신고자가 확인할 수 있는 정보

정보 확인 가능 여부
신고된 사실 가능
위반으로 지적된 행동 강령 조항 가능
대상 콘텐츠 가능
조치 내용 및 기간 가능
관리자의 판단 사유 가능
신고자가 누구인지 불가능
신고자가 작성한 원본 사유 불가능
신고 건수 불가능

근거: 피신고자에게 개선에 필요한 정보는 모두 제공하되, 신고자를 특정할 수 있는 정보는 철저히 보호합니다.

제재 중 제한 사항

콘텐츠 검열

  • 해당 콘텐츠가 타임라인과 검색에서 숨겨집니다
  • 직접 링크(퍼머링크)로는 접근 가능하지만, 검열 안내가 표시됩니다
  • 작성자 본인은 콘텐츠를 볼 수 있습니다

일시 정지

  • 새로운 콘텐츠 작성 불가
  • 댓글 작성 불가
  • 반응 불가
  • 팔로/언팔로 불가
  • 기존 콘텐츠 열람은 가능
  • DM 수신은 가능하나 발신 불가

영구 정지

  • 계정 접근 불가
  • 모든 기능 사용 불가
  • 기존 콘텐츠는 숨김 처리됨

이의 제기 프로세스

이의 제기 자격

  • 조치를 받은 피신고자만 이의 제기 가능
  • 하나의 조치에 대해 1회의 이의 제기 가능
  • 이의 제기 기한: 조치 통보 후 14일 이내

이의 제기 흐름도

appeal_process start 피신고자가 이의 제기 write 이의 내용 작성 start->write submit 이의 제출 write->submit review 관리자 검토 (다른 관리자 권장) submit->review decision 판단 review->decision reject 기각 decision->reject uphold 조치 유지 decision->uphold modify 조치 변경 decision->modify notify 결과 통보 (피신고자, 원신고자) reject->notify uphold->notify modify->notify

이의 제기 양식

이의 제기 사유:
[왜 이 조치가 부당하다고 생각하시는지 설명해 주세요]

추가 맥락 또는 증거:
[조치 결정 시 고려되지 않았다고 생각되는
맥락이나 정보가 있다면 제공해 주세요]

[제출]

이의 제기 검토

검토 원칙
  • 가능하면 원래 조치를 결정한 관리자가 아닌 다른 관리자가 검토합니다
  • 원 신고 내용, 조치 사유, 이의 제기 내용을 종합적으로 검토합니다
  • 새로운 정보나 맥락이 있는지 확인합니다
결정 옵션
  • 이의 기각: 원 조치 유지
  • 조치 완화: 더 가벼운 조치로 변경 (예: 정지 → 경고)
  • 조치 철회: 조치 취소 및 기록 정정
  • 조치 강화: 드문 경우, 이의 제기 과정에서 더 심각한 위반이 발견된 경우

결과 통보

피신고자에게:

귀하의 이의 제기를 검토한 결과를 알려드립니다.

결정: [이의 기각 / 조치 완화 / 조치 철회]

판단 사유:
[관리자의 검토 결과 설명]

(해당 시) 변경된 조치:
[새로운 조치 내용]

원 신고자에게:

귀하가 신고하신 건에 대해 피신고자로부터
이의 제기가 있어 재검토가 진행되었습니다.

재검토 결과: [원 조치 유지 / 조치 변경]

(조치가 변경된 경우)
변경 사유에 대한 간략한 설명:
[설명]

패널티 체계

패널티 종류 및 기준

경고 (warning)

설명
위반 사실을 알리고 재발 방지를 요청하는 가장 가벼운 조치입니다.
적용 기준
  • 경미한 행동 강령 위반
  • 초범이며 악의가 없어 보이는 경우
  • 실수나 무지로 인한 위반으로 판단되는 경우
효과
  • 경고 메시지가 발송됩니다
  • 경고 이력이 기록되어 향후 판단에 참고됩니다
  • 일정 기간(예: 1년) 경과 후 이력에서 제외될 수 있습니다
경고 누적
  • 경고 3회 누적 시 자동으로 더 강한 조치 검토 대상이 됩니다
  • 단, 자동 제재는 없으며 관리자의 판단이 필요합니다

콘텐츠 검열 (content censorship)

설명
특정 콘텐츠를 공개 영역에서 숨기는 조치입니다.
적용 기준
  • 콘텐츠 자체가 행동 강령을 위반하는 경우
  • 사용자의 전반적 행동보다 특정 콘텐츠가 문제인 경우
효과
  • 해당 콘텐츠가 타임라인, 검색, 추천에서 제외됩니다
  • 퍼머링크는 유지되나, 접근 시 검열 안내가 표시됩니다
  • 연합(federation)으로 다른 서버에 Delete 액티비티가 전송될 수 있습니다

검열 콘텐츠 표시

이 콘텐츠는 행동 강령 위반으로 검열되었습니다.
[원문 보기] (클릭 시 경고와 함께 표시)

일시 정지 (temporary suspension)

설명
일정 기간 동안 계정 활동을 제한하는 조치입니다.
적용 기준
  • 경고에도 불구하고 위반이 반복되는 경우
  • 중간 수준의 심각한 위반인 경우
  • 즉각적인 활동 중단이 필요하지만 영구 정지까지는 아닌 경우
정지 기간
  • 최소 1일 – 최대 90일
  • 관리자가 위반 정도에 따라 결정
  • 권장 기준:
    • 경미한 반복 위반: 1–7일
    • 중간 수준 위반: 7–30일
    • 심각한 위반 (초범): 30–90일
효과
  • 새 콘텐츠 작성 불가
  • 상호작용(반응, 댓글 등) 불가
  • 기존 콘텐츠 열람은 가능
  • 정지 해제 시 완전한 기능 복구
원격 사용자의 경우
  • Hackers' Pub 내에서 해당 기간 동안 연합 차단
  • 원격 서버 관리자에게 ActivityPub Flag 액티비티로 통보

영구 정지 (permanent suspension)

설명
계정을 영구적으로 비활성화하는 가장 강력한 조치입니다.
적용 기준
  • 매우 심각한 행동 강령 위반 (혐오 발언, 불법 콘텐츠 등)
  • 일시 정지 후에도 동일한 위반이 반복되는 경우
  • 명백한 악의를 가지고 커뮤니티를 해치려는 의도가 확인된 경우
효과
  • 계정 로그인 불가
  • 모든 기능 사용 불가
  • 공개 콘텐츠 숨김 처리
  • 프로필 페이지에 정지 안내 표시
원격 사용자의 경우
  • Hackers' Pub과의 영구적 연합 차단
  • 원격 서버 관리자에게 ActivityPub Flag 액티비티로 통보
복구
  • 원칙적으로 영구 정지는 복구되지 않습니다
  • 극히 예외적인 경우, 충분한 시간 경과 후 재심 요청 가능

패널티 이력 관리

패널티 이력 보존 기간 비고
경고 1년 1년간 추가 위반 없으면 이력에서 제외
콘텐츠 검열 무기한 콘텐츠 존재하는 한 유지
일시 정지 무기한 기록은 유지, 판단 시 경과 시간 고려
영구 정지 무기한 -

ActivityPub 연합 처리

개요

Hackers' Pub은 ActivityPub 프로토콜을 사용하는 분산형 네트워크의 일부입니다. 신고 기능도 이 환경에서 원활히 작동해야 합니다.

Flag 액티비티

ActivityPub 명세에는 Flag 액티비티가 정의되어 있으며, 이를 통해 신고를 연합 네트워크에 전파할 수 있습니다.

Flag 액티비티 구조:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Flag",
  "actor": "https://hackerspub.example/users/moderator",
  "object": [
    "https://remote.example/users/reported_user",
    "https://remote.example/posts/problematic_post"
  ],
  "content": "Violation of Code of Conduct: harassment"
}

원격 콘텐츠 신고 처리

신고 접수

  1. 로컬 사용자가 원격 콘텐츠/사용자를 신고합니다
  2. 신고는 Hackers' Pub 데이터베이스에 저장됩니다
  3. 관리자가 일반 신고와 동일하게 검토합니다

조치 적용

  1. Hackers' Pub 내 조치:

    • 해당 콘텐츠의 로컬 캐시 숨김/삭제
    • 해당 사용자와의 연합 차단 (일시/영구)
  2. 원격 서버 통보 (선택적):

    • Flag 액티비티를 원격 서버에 전송
    • 원격 서버의 조치 여부는 해당 서버의 재량

외부에서 받은 Flag 처리

다른 서버에서 Hackers' Pub으로 Flag 액티비티가 전송된 경우:

  1. Flag 액티비티 수신 및 파싱
  2. 신고 대상이 로컬 사용자/콘텐츠인지 확인
  3. 관리자에게 외부 신고로 표시하여 알림
  4. 관리자가 검토 후 자체 판단에 따라 조치

외부 신고 표시:

[외부 신고] remote.example에서 접수됨

대상: @localuser의 콘텐츠
사유: "Violation of our community guidelines"

* 이 신고는 외부 서버에서 접수되었습니다.
  자체 행동 강령에 따라 판단해 주세요.

Mastodon 호환성

Mastodon은 가장 널리 사용되는 ActivityPub 구현체입니다. Mastodon과의 호환성을 위해 다음을 고려합니다:

  • Mastodon의 Flag 액티비티 형식 지원
  • Mastodon 관리자 API와의 연동 고려 (향후)
  • Mastodon에서 보내는 신고 수신 및 처리

알림 체계

알림 유형

알림 유형 수신자 내용
flag_received 관리자 새 신고 접수됨
flag_resolved 신고자 신고 처리 완료됨
action_taken 피신고자 조치가 취해짐
appeal_received 관리자 이의 제기 접수됨
appeal_resolved 피신고자 이의 제기 처리 완료됨
appeal_result 신고자 이의 제기로 인한 변경 알림
suspension_ending 피신고자 정지 해제 임박 알림

알림 채널

인앱 알림
기본 알림 방식
이메일
중요 알림 (조치, 정지 등)
ActivityPub
원격 사용자의 경우 해당 서버로 전송

프라이버시 및 보안

신고자 익명성 보호

원칙
신고자의 신원은 피신고자에게 절대 공개되지 않습니다.
기술적 조치
  • API 응답에서 신고자 정보 필터링
  • 관리자 UI에서만 신고자 정보 표시
  • 로그에서 신고자 정보 마스킹 (필요시)

데이터 접근 제어

역할 접근 가능 정보
일반 사용자 자신의 신고 내역만
피신고자 자신에 대한 조치 및 사유 (신고자 정보 제외)
관리자 모든 신고 정보 (신고자 정보 포함)

콘텐츠 스냅샷

신고 시점의 콘텐츠를 스냅샷으로 저장하는 이유:

  • 피신고자가 콘텐츠를 수정/삭제해도 원본 증거 보존
  • 공정한 판단을 위한 기록 유지
  • 이의 제기 시 참고 자료로 활용
보존 기간
  • 케이스 종료 후 최소 1년간 보존
  • 법적 요구사항이 있는 경우 더 오래 보존

악용 방지

허위 신고 방지
  • 동일 사용자의 동일 대상 반복 신고 제한
  • 허위 신고 시 신고자에 대한 제재 가능
  • 신고 패턴 모니터링
신고 폭주 방지
  • 단시간 다수 신고 시 속도 제한
  • 관리자에게 이상 패턴 경고

관리자 대시보드

대시보드 개요

관리자 대시보드는 신고 관리의 중심 허브입니다.

주요 화면
  1. 대기 중인 신고 목록
  2. 신고 상세 및 처리 화면
  3. 이의 제기 목록
  4. 통계 및 분석
  5. 제재 중인 사용자 목록

신고 목록 화면

┌─────────────────────────────────────────────────────────┐
│  신고 관리                                    [통계 보기] │
├─────────────────────────────────────────────────────────┤
│  필터: [전체 ▼] [대기 중 ▼] [최신순 ▼]      검색: [____]│
├─────────────────────────────────────────────────────────┤
│                                                         │
│  ⚠️ 높은 우선순위 (신고 5건 이상)                        │
│  ┌─────────────────────────────────────────────────┐   │
│  │ 🔴 @user123의 콘텐츠 (신고 7건)                 │   │
│  │    "혐오 발언", "차별적 표현" 외 5건             │   │
│  │    최초 신고: 2시간 전                          │   │
│  └─────────────────────────────────────────────────┘   │
│                                                         │
│  일반 신고                                              │
│  ┌─────────────────────────────────────────────────┐   │
│  │ 🟡 @remote@other.server 사용자 (신고 2건)       │   │
│  │    "스팸 행위"                                  │   │
│  │    최초 신고: 5시간 전                          │   │
│  └─────────────────────────────────────────────────┘   │
│  ┌─────────────────────────────────────────────────┐   │
│  │ 🟢 @newuser의 댓글 (신고 1건)                   │   │
│  │    "부적절한 언어 사용"                         │   │
│  │    신고: 1일 전                                 │   │
│  └─────────────────────────────────────────────────┘   │
│                                                         │
└─────────────────────────────────────────────────────────┘

신고 상세 화면

┌─────────────────────────────────────────────────────────┐
│  신고 상세 - 케이스 #12345                    [← 목록]  │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  📋 기본 정보                                           │
│  ────────────────────────────────────────               │
│  대상: @user123의 콘텐츠                                │
│  유형: 단문 (note)                                      │
│  신고 건수: 7건                                         │
│  상태: 대기 중                                          │
│                                                         │
│  📝 신고된 콘텐츠                                       │
│  ────────────────────────────────────────               │
│  ┌─────────────────────────────────────────────────┐   │
│  │ [콘텐츠 원문 표시]                              │   │
│  │ 작성일: 2024-12-01 14:30                        │   │
│  └─────────────────────────────────────────────────┘   │
│                                                         │
│  🔍 신고 사유 (7건)                                     │
│  ────────────────────────────────────────               │
│  1. "명백한 혐오 발언입니다" - 신고자A, 2시간 전        │
│  2. "특정 집단을 비하하는 표현" - 신고자B, 3시간 전     │
│  3. "불쾌한 차별적 언어" - 신고자C, 4시간 전            │
│  ... (더 보기)                                          │
│                                                         │
│  🤖 LLM 분석 결과                                       │
│  ────────────────────────────────────────               │
│  관련 행동 강령 조항:                                   │
│  - 차별 금지 (신뢰도: 95%)                              │
│  - 존중하는 언어 사용 (신뢰도: 88%)                     │
│                                                         │
│  📊 피신고자 이력                                       │
│  ────────────────────────────────────────               │
│  - 가입일: 2024-06-15                                   │
│  - 이전 경고: 1회 (2024-09-20)                          │
│  - 이전 정지: 없음                                      │
│                                                         │
│  ⚡ 조치                                                │
│  ────────────────────────────────────────               │
│  [기각] [경고] [콘텐츠 검열] [일시 정지] [영구 정지]    │
│                                                         │
└─────────────────────────────────────────────────────────┘

통계 화면

기간 선택 드롭다운으로 조회 범위를 설정합니다 (예: 최근 30일).

요약

항목
총 신고 건수 127건
처리 완료 98건 (77%)
평균 처리 시간 4.2시간

조치 분포

조치 건수 비율
기각 45건 46%
경고 38건 39%
콘텐츠 검열 10건 10%
일시 정지 4건 4%
영구 정지 1건 1%

위반 유형 (상위 5개)

순위 유형 건수
1 스팸/광고 32건
2 혐오 발언 24건
3 괴롭힘 18건
4 부적절한 콘텐츠 12건
5 허위 정보 8건

향후 고려사항

자동화 기능 (향후 도입 검토)

  • 자동 숨김: 특정 임계값 이상의 신고가 접수되면 관리자 검토 전 임시 숨김
  • AI 기반 사전 필터링: 명백한 위반 콘텐츠 자동 감지
  • 스팸 자동 처리: 명백한 스팸에 대한 자동 조치

주의

자동화 기능은 오탐의 위험이 있으므로 신중하게 도입해야 합니다.

커뮤니티 참여

  • 신뢰할 수 있는 신고자: 정확한 신고 이력을 가진 사용자의 신고에 높은 가중치
  • 커뮤니티 중재자: 관리자 부담 분산을 위한 커뮤니티 중재자 제도 검토

다국어 지원

  • 신고 사유 자동 번역 (관리자가 다른 언어 사용 시)
  • 행동 강령 다국어 버전과의 연동
  • 조치 통보 메시지 다국어 템플릿

법적 요구사항 대응

  • 법적 요청에 따른 데이터 보존/제공 절차
  • 저작권 침해 신고 (DMCA 등) 별도 처리 절차
  • 사법기관 협조 절차

부록: 용어 대조표

한국어 영어 설명
신고 flag/report 위반 의심 콘텐츠/사용자를 알림
행동 강령 code of conduct 커뮤니티 규칙
관리자 moderator 신고 처리 권한자
검열 censorship 콘텐츠 숨김 처리
정지 suspension 계정 활동 제한
이의 제기 appeal 조치에 대한 재검토 요청
연합 federation 분산 네트워크 간 연결
콘텐츠 post 게시글과 단문을 통칭
게시글 article 장문의 블로그 형식 글
단문 note 짧은 마이크로블로그 형식 글
타임라인 timeline 콘텐츠 피드
팔로 follow 다른 사용자 구독
팔로워 follower 나를 구독하는 사용자
차단 block 특정 사용자 접근 제한
반응 react 콘텐츠에 이모지로 반응
연합우주 fediverse ActivityPub 기반 분산 소셜 네트워크
인스턴스 instance 연합우주의 개별 서버

이 문서는 Hackers' Pub 커뮤니티의 의견을 수렴하여 지속적으로 개선됩니다.

Read more →
7

인터페이스가 구린 라이브러리를 쓸때는 반!드!시! 심호흡을 하고 멀쩡한 인터페이스의 wrapper를 만든후에! 기능 개발을 합시다. 절대 대충 꾸역꾸역 만들어보자고 덤비면 안됩니다. 결국 후회합니다.

  • V모사의 AI 라이브러리를 쓰다가
4

Claude Code의 인기와 함께 터미널에서 한글을 쓰는 모습을 자주 볼 수 있습니다. 하지만 터미널에서 쓰이는 한글은 글자간의 간격이 넓어 보기 좋지 않은 경우가 많습니다. 왜 이런 걸까요?

흔하게 쓰는 코드용 글꼴은 로마자, 숫자, 특수기호만을 다룰 뿐 한글은 다루지 않습니다. 그래서 터미널은 한글 표시를 하기 위해 대체 글꼴을 사용합니다. 대체 글꼴은 보통 OS의 기본 글꼴일 것입니다. 가변폭 글꼴이겠죠. 터미널은 이를 일부러 고정폭으로 만들기 위해 한글 한 자에 로마자 2자 폭을 할당하는데 이 과정에서 여백이 추가되면서 자간이 넓은 어색한 한글을 보게 되는 것입니다.

해결책은 한글 고정폭 글꼴을 사용하는 것입니다. 한글 고정폭 글꼴은 한글 1자를 로마자 2자 폭에 맞춰 만들었으므로 터미널이 더 이상 여백을 만들지 않습니다. 이러한 한글 고정폭 글꼴이 많진 않습니다. 10종이 안 되는 것 같네요. 저는 그중 Monoplex를 사용하고 있습니다. @hongminhee洪 民憙 (Hong Minhee) 님은 Sarasa Gothic을 사용하신다고 하네요. 적은 수의 글꼴이지만 맘에 드시는 걸 찾으셔서 예쁜 한글 출력을 보시면 좋겠습니다.

한글 고정폭 글꼴 적용이 안 된 터미널 화면한글 고정폭 글꼴 적용이 된 터미널 화면
3
4

Optique 0.9.0 pre-release is ready for testing!

The big new feature: sync/async mode support. You can now build CLI parsers with async value parsing and suggestions—perfect for shell completions that need to run commands (like listing Git branches/tags).

The API automatically propagates async mode through combinators, so you only decide sync vs async at the leaf level.

Try it:

npm  add       @optique/core@0.9.0-dev.212 @optique/run@0.9.0-dev.212
deno add --jsr @optique/core@0.9.0-dev.212 @optique/run@0.9.0-dev.212

I'd love feedback before merging! Especially interested in:

  • API ergonomics
  • Edge cases I might have missed
  • TypeScript inference issues

Docs:

PR: https://github.com/dahlia/optique/pull/70

0
3
1
1
1

VCS와 패키지 매니저가 통합되어야 한단 얘기를 했었는데, shadcn의 인기가 그런 방향에 대한 지지를 간접적으로 보여주고 있다. shadcn은 UI 라이브러리를 만들어봤자 어차피 고쳐쓰는 경우가 많아서 나왔다. 문제는 기존의 npm 패키지 같은 것들은 받는건 쉬운데 그다음에 고치는게 열불터지는 것이다.

  1. 조건에 맞는 소스 코드를 받는 것 2. 그걸 고치는 것, 에서 패키지 매니저는 1은 잘하는데 2를 불편하게 만든다. VCS는 1을 할수있는데, 약간 번거롭게 되어있고(git submodule을 생각해보라), 2는 당연히 쉽다. VCS에서 1을 개선해야한다.
4

Zed는 망치가 좀 부족한가.. 심지어 성능도 좋은게 잘 체감 되지 않는데, 렌더링이 아닌 다른 곳에서(아마도 LSP와의 통신?) 구현이 구린지 랙이 빈번하다.

1
2

AI 물 사용량 떡밥의 문제는, 그 이야기를 하는 사람의 상당수가 AI의 결과물은 모조리 무가치하다는 생각을 하고있다는 것이다. 결과물의 가치가 0이라면, 뭐 물을 500ml만 써도 낭비는 낭비겠지요? AI와 관련해 해결해야할 문제가 한두개가 아닌데, 논의에 질을 높이고 고품격의 토큰이 오갔으면 좋겠다.

3

(아무도 관심없겠지만) 요거의 예시로는 tree-sitter의 파싱 테이블 + AST node 메타데이터 export가 있다. 지금은 파싱 테이블 대신 parser.c만 뱉고 중요한 메타데이터를 몇개 빼먹는다. 하는 김에 rewrite in haskell도 하면 더 좋고..

5

NextJS 처음 써보는데, 챗봇 UI처럼 인터액티브한 웹앱을 만들때 도움이 되는 부분이 뭔지를 모르겠다. 처음엔 SPA + API 서버 만드는것과 비교해, 자명한 데이터 바인딩 보일러플레이트를 줄여줄거라 생각했다. 근데, 순수 SSR로 처리할 수 없는, 클라에서 상태를 업데이트하는 약간만 복잡한 플로우에서도 전혀 도움이 안된다.

@bglbgl gwyng 조금 박한 평가일지는 모르겠지만 NextJS는 SEO가 중요한 거 아니면 굳이라는 생각입니다. SSR을 써야 하는 경우가 요즘에는 상당히 제한적이라는 게 제 생각입니다. 굳이 따지자면 프론트엔드랑 백엔드랑 같이 작업할 수 있다 정도인데, 이건 풀스택이 아닌가 싶기도 하고요.

1

좀 웃긴 생각이 났는데, '해결해주면 나랑 친해질수 잇는 문제들'이란 목록을 만들어서 공유하고 싶다. 네임드가 되면 실제로 잘 동작하려나.

6
1
4
2

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how / works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

2
1
0

@bglbgl gwyng 그러면 계속해서 여러 개의 메세지가 나올 때, 한번 스트리밍이 끝나면 어느 인덱스의 메세지에서 최종 output을 확인할 수 있는지 별로인 것부터가 크다고 생각합니다. 그 뿐만이 아니라 요즘 LLM들은 Text랑 Tool Calling 말고도 multimodal 모델들이 많아서 Image나 File도 첨부할 수 있는데 이런 part들은 어떻게 한 메세지에 확장해서 담을 수 있을지 고민한 결과이기도 하구요.

@nebuletoHaze 저는 MessageisFinal같은 프로퍼티가 있으면 된다고 생각하고, 말씀하신 이미지나 파일 첨부도 그냥 메시지를 쪼개는게 낫다고 생각합니다. 그냥 챗봇(AI 챗 UI가 아니라 디스코드 등에 붙는)이 가질만한 인터페이스를 그대로 가지는게 낫다고 생각해요.

0

bgl gwyng replied to the below article:

스마일 PRO 라식 수술 후기

자손킴 @jasonkim@hackers.pub

시력교정술을 받은 주변사람들이 신세계라며 추천을 해도 그동안 관심이 없었다. 어렸을때부터 안경을 쓰고 평생을 살아온지라 안경을 쓰는 것이 불편하다고 느껴 본 적이 없었기 때문이다.

라식을 해볼까? 라고 생각이 든 것은 스쿠버 다이빙을 시작하게 되면서였다. 다이빙에 취미를 붙이고나니 가장 불편한게 눈이었다. 렌즈를 끼고 있는게 불편한건 물론이고 아침 바쁜 와중에 렌즈가 안들어가서 진을 다 빼고 하루를 시작하는것도 문제였다. 게다가 렌즈를 부족하게 들고가거나 숙소에 렌즈를 놓고 오는 등 나의 정신머리 때문에 반쪽짜리 다이빙을 하게 되는 일이 반복되면서 시력교정을 해야겠다고 결심했다.

공장식 병원이야 어차피 거기서 거기라는 생각에 병원비교 사이트를 보고 적당한 곳을 골라 검사 예약을 했다. 원하면 당일 수술도 가능하다고 하던데 나는 검사만 먼저 받고 일주일후에 수술을 하기로 했다.

검사는 일반적인 안과 검사와 크게 다른 것은 없었다. 눈에 바람을 쏘는 것을 시작으로 뭔가를 들여다보고 빛을 비추고 등등 예닐곱가지의 검사가 진행되었다. 이어서 시력 검사를 하고 교정 후 도수를 결정했는데 이것은 안경 맞출때와 동일했다.

검사가 끝나고 의사선생님과 상담하며 눈의 상태에 대해서 설명을 들었다. 다행히 안압이나 눈 모양등도 정상이고 각막 두께도 평균이라 라섹, 라식 모두 원하는대로 진행이 가능하다고 했다. 다만 이제 노안이 오고 있기 때문에 돋보기를 쓰는 시간을 조금이라도 더 늦추려면 시력을 약간 낮추고 양눈 중 주로 가까이 보는 눈은 시력을 조금 더 낮춰 교정하는게 좋겠다는 제안을 받았다.

이어서 코디네이터에게 수술 종류와 방법에 대한 설명을 들었다. 나는 회복이 빠른게 최우선이었기 때문에 스마일PRO를 하기로 결정했다.

수술 당일에도 2~3가지의 검사를 다시하고 최종적으로 교정 시력에 대해서도 다시 한 번 확인을 하고 코디네이터에게 수술 후 주의사항과 안약 투여에 대한 설명을 듣는다.

눈에 물이 닿는 것과 격렬한 운동은 일주일 정도 피해야한다. 2주간은 금주하고 한 달동안 과음도 피해야 한다. 목욕탕, 사우나처럼 뜨거운 증기와 물은 한달간 피한다.

의사선생님을 만나 눈 상태에 대해서 최종점검을 하고 수술 대기실로 이동을 하여 위생모와 가운을 입고 잠시 기다리다 수술실로 들어갔다. 간호사님의 안내에 따라 수술장비에 누우면 눈을 감고 있으라 한 후 세팅을 시작하는데, 이때부터는 절대 고개를 들지말라고 한다.

잠시후 눈을 뜨라고 한 뒤 의사가 눈에 마취안약을 넣어줬다. 집게 같은걸로 눈을 벌리고 "이것만 문제 없으면 다른건 잘 참으실 수 있을거에요"라는 소리와 함께 눈앞에서 뭔가가 왔다갔다 하는데 아마도 마취가 되었는지 안구를 건드려 보는 것 같았다. 눈에 아무런 느낌은 없었다.

수술은 오른쪽 눈부터 진행되었다. 왼쪽눈에는 거즈 같은 것을 덮고 오른쪽 눈으로 앞에 보이는 초록불빛을 바라보라고 한다. 초록불빛을 바라볼때 다른 눈을 감으면 눈이 움직일 수 있으니 양쪽눈을 다 뜨되 수술하는 눈으로만 보라고 한다.

처음에는 크고 흐릿하게 보였던 초록불빛이 점점 작고 선명해 지면서 초록점으로 보인다.초록점을 눈의 중앙에 오도록 보라고 하는데, 이때가 가장 어려웠다. 초록점을 눈의 가운데에 오도록 보고 있는데 의사가 거기가 아니니 제대로 보라고 하는것이다. 몇 번을 다시 시도해도 잘 안됐는지 "환자분이 하는 수술인데 협조가 안되면 어떻게 하냐"며 의사가 약간 역정을 냈다.

초록점을 보는데 실패하면 기계가 눈을 잡아줄 수 없고 의사가 직접 조작하여 수술을 해야 하는데, 그러면 아무래도 기계만큼의 정확도가 나오지는 않는 모양이다.

어떻게하면 방향을 맞출 수 있을지 궁리하다 눈알을 오른쪽에서 왼쪽으로 천천히 굴려보다 의사가 됐다고 하면 멈춰보기로 했다. 눈알을 굴리는데 의사가 거기가 맞다고 하였다. 초록점은 안구의 중앙이 아닌 미간 정도의 위치에 있었다. 잘은 몰라도 사람마다 안구의 각도 같은게 차이가 있나보다.

이제 레이저를 조사하니 가만히 있으라 하고 의사와 간호사가 시간을 세어준다. 초록점을 보고 6~7초 정도 있으면 어느새 점이 사라지고 눈앞이 하얗게 보인다. 2~3초가 더 지나자 끝났다며 잘 참았다고 한다. 레이저가 조사되는 동안은 별다른 느낌은 없었다.

다음으로 왼쪽눈을 진행하는 오른쪽보다 훨씬 수월했다. 왼쪽눈도 우선 처음에는 초록점을 눈의 중앙에 오게 바라봤는데 그게 맞았는지 한 번에 진행되었다. 마찬가지로 약 10초정도가 걸려 레이저 조사가 끝났다.

레이저 조사가 끝나면 무언가로 눈을 후비적거리고 주사를 몇 개 놓고 안약등을 넣고 불빛을 쬐어준다. 이것은 레이저 조사가 마지막으로 끝난 왼쪽을 먼저 하고 오른쪽을 하였다. 아마도 각막 조각을 제거하고 소독등의 처치를 하는 것 같았다. 이 과정은 눈 한쪽당 1~2분 정도 걸렸던 것 같다.

모든 과정이 끝나면 간호사의 안내에 따라 장비에서 일어나 이동을 한다. 궁금한 마음으로 주변을 둘러봤는데 세상이 온통 뿌연게 온통 손자국이 번짐 안경을 쓰고있는 기분이었다. 뿌옇긴해도 이전보다 더 선명해진것은 체감이 됐다.

다시 한 번 의사선생님을 만나 눈에 이상이 없나 검사를 받고 몇가지 주의 사항을 들은 후 퇴원을 한다. 초반에는 빛번짐이 있을 수 있고 시력이 한번에 교정시력 만큼까지 잘보이는 건 아니지만 시간이 지나며 계속 더 잘보일 것 이라고 한다. 그리고 이제 눈이 시리기 시작할건데 1~3시간 정도면 가라앉을 거라는 이야기도 들었다.

퇴원하는 길에 약국에 들려서 안약 2종류와 인공눈물을 받았다. 안약은 일주일간 하루 4번을 투여하고 인공눈물은 수시로 넣으라고 한다. 안약을 여러개 넣을때는 최소한 5분 간격을 두고 넣으라고 하는데 종류가 여러개이다보니 안약 넣다보면 하루가 다 간다.

집에 오니 눈시림이 더 심해지고 눈에 다래끼나 나거나 눈썹이 들어간듯한 이물감이 느껴져서 눈을 뜨고 있을 수가 없었다. 눈을 떠도 온통 뿌옇게 보여서 사물의 형체는 분간이 되지만 글씨 같은건 읽을 수가 없었다. 안약을 넣어야 하는데 주의사항이 적혀있는 종이를 읽을 수 없어서 제미나이 라이브를 켜고서 읽어달라고 했다.

안약을 넣고서 침대에 누워 눈을 감았다. 눈을 감아도 빛이 밝으면 눈이 시려서 빛을 차단하고 누워있다 두어시간 자고 일어났다. 이물감은 여전했지만 눈시림과 빛번짐이 덜해서 눈을 뜨고 무언가를 볼 수는 있었다. 눈을 오래 뜨고 있으면 피로감이 있는건 마찬가지라 저녁 먹고 다시 안약을 넣고 일찍 잠을 청했다. 덕분에 밀린 수면 부채를 많이 갚았다.

눈의 피로감 때문인지 깊게는 못자고 자다 두어번 깼다. 일어나보니 새벽 5시쯤 되었는데 더이상 잠이 안오길래 후기나 써야겠다고 생각했다. 이물감이나 눈시림은 많이 나아졌고 눈도 어제보다는 더 선명하게 보이기 시작했다. 그러나 빛번짐으로 인해 탁하고 뿌옇게 보이는건 여전했다.

모니터나 스마트폰의 화면을 볼 수는 있는데 밝으면 눈이 아프고 집중하면 눈이 시려서 글자 크기를 키우고 화면 밝기는 최대한 낮췄다. 모니터를 오래 보면 눈이 금방 피로해져서 드문드문 후기를 적다가 진료 시간이 다되어 다시 병원을 찾았다.

라식 수술 후에는 1일, 1주일, 1개월, 3개월에 진료를 받는 것을 권장하고 6개월 이후에는 6개월~1년 주기로 한 번씩 검사를 받는 것을 권장한다고 한다.

불편한게 있는지 물어봐서 눈시림과 이물감이 있었지만 지금은 많이 좋아졌다고 답하였다. 먼거리와 가까운 거리의 시력을 다시 한 번 검사하고 의사선생님을 만나 안구 상태에 대해서 진료를 받았다. 어제 수술 중 초록점을 바라보는 문제에 대해 이야기를 나눴다.

내가 걱정했던 부분은 혹여나 잘못된 위치를 바라봐서 각막이 엉뚱하게 절삭된 것은 아닐까 하는 것이었다. 하루가 지나면서 그렇지는 않을 것 같다는 생각을 했으나 혹시 모를 일이라 한 번 더 의사선생님한테 물어봤다.

다행히 어제 수술도 정확히 되었고 오늘 안구 상태도 이상 없으니 걱정 말라는 답을 들었다. 혹여나 초록점을 제대로 못보는 환자가 있다면 나처럼 안구의 중앙이 아닌 다른 곳을 봐야 하는 것일 수 있으니 다른 곳을 보도록 유도하며 안구를 맞추면 좋겠다는 말씀을 드리고 다음주에 뵙자하고 진료를 마무리했다.

시간이 지날수록 시야가 점점 선명해 지는게 체감이 되고 있다. 그러나 뿌옇게 보이는 느낌은 아직 남아 있어서 안경을 닦거나 고쳐써야 할 것 같은데 그럴 안경이 없어서 당혹스러움을 느끼고 있다.

나는 이제 지금까지와는 다른 눈으로 세상을 보게 되었다.

Read more →
2
1

@bglbgl gwyng

전 LangChain / LangGraph에 비하면 Vercel AI SDK가 훨씬 sane하다고 생각합니다 ^_ㅜ… 원래 에이전트를 LangChain으로 만들다 이제 Vercel AI SDK에 정착했습니다.

Tool calling은 무엇을 써서 만들어도 안에선 결국 LLM이 호출할 함수와 실행 인자 토큰을 보내면 그걸 provider의 SDK나 그걸 감싼 라이브러리(e.g. LangChain or AI SDK)에서 schema validation을 하고 실패하면 retry를 시키고 하면서 사실상 자기 혼자서 멀티 턴처럼 수행합니다.(그러다가 루프가 나거나 하지 않도록 안에서 상태 머신을 만들고 depth라던가 제한하는거구요.) 그리고 각 파트가 업데이트되고 토큰을 계속 업데이트하다가 동작이 모두 끝나면 그 Part 속 전체 메세지와는 별개의 Message 전체 출력이 나온다는 점에서 이 방식이 맞다고 생각합니다.

저흰 클라이언트와 서버가 굉장히 구분된 편이긴 한데, 서버에서 SSE로 스트림 돌면서 text-delta이면 토큰 이벤트로 추가된 토큰을 내려주고, 스트림이 다 끝나면 전체 텍스트를 가져와서 완료 이벤트로 전체 텍스트를 한번 더 내려주고 대화 제목 업데이트가 필요하면 대화 제목 만들어서 대화 제목 이벤트 보내주고 완료 시점에 데이터베이스에 저장하고 완료 이벤트를 내리고 있습니다. + 클라이언트의 SSE 연결이 끊어져도 해당 작업은 계속 백그라운드에서 돌게만 해두었습니다.

아마 저희가 AI SDK의 프론트엔드 컴포넌트를 쓰지 않고 별도로 자체적으로 이벤트 목록과 스키마를 정해서 그걸로 컴포넌트를 만들어서 크게 스트레스를 못 받는 것일지도 모르겠네요.

@nebuletoHaze 멀티턴을 Message 여러개하는 걸로 할수있지 않나요? 멀티턴을 위해 Part가 필요한지 모르겠습니다.

별개로 말씀하신 구현이 저의 구현이 비슷할거 같습니다. 저도 Vercel AI SDK는 그냥 프로바이더들의 공통 인터페이스로만 쓰고 실제로 delta다루는 로직은 직접 다 하고있습니다.

0

@nebuletoHaze Vercel AI SDK에 대한 불만은 인용에 써놨구요, 챗봇 UI에서는 서버에서 상태를 스트리밍으로 받와야하는데(저도 SSE 쓰고 있습니다), 이 시나리오에서 NextJS가 사실상 도움이 안됩니다.

0

NextJS 처음 써보는데, 챗봇 UI처럼 인터액티브한 웹앱을 만들때 도움이 되는 부분이 뭔지를 모르겠다. 처음엔 SPA + API 서버 만드는것과 비교해, 자명한 데이터 바인딩 보일러플레이트를 줄여줄거라 생각했다. 근데, 순수 SSR로 처리할 수 없는, 클라에서 상태를 업데이트하는 약간만 복잡한 플로우에서도 전혀 도움이 안된다.

2
3
2

그동안 Nix 쓰면서 고통도 많이 받았는데 그래도 주변에 꾸준히 Nix를 권한다. Nix가 '빌드'라는 소프트웨어 개발의 아주 일반적인 문제를 한방에 푸는 방법론이기 때문이다. 물론 아직 몇가지 문제가 좀 있지만(잘 안된다, 불편하다 식의 단순한 문제는 아니다), 나 자신도 그 해결책을 위한 몇가지 아이디어를 가지고 있고, 머지않은 미래에 풀릴거라 생각한다.

UNIX 철학이 작은 기능을 확실하게 수행하는 프로그램들을 만들어 조합하자인데, ls, cat, grep 등이 그 예시다. 내가 볼땐 Nix도 생각도 거기에 해당된다. Nix도 좋은 의미로 의외로 꽤 작다.

5

@hongminhee洪 民憙 (Hong Minhee) Vercel AI SDK에서 제가 문제점이라고 느낀 디자인을 그대로 갖고 있네요. 사실 저도 아직 충분히 고민해보진 못했고 반대 의견은 매우 환영입니다.

제가 문제라고 느낀 부분은 Message 타입 밑에 Part가 있는 건데요. 그러니까 LLM의 응답이 플랫하게 Message[]이 아니라 Message[].Part[]가 됩니다. Part는 Plain Text거나 Tool Call일 수 있습니다. 그런데 이게 메시지를 DB에 저장하고 Streaming UI를 만들때 불편합니다. 그냥 Part를 없애고 Message만 있으면 좋겠어요.

처음에 저런식의 디자인을 한 동기를 추측해보자면, Message[]를 User/Assitant/User/Assistant/... 이렇게 번갈아 나타나는 형태를 기대하고, 그걸 만족시키려면 Assistant/Assitant 이렇게 연달아 나타나는걸 피해야하니 Part를 도입한게 아닌가 싶습니다. 근데 실제론 저 번갈아 나타나야한다는 조건이 타입으로 강제도 안되고(이건 어려우니 OK) 런타임에서 뭐라고 하지도 않아요. 그리고 실제 사용에서 연달아 나타나는걸 허용하는게 오히려 자연스럽습니다.

그래서 처음에 잠깐 잘못 생각해서 나온 디자인이, 실제론 의도한 제약을 주고있지도 못하고 그냥 쓰임만 불편하게 만들고 있는거 같습니다.

2