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

<strong>AI 시대에 개발자는 어떻게 일하는가</strong> <strong>프론트엔드 개발자는 웹 개발 프로세스에서 어디에 있는가</strong> <strong>프론트엔드 개발자에게 왜 조율과 리딩 능력이 중요한가</strong>

---

<strong>기획 / PM / PO</strong> — 무엇을 왜 만들지 정합니다. 요구사항,

우선순위, 일정, 사용자 문제를 다룹니다.

<strong>디자인</strong> — Figma 같은 도구로 화면과 사용 흐름을 설계합니다.

색상, 여백, 컴포넌트 상태, 반응형 화면이 여기서 나옵니다.

<strong>프론트엔드</strong> — 사용자가 직접 보는 화면을 구현하고, 디자이너의

시안을 실제 웹으로 바꾸며, 백엔드 API와 연결합니다.

<strong>백엔드</strong> — 데이터 저장, 인증, 비즈니스 로직, API를 만듭니다. <strong>배포 / 운영</strong> — 만든 서비스를 서버에 올리고, 에러와 성능을

모니터링합니다.

---

이름이 두 글자가 아니라 스무 글자면 어떻게 보일까? 이미지가 없으면 어떤 기본 이미지를 보여줄까? 모바일 화면에서는 이 카드가 한 줄에 몇 개 보여야 할까? 로딩 중, 에러, 빈 데이터 상태는 어떻게 보여줄까? 버튼을 누를 수 없는 상태는 어떤 색과 문구로 표현할까?

{
  "user_id": 12,
  "joined_at": "2026-05-04T10:00:00Z",
  "status": "PENDING"
}

// 화면이 원하는 형태
{
  userName: "진규",
  canApprove: true,
  unreadNotificationCount: 3,
  recentActivityLabel: "방금 전 PR을 열었습니다"
}

<strong>화면에 맞는 데이터 제공</strong>: 여러 API 응답을 프론트엔드에서

억지로 조합하지 않아도 됩니다.

<strong>클라이언트 코드 단순화</strong>: 화면 컴포넌트는 이미 가공된 데이터를

받아 렌더링에 집중할 수 있습니다.

<strong>네트워크 요청 감소</strong>: 여러 요청을 BFF에서 묶어 한 번에 내려줄

수 있습니다.

<strong>클라이언트별 최적화</strong>: 웹, 모바일, 어드민처럼 필요한 데이터가

다른 클라이언트에 맞춰 응답 형태를 다르게 설계할 수 있습니다.

<strong>보안상 숨겨야 할 정보 보호</strong>: 외부 API 키나 내부 서비스 구조를

브라우저에 직접 노출하지 않고 서버 계층에서 처리할 수 있습니다.

<strong>계층이 하나 늘어납니다</strong>: 장애 지점과 운영해야 할 코드가

추가됩니다.

<strong>로직 중복이 생길 수 있습니다</strong>: 백엔드에도 있는 비즈니스 규칙을

BFF에 다시 쓰기 시작하면 책임 경계가 흐려집니다.

<strong>프론트엔드 팀의 서버 역량이 필요합니다</strong>: 캐싱, 인증, 에러

처리, 배포, 모니터링 감각이 없으면 오히려 위험해질 수 있습니다.

<strong>백엔드와의 역할 충돌이 생길 수 있습니다</strong>: 어디까지가 백엔드

책임이고 어디부터가 BFF 책임인지 합의하지 않으면 팀 간 갈등이 생깁니다.

---

"이 버튼 위치 좀 바꿀 수 있어요?" "모바일에서는 왜 이렇게 보여요?" "이 데이터가 없을 때는 뭘 보여줘야 해요?" "API는 이렇게 내려가는데 화면에서 필요한 게 더 있나요?" "이 플로우, 사용자가 헷갈리지 않을까요?"

---

예전 방식: 내가 코드를 쓰고, AI가 옆에서 몇 줄을 제안한다. 지금 방식: 내가 목표를 설명하면, AI가 프로젝트를 읽고 필요한 파일을 찾아 수정한다.

<strong>기획 에이전트</strong>: 요구사항을 정리한다. <strong>구현 에이전트</strong>: 코드를 작성한다. <strong>리뷰 에이전트</strong>: 위험한 부분과 개선점을 찾는다. <strong>테스트 에이전트</strong>: 테스트를 실행하고 깨지는 부분을 확인한다.

요구사항 정리 → 구현 → 테스트 실행 → 코드 리뷰 → 수정 → 최종 보고

<strong>OpenClaw</strong>: 사람과 에이전트를 잇는 게이트웨이입니다. 텔레그램,

디스코드, 웹 같은 채널에서 들어온 요청을 적절한 에이전트나 세션으로 보내고, 결과를 다시 사람에게 돌려줍니다. 기억, 스케줄, 세션, 채널 라우팅 같은 운영 인프라가 여기에 붙습니다.

<strong>Hermes</strong>: 실제 코드 작업을 굴리는 에이전트 러너에 가깝습니다.

저장소를 읽고, 파일을 수정하고, 테스트를 실행하고, 결과를 보고하는 실행 환경입니다. 하네스 안에서 "실제로 손을 움직이는 팀원"이라고 보면 됩니다.

// 게임이 내부에서 쓰는 함수가 그대로 전역에 노출돼 있었다
applyLaser(anyRegion, anyRegion); // 1회 호출에 점수 +38

// 같은 호출을 반복하면 점수가 계속 올라가는 구조였습니다

---

이 코드가 요구사항을 만족하는가? 이 코드가 우리 팀 컨벤션과 맞는가? 이 상태 이름과 함수 이름이 읽기 쉬운가? 예외 케이스가 빠져 있지는 않은가? 성능이나 보안 문제가 생기지는 않는가? AI가 대충 뭉개고 지나간 부분은 없는가?

로그인 폼 컴포넌트를 만들어줘.
조건:
- 이메일/비밀번호 입력
- 로딩 상태에서는 버튼 disabled
- 실패 시 에러 메시지 표시
- 기존 Button 컴포넌트 사용
- 스타일은 현재 프로젝트의 Tailwind 컨벤션 따르기
- 접근성상 label과 input 연결하기

---

<strong>사용자</strong>: 이 화면을 처음 보는 사람이 이해할 수 있는가? <strong>디자인</strong>: 시안의 의도와 상태가 실제 웹에서 유지되는가? <strong>백엔드</strong>: 데이터 구조와 API가 화면 요구사항을 만족하는가? <strong>팀</strong>: 이 코드가 다른 사람이 읽고 고치기 쉬운가?

---

---