최근 "일회용 마케팅 랜딩 페이지" 같은 일을 프리랜서로 수정해 본 경험, 통제욕이 강한 고객들은 늘 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급 거대 기업이 아니라 중소기업은 무너질 위험
“지속적으로 틀리다가 문득 맞출 수도 있다”는, “터키 착각” 일화(예: 매일 밥받던 칠면조가 어느 날 도살되는 착각에서 유래, Turkey illusion) 공유
이런 논의의 밑바닥에 있는 가정은 기술적 진보가 머지않아 한계에 다다른다는 기대인데, 만약 그게 틀리면, 언젠가는 AI가 전체 인프라·로그·재무·문서까지 파악해서 비즈니스까지 총괄적으로 이해·설계하는 날이 오지 말란 법 없다는 디딤돌, AI 모델은 아직 늘어나고 있고 기능은 더 좋아지고 저렴해지고 있어 결국 언젠가 대체의 본질까지 이른다는 쪽에 더 무게 싣기
단 그 경우 AI가 만든 시스템이 점점 ‘외계인’처럼 불투명해지고, 기존 인간 중심 개발 생태계는 최소화될 위험, 여전히 일부 전문가가 AI의 소프트웨어 공학적 경로를 감시·조율하는 사회적 제어가 필수, 이 전환은 길고 복잡한 변화일 것이라는 전망
개발자 해고는 기술 발전 때문이 아니라, 불확실성에 따른 후속 조치이며, 기술/AI 핑계는 사후적 변명이라는 시각, 5년 전만 해도 비용을 감수하고서라도 SW 엔지니어를 늘려 생산성 확대를 꾀했음을 예시로 듬, 따라서 비용이 근본이 아니라는 주장
“그 추가 생산성은 경제지표 어디에도 안 잡힌다”는 반론, 실제로 생산성이 늘었다면 경제 전체에서 확인되어야 하는데 그렇지 않다는 의구심
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)
이런 논의의 밑바닥에 있는 가정은 기술적 진보가 머지않아 한계에 다다른다는 기대인데, 만약 그게 틀리면, 언젠가는 AI가 전체 인프라·로그·재무·문서까지 파악해서 비즈니스까지 총괄적으로 이해·설계하는 날이 오지 말란 법 없다는 디딤돌, AI 모델은 아직 늘어나고 있고 기능은 더 좋아지고 저렴해지고 있어 결국 언젠가 대체의 본질까지 이른다는 쪽에 더 무게 싣기
개발자 해고는 기술 발전 때문이 아니라, 불확실성에 따른 후속 조치이며, 기술/AI 핑계는 사후적 변명이라는 시각, 5년 전만 해도 비용을 감수하고서라도 SW 엔지니어를 늘려 생산성 확대를 꾀했음을 예시로 듬, 따라서 비용이 근본이 아니라는 주장