코드 잘 짜면 오히려 위험합니다

오늘 GeekNews 상위권에 올라온 세 편은 서로 다른 매체에서 나왔는데 이상하게 같은 방향을 가리킵니다. 코드를 쓰는 일이 싸지고 빨라지면, 남는 병목은 어디로 옮겨가는가. IEEE Spectrum은 그 답을 엔지니어의 역할에서 찾고, 파비앵 상글라르는 설정 파일 한 장에서 찾고, 포러너 벤처스는 아직 만들어지지 않은 인프라 계층에서 찾습니다. 세 글을 이어서 읽으면 2026년 개발 조직이 어디로 이동하고 있는지 윤곽이 잡힙니다.

프로덕트 엔지니어의 사고방식 – 태스크 수행자에서 문제 해결의 주체로

명세를 코드로 옮기는 일은 이미 AI의 영역

IEEE Spectrum에 실린 이 글의 출발점은 Claude Code를 만든 보리스 체르니의 표현입니다. “coding is basically solved.” 명확하게 쪼개진 명세를 정확한 코드로 옮기는 작업, 즉 전통적인 개발 조직에서 좋은 엔지니어의 기준이었던 그 능력이 하필 AI가 가장 잘하는 영역이 됐다는 것입니다.

글은 여기서 한 걸음 더 나갑니다. 엔지니어의 가치가 “태스크를 주면 구현한다”에만 있다면 AI와 정면으로 경쟁하게 되고, 그 경쟁의 승패는 이미 정해져 있다는 것입니다. 대신 희소해지는 것은 좋은 아이디어와 문제 정의입니다. 기업들이 프로덕트 엔지니어 채용을 빠르게 늘리면서도 사람을 못 구하는 이유가 코딩 실력이나 경력 부족이 아니라, 제품을 자기 문제처럼 바라보는 사고방식을 가진 엔지니어가 드물기 때문이라고 진단합니다.

조직이 평평해지면 판단까지 요구된다

중간관리 계층을 줄이는 기업이 늘면서 적은 인원이 더 많은 일을 처리하는 구조가 만들어졌습니다. 단순한 업무량 증가로 볼 수도 있지만, 글은 이를 기회로 읽습니다. 특정 기술 분야에서 가장 뛰어난 사람만큼이나 희소한 것은 조용히 비용을 발생시키는 문제를 발견해 경영진에게 알리거나 직접 해결하는 엔지니어라는 것입니다.

실천 방법도 구체적입니다. 팀의 결정을 수동적으로 따르는 대신 근거를 붙여 자기 의견을 말할 것. 새 프레임워크를 배우기보다 고객이 실제로 일하는 도메인을 이해할 것. 레딧 같은 곳에서 실제 종사자가 무엇에 불평하는지 관찰하면 아이디어의 출발점이 내부 회의실에서 고객의 현장으로 바뀝니다. 실험은 LaunchDarkly나 Optimizely 같은 도구로 사용자 5퍼센트에게만 먼저 적용하고 지표가 나빠지면 바로 되돌리는 식으로 싸고 안전하게 만들 것. 그리고 버튼 색상 취향으로 다투기 전에 무엇을 개선하려는지 목표부터 정할 것. 멋진 리디자인이라도 사용 시간이 떨어지면 실패이고, 보기 나쁜 버전이라도 매출을 올리면 목표 기준에서는 그쪽이 더 좋은 제품입니다.

글쓴이가 관리자로 일할 때 매주 스스로에게 던졌다는 질문이 인상적입니다. “지금 내가 할 수 있는 가장 영향력 있는 일은 무엇인가?” 답이 코드를 더 쓰는 것이었던 적은 거의 없었다고 합니다. 아무도 정의하지 못한 복잡한 문제를 이해하거나, 한 사람 머릿속에 있던 지식을 조직에 퍼뜨리거나, 필요한 사람들을 모아 미뤄온 결정을 내리게 하는 일이 훨씬 큰 영향을 만들었습니다. 회사의 분기 목표조차 모른다면 그것을 알아내는 것부터가 시작이라는 조언도 붙어 있습니다.

agent.md로 LLM 생성 코드의 품질 높이기

기능은 되는데 프로덕션에는 못 쓰던 코드

둠 엔진 해설로 유명한 파비앵 상글라르의 기록입니다. 2025년 중반 러스트 기반 mDNS 구현체 libadbmdns를 만들 때 LLM이 내놓은 코드는 컴파일조차 되지 않았습니다. 그런데 2026년 1월에는 복잡한 indexed-binary heap 클래스를 작성했고, 윈도우 IOCP 구현 때문에 발생한 polling 크레이트의 드문 버그까지 찾아냈습니다.

문제는 결과물이었습니다. 주석도 구조도 없는 스파게티 코드여서, 프로덕션 수준으로 정리하는 시간이 개발 속도 향상분을 그대로 상쇄했습니다. 그는 에이전트 IDE에서 매직 넘버를 쓰지 말라고, 의도를 설명하는 짧은 주석을 붙이라고, 함수 이름을 짧게 만들라고 반복해서 지시했습니다. 품질은 직접 작성한 수준에 가까워졌지만 세션이 새로 시작될 때마다 같은 말을 되풀이해야 했습니다.

규칙을 파일로 고정하다

해법은 코딩 하네스가 세션 시작 시 agent.md를 읽어 프롬프트에 주입한다는 점을 이용하는 것이었습니다. 프로젝트 루트에 agent.md를 두고 gemini.md와 claude.md를 심볼릭 링크로 연결하면 여러 환경에서 같은 규칙이 적용됩니다. 새 규칙이 필요하면 편집기를 열지 않고 에이전트에게 파일 업데이트를 요청합니다.

규칙은 짧고 직설적입니다. 반복되거나 의미 있는 매직 넘버는 상수나 enum으로 추출하되 자명한 일회성 값은 인라인으로 남긴다. HTTP 200 OK처럼 명세에서 온 값은 반복 여부와 무관하게 상수로 쓴다. 화살표 안티패턴을 피하려 이른 반환과 continue를 활용한다. 함수 이름은 30자 미만, boolean 매개변수 대신 enum, 한 줄짜리 if에도 항상 중괄호. 하위 수준 동작은 드라이버나 추상화 계층에 캡슐화하고, 각 계층은 바로 아래 인접 계층과만 통신한다. 멤버 가시성 변경은 중대한 설계 변화로 취급해 private을 public으로 바꾸기 전에 승인을 요청한다. 구현할 기능과 무관한 코드는 건드리지 않고 변경 줄 수를 최소화한다.

커밋 메시지는 7개 규칙을 따릅니다. 제목과 본문 사이 빈 줄, 제목 50자 이내 절대 상한 72자, 첫 글자 대문자, 끝에 마침표 금지, “If applied, this commit will”을 완성하는 명령형, 본문 72자 수동 줄바꿈, 그리고 방법이 아니라 무엇을 왜 바꿨는지 기록하기. 버그 수정 요청을 받으면 수정 코드부터 쓰지 않고 버그를 재현하는 실패 테스트를 먼저 작성하게 합니다.

한계도 분명히 적어뒀습니다. agent.md는 코드 검토를 없애는 만능책이 아니고, LLM은 계속 환각하므로 직접 검증해야 합니다. 다만 스타일 지적에 쓰던 시간이 줄어 아키텍처와 설계 검토에 집중할 수 있게 됐습니다. 문맥이 길어지면 모델이 시작과 끝에 더 주의를 기울이는 문맥 희석 현상 때문에, 기능마다 새 세션을 시작하거나 품질이 떨어질 때 “Reload agent.md”라고 요청해 지침을 다시 불러와야 합니다. 해커뉴스 댓글에서는 이 중 상당수를 린터로 강제해야 사람이 쓴 코드에도 같은 기준이 적용된다는 반론, 주석 작성을 오히려 금지한다는 반대 사례, AGENTS.md 대신 CODING_STANDARDS.md로 분리해 문맥 오염을 줄이자는 제안이 나왔습니다.

AI가 인간의 실행력을 확장하려면 무엇이 필요한가

자율성이 아니라 에이전시

포러너 벤처스가 The Human Bet과 후속 글 The Supply Side에서 던지는 질문은 방향이 다릅니다. 자동차가 이동 범위를, 인터넷이 정보 접근을, 스마트폰이 연결을 넓혔다면 AI가 줄이려는 거리는 사람이 생각하고 행동할 수 있는 능력 자체의 한계라는 것입니다.

그래서 중요한 질문은 AI가 얼마나 자율적으로 판단하느냐가 아니라 사람이 실제로 할 수 있는 일을 얼마나 늘려주느냐입니다. 많은 사람에게 부족한 것은 야망이나 지능이 아니라 의도와 실제 행동 사이의 실행 격차이고, 지능과 정보와 조언이 풍부해질수록 병목은 무엇을 아느냐에서 아는 것을 지속적으로 행동으로 바꾸는 능력으로 옮겨갑니다. 스스로 일정을 조정하는 캘린더는 사용자의 주도권을 뺏는 것이 아니라 일정 관리에 쓰던 인지 부하를 다른 일에 쓸 수 있게 돌려주는 것이라는 비유가 나옵니다.

공급 측을 세 계층으로 나누다

후속 글은 이런 제품이 실제로 가능해지려면 어떤 회사와 인프라가 새로 만들어져야 하는지를 별도 문제로 다룹니다. 하나의 통합된 AI 인프라 시장으로 묶는 대신 세 계층으로 쪼갭니다.

Capability Layer는 AI 네이티브 기업이 훨씬 작은 팀으로 제품을 만들고 고객을 상대한다는 전제에서 출발합니다. 기회는 단순 자동화가 아니라 작은 팀이 훨씬 큰 조직 수준의 역량을 갖게 하는 데 있습니다. 스트라이프와 쇼피파이가 인터넷 비즈니스를 지원했던 자리를 새 스택이 채우게 된다는 예측입니다.

Control Layer가 가장 흥미롭습니다. 기존 인터넷 인프라는 사람이 로그인하고 결제하고 계약하고 승인한다는 전제 위에 세워졌는데, 에이전트가 조사와 협상과 구매와 예약까지 수행하면서 이 전제가 무너지고 있습니다. 질문은 AI가 무엇을 할 수 있느냐에서 무엇을 할 권한이 있느냐로 이동합니다. 사용자 의도를 담는 신원 체계, 허용 범위를 정하는 권한 체계, 행동을 추적하는 감사 기록, 에이전트 간 결제 인프라가 필요해집니다. 목표는 AI를 더 똑똑하게 만드는 것이 아니라 자율적으로 행동하는 시스템을 신뢰할 수 있게 만드는 것입니다.

Model Layer는 예외 조항에 가깝습니다. 장기 가치는 기반 모델보다 사용자와 관계를 만드는 애플리케이션에 있다는 관점을 유지하되, 규제 산업이나 폐쇄 생태계처럼 범용 모델이 접근하기 어려운 독점 데이터가 있는 영역에서는 전문 모델이 지속 가능한 우위가 될 수 있다고 봅니다. 초기 성능 우위는 결국 따라잡히겠지만, 그 시간 동안 더 좋은 제품에서 더 많은 사용으로, 더 많은 도메인 데이터에서 더 깊은 고객 이해로 이어지는 순환을 쌓을 수 있다는 계산입니다.

관련 글

• 모든 피아노에 있는 이 버그
• 회계법인 50곳을 사버렸습니다
• AI 비용, 아직도 이렇게 내세요?
• Nobody Knows Who Built This Frontier Coding Model
• The Tiny Model That Embarrassed Frontier AI Labs

출처

1. GeekNews – 프로덕트 엔지니어의 사고방식
2. IEEE Spectrum – The Product Engineer Mindset
3. GeekNews – agent.md로 LLM 생성 코드의 품질 높이기
4. Fabien Sanglard – agent.md
5. GeekNews – AI가 인간의 실행력을 확장하려면 무엇이 필요한가
6. Forerunner Ventures – The Human Bet