Ask HN: 시니어 엔지니어의 현재 궤적은 무엇인가?
Ask HN: What is the current trajectory of a senior engineer?
저는 최근에 설계 루프에서 인간이 필요 없게 되는 시점에 대해 점점 더 많이 생각하고 있습니다. LLM이 코드와 수학처럼 정답/오답을 줄 수 있는 모든 것으로 RL되어 있다면, Anthropic, OpenAI 등이 좋은 아키텍처와 나쁜 아키텍처 데이터셋을 내부적으로 구축하고 RL하는 것을 막는 것은 무엇일까요? 2024년에는 LLM이 고급 자동 완성에 불과했지만, 이제 사람들은 에이전트로 '소프트웨어 팩토리'를 만드는 것에 대해 이야기하고 있습니다. 이 발전을 막는 것은 무엇이며, 왜 소프트웨어 아키텍처가 1~2년 후에도 에이전트에게 어려울까요? 저는 비즈니스적으로 실제 소프트웨어 프로그래머 기술의 필요성이 몇 년 안에 90% 사라지고, 사람 기술이 더 많은 제품 리드 등이 선호될 것이라고 생각합니다. 좋은 시절이었습니다.
아키텍처는 단지 정답/오답이 있는 것이 아니라, 트레이드오프와 맥락에 대한 이해가 필요합니다. LLM이 좋은 아키텍처와 나쁜 아키텍처를 구분하려면 수많은 실제 프로젝트의 성공/실패 데이터가 필요하지만, 그런 데이터는 대부분 비공개이고 주관적입니다. 또한 아키텍처 결정은 비즈니스 목표, 팀 역량, 예산 등 수많은 요소에 달려 있어 단순히 RL로 최적화하기 어렵습니다.
저는 시니어 엔지니어의 역할이 에이전트를 관리하고 조율하는 쪽으로 이동할 것이라고 봅니다. 에이전트가 코드를 생성할 수는 있지만, 어떤 문제를 해결해야 하는지 정의하고, 결과를 검증하며, 이해관계자와 소통하는 일은 여전히 인간의 몫입니다. 따라서 기술적 깊이와 함께 커뮤니케이션, 제품 감각, 리더십이 더 중요해질 것입니다.
소프트웨어 개발은 단순히 코드를 작성하는 것이 아니라, 불명확한 요구사항을 명확히 하고, 시스템의 경계를 설정하며, 예상치 못한 상호작용을 처리하는 일입니다. 에이전트는 훈련된 패턴 내에서는 뛰어나지만, 새로운 도메인이나 복잡한 레거시 시스템에서는 여전히 인간의 직관과 경험이 필요합니다. 1~2년 내에 완전히 대체되기는 어려울 것입니다.
비즈니스 관점에서 보면, 기업은 단기적 비용 절감을 위해 자동화를 추진하겠지만, 장기적으로는 신뢰성과 유지보수성 문제에 직면할 것입니다. 시니어 엔지니어는 시스템의 장기적 건강을 책임지는 역할을 하며, 이는 에이전트가 대체하기 어려운 부분입니다. 오히려 시니어의 역할은 더 전략적으로 변할 것입니다.
기술 발전 속도를 고려하면, 5년 후에는 지금과 완전히 다른 풍경이 펼쳐질 수 있습니다. 하지만 '소프트웨어 팩토리'가 현실화되려면 에이전트가 스스로 디버깅하고, 요구사항을 이해하며, 협업하는 능력이 필요합니다. 현재로서는 인간이 여전히 루프 안에 있어야 하며, 그 역할은 진화할 것입니다.
HN 토론
74- dimbletimbers
내 생각엔 개발자들과 HN 사람들은 평범한 사람들이 컴퓨터에 대해 얼마나 알고, 관심 갖고, 상호작용하고 싶어 하는지 엄청 과대평가하는 것 같다. 직업이 어떻게 변하든, 컴퓨터와 대화하는 걸 좋아하고 이메일이나 유튜브를 보여주는 것 외에 뭔가를 하게 만드는 법을 아는 사람이라면 앞서 나가는 것이고, 아마 그 자리를 유지할 수 있을 것이다.
- RugnirViking
나는 성능, 테스트, 관측 가능성에 더 집중하라고 제안하고 싶다.
인간의 이해 + 품질/유지보수성이야말로 돈이 되는 곳이다. 에이전트로 그런 것들을 만드는 법을 배워라.
엔지니어가 진짜로 멸종하리라고는 생각하지 않는다. 다만 수는 꽤 줄어들 수 있다. 최근 https://news.ycombinator.com/item?id=50063427 에서 "AI 사용은 기술이다"라는 논의가 내 느낌을 잘 담아낸 것 같다. 이런 도구에서 최선을 끌어내기 위해 배울 것들이 있고, 앞으로도 계속 그럴 것이다. 그렇다는 건 누군가는 그 일로 돈을 받는다는 뜻이다. 네가 그중 하나가 되도록 하라.
- bradfa
LLM이 있기 전에도 소프트웨어 엔지니어링 팀에는 프로덕트 매니저, 프로젝트 매니저, 스크럼 리더 등의 역할이 있었다. LLM 기반 개발이 진행되면서 이런 역할들과 엔지니어링으로의 교차가 계속 융합되기 시작할 것 같다.
엔지니어들이 프로젝트 관리, 고객의 목소리, 엔지니어링과 경영 사이의 중개자로서 업무를 조직하는 것이 할 수 있고/해야 하고/필요한 일이라는 걸 몰랐던 게 아니다. 단지 한 사람이 할 수 있는 일보다 더 많은 일이 있어서 업무를 위임한 것이었다. 이제 이런 역할들은 부분적으로 LLM에 넘길 수 있지만, 엔지니어링을 이끌고 비즈니스/고객과 인터페이스하는 인간이 루프 안에 여전히 있는 것은 가치 있을 것이다.
전체적으로 무엇을 만들지, 다음에 무엇을 만들지, 나중에 무엇이 올지, 그리고 제품이 비즈니스 목표와 어떻게 연결되는지 아는 것은 여전히 매우 인간적인 일이다.
- gregwebs
시니어 엔지니어와 모든 SWE 직무는 점점 더 테크니컬 리드에 가까워질 것이다.
AI를 지시하고 $/시간당 더 많은 가치를 창출할 수 있다면, 소프트웨어 엔지니어가 아닌 사람이 AI를 지시해 소프트웨어를 개발하는 것보다 여전히 많은 가치를 창출할 수 있다.
프로토타입이 아닌 대부분의 일에서 지금도 그래야 한다. 직업은 "코드 작성"에서 "소프트웨어 출시"로 바뀌었다. 테크니컬 리드다.
점점 더 지능적인 AI 소프트웨어 개발을 접근 가능하게 만드는 소프트웨어 제품들은 소프트웨어 엔지니어 개입의 필요성을 계속 줄일 것이다. 하지만 소프트웨어는 1000배 더 많아질 것이다. 따라서 적응하는 사람들에게는 기회가 계속 있을 수 있다.
- apimade
때로는 나쁜 아키텍처가 올바른 아키텍처이고, 좋은 아키텍처가 잘못된 선택이기 때문이다.
Carmack의 DOOM이 "모범 사례"로 나왔을 거라고 생각하는가? 절대 아니다.
나는 예측하거나 예상할 수 있었던 문제에 대해, 이전에 그 문제나 비슷한 문제를 본 적이 있거나 조직, 고객, 제안된 솔루션을 관리하는 팀 규모에 대한 맥락이 있었다면, 잘못된 기술, 접근 방식, 설계를 선택한 엄청나게 재능 있는 사람들과 일한 적이 있다. 하지만 그들은 그렇지 않다.
AI는 교과서적이고 "엔터프라이즈급" 솔루션을 내놓는 데 탁월하다. 하지만 코드 생산 비용이 줄어들수록 단순하고 소화 가능한 솔루션의 가치가 커질 것이라고 생각한다. TDD 등도 도움이 될 수 있지만, 어느 시점이 되면 너무 추상화되고, 너무 복잡해지고, 한 사람이 파악하기 너무 어려워진다.
그 시점에서는 사용자 여정을 이해하는 테스트 관리자가 그 무게만큼의 금값을 할 것이고, 어떤 솔루션에서든 진정한 가치는 잘 표현된 테스트가 될 것이다.