자신감 넘치는 수프

발행: (2026년 3월 19일 AM 12:11 GMT+9)
9 분 소요
원문: Dev.to

Source: Dev.to

It is 2:14 AM. Production is degraded. You are hunting for the edge of the fire, but there is no edge. Forty minutes have passed. The code compiles, the tests are green, the deployment was flawless, yet the system is failing under load. You stare at a file trying to find where the payment logic ends and the user logic begins, but everything is touching everything. The auth module reaches into the billing service, and the billing service mutates concerns it should never have touched. There are no boundaries, no interfaces, no quiet spaces where one system hands off to another and walks away—just a wall of perfectly indented, completely entangled syntax. The codebase is confident. The codebase is everywhere. You are drowning in it.

좋은 엔지니어링

좋은 엔지니어링은 타이핑 속도가 아니다.
어떤 전투를 먼저 포기할지 아는 것이다.
기능을 만들기 전에 실패 모드를 스케치한다.
구현 전에 인터페이스를 작성하고, 일부러 느슨하게 유지한다—그것이 해야 할 일을 모른다는 이유가 아니라, 피벗, 부하 급증, 데이터베이스 잠금 등을 예상하기 때문이다.
경계를 분리함으로써 시스템은 예측 가능하게 실패한다: 결제 서비스는 죽고, 인증 서비스는 계속 실행되며, 화재는 당신이 화재 전에 만든 이음새에서 멈춘다.

Designing for Failure

이것은 설계된 손실이다. 실제 압력을 견디기 위해 더 큰 시스템이 살아남을 수 있도록 작고 통제된 실패를 계획한다. 초기 손실이 실제로 지속되는 무언가를 만들기 위한 충분한 정보를 모으는 방법이기 때문에 일부러 일을 미완성으로 남겨둔다. 사용자가 솔루션과 어떻게 상호작용할지 알 수 없기 때문에 느슨하게 유지한다. 인간은 당신이 모델링하지 않은 맥락을 가지고 인터페이스에 접근한다; 그들은 당신이 설계하지 않은 경로를 찾아내고 그것을 끌어당겨 무언가가 부서질 때까지 계속한다. 유연하지 못한 시스템은 부서진다. 이음새는 깔끔한 코드의 지표가 아니라—당신 자신의 가정만큼이나—계획된 후퇴 지점이다.

아마추어 vs. 전략적 싸움

소셜 미디어에 가서 아마추어들이 싸우는 모습을 보세요. 잽도 없고, 페인트도 없으며, 상대를 읽는 것도 없습니다. 두 사람이 첫 종부터 가능한 한 강하고 빠르게 펀치를 날립니다. 이것은 공격성처럼 보이고, 자신감처럼 보입니다. 두 번째 라운드가 되면 두 파이터 모두 힘이 빠지고, 팔이 내려가며, 이미 모든 것을 소진했기 때문에 피할 수 있었던 펀치를 맞게 됩니다. 아마추어는 정보를 얻기 위해 펀치를 날리지 않습니다; 끝내기 위해 펀치를 날립니다. 모든 스윙은 강타이며, 각 강타는 미래에 대한 투표—3라운드에 대한, 전환점에 대한, 싸움이 바뀌고 남은 것이 필요해지는 순간에 대한 투표입니다.

LLM은 아마추어처럼 싸웁니다—똑똑하지 않아서가 아니라, 보존할 체력이 없기 때문입니다. 모델에게는 3라운드가 없습니다; 티켓, 응답, 그리고 컨텍스트 창이 닫히기 전에 모든 공백을 구문으로 채워야 할 필요만 있습니다. 잽을 날릴 수도 없고, 인터페이스를 의도적으로 불명확하게 할 수도 없으며, 시점을 닫는 것을 저항할 수도 없습니다. 불완전함은 모델에게 실패처럼 느껴지므로, 즉시, 완전한 자신감으로 마무리합니다. 이것은 버그가 아니라 도구의 본질입니다.

AI가 엔지니어링에 미치는 영향

Dave Farley는 150명의 개발자를 조사했으며 AI가 그들을 55 % 더 빠르게 만든다는 결과를 얻었습니다. 데이터는 실제이지만, 우리는 무엇이 빨라졌는지를 오해하고 있습니다. 그것은 완료 속도가 55 % 빨라진 것입니다. 기계는 접촉 순간 전체 기능을 결정화합니다—코드처럼 배열된 토큰은 마치 얼굴 형태로 빛을 포착하지만 그 아래의 두개골을 이해하지 못하는 사진과 같습니다. 철근도 없고, 하중을 지탱하는 논리도 없습니다. 포화도가 낮은 용액에서는 분자들이 자유롭게 움직이며, 분리하고, 변형하고, 가공할 수 있습니다. 반면에 Vibe 코딩은 과포화 상태이며, 엔터키를 누르는 순간 모든 것이 서로 결합합니다. 피벗을 위한 틈새가 남아 있지 않고, 사전에 설계된 실패 모드도 없으며, 모델링을 놓친 사용자를 위한 여지도 없습니다.

Farley는 AI가 엔지니어링에 뛰어나다는 것을 증명한 것이 아니라, AI가 첫 번째 전투에서 승리하는 데 뛰어나다는 것을 증명했습니다. 느슨하게 유지되어야 했던 작업—예정된 후퇴 지점, 아키텍처 경계—가 55 % 더 빨리 건너뛰어졌습니다.

Conclusion

아직도 새벽 2시 14분이다. 당신은 여전히 불꽃의 가장자리를 찾고 있다. 아키텍처는 설계된 것이 아니라 단지 출력된 것일 뿐이다. 기계가 강타를 날렸고, PR이 승인되었으며, 스프린트‑속도 차트는 위쪽 오른쪽을 가리켰다. 리더십은 쾌감을 얻었고, 엔지니어는 어둠을 얻었다.

몇 시간 후에 스탠드‑업이 있다. 당신은 무엇을 말할지 모른다, 왜냐하면 아직도 무엇에 직면하고 있는지 모르기 때문이다. 수프는 어디에나 있다. 그 안 어딘가에서 무언가가 타오르고 있다. 어딘가에서, 6개월 전, 프롬프트가 승리했다. 그리고 지금, 어둠 속에서, 당신은 지고 있다.

참고

우리는 AI를 사용한 150명의 개발자를 조사했습니다 (실제로 일어나고 있는 일) — Dave Farley

0 조회
Back to Blog

관련 글

더 보기 »

준비가 되기 전에 나타나기

나의 여정 나는 아무도 눈치채기 전에 시스템 디자인에 대해 글을 올린 지 몇 달이 되었다. 전략도, 청중도 없었고—그저 내가 파악하고 있던 것들의 진행 중인 목록일 뿐이었다.

HTML popover 속성 — 완전 심층 분석

popover 속성은 현대적인 내장 방식으로 경량 오버레이를 만들 수 있게 해 줍니다. 예를 들어: - dropdowns - menus - tooltips - context panels - mini dialogs It is nat...