▲

"개발자가 대체된다"는 유행은 왜 반복될까 ?

 (alonso.network)
45P by GN⁺ 10일전 | ★ favorite | 댓글 19개
  • NoCode부터 AI까지, 개발자를 대체하겠다는 기술은 반복적으로 등장하지만 실제로는 기술 변화에 따라 역할이 변형됨
  • NoCode는 개발자를 없애지 않고 NoCode 전문가와 통합 기술자를 탄생시켰고, 클라우드는 DevOps 엔지니어라는 고급 직군을 만들었음
  • 현재 AI 개발도구도 비슷한 길을 걷고 있으며, AI가 코드를 짜는 시대에도 시스템 아키텍처 설계 능력은 여전히 핵심임
  • AI는 로컬 최적화는 잘하지만 전체 시스템 설계에는 약하며, 빠른 생성 속도로 인해 구조적 실수를 빠르게 고착화할 위험이 있음
  • 개발자 대체는 결국 기술 스택 변화에 따른 진화와 고도화일 뿐, 본질적 역할은 계속 필요함

From NoCode to AI-Assisted

  • 몇 년 주기로, 소프트웨어 개발자를 대체할 것이라 주장하는 새로운 기술이 등장함
  • "코딩의 종말", "이제 누구나 앱을 만들 수 있음", "아이도 코딩한다" 등 과장된 기대가 포함된 유사한 제목들이 반복적으로 생성됨
  • 경영진과 컨설턴트들이 이 흐름에 주목하고, 예산이 이동하는 모습이 나타남
  • 하지만 현실은 항상 “대체”가 아니라 “변형”이었음
    • 복잡해진 기술을 다루는 새로운 역할과 고도화된 전문직이 탄생하고, 임금 수준도 상승하는 경향이 반복적으로 드러남
  • NoCode는 전문 기술자 없이 앱을 만들 수 있다는 기대를 만들었지만, 결국 데이터 모델링, 통합, 유지보수 등 복잡한 문제가 존재했고 이를 해결할 새로운 직군이 탄생함
  • 클라우드는 시스템 관리자 없이 운영 가능하다는 믿음을 줬지만 실제로는 DevOps 엔지니어라는 고급 전문성을 요구하게 되고, 임금도 상승함
  • AI도 마찬가지로, “AI가 코드를 대신 작성”할 수 있을 것 같지만 실제로는 AI를 관리·오케스트레이션 할 수 있는 숙련 개발자의 중요성이 더욱 커짐

반복되는 대체 약속의 회전목마(The Endless Carousel of Replacement Promises)

NoCode/LowCode 혁신

  • 직관적인 인터페이스로 모든 사용자가 앱을 만들 수 있다는 NoCode/LowCode 혁신이 등장
  • 하지만 실제 현장에서는 데이터 모델 설계, 기존 시스템과 데이터베이스 통합, 예외 처리, 유지 관리 등 신규 문제가 발생함
  • 이에 따라 단순 개발자가 아닌, 도메인 지식과 기술적 한계를 동시에 이해하는 NoCode 전문가가 필요해짐
  • 이들은 기존 개발자보다 더 높은 연봉을 받음

클라우드 혁명

  • 클라우드로 이전하면 시스템 관리자가 필요 없어질 거라는 기대가 컸음
  • 하지만 클라우드 관리 전문성과 복잡성이 오히려 증가함
  • 기존 시스템 관리자는 DevOps 엔지니어로 변신하여 더 높은 급여를 받고, 인프라 자동화, 배포 파이프라인, 분산 시스템 관리 등 업무 수준이 고도화됨
  • 업무는 사라진 것이 아니라, 새로운 작업 형태로 진화함
  • 마이크로서비스 전환에서도 복잡성이 커지고, 결국 근본적으로 시스템을 관리하는 전문가의 역할이 중요함이 드러났음

오프쇼어(Offshore) 개발 바람

  • 해외 아웃소싱으로 비용을 절감할 수 있다는 믿음이 생겨났지만, 커뮤니케이션 문제, 품질 저하, 도메인 지식 부족으로 어려움 발생
  • 결국 분산 팀 구조조, 명확한 소유권, 강력한 아키텍처 등으로 전략이 변화하며, 초기 기대했던 것보다 전체 비용이 증가하는 결과를 낳음

AI 코딩 어시스턴트 혁명

  • 이제는 AI가 코드를 자동으로 생성한다는 약속이 화두임
  • 초기 현실에서는, AI가 만들어주는 코드는 종종 미묘한 오류와 일관성 문제를 내포함
  • 시니어 엔지니어가 AI 결과를 검토·수정하는 데 많은 시간을 쓰며, 경험 있는 개발자일수록 훨씬 더 많은 가치를 창출함
  • AI 보조만으로 구축된 시스템은 체계적인 아키텍처가 부재한 경우가 많음
  • 즉, 기술이 기술자를 대체하는 것이 아니라, 더 높은 추상화 계층으로 기술자의 전문성을 끌어올리는 것임

이번 사이클이 특별한 이유

  • 사람들이 간과하는 핵심: 코드는 자산이 아니라 부채
  • 빠르고 쉽게 코드를 만들수록, 유지보수와 보안, 리팩터링의 부담도 커짐
  • AI는 함수 단위 최적화는 가능하지만 전체 시스템 설계 능력은 부족
  • 구현 속도가 빨라질수록 구조적 실수를 빠르게 고착화할 위험 존재
  • 결국, AI 시대에도 진정한 자산은 시스템 아키텍처 설계 능력이며, 이는 대체가 아닌 강화의 대상임
  • "AI가 개발자를 대체한다"는 주장은 다음의 근본적 오해에서 비롯됨
    • 코드는 자산이 아니라 부채라는 사실
    • 코드는 지속적인 유지·검증·보안 관리·교체가 필요하며, 그 라인 수만큼 부채가 증가함
  • AI가 코드를 빠르게 만들어준다는 것은, 부채를 그만큼 빠르게 발생시킨다는 것에 불과함
  • 즉, AI는 로컬 최적화(함수, 부분 기능)는 잘하지만, 글로벌 설계·아키텍처 결정은 부족함
  • 구현 속도가 빨라질수록, 잘못된 설계가 시스템 전체에 '굳어지는' 위험성이 커짐
  • 일회성 단기 사이트 제작에는 문제가 없으나, 장기적으로 발전하는 시스템에는 치명적임
  • 기술 혁신의 패턴은 변함없이 유지됨
    • 시스템 관리자는 DevOps 엔지니어가 되고, 백엔드 개발자는 클라우드 아키텍트가 됨
  • 하지만 AI는 모든 것을 가속화함. 살아남고 발전하는 기술은 코드 작성이 아님
  • 그것은 바로 시스템을 설계하는 것(Architecting systems). AI가 할 수 없는 유일한 일이 바로 그것임
▲
click 10일전  [-]

AI 바이브 코딩 검수해주실 분 찾습니다 이미 다 만들어놨는데 오류나는 거 살짝만 고쳐주세요 이런 외주 요청사항이 이미 나오는데 새로 만드는 편이 빠르죠

답변달기
▲
heim2 10일전  [-]

소름 ㅋㅋㅋㅋ

답변달기
▲
aer0700 7일전  [-]

이거 저도 당해봤는데 끔찍하더라고요...

답변달기
▲
mentee313 9일전  [-]

모르는 사람들인지 신경안쓰는 사람들인지 아무튼 많더라고요...
번역도 마찬가지로... AI가 쓸만하긴?하지만 많은 사람 힘들게 하는 것 같습니다...
얼핏 보면 그럴듯하지만 고치는 사람 입장에선 일은 더 늘어나고ㅠㅠ

답변달기
▲
kimjoin2 9일전  [-]

점진적으로 대체되고있다 봐야한다 생각합니다.
동일 작업 결과를 위해 투입되어야 하는 사람 수는 줄고있는게 사실이에요.

"시스템을 설계하는 것"에 대해서도 사람 10명이 하던것을 8명+ai 서포트로 해결된다면
이미 2명은 대체된 상황이죠.

답변달기
▲
ahwjdekf 10일전  [-]

바이브 코딩 뒷감당 잘 안되는게 문제인듯

답변달기
▲
tkddls8848 8일전  [-]

개인적 경험으로 의견에 동의합니다. AI도 결국 툴이라서 1에서 99까지는 정말 빠르고 좋은데 항상 나머지 1이 없는 느낌이 듭니다

답변달기
▲
GN⁺ 10일전  [-]
Hacker News 의견

  • 최근 "일회용 마케팅 랜딩 페이지" 같은 일을 프리랜서로 수정해 본 경험, 통제욕이 강한 고객들은 늘 AI가 제대로 처리하지 못할 이상한 요구사항을 추가해서 결국 내가 문제를 수습하게 되는 상황, 아무리 AI가 똑똑해져도 소프트웨어 문제가 기술적인 게 아니라, ‘필요하지 않은 복잡함’을 사람 자체가 계속 만들어내는 문제라는 관점, 결국 개발자의 가장 큰 무기는 “거절”이라는 말, 하지만 AI끼리 경쟁하면 사람처럼 늘 하나쯤은 예스를 외칠 것이라는 우려 담음

    • 소프트웨어는 완벽하게 구현할 수 있지만, 요구사항 자체가 기술적 현실을 반영하지 않으면 결국 혼란만 생긴다는 고전적인 “요구사항 버그” 개념, AI도 포맷이나 지원 여부(예: gif는 투명도 미지원) 같은 현실적 제한에 대해선 이젠 대응 가능하지만, “로고를 각 점이 중심에서 같은 거리에 위치하는 정사각형으로 해달라” 같은 황당한 요구는 인간이 계속 써낼 거라는 생각, jpg의 오타도 유머로 언급

    • ‘아니요’와 ‘예’ 사이에는 “이게 맞냐”는 50가지 그레이스케일이 존재한다는 경험, 누군가는 “데이터베이스를 다운로드할 수 있는” 웹페이지를 원한다고 했지만 실제론 간단한 csv 내보내기를 뜻한 것처럼 맥락 해석의 중요성, 이런 뉘앙스를 chatgpt가 제대로 파악할지 궁금한 시선

    • ‘거절’이 진짜로 개발자 업무에서 가장 어렵고 힘든 부분, 많은 개발자가 사실 이런 역할 자체를 즐기지 않거나 자기 일이 아니라고 여기는 현실, 결국 프로젝트의 실제 성공은 기술이 아닌 이해관계자와의 ‘인간 대 인간’ 소통이 좌우한다는 점에서, ‘사실상 PM 역할을 겸하는 개발자’가 항상 필요하다는 믿음

    • 이 모든 게 이른바 ‘피플웨어’라는 책에 잘 나오는 내용, “당신의 모든 문제가 기술적이길”이라는 인사를 좋아하는 이유, 실제로 코드로 푸는 문제는 극히 일부 엣지케이스를 빼면 항상 그리 어렵지 않았던 현실

    • 좋은 포인트라는 의견 및 AI가 잠재적으로 복잡도를 추정하고 경고하는 데 점점 탁월해질 가능성, 체스에서 AI가 이미 인간보다 훨씬 더 좋은 평가/판단 능력을 보이는 사례 비유, 여기서 AI는 LLM에 한정하지 않지만 그 범주 내의 발전을 인정

  • 기사에서 말하는 “AI는 시스템을 설계(architecting)할 수 없다”는 주장에 동의하지 않는 입장, 사실 AI는 이미 이 영역에서 점점 실력을 늘려가는 중이며 필요조건 단어 자체를 계속 바꿔가며 논점을 옮기는 현상이 있다고 지적, 단 AI가 스스로 무엇을 원해야 하는지, 또는 사용자의 동기까지 대신 결정해주지는 못함(물론 아이디어 제시는 가능), 앞으로도 누군가 직접 움직이고 문제를 해결하기 원해야 사회가 돌아가며, 개발자의 역할이 변할 뿐 문제 해결은 여전히 인간 몫이라는 생각

    • “개발자” 의미가 바뀐다고 했는데, 사실 본질은 처음부터 똑같았다는 시각, 프로그래밍이란 본질적으로 불명확한 요구를 명확하게 코드로 바꾸는 일, 과거와 달리 방법이 머신코드·펀치카드에서 프레임워크·GUI 등 그림도구까지 변해왔으나, 결국 코드를 쓰는 게 가장 효과적인 이유는 명료성과 전달력 때문이라고 강조, LLM은 기존의 답습엔 강하지만 완전히 참신한 작업이나 설명을 자연어로 시도하면 답답함이 크다는 솔직함, 시장은 하이프가 극대화된 상태이지만 결국 새로운 기술이 나올 때마다 부분적으로 바뀌는 패턴 반복

    • 이미 회사들이 AI로 인해 주니어 채용을 줄이는 등 변화가 감지되고 있다는 관찰, AI가 아키텍팅만 빼고 다 한다면 결과적으로 더 적은 수의 엔지니어만 필요로 하는 구조가 된다는 우려

    • AI가 아직 아키텍처링을 할 수 없다고 단언, 아키텍처링과 플래닝(계획 수립)은 다르다며, 플래닝은 제한·솔루션·리소스를 배분하고 예측하는 능력, 여전히 AI가 이를 효과적으로 수행하는 수준까지는 멀었다고 밝힘, 진정한 아키텍처링은 다중 레이어의 협력·경쟁적 설계, AI가 한 레이어에서 실수하면 전체가 틀어질 수 있고, 이런 시스템을 사람만이 안전하게 설계 및 감리 가능하다고 강조

    • 충분한 맥락 정보만 있다면 AI도 원하는 것을 상당히 잘 파악할 수 있다는 의견, 이는 사실 사생활 침해 관련 경고와도 이어짐, 조직이 강력한 시스템·문맥 인지 기술을 쥐면, AI가 당신의 욕구나 다음 행동까지도 “충분히” 예측해낼 수 있게 된다는 점이 오히려 더 무서운 부분

    • AI가 아키텍처링이 아니라 시뮬레이션만 하고 있고, 심지어 코딩조차 제대로 못하는 경우가 많다는 솔직한 지적

  • 비즈니스가 품질을 중시한다는 가정 자체가 잘못됐다는 주장, 기업은 오직 수익성만 고려하며, 고객이 원할 경우에만 고품질을 제공하는 구조, 솔직히 고객도 실제론 품질보다 가성비 ‘최고’ 물건을 좋아해서 아마존에서 가장 싼 툴을 사서 반복적으로 비슷한 허술한 (vibe code) 코드를 계속 양산한다는 견해, 결국 품질을 진짜 중요시하는 집단은 엔지니어들뿐이며, 엔지니어 관점에서 품질이 중요한 미래 예측은 과감히 무시해도 된다는 입장

    • 품질은 차별화 포인트가 될 수 있다는 의견, 아이폰 등장 당시 온갖 기능 많은 경쟁작이 있었어도 실제로 더 부드럽고 세련된 UI가 되자 결국 시장을 압도했다는 사실 강조

    • 본인이 가장 좋아하는 품질 중심 기업 Fractal Audio 소개, 기타용 하드웨어 기반 모델러(앰프 및 페달 보드 시뮬레이터)를 만드는 소규모 회사, 연이은 혁신적 업데이트와 CEO의 아날로그 모델링 성능 집착, 대기업보다 훨씬 탁월한 품질, 커미션·구독·유명인 마케팅 없이 직판과 무상 알고리즘 업데이트만으로 포지셔닝, 품질로 시장 점유율 확보한 살아있는 예시이자, 모든 비즈니스가 무조건 ‘최저가 저품질 경쟁’ 만 하는 건 아니라는 주장

    • 고객이 품질을 중시하지 않는다는 관점에 반발하며, 만약 품질이 무의미하다면 모든 스타트업이 그냥 불완전하고 싸기만 한 제품만 만들어 엄청난 매출과 성공을 했어야 한다고 반론 제기

    • 실제로 성공한 소프트웨어 제품들은 대부분 매우 뛰어난 품질이었음을 열거, Google, iPhone, Stripe, Notion 등 실제 시장에서 오래 살아남은 상품은 결코 느리거나 버그투성이가 아님, 오히려 품질이 성공 요인으로 작용했다고 봄, 반대 사례를 듣지 못했다는 의문 제기

    • 품질이 일정 수준까지는 부품화·구독화·인터넷 연결 등으로 희미해질 수도 있지만, 모든 게 급격히 무너지는 미래가 올 수 있다고 우려, 기기가 벽돌이 되거나, 간단한 사이트조차 실행이 12초 걸리거나, 사회 인프라·정부 시스템이 수십억을 쏟아붓고도 불안정해지고, 일상 대화가 LLM 상대가 되는 세상에 대한 리스크 상기

  • 과거 UML 기반 “아키텍트가 사양 만들고 개발자는 빈칸 채우기”식 조직 혁명은 오히려 지나치게 복잡한 시스템을 만들며 기민성 상실, 이어 등장한 “애자일”도 잘못 이해돼 개발자 미시관리·비신뢰·비창의적인 조직 문화 확산으로 이어진 패턴 회고, 결국 성공한 팀의 특징은 도구/프로세스 상관없이 비개발자가 개발자 일에 진심으로 관심갖고 문제를 함께 풀 때였으며, 반대로 복잡성 낮추는 시도는 언제나 실패했다고 평가

  • “아키텍처링이 가장 가치있는 기술이지만 AI가 대체할 수 없는 부분”이라는 주장에 대해, 실제로 AI에게 시스템 아키텍처 설계를 명시적으로 부탁하면, 현실에서 만난 설계자 중 최소 30%보다 오히려 더 나은 결과를 내놓는 사례 많음, AI 사용자들이 그런 요청을 잘 안 해서 그렇다는 입장

    • 현재 LLM은 주로 중간 수준(best practice)의 답변이 훈련 데이터로 많기 때문에, 자연스럽게 1/3 수준의 인간 설계자보다는 나은 결과(커먼센스 중심의 ‘무난한’ 설계)를 내놓는 반면, 훈련 데이터에 없는 완전히 새로운 분야나 고성능이 요구되는 산업에서는 인간의 ‘최초 원리 기반 사고’가 더 필요하고, LLM이 설계하는 DB 커널도 혁신적이기보단 기본적인 수준에 그칠 것이라고 예측

    • 기사 자체가 ChatGPT로 쓴 특유의 스타일(짧은 문장, 반복구, “X가 아니라 X+1”, “X가 아닌 반대-X” 등 표현 장치 과다)에 대한 비판과, HN에서 이런 글이 업보트를 많이 받는 현실에 놀람

    • 저자가 사실은 자기 본인 기술(아키텍팅)을 불가변적이고 대체불가하다고 착각(혹은 자만)하는 심리에서 온 ‘희망적 사고’라고 해석, 만약 다른 능력이 뛰어났으면 그걸 대체 불가로 여겼을 것이란 촌평

    • 아키텍트의 본질은 요구/제약을 정확히 이해하고 시스템에 반영할 수 있는 능력, 즉 좋은 프롬프트 짤 줄 알고 답변을 제대로 읽고, 필요시 강하게 반박할 줄 아는 역량에 있다는 요약

    • 현실에서 만난 ‘아키텍트’ 중 상당수는 실제 IT 인프라 전문성 없이 도면 도구나 엑셀만 다뤄도 된다고 생각하는 등 실질 역량이 부족했고, 매니저처럼 보이지만 실제론 소수만이 본질 업무를 수행할 수 있다는 현실

  • AI에 ‘과도하게’ 의존하는 기업들이 오히려 혁신의 파고에 노출될 위험을 키운다는 의견, AI 시대는 코드 생산성보다 코드 품질 관리가 핵심인데 시장은 자동 코드 생산에 지나치게 집중 중, Satya Nadella가 “MS코드의 30%가 AI로 쓰여진다”는 발언, 실제로 Github에서 월평균 20건 이상 사건 사고 발생 추이(근거 링크: githubstatus.com/history), 효율만 쫓다가 품질 하락으로 뒷감당하게 될 기업들 예상, 특히 MS급 거대 기업이 아니라 중소기업은 무너질 위험

    • AI 무시하는 회사들이 오히려 고전할 거라고 보는 반론 의견

    • “AI를 과용하는 회사는 오히려 장기적으로 큰 비용을 떠안는다”는 주장 및 관련 아티클 소개(AI: Accelerated Incompetence)

  • “코드는 자산이 아니라 부채”라는 주장에 100% 공감, 목표는 최소한의 코드로 목적을 달성하는 것, AI는 오히려 너무 쉽게 코드를 양산하다보니 코드 부채가 훨씬 커진다는 우려

    • 기술 발전의 생산성 역설(생산성이 늘었는데 실제 시스템 복잡성 증대로 효율이 상쇄되는 현상) 관련 위키 링크 공유(Productivity paradox)

    • 현대 AI의 코드 생성 시대가 예전 MS FrontPage로 웹사이트 만들던 시절, html이 90% 쓸데없는 코드로 가득찼던 ‘크러프의 시대’와 닮았다는 비유

    • 이제 코드가 쉽게 대체될 수 있으면 오히려 부채 관점이 무의미해지는 것이 아닌가, 앞으로는 에러 나면 프로그래머가 AI에 코드 다시 짜달라고 할 테니 부담이 적어질 수도 있다는 역발상

    • 본인은 코드를 창조적이고 예술적 표현으로 보는 관점도 있음, 읽기 좋고 세련된 코드를 보면 아름다움을 바로 느낄 수 있던 경험 공유

  • FORTRAN 출시 초기(1954년)부터 “포트란은 코딩과 디버깅 자체를 없애줄 것”이라는 슬로건이 있었음을 상기시키는 링크 공유(BackusEtAl-Preliminary Report)

    • “지속적으로 틀리다가 문득 맞출 수도 있다”는, “터키 착각” 일화(예: 매일 밥받던 칠면조가 어느 날 도살되는 착각에서 유래, Turkey illusion) 공유

  • 이런 논의의 밑바닥에 있는 가정은 기술적 진보가 머지않아 한계에 다다른다는 기대인데, 만약 그게 틀리면, 언젠가는 AI가 전체 인프라·로그·재무·문서까지 파악해서 비즈니스까지 총괄적으로 이해·설계하는 날이 오지 말란 법 없다는 디딤돌, AI 모델은 아직 늘어나고 있고 기능은 더 좋아지고 저렴해지고 있어 결국 언젠가 대체의 본질까지 이른다는 쪽에 더 무게 싣기

    • 단 그 경우 AI가 만든 시스템이 점점 ‘외계인’처럼 불투명해지고, 기존 인간 중심 개발 생태계는 최소화될 위험, 여전히 일부 전문가가 AI의 소프트웨어 공학적 경로를 감시·조율하는 사회적 제어가 필수, 이 전환은 길고 복잡한 변화일 것이라는 전망

  • 개발자 해고는 기술 발전 때문이 아니라, 불확실성에 따른 후속 조치이며, 기술/AI 핑계는 사후적 변명이라는 시각, 5년 전만 해도 비용을 감수하고서라도 SW 엔지니어를 늘려 생산성 확대를 꾀했음을 예시로 듬, 따라서 비용이 근본이 아니라는 주장

    • “그 추가 생산성은 경제지표 어디에도 안 잡힌다”는 반론, 실제로 생산성이 늘었다면 경제 전체에서 확인되어야 하는데 그렇지 않다는 의구심
답변달기
▲
aer0700 7일전  [-]

저는 좀 보수적으로 일하는 사람이라, AI 툴을 중요한 업무에 도입해본 적은 없고, 구글이나 스택 오버플로에 검색하던 걸 제미나이나 CHATGPT에 물어보는 걸로 바꾼 정도? 사용하는 중이긴 한데...
AI에 뭐 만들어달라고 할 때, 함수 단위로 뭐 인풋 하면 뭐 나오는 함수 만들어달라고 해서 받고, AI가 만든 함수에서 받은 리턴 값이 제대로 나왔는지 검사하는 로직 정도는 스스로 작성하는 식으로 사용하면 괜찮지 않을까 생각하고 있어요.

답변달기
▲
dbs0829 8일전  [-]

모든 컨텍스트를 전부 AI가 잘 이해할 수 있는 형식으로 정리할 수 있을까?라는 질문에 저는 회의적입니다. 사람은 단순히 지금 당장 하는 개발에 표면적으로 필요한 컨텍스트 외에도 잠재된 컨텍스트를 가지고 있어서, 이런 부분들을 고려하며 개발하는데, 이 컨텍스트를 사람이 잘 정제된 표현으로 작성할 수 있다고 아직 생각되지 않아요. AI의 문제라기보다는 사람의 한계가 있을거라고 생각합니다. 특히 현대의 사람들의 글쓰기 능력이 저는 그닥 좋지 않다고 생각하기도 하고요.

답변달기
▲
geirdev 9일전  [-]

무서운건 지금 이순간이 아니라 추세 같아요..

답변달기
▲
hey23 9일전  [-]

지금은 전혀 다릅니다.

모든 직업이 대체당할 미래가 코앞이고 개발자는 그중 하나일 뿐이에요

이런건 유행한적 한번도 없습니다.

답변달기
▲
kaykim 9일전  [-]

정확히 똑같은 변화는 없었겠죠.

하지만 오래전 근대에 이미 많은 직업들이 거쳐갔던 변화입니다. 예를 들면, 사진의 등장으로 예술가들이, 자동화된 공장으로 공예가들이 겪었던 변화죠. 코딩이라고 다르지 않아보입니다.

저는 혁신이 일상화되면 결과적으로 지금보다 더 많은 엔지니어들이 필요해질 거라고 예상합니다. 사용자들의 눈높이가 더 높아질테고, 더 크고 복잡한 것을 만들어야 할테니까요. 마치 붉은 여왕 가설에서 말하는 것처럼요.

물론 일의 종류가 바뀌거나 특정 업무가 사라질 가능성은 높습니다. 마치 어느샌가 식자공이 사라진 것처럼요. 그 맥락에서 시스템을 설계한다는 건 아마도 더 높아진 추상화의 은유나 예시일테고요.

답변달기
▲
pcj9024 9일전  [-]

다들 개발자를 뭔가로 대체하고싶어서 그렇다고 봅니다
하는일도 없으면서 돈은 많이받는다고 생각하는 사람들이 상당히많은듯

답변달기
▲
draupnir 9일전  [-]

실제로 대체되는지와 상관없이 그런 내용이 계속 회자되는 이유는 자극적이기 때문이라고 생각합니다.
대부분 그런 헤드라인을 시원하게 뽑아내는 경우, 애초에 현실이 어떤지, 대체라고 하는 것을 어떻게 정의할 수 있는지에 대한 깊은 생각을 거친 결과물일 가능성이 없더라구요.
제대로 생각한 결과물은 오히려 AI나 다른 툴들이 현재 어디까지 할 수 있고 어디를 향해 발전하는 가를 다루게 되고. 그런 노잼 타이틀을 일반 사람이 클릭할 일은 없죠.

답변달기
▲
fanotify 9일전  [-]

자극적인 헤드라인이 많죠..

답변달기
▲
callakrsos 9일전  [-]

시스템 설계 측면도
프롬프팅에 보통 고려하지 않고 넣기 때문은 아닐지

답변달기
▲
ethanhur 10일전  [-]

공감합니다만 "시스템 설계" 보다는 "시스템 설계를 통한 복잡한 문제 해결"이 핵심 아닐까 싶습니다.

쉬운 일은 더 쉬워지고 어려운 일은 계속 더 어려워진다고 믿습니다.

답변달기