# 2026년에 왜 코드를 작성하는가
> Clean Markdown view of GeekNews topic #31411. Use the original source for factual precision when an external source URL is present.
## Metadata
- GeekNews HTML: [https://news.hada.io/topic?id=31411](https://news.hada.io/topic?id=31411)
- GeekNews Markdown: [https://news.hada.io/topic/31411.md](https://news.hada.io/topic/31411.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2026-07-14T07:04:47+09:00
- Updated: 2026-07-14T07:04:47+09:00
- Original source: [softwaredoug.com](https://softwaredoug.com/blog/2026/07/09/write-code)
- Points: 2
- Comments: 2
## Topic Body
- 소프트웨어 엔지니어의 역할은 코드 생산을 넘어 **소프트웨어 팩토리**를 구축·유지하는 일로 확장됐지만, 시스템을 이해하고 개선하려면 여전히 직접 코드를 다룰 필요가 있음
- 프롬프트, `AGENTS.md`, 지식 베이스로 에이전트를 안내하고 테스트, 린팅, 타입 시스템, 평가로 결과를 보호하면 **성능이 낮은 모델**도 충분히 쓸 만한 변경을 만들 수 있음
- 직접 코딩하면 영어를 거치지 않고 **실행 환경에서 사고**할 수 있어, 수동적인 코드 검토만으로 놓치기 쉬운 취약성·약한 테스트·불필요한 예외를 체감하게 됨
- 에이전트는 컴파일러보다 새로 합류한 인턴에 가까워 기존 코드와 부정확한 요구를 보수적으로 따르며, 인간의 일회성 실수까지 **래핑과 간접 계층**으로 확대할 수 있음
- 인간이 접근법을 직접 시험해 패턴을 정립하고 에이전트가 이를 반복하게 해야 **소유감과 판단력**을 유지하면서 자동화의 생산성을 활용할 수 있음
---
### 에이전트가 일하는 소프트웨어 팩토리
- 소프트웨어 엔지니어는 소프트웨어뿐 아니라 누구나 변경을 프롬프트로 요청하고 즉시 배포할 수 있게 하는 **조립 라인**도 유지함
- 프롬프트, 스킬, `AGENTS.md`, 지식 베이스를 통해 에이전트가 성공할 수 있는 인프라를 선제적으로 구성함
- 테스트, 린팅, 타입 시스템, 평가, 다른 AI를 활용한 **자동 평가**로 결과를 사후에 보호함
- 충분한 제약과 최신 컨텍스트를 제공하면 지능이 낮은 모델도 경로를 벗어나지 않고 쓸 만한 변경을 만들 수 있어, 사람이 코드를 읽거나 직접 작성할 필요가 없어 보일 수 있음
- 그러나 Fable 수준의 지능을 가진 에이전트가 있더라도 직접 코딩은 영어라는 중간 계층 없이 **실행 환경에서 직접 사고**하게 해줌
- 에이전트가 만든 diff와 패치를 수동적으로 읽는 것만으로는 시스템 아키텍처와 깊이 연결되기 어려움
- 코드를 직접 다루면 그 위에 기능을 추가할 때 무엇이 깨지는지 체감할 수 있음
- 코드를 정리하고 여러 예외가 붙지 않는 일관된 아키텍처 원칙을 문서화하면 소프트웨어 팩토리도 더 안정적으로 작동함
- 디버깅 과정에서 테스트 전략의 약점을 찾아 고치면 새로운 종류의 버그 전체를 차단할 수 있음
- 직접 코딩만이 소프트웨어를 이해하는 유일한 방법은 아니며, [자화된 바늘과 흔들리지 않는 손](https://xkcd.com/378/)처럼 극단적인 수작업을 고집할 필요도 없음
- 실제 코드의 대부분을 AI가 생성하더라도 직접 코딩은 여전히 유용한 도구로 남음
### 직접 코딩으로 지키는 사고력과 소유감
- 코드 읽기와 승인만 담당하는 [역방향 켄타우로스](https://doctorow.medium.com/https-pluralistic-net-2025-09-11-vulgar-thatcherism-there-is-an-alternative-f1428b42a8fd) 역할에 머물면 집중력과 소유감이 떨어지고, 저품질 코드가 검토를 통과하기 쉬우며 세밀한 조정도 어려워짐
- 세부 사항에 주의를 기울이지 않으면 취약성이 누적되고, 장기적으로는 [저품질 코드가 에이전트에도 악영향](https://arxiv.org/abs/2603.24755)을 줌
- 인간이 직접 접근법을 시험한 뒤 에이전트가 정립된 패턴을 반복하게 하면 결과에 계속 참여하고 소유할 수 있음
- 영어는 계산을 정밀하게 나타내기에는 **명세가 부족한 언어**임
- 알고리듬 작업에서는 실행 가능한 단계로 구상하고 사고할 필요가 있음
- 상황에 따라 설계 공간이 큰 저수준 언어나 계산 환경이 더 제한된 고수준 언어를 선택해 필요한 정밀도를 조절할 수 있음
- 코딩 에이전트를 컴파일러처럼 취급하면 형편없이 작성된 코드도 배포해도 된다는 태도로 이어질 수 있음
- 에이전트는 컴파일러보다 **새로 합류한 인턴**에 가까움
- 불완전하고 품질이 낮을 수 있는 기존 코드를 읽고, 부정확한 변경 설명을 바탕으로 새로운 변경을 생성함
- 인간은 인턴 집단에 사고와 취향을 그대로 넘길 수 없으므로 소비자로 머물지 않고 직접 관여해야 함
- 에이전트는 코드를 발견했을 때보다 더 나은 상태로 남기는 **보이스카우트 규칙**을 자발적으로 따르기 어렵고, 이를 맡기는 일도 부담스러움
- 현재 변경을 최대한 안전하게 만드는 쪽으로 치우쳐 기존 결정을 보수적으로 보존함
- 한 코드베이스에서 인간이 무심코 일부 상태에 브라우저 로컬 스토리지를 사용하자, 나머지 상태는 백엔드 데이터베이스에 저장하는데도 에이전트가 그 결정을 유지하려고 래핑과 간접 계층을 추가해 코드 줄 수가 약 3배로 늘어남
- 이런 보수성은 인간이 내린 일회성의 잘못된 결정을 증폭할 수 있음
- 코드를 직접 삭제하고 탐색하는 과정은 영어로만 지시할 때보다 더 나은 아키텍처에 도달하도록 도움
- 코드에 관심을 기울일수록 사고력과 저작자로서의 감각, 소프트웨어 팩토리를 이끄는 능력이 강화됨
- 소프트웨어 팩토리에서는 아키텍처 패턴부터 알고리듬과 성능까지 **세부 사항**이 중요함
- 에이전트는 평가·측정·보호 장치의 필요성을 높였고, 개인 프로젝트에서도 CI를 사후 작업이 아니라 초기에 추가하도록 유도함
- 이로써 소프트웨어 개발 상태는 크게 개선됐지만, 모든 조립 라인에는 여전히 약점이 남아 있음
- 자동차 공장에서도 조립 라인을 분해하거나, 내연기관의 세부 사항을 파고들어 10% 개선하거나, 현장 문제를 조기에 발견하지 못한 이유를 찾기 위해 하루 종일 브레이크 패드 테스트를 관찰해야 할 때가 있음
- 소프트웨어에서도 세부 사항과 전체 구조를 연결하려면 무엇을 직접 다룰 수 있는지에 **자의적인 경계**를 그어서는 안 됨
## Comments
### Comment 61776
- Author: choijaekyu
- Created: 2026-07-14T11:23:13+09:00
- Points: 1
토큰값이 없어서요ㅠ
### Comment 61751
- Author: neo
- Created: 2026-07-14T07:04:48+09:00
- Points: 1
###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48861923)
- 코드를 작성할 수 없다면 검토도 할 수 없음이 자명해 보이지만, Claude가 작성하고 Codex가 검토하면 된다는 사람과 회사가 있음. 그런데도 어셈블리나 컴파일된 바이너리가 아니라 Python, Java 같은 고급 언어로 결과를 요구하는 이유는 결국 **사람이 코드를 읽을 수 있어야 하기 때문**임
개발자가 코드를 읽고 디버깅하고 추론하길 바라면서, 정작 그 능력을 기르는 훈련은 제공하지 않으려는 태도가 모순적임
- Claude에게 어셈블리를 작성시키지 않는 이유는 **어셈블리로 CRUD 앱을 만든 학습 자료**가 거의 없기 때문임. LLM이 일자리를 잠식하는 건 싫지만, 최첨단 모델이 인터넷에서 수없이 반복되고 문서화된 작업을 잘하는 것도 현실이며 지난 수십 년간 소프트웨어 개발의 상당 부분이 정형화된 CRUD 앱 생산이었던 것도 사실임
모든 창작을 LLM에 맡기면서 업계가 계속 발전할 수 있을지는 의문임
- 코드를 쓰는 행위는 곧 **생각하는 행위**이므로, 코드 작성을 멈추면 사고도 멈추게 됨. 더 높은 수준에서 사고한다고 해도 그 고수준 설계마저 LLM이 더 잘하게 될 테니 지금의 우위는 일시적일 뿐임
- 결국 **인지 방식의 차이**로 보임. 어떤 사람은 영어 설명보다 코드가 더 정확하고 읽기 쉬워서 숙련된 개발자라면 훑어보는 것만으로 동작을 파악하지만, 다른 사람은 코드를 읽기 어렵고 자연어를 더 편하게 여김
어느 쪽이 낫다는 뜻은 아니며, 세부 사항을 덜 중시하는 사람이 세상을 이끌 수도 있고 문제마다 필요한 세밀함의 수준이 다를 수도 있음
- Casey Muratori와 Demetri Spanos가 영상에서 다뤘던 것 같은데, 바이너리를 피하는 이유는 LLM에 대한 신뢰보다 **기계마다 다른 기계어와 오프셋**, 문맥 해석의 어려움에 가까움. Ghidra가 역컴파일한 C 코드와 개발자가 작성한 C 소스의 이해도 차이처럼, 고급 언어는 코드의 의도를 담을 수 있음
컴파일러는 LLM이 실제로 컴파일되고 실행되는 코드를 작성하도록 돕지만, 기계어를 직접 출력하면 아예 실행되지 않을 가능성이 큼. 물론 코드를 전혀 작성할 수 없다면 검토는 훨씬 더 어려움
- Claude가 어셈블리나 바이너리를 직접 출력해야 한다고 실제로 주장하는 사람도 있음. 다만 여러 기계용 어셈블리로 컴파일할 수 있는 **고급 언어보다 이식성이 낮을 가능성**이 큼
- “프로그램을 생성할 만큼 포괄적이고 정확한 프로젝트 명세를 업계에서는 무엇이라 부르는가? **코드**라고 부른다” — [CommitStrip]()
제대로 작성했다면 코드의 핵심은 기반이 되는 비즈니스 로직을 가장 단순하게 표현해야 함. 지원 계층까지 모두 검토할 필요는 없을 수 있지만, 코드를 읽지 않았다면 비즈니스 로직도 완전히 안다고 보기 어려움
- [원문 링크]()
- 이 주제에 관해 쓴 다른 글에서도 **명세보다 코드 사용**을 권했음. 에이전트에게 코드로 지시하거나 따라야 할 예제를 만들어 줘도 괜찮음
[https://softwaredoug.com/blog/2026/07/04/write-code-not-specs]()
- 이래서 **Lisp**가 필요함. 먼저 비즈니스 로직의 기본 요소를 언어의 기본 요소로 삼는 프로그래밍 언어를 만들고, 그 새 언어로 비즈니스가 하는 일을 기술하는 간단한 프로그램을 작성하면 됨
- 중요한 질문은 누가 수동 코드 작성에 돈을 지불할 것인가임. 고객은 코드의 작성이나 생성 자체가 아니라 **문제 해결**에 돈을 내므로, 가장 적은 비용과 소란으로 해결하는 쪽이 사업을 가져가며 AI 도구가 일정을 압축해 주는 이점은 무시하기 어려움
1990년대부터 이 업계에 있었지만 뛰어나지 않은 개발자가 평범한 결과물을 만드는 일은 늘 많았음. 수작업 코드를 지나치게 낭만화하지만 실제 코드베이스는 시간이 지나며 유지보수하기 어려워지고 버그투성이가 되기 쉬웠으며, 엉성하게 수행된 프로젝트도 전혀 새로운 현상이 아님
- 오히려 **적은 양의 코드를 직접 작성하는 편**이 생산성을 높인다고 봄. 하루를 들여 아키텍처를 수동으로 재구성하면 토큰 비용 수천 달러와 몇 주간의 골칫거리를 아낄 수 있음
지금은 양손이 묶인 채 소프트웨어 공장을 지으려는 꼴임
- 평범한 개발자들이 이제는 **평범한 결과물을 10배 더 많이** 생산하고 있음
- 의료·항공·원자력처럼 **소프트웨어 품질이 중요하고 규제되는 산업**에서는 수동 코드 작성에 계속 비용을 지불하길 바람. 다만 이 시장은 비교적 작음
- 집중하고 이해하려면 에이전트를 멀리서 지켜보며 코드를 수동적으로 읽는 데 그치지 않고 직접 코드를 체험해야 함. 결국 **자신의 정신 모형을 훈련해야 한다**는 뜻임
코딩할 때는 무의식이 “이게 맞는 느낌이다” 같은 판단을 많이 내리는데, 이는 반복과 깊은 집중으로만 길러지며 코드 검토나 문서 읽기만으로는 한계가 있음. 이렇게 형성된 정신 모형이 있으면 운영 장애의 오류 메시지만 보고도 원인을 즉시 짚을 수 있지만, 생성된 코드에서는 느린 의식적 사고로 오래 찾아야 함
LLM이 정말 유용하려면 코드 유지보수 전체를 맡아 외부 라이브러리처럼 작동한다고 가정할 수 있어야 하며, 그렇지 않으면 계속 문제가 생길 수밖에 없음
- 인간에게도 이미 이런 분리를 시도했고, 너무 형편없이 작동해서 **상아탑 아키텍트**라는 멸칭까지 생겼음. 실제 시스템에서는 구현 불가능한 이론적 설계가 나오고, 구현 팀이나 LLM은 아키텍처를 우회하며, 아키텍트와 구현자가 엇갈린 논쟁을 벌이는 동안 개발 속도가 크게 느려짐
- 관측 가능성 분야에서는 동적 실행 동작만으로 원인을 찾기 어렵다면 시스템을 더 투명하고 **관측 가능하게 만들어야 한다**고 볼 것임. 사람이 이동하거나 떠날 수 있으므로 뛰어난 개인의 정신 모형에 의존해서는 안 된다는 원칙은 원래부터 유효했다는 입장임
아직 어느 쪽이 맞는지는 모르겠고 더 알아보는 중임
- 2026년에도 **AI 생성 코드는 여전히 형편없음**. Fable이든 맞춤형 Pi/opencode LeetCode 하네스든 결과물이 끔찍하며, 자기 코드와 AI 코드의 품질 차이를 구분하지 못한다면 좋지 않은 소식이 있음
- 내 코드는 AI보다 못했거나 지금도 못하지만 적어도 돈은 받으니, 그 나쁜 소식이 별로 중요하지 않음
- 에이전트가 보이스카우트 규칙을 따르도록 프로파일 실행, 코드 커버리지 확인, 비판적 검토, 보고서와 후속 작업 작성을 **규칙에 명시**해 두었음. 함께 일한 사람의 90%보다 오늘날 최첨단 LLM이 이런 규칙을 훨씬 잘 따르는데, 이것이 나쁘다는 뜻인지 의문임
- 에이전트는 현재 변경을 최대한 안전하게 만드는 쪽으로 치우침. 커피도 마시기 전 무심코 브라우저 로컬 저장소를 쓰라고 했더니, 나머지 상태는 모두 백엔드 데이터베이스에 있는데도 그 잘못된 결정을 보존하려고 래핑과 간접 계층을 추가해 **코드 줄 수를 거의 세 배**로 늘린 적이 있음
에이전트는 보수적이어서 인간의 일회성 실수를 증폭할 수 있음. 이를 해결하는 방법은 많고 사람마다 사고방식도 다르므로 코드를 읽지 않는 방식과 직접 읽고 쓰는 방식 모두 가능하지만, LLM을 거치지 않는 코드의 정밀함에서 얻는 이점도 큼
- 내가 코드를 직접 작성해야 하는 이유는 그렇지 않으면 LLM이 지나치게 많은 코드를 만들기 때문임. 문제를 완전히 이해하고 일반화해야 “Hello World”에 **1만 줄과 추상화 계층 5개**가 붙는 일을 막을 수 있음
LLM은 토큰 예측기이므로 해결할 문제가 많을수록 출력하는 코드 토큰도 늘어나는 경향이 있음
- LLM은 전체를 종합적으로 생각하기보다 코드를 **방어적으로 감싸는 방식**을 좋아해 비대해지기 쉬움. 반면 인간 개발자는 작업하면서 주변 코드도 정리하는 보이스카우트 규칙을 따를 수 있음
- Peter Naur는 수십 년 전에 프로그래밍이 소스 코드·명세·문서를 기계적으로 생산하는 일이 아니라, 시스템 각 부분이 현실 문제와 어떻게 맞물리는지에 관한 깊은 **정신적 이론을 구축하는 인간 활동**이라고 설명했음. 프로그래밍의 진짜 산출물은 개발자들이 공유하는 정신 모형임
해결할 문제를 가진 당사자는 인간이므로 문제를 이해하지 않으면 LLM이 실제 요구와 무관한 문제를 푸는 X/Y 문제가 생길 수 있음. LLM은 라이브러리나 고급 언어처럼 핵심이 아닌 요소를 더 잘 추상화하지만, 문제의 핵심은 여전히 형식적으로 표현해야 함
제약을 하나씩 추가하며 원하는 결과에 도달하는 바이브 코딩도 결국 느슨하고 비형식적인 프로그래밍임. LLM에는 문제 주변부를 맡기고 핵심은 직접 작성하고 이해하는 편이 나음
- 업무의 99%가 C#이지만 LLM 덕분에 아무것도 하지 않고도 늘 바라던 **저수준 프로그래머**라고 자칭할 수 있게 됨
- 회사의 다른 모듈과 비슷하게 K8s에서 실행할 프로젝트를 구성해 달라고 했더니, LLM이 **Hello World 구현의 단위 테스트**까지 작성해 버렸음
- 최신 미국 모델에 클라이언트 측 정보를 표시하는 사소한 작업을 맡겼더니, 초기 핸드셰이크에서 서버가 클라이언트로 정보를 전달하도록 양쪽 코드를 모두 수정했고 실제로 작동하기까지 했음. 하지만 그 정보는 이미 클라이언트에 있었으므로 **클라이언트 코드 한 줄만 바꾸면 되는 작업**이었음
겉으로는 요청을 완벽히 해결했지만 불필요하고 엉성한 코드였음. 종량제 토큰을 판매하는 회사는 문제를 대충 해결하면서도 토큰을 최대한 소비하는 루브 골드버그식 해법을 만들 경제적 유인이 있으며, 생성할 때뿐 아니라 새 버그가 섞인 거대한 코드를 나중에 다룰 때도 토큰을 더 쓰게 됨
복사·붙여넣기 코드를 비웃던 사람들이 이제 엉성하게 붙인 코드에는 열광하는 모습이 우스움
- 2022년 11월 ChatGPT 3.5부터 지금까지의 발전을 보면 **4년 뒤에도 코드를 검토하고 있을지** 의문임. AI 극단론자가 아니더라도 현재 속도가 유지된다면 5~10년 뒤에는 오늘날 형태의 소프트웨어 엔지니어링과 개발이 사라질 가능성이 큼
인간에게는 UI 설계 정도만 남고, 나머지는 모두 추상화되어 AI가 실제 작업을 처리할 수도 있음
- 소원을 한 번에 실현하는 기계라면 단일 요청은 쉽게 처리하지만, 소프트웨어는 **수천 개 소원의 누적**이며 모든 구석에서 이것은 원하고 저것은 원하지 않는다는 미세한 결정을 내려야 함. 현재 LLM 방식에서는 이 모든 결정을 여전히 인간이 관리해야 하지만, 미래에는 지금 상상할 수 없는 방식이 나올 수도 있음
- 발전이 같은 속도로 계속된다고 가정하지만, 보기에는 이미 어느 정도 **정체 구간**에 들어섰음. 모델이 커질 때마다 비용은 기하급수적으로 늘어나며, 계속 더 큰 모델을 훈련하는 사업이 수익성 없다는 점도 꽤 드러났다고 봄
- 모든 동작에 JavaScript가 필요하고 입력란에 글자를 쓰는 것조차 제대로 못 하는 웹사이트를 만든 무능한 인간을 직접 탓하지도 못하게 될 미래가 벌써 싫음. 외형을 기능보다 중시하는 경영진과 그런 사이트가 대부분인 학습 자료 때문에 LLM이 같은 쓰레기를 **훨씬 더 큰 규모로 생산**한다면 실존적 위기가 올 것 같음
웹은 이미 충분히 엉망이니 적어도 지금 상황만큼은 무능한 인간을 탓할 수 있게 해 줬으면 함
- KPI 압박과 무관하게 기회가 있을 때마다 코드를 직접 작성하며, AI에는 **더 똑똑한 코드 자동 완성** 정도만 기대함
- 코딩을 사랑하고 진정으로 행복해지기 때문에 직접 코드를 작성함. **좋아하는 일을 포기할 이유**가 없음
- 컴퓨터에 작업을 지시하고 다른 어떤 수단보다 **수십억 배 빠르게 처리하는 모습**을 보는 데에는 마법 같은 매력이 있음
- 프로그램을 설계하고 코드를 작성하는 일이 즐거워서 이 분야에 들어왔음. AI 활용에는 뒤처졌고 더 익혀야겠지만, **손으로 코딩하는 일**은 절대 그만두고 싶지 않음
- 코딩하면서 돈까지 받는 것이 행복하다면 회사가 그 보상을 중단할 수 있음. 비자를 유지하려고 그 소득에 의존한다면 강제로 변화에 적응해 **코딩을 포기할 가능성**이 매우 큼