주고받는 이메일 데이터에 AI를 활용하는 것에 대한 이야기가 나왔다.

하지만, 이걸 위해 메일 서버를 별도로 구축하거나, 메일 클라이언트와 검색 기능 등을 별도로 코딩하기에는 아무리 AI Code Generation을 쓴다고 해도, 쓸만한 결과물이 나오기까지의 과정이 여간 쉬운 일이 아니다.

결국, 이메일과 관련된 모든 기능이 이미 있는 "MS Office"에 붙어서 바로 코딩할 수 있는 JS 프레임워크를 이용하기로 했다.

MS Outlook의 메일을 AI로 분석하는 실제 예시

// Analyze Microsoft Outlook data with ChatGPT
// Require: WelsonJS framework (https://github.com/gnh1201/welsonjs)
// Workflow: Microsoft Outlook -> OpenAI -> Get Response
var Office = require("lib/msoffice");
var LIE = require("lib/language-inference-engine");

function main(args) {
    var prompt_texts = [];

    var keyword = "example.com";
    var maxCount = 10;
    var previewLen = 160;

    console.log("Searching mails by sender OR recipient contains: '" + keyword + "'.");
    console.log("This test uses Restrict (Sender/To/CC/BCC) + Recipients verification.");
    console.log("Body preview length: " + previewLen);

    var outlook = new Office.Outlook();
    outlook.open();
    outlook.selectFolder(Office.Outlook.Folders.Inbox);

    var results = outlook.searchBySenderOrRecipientContains(keyword);
    console.log("Printing search results. (max " + maxCount + ")");

    results.forEach(function (m, i) {
        var body = String(m.getBody() || "");
        var preview = body.replace(/\r/g, "").replace(/\n+/g, " ").substr(0, previewLen);
        
        var text = "#" + String(i) +
            " | From: " + String(m.getSenderEmailAddress()) +
            " | To: " + String(m.mail.To || "") +
            " | Subject: " + String(m.getSubject()) +
            " | Received: " + String(m.getReceivedTime());

        console.log(text);
        console.log("  Body: " + preview);
        
        // Add an email data to the prompt text context
        prompt_texts.push(text);
        
        // The body to reduce token usage and avoid sending overly large/sensitive content.
        var bodyForPrompt = body;
        var maxBodyLengthForPrompt = 2000; // Keep the body snippet short
        if (bodyForPrompt.length > maxBodyLengthForPrompt) {
            bodyForPrompt = bodyForPrompt.substring(0, maxBodyLengthForPrompt) + "...";
        }
        prompt_texts.push("  Body: " + bodyForPrompt);
    }, maxCount);

    outlook.close();

    // build a AI prompt text
    var instruction_text = "This is an email exchange between the buyer and me, and I would appreciate it if you could help me write the most appropriate reply.";
    prompt_texts.push(instruction_text);

    // complete the prompt text
    var prompt_text_completed = prompt_texts.join("\r\n");

    //console.log(prompt_text_completed);  // print all prompt text

    // get a response from AI
    var response_text = LIE.create().setProvider("openai").inference(prompt_text_completed, 0).join(' ');

    console.log(response_text);
}

exports.main = main;

실행 방법

1. CLI 사용

모든 작성 및 저장을 마친 후, 다음 명령을 통해 실행한다. (outlook_ai.js 파일로 저장했을 때.

cscript app.js outlook_ai

2. GUI 사용

모든 작성 및 저장을 마친 후, WelsonJS Launcher 앱을 통해 실행한다.

실행하면 어떤 결과가 나오는가?

메일 내용에는 개인정보가 포함되어 있으므로 예시는 따로 첨부하지 않았다.

위 코드의 작업이 성공하면 메일 내용이 출력되면서, OpenAI 서버에서 분석을 마친 결과값을 얻어올 수 있다.

오랫동안 머신러닝 딥러닝 AI 모델링을 업으로 삼아 왔지만 정작 LLM이나 이미지 생성 같은 생성쪽은 피해다니다 보니^[1] 이쪽 주제에 대해 아는 척 하기도 쉽지 않지만.. 관련 논의들 구경하다 보면 제가 평소 생각하는 중요 지점들이 잘 이야기되지 않는 것 같아 의식의 흐름을 따라 이것저것 남겨봅니다.

우선 모델이 생성한 결과물이 어떤 성격이나 맥락을 가지는지에 따라 저작권 문제가 완전히 달라지는데, 이건 원래 저작권에 대한 전반적인 성격이 그러하기 때문입니다. 기존 저작물을 복사/변형하더라도 그 목적이 원래 저작물과 판이하게 다를수록 저작권 침해가 아니라 fair use로 인정받을 가능성이 높아집니다.

맥락과 의도가 얼마나 중요한지를 보여주는 상징적인 사례가 구글 북스 소송인데, 구글 북스는 저작권이 있는 책을 사용자들에게 그대로 보여주니까 심각한 저작권 침해로 보일 수 있지만, 법정에서는 구글 북스 웹사이트가 원래 책 내용을 그대로 접근하는 목적을 막고 검색이라는 새로운 목적에만 사용가능하도록 했다고 판단했습니다.

이러한 다양한 사례 연구들이 Foundation Models and Fair Use에 나와 있습니다. 이 논문은 AI 연구자들과 법학 연구자가 같이 썼고 여러 legal edge case가 등장해서 생각을 정리하는 데에 도움이 될 수 있습니다.

Fair use의 핵심 요소인 transformative에 대해 AI모델 입장에서 보면, 사용자가 준 입력 텍스트에 있는 정보를 추출하거나 변환하는 task가 이에 해당할 가능성이 높습니다. 가장 유명한 예시가 텍스트 번역일 것 같은데, 사용자가 입력한 텍스트를 다른 언어로 바꾸는 것이 전부고 거기에 새로운 창작성이 드러나지는 않습니다^[2]. 제가 이해하기로는 LLM이나 소위 AI가 잘 한다고 알려진 task도 대부분 이러한 것입니다. 번역이라든지, 텍스트 포맷을 바꾼다든지 등등. 제 주변에 LLM 잘 활용하신다는 분들을 보면 아마도 대부분 그렇게 쓰시는 것 같고요.

여기서 UX 관점에서의 불평을 하고 싶은데요, 무조건적인 텍스트 생성이 아니라 주어진 입력을 변환하는 능력이 LLM의 핵심 가치라면 모델이나 서비스 입장에서 그런 기능만 제공하고 지나친 생성을 제한하는 UI나 기술 장치를 도입해야 하지 않을까요? LLM을 긍정적으로 생각하지만 전반적인 생성(특히 입력보다 출력이 더 자유도가 높을 경우)이 사회적으로 위험하다고 생각된다면 그러한 조치를 LLM 서비스 제공자들에게 요구할 수는 없을까요? 저는 이러한 방향의 논의를 거의 본 적이 없는데, 아마 LLM를 접해본 사람들은 긍정적이든 부정적이든 그런 인터페이스가 어쩔 수 없는 일이라고 가정하고 있어서 그런 것 같습니다. (마침 며칠 전부터 ChatGPT나 Gemini에 번역 전용 UI가 생겼다는 소식이 보이고 있습니다. 이 글을 조금 더 빨리 쓸 걸 그랬네요..)

프로그래밍 쪽에서도 비슷하게 코드를 생성하는 사용법보다는 코드를 읽고 정보를 추출해주는 쪽이 저작권이나 윤리 문제가 적고 프로그래머의 능력 향상에 도움이 되지 않을거라고 생각하고요. (제가 상상하는 최적의 코딩 AI agent는 Rubber duck에 가까운데, 모든 질문과 해답이 제 머릿속에서 나와야 한다고 생각합니다. 그 중 문제 해결이나 능력 향상에 명백히 도움 안 될 질문만 잘 쳐내주면 좋겠어요.)

cf: 최근 Moral Codes를 조금씩 읽고 있습니다. 프로그래밍과 UI와 LLM과 윤리에 대한 책입니다. 아직 전부를 차근차근 읽은 건 아니지만, 기존의 LLM 논의가 갖혀있던 프레임에 빠져나오는 데에 큰 도움이 될 수 있다고 보여서 이 주제에 관심이 있는 분들에게 추천합니다. Open access라 무료로 볼 수 있어요.

---

1. Generative AI in Servo에서 제시하는 potential exceptions가 제 분야와 정확하게 겹칩니다. ↩︎

2. 현실적으로는 학습 데이터 오류 등으로 입력에 없던 내용이 튀어나오는 문제가 있습니다. Hallucination이라는 용어가 LLM 논의할때 주로 나오지만 실제로는 번역 task 연구 논문에서 처음 제시된 용어이고 해당 분야에서 이 문제는 오랫동안 중요하게 인지되어 왔습니다. ↩︎

코드를 한 줄도 안 짰는데, 최고의 개발자로 평가받았다

최근(정확하게는 작년 7월쯤) 한 사람이 실리콘밸리 회사를 포함해 많게는 60여 개의 회사에 동시에 취업해 일했다는 이야기가 화제가 되었다. 놀라운 점은 그가 여러 회사를 속였다는 사실이 아니라, 오히려 각 회사에서 “일을 정말 잘한다”는 평가를 받았다는 점이었다. 더 어처구니없는 사실은, 그가 실제로는 코드를 거의, 혹은 전혀 작성하지 않았다는 것이다.

그의 직함은 분명 프로그래머였다. 채용 공고 역시 프로그램을 작성할 사람을 찾고 있었다. 그러나 실무에 투입된 뒤 그가 한 일은 코드 작성이 아니라 방향 제시, 구조 정리, 기술 선택에 대한 조언, 그리고 갈등 중재였다. 말하자면 그는 개발자가 아니라 컨설턴트처럼 일했다. 그런데 결과적으로 팀의 생산성은 올라갔고, 프로젝트는 이전보다 더 잘 굴러갔다.

이 기묘한 상황은 개인의 기지나 편법 때문이 아니라, 현대 소프트웨어 조직이 안고 있는 구조적인 모순을 드러낸다.

회사는 정말로 ‘코드를 짜는 사람’을 원했을까

많은 회사가 개발자를 채용할 때 “무엇을 만들 사람인가”보다 “어떤 직무명을 가진 사람인가”를 먼저 적는다. 백엔드 개발자, 시니어 엔지니어, 풀스택 개발자 같은 익숙한 단어들이 채용 공고를 채운다. 그러나 실제로 현장에 들어가 보면 문제는 코드에 있지 않은 경우가 훨씬 많다.

무엇을 만들어야 할지 내부 합의가 없고, 기술 선택에 대한 책임을 누구도 지고 싶어 하지 않으며, 기존 시스템은 누더기처럼 얽혀 있다. 개발자들은 각자 옳은 말을 하지만, 결정은 나지 않는다. 이때 회사에 진짜로 필요한 사람은 코드를 잘 짜는 사람이 아니라, 결정을 내려주고 방향을 정해주는 사람이다.

그 사례의 주인공은 바로 이 공백을 정확히 채웠다. 그는 코드를 쓰지 않았지만, 쓸 필요 없는 코드를 줄였고, 잘못된 선택을 미리 막았으며, 팀이 앞으로 나아갈 수 있도록 정리해 주었다. 회사 입장에서는 그 어떤 개발자보다 “일을 잘하는 사람”처럼 보일 수밖에 없었다.

가장 가치 있는 코드는 ‘안 써도 된 코드’다

소프트웨어 개발에서 가장 큰 손실은 느린 타이핑이 아니라 잘못된 방향이다. 필요 없는 기능을 만드는 데 들어간 시간, 나중에 갈아엎어야 할 구조를 유지하느라 소모되는 에너지, 아무도 책임지지 않는 설계 결정들이 프로젝트를 망친다.

컨설턴트형 인력은 바로 이 지점을 건드린다. “이 기능은 지금 만들 필요가 없다”, “이 문제는 기술 문제가 아니라 조직 문제다”, “이 구조로 가면 반드시 다시 고치게 된다”는 말을 할 수 있는 사람은 코드 생산량으로는 측정되지 않지만, 결과에는 결정적인 영향을 미친다.

그 사람이 동시에 여러 회사에서 일할 수 있었던 이유도 여기에 있다. 각 회사는 하루 여덟 시간을 모두 가져간 것이 아니라, 결정이 막히는 순간에 필요한 ‘판단력’을 빌린 것이었다.

채용 공고는 문제를 말하지 못한다

만약 회사가 솔직하게 채용 공고를 쓸 수 있다면 이렇게 적혀야 할지도 모른다.

“우리는 무엇을 해야 할지 잘 모르겠습니다. 내부에 의견 충돌이 많고, 누군가 정리해 주길 원합니다.”

하지만 현실에서는 그럴 수 없으니, 프로그래머라는 이름으로 사람을 찾는다. 그 결과 코드 작성자를 뽑았다고 생각했지만, 사실은 컨설턴트가 더 잘 맞는 자리에 개발자를 앉혀두는 일이 반복된다.

이번 사례는 그 불일치가 극단적으로 드러난 사건일 뿐이다.

불편하지만 피할 수 없는 결론

이 이야기가 많은 개발자에게 불편하게 느껴지는 이유는 분명하다. 우리는 오랫동안 “코딩을 잘하면 인정받는다”고 믿어왔기 때문이다. 그러나 현실의 많은 조직에서 가장 희소한 자원은 코딩 능력이 아니라 문제 정의 능력, 판단력, 그리고 책임지고 결정하는 용기다.

이 사건은 사기극이라기보다, 회사들이 스스로 무엇이 필요한지 정확히 알지 못했다는 증거에 가깝다. 그리고 그 틈을 정확히 읽어낸 사람이, 코드를 한 줄도 쓰지 않고도 최고의 개발자로 평가받았다.

어처구니없어 보이지만, 이것이 지금의 소프트웨어 산업이 서 있는 위치다.

개요

목적

신고 기능은 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 커뮤니티의 의견을 수렴하여 지속적으로 개선됩니다.