# 나는 소프트웨어 엔지니어가 아니다

> Clean Markdown view of GeekNews topic #29730. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=29730](https://news.hada.io/topic?id=29730)
- GeekNews Markdown: [https://news.hada.io/topic/29730.md](https://news.hada.io/topic/29730.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-05-21T11:02:32+09:00
- Updated: 2026-05-21T11:02:32+09:00
- Original source: [huronbikes.mataroa.blog](https://huronbikes.mataroa.blog/blog/i-am-not-a-software-engineer/)
- Points: 1
- Comments: 1

## Topic Body

- **소프트웨어 엔지니어**라는 정체성 거부는 23년 전 “좋은 해커지만 엔지니어는 아니다”라는 평가에서 시작됨
- **에이전트 패러다임**은 비결정적 프로그램으로 결정적이어야 하는 프로그램을 만들게 하는 방식처럼 느껴짐
- 코드에 대한 믿음은 **가독성**, 이해 가능성, 효율성, 추론 가능성, 같은 입력에 같은 출력을 내는 재현성에 있음
- 직장의 **agentic user flows**와 AI 사용 KPI는 좋은 코드보다 지표와 자연어 입력을 앞세우는 방식으로 받아들여짐
- AI 업계의 미래상은 소프트웨어 개발 대체를 넘어 **생각 자체에 해자**를 두르려는 상상으로 비침

---

### 소프트웨어 엔지니어링과 에이전트 패러다임
- **소프트웨어 엔지니어**라는 정체성에서 스스로를 제외하는 태도는, 23년 전 동료에게 “좋은 해커”지만 엔지니어는 아니라고 들었던 경험에서 출발함
- 최근의 “새로운 **에이전트 패러다임**”은 [Waylon Smithers](https://en.wikipedia.org/wiki/Waylon_Smithers) 같은 기계에게 실수하지 말라고 요청하고, 그 결과를 전문가 소프트웨어 엔지니어링으로 포장하는 방식처럼 보임
- 비결정적 출력을 내는 프로그램으로 결정적이어야 하는 프로그램을 작성하는 방식이 소프트웨어 엔지니어링의 미래로 제시되고 있음
- 코드에 대한 기본 믿음은 여전히 **가독성**, 이해 가능성, 효율성, 충분한 추론 가능성, 같은 입력에 같은 출력을 내는 재현성에 있음
- 실제 시스템에서 재현성은 이미 어렵기 때문에, 코드 작성 자체가 “움직이는 모래” 위에 세워져서는 안 됨
- 결합된 하위 쿼리와 집계 표현식으로 구성된 뷰가 **쿼리 성능**에 미칠 영향, 제어의 역전(Inversion-of-Control), 기능을 메서드에서 분리해 독립 테스트 가능하게 만드는 설계 같은 세부는 여전히 중요함

### AI 중심 개발 흐름에 대한 불신
- 직장에서 요구되는 **agentic user flows**는 의미가 명확하지 않고, 자연어 입력 텍스트 박스가 작은 선택지 집합에서 고르는 방식보다 왜 나은지도 납득하기 어려움
- 소프트웨어 개발 생명주기의 모든 단계에 에이전트를 쓰려는 움직임이 있으며, 손으로 코드를 쓰는 일은 [COBOL](https://en.wikipedia.org/wiki/COBOL)을 쓰는 것처럼 취급될 것이라고도 함
- 에이전트는 문맥에 따라 출력을 평가하는 LLM 프롬프트 래퍼처럼 보이고, 실제 출력은 종종 부족하게 느껴짐
- AI 사용량이 **KPI**로 추적되지만, 지난 23년 동안 KPI보다 좋은 코드를 쓰는 일이 더 중요했음
- 과거 작성한 코드가 “수학 전공자가 쓴 것 같다”는 평가를 받았고, 이를 높은 칭찬으로 받아들였음
- 같은 직장의 한 스태프 소프트웨어 엔지니어 구현은 명시적 인터페이스가 없고, DI 컨테이너를 public static 멤버로 노출했으며, 표 형식 데이터에 적합해서가 아니라 “비즈니스 사용자가 쓰기 쉽다”는 이유로 CSV 설정을 사용했음
- 그 구현을 매우 나쁘다고 말했다가 문제가 됐고, 이 일은 스스로가 소프트웨어 엔지니어가 아니라는 반어적 결론으로 이어짐
- 똑똑하다고 여기는 사람에게서 AI가 소프트웨어 작성과 업계의 미래이므로 받아들여야 한다는 조언을 두 번 들었지만, 그 태도는 부주의해 보임
- 사용해 본 **AI 소프트웨어**는 사고 과정을 돕기보다 방해하거나 적극적으로 가져가는 것처럼 느껴졌고, 그런 전유(co-option)가 염려됨
- 대형 AI 회사 리더들은 소프트웨어 개발 업계의 미래를 즐겁게 말하며, 제품이 고용에 [devastating effects](https://fortune.com/2025/05/28/anthropic-ceo-warning-ai-job-loss/)를 줄 것이라고 발표하고, “[intelligence too cheap to meter](https://youtu.be/sTnl8O_BuuE?t=547)”라는 표현을 씀
- 그 미래가 끔찍한 이유는 기계가 모두를 종이클립으로 만들기 때문이 아니라, 그들이 **생각 자체에 해자**를 두르는 상상을 하고 있기 때문임

## Comments



### Comment 57981

- Author: neo
- Created: 2026-05-21T11:02:32+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/2fqahd/i_am_not_software_engineer) 
- Mary Walton의 W. Edwards Deming 책에 이런 일화가 나옴. 어느 공장 노동자가 기계 고장으로 **불량품**만 나오게 됐고, 보고했지만 정비가 늦어져 직접 고치려던 중 감독이 와서 그냥 돌리라고 했다고 함  
  결국 “불량품을 만들라”는 지시였고, 그는 “내 **작업자로서의 자부심**은 어디 있나? 감독이 기계만큼이라도 나를 존중해 주면 더 나을 텐데”라고 말했음. 그는 불량품을 만들고 돈을 받고 싶지 않았던 것임
  - 이 책인가? https://deming.org/the-deming-management-method-by-mary-walton/  
    읽어볼 만한가?

- 글쓴이보다 경력은 훨씬 짧지만, 커리어 초기에 CSV의 여러 문제 때문에 일부 업무 흐름을 **CSV**에서 벗어나게 해보려 했고, 그때 “비즈니스 업무 흐름에는 CSV가 더 쉽다”는 답을 들었음  
  당시엔 글쓴이처럼 그 답이 아주 별로라고 느꼈지만, 시간이 지나면서 그 판단이 맞는 쪽에 가깝다고 생각하게 됨

- “23년 전에 누가 소프트웨어 엔지니어가 아니라고 했다”는 식의 멍청한 의견이 아직도 괴롭다면, 해결책은 남의 의견을 그렇게까지 신경 쓰지 않는 것이라고 봄  
  고용주의 어리석은 정책이나 동료의 성실성 부족이 답답하다면 다른 회사를 찾으면 됨. 세상에는 80억 명이 있고, 그중 많은 이가 컴퓨터가 뭔가를 해주길 원하며, 그중 또 많은 이가 프로그래밍 비용을 지불함  
  “처음 제과점에서 일할 때 동료가 크루아상은 버터를 더 팔기 위한 Big Dairy의 음모라고 해서, 그걸 세계관의 토대로 삼고 다시는 제과점에서 일할 수 없다고 결론 내렸다”는 식으로 들림. 글쓴이 나이가 없었다면 고등학생쯤으로 봤을 텐데, 23년 전 일을 말할 정도면 이미 그럴 나이는 훨씬 지났다고 봄
  - 이 글이 플래그되는 이유는 짐작만 가능하지만, 그 짐작에 꽤 확신이 있음. 다만 핵심 문제는 어조가 불친절하다는 것보다, 글의 **핵심 논지**를 비껴갔다는 데 있음  
    글의 요지는 글쓴이가 실제로 소프트웨어 엔지니어가 아니라는 게 아니라, 아마 오랫동안 그런 직함으로 일해왔을 것임. 요지는 그 직함에서 스스로를 배제하는 태도가 이 업계가 변한 모습에 대한 **반응**이라는 것에 가까움  
    “이건 엔지니어링이 아니라 헛소리다. 소프트웨어 엔지니어가 된다는 게 이런 뜻이라면 나는 그게 아니다”라고 말하는 셈임  
    개인적으로 그 감정에 공감함. 우리가 소프트웨어 개발자로 하는 일을 “엔지니어링”이라고 부르는 것이 다른 공학 분야에 대한 모욕처럼 느껴진 적이 많았음. 특히 그렇게 부르면서도 정작 우리가 만드는 것에는 별로 신경 쓰지 않는다는 점 때문임  
    토목 엔지니어는 다리가 무너지는 일을 정말 심각하게 받아들이고, 큰 붕괴가 일어나면 업계 전체가 반응하고 배워서 다시는 그런 일이 일어나지 않게 하려 함. 반면 이른바 소프트웨어 “엔지니어”는 완전히 예방 가능한 이유로 운영 환경을 몇 번이고 장애 내고도, 그걸 이력서의 성공담처럼 적을 수 있음  
    지금의 소프트웨어 엔지니어링 흐름, 즉 실제로 배포하는 코드에 신경 쓰지 않고 그 작성을 다른 “지능”에 위임하는 경향에 대해서도 내 생각은 짐작 가능할 것임  
    왜 이런 일이 벌어지는지는 이해하고, 어떻게 해야 하는지에 대한 답을 다 갖고 있다고 말하고 싶진 않음. 하지만 이걸 진지한 일, 즉 “엔지니어링”이라고 가장하지는 말아야 함