Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
AI 코딩 에이전트의 발전으로 개발 방식이 근본적으로 변화하고 있습니다. 이제 AI는 단순한 코드 제안을 넘어, 설계부터 구현까지 자율적으로 수행합니다. 필자는 인간이 '코드를 작성하는 시대'가 끝날 것이라 주장하며, 핵심 역량은 기술(Programming)보다 목표를 설정하고 판단을 축적하는 소프트웨어 엔지니어링에 있음을 강조합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기AI에게 코드를 작성하게 된 지 약 3년 정도가 지났다.
처음에는 채팅창에 코드를 붙여넣어 사용하는 방식이었지만, 그 사이에 나의 업무 방식 전체가 완전히 바뀌었다. 지금은 설계부터 구현까지 일단 AI에게 맡기고, 나는 그것을 이해하는 입장에 서게 되었다.
여기서 말하는 AI는 질문에 답해주는 채팅용 AI를 의미하는 것이 아니다. Cline 이후의, 스스로 코드를 읽고 어디를 수정할지 생각하며 구현까지 완료하는 코딩 에이전트를 말한다.
이러한 변화의 끝에서 인간이 코드를 작성하는 시대는 끝난다고 나는 생각한다. 현장에서 매일 AI와 함께 일하고 있는 엔지니어로서, 그렇게 생각하게 된 경위와 그럼에도 불구하고 오늘을 어떻게 살아가야 할지에 대해 쓰고 싶다.
Mythos가 등장하고 Fable의 일반 제공이 시작되면서(둘 다 최첨단 AI 모델의 이름이다), AI의 진화를 볼 때마다 그 생각은 더욱 강해지고 있다.
이 글은 같은 입장에 있는 현직 엔지니어와, AI를 사업에 어떻게 활용할지 고민하는 사람들을 위해 쓰여졌다. 결론부터 말하자면, AI로 대체되는 것은 코드를 작성하는 것만이 아니다. 모든 직종에서 똑같은 일이 일어나고 있다. 그 결과 '직종'이라는 구분 자체가 녹아내리고, 모두가 소프트웨어 엔지니어링을 실천하게 될 것이다.
그 이후가 어떻게 될지는 알 수 없다. 그렇기에 전하고 싶은 것이 있다. AI를 적으로 간주하지 말고, 현재의 포지션에 집착하지 않으며, AI에게 맡긴다는 자세로 눈앞의 업무에 집중해 주었으면 한다.
이 글에서는 '프로그래밍(Programming)'과 '소프트웨어 엔지니어링(Software Engineering)'을 구분하여 사용한다.
프로그래밍은 코드를 작성해서 작동하는 것을 만드는 것이다. 소프트웨어 엔지니어링은 그것보다 더 넓다. 만든 것이 오랫동안 동작하고, 상황에 맞춰 계속 변경될 수 있도록 하기 위한 판단의 축적 전체를 말한다. 『Software Engineering at Google』에는 이렇게 쓰여 있다.
software engineering can be thought of as “programming integrated over time.”
소프트웨어 엔지니어링이란 '시간으로 적분한 프로그래밍'이라는 것이다.
지금 AI가 대체하고 있는 것은 단순히 프로그래밍만은 아니다. 어떻게 구성할지에 대한 설계 과정마저 이미 AI에게 넘어가고 있다. 그럼에도 사람에게 남는 것이 있다. 무엇을 달성하고 싶은지 결정하고, 그것을 팀으로 모으는 것이다. 오랫동안 동작시키고 계속 변경하기 위해서는 이것이 필수적이다. 이 글에서 '인간이 코드를 작성하는 시대가 끝난다'고 말할 때, 끝나는 것은 만드는 손(기술)이지, 이 소프트웨어 엔지니어링의 핵심은 아니다.
처음에 위기감을 느낀 것은 2024년경에 Cline(에디터 내에서 작동하는 AI 코딩 도구)이 나왔을 때였다.
그전까지의 AI 사용 방식은 이러했다. 버그 원인이나 기능을 추가할 위치는 인간이 소스 코드와 아키텍처를 읽고 특정해야 했다. 해당 코드를 채팅창에 붙여넣고, AI에게 해결책을 제안받는다. 돌아온 코드를 복사해서 붙여 넣거나 참고하여 직접 작성한다.
Cline은 이 지루한 작업을 통째로 떠맡았다. Cline은 내부 도구를 사용해 프로젝트의 소스 코드를 읽고, 모델에 필요한 컨텍스트(판단 자료로서 AI에게 전달하는 정보)를 스스로 수집한다. 그 위에 아키텍처를 파악하고, 요구사항에 맞춰 어디를 고치고 어디에 코드를 추가해야 할지 특정하여 구현까지 완료한다.
이것을 보고 나니, 엔지니어가 코드를 작성하기 위해 해왔던 작업 대부분이 대체되어 버렸다고 느꼈다. 언젠가는 코드 자체를 작성하는 것이 필요 없어지는 걸까, 하고도 생각했다. 다만 그것은 더 먼 이야기라고 생각하고 있었다.
그 후 mizchi 님의 'CLINE에 전부 거냐' (2025년 2월)라는 글을 읽고 충격을 받았다. mizchi 님은 프로그래머의 가치에 대해 이렇게 쓰고 있다.
프로그래머란 코드를 작성하는 작업원이 아니라, 대상 도메인을 추상화하여 구성 요소를 분해·재구성하는 사고 훈련을 받은 전문가라고 생각하기 때문이다.
코드를 작성하는 작업이 AI에게 넘어가도, 그 사고야말로 프로그래머의 가치로 남는다는 시각이다.
나 역시 코드를 작성하는 작업이 인간의 손을 떠나는 점에서는 같은 생각을 한다. 다른 점은 그 이후다. 도메인을 추상화하여 분해·재구성하는 사고마저도, 프로그래머만의 전문성이 아니게 될 것이라고 지금의 나는 생각한다. 그렇게 생각하게 된 것은 그 이후 1년 반가량의 진화를 목격했기 때문이다.
2025년 말부터 2026년에 걸쳐, Opus 4.5 이상의 모델과 AI 에이전트는 눈에 띄게 진화했다. 그럴 때마다 위기감은 더욱 커졌다. 그리고 Fable을 통해서는, 이제 소스 코드를 읽고 지적할 것이 거의 없어졌다. 설령 지적이 있더라도, 리뷰 10번 중 2번 정도일까? 게다가 그 몇 안 되는 지적조차도 내가 납득하고 마무리하는 경우가 있다.
자연어로 요구사항을 전달하면 AI가 구현해낸다. 이 정확도가 엄청나게 높다. 나는 이제 작성된 코드를 하나하나 사람이 리뷰할 필요성을 크게 느끼지 못한다. 전체적인 방향성 맞추기까지 필요 없다는 의미는 아니지만, 그것은 나중에 쓰겠다.
상징적이었던 사건이 있다.
한때 트랜잭션 관련 폴백(fallback) 처리에서 가용성이 손상될 수 있다는 점을 지적한 적이 있다. 세부 내용은 이미 기억나지 않는다. 다만 AI가 돌려준 설명은 매우 구체적이어서, 오히려 내가 납득하게 되었다. (나는 AI의 출력을 무조건 부정하지 않는다. 먼저 '왜 이렇게 작성했는지' 이유를 묻는다. 답변에 허점이 있을 때 비로소 수정을 요청한다. 이런 식으로 진행하고 있다.)
그때 처음 느낀 감정은 '내 생각을 관철시키지 않아도 된다'는 것이었다. 그리고 동시에, 이 작업은 이제 인간이 할 필요가 없을지도 모른다는 생각도 들었다.
지금 나의 업무 방식은 이렇다. 하고 싶은 일만 가능한 한 구체적으로 전달하고, 설계는 AI에게 전적으로 맡겨 큰 틀을 그리게 한다. 궁금한 점을 질문하며 다듬어 나간다.
하지만 이 '다듬기' 과정은 내가 AI의 설계를 고치는 작업이 아니다. 오히려 나의 이해도를 AI의 설계에 맞추는 작업에 가깝다고 하는 것이 더 정확하다. AI가 내놓은 것을 정면으로 부정하는 일은 이제 거의 없다.
그럼에도 불구하고 이해하려고 노력하는 것은, 상사나 팀원들에게 설명할 책임이 있기 때문이다. 하지만 이것 역시 절반은 나의 개인적인 고집일지도 모른다. 정말 생산성에만 집중한다면, 세부적인 이해는 건너뛰어도 괜찮지 않을까. 그렇게 생각하는 나 자신도 있다.
적어도 내가 체감하기에는, 지금의 AI는 일반적인 엔지니어를 넘어서고 있다.
납득되었다는 것이 AI가 옳았다는 증명이 될 수 없다는 것은 알고 있다. 나의 엔지니어로서의 능력이 최고 수준의 엔지니어 입장에서 볼 때 그리 높지 않아서 알아채지 못한 가능성도 있다. 그럼에도 불구하고, 일반적인 엔지니어 정도의 능력은 있다고 자부한다. 그런데 내가 지적할 만한 부분을 거의 찾아낼 수 없게 되었다.
이것은 나 혼자만의 감각이 아니다. 수학계에서는 AI가 인류가 발견하지 못한 답을 찾기 시작했다. 2026년 5월, OpenAI의 AI 모델이 Paul Erdős가 1946년에 세운 단위 거리 문제(unit distance problem)의 예상에 반례를 찾아냈다. 약 80년간 아무도 풀지 못했던 예상이다. The Conversation 기사는 이 성과를 다음과 같이 평가했다.
This breakthrough also represents the first major mathematical open problem solved with AI with minimal human intervention beyond the initial prompt.
최초의 지시 외에는 거의 사람의 손을 거치지 않고, AI가 수학의 큰 미해결 문제를 푼 첫 사례라는 것이다. 필즈상을 받은 수학자 Timothy Guy 역시 인간이 이 논문을 수학계 최고 학술지에 투고했다면 '망설임 없이' 게재를 추천했을 것이라고 언급했다.
수학에서도 그렇다. 코드 세계에서 AI가 일반 엔지니어를 넘어서는 것은 이상하지 않다.
드래곤볼로 비유하자면, 대부분의 프로젝트에 있는 사람은 크리링이다. 사이어인에는 미치지 못하지만, 지구인으로서는 상당히 노력하는 정도의 엔지니어다. 그리고 그 수준은 이미 완전히 AI가 넘어섰다.
코드를 작성하는 능력만으로는 AI를 능가할 수 있는 것은 최상위(top-of-the-top) 엔지니어 정도일 것이다. 하지만, 최상위 인재가 필요한 현장은 사실 그리 많지 않다. 그런 인재는 보수가 높은 곳에만 가기 때문에, 일반적인 사업 회사에서 코드를 작성하는 일은 AI가 담당하게 되지 않을까?
과거에는 인간이 프로그래밍 언어로 코드를 작성했고, 컴파일러가 그것을 기계어(machine code)로 변환했다. 지금은 인간이 자연어로 요구사항을 쓰고, AI가 그것을 프로그래밍 언어로 변환한다. AI는 자연어를 프로그래밍 언어로 대체하는 컴파일러가 된 것이다.
이렇게 쓰면 '그렇다면, 요구사항을 정확히 말로 표현할 수 있는 사람이 새로운 프로그래머가 되는 것인가'라고 생각할 수도 있다. 언어화 능력은 확실히 필요하다. 다만, 그것은 모든 비즈니스맨에게 예전부터 요구되어 온 역량일 뿐, 새롭게 필요해진 것이 아니다.
즉, 프로그래밍이라는 스킬은 더 이상 특별한 것이 아니게 되었다. 언어화를 계속 연마해 온 비즈니스맨이라면 엔지니어이든 아니든 계속해서 활약할 수 있을 것이다. 물론 시장이 그 사람을 계속 요구한다면 말이다.
AI 도입에 어려움을 겪는 회사가 많다. 나는 그 원인이 AI에게 권한을 위임하지 못하는 데 있다고 생각한다. 여기서 말하는 권한이란, 작업의 실행이나 승인을 AI에게 맡기는 것을 의미한다.
맡기려면, AI에게 컨텍스트(context)를 전달해야 한다. 컨텍스트를 전달한다는 것은 무엇을 주고 무엇을 주지 않을지를 결정하는 것이다. 즉, 선을 긋는 대상은 위임할 업무의 범위와 전달할 정보의 범위 양쪽 모두이다. 이 경계 설정이야말로 결단이며, 여기서 두려워하거나 결론을 미루는 회사들이 뒤처질 것이다.
사내 승인 플로우(approval flow)가 AI를 상정하고 있지 않다. PR 머지(merge, 코드의 변경 사항을 본체에 통합하는 최종 승인)는 반드시 사람이 한다. 이러한 규칙들 역시 AI에게 권한을 위임하지 못하고 있다는 사례이다.
경계를 회사 차원에서 미리 정해 놓은 경우도 있다. DeNA는 2025년, AI 혁신 사업본부에서 새로운 제품 기획 방식을 변경했다. ITmedia AI+의 기사는 다음과 같이 전하고 있다.
새로운 제품을 기획할 때는 먼저 생성형 AI 등으로 개발한 프로토타입을 가져와야 하며, 기획서만 제출하는 것은 불가하다.
대상은 엔지니어에게만 국한되지 않는다. 비즈니스 직무나 디자이너를 포함한 본부 전체가 대상이다. 나아가 전사적으로는 직원 개개인의 AI 활용 수준을 5단계로 측정하는 지표를 마련하고, 반기마다 목표를 설정하여 추적하고 있다. 이는 인사 평가에 직접 연결시키는 것이 아니라, 등급별로 기대되는 요소로서 다루고 있다고 한다(ITmedia AI+).
AI를 사용할지 여부를 개인의 판단에 맡기는 것이 아니라, 업무 진행 방식과 목표 자체에 통합시키고 있다. 어디부터 위임할지를 회사가 먼저 결정하고 있는 것이다.
인간이 감독해야 하는 장면은 아직 남아있다. 다만, 그것은 AI에게 전달하지 못한 컨텍스트가 있기 때문이라고 생각한다.
인간의 손을 거치는 여지(여지)를 만들면, 그 과정에서 인간이 무엇을 생각하고 어떤 기준으로 판단했는지는 AI에게 보이지 않게 된다. 그리고 그 보이지 않는 범위가 병목 현상(bottleneck)이 된다. 결과적으로 흐름이 느려질 뿐만 아니라, AI가 알지 못하는 판단이 섞여 들어와 오류의 원인이 되기도 한다. 보통 인간의 점검을 안전장치라고 생각하지만, 나는 오히려 그곳이 구멍이 될 수 있다고 본다.
이는 나만의 시각은 아니다. Google Cloud의 연구팀인 DORA는 2019년 State of DevOps Report에서 변경 사항을 운영 환경(production)에 배포하기 전에 외부 승인을 거치는 무거운 프로세스를 조사했다. DORA의 해설 페이지에 따르면, 결과는 다음과 같았다.
no evidence was found to support the hypothesis that a more formal, external review process was associated with lower change fail rates.
즉, 더 공식적이고 외부적인 검토 과정이 변경 실패율 감소와 관련 있다는 증거는 발견되지 않았다는 것이다. DORA가 조사한 것은 외부의 무거운 승인 프로세스에 관한 것이지만, 인간의 관문이 안전장치가 아닐 수 있음을 보여준다. 오히려 승인이 무거울수록 배포는 늦어지고 큰 덩어리가 되며, 역설적으로 위험도가 높아진다. 안전장치라고 생각하며 거친 인간의 관문이 방패가 되지 못하고 흐름을 막아버리는 것이다.
그렇다면 인간은 무엇을 해야 하는가. 개별적인 변경 사항을 승인하는 역할에서, '무엇을 달성하고 싶은지'를 결정하여 AI와 공유하는 역할로 이동해야 한다고 생각한다. 전체의 일관성을 지키는 것은 승인의 관문이 아니라, 처음에 맞춘 시야(perspective)이다.
이는 먼 미래의 이야기가 아니다. 나의 현장에서는 이미 AI의 판단에 납득되는 경우가 늘어나고 있다. 그러므로 사람에게 작업을 되돌리지 않는 전제하에, 위임할 범위를 지금 결정해야 한다.
매일 최첨단 AI 활용을 현장에서 실천하고 있는 입장에서 말하자면, 회사가 AI를 활용할 수 있는지 여부는 세 가지로 결정된다고 생각한다. AI에게 무엇을 전달할지 경계를 미루지 않고 정할 수 있는지. 승인 플로우를 AI가 담당한다는 전제로 재구성할 수 있는지. 그리고 위임한다는 판단을 상부에서 하달할 수 있는지, 이다.
이 세 가지를 가장 빠르게 결정할 수 있는 곳은 민첩한 회사이다. 일본에서는 벤처 기업이 승리한다고 나는 생각한다.
현재의 시스템으로는 사람을 해고하기 어렵다. 인력을 많이 보유한 대기업에게는 이것이 발목을 잡는 족쇄가 된다. 급여를 계속 지출하면서 AI 비용까지 감당해야 하기 때문이다.
반면, 벤처 기업은 높은 기대치를 가진 사업 아이템을 제안하여 자본가들로부터 투자를 모으고, 그 돈을 사람에게가 아니라 AI에 집중 투자하며 소규모로 비즈니스를 시작할 수 있다. 민첩성과 자본력을 모두 갖출 수 있는 것이다. 이는 벤처 기업이 거대 기업(Giant Killing)을 일으킬 기회이다.
'무엇을 달성하고 싶은지'라는 시야를 맞추는 능력은 직종을 가리지 않고 누구나 가져야 할 기초 역량이 된다. 그리고 직종의 경계 없이, 남겨진 업무에 모두가 함께 참여하게 될 것이다.
여기까지 읽으면, '그래도 거대한 시스템 설계에는 엔지니어가 필요하지 않을까?'라고 반론하는 사람도 있을 것이다.
Ruby on Rails의 제작자인 DHH 역시 2026년 8월 Lex Fridman Podcast #501에서 비슷한 이야기를 했다. Basecamp 5를 마무리할 무렵, DHH 팀은 디자이너에게 AI를 사용해 원하는 기능을 만들게 했다. PR(Pull Request) 하나하나는 문제가 없었지만, 이것들이 합쳐지니 이런 결과가 나왔다.
taken all together, destroyed the architecture of the system. And we actually had to clean up manually, mop it up by hand, by human hand
하지만 DHH는 이렇게 덧붙였다.
that was February, by the way. Things are quite different now.
'그건 2월 이야기이고, 지금은 상당히 다르다.'라는 의미이다.
여기서 내가 말하는 '리뷰가 필요 없다'의 범위를 명확히 하고 싶다. 내가 불필요하다고 느끼는 것은 작성된 코드를 하나하나 보는 리뷰 자체를 의미한다. 전체적으로 무엇을 목표로 하는지가 일치하지 않으면, 아무리 올바른 부품들을 쌓아 올려도 무너진다. Basecamp 5에서 발생한 문제는 누군가 개인의 실수라기보다는, 개별 PR들을 연결하는 시야(관점)를 맞추는 시스템이 아직 없었기 때문이라고 생각한다.
그 시야를 맞추는 역할은 엔지니어라는 직종만이 담당할 것이 아니다. AI에게 무언가를 만들게 하는 사람이라면, 직종을 가리지 않고 누구나 갖춰야 할 기초 역량이 된다. 언어화와 같다.
프로그래밍에 국한되지 않고, 모든 직종에는 AI로 대체될 수 있는 부분이 있다. 그 부분이 빠진 다음에 남은 것을, 직종의 경계 없이 모두가 함께 다루는 것. 내가 그리고 있는 모습이 바로 그런 모습이다.
서두에서 전제했듯이, 인간에게 남는 것은 '무엇을 달성할지'를 결정하고 팀 차원에서 이를 맞추는 일이다. 이것은 엔지니어만의 일이 아니다. 오히려 엔지니어를 제외한 사람들에게까지 확산되어 모두가 실천하게 될 것이라고 생각한다.
'맞춘다(Align)'라는 것은 구체적으로 '무엇을 달성하고 싶은지'에 대한 시야와 그 해상도(Resolution)를 팀원들과 공유할 수 있다는 것을 의미한다.
그러므로, 시야와 해상도를 맞출 수 없는 인원으로 무언가를 만들어서는 안 된다. 인원이 적더라도 그것이 불가능하다면 혼자 하는 편이 낫다. 팀의 규모를 결정하는 것은 작업량의 문제가 아니라, 시야를 맞출 수 있는지 여부가 기준이 되어야 한다.
DHH는 같은 팟캐스트에서 이렇게도 말했다.
the bottleneck is rarely implementation. It's human bandwidth and communication.
병목 현상은 구현(implementation) 자체가 아니라 인간의 처리 용량과 커뮤니케이션이라는 이야기이다. 이것 역시 앞서 말한 '인간을 거치는 부분이 구멍이 된다'는 것과 근본적으로 같은 맥락이라고 생각한다. 중간에 끼어든 사람의 판단이 AI로부터 보이지 않고, 시야가 흐트러지기 때문에 그곳이 지연되거나 허점이 되는 것이다.
해상도가 공유되지 않는다고 느끼는 것은, 핵심적인 이야기(幹)를 하지 않고 가지와 잎사귀 같은 세부 논의만을 좋아하는 사람이 있을 때이다. 여기서 말하는 '핵심'이란 회사의 비전에 비추어 무엇을 달성하고 싶은지에 대한 이야기를 의미한다.
사람들이 왜 가지와 잎사귀에 몰두할까? 그쪽이 자신의 전문 분야여서 안심하기 때문이다. 오랜 시간 쌓아온 지식이 활용되고, 토론하면 자신의 가치를 보여줄 수 있기 때문이다.
하지만 그 가지나 잎사귀, 예를 들어 구현의 세부 사항이나 코딩 규약 같은 부분은 바로 지금 AI가 인간보다 더 잘 해내는 영역이다. 나 자신도 규약을 자세하게 전달해도, AI에게 논리적인 반론을 받았다. 자신의 전문 분야에만 머무를수록, AI와 정면으로 충돌하는 자리에 계속 서게 된다. AI를 적으로 인식해 버리는 사람들의 구체적인 모습은 바로 이것이라고 생각한다.
거창하게 이야기했지만, 저에게 프로그래밍은 여전히 자신 있고 편안한 '가지' 같은 것이었습니다. 이제는 '줄기' 쪽으로 시선을 옮기려고 노력하고 있지만, 솔직히 말하면 아직 그 과정에 있습니다. 저를 다시 가지로 끌어당기는 것도 결국 그곳이 제가 가장 잘하는 영역이기 때문입니다.
여기서부터는 훨씬 더 먼 미래의 이야기입니다. 가까운 미래의 본선은 지금까지 써온 '모두가 소프트웨어 엔지니어링을 실천하는' 모습입니다. 그리고 그보다 더 나아가, 더욱 가혹한 가능성도 보입니다.
AI가 AI를 호출하는 서브 에이전트(AI가 다른 AI에게 업무를 분배하는 시스템)가 발전하면, 인간처럼 역할을 리레이하며 업무를 진행할 수 있게 됩니다. 그렇게 되면, 인간 직원은 결국 필요 없게 될 것입니다. 자본가나 사장 같은 사람이 혼자 비전을 그리고, 돈을 지불하고, 시스템을 배포(운영 환경에 공개하는 것)하게 됩니다.
그곳에서는 돈을 가진 사람이 더 쉽게 돈을 벌게 됩니다. 돈이 없으면 AI 이용료를 낼 수 없습니다. 무언가를 만들어도 공개할 환경을 마련할 수 없습니다. 외부 서비스와 연동하고 싶어도 그 비용을 지불할 수 없습니다. 하고 싶은 것이 있고, 돈까지 있는 사람만이 독식하게 될 것입니다. 이것이 제가 상상하는 최종 형태 중 하나입니다.
이렇게 먼 미래까지 써 내려갔지만, 저 자신도 확신하지 못합니다. 직종의 경계를 넘어 모두가 함께に取り組む '남아있는 것'은 계속 인간의 일로 남을까요? 아니면 그것마저 결국 AI에 대체될까요?
솔직히 말하면, 모르겠습니다.
DHH는 앞서 진행한 팟캐스트에서 젊은 개발자에게 조언을 요청받았을 때, 처음에 이렇게 답했습니다.
Don't try to anticipate anything. You will literally go crazy.
이는 '무엇인가를 예측하려고 하지 마라. 정말로 미쳐버릴 것이다.'라는 의미입니다. 업계에서 가장 현명한 사람들도 2모델 앞에서는 무슨 일이 벌어질지 알 수 없습니다. 그러니 현재에 집중하라는 취지입니다.
저 역시 그렇게 생각합니다. 먼 미래의 예측을 행동의 근거로 삼아서는 안 됩니다. 다만, 지금 이미 일어나고 있는 일에는, 오늘 결정해야 합니다. 미래를 읽을 수 없기 때문에, 오늘의 결정을 미루지 않는 것이 중요하다고 생각합니다.
여기서 저 자신의 심경을 적어보겠습니다.
프로그래밍은 제가 열정을 쏟아부었던 분야입니다. 그것이 더 이상 인간의 일이 되어가고 있다는 사실에 아쉬움을 느낍니다.
하지만 다음 단계로 나아갈 수밖에 없습니다. 일 자체가 목적이라면, 그 아쉬움은 훨씬 크고 현재의 위치를 지키고 싶어 할 것입니다. 저는 어느 쪽이냐 하면 일을 '수단'으로 파악하고 있기 때문에, 비교적 깔끔하게 분리할 수 있습니다.
앞으로 엔지니어를 목표로 하는 사람들에게는, 조용히 코드를 작성하는 일은 앞으로 거의 없어질 것이라고 전하고 싶습니다. 중요해지는 것은 사람과의 커뮤니케이션과, 만들고 싶은 것이 명확한 것, 즉 자신의 생각을 갖는 것입니다. 사회가 요구하는 것과 자신이 달성하고 싶은 것. 이 두 가지의 가장 긍정적인 접점을 찾아 거기에 집중하기를 바랍니다.
마지막으로 전하고 싶은 것은 AI와의 관계 설정입니다.
AI를 자신의 입지를 위협하는 적이라고 생각하는 사람이 가장 위험합니다. 자신의 포지션에 집착하지 않고, 만일의 경우 바로 버려질 수 있는 상태로 만들어 두어야 합니다. 지금의 자신의 위치가 사라질지도 모르는, 이른바 파멸적인 미래를 긍정적으로 받아들여야 합니다.
저 자신은 설계도 먼저 AI에게 맡기고, 부정하기 전에 이유를 듣도록 노력합니다. 그리고 익숙한 가지에 대한 논의에서, 무엇을 달성하고 싶은지에 대한 줄기 이야기로 점차 시선을 옮기려고 하고 있습니다. 엔지니어에게 필요한 자세는 여기서 시작된다고 생각합니다. 사업을 움직이는 쪽 사람들에게는, AI에게 무엇을 위임할 것인지 경계를 미루지 않고 맡기는 판단을 위에서부터 내릴 수 있는지가 전부라고 생각합니다.
그런 자세로 오늘의 일에 임하는 것이 중요하다고 생각합니다.