#03 변화의 파도에 휩쓸리지 않기 위해. 지금 바로 할 수 있는 3가지 방향 전환

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

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

#01・#02를 읽어주신 분들, 감사합니다. 「가치가 변한다」 「역할(Role)이 변한다」 —— 그렇게 말해도, 「그럼 지금부터 무엇을 해야 하는가」라는 이야기가 가장 궁금한 부분일 것입니다.

저 자신도 답을 찾으면서 지난 1년 정도 여러 가지를 시도해 왔습니다. 이 기사에서는 그 과정에서 보이기 시작한 「방향성」 3가지를 공유합니다.

「이것만 하면 무조건 괜찮다」라는 마법 같은 정답은 아닙니다. 하지만 적어도 「이것을 해두면 방향은 어긋나지 않는다」라고 확신하는 3가지입니다.

가장 먼저 해야 할 일은, AI의 아웃풋(Output)을 비판적으로・언어화하여 평가할 수 있게 되는 것입니다.

「왠지 이상한 것 같다」에서 멈춰 있는 동안에는 AI 툴의 유저와 다를 바 없습니다. 「어디가, 왜, 어떻게 문제인지」를 설명할 수 있어야 비로소 엔지니어로서의 가치가 나옵니다.

① AI에게 의도적으로 틀린 코드를 작성하게 하여, 그 허점을 찾는 연습을 한다

예를 들어 다음과 같은 프롬프트(Prompt)를 시도해 보세요.

다음 사양으로 코드를 작성해 주세요.
단, 의도적으로 보안상의 문제를 1~2개 포함해 주세요.
그 후, 「어디에 문제가 있는지」를 문제가 포함되지 않은 버전과 비교하여 설명해 주세요.
...

이런 연습을 반복하면 「AI가 범하기 쉬운 실수 패턴」이 보이기 시작합니다.

② 코드 리뷰(Code Review)의 관점을 언어화하여 문서화한다

당신이 지금까지 감각적으로 해왔던 리뷰의 관점 —— 그것을 문장으로 만들어 보세요. 「이 패턴은 위험하다」 「이 방식은 나중에 막힌다」라는 지식이 언어화되어 있다면, AI의 아웃풋 평가에도 그대로 사용할 수 있습니다.

③ AI와 「토론하는」 습관을 들인다

AI가 내놓은 코드나 설계에 대해, 「왜 이런 구현을 했는지」 「다른 방법과 비교하면 어떤지」 「이 접근 방식의 단점은 무엇인지」라고 질문해 보는 것입니다. AI의 대답이 옳은지 스스로 판단하는 훈련이 됩니다.

AI는 코드를 작성할 수는 있어도, 「이 업계의 상관습상 이것은 절대 안 된다」라는 판단은 할 수 없습니다.

특정 도메인(Domain)에 정통한 엔지니어는 앞으로 희소해질 것입니다.

AI가 서툰 것은 「겉으로 드러나지 않는 규칙」을 아는 것입니다.

예를 들어 금융 업계라면, 「이 처리는 일본은행(Bank of Japan)의 규제상 로그를 몇 년간 보존해야 한다」라거나 「이 금액의 임계치를 넘으면 자동으로 상급자 승인 플로우가 필요하다」와 같은 —— 그런 지식은 문서를 읽는 것만으로는 얻을 수 없는, 현장에서만 익힐 수 있는 지식입니다.

의료·간병, 제조, 물류, 공공 —— 어느 업계든 외부에서는 보이지 않는 「암묵적인 규칙」이 있습니다. 그곳을 알고 있는 엔지니어는 AI와 결합했을 때 압도적으로 강합니다.

① 현재 현장의 도메인을 「심화」하는 데 시간을 쓴다

기술 공부만 하는 것이 아니라, 자신이 개발하고 있는 프로덕트(Product)의 비즈니스 모델(Business Model), 업계 규제, 유저의 실제 업무 플로우(Flow)를 이해하는 데 의식적으로 시간을 사용합니다.

PM이나 비즈니스 사이드(Business Side) 사람들과 대화하는 시간을 늘리는 것도 유효합니다.

② 도메인의 「왜」를 물을 수 있는 관계를 만든다

「이 사양, 왜 이렇게 되어 있나요?」라고 가볍게 물을 수 있는 관계가 도메인 지식을 빠르게 심화하는 최단 루트입니다. 업무 요건의 배경을 이해하면 AI에 대한 지시(Instruction)의 정밀도도 올라갑니다.

③ 자신의 도메인 지식을 아웃풋(Output)한다

기술 블로그도 좋고 사내 문서도 좋습니다. 「엔지니어의 시선으로 이 업계를 이야기한다」는 콘텐츠를 만듦으로써 지식이 정리되고, 같은 고민을 가진 사람과 연결될 수 있습니다.

이것이 3가지 중에서 가장 간과하기 쉬운 것이라고 생각합니다.

「커뮤니케이션이 중요하죠」라는 이야기는 귀에 못이 박히도록 들어왔을 것입니다. 하지만 이번에는 조금 다른 각도의 이야기를 하겠습니다.

「유저의 언어를 AI를 위한 인풋(Input)으로 변환하는」 스킬이 엔지니어의 핵심 스킬이 되어갈 것이라는 이야기입니다.

AI를 사용한 시스템 개발에서 가장 어려운 것은 「무엇을 AI에게 시킬지를 결정하는 것」입니다.

유저는 「왠지 잘 안 된다」 「좀 더 이렇게 해줬으면 좋겠다」라는 말로 이야기합니다. 그 말로부터 「정말로 곤란해하는 것」을 끌어내어 「AI가 처리할 수 있는 정밀한 언어」로 변환하는 것 —— 이것은 인간만이 할 수 있는 일입니다.

코드를 작성하는 부분은 AI에게 맡길 수 있게 되더라도, 「무엇을 만들어야 하는가」를 정확하게 이끌어내는 상류(Upstream)의 역량은 오히려 중요성이 커져갈 것입니다.

① 「5번 왜(Why)라고 묻기」를 실천하기

사용자나 비즈니스 측으로부터 요구사항이 왔을 때, 표면적인 요구를 그대로 받아들이지 않고 「왜 그것이 필요한가」를 최소 3~5회 정도 깊게 파고드는 습관을 들인다.

「검색 기능이 필요하다」 → 「어떤 정보를 찾는 데 어려움을 겪고 있는가」 → 「지금은 어떻게 찾고 있는가」 → 「그 방식은 어디가 불편한가」……와 같은 방식으로 말이다. 본질적인 과제가 보이기 시작하면, AI에 대한 지시(Prompt)의 정밀도도 훨씬 높아집니다.

② 사용자 인터뷰에 동석하기

PM(Product Manager)이나 UX 디자이너가 사용자와 대화할 때, 엔지니어로서 동석할 수 있도록 요청해 본다. 엔지니어가 사용자의 생생한 목소리를 들을 기회는 적지만, 그곳에서 얻는 「문맥 (Context)」은 이후 AI 활용의 정밀도를 크게 변화시킵니다.

③ 요구사항 정의(Requirement Definition) 메모를 직접 작성하는 습관 갖기

AI에게 메모를 작성하게 하는 것은 편리하지만, 「자신의 언어로 요구사항을 정리하는」 연습은 계속하는 것이 좋다고 생각합니다. 사람의 말을 구조화하는 능력은 사용하지 않으면 퇴화합니다.

세 가지를 나열해 보고 느끼는 점은, 이것들이 모두 「방어적인 스킬업」이 아니라는 점입니다.

• AI의 허점을 간파하는 능력 → 엔지니어로서의 깊이가 더해짐
• 도메인 지식 (Domain Knowledge) → 자신이 관여하는 프로덕트에 대한 이해가 깊어짐
• 대화 능력 → 사용자와 조직과의 관계가 좋아짐

모두 실행한 후에 「왠지 업무가 재미있어졌다」라는 감각으로 이어지는 것들이라고 생각합니다.

「변화의 파도에 휩쓸리지 않기 위해서」라기보다, 「이 변화를 이용해서 내 업무를 더욱 재미있게 만들겠다」 정도의 마음가짐을 갖는 편이 더 오래 지속될 수 있을 것 같습니다.

방향 전환	핵심	오늘부터 시작할 수 있는 것
① AI의 「허점」을 언어화하기	비판적 평가력	AI에게 오류가 포함된 코드를 작성하게 하고 찾아내는 연습
...

도입편은 여기까지입니다. 다음 연재에서는 각각의 테마를 더욱 구체적으로, 실제 현장의 사례를 곁들여 심도 있게 다룰 예정입니다.

계속해서 잘 부탁드립니다.

기사를 읽어주신 분들, 감사합니다. 「나는 이렇게 대응하고 있다」라거나 「이런 관점도 있다」와 같은 의견을 꼭 댓글로 들려주세요. 한 분 한 분의 현장 목소리가 이 연재를 더 좋게 만드는 재료가 됩니다.