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

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

소프트웨어 엔지니어링과 에이전트 패러다임

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

AI 중심 개발 흐름에 대한 불신

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