AI는 더 많은 엔지니어링 규율이 필요하다. 적은 것이 아니다.

출처: Hacker News

몇 일 전 나는 제목이 ‘AI 열정가들은 시간에 쫓기고, AI 비평가들은 엔트로피와 경쟁한다’라는 글을 썼다.

나는 AI 관련 주제들인 AI mandato, 커뮤니케이션 규범, 코드 리뷰, AI 아트 등 깊이 다룰 준비된 메모가 있다. 최근 게시물에 많은 흥미로운 회신을 받았고, 이제 그 회신들을 처리한 뒤에야 다른 주제로 이동할 수 있을 것이다. 😉

흥미로운 회신은 두 가지 유형이 있었다: 첫 번째는 기술적 관점, 두 번째는 윤리적 관점이다. 각각 따로 답변하겠다. 먼저 기술적인 측면을 다루자, 쉽기 때문이다.

어떤 독자들이 나의 주장으로 코드 리뷰를 버리고 가장 나쁜 코드를 바로 생산에 넣으라고 말하고 있다고 생각했으며, 지금 바로, 1이라고 받아들인 것 같다.

그건 내가 하는 것이 아니다. 내가 생각하는 해야 할 일 도 아니다. 하지만 나는 그 예시를 무작위로 골라낸 게 아니라, 이유를 설명하겠다.

It’s easy to forget, but for most of 2025, the idea that AI‑generated code was slop and might always be slop was not only a reasonable position to hold, it was the default, mainstream position.2

그 질문은 지난 11월에 결정적으로 답변되었다. Opus 4.5가 출시된 이후로 AI는 일반 소프트웨어 엔지니어 수준의 코드를 생성할 수 있게 되었으며, 특히 일반적인 패턴에서는 그렇다. 훨씬 빠르고 저렴하게 말이다.

나는 1월 초에 책을 읽고 이 사실을 깨달았다. 그리고 2026년 초 몇 달 동안 주변 사람들이 비슷한 인식을 하고 있다는 것을 알게 되었다.

하지만 많은 이들이 그 전부터 예상하고 있었다.

대세는 Opus 4.5가 변화를 가져왔다고 하지만, 실제로는 전환점이었다. 에이전트 harnesses(LLM을 도구와 함께 루프에 감싸는 코드)가 2025년 중반에 실용화되었고, 그 이전에는 2024년 후반부터 존재했다. 툴 사용, 함수 호출, MCPs 등 2025년 한 해 동안 쌓인 이 흐름이 연말에 실용적인 범용 가용성으로 정점을 찍었다.

그것이 바로 열정가들이 지난해 우리에게 말하려고 했던 것이다. 단순히 “이게 올 것”이 아니라 “이게 예상보다 빠를 거야”라고 말이다.

결국 그들은 맞았다.

알고 보면, 나는 신뢰성에 초점을 둔 분야에서 온 사람이다. 내가 자신과 우리 팀에 줄 수 있는 칭찬은 우리가 새로운 현실을 적응하지 못하는 데 어려움을 겪지 않으며, 문제가 실제 존재하고 앞에 있을 때 매끄럽고 열의적으로 조정한다는 점이다. 이는 혐스러운 기술적 혼돈을 핥는 zelo와 그 뒤에 나오는 캠프파이어 이야기를 즐기는 태도 덕분이다.

The un‑compliment I will pay myself and my people is that we sometimes struggle to accept that progress is real, that the continued existence of bugs and edge cases does not diminish the fact that huge swaths of problem space do get more‑ or‑less solved over time, to the point they can be taken for granted by most people.3

코드가 완전히 쓰레기에서 “아 damn, 그거 나쁘지 않다”로 바뀐 속도는 내가 머릿속에 두고 있는 것이며, 열정가들은 harness 엔지니어링과 AI 검증이 실제 존재하며 이미 여기 있으며, 놀랍게도 빠르게 향상되고 있다고 말한다.

Holding out for “I’ll believe it when I see it” was forgivable the first time, but much less so the second time. This is what it feels like to be on the inside of an exponential change curve, turns out.4

여기서 멈추고 정확히 내가 생각하는 상황을 명확히 말하겠다. 그리고 내가 왜 흥분되는지, 그 이유는 무엇인지 설명하겠다.

당신은 내가 거기까지 갈 의무가 없다. 하지만 현재 “그건 X가 아니었어”, “항상 Y였어”, “미래는 xyzzy에게 속한다” 🤮 같은 과도한 주장들이 너무 많다. 나는 내 주장을 명확히, 조건부적이고 구체적이며 맥락에 맞는 것이라고 말하고 싶다.

2025년 한 해 동안 일어난 일은 코드 생산의 경제학이 뒤집혔다는 것이다. 코드를 생성하는 것이 매우 어렵고 시간‑소모적이며 비쌌던 것이 아니라, 거의 무료이고 즉시 가능하게 되었다. 코드 라인들은 소중히 여겨지고 재사용되고 관리되며 정교하게 관리되는 것이 아니라, 즉시 폐기되고 재생산될 수 있게 되었다.

컴퓨팅 역사의 대부분 동안 사람들은 소프트웨어를 이해하기 위해 코드를 작성하는 것이 주요 방법이었다. 숙련된 후에는 코드 읽기와 토론이 대부분의 길을 제공한다. (나는 소프트웨어 엔지니어가 항상 코드에 과도하게 의존하고, 관측을 통해 시스템을 senso‑making 하는 데 집중하지 않는다고 생각한다.)

Many great software engineers hold that true product of every (good) software engineering team has always been a shared understanding of the software we own. That it gets stored as cache state in our fragile little meat brains, frequently flushed to disk, deployed to production, committed to GitHub, but our minds are where meaning has always lived.

It’s something I love about this industry. But there’s no denying that minds have been a poor container for certain aspects of the software development model. We are forgetful, distractible, impatient. We are bad at spotting small details, we grow habituated to repetition. Worst of all, the model in our heads diverges massively and perpetually from the world our users interact with.

Anyway, SREs have never quite bought that explanation. To us, it’s clear that the true product of every (good) software engineering team is production.

Only prod is prod. Test in prod, or live a lie.

(This is all backstory. I am getting to the point, I promise.)

We issued our AI mandate last August.5. I had seen enough to know that this was happening, and it was time to do the responsible thing. Honeycomb is a devtools company, and people come to us to help with hard problems on the forefront of technology. I was all in on AI, but I can’t say I was super excited about it, in my heart of hearts.6