
PG에서 프롬프트 아키텍트(Prompt Architect)로. 커리어를 바꾼 사람들의 이야기 실전편 #04
요약
생성 AI 도입으로 인해 변화하는 엔지니어의 역할과 커리어 전환 사례를 다룹니다. AI가 생성한 코드의 품질을 관리하거나, 요건 정의 능력을 프롬프트 설계로 확장하여 새로운 가치를 창출하는 실전 사례를 소개합니다.
핵심 포인트
- AI 코드 리뷰 및 품질 관리라는 새로운 역할의 등장
- 요건 정의(SE) 역량과 프롬프트 설계(Prompt Design)의 유사성
- AI 시대에 엔지니어가 생존하기 위한 스킬 시프트 전략
이 기사는 연재 「생성 AI 시대, 엔지니어는 무엇으로 먹고사는가」의 실전편 #04입니다.
- 도입편은 이쪽에서 확인하세요.
- 실전편 #01 「모두가 AI를 사용할 수 있는」 팀은 왜 붕괴하는가
- 실전편 #02 아무도 하지 않던 일을 하는 사람이 다음 시대의 키맨(Keyman)이 된다
- 실전편 #03 「AI 네이티브 팀」의 현장에서 무슨 일이 일어나고 있는가
- 실전편 #04 PG에서 프롬프트 아키텍트(Prompt Architect)로. 커리어를 바꾼 사람들의 이야기 ← 지금 여기
- 실전편 #05 조직이 AI를 도입하고 반년 후, 살아남은 엔지니어의 공통점
생성 AI 이야기는 「미래의 이야기」로 이야기되는 경우가 많다. "○○라는 직종이 생겨난다", "△△라는 스킬이 필요해진다"——하지만 그것은 5년 후, 10년 후의 이야기처럼 들린다.
하지만 실제로는, 이미 변하고 있는 사람들이 있다.
이 기사에서는 이미 자신의 커리어를 AI 시대에 맞춰 시프트(Shift)해 온 사람들의 이야기를 대화 기반으로 소개한다. 세 사람의 스토리다.
이하의 이야기는 여러 현장에서 들은 실화를 바탕으로, 개인이 특정되지 않도록 일부를 재구성 및 익명화하였다.
"코드를 쓰는 양이 눈에 띄게 줄어들었거든요. 하지만 리뷰하는 양은 늘어났죠. 처음에는 불만이었어요. '나, 코드 쓰고 싶은데'라고 말이죠."
A씨는 백엔드 엔지니어(Backend Engineer)로서 7년간 주로 Java와 Python으로 개발을 계속해 왔다. 팀에 Copilot이 도입된 이후, 젊은 멤버들이 AI로 작성한 코드를 리뷰하는 업무를 맡게 되는 일이 늘었다.
처음에는 "잡무를 떠맡았다"고 느꼈다고 한다.
"하지만 하다 보니 알게 되었어요. AI는 같은 실수를 반복하거든요. 패턴이 있어요. 예외 처리(Exception Handling)의 누락, 로그(Log)의 입도(Granularity), 테스트 커버리지(Test Coverage)의 편중——이런 것들이 매번 같은 부분에서 나타나요."
그 관찰 내용을 사내 문서로 정리하기 시작했다. "AI 코드 리뷰 체크리스트"로 정리하여 팀에 공유했다.
"그랬더니 생각보다 반응이 좋았어요. 다른 팀에서 문의가 오기 시작했고, 정신을 차려보니 사내의 AI 코드 품질 상담 창구 같은 역할을 하고 있더라고요."
지금 A씨의 역할은 "AI 아웃풋 품질 담당"이다. 정식 직종명은 아직 없지만, 그 역할에 급여가 연동되게 되었다.
"코드 품질 관리라는 건 예전부터 있던 업무입니다. 하지만 상대가 인간이 아니라 AI가 된 것뿐이에요. 그뿐입니다. 하지만 AI는 변명을 하지 않고, 같은 실수를 지적하면 고칩니다. 사람보다 다루기 쉬운 부분도 있죠 (웃음)."
"SE(System Engineer)로서 요건 정의(Requirement Definition)를 하고 있었는데, 어느 순간 깨달았어요. 고객의 이야기를 듣고 구조화해서 AI에 던지는 것——이게 SE의 업무와 거의 똑같다는 걸."
B씨는 오랫동안 금융계 시스템의 SE로서 요건 정의 및 설계를 담당해 왔다. AI가 보급되기 시작할 무렵, 자신의 스킬과 AI의 궁합이 좋다는 것을 깨달았다.
"요건 정의란 모호한 언어를 정리하여 시스템이 이해할 수 있는 언어로 변환하는 업무 아닌가요. 프롬프트 설계(Prompt Design)는 정확히 같은 일을 AI를 대상으로 하고 있는 거죠."
B씨가 의식적으로 한 것은 "AI를 위한 인풋(Input) 설계"를 체계화하는 것이었다.
"어떤 문맥(Context)을 주어야 정밀도가 올라가는지, 제약 조건의 작성법, 출력 형식(Output Format)의 지정——이것을 도메인(Domain)별로 패턴화해 나갔습니다. 금융계라면 이렇게 쓰고, 법적 문서가 관여하는 경우에는 이렇게 제한을 둔다, 하는 식으로."
그 지식을 바탕으로 지금은 사내외 프로젝트에서 "AI를 어떻게 사용하게 할 것인가"를 설계하는 컨설팅에 가까운 일을 하고 있다.
"SE의 업무는 없어진다는 말을 듣곤 하잖아요. 하지만 제 체감으로는 SE 스킬은 전혀 헛되지 않았어요. 오히려 AI가 들어옴으로써 SE의 상류(Upstream) 부분——즉 '무엇을 시스템에 시킬 것인가'를 결정하는 능력——의 중요성이 커졌다고 느낍니다."
"엔지니어인데 왜인지 유저 히어링(User Hearing)에 따라가게 되더라고요 (웃음). 처음에는 무슨 뜻인지 몰랐지만, 그것이 지금의 제 강점이 되고 있는 것 같습니다."
C씨는 젊은 엔지니어지만, "코드보다 사람의 이야기를 듣는 것을 좋아한다"는 자각이 있었다. PM으로부터 "유저 인터뷰(User Interview)에 동석하지 않을래?"라는 제안을 받은 것이 전환점이었다.
"히어링에서 '뭔가 잘 안 돌아가요'라고 들은 말을 엔지니어에게 전달하면 전달되지 않아요. '화면이 멈춰요'라고 말해도 상황을 모르면 재현할 수 없죠. 하지만 저는 '이런 조작을 했을 때 어떤 데이터가 어떻게 처리되어'라고 상상할 수 있어요."
C씨는 유저와 엔지니어의 "통역사"로서 가치를 발휘하게 되었고, 지금은 그 너머의 단계——유저의 언어를 AI를 위한 인풋으로 변환하는 작업——을 담당하고 있다.
「사용자가 말한 『대충 이런 느낌』을 AI가 처리할 수 있는 언어로 바꾸는 것이 즐거워요. 퍼즐 같거든요.」
「어려운 점은 사용자의 말을 너무 많이 바꾸지 않는 것입니다. 너무 많이 변환하면 본질이 어긋나버려요. 사용자가 말한 『왠지 사용하기 불편하다』라는 말 속에 사실은 중요한 니즈가 숨어 있을 때가 있습니다. 그것을 뭉개지 않고 AI에게 전달하는 것——그 균형을 잡는 것이 아직 어렵습니다.」
세 사람의 커리어를 나열해 보면 공통된 패턴이 보입니다.
A씨는 코드 리뷰 (Code Review) 스킬을 AI 리뷰에 전용할 수 있었습니다. B씨는 SE(시스템 엔지니어)의 요건 정의 (Requirements Definition) 스킬이 프롬프트 설계 (Prompt Design)로 직결되었습니다. C씨는 사용자와의 커뮤니케이션 (Communication) 스킬이 번역가로서 기능했습니다.
제로에서 새로운 기술을 습득한 것이 아닙니다. 기존 스킬의 「사용법과 사용하는 대상」이 바뀐 것입니다.
세 사람 모두 커리어 플랜 (Career Plan)을 세워 움직인 것이 아닙니다. 눈앞의 과제에 직면하고, 자신이 잘하는 것으로 대응하다 보니 어느샌가 새로운 역할을 맡게 되었습니다.
이것은 중요한 시사점입니다. 「AI 시대에 어떤 커리어를 선택할지」를 지금 결정할 필요는 없습니다. 지금의 업무 속에서 「나만이 할 수 있는 것」을 쌓아 올린 끝에, 역할은 자연스럽게 생겨납니다.
세 사람 모두 자신이 하고 있는 일을 언어화 (Verbalization)하여 발신하고 있습니다. A씨는 체크리스트로 정리하여 팀에 공유했습니다. B씨는 프롬프트 패턴 (Prompt Pattern)을 체계화했습니다. C씨는 사용자와 엔지니어 사이의 번역 프로세스 (Translation Process)를 언어화하려고 노력하고 있습니다.
「왠지 할 줄 아는 사람」은 많습니다. 하지만 「무엇을 하고 있는지 설명할 수 있는 사람」은 적습니다. 그 차이가 하나의 역할로서 인지될지 여부를 가릅니다.
이 글을 읽고 계신 분들께 한 가지 질문을 던지고 싶습니다.
지금 당신의 업무 중에서, **「AI에게는 어렵지만, 나에게는 할 수 있는 것」**은 어디에 있습니까?
코드를 작성하는 속도가 아니어도 좋습니다. 사람의 말을 잘 듣는 것, 업계의 암묵적인 규칙에 밝은 것, 팀의 분위기를 읽고 조율하는 것, 문서를 알기 쉽게 정리하는 것——그런 「수수하지만 확실히 존재하는」 강점 속에 다음 커리어의 씨앗이 심겨 있다고 생각합니다.
- 이미 새로운 커리어를 개척하고 있는 사람들이 있다
- 공통점은 「제로에서 변한 것」이 아니라 「기존 스킬의 사용법이 변한 것」이다
- 커리어 체인지 (Career Change)는 계획이 아니라 「눈앞의 일에 직면한 결과」로 생겨나는 경우가 많다
- 「언어화하여 발신하는 것」이 역할로서 인지되기 위한 열쇠이다
다음 회차 #05(최종회)에서는 AI 도입 후 반년이 지난 조직에서 살아남은 엔지니어의 공통점을 다룹니다.
「나도 이런 시프트를 했다」, 「이런 커리어 패스 (Career Path)가 있었다」는 이야기를 꼭 댓글로 알려주세요. 이런 리얼한 이야기가 읽는 분들에게 가장 큰 참고가 된다고 생각합니다.
주식회사 나카노히토 컴퍼니(Nakano Hito Company)에서는 수시로 엔지니어를 모집하고 있습니다. 자세한 내용은 채용 정보 페이지를 확인해 주세요.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기