주고받는 이메일 데이터에 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여 개의 회사에 동시에 취업해 일했다는 이야기가 화제가 되었다. 놀라운 점은 그가 여러 회사를 속였다는 사실이 아니라, 오히려 각 회사에서 “일을 정말 잘한다”는 평가를 받았다는 점이었다. 더 어처구니없는 사실은, 그가 실제로는 코드를 거의, 혹은 전혀 작성하지 않았다는 것이다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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