The Cline AI Assistant is Mesmerizing

2025-02-01

Cline AI 어시스턴트는 넋을 빼놓는다

어제 Cline AI assistant를 써 봤습니다. 그리고 다섯 시간 동안 최면에 걸린 듯 Cline이 버그를 고치는 모습만 넋 놓고 바라봤습니다.

전문 개발자로서 그 경험은 매혹적이면서도 두려웠습니다. AI가 이 정도 수준에 도달했다는 사실이 매혹적입니다. 같은 이유로 두렵기도 합니다. AI가 저보다 더 잘, 더 빠르게 코드를 작성하는 세상에서 제가 어떤 역할을 해야 할지 모르겠기 때문입니다.

이 분야에 뒤늦게 뛰어든 셈입니다. 다른 많은 개발자들이 이미 AI 도구를 워크플로에 훨씬 깊이 통합했다는 걸 알고 있지만, 아직 경험해 보지 못한 분들을 위해 제가 본 것을 공유하고 싶었습니다.

예전에도 AI 도구를 써 봤습니다

Cline이 처음 써 본 AI는 아닙니다.

지난 2년간 LLM 어시스턴트를 실험해 왔습니다. 특히 최근 6개월 동안은 모델이 신뢰할 수 있을 만큼 정확한 코드를 만들어 내는 수준에 도달하면서 훨씬 더 자주 사용했습니다.

검색 엔진으로는 Kagi를 쓰고 있습니다. Ultimate 요금제에는 주요 LLM을 무제한으로 쓸 수 있는 혜택이 포함되어 있습니다. 주로 Kagi Assistant 기능을 통해 LLM과 대화하는데, 사실 LLM과 채팅하는 웹 UI일 뿐입니다.

제가 쓰는 검색 엔진 Kagi는 주요 LLM을 모두 쓸 수 있는 깔끔한 웹 채팅 인터페이스를 제공합니다.

참고로 저는 Kagi 크라우드펀딩에 참여한 적이 있어 약간의 지분을 가지고 있는데, 그 구조를 정확히 이해하고 있지는 않습니다.

AI 도구를 쓰면 제가 기계가 된 기분입니다

최근에 느낀 문제는 AI 도구를 쓰면 제가 기계가 된 것 같은 기분이 든다는 것이었습니다. 편집기와 채팅 인터페이스 사이에서 코드를 멍하니 복사해 붙여 넣고, “작동하지 않습니다”라고 말한 뒤 오류 메시지를 붙여 넣고, 같은 과정을 네다섯 번 반복할 뿐이었습니다.

챗봇 LLM이 버그에 대해 계속 잘못된 수정안을 내놓고 전체 해결책을 보여 달라고 여러 번 재촉해야 하는 모습입니다.

분명 더 나은 도구가 있을 것이다

제가 하던 방식보다 AI를 통합하는 더 나은 방법이 분명 있을 거라고 생각했습니다.

“코드와 오류 메시지를 왔다 갔다 복사하는 사람”이라는 제 역할을 대신해 줄 도구가 필요했습니다.

1년 간격으로 Sourcegraph Cody를 두 번 써 봤는데, 두 번 다 실망스러웠습니다. 코드를 제자리에서 바로 수정해 주는 건 브라우저와 에디터 사이를 오가며 붙여 넣는 것보다 낫긴 했지만, Cody가 느리고 버그가 많아 결국 다시 웹 브라우저에 코드를 붙여 넣는 방식으로 돌아갔습니다.

최근 Cline에 대한 블로그 글 몇 개를 봤는데, 몇 가지 이유로 마음에 들었습니다:

코드가 오픈소스입니다.
제가 주로 쓰는 에디터인 VS Code와 연동됩니다.
로컬 파일을 직접 수정하고, 명령어를 실행하며, 명령어 출력을 보고 반복 작업할 수 있습니다.
원하면 로컬에서 호스팅하는 LLM을 사용할 수 있습니다.
다른 많은 AI 어시스턴트처럼 AI API 구매의 중간 다리 역할을 고집하지 않습니다.

단점은 Cline이 투자금을 태우는 것 외에는 뚜렷한 수익원이 없어 보인다는 점입니다. 그래서 지속 가능성은 불투명하지만, 지금 당장은 괜찮습니다.

어휘 착시: AI 어시스턴트를 시험하기에 완벽한 프로그램

최근 제 블로그에서 “어휘 착시(lexical illusion)”를 찾아주는 도구가 있으면 좋겠다고 생각했습니다. Matt Might가 그렇게 부르는 현상인데, 글에서 단어가 중복됐는데도 알아차리지 못하는 경우를 말합니다. 예를 들면 다음과 같습니다:

Many readers are not aware that the
the brain will automatically ignore
a second instance of the word “the”
when it starts a new line.

저는 블로그에서 이런 실수를 자주 하고, 교정 막바지나 발행 후에야 발견하곤 합니다.

Matt Might는 어휘 착시를 찾는 Perl 스크립트를 공유했지만, 기본적인 수준이었고 제 블로그의 Markdown 서식 문자 때문에 오탐이 많았습니다.

Kagi Assistant에 Markdown을 인식하는 Python 버전을 만들어 달라고 했지만, 계속 버그 있는 코드만 내놓았습니다.

이 문제가 Cline을 시험하기에 완벽한 사례라고 생각했습니다. 원하는 동작을 담은 테스트 케이스만 계속 보여주면, AI 어시스턴트가 테스트를 통과할 때까지 코드를 계속 수정할 수 있어야 하기 때문입니다.

빠르게 동작하는 도구를 만들고 싶어 Zig로 작성할 핑계이기도 했습니다. 많은 파일을 최대한 빠르게 훑어야 했고, 저는 Zig로 작업하는 걸 좋아합니다.

문제 정의하기

도구의 핵심 인터페이스는 간단했습니다. 파일 내용을 문자열(Zig에서는 [] const u8)로 받아 중복된 단어와 해당 줄 번호 목록을 반환하면 됩니다.

기본 인터페이스는 이렇게 생겼습니다:

pub const DupeWord = struct {
    line_number: u32,
    word: []const u8,
};

pub fn FindAdjacentDupes(allocator: std.mem.Allocator,
                         input: []const u8) !ArrayList(DupeWord) {
   // TODO: Implement this.
}

그리고 초기 단위 테스트는 다음과 같았습니다:

test "FindAdjacentDupes" {
    // Don't consider distinct words to be duplicates.
    try testFindDupes("cat dog", &[_]DupeWord{});

    // Find simple dupes.
    try testFindDupes("cat cat", &[_]DupeWord{
        .{ .line_number = 1, .word = "cat" },
    });
}

fn testFindDupes(input: []const u8, expected: []const DupeWord) !void {
    const allocator = testing.allocator;
    var result = try FindAdjacentDupes(allocator, input);
    defer {
        for (result.items) |item| {
            allocator.free(item.word);
        }
        result.deinit();
    }

    try testing.expectEqual(expected.len, result.items.len);

    for (expected, 0..) |expected_dupe, i| {
        try testing.expectEqual(expected_dupe.line_number, result.items[i].line_number);
        try testing.expect(std.mem.eql(u8, expected_dupe.word, result.items[i].word));
    }
}

Cline의 첫 결과

30초 정도, LLM 크레딧으로는 0.09달러 만에 Cline이 테스트를 통과시켰습니다:

Cline이 FindAdjacentDupes를 이렇게 업데이트했습니다:

pub fn FindAdjacentDupes(allocator: std.mem.Allocator, input: []const u8) !ArrayList(DupeWord) {
    var result = ArrayList(DupeWord).init(allocator);

    var it = std.mem.splitScalar(u8, input, ' ');
    var prev_word: ?[]const u8 = null;

    while (it.next()) |word| {
        if (prev_word) |prev| {
            if (std.mem.eql(u8, prev, word)) {
                const dupe_word = try allocator.dupe(u8, word);
                try result.append(DupeWord{
                    .line_number = 1,
                    .word = dupe_word,
                });
            }
        }
        prev_word = word;
    }

    return result;
}

Cline은 var를 const 대신 쓰거나 폐기된 API를 쓰는 등 몇 번 잘못된 방향으로 갔지만, 사람이 그러듯 오류 메시지를 보고 스스로 수정했습니다.

구현은 당연히 불완전했습니다. Markdown 서식이나 대문자, 문장 부호 등을 처리하지 못했습니다. 줄 번호가 1인 테스트 케이스만 보여줬기 때문에, 현재 구현은 줄 번호를 항상 1로 하드코딩해서 반환하고 있었습니다.

그때 완전히 빠져들었습니다

Cline이 초기 구현을 마친 뒤, 저는 계속 새로운 테스트 케이스를 작성했고 Cline이 제 테스트를 만족하도록 코드를 업데이트하는 모습을 지켜봤습니다.

그리고 그때 완전히 빠져들었습니다. 이렇게 소프트웨어를 개발할 수 있다는 사실에 너무 놀랐습니다. 원하는 것을 말하기만 하면 도구가 정확히 시키는 대로 해냈습니다.

이 글 맨 위에 올린 영상이 실제 작업 모습입니다:

결과

그날 남은 시간을 Cline과 함께 도구를 구현하는 데 썼습니다. 그리고 이제 중복 단어를 찾는 도구의 동작 버전을 갖게 되었습니다. 이름은 wordword입니다:

mtlynch/wordword on Codeberg

wordword로 제 블로그에서 어휘 착시 오류 일곱 건을 찾아냈습니다.

총비용은 OpenRouter 크레딧으로 6달러였고, 이는 Cline과 5시간 동안 쉬지 않고 작업한 금액입니다.

지금까지 배운 점

감독 없이 돌리면 비효율적이지만 워낙 싸서 상관없다

Cline에는 각 단계마다 계획을 승인하도록 하는 옵션이 있습니다. 5초마다 “승인” 버튼을 누르는 게 금방 지루해져서 파일 읽기, 파일 쓰기, 명령어 실행을 자동 승인하도록 설정했습니다.

신경을 끄고 지켜보니 Cline이 가끔 막다른 골목에 빠져 실패할 게 뻔한 전략을 반복 시도하기도 했습니다.

그럼에도 저는 대부분 Cline이 해결책에 도달하거나 20회 시도 제한에 걸릴 때까지 그냥 감독 없이 돌려두었습니다. 이런 막다른 시도는 API 크레딧을 소모하지만, 몇 센트 단위라 일일이 관리하는 것보다 그냥 몇 센트 낭비하는 편이 낫다고 생각했습니다.

Cline은 사용자를 무조건 신뢰하므로 말을 신중하게 해야 합니다

Cline이 가장 크게 헤맸던 때는 제가 실수로 잘못된 동작을 담은 테스트 케이스를 작성했을 때였습니다.

너무 서둘러 작성한 테스트 케이스입니다:

// Detect duplicates after a heading
try testFindDupes(
    \\## Foods
    \\
    \\These potatoes potatoes are the best!
, &[_]DupeWord{
    .{ .line_number = 1, .word = "potatoes" },
}

줄 번호를 3이어야 하는데 실수로 1이라고 썼습니다.

테스트를 통과시켜 달라고 하자 Cline은 명백히 3이어야 할 줄 번호를 어떻게든 1로 정당화하려고 애쓰며 한동안 헤맸습니다.

Cline에게 디버그 출력문을 넣으라고 하세요

LLM은 코드가 왜 그렇게 동작하는지 정보를 더 모으기보다 추측으로 해결책을 내놓는 경향이 있음을 알게 되었습니다.

Cline이 같은 버그를 맹목적으로 고치려는 시도를 반복하며 루프에 빠졌을 때, 작업을 잠시 멈추고 디버그 출력문을 넣어 코드에 대한 가정을 검증하라고 지시하면 도움이 되었습니다. Cline은 유용한 디버깅 출력을 추가했고, 해결책이 완성되었다고 선언하기 전에 모두 깔끔하게 제거하는 것도 잊지 않았습니다.

Kagi는 아마 나 때문에 손해를 보고 있을 것이다

이번이 처음으로 종량제 LLM API를 써 본 경험입니다. 토큰 비용에 대한 얘기를 들어본 적은 있지만, Kagi가 기본적으로 “비용은 신경 쓰지 마세요”라고 하기 때문에 감이 잘 오지 않았습니다.

Cline은 코딩 작업마다 크레딧이 얼마나 쌓였는지 진행 중에 친절하게 보여줍니다.

그래서 저는 확실히 Kagi의 월 25달러 무제한 요금제에서 이득을 보고 있습니다. Cline으로 5시간 동안 6달러를 썼는데, Cline은 토큰 소모를 최소화하려고 많은 노력을 합니다. 저는 Kagi Assistant를 매일 쓰고, 대화 중에 거대한 파일을 10번 이상 붙여 넣기도 합니다. 이제 비용을 알게 되니, 아마 하루에 5~10달러 정도의 API 비용을 Kagi에 부담시키고 있는 셈입니다.

참고할 만한 자료

대부분의 AI 관련 글은 내용이 얕거나 실질적인 교훈이 부족합니다. 가능성을 가늠하는 데 가장 유용했던 글은 다음과 같습니다:

“Everything I built with Claude Artifacts this week” by Simon Willison
“How I Use ‘AI’” by Nicholas Carlini
“How I program with LLMs” by David Crawshaw