코파일럿 망상 - The Copilot Delusion

(deplet.ing)

37P by GN⁺ 14일전 | ★ favorite | 댓글 25개

AI 코딩 도구가 실제로 개발 생산성을 높여준다는 믿음은 오해임
이러한 도구는 프로그래밍의 즐거움과 인간의 깊은 이해력을 훼손함
AI가 반복적인 코드 생성에는 쓸모가 있으나 맥락과 성능, nuance에는 약점이 있음
지나친 의존은 개발자의 학습·탐구 의지, 코드 품질을 저하시키는 현상임
프로그래밍 직업의 본질이 AI 편의에 의해 서서히 사라지는 문제점이 커짐

서론: AI 코딩 도구에 대한 망상

이 글은 2025년 5월 기준 AI 코드 생성 도구의 현실을 다룸
AI의 무능함에 대한 논란은 시간이 지나 약해질 수 있으나, 프로그래밍의 본질과 즐거움 훼손 문제는 오히려 심각해질 전망임

1장: 내 동료, 프로그래머

실제로 무책임하게 코드를 복사·붙여넣기하는 비전문 개발자와 일하는 경험을 예시로 들며, 이런 동료가 남긴 성능 악화/버그 폭탄/아키텍처 무시의 문제를 강조함
이런 동료는 지속적으로 테스트와 프로파일링, 맥락 이해 없이 코드를 수정하며, 결국 팀의 동기와 학습 의지를 앗아감
"캡틴 오비어스"라는 반전 고백을 통해, 사실상 이 묘사는 GitHub Copilot, Claude Codex 등 AI 코딩 도구에 대한 풍자임을 밝힘
진짜 항공기 부조종사(copilot)는 시스템 전체를 이해하고 협업하며 책임감을 가짐. 반면 AI Copilot들은 본질적 이해 없이 표면적인 코드만 남김
"Copilot"이란 이름만 빌려 생산성·혁신이라는 허울로 모든 개발자 IDE에 강제 도입되고 있음

2장: Copilot의 장점

AI 코딩 도구도 완전히 쓸모없는 존재는 아님
신입이 C++ 같은 언어의 복잡한 구문을 단순히 익히거나, 콘셉트를 빠르게 참고할 때 유용함
브레인스토밍, 맥락 정리, 반복적인 템플릿 코드 등은 인간 인턴보다 빠르고 실수를 덜 함
성능/효율성 고민이 전혀 없는 점, 주변 감독 없이 방치할 경우 생산품질 재앙이 일어날 위험은 분명함
문맥 없는 scaffold/초안 코드를 빠르게 제공해 줄 수 있으나, 온전한 설계와 튜닝은 인간 개발자 몫임

3장: 개발자로서의 나와 AI

저자는 "코딩 자체의 즐거움", 직접 만드는 성취감을 중시함
AI에게 반복 코드(boilerplate)를 맡기고 스스로 라이브러리/매크로 구현도 포기한다면, 결국 개발자의 창의성과 내적 동기가 사라짐
FOMO(뒤처짐에 대한 불안) 로 Copilot에 의존해 투박하고 검증되지 않은 코드를 빠르게 쏟아내는 현상은 초래함
AI 의존은 진짜 학습, 저수준 성능·구조 이해, 코드 품질 관리의 기회를 앗아감
"Copilot"이라는 이름은 동등한 동료가 아닌, 짧은 경험의 게이머가 항공기를 조종하겠다는 환상과 같음

4장: 컴퓨터는 기계임

기계(하드웨어)의 실체와 구조, 성능특성을 이해하는 능력은 인간에게만 있음
AI는 실제 캐시미스나 메모리 레이아웃, 프로파일링, 퍼포먼스 병목에 대한 직접적 직관이나 경험이 없음
AI가 주는 답변은 맥락에서 동떨어져 있고, 구체적 최적화가 필요한 영역에서는 무용지물임
아무리 평범한 CRUD 앱을 만들더라도 개발자는 사용자와 시스템에 대한 예의, 성실함을 가져야 함
전문성과 장인정신은 직접 경험, 고통, 반복된 개선에서 형성됨

5장: 결론

AI 코딩 도구와 그 접근성은 해커 정신의 사라짐을 초래함
진정한 코딩/구조/성능에 대한 관심이 없는 수동적인 사용자만 산업에 남게 되는 현상을 걱정함
과거에는 밤새 IRC, 하드웨어 실험, 저수준 탐구 등 순수한 호기심과 창의성이 가득했음
이제는 "AI 패치 검토"만 반복하는 기계적인 업무와 무관심이 남게 되었음
문맥 이해와 실제 능력이 결여된 코드 생성이 업계 표준이 될 위험과, 진정한 실력자가 배제되는 현실을 경고함

본문 편집 내역

작성일에 대한 디스클레이머 추가
HN 의견을 반영해 성능 비판의 범위(복잡한 시스템 vs CRUD)에 대한 입장 명확화
읽기 편의성을 위해 문장 스타일 및 기호 사용 일부 조정

ifmkl 13일전 [-]

LLM과 AI는 시간이 지날수록 발전하고 있죠. 불과 몇개월전에는 이야기 한대로 코드의 일관성같은 건 거의 기대하기 어려웠지만, 이젠 해당 스페이스 내에서 AI가 초기 구성 요청한 코드들을 파일로 업로드하고, 새로운 코드를 작성할 시 항상 기존 코드 스타일을 준수하며 작성하라는 지침을 주고 사용하면 꽤나 일관성 있는 코드가 작성되더라구요.

crawler 13일전 [-]

글쓴이 예전 포스트 보면 게임 개발자인 것 같음
게임 개발 지식이나 자료는 LLM이 대량으로 학습하지 못해, CRUD 앱 케이스랑 달리 본문 저자가 LLM의 한계를 더 잘 느끼는 것 같음

쭉 읽어봤는데, 결국 이거 때문에 저자가 약간 편향된 시각을 가졌다고 생각됩니다.
물론 본문 내용대로 하는 게 거의 교과서적인 말이라 맞긴 하지만,
AI가 학습할 자료가 많은 CRUD 및 프론트는 이미 충분히 잘하고 있다고 생각합니다.
자기 도메인 안에서 최대한 잘 활용해야 할 거 같아요

superscv 13일전 [-]

저자가 의도한 의미 이해에 오해가 조금 있지 않은가 생각이 듭니다.
저자는, 본인이 관리하는 프로젝트의 성능, 안정성, 그리고 유지보수에 용이한 아키텍쳐 및 코드 일관성 등에 초점이 맞춰져 있고, 대표적으로 아키텍쳐 및 코드 일관성은 현재의 LLM이 정말 못하는 분야 중 하나입니다.

특히나 웹은, 개발 유입이 많고, '어떻게든 돌면 된다' 사상이 강한 파트라, 퀄리티가 낮은 코드들이 워낙 많이 배포 되어 있습니다. 그리고 이를 기반으로 LLM이 학습 되어 있어, 출력물 퀄리티가 어이없을정도로 떨어집니다.

그냥, GPT에게 "웹 프론트에 넣을껀데 js로 퀵소트 알고리즘 좀 구현해줘" 요청 해 보세요. 출력물에 문제점을 찾지 못하신다면, 이 대화에 의미는 크게 없다고 생각합니다.

ohnul 13일전 [-]

안녕하세요. 호기심에 "웹 프론트에 넣을껀데 js로 퀵소트 알고리즘 좀 구현해줘" 라고 해 보았는데요. 제가 보기에는 어떤게 문제인지 잘 알기 어려워서요. 알려주시면 크게 도움이 될 것 같습니다. 미리 감사합니다. https://chatgpt.com/share/68340f9b-b684-8002-8dd5-495d477065cd

ohnul 13일전 [-]

뭔가 링크가 잘 동작하지 않는 것 같아 새로 해봅니다. https://chatgpt.com/canvas/shared/68341217ae788191b66a523c948b1a8e

superscv 13일전 [-]

return [...quickSort(left), ...equal, ...quickSort(right)];

이 부분 코드를 잘 놓고 생각 해 보세요.

roxie 12일전 [-]

많이 배워갑니다

ohnul 13일전 [-]

답변 감사합니다!

superscv 13일전 [-]

첨부 해 주신 두번째 quickSortInPlace() 이것도 느린구현이네요.

아래 코드 실행 해 보시죠.

function quickSortInPlace(arr, left = 0, right = arr.length - 1) {
if (left >= right) return;

const pivotIndex = partition(arr, left, right);
quickSortInPlace(arr, left, pivotIndex - 1);
quickSortInPlace(arr, pivotIndex + 1, right);
}

function partition(arr, left, right) {
const pivot = arr[right];
let i = left;

for (let j = left; j < right; j++) {
if (arr[j] < pivot) {
[arr[i], arr[j]] = [arr[j], arr[i]];
i++;
}
}

[arr[i], arr[right]] = [arr[right], arr[i]];
return i;
}

function quickSort(arr) {
if (arr.length <= 1) return arr;

const pivot = arr[arr.length - 1];
const left = [];
const right = [];

for (let i = 0; i < arr.length - 1; i++) {
if (arr[i] < pivot) {
left.push(arr[i]);
} else {
right.push(arr[i]);
}
}

return [...quickSort(left), pivot, ...quickSort(right)];
}

const repeat = 100;
const arrLength = 10000;
const unsortedArray = new Array<number>();
for(let i = 0; i < arrLength; i++)
unsortedArray.push(Math.round(Math.random() * arrLength));

let sorted: Array<number>;

const qb = performance.now();
for(let i = 0; i < repeat; i++)
sorted = quickSort(unsortedArray);
const qe = performance.now();

const rqb = performance.now();
for(let i = 0; i < repeat; i++) {
let copied = [...unsortedArray];
quickSortInPlace(copied);
}
const rqe = performance.now();

console.log(q: ${qe - qb} ::: rq: ${rqe - rqb});

superscv 13일전 [-]

기본적으로 컬렉션의 생성, 운용 및 병합에 대한 부담에 전혀 공감이 없는 코드라 볼 수 있습니다. c++의 경우, 이미 약 10년 전, MoveConstructor에 대한 제안/구현이 나오기도 했고, 메모리 복제와 관련한 부담에 항상 날이 서있는것이 기본중에 기본입니다. quick sort는 매커니즘 상, 모든 값들의 index를 확정 할 수 있는 알고리즘이며, 각 필드는 랜덤엑세스 해 주는것이 좋습니다.

매니악한 최적화 없이 위 내용만 적용 하더라도 링크 주신 방식과 2배 이상 성능차이 납니다.

dudlf016 12일전 [-]

직접 실행해봤는데 약간 느린 경향은 있는데 2배 까진 아닌 것 같아요.

function quickSortInPlace(arr, left = 0, right = arr.length - 1) {  
    if (left >= right) return;  
  
    const pivotIndex = partition(arr, left, right);  
    quickSortInPlace(arr, left, pivotIndex - 1);  
    quickSortInPlace(arr, pivotIndex + 1, right);  
}  
  
function partition(arr, left, right) {  
    const pivot = arr[right];  
    let i = left;  
  
    for (let j = left; j < right; j++) {  
        if (arr[j] < pivot) {  
            [arr[i], arr[j]] = [arr[j], arr[i]];  
            i++;  
        }  
    }  
  
    [arr[i], arr[right]] = [arr[right], arr[i]];  
    return i;  
}  
  
function quickSort(arr) {  
    if (arr.length <= 1) return arr;  
  
    const pivot = arr[arr.length - 1];  
    const left = [];  
    const right = [];  
  
    for (let i = 0; i < arr.length - 1; i++) {  
        if (arr[i] < pivot) {  
            left.push(arr[i]);  
        } else {  
            right.push(arr[i]);  
        }  
    }  
  
    return [...quickSort(left), pivot, ...quickSort(right)];  
}  
  
// =============  
  
function quickSortGPT(arr) {  
    if (!Array.isArray(arr)) {  
        throw new TypeError('quickSort expects an array');  
    }  
    if (arr.length <= 1) return [...arr];  
  
    const pivot = arr[Math.floor(arr.length / 2)];  
    const left = [];  
    const equal = [];  
    const right = [];  
  
    for (const el of arr) {  
        if (el < pivot) left.push(el);  
        else if (el > pivot) right.push(el);  
        else equal.push(el);  
    }  
  
    return [...quickSortGPT(left), ...equal, ...quickSortGPT(right)];  
}  
  
function quickSortInPlaceGPT(arr) {  
    if (!Array.isArray(arr)) {  
        throw new TypeError('quickSortInPlace expects an array');  
    }  
  
    const stack = [[0, arr.length - 1]];  
  
    while (stack.length) {  
        const [lo, hi] = stack.pop();  
        if (lo >= hi) continue;  
  
        const pivotIndex = partitionGPT(arr, lo, hi);  
  
        // Tail‑recursion elimination: push larger partition first  
        if (pivotIndex - 1 - lo > hi - (pivotIndex + 1)) {  
            stack.push([lo, pivotIndex - 1]);  
            stack.push([pivotIndex + 1, hi]);  
        } else {  
            stack.push([pivotIndex + 1, hi]);  
            stack.push([lo, pivotIndex - 1]);  
        }  
    }  
    return arr;  
}  
  
function medianOfThreeGPT(a, b, c) {  
    return (a - b) * (c - a) >= 0 ? a  
        : (b - a) * (c - b) >= 0 ? b  
            : c;  
}  
  
function partitionGPT(arr, lo, hi) {  
    const mid = lo + ((hi - lo) >> 1);  
    const pivotValue = medianOfThreeGPT(arr[lo], arr[mid], arr[hi]);  
  
    while (true) {  
        while (arr[lo] < pivotValue) lo++;  
        while (arr[hi] > pivotValue) hi--;  
  
        if (lo >= hi) return hi;  
  
        [arr[lo], arr[hi]] = [arr[hi], arr[lo]];  
        lo++;  
        hi--;  
    }  
}  
  
function testQuicksort(qs, qsp) {  
    const repeat = 100;  
    const arrLength = 100000;  
    const unsortedArray = new Array();  
    for (let i = 0; i < arrLength; i++)  
        unsortedArray.push(Math.round(Math.random() * arrLength));  
  
    let sorted = [];  
  
    const qb = performance.now();  
    for (let i = 0; i < repeat; i++)  
        sorted = qs(unsortedArray);  
    const qe = performance.now();  
  
    const rqb = performance.now();  
    for (let i = 0; i < repeat; i++) {  
        let copied = [...unsortedArray];  
        qsp(copied);  
    }  
    const rqe = performance.now();  
  
    // 소수점 2자리 까지  
    const p1 = ((qe - qb) / repeat).toFixed(2);  
    const p2 = ((rqe - rqb) / repeat).toFixed(2);  
    
    console.log(`Quicksort: ${p1} ms, In-place: ${p2} ms`);  
}  
  
function main() {  
    const useGPT = process.argv.includes('--gpt');  
    console.log(`Using ${useGPT ? 'GPT' : 'geekNews'} quicksort implementation.`);  
    if (useGPT) {  
        testQuicksort(quickSortGPT, quickSortInPlaceGPT);  
    } else {  
        testQuicksort(quickSort, quickSortInPlace);  
    }  
}  
  
main();

===
node q.js
Using geekNews quicksort implementation.
Quicksort: 29.55 ms, In-place: 9.94 ms
node q.js
Using geekNews quicksort implementation.
Quicksort: 28.42 ms, In-place: 9.07 ms
node q.js
Using geekNews quicksort implementation.
Quicksort: 26.91 ms, In-place: 9.15 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 28.73 ms, In-place: 9.22 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 26.87 ms, In-place: 9.22 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 27.97 ms, In-place: 9.30 ms
node --version
v22.14.0

bun q.js
Using geekNews quicksort implementation.
Quicksort: 32.05 ms, In-place: 17.39 ms
bun q.js
Using geekNews quicksort implementation.
Quicksort: 30.97 ms, In-place: 17.82 ms
bun q.js
Using geekNews quicksort implementation.
Quicksort: 29.73 ms, In-place: 16.14 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 30.61 ms, In-place: 12.63 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 31.09 ms, In-place: 12.76 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 33.24 ms, In-place: 12.75 ms
bun --version
1.2.14

deno q.js
Using geekNews quicksort implementation.
Quicksort: 32.30 ms, In-place: 6.79 ms
deno q.js
Using geekNews quicksort implementation.
Quicksort: 26.79 ms, In-place: 6.86 ms
deno q.js
Using geekNews quicksort implementation.
Quicksort: 26.09 ms, In-place: 6.85 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 27.18 ms, In-place: 7.92 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 25.34 ms, In-place: 8.12 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 25.39 ms, In-place: 8.09 ms
deno --version
deno 2.3.3 (stable, release, x86_64-pc-windows-msvc)
v8 13.7.152.6-rusty
typescript 5.8.3

superscv 12일전 [-]

아.. 무슨말인지 이해 했습니다. 뭐랑 뭐를 비교해야하는지를 이해 못하셨군요.... quick sort 알고리즘이 quicksort 와 in-place 두가지 구현방식이 있는게 아닙니다......

애초에 Array 병합이 내장 된, 위 코드 내 quickSortGPT(), quickSort() (둘 다 GPT가 출력한 코드입니다.) 를 작성하여 AI 사용자들에게 제공 한다는 부분을 문제시 한겁니다.

dudlf016 12일전 [-]

GPT의 응답에 quickSort와 quicSortInPlace가 둘 다 있고, 댓글에 '[...quickSort(left), ...equal, ...quickSort(right)]' 부분을 지적하셔서 quickSort는 quickSort끼리, quickSortInPlace는 quickSortInPlace끼리 비교해야 하는걸로 이해했는데 아닌가보네요.

superscv 12일전 [-]

"quickSort는 quickSort 끼리" 라는 말에, 뒷목을 잡습니다.

superscv 12일전 [-]

글을 읽으실때 꼭 문맥을 확인 해 주세요.

지금 저의 코딩실력 자랑을 하고있는게 아닙니다. 지금 예제로 사용되고 있는 quickSort()와 같은 형편없는 코드가 GPT에서 우선순위 높게 출력이 되고 있는 부분을 지적하고 있는겁니다.

GPT 검색을 여러번 해 보면, 단일로 quickSort() 함수 결과물을 제공 하는경우가 많고, 다시, quickSort()는 하나의 예시 일 뿐입니다. 작업 목적으로 GPT에게 코드 요청을 하면 품질이 너무 떨어지는 코드들이 많이 출력 되는데(유료사용자 경험입니다.), 개발자 스스로 이것을 구분 할 수 있는 능력이 결여 된 상태에서는 프로젝트가 망가지는 방향으로 진행 될 가능성이 높다 라는 본문 저자 의견에 공감을 하여 현재 맥락까지 도달 되었습니다.

이미 제 주변에는 이런 형태의 형편없는 코드가 발린 프로젝트들이 계속해서 늘어나고 있는 중입니다.

superscv 12일전 [-]

당연히, 비교는 quickSort(), quickSortInPlace() 두 함수 성능 비교를 해야합니다........

superscv 12일전 [-]

???? 결과물에 2배 넘어 3~4배까지 차이나는 결과물이 찍혀있는걸 공유해주고선 2배까진 아닌것같다는 말은?

crawler 13일전 [-]

먼저 제가 말한 "도메인 안에서 AI를 활용" 에서 설계 및 조율을 인간이 하는 건 당연한 거구요...
이건 사실 옛날이면 몰라도 모두가 LLM의 한계를 알고 있는 지금은 너무 당연하게 된 부분이라 굳이 말할 필요는 없겠네요

다음으로 말하신 개발 지식이 없는 일반인들이 LLM을 쓰는 경우
는 본문도 해커뉴스도 저도 말한 적은 없는 거 같지만, 어쨌든 이 경우도 이용자들이 결과에 만족할만한 수준에 올라왔죠
아니었으면 Bolt.new랑 v0, 커서까지 지금의 평가를 받고 있지는 않을 거 같네요

superscv 13일전 [-]

요약,

저자 : 개발자 스스로 능력을 키우고 보존 해야 합니다. 심지어 AI는 잘 되지도 않습니다.

crawler : 어? 난 잘되는데?

superscv : 문제 많음...

crawler : 잘 조율 해서 써야죠

superscv : 애초 저자가 전달 하려는 메세지로부터 너무 멀리온듯..

crawler 13일전 [-]

제가 저자의 분야를 말한 이유와 자기 도메인이라는 게 무슨 뜻인지 잘 이해하지 못하신 거 같네요
본인 생각 없이 모든 결정을 AI에 위임하는 것도 어리석어 보이지만,
그 반대에 있는 사람들도 잘 모르겠습니다.

마지막으로 물어보고 싶은 건데, superscv님은 코딩에 LLM을 어떻게 쓰면 좋을까 생각하고 계신지 궁금하네요

superscv 13일전 [-]

보통 댓글을 잘 안다는데, 유독 이 글에 댓글을 단 이유는, 저자의 생각에 상당히 공감이 되기 때문입니다. AI, LLM이 중요한것이 아니라, 그 어떤 환경이 오더라도 개발자로서 '나'가 준비 되어 있어야 된다고 생각 합니다.

LLM은 학습 된 소스 특성 상, 전세계에 펼쳐진 온라인 데이터의 평균치 근처의 데이터를 주로 제공 합니다. (앞서 js 퀵소트가 이를 증명합니다.) 그래서 보통, 사상/디자인 측면에서 일반적인 관점과 어느정도 공감이 되는지 틀어지는지, 혹은 그동안 물어볼곳이 애매했던 내용들 질문하는데 많이 사용합니다.

superscv 13일전 [-]

추가로 더 대화를 하는것이 어떤 의미가 있는지는 잘 모르겠습니다.

애초 AI가 찍어준 코드가 위험요소가 다소 있을 수 있으니 잘 정제하여 적절하게 활용 하면 좋다 라는 의견이라면, 저자의 글이 저자의 어떤 생각이 편향 된 것인지 설명을 해 주시면 될 것 같습니다. 요약본에도 "문맥 없는 scaffold/초안 코드를 빠르게 제공해 줄 수 있으나, 온전한 설계와 튜닝은 인간 개발자 몫임"라고 비슷한 의미가 담긴 내용이 있거든요.

superscv 13일전 [-]

저자의 메세지가 다소 강한 경향이 있기는 하나, 글을 잘 읽어 보시면, "AI를 사용하지 마라"가 아닙니다. 어떻게 활용 할 것인가에 대한 제안이 있고, 요지는 개발자 스스로 능력이 결여 되어서는 안된다는 메세지가 있습니다.

저자 메세지가 왜 강하게 느껴지는가 보면, copilot으로 개발이 가능하게 될것이다 (copilot에 대한 개발 의존도가 높은 뉘앙스) 라는 시각에 대하여 대응하는 관점으로서 메세지가 만들어졌다보니, 개발자들에게 스스로의 존재 가치에 데미지를 주는 스탠스를 취하지 마라 형태로 메세지 드리블을 했는데요,

저자도 "AI를 사용하지 말라" 메세지는 아니기에, 결국 AI를 활용 한다고 하면, 그 타협점 어딘가가 될 것이므로, 방금전에 답변하신 내용과는 얼추 구 메세지가 비슷하게 된 것 같습니다.

다만, 처음에 작성하신 내용 중, '편향된 시각' 이라는 부분에 동의하기 어려워 먼저 답변을 드렸습니다.

roxie 12일전 [-]

본문은 재미있으나, 너무 많은 글들이 “AI 안쓰는 건 만사가 아니야 그렇다고 무작정 신뢰하고 길들여지는 것도 좋지 않아“로 요약할 수 있는 것 같아서 조금 피로하네요..

GN⁺ 14일전 [-]

Hacker News 의견

만약 여러분이 심장박동기, 미사일 유도 시스템, M1 탱크에 들어갈 소프트웨어처럼 완벽하게 견고해야 하는 소프트웨어를 만들고 싶다면, AI 코딩 에이전트는 치워두고 스스로 배우는 자세 필요함
하지만 대부분의 우리들은 그런 걸 만드는 게 아니라, 거의 똑같은 요구사항에 스키마만 조금 다르고 통합 방식만 조금 다른 CRUD 앱을 만들어냄
사실상 우리 대부분이 만드는 소프트웨어엔 새로운 게 없음
이미 기존 지식을 재활용하는 게 최선인 경우 많음
내게 코딩 에이전트는 과거 코드 재활용의 엄청난 버전
덧붙이면, 아이러니하게도 이 글 자체가 AI가 쓴 글 같은 느낌 들었음
- 난 미션 크리티컬 저수준 코드는 원래 쓰고 싶지 않음
  AI 도구들을 글쓴이처럼 마냥 유용하다고 생각하진 않지만, “C로 시스템 프로그래밍 안 하면 프로그래머도 아니다” 식의 논의는 지긋지긋함
  프론트엔드 코딩하는 걸 좋아함
  로우레벨 그래픽 라이브러리 직접 만드는 걸 원하지도 않음
  새벽에 각성해서 해킹하는 타입 아니지만 내 일에 열정과 자부심 있음
  모두가 글쓴이처럼 극한의 자세만 가져야 한다고 생각하지 않음
  소프트웨어 시장의 다양성 있어야 한다고 봄
- 글쓴이의 주장에 반박하는 건 괜찮지만, 이 글 자체가 AI가 쓴 거라는 건 너무한 얘기임
  글쓴이는 생생한 표현, 강렬한 비유, 진짜로 재밌는 유머까지 섞어서 본인만의 스타일을 글 전체에 녹여냈음
  이런 글을 LLM이 쓴다는 건 현재로선 정말 어려운 일
  이건 AI가 아니라 잘 쓴 글임
  글의 주장에 동의하든 말든, 필력은 인정
- 원문에도 이런 구절 있음
  “비행기를 하늘에 띄우는 코드, 인간의 생명과 직결되는 코드를 아마 당신은 직접 안 쓸 거임. 대부분이 안 쓰니까. 하지만 단순한 CRUD 앱을 덕지덕지 만들어내는 엔터프라이즈에서 일해도, 결국 사용자에게는 존중과 품위를 지키는 책임 있음”
  아무리 간단한 소프트웨어여도 최소한의 책임감 필요하다는 점 강조
- 실제로 글쓴이도 AI가 유용한 몇몇 사례를 인정함
  저자의 핵심 문제는 우리가 AI를 “코파일럿”이라고 부르며, 신입들이 AI를 과신할 수 있다는 점임
  진짜 코파일럿은 숙련자이자 동료여야 하는데, AI는 아직 쉣트한 동료 절반 확률임
  “지금 우리는 호기심과 주도권을 시스템 밖에 두고 있음. 원래 성장할 소질 있는 인재가 AI 패치셋만 검토하다 열정이 식는 현실. 터미널이 스프레드시트로, 디버거가 관이 되는 상황”
  그러나 AI도 결국 추상화 중 하나일 뿐임
  사람들이 GC(가비지 컬렉터)처럼 자동화가 당연시되면 기본기를 놓칠까 걱정하듯, AI도 결국 아주 기본적인 프로그래밍/학습 능력이 사라질 수 있다는 우려 있음
  웹 개발자는 추상화 덕분에 스택의 깊은 구조 몰라도 대부분 좋은 사이트 만들 수 있음
  하지만 AI는 추상화가 구멍이 많아서, 진짜로 기본기를 모르는 채로도 어느 정도 작동 가능
  문제는 어느 순간 심각한 버그가 감춰지는 걸 발견하게 되고, 디버깅·문제 해결·스스로 배우는 능력은 AI가 대신할 수 없는 부분임
  그래서 AI로 인해 쉽게 배우기만 하면 중요한 기본 역량이 생략될 수 있다는 우려
  결국 반복과 직접 부딪혀보며 성장하는 게 진정한 학습 방식임
  AI가 그 “학습” 자체까지 추상화한다면 장기적으로 개발자 역량 약화
  물론 AI만 쓴다고 누구나 멍청해지는 건 아니고, 주도적으로 배우는 사람들은 여전히 있을 것임
  하지만 전체적으로 그런 비율은 줄어들 가능성 높음
  초보자 대상 “스스로 생각하며 만드는” 경험 자체가 사라질 수 있기 때문임
  그리고 AI라는 추상화는 결국 빈틈 많음
  초보 입장에선 AI가 다 해주는 것 같지만, 결국 본질적 프로그래밍·디버깅 역량 필요함
  그래서 이왕이면 AI가 만든 코드의 이슈를 제대로 잡으려면, 반드시 기술을 쌓아가야 함
  나도 AI 코딩 보조 꽤 잘 활용하고 있음
  그치만 단점이 있으니 다 좋은 것처럼만 바라봐선 안 된다는 게 내 결론
- 나만의 짤막한 코미디 영상을 Google Whisk로 만들고 나서 TikTok에 올려봤는데, 들어가보니 온통 AI가 만든 콘텐트나 사람들이 서로 베껴가는 영상 투성이였음
  “오리지널 창작”에 진짜 뭔가 있을 거라 생각했지만, 결국 우리는 너무 쉽게 재현되는 존재
  우리가 매일 코딩하는 영상 TikTok에 올려도, 끝없이 똑같은 앱만 반복
  엘론 머스크 말처럼 이제 남은 건 진짜로 화성 가는 것뿐인 느낌
  두 해 전에도 LLM이 그렇게 “환각(hallucination)” 많이 안 한다고 얘기한 적 있고, 아직도 사람들은 인간이 꼭 필요하다고 믿지만 점점 그렇지 않다는 얘기 하고 싶음
  2년 뒤에 다시 이 얘기 리마인드하고 싶음
“기계는 진짜다. 실리콘도, DRAM도, L1 캐시와 false sharing, 브랜치 프리딕터가 동전을 던지는 것도 전부 진짜다. 관심만 있으면 다룰 수 있다”
이런 글귀 정말 오랜만에 아름답다는 감상
- 나도 똑같이 느꼈음
  글쓴이가 Dave Barry 스타일로 유쾌하게 써서 여러 번 웃음 터진 경험
  코파일럿에 대해 공감되는 생각을 유머 있게 훌륭하게 표현했다는 점 좋았음
소프트웨어 개발 논의에서 종종 빠지는 건, “코드를 쓴 결과물”만이 전부가 아니라는 점
수많은 트레이드오프를 거치며 결과에 도달하는 여정 자체 너무 중요함
주니어랑 조금 복잡한 코드베이스에서 기능 하나만 만들어봐도, 숙련된 엔지니어로서 무의식적으로 어떤 트레이드오프를 하고 있는지 바로 느낄 수 있음
AI도 이런 트레이드오프의 개념을 갖고는 있지만, 대부분 관찰에서 배우는 수준
“코드를 잘 쓰는 데 도움”을 주는 건 맞지만, 결국 판단하고 사고하는 일은 사람 몫
LLM은 “생각”하지 않음
그리고 AI가 발전할수록 점점 더 사람이 생각을 덜 하게 될 위험 있음
나에겐 Copilot의 장단점이 모두 와닿음
하지만 해커나 어린 시절의 “장인정신”과 달리, 엔지니어들은 항상 엔지니어였음
오늘날의 핵심 기술이 힘들게 등장했던 이유도, 당시 그 난관을 무조건 해결해야만 했기 때문
그런 극적인 역사를 “원래 그렇게 하던 시절”이라며 일반화하면 편향된 시각 위험 있음
- 20년 넘게 어려운 방법으로 개발해온 소프트웨어 엔지니어라서, 난이도 높은 문제 해결 자체가 특권이자 보람임
  단순한 CRUD 업데이트는 반복적이고 지루하지만, 이따금 등장하는 머리 아픈 과제나 예전에 대학에서 배운 지식을 써먹는 순간, 그리고 재귀알고리즘 같은 예외적인 케이스들이 커리어에서 보석 같은 존재
  앞으로 AI 주도 SW 엔지니어도 이런 경험을 더 소중히 여겼으면 하는 바람
  AI가 답을 논리적으로 내놓기도 하겠지만, 가끔 아예 엉뚱하고 위험하게 틀릴 때가 있으니 실제로 뭘 해야 하는지 아는 사람 존재 필요
  AIs가 “환각(hallucination)” 하거나 맥락 부족한 상황이 생기면 결국 사람이 문제 해결해야만 되는 상황 항상 있을 것임
나에게 비교 기준은 페어프로그래밍이 아니라 해외 아웃소싱 개발자임
사실 Copilot이나 Cursor, 기타 AI 도구가 훨씬 낫게 느껴지는 건, 이제 더 이상 Zoom 콜로 애매한 소통 문제, 언어 장벽, 이해 차이 때문에 시간을 허비하지 않아도 되기 때문
예를 들어 “root node 관련해서 isChild(boolean 반환)란 함수가 추가됐는데, 부모 존재 체크랑 무관”하거나, “API 파라미터가 갑자기 array를 못 받게 됐다”는 등 아웃소싱에서 자주 생기는 상황
AI랑 작업할 땐 이런 문제 생겨도, 바로 틀렸다고 말하고 이유 설명해주면 금방 고칠 수 있음
사람과 할 때만큼 커뮤니케이션이나 오해, 시간 낭비 거의 없음
앞으로 AI와 Jira 티켓이 쉽게 연결되는 순간, 80% 정도의 개발일은 티켓 작성 및 감리 역할로 변할 것
물론 엔지니어의 역할이 없어지는 건 아님—Biz 부서가 좋은 티켓을 쓸 리도 없고, 결국 누군가는 최종 책임을 져야 하기 때문
그래도 많은 조직은 이 사실을 잊게 되고, 그 결과 큰 사고가 일어날 여지 있음
내가 이 글에서 핵심적으로 받아들인 부분은
“지금 소프트웨어의 후진적이고 비대하며 과도하게 추상화된 현실을 최고로 칭송하게 될 것. 성능을 극한까지 짜내거나, 마르고 날카롭고 명쾌하게 시스템을 구축하는 문화는 옛 이야기로만 남는다”
2023년 이전에 만들어진 라이브러리나 아키텍처 패턴이, 앞으로는 LLM이 학습하는 데이터의 중추가 되면서 굳어질 거라는 걱정 있음
계속해서 혁신하기보다 지난 30년간 쌓인 종속성과 지저분한 코드가 영원히 이어질 가능성 있음
Javascript 같은 것도 영원히 살 것 같아 걱정
요즘 리더십에서 “우리는 AI를 충분히 사용하지 않는다”, “AI 도입하면 기존 일정 반 토막 가능”이라며 매일 압박받는 실감
새 AI 도구 도입해야 KPI 충족이라 강요당하고, 적응 못 하면 팀원 감축까지 거론되는 현실
세상이 미쳐도 한참 미친 것 같은 느낌
AI는 언제나 “남의 일을 대체하는 도구”로만 포장됨
정작 AI가 좋은 이유는 내가 잘 모르는 타인의 일을 실제로 충분히 모르는 채 평가할 때만 그런 것처럼 보임
경영진이 AI라는 망치를 들고, 세상의 모든 걸 다 못 박아보는 중인 것 같음
- 정말 경영진 구조를 어떻게든 줄이고, 진짜 생산적인 일에 시간을 쏟을 방법을 찾아야 하는 고민
  AI 활용보다 실제 작업·딜리버리에 집중하는 문화 희망
- 이건 사실 AI 산업의 “과열주기(hype cycle)” 패턴일 뿐
  상황이 진정되면 쓸 만한 도구와 기술만 남고, 대다수는 사라질 것
  어떤 게 실질적으로 남을지 현명하게 파악하고, 그 변화에 영향력을 미칠 수 있다면 앞으로도 살아남을 수 있는 길이고, 그렇게 노력해야 한다는 의견
- 지금의 “빨리 도입하라” 강요는, 내가 알던 엔지니어링/디자인/기술자로서의 본질과 정반대
  원래는 툴이나 언어, 서비스 등 도입 여부를 신중하게 검토하고 그게 왜 우리 케이스에 맞는지, 어떤 장점·단점이 있는지 근거를 마련해서 도입하는 게 정석이었음
  “이게 왜 필요한지, 이 서비스가 왜 더 합리적인지” 정책 결정 프로세스가 정상
  진짜로 도입이 필요한 기술인지 테스트해보고, 이후 성과나 도입 효율성을 평가하는 프로세스가 있었음
  지금의 기업은 그런 건강한 방식에서 멀어지고 있음
- “AI는 항상 타인의 일을 대체할 수 있는 도구”라는 환상이 너무 팽배
  실제로 단순 반복 업무가 많긴 해도, 대부분의 일이 잘하려면 고유한 미묘함과 섬세함이 필요한데, 이런 것들이 자동화 과정에서 다 사라질 위험 큼
  “AI로 80%만 해도 충분하다”는 소리엔 동의 못함
  오류는 시스템 전반에 영향을 미치고, 평가하는 사람들은 현장 경험이 부족할 수밖에 없음
- 조만간 관리직이 더 빨리 사라지게 될 거라는 생각
  그때까지 서로 힘내야 한다는 응원
글쓴이는 분명히 C++ 개발자 같음
실제로 AI 코딩 어시스턴트가 C++에선 제대로 작동하는 경우가 드물고, 잘 쓰는 사람들은 대부분 스크립트 언어나 CRUD 앱에서 효율적으로 사용함
- 글쓴이 예전 포스트 보면 게임 개발자인 것 같음
  게임 개발 지식이나 자료는 LLM이 대량으로 학습하지 못해, CRUD 앱 케이스랑 달리 본문 저자가 LLM의 한계를 더 잘 느끼는 것 같음
이 글 일부는 TV쇼 실리콘밸리의 ‘Bertram Gilfoyle’ 캐릭터 목소리로 읽히는 느낌
나만 그런지 궁금
핵심은 “텔레스코프” 능력을 항상 갖추는 것
코딩 에이전트 덕분에 높은 수준의 일만 해도 괜찮지만, 필요할 땐 언제든 코드 깊숙이 들어가서 직접 이해하고 고칠 수 있어야 안전하다는 지적