<div id="readability-page-1" class="page"><article>
        <h2 id="AI-시대의-불안-앞에서"><a href="#AI-시대의-불안-앞에서" title="AI 시대의 불안 앞에서"></a>AI 시대의 불안 앞에서</h2><p>요즘 AI 이야기를 하다 보면 주변에서 뒤처지는 것 같다는 불안을 자주 듣게 된다. 새로운 도구와 새로운 방식이 쏟아지고, 이제 누구나 개발할 수 있는 시대가 오는 것처럼 이야기된다. 특히 기존 엔지니어일수록 이런 변화 앞에서 더 불안해하기 쉬운 것 같다.</p>
<p>나 역시 비슷한 고민을 했다. 이제 누구나 개발할 수 있는 시대라면 소프트웨어 엔지니어는 어떤 역할을 해야 할까. 무엇을 더 잘해야 하고, 무엇을 버려야 하며, 우리는 얼마나 달라져야 할까.</p>
<p>겉으로 보면 정말 많은 것이 바뀌고 있다. 예전에는 구현 자체가 큰 장벽이었다. 특히 현실의 개발은 새 기능만 만드는 일이 아니었다. 이미 돌아가고 있는 레거시 환경을 운영하고, 문제를 수습하고, 조금씩 개선해가면서 동시에 새로운 기능까지 만들어야 했다. 어려움은 단순히 무언가를 구현하는 데 있다기보다, 복잡한 맥락과 제약이 얽힌 상태에서 계속 앞으로 나아가야 한다는 점에 더 가까웠다. 지금도 그 본질은 크게 다르지 않다. 다만 AI는 코드를 빠르게 만들고 문서를 정리해주면서 여러 작업의 속도를 분명히 높여준다. 그래서 처음에는 이제 훨씬 쉬워지거나 빨라질 것 같다는 기대가 생긴다. 그런데 막상 해보면 생각만큼 쉽지도 않고, 기대한 만큼 빨라지지도 않는 경우가 많다.</p>
<p>이런 고민을 하면서 여러 글을 읽고 생각을 정리해보니, 내 생각은 오히려 다른 쪽으로 갔다. 바뀐 건 많지만, 그 변화의 상당수는 작업 방식에 가깝다는 쪽이다. 코드를 입력하는 방식, 초안을 만드는 방식, 지식을 찾는 방식은 달라졌지만 소프트웨어를 만드는 일의 중심에는 여전히 크게 변하지 않은 것들이 남아 있다.</p>
<h2 id="만들기-쉬워질수록-문제에서-멀어진다"><a href="#만들기-쉬워질수록-문제에서-멀어진다" title="만들기 쉬워질수록 문제에서 멀어진다"></a>만들기 쉬워질수록 문제에서 멀어진다</h2><p>최근에 읽은 <a target="_blank" rel="noopener" href="https://notes.visaint.space/ai-coding-is-gambling/">AI Coding is Gambling</a>이라는 글은 AI 코딩이 마치 프롬프트를 넣고 원하는 결과가 나올 때까지 계속 레버를 당기는 일과 비슷하다고 말한다. 문제를 더 잘 이해해서 앞으로 나아간다기보다, 이번에는 좀 괜찮은 결과가 나오기를 기대하면서 계속 시도하게 된다는 것이다. 이 비유가 흥미로웠던 이유는, AI를 쓰다 보면 문제를 깊이 이해하는 일보다 그럴듯한 결과를 빨리 얻는 쪽으로 쉽게 기울 수 있다는 점을 꽤 잘 보여준다고 느꼈기 때문이다.</p>
<p>물론 이런 함정이 AI 때문에 새롭게 생긴 것은 아니다. 원래도 사람들은 고객의 문제를 깊이 이해하기보다, 고객이 말한 솔루션을 빠르게 만들어주는 쪽으로 자주 기울곤 했다. 문제를 제대로 이해하다 보면 고객이 처음 말한 방향과 다른 해석이나 다른 해결책이 나올 수 있고, 그러면 그걸 다시 설명하고 설득하는 과정이 필요해진다. 반면 고객이 말한 솔루션을 바로 만드는 쪽은 더 빠르고, 눈에 보이는 결과도 빨리 나온다.</p>
<p>예전에는 그나마 구현 비용이 커서 함부로 “일단 만들어보자”로 가기 어려웠다. 기능이 정말 필요한지, 어떤 제약이 있는지, 기존 시스템과 어떻게 연결되는지 조금 더 오래 생각할 수밖에 없었다. 하지만 이제는 그 문턱이 훨씬 낮아졌다. 그래서 원래도 하던 실수를 더 쉽게, 더 빠르게 반복하게 된다. 문제의 본질보다 솔루션 생산 자체에 집중하게 되고, 무엇을 왜 만드는가보다 무엇이든 빨리 만들어내는 일이 더 중요해지기 쉽다. 그러면 앞에서 충분히 생각하는 시간은 줄고, 뒤에서는 엉성하게 만들어진 결과물을 수습하는 일만 남는다.</p>
<h2 id="AI는-사고를-증폭한다"><a href="#AI는-사고를-증폭한다" title="AI는 사고를 증폭한다"></a>AI는 사고를 증폭한다</h2><p>여기서 1991년에 나온 QSM 1의 서문에서 제럴드 와인버그가 한 말이 떠올랐다.</p>
<blockquote>
<p>The computer, I learned, was a mirror of my intelligence, and I wasn’t too impressed by my reflection.<br>Later, when I wrote larger programs in concert with other people, I learned that the computer was not just a mirror, but a magnifying mirror.</p>
</blockquote>
<p>와인버그는 컴퓨터가 인간의 사고를 그대로 비추는 데서 그치지 않고, 더 큰 프로젝트에서는 그것을 더 크게 확대해서 드러낸다고 봤다. 이 말이 1991년에 나온 책의 이야기인데도 지금 AI 시대를 설명하는 데 여전히 잘 들어맞는다는 점이 흥미롭다. 결국 AI도 비슷하다. 인간의 사고를 대체하기보다 오히려 증폭한다. 방향이 맞으면 더 멀리 갈 수 있고, 방향이 틀리면 더 빠르게 잘못된 곳으로 간다. 예전에는 생각이 부족하면 결과물도 대체로 허술해서 문제가 비교적 빨리 드러났다. 이제는 생각이 부족해도 겉보기에는 그럴듯한 결과가 빠르게 나오기 때문에, 더 늦게 이상을 알아차리거나 더 큰 비용을 치른 뒤에 문제를 발견하기 쉬워졌다.</p>
<p>최근에 들은 InfoQ 팟캐스트 <a target="_blank" rel="noopener" href="https://www.infoq.com/podcasts/team-strengths-weaknesses-software-development/">AI Amplifies Team Strengths and Weaknesses in Software Development</a>도 비슷한 이야기를 한다. 많은 팀들이 원래도 명확한 스펙, 공동의 책임감, 빠른 피드백, 협업 같은 기본기에서 어려움을 겪고 있었고, AI는 그런 문제를 대신 해결해주지 않는다는 것이다. 오히려 코드 생성만 빨라지면, 기본기가 좋은 팀은 그 속도를 전체 흐름의 개선으로 이어갈 수 있지만 기본기가 약한 팀은 리뷰, 디버깅, 정렬되지 않은 요구사항 같은 다른 지점에서 병목이 더 크게 드러난다. 그래서 그 팟캐스트는 AI를 cure가 아니라 amplifier라고 부른다. 결국 와인버그의 말과 InfoQ 팟캐스트에서 나온 이야기는 비슷한 방향을 가리키고 있다. AI는 소프트웨어 개발의 새로운 본질을 만드는 것이 아니라, 원래 있던 강점과 약점, 그리고 본질을 더 선명하게 드러낸다.</p>
<h2 id="소프트웨어-개발의-본질은-여전히-같다"><a href="#소프트웨어-개발의-본질은-여전히-같다" title="소프트웨어 개발의 본질은 여전히 같다"></a>소프트웨어 개발의 본질은 여전히 같다</h2><p>내가 보기에 소프트웨어 개발의 본질은 여전히 현실을 모델링하는 일이다. 예를 들어 주문, 고객, 재고 같은 개념들이 어떤 관계를 맺고 어떤 상태 변화를 거치는지, 그 사이에 어떤 규칙과 제약이 있는지를 코드로 옮기는 일이다. 이건 단순히 코드를 생성하는 능력만으로 해결되지 않는다. 무엇이 중요한 규칙인지, 어떤 예외가 치명적인지, 어디까지를 시스템이 책임져야 하는지를 이해해야 한다.</p>
<p>소프트웨어 개발은 결국 변화를 다루는 일이기도 하다. 처음 만드는 것보다 더 어려운 것은, 계속 바뀌는 요구사항과 맥락 속에서 시스템을 수정해나가는 일이다. AI는 변경을 고려한 것처럼 보이는 구조를 내놓기도 하지만, 실제 맥락과 맞지 않는 추상화나 오버엔지니어링으로 흐르는 경우도 많다. 결국 어떤 변화를 대비해야 하는지 판단하는 일은 여전히 사람의 몫이다.</p>
<p>또 실제 현장에서는 코드 자체보다, 무엇을 만들고 있는지에 대한 이해가 더 자주 어긋난다. 어떤 문제를 풀고 있는지, 누가 어떤 제약을 중요하게 보는지를 서로 다르게 이해한 채 개발이 진행되기 때문이다. 이런 상태에서는 코드가 기술적으로 맞더라도, 정작 사용자가 원하는 문제를 풀지 못하거나 팀이 기대한 방향과 다른 결과물이 나오기 쉽다.</p>
<h2 id="소프트웨어-엔지니어의-역할도-변하지-않는다"><a href="#소프트웨어-엔지니어의-역할도-변하지-않는다" title="소프트웨어 엔지니어의 역할도 변하지 않는다"></a>소프트웨어 엔지니어의 역할도 변하지 않는다</h2><p>나는 소프트웨어 개발의 본질이 크게 달라지지 않은 것처럼, 소프트웨어 엔지니어의 역할도 생각보다 크게 달라지지 않는다고 생각한다. 여전히 중요한 사람은 코드를 가장 빨리 찍어내는 사람이 아니라, 현실을 정확히 이해하고, 복잡한 상황에서 중요한 것을 구분하고, 무엇을 포기하고 무엇을 지켜야 할지를 끝까지 판단할 수 있는 사람이다.</p>
<p>AI는 답을 더 빨리 만들어주고 개발의 방식과 속도를 많이 바꾸고 있지만, 무엇이 중요한 문제인지 대신 정해주지는 않는다. 어떤 제약이 진짜 제약인지, 그럴듯한 답과 맞는 답을 어떻게 구분할지, 어떤 구조와 선택이 실제 맥락에 맞는지를 판단하는 책임은 여전히 사람에게 남아 있다. 그래서 나는 AI 시대일수록 불안 그 자체에 휩쓸리기보다, 원래 소프트웨어 엔지니어가 해오던 역할의 본질에 더 집중해야 한다고 생각한다. 문제를 정확히 이해하고, 중요한 제약을 구분하고, 끝까지 판단하는 일 말이다.</p>
<h2 id="참고한-글"><a href="#참고한-글" title="참고한 글"></a>참고한 글</h2><ul>
<li><a target="_blank" rel="noopener" href="https://notes.visaint.space/ai-coding-is-gambling/">AI Coding is Gambling</a></li>
<li><a target="_blank" rel="noopener" href="https://www.infoq.com/podcasts/team-strengths-weaknesses-software-development/">AI Amplifies Team Strengths and Weaknesses in Software Development</a></li>
</ul>

    </article></div>

wonderland

AI 시대의 불안 앞에서
요즘 AI 이야기를 하다 보면 주변에서 뒤처지는 것 같다는 불안을 자주 듣게 된다. 새로운 도구와 새로운 방식이 쏟아지고, 이제 누구나 개발할 수 있는 시대가 오는 것처럼 이야기된다. 특히 기존 엔지니어일수록 이런 변화 앞에서 더 불안해하기 쉬운 것 같다.
나 역시 비슷한 고민을 했다. 이제 누구나 개발할 수 있는 시대라면 소프트웨어 엔지니어는 어떤 역할을 해야 할까. 무엇을 더 잘해야 하고, 무엇을 버려야 하며, 우리는 얼마나 달라져야 할까.
겉으로 보면 정말 많은 것이 바뀌고 있다. 예전에는 구현 자체가 큰 장벽이었다. 특히 현실의 개발은 새 기능만 만드는 일이 아니었다. 이미 돌아가고 있는 레거시 환경을 운영하고, 문제를 수습하고, 조금씩 개선해가면서 동시에 새로운 기능까지 만들어야 했다. 어려움은 단순히 무언가를 구현하는 데 있다기보다, 복잡한 맥락과 제약이 얽힌 상태에서 계속 앞으로 나아가야 한다는 점에 더 가까웠다. 지금도 그 본질은 크게 다르지 않다. 다만 AI는 코드를 빠르게 만들고 문서를 정리해주면서 여러 작업의 속도를 분명히 높여준다. 그래서 처음에는 이제 훨씬 쉬워지거나 빨라질 것 같다는 기대가 생긴다. 그런데 막상 해보면 생각만큼 쉽지도 않고, 기대한 만큼 빨라지지도 않는 경우가 많다.
이런 고민을 하면서 여러 글을 읽고 생각을 정리해보니, 내 생각은 오히려 다른 쪽으로 갔다. 바뀐 건 많지만, 그 변화의 상당수는 작업 방식에 가깝다는 쪽이다. 코드를 입력하는 방식, 초안을 만드는 방식, 지식을 찾는 방식은 달라졌지만 소프트웨어를 만드는 일의 중심에는 여전히 크게 변하지 않은 것들이 남아 있다.
만들기 쉬워질수록 문제에서 멀어진다
최근에 읽은 AI Coding is Gambling이라는 글은 AI 코딩이 마치 프롬프트를 넣고 원하는 결과가 나올 때까지 계속 레버를 당기는 일과 비슷하다고 말한다. 문제를 더 잘 이해해서 앞으로 나아간다기보다, 이번에는 좀 괜찮은 결과가 나오기를 기대하면서 계속 시도하게 된다는 것이다. 이 비유가 흥미로웠던 이유는, AI를 쓰다 보면 문제를 깊이 이해하는 일보다 그럴듯한 결과를 빨리 얻는 쪽으로 쉽게 기울 수 있다는 점을 꽤 잘 보여준다고 느꼈기 때문이다.
물론 이런 함정이 AI 때문에 새롭게 생긴 것은 아니다. 원래도 사람들은 고객의 문제를 깊이 이해하기보다, 고객이 말한 솔루션을 빠르게 만들어주는 쪽으로 자주 기울곤 했다. 문제를 제대로 이해하다 보면 고객이 처음 말한 방향과 다른 해석이나 다른 해결책이 나올 수 있고, 그러면 그걸 다시 설명하고 설득하는 과정이 필요해진다. 반면 고객이 말한 솔루션을 바로 만드는 쪽은 더 빠르고, 눈에 보이는 결과도 빨리 나온다.
예전에는 그나마 구현 비용이 커서 함부로 “일단 만들어보자”로 가기 어려웠다. 기능이 정말 필요한지, 어떤 제약이 있는지, 기존 시스템과 어떻게 연결되는지 조금 더 오래 생각할 수밖에 없었다. 하지만 이제는 그 문턱이 훨씬 낮아졌다. 그래서 원래도 하던 실수를 더 쉽게, 더 빠르게 반복하게 된다. 문제의 본질보다 솔루션 생산 자체에 집중하게 되고, 무엇을 왜 만드는가보다 무엇이든 빨리 만들어내는 일이 더 중요해지기 쉽다. 그러면 앞에서 충분히 생각하는 시간은 줄고, 뒤에서는 엉성하게 만들어진 결과물을 수습하는 일만 남는다.
AI는 사고를 증폭한다
여기서 1991년에 나온 QSM 1의 서문에서 제럴드 와인버그가 한 말이 떠올랐다.
The computer, I learned, was a mirror of my intelligence, and I wasn’t too impressed by my reflection.
Later, when I wrote larger programs in concert with other people, I learned that the computer was not just a mirror, but a magnifying mirror.
와인버그는 컴퓨터가 인간의 사고를 그대로 비추는 데서 그치지 않고, 더 큰 프로젝트에서는 그것을 더 크게 확대해서 드러낸다고 봤다. 이 말이 1991년에 나온 책의 이야기인데도 지금 AI 시대를 설명하는 데 여전히 잘 들어맞는다는 점이 흥미롭다. 결국 AI도 비슷하다. 인간의 사고를 대체하기보다 오히려 증폭한다. 방향이 맞으면 더 멀리 갈 수 있고, 방향이 틀리면 더 빠르게 잘못된 곳으로 간다. 예전에는 생각이 부족하면 결과물도 대체로 허술해서 문제가 비교적 빨리 드러났다. 이제는 생각이 부족해도 겉보기에는 그럴듯한 결과가 빠르게 나오기 때문에, 더 늦게 이상을 알아차리거나 더 큰 비용을 치른 뒤에 문제를 발견하기 쉬워졌다.
최근에 들은 InfoQ 팟캐스트 AI Amplifies Team Strengths and Weaknesses in Software Development도 비슷한 이야기를 한다. 많은 팀들이 원래도 명확한 스펙, 공동의 책임감, 빠른 피드백, 협업 같은 기본기에서 어려움을 겪고 있었고, AI는 그런 문제를 대신 해결해주지 않는다는 것이다. 오히려 코드 생성만 빨라지면, 기본기가 좋은 팀은 그 속도를 전체 흐름의 개선으로 이어갈 수 있지만 기본기가 약한 팀은 리뷰, 디버깅, 정렬되지 않은 요구사항 같은 다른 지점에서 병목이 더 크게 드러난다. 그래서 그 팟캐스트는 AI를 cure가 아니라 amplifier라고 부른다. 결국 와인버그의 말과 InfoQ 팟캐스트에서 나온 이야기는 비슷한 방향을 가리키고 있다. AI는 소프트웨어 개발의 새로운 본질을 만드는 것이 아니라, 원래 있던 강점과 약점, 그리고 본질을 더 선명하게 드러낸다.
소프트웨어 개발의 본질은 여전히 같다
내가 보기에 소프트웨어 개발의 본질은 여전히 현실을 모델링하는 일이다. 예를 들어 주문, 고객, 재고 같은 개념들이 어떤 관계를 맺고 어떤 상태 변화를 거치는지, 그 사이에 어떤 규칙과 제약이 있는지를 코드로 옮기는 일이다. 이건 단순히 코드를 생성하는 능력만으로 해결되지 않는다. 무엇이 중요한 규칙인지, 어떤 예외가 치명적인지, 어디까지를 시스템이 책임져야 하는지를 이해해야 한다.
소프트웨어 개발은 결국 변화를 다루는 일이기도 하다. 처음 만드는 것보다 더 어려운 것은, 계속 바뀌는 요구사항과 맥락 속에서 시스템을 수정해나가는 일이다. AI는 변경을 고려한 것처럼 보이는 구조를 내놓기도 하지만, 실제 맥락과 맞지 않는 추상화나 오버엔지니어링으로 흐르는 경우도 많다. 결국 어떤 변화를 대비해야 하는지 판단하는 일은 여전히 사람의 몫이다.
또 실제 현장에서는 코드 자체보다, 무엇을 만들고 있는지에 대한 이해가 더 자주 어긋난다. 어떤 문제를 풀고 있는지, 누가 어떤 제약을 중요하게 보는지를 서로 다르게 이해한 채 개발이 진행되기 때문이다. 이런 상태에서는 코드가 기술적으로 맞더라도, 정작 사용자가 원하는 문제를 풀지 못하거나 팀이 기대한 방향과 다른 결과물이 나오기 쉽다.
소프트웨어 엔지니어의 역할도 변하지 않는다
나는 소프트웨어 개발의 본질이 크게 달라지지 않은 것처럼, 소프트웨어 엔지니어의 역할도 생각보다 크게 달라지지 않는다고 생각한다. 여전히 중요한 사람은 코드를 가장 빨리 찍어내는 사람이 아니라, 현실을 정확히 이해하고, 복잡한 상황에서 중요한 것을 구분하고, 무엇을 포기하고 무엇을 지켜야 할지를 끝까지 판단할 수 있는 사람이다.
AI는 답을 더 빨리 만들어주고 개발의 방식과 속도를 많이 바꾸고 있지만, 무엇이 중요한 문제인지 대신 정해주지는 않는다. 어떤 제약이 진짜 제약인지, 그럴듯한 답과 맞는 답을 어떻게 구분할지, 어떤 구조와 선택이 실제 맥락에 맞는지를 판단하는 책임은 여전히 사람에게 남아 있다. 그래서 나는 AI 시대일수록 불안 그 자체에 휩쓸리기보다, 원래 소프트웨어 엔지니어가 해오던 역할의 본질에 더 집중해야 한다고 생각한다. 문제를 정확히 이해하고, 중요한 제약을 구분하고, 끝까지 판단하는 일 말이다.
참고한 글
AI Coding is Gambling
AI Amplifies Team Strengths and Weaknesses in Software Development

AI 시대, 더 선명해진 소프트웨어 개발의 본질

댓글