프론트엔드 스터디 대면 6주차(2): AI 시대의 개발 방식과 프론트엔드 개발자의 위치

웹 서비스 하나가 만들어지기까지는 보통 여러 역할이 엮입니다. 회사마다 다르지만 큰 흐름은 대략 이렇습니다.

이 중 프론트엔드는 단순히 "화면 만드는 사람"으로만 보면 부족합니다. 실제로는 사용자 경험이 최종적으로 드러나는 지점에 있기 때문에, 여러 역할의 결정이 프론트엔드에서 한 번에 만납니다.

디자이너가 만든 시안이 실제 데이터와 만나면 깨질 수 있고, 백엔드 API가 내려주는 데이터 구조가 화면 요구사항과 맞지 않을 수 있습니다. PM이 정한 정책이 UI로 표현되면서 모호함이 드러나기도 합니다. 그 모호함을 가장 자주 발견하는 사람이 프론트엔드 개발자입니다.

디자이너는 보통 이상적인 상태의 화면을 그립니다. 하지만 실제 웹에서는 다양한 변수가 생깁니다.

이런 질문은 디자인만의 문제도 아니고 개발만의 문제도 아닙니다. 화면을 실제로 만드는 사람이 질문을 던지고, 디자이너와 함께 합의해야 합니다. 그래서 좋은 프론트엔드 개발자는 Figma를 "그림"으로만 보지 않고, 상태와 예외 케이스가 포함된 시스템으로 봅니다.

예를 들어 버튼 하나도 기본 상태, hover 상태, disabled 상태, loading 상태가 있습니다. 이런 상태를 제대로 질문하고 정리하는 사람이 팀의 UI 품질을 끌어올립니다.

백엔드는 데이터를 안정적으로 저장하고 내려주는 역할을 합니다. 프론트엔드는 그 데이터를 사용자가 이해할 수 있는 화면으로 바꿉니다. 여기서 자주 생기는 문제가 API 구조와 화면 구조가 딱 맞아떨어지지 않는 것입니다.

백엔드 입장에서는 충분히 명확한 데이터일 수 있습니다. 하지만 프론트엔드에서는 이걸 "가입 대기 중", "2026년 5월 4일", "승인 버튼 노출 여부" 같은 사용자 언어로 바꿔야 합니다.

그래서 프론트엔드 개발자는 API를 그냥 받아 쓰는 사람이 아니라, 화면 요구사항을 기준으로 백엔드와 데이터 계약을 맞추는 사람입니다. 어떤 필드가 필요한지, 에러는 어떤 형태로 내려올지, 페이지네이션은 어떻게 할지, 권한에 따라 버튼이 보일지 같은 이야기를 해야 합니다.

여기서 한 단계 더 나가면 BFF(Backend For Frontend)라는 개념이 나옵니다. 이름 그대로 "프론트엔드를 위한 백엔드"입니다. 일반 백엔드 API가 서비스 전체의 데이터와 비즈니스 로직을 담당한다면, BFF는 특정 화면이나 특정 클라이언트가 쓰기 좋게 데이터를 가공해서 내려주는 중간 계층에 가깝습니다.

예를 들어 백엔드 API가 사용자 정보, 권한 정보, 알림 개수, 최근 활동을 각각 따로 내려준다고 해봅시다. 프론트엔드가 화면 하나를 그리기 위해 API를 네 번 호출하고, 각 응답을 조합해야 한다면 화면 코드가 복잡해집니다. 이때 BFF에서 필요한 데이터를 한 번에 모아 화면에 맞는 형태로 내려줄 수 있습니다.

그래서 요즘 프론트엔드 개발자는 단순히 브라우저 안의 코드만 만지는 게 아니라, Next.js의 Route Handler, Server Action, API Route, Remix loader/action 같은 서버 쪽 경계도 함께 다루는 경우가 많습니다. 화면을 가장 잘 아는 사람이 화면에 필요한 데이터 형태도 가장 잘 정의할 때가 많기 때문입니다.

그래서 BFF를 "프론트엔드가 백엔드를 대체한다"로 이해하면 안 됩니다. 더 정확히는

입니다. 핵심 비즈니스 로직과 데이터 무결성은 여전히 백엔드의 중요한 책임이고, BFF는 화면 요구사항과 백엔드 API 사이의 간극을 줄이는 역할에 가깝습니다.

이 흐름 때문에 프론트엔드 개발자에게 요구되는 범위가 조금 넓어졌습니다. HTML, CSS, 브라우저 JS만 아는 것에서 끝나는 게 아니라, HTTP, 인증, 쿠키, 캐싱, 서버 런타임, API 설계 감각까지 조금씩 필요해지고 있습니다. 다만 처음부터 백엔드 전체를 다 하라는 뜻은 아닙니다. 화면을 위해 어디까지 서버에서 처리해야 하는지 판단하는 감각이 중요해졌다는 뜻입니다.

프론트엔드는 사용자가 직접 만지는 화면을 만들기 때문에, 자연스럽게 제품 판단과 가까워집니다. "이 기능이 기술적으로 가능한가"뿐만 아니라, "사용자가 이 흐름을 이해할 수 있는가", "지금 일정에서 어디까지 만드는 게 맞는가"를 같이 보게 됩니다.

작은 팀이나 초기 스타트업에서는 프론트엔드 개발자가 사실상 PM처럼 움직이는 경우도 많습니다. 기능 범위를 쪼개고, 디자인에서 빠진 예외 상태를 정리하고, 백엔드와 API 범위를 맞추고, 배포 후 사용자 반응을 확인합니다.

물론 직군 이름이 PM으로 바뀐다는 뜻은 아닙니다. 다만 프론트엔드는 구조상 기획, 디자인, 백엔드, 사용자 사이의 접점에 있기 때문에, 제품을 리딩하는 감각이 중요해질 수밖에 없습니다.

백엔드 개발자도 당연히 커뮤니케이션과 리딩이 중요합니다. 다만 프론트엔드는 업무 특성상 눈에 보이는 결과물과 여러 직군의 요구사항이 동시에 모이는 경우가 많습니다.

백엔드는 내부 구조, 데이터 모델, 성능, 안정성, 보안처럼 사용자에게 직접 보이지 않는 깊은 영역을 많이 다룹니다. 반면 프론트엔드는 사용자와 팀원 모두가 바로 볼 수 있는 화면을 다룹니다. 그래서 질문이 더 많이 들어옵니다.

이런 질문들은 단순 구현 질문이 아니라 의사결정 질문입니다. 프론트엔드 개발자가 이때 "그건 제 일이 아닌데요"라고만 하면 팀 속도가 느려집니다. 반대로 문제를 정리해서 "이 경우에는 A/B 중 하나를 선택해야 하고, 저는 A가 더 낫다고 봅니다"라고 말할 수 있으면 팀이 앞으로 움직입니다.

그래서 프론트엔드에서 리딩 능력은 "직급이 높아야 한다"는 의미가 아닙니다. 모호한 화면과 요구사항을 구체적인 결정으로 바꾸는 능력에 가깝습니다. 이 능력이 있으면 주니어여도 팀에서 훨씬 빠르게 신뢰를 얻습니다.

이제 AI 이야기를 해보겠습니다. 몇 년 전만 해도 AI 코딩 도구는 에디터에서 자동완성 몇 줄 해주는 정도로 많이 쓰였습니다. 지금은 흐름이 꽤 달라졌습니다.

예전에는 GitHub Copilot처럼 현재 파일의 다음 줄을 추천해주는 방식이 중심이었습니다. 지금은 Claude Code, Codex CLI, Gemini CLI 같은 도구처럼, 터미널에서 프로젝트 전체를 읽고 파일을 직접 수정하는 방식이 빠르게 커지고 있습니다.

그래서 개발자의 일이 "코드를 한 줄씩 치는 것"에서 "무엇을 시킬지 정하고, 결과를 검토하고, 팀의 맥락에 맞게 조정하는 것"으로 조금씩 이동하고 있습니다.

더 나아가 요즘은 AI 하나에게 모든 걸 맡기기보다, 역할을 쪼개서 여러 에이전트처럼 쓰는 흐름도 생기고 있습니다.

사람 팀과 비슷합니다. 한 명에게 "다 해줘"라고 하면 빠르지만 허점이 많습니다. 역할을 나누면 느려 보이지만 결과가 더 안정적입니다. 앞으로 개발자는 AI를 단순히 검색 도구처럼 쓰는 것이 아니라, 작은 팀을 운영하듯이 쓰는 능력이 중요해질 가능성이 큽니다.

이때 등장하는 개념이 하네스(harness)입니다. 하네스는 여러 에이전트를 그냥 "각자 알아서 해"라고 풀어놓는 것이 아니라, 어떤 순서로 일할지, 어떤 결과를 검증할지, 실패하면 다시 시킬지 같은 흐름을 관리하는 구조입니다.

사람 팀에서 PM, 개발자, 리뷰어, QA가 나뉘듯이 AI도 역할을 나누면 결과가 더 안정적입니다. 핵심은 "AI 한 명이 똑똑한가"보다, AI들이 실수했을 때 걸러지는 구조가 있는가입니다.

여기서 조금 더 실제적인 예시를 들면, 제가 요즘 쓰는 구조가 OpenClaw와 Hermes입니다. 지금 전부 이해할 필요는 없고, "이런 식으로 AI 개발 환경이 운영될 수 있구나" 정도만 보면 됩니다.

비유하면 OpenClaw는 회사 사무실 또는 접수 창구이고, Hermes는 실제 작업 책상입니다. 사람은 텔레그램으로 "이 기능 수정해줘"라고 말하고, 게이트웨이는 그 요청을 작업 환경으로 보내고, 러너는 저장소에서 실제로 일을 합니다. 사람이 브라우저나 터미널 앞에 계속 붙어 있지 않아도, 에이전트가 백그라운드에서 일하고 결과를 보고하는 식입니다.

이 흐름이 중요한 이유는, 앞으로 개발 환경이 단순히 "AI 채팅창에 코드 물어보기"에서 끝나지 않을 가능성이 크기 때문입니다. 프로젝트 맥락을 아는 에이전트가 있고, 그 에이전트를 실행하는 러너가 있고, 여러 채널과 세션을 관리하는 게이트웨이가 있는 식으로 점점 운영 시스템에 가까워지고 있습니다. 그래서 개발자는 코드를 쓰는 사람을 넘어, AI 팀과 작업 흐름을 설계하는 사람에 가까워질 수 있습니다.

AI는 "그럴듯하게 동작하는 코드"를 매우 빠르게 만듭니다. 문제는 그 코드가 항상 안전하거나, 성능이 좋거나, 팀 컨벤션에 맞거나, 실제 요구사항을 제대로 만족하는 것은 아니라는 점입니다.

실제로 웹 개발을 잘 모르는 친구가 AI로 웹 게임을 만들어 온 적이 있습니다. 점수 겨루기 게임이었고, 겉으로 보기에는 꽤 잘 돌아갔습니다. 버튼을 누르면 게임이 진행되고, 점수가 오르고, 랭킹도 보였습니다. 그런데 QA하듯이 브라우저 개발자 도구를 열어보니 문제가 바로 보였습니다.

브라우저 F12를 열면 프론트엔드 코드는 기본적으로 사용자가 볼 수 있습니다. 그 상태에서 콘솔을 조금 만져보니, 점수와 관련된 내부 함수와 상태가 너무 쉽게 접근됐습니다. 랭킹을 올리려고 복잡한 해킹을 한 게 아니라, 그냥 콘솔에서 점수 변수를 바꾸거나 게임 내부 함수를 직접 호출하면 됐습니다. 말 그대로 5분 만에 1등을 만들 수 있었던 거죠.

아래 코드는 지금 전부 이해하지 않아도 됩니다. 핵심은 "게임 안에서만 실행되어야 할 함수가 콘솔에서 그대로 호출됐다" 는 점입니다.

원래라면 레이저 아이템을 실제로 획득했고, 사용 가능한 상태인지 검증한 뒤에만 점수가 올라야 합니다. 그런데 이 게임에서는 applyLaser 같은 내부 함수가 전역(window)에 그대로 붙어 있었고, "레이저 특수 아이템을 진짜로 썼을 때만 발동해야 한다"는 검증 이 없었습니다. 아무 셀 객체를 넣어도 점수가 올라갔고, 같은 호출을 반복하면 랭킹을 마음대로 조작할 수 있었습니다.

이 사례가 보여주는 건 단순합니다. AI는 "게임이 동작하는 코드"를 빠르게 만들 수 있습니다. 하지만 "사용자가 브라우저 콘솔에서 뭘 할 수 있는지", "점수 계산을 클라이언트에 둬도 되는지", "서버에서 검증해야 하는 값은 무엇인지"를 항상 먼저 챙겨주지는 않습니다. 작동하는 것과 안전한 것은 다릅니다.

여기서 기초 공부의 의미가 다시 생깁니다. JS를 모르면 AI가 만든 코드가 왜 위험한지 읽을 수 없습니다. DOM, 스코프, 객체, 함수, 전역 객체, API를 알아야 "이 함수가 왜 콘솔에서 호출되지?", "이 점수 계산을 브라우저에 둬도 되나?"를 의심할 수 있습니다. AI 시대에는 코드를 직접 쓰는 능력만큼이나 AI가 만든 코드의 허점을 찾는 능력이 중요해집니다.

앞으로도 코드를 직접 쓰는 능력은 필요합니다. 하지만 더 중요해지는 것은 코드를 읽고 판단하는 능력입니다.

AI가 코드를 많이 써줄수록, 사람은 더 많이 검토해야 합니다. 역설적으로 기초가 약한 사람은 AI를 잘 쓰기 어렵습니다. 틀린 결과를 봐도 틀렸다는 걸 모르기 때문입니다.

AI에게 일을 잘 시키려면 질문을 잘 만들어야 합니다. "이거 만들어줘"보다 좋은 요청은 이런 식입니다.

좋은 요청은 구현 조건, 예외 상태, 기존 코드와의 연결, 검토 기준을 포함합니다. 이건 사실 PM이 요구사항을 정리하는 방식과도 닮아 있습니다. 그래서 AI를 잘 쓰는 개발자는 자연스럽게 요구사항을 잘 쪼개는 사람이 됩니다.

AI가 만든 코드는 보통 평균적인 스타일입니다. 우리 팀의 네이밍, 폴더 구조, 컴포넌트 규칙, 에러 처리 방식과 맞지 않을 수 있습니다. 이걸 그대로 PR에 올리면 리뷰에서 많이 걸립니다.

그래서 주니어에게도 "AI가 만들어준 코드를 우리 팀 코드처럼 바꾸는 능력"이 중요해집니다. 변수명을 바꾸고, 중복을 줄이고, 컴포넌트를 나누고, 에러 상태를 추가하고, 리뷰어가 이해할 수 있게 PR 설명을 쓰는 것. 이게 실제 업무에 가깝습니다.

프론트엔드 개발자는 단순히 화면을 예쁘게 만드는 사람이 아닙니다. 좋은 프론트엔드 개발자는 다음 네 가지를 함께 봅니다.

AI 시대에는 이 네 가지를 연결하는 능력이 더 중요해질 수 있습니다. 코드를 생성하는 비용은 낮아지고 있지만,

은 여전히 사람에게 남아있기 때문입니다.

그래서 앞으로 공부할 때도 "이 문법을 외워야지"에서 끝나지 않았으면 좋겠습니다. 이 문법이 화면에서 어떤 문제를 해결하는지, 팀에서 어떤 커뮤니케이션을 줄여주는지, AI가 만든 코드를 검토할 때 어떤 기준이 되는지를 같이 봐야 합니다.

AI 시대에 개발자의 역할은 사라진다기보다 바뀌고 있습니다. 코드를 직접 치는 시간은 줄어들 수 있지만, 무엇을 만들지 정하고, 결과를 검토하고, 팀의 맥락에 맞게 연결하는 능력은 더 중요해지고 있습니다.

특히 프론트엔드 개발자는 사용자와 가장 가까운 곳에 있으면서, 디자이너·백엔드·PM의 요구가 만나는 접점에 있습니다. 그래서 단순 구현력뿐 아니라 질문하는 능력, 조율하는 능력, 설명하는 능력, 리딩하는 능력이 중요합니다.

앞으로 JavaScript와 React를 배우는 과정에서도 이 관점을 계속 가져가면 좋겠습니다. 문법을 배우는 이유는 문법 그 자체가 아니라, AI가 만든 코드든 사람이 만든 코드든

입니다.