AI를 쓰지 않는 개발을 취미로 부르지 말라 - 엔지니어링과 이름의 문제

TL;DR

• AI를 쓰지 않는 개발을 수공예적 취미로 분류하면 신뢰성과 유지보수성을 위해 직접 코드를 이해하려는 동기가 지워진다. purplesyringa는 결과를 중시하는 엔지니어와 과정만 즐기는 코더라는 이분법에 반대한다. 도구 선택만으로 엔지니어링 여부를 결정할 수 없다는 주장이다.
• 세심함과 주의, 정확성은 결과와 대립하는 가치가 아니다. 코드를 검토하고 기술 부채를 관리하는 일은 제품의 신뢰성을 만드는 과정이다. 다만 직접 작성했다고 완전한 정확성이 보장되는 것은 아니며 원문의 수치 표현도 실험 결과는 아니다.
• 저자는 AI-assisted coding과 AI-free software engineering이라는 명칭을 제안한다. 목표는 AI를 쓰지 않는 방식만 정답이라고 뒤집는 것이 아니라 그 방식도 전문적인 개발로 논의될 자리를 지키는 일이다. 명칭을 둘러싼 비판과 AI의 실제 성능 평가는 구분할 필요가 있다.

AI를 쓰는 사람은 결과를 중시하는 소프트웨어 엔지니어이고 쓰지 않는 사람은 코딩 과정을 즐기는 수공예 프로그래머라는 구분이 있다. purplesyringa는 자신이 그 구분에 들어맞지 않는다고 반박한다. 직접 코드를 작성하려는 이유가 취미의 순수성을 지키기 위해서가 아니라 낮은 수준의 동작까지 이해하고 신뢰할 수 있는 프로그램을 만들기 위해서이기 때문이다.

과정에 대한 관심이 결과의 품질을 만든다

신뢰성은 실행 화면이 한 번 잘 나오는 것보다 넓은 목표다. 유지보수가 가능한지, 읽을 수 있는 구조인지, 문서화되지 않은 동작에 의존하지 않는지까지 포함한다. 이런 성질을 확인하려면 설계와 코드의 세부를 오래 살펴야 할 때가 있다. 과정에 시간을 들이는 태도를 결과에 무관한 취향으로만 분류하면 그 시간이 품질에 기여하는 부분을 놓친다.

저자는 LLM이 자신과 코드 사이에 거리를 만들어 중요한 세부를 파악하기 어렵게 한다는 이유로 사용을 거부한다. 원문에 등장하는 99%와 100%는 정확성과 품질을 어디까지 추구하는지 강조하는 표현이다. 테스트·증명 도구의 정확도를 측정한 비교나 손으로 쓴 코드의 완전성을 입증한 수치는 아니다. 직접 작성 여부와 별개로 무엇을 이해하고 어떤 근거로 신뢰하는지가 엔지니어링의 문제로 남는다.

이름은 무엇을 기본값으로 보이게 하는가

수공예라는 말 자체가 나쁜 것은 아니다. 하지만 그 반대편을 소프트웨어 엔지니어라고 부르면 AI를 쓰지 않는 사람은 전문적인 엔지니어링 밖에 있는 듯한 인상을 줄 수 있다. 저자가 문제 삼는 것은 바로 이 대비다. AI 사용이 당연한 기본값이 되고 비사용은 별도 취향을 가진 예외로 설명되는 순간 도구의 효용을 따지는 논의가 정체성의 서열로 바뀔 수 있다.

과거 언어나 프레임워크 논쟁에서는 어느 선택이 더 안전하고 배우기 쉽고 유지하기 좋은지가 주된 논거였다. 이번 논쟁에서는 신뢰성에 시간을 쓰는 일이 진지한 개발인지 자체가 의심받는다고 저자는 느낀다. 이는 업계 전체의 태도를 조사한 통계가 아니라 담론의 변화를 읽는 개인적인 비판이다. 특정 도구를 선호한다는 사실과 다른 방식의 전문성을 부정하는 행동은 구분해야 한다.

엔지니어링을 구분하려면 더 풍부한 언어가 필요하다

원문은 Hillel Wayne이 다른 공학 분야에서 소프트웨어로 옮긴 사람들을 인터뷰한 프로젝트를 인용한다. 그 인터뷰의 결론은 소프트웨어 엔지니어링이 실제 엔지니어링이라는 쪽이었다. 동시에 소프트웨어를 쓰는 모든 활동이 같은 종류의 엔지니어링은 아니며 개발자·프로그래머·엔지니어를 구분할 어휘가 부족하다는 의견도 있었다. 전기를 다루는 모든 사람이 전기공학자는 아니지만 다른 역할도 중요하다는 비유다.

purplesyringa는 이 어휘 논의를 현재의 AI 담론에 비춰 해석한다. 다만 Wayne의 글이 바이브코더를 장인으로, AI를 쓰지 않는 사람을 엔지니어로 직접 분류한 것은 아니다. 원문 인터뷰는 AI 코딩 논쟁보다 앞선 글이며 소프트웨어 직무와 공학의 관계를 다룬다. 이를 현재의 명칭 문제에 연결한 해석은 purplesyringa에게 속한다.

배우는 수고를 불필요한 것으로 만들지 않는다

저자는 소프트웨어 공동체가 어려운 개념과 교육의 가치를 낮게 보는 태도도 원인일 수 있다고 의심한다. 타입 시스템이나 포인터처럼 이해에 시간이 필요한 주제를 실용적이지 않다고 밀어내고 즉시 복사해 쓸 해법만 찾는 습관에 대한 비판이다. 학습의 비용을 줄이는 도구와 학습 자체를 불필요하다고 취급하는 태도는 같지 않다. 이 설명 역시 모든 AI 사용자에게 적용되는 성격 판단으로 확대할 수는 없다.

원문은 용어의 재정의와 집단 배제의 역사적 수사를 강하게 끌어오지만 조직적인 심리전이라고 믿지는 않는다고 명시한다. 따라서 누군가 계획적으로 용어를 퍼뜨렸다는 증거가 있는 글로 읽으면 안 된다. 남는 질문은 자신이 쓰는 이름이 어떤 작업을 정상적인 전문 활동으로 인정하고 어떤 작업을 사소한 취미로 보이게 하는지다.

AI를 쓰지 않는 개발도 전문적인 선택으로 남긴다

저자가 제안한 명칭은 AI를 쓸 때 AI-assisted coding, 직접 작업할 때 AI-free software engineering이다. AI 사용 여부를 명시하면서 비사용 개발을 놀이처럼 보이게 할 수 있는 artisanal이라는 표현을 피하려는 선택이다. 이것이 모두가 따라야 할 표준 명칭으로 확정됐다는 뜻은 아니다. 중요한 목적은 AI를 쓰지 않는 개발이 공개 논의에서 전문적인 선택으로 남도록 하는 것이다.

결론도 AI를 피하는 방법만 유일하게 옳다고 주장하는 데 있지 않다. 코드를 설계하며 기울이는 주의, 함께 문제를 해결하는 과정, 사용 경험을 다듬는 노력을 더 잘 설명하자는 요구다. 도구의 속도만 비교할 때 보이지 않는 책임과 판단을 드러내자는 요구다. 그런 설명이 있어야 개발자가 도구를 사용하는 이유와 사용하지 않는 이유를 같은 수준에서 논의할 수 있다.

참고 자료

Don’t call yourself an artisanal programmer — purplesyringa, 2026년 9월 13일.

Are We Really Engineers? — Hillel Wayne. 인용된 인터뷰의 문맥과 현재 AI 논쟁에 대한 저자의 해석을 구분하기 위해 대조했다.