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

• 도입편은 이쪽에서 확인하세요.
• 실전편 #01 「모두가 AI를 사용할 수 있는」 팀은 왜 붕괴하는가
• 실전편 #02 아무도 하지 않으려던 일을 하는 사람이 다음 시대의 키맨이 된다 ← 지금 여기
• 실전편 #03 「AI 네이티브 팀」의 현장에서 무슨 일이 일어나고 있는가
• 실전편 #04 PG에서 프롬프트 아키텍트(Prompt Architect)로. 커리어를 바꾼 사람들의 이야기
• 실전편 #05 조직이 AI를 도입하고 반년 후, 살아남은 엔지니어의 공통점

조금 전까지만 해도 팀의 키맨(Keyman)이라고 하면 「가장 코드를 잘 짜는 사람」이었습니다. 어려운 구현을 맡길 수 있는 사람, 버그를 즉시 고칠 수 있는 사람, 설계를 맡길 수 있는 사람.

하지만 지금, 조금 다른 사람이 키맨이 되어가고 있는 현장이 나타나고 있습니다.

「코드를 쓰는 양」은 많지 않은데, 왠지 그 사람이 없으면 프로젝트가 돌아가지 않는다——그런 사람.

그들에게 공통적인 것은, 「아무도 하고 싶어 하지 않았지만, 사실은 중요했던 일」을 자연스럽게 하고 있었다는 점입니다.

구체적으로 살펴보겠습니다.

팀에 AI가 도입되면 코드나 문서의 양이 단번에 늘어납니다. 「일단 AI에게 시킨 것」들이 쌓여갑니다.

그것을 누가 가장 먼저 훑어보는가——이 역할은 처음에는 「귀찮은 일」처럼 보입니다. 하지만 실제로 해보면 여기에는 큰 가치가 있습니다.

AI 특유의 실수 패턴을 파악할 수 있습니다. 어떤 프롬프트(Prompt)일 때 품질이 높은지·낮은지에 대한 지견이 쌓입니다. 팀의 「AI 사용 수준」을 끌어올릴 수 있습니다. 어느샌가 「이 사람이 없으면 품질을 담보할 수 없다」는 존재가 되어 있었다는 케이스가 실제로 일어나고 있습니다.

사용자나 비즈니스 사이드의 요구사항을 AI로의 인풋(Input)으로 변환하는 사람.

「왠지 이렇게 해줬으면 좋겠다」라는 말을 「AI가 잘 처리할 수 있는 입도의 요건」으로 떨어뜨리는 것. 이것은 은근히 어렵습니다.

요건 정의의 상류 스킬과 AI를 향한 프롬프트 설계 스킬이 모두 필요합니다. 하지만 둘 다 적당히 할 수 있다면 성립합니다. 「SE(System Engineer)로서도 중견, AI도 사용할 줄 아는」 정도의 사람이 의외로 빠지게 되는 역할입니다.

팀 내에서 AI를 가장 잘 사용하고 있는 사람의 지견을 다른 멤버에게 전파하는 역할.

「이런 프롬프트로 내는 편이 좋다」, 「이 케이스는 AI에게 맡기는 것보다 직접 쓰는 게 빠르다」라는 현장 지식을 문서나 점심시간 공유회를 통해 팀에 전달하는 사람.

이것은 아무도 「자신의 일이다」라고 생각하지 않기 때문에 대부분 방치되어 있습니다. 하지만 실행한 사람의 평가는 서서히 올라갑니다.

AI를 사용하여 만든 시스템은 기존의 개발보다 「작동하기 시작한 후의 거동을 예측하기 어렵다」는 특성이 있습니다.

특히 LLM(Large Language Model)을 포함한 시스템은 동일한 입력에도 출력이 변합니다. 운영 환경에서 어떻게 행동하는지를 지속적으로 모니터링하고, 문제를 찾아내어 대처하는——이 역할은 AI가 보급될수록 수요가 늘어납니다.

QA 엔지니어와 SRE(Site Reliability Engineering)가 융합된 듯한 역할로, 아직 이름도 붙어 있지 않지만 확실히 필요로 하고 있습니다.

여기에는 이유가 있습니다.

AI가 보급되면 「누구나 할 수 있는 일」의 비용은 제로에 가까워집니다. 반대로 말하면, 「아무도 하지 않는 일」에는 경쟁 상대가 없습니다.

희소성의 원리입니다.

코드를 짜는 일은 이제 「AI도 할 수 있는」 영역에 들어가고 있습니다. 하지만 AI의 아웃풋(Output)을 리뷰하고, AI와 사용자 사이를 가교하고, 팀의 AI 활용을 설계하는——이것들은 아직 「인간만이 할 수 있는」 영역에 있습니다.

게다가 「아무도 하지 않기」 때문에, 조금만 해도 눈에 띌 수 있습니다.

「하지만 자신에게 맞는지 모르겠다」는 분들을 위해 구체적인 단계를 적겠습니다.

지금 팀에서 「아무도 하지 않지만, 하는 편이 좋겠지」라고 생각되는 일은 어디에 있습니까?

AI의 아웃풋 리뷰가 개인의 역량에만 의존(属人化)하고 있지는 않은가. AI 사용법이 멤버마다 제각각이라 품질에 편차가 있지는 않은가. 사용자와 엔지니어 사이에서 AI 관련 번역이 이루어지지 않고 있지는 않은가.

우선 그것을 관찰하는 것부터 시작합니다. 「누군가는 해야 하지만 아무도 하지 않는」 포인트가 당신의 포지션이 될 수 있는 장소입니다.

갑자기 큰 역할을 가져오려 하지 않아도 됩니다.

「AI 리뷰 관점을 정리한 문서를 만들어 볼게요」, 「팀의 프롬프트 모음, Notion에 정리해 보겠습니다」——이런 작은 「떠맡기」로 충분합니다.

처음에는 본업의 틈틈이 하는 정도로 괜찮습니다. 해보면 「이 일, 나에게 맞을지도 몰라」, 「반대로 전혀 맞지 않았어」라는 체감을 알 수 있게 됩니다.

「자신이 하고 있는 것」을 언어화하여 팀이나 외부에 발신함으로써, 그 역할이 당신의 것이 되어 갑니다.

Qiita여도 좋고, 사내 스터디 모임이어도 좋습니다. "나는 이런 관점에서 AI 아웃풋 (AI output)을 리뷰하고 있다", "이런 프롬프트 (prompt)가 잘 작동했다 혹은 작동하지 않았다"라는 내용을 계속해서 발신함으로써, "그 사람에게 물어보면 알 수 있다"라는 인식이 생겨납니다.

그것이 키맨 (keyman)이 되는 최단 경로입니다.

처음에는 그런 일이 손해처럼 보일 수도 있습니다. "왜 내가 이걸 해야 하지?"라고 생각할 수도 있습니다.

하지만 생각해 보세요. 코드를 작성하는 속도로 경쟁한다면, 상대는 AI입니다. AI와 속도로 승부하는 것은 승산이 그리 높지 않습니다.

하지만 "팀 내에서 AI를 가장 잘 활용하도록 설계하는" 일이라면, 현재로서는 경쟁 상대가 거의 없습니다.

키맨으로 가는 길은, "아직 아무도 이름을 붙이지 않은 일" 속에 있다고 느낍니다.

• AI의 보급으로 "코드를 짤 줄 아는 사람이 키맨"이라는 도식이 변하고 있음
• "아무도 하지 않았던 일" — AI 리뷰, 통역, 지식 공유, 운영 품질 관리 — 에 가치가 생겨나고 있음
• 희소성의 원리: "누구나 할 수 있는 일"은 비용이 0에 가까워지고, "아무도 하지 않는 일"에서 경쟁 우위가 생겨남
• 되는 방법은 "관찰 → 작게 맡아보기 → 언어화하여 발신"의 3단계

다음 회차 #03에서는, 실제로 "AI 네이티브 (AI-native) 팀"의 현장에서 어떤 일이 일어나고 있는지, 구체적인 사례를 바탕으로 쓰겠습니다.

"내 현장에서도 비슷한 역할이 생겨나고 있다", "이런 일이 생겼다"라는 이야기가 있다면, 댓글로 알려주시면 감사하겠습니다.

주식회사 나카노히토 컴퍼니 (Nakano Hito Company)에서는 수시로 엔지니어를 모집하고 있습니다. 자세한 내용은 채용 정보 페이지를 확인해 주세요.