#01 「만들 수 있다」는 더 이상 무기가 아니다. 앞으로는 「꿰뚫어 보는 능력」이 요구되는 시대

이 기사는 연재 시리즈 「생성 AI 시대, 엔지니어는 무엇으로 먹고사는가」의 도입편 #01입니다.

• #01 「만들 수 있다」는 더 이상 무기가 아니다. 앞으로는 「꿰뚫어 보는 능력」이 요구되는 시대 ← 현재 위치
• #02 PM·SE·PG라는 역할은 사라진다. 대신 다가오는 것은 아직 이름도 없는 직종이다
• #03 변화의 파도에 휩쓸리지 않기 위해. 지금 바로 할 수 있는 3가지 방향 전환

코드를 작성할 수 있다는 것 자체의 시장 가치는 확실히 낮아지고 있습니다.

이것은 협박이 아니라 현실입니다.

GitHub Copilot을 사용하면 간단한 기능이라면 몇 분 만에 형태를 갖출 수 있습니다. Claude Code에 의존하면 설계의 골격까지 뽑아줍니다. 「제로(Zero)에서 작성한다」는 작업의 가치가 엄청난 속도로 희박해지고 있습니다.

실제로 현장에서 느끼고 계신 분들도 많을 것입니다. 「이거, AI에게 부탁했으면 5분 만에 작성했을 내용이네」라는 상황이 1년 전보다 분명히 늘었습니다.

문득 제조업의 역사가 떠올랐습니다.

공장에 기계가 도입되었을 때, 숙련된 장인이 「손으로 만드는」 기술은 필요 없게 되었습니다. 용접공(Welder)도, 선반공도 기계가 정밀하게 대체하게 되었습니다.

하지만——대신 늘어난 것이 **「검품(Inspection)」**이라는 업무였습니다.

기계가 만든 것이 정말 사용할 수 있는지 눈과 손, 경험으로 확인하는 사람들. 「이 부분의 버(Burr, 거친 부분)가 제품 수명에 영향을 준다」, 「이 공차는 스펙상 OK지만 현장에서는 문제가 된다」——그러한 판단을 내릴 수 있는 사람의 가치는 오히려 올라갔습니다.

이것이 지금의 소프트웨어 개발과 완전히 같은 구도라고 생각합니다.

제조업 (기계화 후)	소프트웨어 개발 (AI 도입 후)
기계가 부품을 제조	AI가 코드를 생성
...	...

그렇다면 구체적으로, 「꿰뚫어 보는 힘」이란 무엇을 보는 것일까요. 제가 현장에서 의식하게 된 포인트들을 정리해 보겠습니다.

AI가 생성한 코드는 놀라울 정도로 「겉보기에는 동작하는」 경우가 많습니다. 하지만 동작하는 것과 올바른 것은 별개입니다.

예를 들어 데이터베이스(Database) 액세스 처리. AI는 SQL 인젝션(SQL Injection) 대책을 잊어버릴 때가 있습니다. 동작 확인 시에는 문제없이 보이지만, 악의적인 사용자가 나타나면 끝입니다. 이런 것을 「동작하니까 OK」라며 통과시켜 버리는 것이 지금 가장 무서운 패턴이라고 생각합니다.

코드 리뷰(Code Review)에서 「왜 여기에 이 로직이 필요한가?」라고 물으면, AI에게 생성을 시킨 본인이 대답하지 못하는 케이스가 나오고 있습니다.

생성 AI는 문맥(Context)을 모른 채 패턴 매칭(Pattern Matching)으로 코드를 작성합니다. 따라서 「이 API의 사양상 여기서 에러 핸들링(Error Handling)이 필요한 이유」를 이해한 상태에서 작성하는 것이 아닙니다.

자신이 작성한 코드의 의도를 설명할 수 없는 것은 필사(Copying)와 같습니다. 그 자체는 나쁘지 않지만, 설명 책임을 지는 엔지니어로서는 리스크가 됩니다.

AI는 요구사항의 배후에 있는 「왜 그 규칙이 존재하는가」를 모릅니다.

예를 들어 「사용자가 탈퇴하면 데이터를 삭제한다」라는 기능을 AI에게 구현하게 했다고 가정했을 때, 법적인 보존 의무가 있는 데이터까지 삭제하는 코드를 생성해 버리는 일이 발생합니다. 이것은 코드로서는 올바르게 보일지 몰라도, 비즈니스 측면에서는 치명적인 실수입니다.

동작하고 있고 요구사항도 충족한다. 하지만 3개월 뒤에 누군가가 코드를 만졌을 때, 이해할 수 있는가?가 포인트입니다.

AI는 「지금」 동작하는 것을 만드는 데는 능숙하지만, 「미래의 인간이 읽고 수정하기 쉬운」 코드를 의식적으로 작성하는 것은 아직 서툽니다. 변수명이 의미 불명이라거나, 동일한 로직이 여기저기 흩어져 있는 등의 일이 발생합니다.

제조업의 검품자가 단순히 「보기만 하는」 사람이 아닌 것처럼, 앞으로의 엔지니어도 「리뷰만 하는」 것이 아니라, AI의 아웃풋을 올바르게 평가·개선하고 책임을 질 수 있는 사람이 되어야 합니다.

그것은 결국 다음과 같은 것이라고 생각합니다.

• 코드를 작성하는 속도가 아니라, 코드를 읽고 이해하는 깊이
• 구현 지식이 아니라, 왜 그 구현이 필요한지에 대한 문맥(Context) 이해
• 「동작했다」의 확인이 아니라, 「이대로 괜찮은가」에 대한 종합적인 판단력

코드를 작성할 수 있다는 것에 자부심을 가져온 분들에게는 조금 아픈 이야기일지도 모릅니다. 저 자신도 그랬습니다. 하지만 이것은 제대로 마주해 두어야 할 변화라고 생각합니다.

• 생성 AI에 의해 「코드를 작성하는」 행위의 시장 가치는 낮아지고 있다
• 제조업의 기계화 이후 「검품자」의 가치가 올라간 것처럼, 「AI의 아웃풋을 꿰뚫어 보는 힘」이 다음의 중심이 된다
• 「동작함」뿐만 아니라 「올바름·안전함·설명 가능함·미래에도 사용 가능함」을 판단할 수 있는 것이 중요하다

다음 회 #02에서는 PM(Project Manager)・SE(System Engineer)・PG(Programmer)라는 역할 자체가 어떻게 변해갈지, 그리고 완전히 새로운 직종의 전조에 대해 쓰겠습니다.

이 연재는 현장에서 느낀 점이나 자신의 생각을 솔직하게 적고 있습니다. "우리 현장은 이렇다"라는 의견, 대환영입니다. 댓글로 알려주시면 감사하겠습니다.