LLM 시대 시니어 소프트웨어 엔지니어의 궤적은? Hacker News 토론

"Ask HN: What is the current trajectory of a senior engineer?"라는 제목의 Hacker News 토론은 58개의 댓글을 생산했지만 합의에 도달하지 못했습니다. 댓글 작성자들 사이의 지배적인 견해는 시니어 엔지니어링 역할이 코드 작성에서 에이전트 지휘, 품질 책임, 조직 내 정치적 역학 탐색으로 재정의되고 있다는 것입니다 — 제거되는 것이 아니라. 소수의 견해는 아키텍처 자체가 강화 학습의 다음 대상이며, 그 역할이 몇 년 안에 상당히 축소될 것이라고 주장합니다.

토론이 시작된 질문

원 게시자는 프론티어 랩이 단순히 좋은 소프트웨어 아키텍처와 나쁜 소프트웨어 아키텍처의 데이터셋을 구축하고, 코드와 수학에서 옳고 그름이 존재하는 것처럼 강화 학습을 적용할 수 없는 이유를 물었습니다. 게시자는 핵심을 직설적으로 제시했습니다:

"2024년에 LLM이 멋진 자동 완성 기능이었다는 점을 감안할 때, 이제 사람들이 에이전트로 '소프트웨어 팩토리'를 구축하는 것에 대해 이야기하고 있습니다. 이 발전을 막을 수 있는 것은 무엇이라고 생각하십니까? 왜 1~2년 후에도 에이전트에게 소프트웨어 아키텍처가 여전히 어려울까요?"

게시자 자신의 결론은 프로그래머에게 비관적이었습니다: "저는 (비즈니스 관점에서) 실제 소프트웨어 프로그래머 기술에 대한 필요가 몇 년 안에 90% 사라질 것이라고 생각합니다. 제품 리드 같은 사람들은 사람 관리 능력이 더 많기 때문에 더 선호될 것입니다. 좋은 시간이었습니다."

가장 강력한 반론: 아키텍처가 아예 중요하지 않게 될 수도 있다

구조적으로 가장 흥미로운 답변은 akoboldfrying이 제시했는데, 그는 질문의 전제가 틀렸다고 주장했습니다 — 에이전트가 아키텍처를 배울 수 없기 때문이 아니라, 아키텍처가 인간의 인지적 한계를 극복하기 위한 수단으로만 존재하기 때문입니다.

"모듈성과 추상화 수준과 같은 조직 원칙을 적용/강제하는 의미의 아키텍처는 현재 우리가 복잡성을 관리하기 위해 주로 수행하는 것입니다 — 제한된 두뇌에 시스템의 최대한 많은 부분을 담기 위해서입니다. 충분히 큰 시스템의 경우 효율적으로 작업하려면 이것이 필요합니다. 하지만 이러한 '목발' 없이 '전체를 머릿속에 담을 수 있다면' 실제로 그럴 필요가 없습니다. 그것들은 없앨 수 있는 오버헤드가 됩니다."

댓글 작성자는 이를 아무도 아키텍처를 계획하지 않는 'Hello world' 스크립트에 비유했습니다. 모델이 전체 코드베이스를 컨텍스트에 담을 수 있다면, 아키텍처 규율은 자동화될 기술이 아니라 선택적 오버헤드가 된다는 논리입니다.

에이전트가 이미 아키텍처에 근접했다는 토론의 증거

jwr라는 댓글 작성자는 Fable 5.1과 Astra라는 두 모델을 아키텍처 설계 문서에 사용한 직접적인 경험을 보고하며 결과가 인간 작업과 경쟁력이 있었다고 말했습니다:

"저는 그들과 함께 아키텍처 설계 문서 작업을 했는데 매우 훌륭했습니다. 그들의 제안 중 일부는 제 해결책보다 나았습니다. 시스템 아키텍트를 완전히 대체할 수 있는 단계는 아니지만 가까워지고 있습니다."

같은 댓글 작성자는 모델의 도달 범위 밖에 남아 있는 것을 지적했습니다: "무엇을 구축할지, 그리고 인간이 이해할 수 있는 방식으로 복잡한 정보를 제시하는 이해 가능한 사용자 인터페이스를 만드는 방법에 대한 질문은 여전히 열려 있습니다. 그것은 AI가 아직 할 수 없는 일입니다."

두 번째 댓글 작성자 zeryx는 에이전트로 비디오 게임을 만들려고 시도했다고 설명하며, 에이전트가 개별 코드 조각을 작성하고 기본적인 실패 모드를 잡는 스크립트를 작성하며 VM을 실행하고 AutoHotkey로 게임 상태를 트리거하고 스크린샷과 GIF를 찍어 자신이 만든 것을 평가하는 등 게임을 플레이할 수도 있었다고 보고했습니다. 실패는 실행에 있지 않았습니다:

"재미를 극대화하기 위해 무엇을 구축할지 직관적으로 아는 것, 또는 다른 비논리적인 인간 경험은 결코 RL로 처리할 수 없습니다."

토론에서 에이전트에게 여전히 어렵다고 말하는 것

여러 댓글 작성자는 자동화에 저항한다고 생각하는 작업 집합에 수렴했습니다. 그들의 이유는 일반적인 'AI는 코딩을 못한다'는 주장과 다릅니다.

조직적 합의. accurrent는 시니어 역할 자체를 정치적인 것으로 정의했습니다: "IMO 시니어 소프트웨어 엔지니어는 대규모 조직에서 합의를 이끌어내는 사람입니다. LLM이 곧 그 문제를 해결할 것 같지 않습니다." 같은 댓글 작성자는 백엔드에서 레이스 컨디션을 추적하고 컨텍스트 창에 무엇이 들어맞는지 추론하는 것이 여전히 인간의 감독을 요구하며, 원활한 마이그레이션을 위한 테스트 설계도 마찬가지라고 언급했습니다.

나쁜 아이디어에 반대하기. jgilias는 현재 모델이 이 역할에 유용하기에는 지나치게 순응적이라고 주장했습니다:

"모델에는 정렬 문제가 있습니다. 즉, 나쁜 아이디어에 충분히 강하게 반대할 만큼 '정렬'되어 있지 않습니다. 권력 역학 등으로 인해 실제로 반대할 수 없는 경우도 있지만, 작업은 여전히 어떻게든 수행되어야 합니다. 그래서 인간은 때로 나쁜 아이디어를 무시하고, 때로는 서사에 동조하는 척하면서 실제로 필요한 일을 하며, 때로는 다른 방법이 없을 때 발을 굳히고 나쁜 아이디어가 뿌리내리기 전에 제거합니다. 에이전트는 어제 존재했던 최고 수준의 모델 능력으로 이를 수행할 수 있습니다. 하지만 그러려면 심각하게 '비정렬'되어야 할 것입니다."

책임. papa-smurf는 소프트웨어 개발을 떠나 시스템 컨설팅으로 전환한 경험을 설명하며 해자를 명시적으로 언급했습니다: "(컨설팅) 직업의 주요 해자는 고객이 항상 책임을 돌릴 인간이 필요하다는 것입니다. 그게 저입니다. 비슷한 역할은 상대적으로 안전할 것 같습니다."

무엇을 구축할지 결정하기. fergie는 질문의 본질을 축약했습니다: "궁극적으로 기계에게 무엇을 하라고 지시할지 결정하고 실제로 기계에게 지시할 사람이 여전히 필요합니다. 그것이 JavaScript든 평범한 영어든 중요하지 않습니다."

재구성: 기술 리드로서의 시니어 엔지니어

토론에서 가장 반복된 예측은 직함은 살아남지만 직무 설명이 바뀐다는 것입니다. gregwebs는 직접적으로 말했습니다:

"시니어 엔지니어와 모든 SWE 직책은 기술 리드에 더 가까워질 것입니다. AI를 지시하고 비엔지니어가 AI로 소프트웨어를 개발하는 것보다 시간당/달러당 더 많은 가치를 생산할 수 있다면 여전히 많은 가치를 생산할 수 있습니다. 이것은 프로토타입이 아닌 대부분의 경우 지금도 그래야 합니다. 직업은 '코드 작성'에서 '소프트웨어 출시'로 바뀌었습니다. 기술 리드."

같은 댓글 작성자는 단순한 인원 감소에 반하는 공급 측 주장을 추가했습니다: "하지만 소프트웨어도 1000배 더 많아질 것입니다. 적응하는 사람들에게는 계속 기회가 있을 수 있습니다."

bradfa는 역할 수렴에 대한 평행한 관점을 제시하며, 제품 관리자, 프로젝트 관리자, 스크럼 리더가 LLM 이전에도 엔지니어링 팀에 이미 존재했으며, 이러한 역할은 별도의 작업 종류가 아니라 작업의 위임이었다고 언급했습니다:

"이제 이러한 모든 역할은 부분적으로 LLM에 오프로드될 수 있지만, 엔지니어링을 안내하고 비즈니스/고객과 인터페이스하는 인간 인 루프는 여전히 가치가 있을 것입니다. 전체적으로 무엇을 구축할지, 다음에 무엇을 구축할지, 나중에 무엇이 올지, 제품이 비즈니스 목표와 어떻게 관련되는지 아는 것은 여전히 인간의 노력입니다."

토론이 권장하는 기술

RugnirViking은 구체적인 기술 방향을 권장했습니다: "성능, 테스트, 관찰 가능성에 더 집중하는 것이 좋겠습니다. 인간의 이해 + 품질/유지보수성이 돈이 되는 곳입니다. 에이전트로 이러한 것을 만드는 법을 배우십시오." 같은 댓글 작성자는 'AI 사용은 기술'이라는 아이디어에 대한 별도의 Hacker News 토론을 링크하며 결론을 내렸습니다: "엔지니어가 정말 멸종할 것 같지는 않지만, 더 적어질 수는 있습니다."

accurrent는 프로토타이핑이 이제 충분히 저렴해져 많은 개념을 테스트할 수 있기 때문에 미학과 UX 직관이 프론트엔드에서 새롭게 가치 있는 분야라고 지적했고, 로봇공학은 LLM 지원 코딩에도 불구하고 "더 빨리 움직이는 느낌이 들지 않을 만큼 교차 기능적 문제가 많은" 영역이라고 언급했습니다.

반대 의견: 경제성은 입증되지 않았고 낙관론은 자기 이익적이다

모든 사람이 에이전트 능력이 제약 조건이라는 전제를 받아들인 것은 아닙니다. sdcfgy는 제약이 재정적, 정치적이라고 주장했습니다:

"경제와 현실은 입증되지 않았고 불투명합니다. 우리가 가진 증언의 대부분은 막대한 투자를 한 사람들이거나 현재 낮은 할인율로 기술 비용을 지불하는 사람들입니다. 기술을 제공하는 회사들은 재정적으로 건강하지 않고, 지정학적으로 크게 정렬되어 있으며 많은 사람에게 위험 요소입니다. 그것이 작동하는지 여부는 논쟁의 여지가 없습니다. 그것은 지평선에 큰 경제적 또는 정치적 실패처럼 보입니다. 따라서 미래를 생각하기 전에 지켜봐야 합니다."

amelius는 채택 자체를 함정으로 규정했습니다: "AI에 낙관적인 모든 바이브 코더는 우리가 AI를 훈련시키고 있다는 것을 깨달아야 합니다. AI가 우리를 대체하도록 돕는 것입니다. 우리는 기본적으로 크리스마스를 위해 투표하는 칠면조입니다. 우리는 끝났습니다."

fergie는 시니어 연봉 하락 압력에 대한 경쟁 설명을 제시했습니다: "SWE 연봉 상위권에 실제로 압력이 있는 것 같습니다. 이것이 단순한 희망적 사고일 가능성도 있지만, 사실이라면 실제 업무 감소보다는 지원자 증가와 더 관련이 있다고 생각합니다. AI는 모든 빈자리에 대한 지원서 수를 증가시킨 것 같습니다."

zerop은 채택이 실제로 어디에 착지할지에 대해 더 좁은 주장을 했습니다: "LLM은 코딩에서 좋은 성과를 거둘 수 있었습니다. 누군가가 그것이 생산한 작업(코드)을 검토하기 때문입니다. 물론 코드 품질은 시간이 지남에 따라 좋아졌습니다. IMO 인간 인 루프 시나리오 외에는 AI가 비즈니스에서 큰 채택을 보지 못할 것입니다."

수요 측 주장: 대부분의 사람들은 컴퓨터와 대화하고 싶어하지 않는다

dimbletimbers는 토론 참가자들이 경쟁을 체계적으로 과대평가한다고 주장했습니다:

"개발자와 HN 사람들은 평균적인 사람이 컴퓨터에 대해 얼마나 알고, 관심을 가지며, 상호 작용하기를 원하는지 과대평가한다고 생각합니다. 직업이 무엇이 되든, 컴퓨터와 대화하는 것을 좋아하고 이메일이나 YouTube를 보여주는 것 외에 다른 일을 시키는 방법을 안다면, 당신은 앞서가고 있으며 그 위치를 유지할 수 있을 것입니다."

testerius는 프로그래머를 수학자, 의사, 생물학자, 영업 사원, 마케터, 교사, 예술가와 함께 일반적인 노동 주장으로 확장했습니다: "물론 프로그래머나 수학자를 없앨 수는 있지만, 그러면 스스로 상황을 이해하고 처리해야 합니다. '무슨 일이 일어나고 있는지' 확인할 사람은 여전히 필요합니다."

frangonf는 같은 주장의 최소 버전을 만들었습니다: "소프트웨어(그리고 곧 비슷하게 타격을 받을 다른 분야)가 여전히 '틀릴' 수 있고, 기계의 도움을 받아도 여전히 망칠 수 있다면, 소프트웨어를 하는 사람들에게는 여전히 자리가 있습니다."

토론이 도달한 지점

어떤 댓글 작성자도 타임라인을 안다고 주장하지 않았습니다. 토론의 실제 산출물은 후보 해자 목록 — 조직적 합의, 책임, 무엇을 구축할지 결정, 미학 및 UX 판단, 성능 및 관찰 가능성 작업, 나쁜 아이디어를 무시할 의지 — 과 함께 두 가지 진정으로 양립할 수 없는 예측입니다. 하나는 아키텍처가 배울 수 있는 기술이며 에이전트가 흡수할 것이고, 그 후에는 규율이 불필요한 오버헤드가 된다는 것입니다. 다른 하나는 아키텍처가 에이전트가 애초에 필요로 하지 않았던 인간 기억 한계에 대한 해결책이므로, 에이전트가 그것을 배울 수 있는지 여부는 핵심이 아니라는 것입니다.

여러 댓글 작성자는 실존적 프레임에 분석보다는 어두운 유머로 응답했습니다. Zealotux는 썼습니다: "저는 해충 방제 사업을 시작하거나 길에서 찾은 가구를 리폼하는 것을 알아보기 시작했습니다. 시니어 엔지니어를 위한 다른 아이디어가 있으면 알려주세요." 스스로를 '거의 공식적으로 그레이비어드 영역'이라고 표현한 sitzkrieg는 말했습니다: "양봉장을 시작할 생각입니다. 벌에게 100번 쏘이는 것이 어떤 출처의 LLM 코드와 상호 작용해야 하는 것보다 더 재미있을 것 같습니다." sharpshadow는 토론의 불안을 가장 압축된 버전으로 제시했습니다: "손으로 코딩하는 것은 금지될 것입니다. 너무 큰 위험 요소입니다. 당신은 전능자와 소통하는 샤먼이 될 수 있습니다."