생성 중지, 사고 시작

발행: 3일 전 (2026년 2월 9일 오전 06:58 GMT+9)

18 분 소요

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content you want converted to Korean? Once I have that, I’ll keep the source link exactly as you specified and preserve all formatting, markdown, and code blocks. Thank you!

Source:

Stop generating, start thinking

by Sophie Koonin
2026 년 2월 8일

태그: ai, engineering

제 경력 전반에 걸쳐 저는 업계의 새로운 동향을 따라잡는 데 꽤 성공했다고 생각합니다. 컨퍼런스에 참석하고, 사양을 작성하는 매우 똑똑한 사람들을 (나중에 친해지면서) 팔로우하고, 동료들에게 CSS나 JS의 흥미로운 새로운 기능을 슬랙에 공유하는 사람 중 한 명이었죠. 최신 Chrome만 신경 쓰면 되는 내부 도구에서 일하고, 아직 실험 단계인 프로덕션 앱에서 앵커 포지셔닝을 가지고 노는 즐거움!

그렇기에 제가 뒤처질 위험을 느끼고—뭔가 놓치고 있다는 느낌이 드는—것은 매우 불안합니다. 제가 원하지 않지만, 많은 사람들이 LLM‑생성 코드를 너무 과하게 사용하고 있어 머리가 복잡해집니다.

저는 Copilot—그리고 최근에는 Claude—를 일종의 “매운 자동완성” 및 가끔 디버깅 도우미로 사용해 왔지만, 뭔가 약간이라도 영리하게 하려고 하면 완전히 엉망이 됩니다. 제가 잘못 사용하고 있다는 점은 알지만, 프롬프트를 다듬는 데 드는 시간보다 제가 직접 코드를 짜는 것이 더 효율적인데도 불구하고 그 가치를 정당화하기가 어렵습니다.

충분히 많은 컨텍스트를 제공해야 하지만—너무 많이 주면 과부하가 걸립니다. AI 어시스턴트의 겉보기에 연약한 자존심을 “당신은 분산 시스템 전문가다”라고 말하며 매끄럽게 달래는 긴 프롬프트를 만들어야 합니다. 마치 불안하고 평범한 소프트웨어 개발자에게 말하듯이 말이죠.

아니면 이 모든 과정을 거치기 전에 코드를 바로 짜는 편이 더 빠를 수도 있습니다.

점점 더 많은 사람들이 코드를 직접 작성하는 대신 생성하고 있는 모습을 보면서, 엔지니어들이 우리 직업의 좋은 부분(코딩)을 포기하고 지루한 부분(리뷰)만 남기는 것이 왜 이렇게 쉬운지 궁금합니다.

아마도 사람들은 컴퓨터에게 역할극 지시를 내리는 것을 즐기는 걸지도 모릅니다; 잘 모르겠어요. 하지만 사람들이 기꺼이—그리고 자랑스럽게—자신들의 제품에 생성 코드를 가득 채우는 것은 위험하다고 생각합니다.

제가 이 문제에 대해 우려를 표명했을 때 마주한 몇 가지 논점을 공유합니다.

Reference: “Spicy autocomplete” – The Guardian

“이것은 우리 시대의 산업혁명이다! 마치 기계화가 다시 일어난 것 같다.”

산업혁명과의 유사점

산업혁명은 기후 변화에 큰 영향을 미쳤다—OER Project analysis 를 참고하라.
오늘날 AI 데이터 센터의 에너지 소비는 엄청나다; IEA report on AI‑driven demand 가 그 규모를 강조한다.

이 전력의 전부가 화석 연료에서 나오는 것은 아니어서 19세기 모델보다 개선된 점이다.
그럼에도 불구하고 우리는 사소한 결과물에 막대한 자원을 낭비하고 있다—예를 들어 메타가 신속히 차단한 바이럴 “새우 예수” 이미지 같은 경우다. Business Insider story 를 확인하라.

패스트패션 비유

기계화는 상품을 더 저렴하고 접근하기 쉽게 만들었지만, 동시에 품질 경쟁을 최저 수준으로 몰아냈다. 현대의 사례는 다음과 같다:

SHEIN – 커피 한 잔 값보다 저렴한, 매우 인화성이 높은 바지를 구매할 수 있다.
저임금과 열악한 노동권을 가진 개발도상국으로 공장을 이전해 이익을 극대화한다.

생성된 코드는 패스트패션과 매우 흡사하다:

처음 보면 괜찮아 보이지만, 자세히 살펴보면 금방 부서진다.
기존 디자인을 그대로 베끼는 경우가 많으며, 이는 Sunday Post on high‑street copycats 에서 보고되었다.
환경에 미치는 영향도 상당하다.

핵심 차이점: 결정론 vs 비결정론

기계화는 인간의 노력을 기계가 같은 작업을 신뢰성 있게 수행하도록 대체했다. 보일러플레이트 코드를 생성하는 코덱모드나 스크립트가 좋은 예이며, 문제가 발생하면 사람이 기계를 점검하고 원인을 진단할 수 있다.
LLM 출력은 비결정적이며 내부 작동 방식이 불투명하다. 매번 다른 결과를 내고 종종 환각(hallucination)까지 포함하는 기계화된 프로세스는 실용성이 거의 없다.

요약하면, AI의 부상은 산업혁명의 규모와 자원 요구와 유사하지만, 그 비결정론적 특성과 환경 발자국은 별도의 과제로 남아 있어 해결이 필요하다.

“LLM은 어셈블리와 마찬가지로 고수준 프로그래밍 언어가 어셈블리와 같았던 것처럼 또 다른 추상화 레이어일 뿐이다.”

자바나 고(Go)를 쓰면 어셈블리를 배울 필요가 없다는 점은 사실이다. 내가 어셈블리와 비슷하게 느끼는 가장 가까운 것은 뜨개질 패턴이다.

우리가 소프트웨어를 작성하는 방식은 우리가 생각해야 하는 것에 따라 진화해 왔다(선택한 언어에 따라 다름):

런타임이 가비지 컬렉션이나 메모리 할당을 대신해 주기 때문에 이를 생각할 필요가 없다.
여전히 기존 시스템 전체 맥락에서 건축적으로 타당한 효율적인 코드를 작성해야 한다.
내가 만드는 소프트웨어가 핵심 경로에 어떤 영향을 미칠지 고려하고 유지보수성 vs. 배포 속도를 따져야 한다.
웹을 위한 개발에서는 브라우저 호환성, 접근성, 보안, 성능을 생각해야 한다.

LLM이 가장 큰 피해를 주는 영역

내가 본 가장 큰 문제는 엔지니어들이 소프트웨어 개발에 들어가야 할 생각을 외주화한다는 점이다. LLM은 시스템 아키텍처에 대해 추론할 수 없다—그들은 생각하지 않는다. 우리가 생각을 멈추고 모델도 생각하지 않으면, 아무도 생각하지 않는 상황이 된다. 아무도 사려 깊게 설계하지 않은 소프트웨어에서 좋은 결과가 나오길 기대할 수 없다.

호라이즌 스캔들 이후—버그가 있는 우체국 소프트웨어 때문에 무고한 우체국 직원들이 감옥에 가게 된 사건—우리는 그 어느 때보다 소프트웨어에 대해 생각해야 한다. 소프트웨어에 책임감이 필요하다.

그 버그로 인해 13명이 자살했다는 직접적인 결과가 있었다.

우리의 형편없는 코드가 문제다

“하지만 오늘날 인간 개발자들은 접근성이 없고, 성능이 떨어지며, 자바스크립트에 의존하는 코드를 작성한다! 차이가 뭐야?”

정확히 그렇다. LLM은 (우리의 명시적 동의 없이) 우리 형편없는 코드 전체를 학습하고, 이것이 출력되어야 할 것이라고 학습시켰다. 결과적으로 그들은:

인간의 실수를 반복한다.
같은 결함이 있는 출력물에 다시 재학습되어, 일명 인간‑지네(epistemology) 라는 피드백 루프를 만든다(매기 애플턴의 AI Dark Forest 기사 참조).

우리는 인간으로서 충분히 좋은 코드를 쓰지 못했기에, 같은 것을 더 빨리 쓰는 무언가를 가질 자격이 없다.

그리고 우리가 지금까지 잘 해왔다고 생각한다면, 그렇지 않다:

보조 기술 사용자는 접근성이 떨어지는 인터페이스에 자주 부딪힌다.
인터넷 연결이 열악한 지역(또는 영국 어느 도시에서든 모바일 데이터를 사용하는 사람)에서는 성능 문제가 발생한다.
인종 차별은 얼굴 인식 소프트웨어와 심지어 손 건조기 같은 일상 기기에서도 여전히 존재한다.
우체국 직원들은 버그가 있는 소프트웨어의 직접적인 피해를 겪었다.

우리는 학습하고, 개선하고, 더 나은 소프트웨어를 만들 대신, 생각하지 않는 알고리즘에 우리의 실수를 외주화하고 있다.

네 눈은 좋고, 두 눈은 나쁘다

제시카 로즈와 에다 에렌은 FFConf 2024에서 AI 코딩 어시스턴트가 우리의 기술을 잃게 만드는 위험에 대해 훌륭한 강연을 했다. 그 중 한 슬라이드가 눈에 띈다:

Slide from FFConf 2024: “Code you did not write is code you do not understand. You cannot maintain code you do not understand.”

핵심 포인트

인간이 만든 PR을 검토할 때는 동료가 코드를 고민했기 때문에 일정 수준의 신뢰가 있다.
오픈소스 유지보수자는 이미 LLM이 만든 저품질 PR이 급증하는 현상을 목격하고 있다.
LLM이 코드를 생성했더라도, 기여자는 자신이 커밋한 내용에 대해 책임을 진다.
리뷰어 역시 책임을 지므로, 변경 사항에 두 쌍의 눈이 여전히 존재한다.

“단일 눈” 워크플로우 위험

일부 기업은 Claude와 같은 도구를 사용해 슬랙 채팅에서 바로 PR을 생성한다. 워크플로우는 다음과 같다:

개발자가 Claude에게 변경을 요청한다.
Claude가 코드를 자동 생성하고 PR을 연다.
리뷰어가…

roves the PR.

리뷰어가 변경 사항을 보는 유일한 사람이라면, 우리는 한 쌍의 눈을 잃은 것이며 팀 내 공유 컨텍스트가 감소하게 됩니다.

PR을 검토하는 것은 단순히 버그를 잡는 것이 아니라, 코드와 변경 이유에 대한 이해를 공유하는 것입니다. PR을 완전히 건너뛰고 메인 브랜치에 직접 커밋하는 팀은 엔지니어가 끊임없이 페어링하여 공유 컨텍스트를 유지할 때만 규모를 확장해 작업할 수 있습니다.

Takeaways

LLMs는 인간의 추론을 대체하는 것이 아니라 도구입니다.
책임은 코드를 작성하고, 검토하고, 배포하는 인간에게 있어야 합니다.
다중 검토 단계(“four eyes” 원칙)를 유지하여 공유된 이해를 보존하십시오.
지금 더 나은 코딩 관행에 투자하십시오; 그렇지 않으면 현재 실수의 전파를 가속화할 뿐입니다.

나는 반‑진보가 아니라 반‑과대광고다

나는 LLM에 반대하는 것이 아니라는 점을 분명히 하고 싶다. 내가 문제 삼는 것은 이를 인공지능이라고 부르는 브랜딩이다—그것은 지능이 아니라 단순히 기계 학습의 한 형태일 뿐이다. “생성 AI”는 본질적으로 사람들이 지나치게 기대하는 매우 정교한 마코프 체인에 불과하다.

생성 AI를 빠른 프로토타입 제작에 사용하는 것은 전혀 문제되지 않는다. 와이어프레임이나 인터랙티브 데모를 급히 만들 필요가 있을 때는 충분히 의미가 있다. 내가 우려하는 것은 사람들이 “코드에 분위기를 입혀” 바로 프로덕션 수준의 소프트웨어를 만들 수 있다고 생각하거나, 코드 뒤에 있는 실제 사고 과정을 넘겨줄 수 있다고 믿는 경우이다.

Mikayla Maki는 에이전트와 작업할 때 특히 좋은 관점을 제시했다: 인간을 루프에 남겨두고, 신뢰하지 못하는 외부 기여자처럼 다루라. 이미 수행 방법을 알고 있는 작업에만 에이전트를 사용하라, 왜냐하면 그 작업을 이해하고 있는 것이 필수이기 때문이다.
— On Programming with Agents (Zed.dev)

나는 내 스파이시 자동완성을 계속 사용할 것이지만, 당분간 내 사고를 외주 주지는 않을 것이다.

생성은 멈추라.
이해를 시작하라.
우리가 처음 이 일을 즐겼던 이유를 기억하라.