B
Boaz2025. 6. 10.

AI는 프론트엔드 엔지니어를 대체할까?

(얼마전에 유튜브에 올렸던 내용인데 글로도 정리해보았어요. 영상을 선호하시면 이 링크에서 보실 수 있어요.)

여러가지 코딩 관련 AI 서비스가 쏟아져 나오면서, 아직 사용해보지 못한게 많은데 뒤쳐지는 것은 아닐까? 이런 서비스들로 인해 프론트엔드 엔지니어는 앞으로 어떻게 될까? 고민이 되는 요즘이어요.

2025년 5월 Google 에서 출시한 코딩 AI Agent(Jules)에 대한 경험을 정리해보려 해요.

AI Agent 가 어떤 일까지 할 수 있는지, 이러한 발전 가운데 아직 사람이 할 수 있는 일은 무엇인지, 앞으로 더 빨라질 변화에 대해 어떻게 대비해야 할지 등에 대해 생각해 보았어요.

AI Agent 가 할 수 있는 일

Google AI Agent(Jules)는 https://jules.google 에 접속하여 github 을 연결하고, repo 와 branch 를 선택한 다음, 작업할 내용을 지시할 수 있어요.

총 20개가 넘는 다양한 종류의 작업을 지시 해보았는데요. 그중에서 인상 깊었던 3가지 작업을 설명해볼게요.

SEO metadata 추가

개발중인 product engineer community 사이트의 metadata 를 추가하는 작업을 지시 해보았어요. Next.js 15 최신 버전의 metadata api 를 사용해서 community app 의 모든 페이지를 추가하는 작업이었어요. (아래는 제가 입력한 프롬프트이어요.)

```html Add metadata to various pages in the community app(apps/community) for SEO purposes using the next.js 15 latest (app router) metadata api (https://nextjs.org/docs/app/getting-started/metadata-and-og-images)) ```

프롬프트 입력 후 조금 기다리면, Jules 가 아래 그림처럼 계획을 세운 후 확인 해달라고 해요.

계획을 승인하면, 바로 작업을 시작해요.(비동기로) 그렇게 작업이 끝나면 아래 그림처럼 PR 을 생성해주어요.(메세지도 전부 작성)

위 그림처럼 PR 생성 후에, files changed 도 같이 확인이 가능해요.(PR 생성을 알려준 대화 옆에서) PR을 확인해보니 요청한 작업을 최신 Next.js metadata api 를 사용해서 완벽하게 처리 해주었어요. static 뿐아니라, dynamic metadata 까지도 적절한 api 를 활용해서 개발해주었어요.

기존 작업에 이어서 추가 수정 요청 가능

여기까지만 해도 놀라운데, 이어서 추가 수정이 가능한지 요청 해보았어요. product engineer ommunity 사이트 사용자가 주로 한국인이었기에, metadata 를 한글로 다시 작성해달라고 수정 요청을 했어요. 그랬더니 위와 동일하게 계획을 세우고, 승인 후 작업을 완벽하게 처리했어요. 더 나아가 요청이 빠진 페이지도 발견해서 저에게 이 페이지까지 작업할지를 역으로 물어보았어요.

이렇게 SEO 관련 metadata 작업은 귀찮지만 필요한 일이었는데요. Agent 에게 부탁하면 제가 해야할 더 중요한 일을 하면서 동시에 처리 가능하구나 확인하는 순간이었어요.

Login, Logout 후 redirect page 수정

두 번째로 요청해 본 작업은 로그인/로그아웃 후 redirect 되는 페이지를 수정하는 작업이었어요. 현재 개발 중인 community 사이트에서는 로그아웃하면 항상 메인 페이지로 돌아가게 되어 있었는데, 사용자가 게시글을 읽던 중에 로그아웃을 하면 그냥 메인으로 튕겨버리는 불편함이 있었어요. 이걸 개선해달라고 요청했어요.

로그아웃 후 redirect

(아래는 제가 입력한 프롬프트예요.)

```html After user logout, go back to previous page(not main page). Currently, after logout, user always go to main page not related with from where. ```

Jules 에게 요청을 하자, 바로 관련 코드를 분석해서 계획을 세워줬어요. 그리고 계획을 승인하니 실제로 current url 을 추적해서 로그아웃 시 그 페이지로 다시 돌아가도록 redirect 로직을 추가해주었어요. (아래 그림에서 빨간 네모가 결과물 코드이어요.)

이 작업이 너무 쉬운 편이어서, 추가로 로그인 관련 작업도 요청해보았어요.

로그인 후 redirect

로그인 작업도 동일한 로직이었어요. 로그인 전에 question 목록 페이지를 보고 있다가 로그인하면 다시 question 목록으로 돌아오도록이요.

```html after login, go back to before login page(e.g. questions list page -> login page -> login success -> questions list page) please check apps/auth for login logic ```

이 작업 결과를 보면서 또 놀랐는데, Jules 는 이 요청에 대해

  1. nextPathname 을 hidden input 을 통해
  2. form data 로 넘기는 로직을 추가했고,
  3. server action 에서 이 값을 받아서 로그인 성공 후
  4. 다시 해당 경로로 redirect 해주는 로직까지

완벽하게 구현했어요.

작업이 끝난 후 PR 도 생성해주었고, PR 메세지도 직접 작성해주었어요. 실제로 백로그에 등록하고 처리하려던 작업을 프롬프트 한줄로 해결한 것이어요. cursor 로 작업할 때와 다르게 직접 파일을 context 에 추가해줄 필요 없이, 코드베이스 전체를 이해하고 필요한 작업을 수행해준다는 부분이 특히 놀라웠어요.

전체 코드를 읽고, 중복 작업이라고 알려준다

심지어 시험 삼아 "소셜 로그인에서도 동일한 로직을 추가해줘"라고 작업을 요청하는 프롬프트를 입력했더니, "이미 소셜 로그인에는 해당 로직이 구현되어 있어요." 라고 답했어요. 실제로 소셜 로그인에는 이전에 제가 구현해둔 redirect 처리가 있었는데, 그걸 파악하고 중복 작업을 하지 않겠다고 대답한거여요. 이때 "이건 AI Agent 가 아니라 찐 협업하는 동료 같은데?" 라고 느꼈어요.

Monorepo 신규 패키지 생성 및 기능 연동

세 번째로 요청한 건, 좀더 큰 규모의 작업이었어요. 제가 운영하는 product engineer 플랫폼은 monorepo 로 구성되어 있는데요, 여기에 이메일 템플릿을 위한 새로운 패키지를 추가하는 작업을 Jules 에게 시켜보았어요.

이때 제가 작성한 프롬프트는 아래와 같아요.

```html make packages/transactional for email templates to send email in apps/community when another user add comment at your post. (Currently already send email logic with resend, but no email template. so please refer below website(github repo) as sample) https://github.com/resend/react-email-turborepo-pnpm-example ```

이 요청을 받고 Jules 는 모노레포의 전체 구조를 분석하고, 어떤 디렉토리 경로가 존재하지 않는지를 확인한 뒤, 경로가 없을 경우 직접 폴더를 생성해 주었어요. 그냥 "파일 몇 개 복사해서 만들어줘" 수준이 아니라, 모노레포 구조를 이해하고, 새로운 패키지를 추가하는 방식으로 작업을 처리했어요.

그리고 댓글이 작성 되었을 때, 이 transactional 패키지의 이메일 템플릿을 사용해서 실제 메일이 발송되도록 apps/community 의 기존 로직과도 연결해 주었어요. (필요한 라이브러리들도 직접 설치하고요) 즉, 템플릿을 만든걸 넘어서, 활용하는 부분까지 깔끔하게 작업해주었어요.

심지어 제가 직접 한다해도 꽤 시간이 걸리는 작업이었어요. Jules 는 이 작업을 정확하게, 심지어 병렬로(제가 다른 일을 하는 동안에) 처리 해주었어요. 이 정도면 개발자의 일 중에 꽤 많은 부분을 위임할 수 있을 것 같아요.

브랜치 단위여서, 직접 commit 추가도 가능

다만, 작업이 완료된 후 PR 이 생성 되었을 때, 빌드가 깨져있었어요. 이 부분은 직접 수정하는게 더 빨라보였어요. 해당 branch 로 checkout 한 후, 직접 수정해서 commit 을 추가 했어요. 이렇게 빌드 깨진게 해결된 PR 에 사람 동료가 리뷰를 남겨주었어요. AI Agent 가 모노레포 구조를 파악해서 새로운 기능을 패키지 단위로 추가하고, 그걸 기존 로직과 연결해주는 일을 해주는 것도 신기한데, 이 작업을 마무리하기까지 과정이 리뷰를 준 사람 동료와 협업하는 것처럼 느껴졌어요.

아직 사람 엔지니어가 해야 할 일

앞에서 본 것처럼 AI 에이전트가 할 수 있는 일은 점점 많아지고 있어요. 단순히 코드를 생성하는 걸 넘어서, PR을 생성하고, 메시지를 작성하고, 기존 코드를 분석해서 중복 작업을 거르기도 하는 등이요. 이런 작업들을 시켜보면서 아직 사람이 할 수 있는 일이 무엇이 남아있을까, 과정을 돌아봤어요.

그러면서 발견한 아직은 사람이 해야할 일은, 복잡한 문제를 AI가 처리할 수 있도록 단순하게 바꾸는 일인 것 같아요.

AI가 할 수 있는 작업의 공통점?

Jules 를 여러 번 사용해보니, 잘해내는 작업은 공통점이 있었어요. 규모가 적당하고, 뭘 해야 하는지 구체적으로 설명이 가능하다는 점이어요.

예를 들어

  • 특정 페이지에 SEO 메타데이터를 추가하는 일
  • 로그아웃 시 이전 페이지로 리다이렉트하도록 수정하는 일
  • 댓글 작성 시 이메일을 보내는 템플릿을 추가하는 일

이런 작업들은 입력과 출력이 비교적 명확한 편인것 같아요. 요청을 자연어로 표현할 수 있고, Jules 도 그걸 이해할 수 있어요. 이처럼 복잡한 작업들을 AI Agent 가 잘 해낼 수 있도록 요청하는 일은 아직 사람이 해야하는 것 같아요.

복잡한 작업을 AI Agent 에게 요청하는 법?

실무에서 처리하는 작업들 대부분은 무엇을 작업할지 명확하게 정리하는 것부터 시작해요. 기획, UX, 디자인, 백엔드 등 다양한 부서의 이해관계를 조율해야 하고, 그 가운데서 프론트엔드 엔지니어는 비즈니스 배경, 기술적인 상황 등을 고려해서 적절한 해결책을 찾아야 해요.

이처럼 복잡한 작업을 Jules(AI Agent) 에게 바로 요청하는 것은 어려워요. Jules 가 충분히 잘 해내기 위해서는 할일을 아래 상자처럼 적당한 사이즈로 쪼개야 하고, 구체적으로 어떤 내용인지 써주어야 하는 것 같아요.

  1. 작업을 적당한 규모로 쪼개는 일 작업의 범위가 너무 크면 Jules 도 실패해요. "로그인, 로그아웃, 회원가입처럼 리다이렉트가 필요한 곳에 원래 페이지로 리다이렉트를 구현해줘", 같은 요청은 대부분 실패하거나 수정이 필요한 결과가 나와요. 하지만 그걸 "로그인 시 원래 페이지로 돌아가게 해줘" 럼 적당한 규모로 쪼개면, Jules 가 충분히 실행할 수 있어요.
  2. 쪼갠 작업에 대해 구체적인 가이드를 주는 일 설명이 모호하면 원하는 결과를 얻기 어려워요. 작업을 시킬 때는 구체화 시킬수록 좋아요. 어떤 페이지에서, 어떤 동작을, 어떤 목적을 위해 하려는지 정리해보는게 도움이 되어요. 공식 문서나 예시 레포 링크를 첨부하는 것도 좋은 것 같아요. 물론 아주 세세한 방식 예를 들어 위에서 로그인 redirect 작업을 시켰을 때, current path 를 넘기기 위한 hidden input 을 만들고, server action 에서 그걸 받아서 리다이렉트하는 흐름까지 정확하게 지시하는 등은 필요하지 않은 것 같아요. 실제로 저 또한 그렇게 하지 않았음에도 충분히 좋은 결과를 주어서요. 얼마나 구체적이어야 할지는 시켜보면서 감을 잡아야할 것 같아요.

이처럼 Jules 가 거의 다 해주지만 아직 사람이 해야 할 일이 남아 있는 것 같아요. 다만 그 일이 직접 구현하는 일보다는, AI가 이해하고 실행할 수 있도록 맥락을 정리하고 설계하는 일로 바뀌고 있는 것 같아요.

AI 와 사람의 경계선이 바뀌는 중?!

AI 가 할 수 있는 일은 점점 더 많아지고 있어요.

해낼 수 있는 작업의 규모는 점점 더 커지고, AI 에게 필요한 가이드도 점점 덜 구체적이어도 충분히 잘 해내고 있어서요. 즉, 설계 영역도 곧 AI 에게 위임할 수 있게 될 것 같아요. 이러한 변화 속에서 사람 엔지니어가 앞으로 할 일도 같이 변하고 있어요.

엔터프라이즈급 SW 를 개발할 때는 여전히 더 크고 복잡한 설계가 필요해요. 이런 부분에 대한 역량을 쌓아야 할 것 같아요. AI 가 대체하기 좀 더 어려운 영역인 것 같아서요. 그러나 이 부분도 AI 가 발전하면 위임할 수 있게될 거에요.

설계보다 앞선 일? 문제 정의!

설계마저 AI 에게 위임하게 된다면, 사람 엔지니어에게는 현실의 다양한 문제 중에서 컴퓨터로 잘 해결할 수 있는 문제를 발견하고 정의하는 일이 남게 될 것 같아요. 이를 잘 해내기 위해서는 아래 역량이 필요할 것 같아요.

컴퓨터 공학(CS) 기초

가장 먼저는 기술력이어요. 컴퓨터 공학 기초 지식과 소프트웨어 개발 경험이요. 지식과 경험을 통해 직관을 기르는 과정이 필요할 것 같아요.

컴퓨터로 해결할 수 있는 문제를 발견하려면 컴퓨터 공학 기초 공부가 중요할 것 같아요. 운영체제, 네트워크, 알고리즘과 자료구조 등이요. 그래야 컴퓨터의 능력과 한계를 파악하고, 해결할 수 있는 범위를 알고 있기 때문이어요.

사용자에 대한 관심

AI 는 로봇 공학이 충분히 발전하기 전까지는 물리적인 한계가 있어서요. 사람의 5감을 사용해서 직접 정보를 수집하는 것에 비하면 더 적은 정보 밖에 없기에 문제를 제대로 정의하기 부족할 수 있어요.

또한 로봇 공학이 발전한다 해도, AI 는 사람대 사람으로 관계를 맺을 수는 없어요. 신뢰 혹은 같은 종으로 느끼는 감정의 교류 등은 AI 가 사람을 마지막까지 대체하기 어려운 부분일 것 같아요. 이런 부분에서 사람 엔지니어가 가지는 강점을 발휘해서, 사용자에게 관심을 갖고 공감한다면 진짜 문제를 발견할 수 있을 것 같아요.

앞으로 어떻게 해야할까?

문제 정의, 컴퓨터 공학 기초, 사용자에 대한 관심 모두 중요하다는 건 충분히 이해가 가는데, 무엇부터 해야할까? 고민이 되신다면, 전략적으로 우선순위를 정해야 할것 같아요. 단기적으로 먼저 갖춰야 할 역량과 장기적으로 함께 학습해야할 방향을 나누는 것처럼요.

단기적으로는 설계 역량과 CS 기초

당분간은 설계 역량을 키우는데 집중하는 것이 유리할 것 같아요. AI 발전 방향성을 보면 설계도 대신하게 되겠지만, 결국은 잘 설계하도록 위임하려면 사람의 설계 역량이 중요할 것 같아서요.

자료구조 & 알고리즘

위에서 얘기한 적당한 규모로 작업을 쪼개고, 작업별로 구체적인 가이드를 주는 일은 알고리즘 & 자료구조를 공부하면서 연습할 수 있어요. 컴퓨터적인 사고 능력을 기르는 것이어요.

시스템 디자인

이와 동시에, 시스템 디자인 등을 학습하며 직접적으로 설계 역량을 키울 수도 있을 것 같아요. 특히 프론트엔드 엔지니어 입장에서 다양한 컴포넌트 설계 뿐만 아니라, 앱 전체를 설계하는 경험을 많이 쌓아야 할 것 같아요. 더 크고 복잡한 앱일수록 더 큰 도움이 될 것 같아요.

장기적으로는 문제 정의

문제를 정의하는 일은 무에서 유를 창조하는 일이기에 항상 쉽지 않은 것 같아요. 스스로 겪는 일상에서의 작은 불편함부터 해결해보는 연습이 도움이 될 것 같아요. 첫번째 사용자가 내가 되는 것이어요. 내가 겪는 불편을 제대로 해결하는 것에서 출발해서, 동일한 불편을 겪는 사람들로 관심을 확대하면 조금 더 수월하게 시작할 수 있더라고요.

또한 처음부터 주변 사람을 관찰하며 겪는 불편을 발견하고 기술적으로 해결해주는 방법도 있어요. 두 방법 사용자 즉, 사람에 대한 관심이 중요한 것 같아요.

맺으며

저또한 프론트엔드 엔지니어의 한 사람으로, AI 발전을 눈여겨보며 앞으로 어떻게 해야 살아남을 수 있을까 고민하고 있어요. 지식을 쌓고, 직접 경험하며 2025년 5월 현재 시점에서 생각을 정리해두는 것이 의미가 있을 것 같아서요. 함께 이 시기를 지나가는 다른 프론트엔드 엔지니어 분들에게 도움이 되면 좋겠다 하는 마음으로 이 글을 썼어요.

글을 쓰면서 프론트엔드 엔지니어라는 나름대로 좁은 영역 안에서도 인프라 쪽에 더 무게 중심을 둔 플랫폼 엔지니어와 프로덕트 자체에 집중하는 프로덕트 엔지니어로 구분할 수 있는데, 너무 프로덕트 엔지니어 중심으로 글을 쓴건 아닐까 고민도 했어요. 아무래도 주로 제가 경험한 영역이 프로덕트 엔지니어링 쪽이다보니 조금 더 그쪽에 집중하여 글을 쓴 부분도 있는 것 같아요. 아직 제가 경험하지 못한 영역에서는 또 다른 방향성을 예측할 수 있을 것 같습니다.

다만 제가 경험한 범위 안에서, 저는 개발의 본질이 기술로 사용자를 도와주는 것이라고 생각해서요. 저와 같이 생각하는 분들이 더욱 많아질 때까지 열심히 직접 개발하고 공부하며, 또한 글쓰고 강의하며 지내려고 합니다. 각자의 자리에서 함께 공부하는 모든 분들 화이팅입니다. .........