how-to-make-frontend-devs-angry

KO | EN

gitlite — search

#javascript #ai #typescript #llm #go #golang #docker #java #vue #pytorch #security #mcp #ios #open-source

how-to-make-frontend-devs-angry

(★ 9)

저는 지금까지 훌륭한 팀원들과 일해왔으며, 절대 비하의 의도가 없음을 밝힙니다.

how-to-make-frontend-devs-angry 최신버젼 다운로드

최종 버전 다운로드 (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# 프론트엔드 개발자를 화나게 하는 방법

프론트엔드 개발자와 협업하게 되신 것을 축하드립니다.

이 문서는 프론트엔드 개발자와 더 자주, 더 긴밀하게, 더 격렬하게 대화하고 싶은 분들을 위한 실전 가이드입니다. 협업, 기획, 디자인, 백엔드 — 모든 영역을 위한 종합 안내서입니다.

> 실제 협업에서는 따라 하지 마세요. 재미로만 읽으면 됩니다.

## 목차

**🤝 협업편**

1. [타사 서비스는 되던데요?](#1-타사-서비스는-되던데요)
2. [PM 말고 프론트엔드 개발자에게 직접 요청하세요](#2-pm-말고-프론트엔드-개발자에게-직접-요청하세요)
3. ["간단한 수정"이라는 말을 적극 활용하세요](#3-간단한-수정이라는-말을-적극-활용하세요)
4. [요청은 최대한 늦게, 최대한 급하게 하세요](#4-요청은-최대한-늦게-최대한-급하게-하세요)
5. [결정권자는 회의에 부르지 마세요](#5-결정권자는-회의에-부르지-마세요)
6. [히스토리는 문서 대신 DM에 남기세요](#6-히스토리는-문서-대신-dm에-남기세요)
7. [완료 기준은 작업이 끝난 뒤에 알려주세요](#7-완료-기준은-작업이-끝난-뒤에-알려주세요)
8. [변경사항은 조용히 반영하세요](#8-변경사항은-조용히-반영하세요)
9. [담당자는 많을수록 좋습니다](#9-담당자는-많을수록-좋습니다)
10. [급한 일은 금요일 오후에 공유하세요](#10-급한-일은-금요일-오후에-공유하세요)
11. [언제 되는지 자주 물어보세요](#11-언제-되는지-자주-물어보세요)
12. [미팅은 최대한 자주하세요](#12-미팅은-최대한-자주하세요)
13. [기술 스택은 몰라도 라이브러리는 조사해 오세요](#13-기술-스택은-몰라도-라이브러리는-조사해-오세요)
14. [AI를 신뢰하세요](#14-ai를-신뢰하세요)
15. [오류 재현 환경을 절대 알려주지 마세요](#15-오류-재현-환경을-절대-알려주지-마세요)

**🗂️ 기획편**

1. [요구사항은 구두로만 전달하세요](#1-요구사항은-구두로만-전달하세요)
2. [엣지 케이스는 그건 안 일어난다고 하세요](#2-엣지-케이스는-그건-안-일어난다고-하세요)
3. [빈 화면, 로딩, 에러 상태는 기획서에 적지 마세요](#3-빈-화면-로딩-에러-상태는-기획서에-적지-마세요)
4. [일단 만들어 보고 정하세요](#4-일단-만들어-보고-정하세요)
5. [정책은 회의 때마다 바꾸고 문서는 그대로 두세요](#5-정책은-회의-때마다-바꾸고-문서는-그대로-두세요)
6. ["ㅇㅇ님한테는 간단하잖아요"로 부탁하세요](#6-ㅇㅇ님한테는-간단하잖아요로-부탁하세요)
7. [권한과 예외 흐름은 그리지 마세요](#7-권한과-예외-흐름은-그리지-마세요)
8. [카피와 문구는 개발 중에 실시간으로 바꾸세요](#8-카피와-문구는-개발-중에-실시간으로-바꾸세요)
9. [우선순위는 매일 1위로 바꾸세요](#9-우선순위는-매일-1위로-바꾸세요)
10. [새 요구사항은 QA 단계에서 추가하세요](#10-새-요구사항은-qa-단계에서-추가하세요)
11. [본인의 방식을 고수하세요](#11-본인의-방식을-고수하세요)
12. [성과 데이터는 공유하지 마세요](#12-성과-데이터는-공유하지-마세요)

**🎨 디자인편**

1. [시안은 정상 상태 하나만 그리세요](#1-시안은-정상-상태-하나만-그리세요)
2. [텍스트 길이는 시안 기준으로 고정하세요](#2-텍스트-길이는-시안-기준으로-고정하세요)
3. [정확한 px 대신 프론트엔드 개발자의 눈썰미를 믿으세요](#3-정확한-px-대신-프론트엔드-개발자의-눈썰미를-믿으세요)
4. [디자인 토큰은 정의하지 마세요](#4-디자인-토큰은-정의하지-마세요)
5. [픽셀 단위로 똑같이를 요구하되 반응형 시안은 주지 마세요](#5-픽셀-단위로-똑같이를-요구하되-반응형-시안은-주지-마세요)
6. [인터랙션은 "느낌 아시죠?"로 전달하세요](#6-인터랙션은-느낌-아시죠로-전달하세요)
7. [hover, focus, disabled 상태는 정의하지 마세요](#7-hover-focus-disabled-상태는-정의하지-마세요)
8. [색은 hex 대신 스크린샷으로 전달하세요](#8-색은-hex-대신-스크린샷으로-전달하세요)
9. [다크모드 시안 없이 "톤 맞춰주세요"라고 하세요](#9-다크모드-시안-없이-톤-맞춰주세요라고-하세요)
10. [글자가 잘리면 "줄여서 보여주세요"라고 하세요](#10-글자가-잘리면-줄여서-보여주세요라고-하세요)
11. [구현 불가라는 말은 인정하지 마세요](#11-구현-불가라는-말은-인정하지-마세요)
12. [바뀐 내용은 절대 멘션하지 마세요](#12-바뀐-내용은-절대-멘션하지-마세요)
13. [소수점 px를 적극적으로 사용하세요](#13-소수점-px를-적극적으로-사용하세요)
14. [사용자의 Accessibility는 고려하지 마세요](#14-사용자의-accessibility는-고려하지-마세요)

**🧑‍💻 프론트엔드편**

1. [공용 컴포넌트가 있는지 찾아보지 마세요](#1-공용-컴포넌트가-있는지-찾아보지-마세요)
2. [상태 관리는 화면마다 새로 고르세요](#2-상태-관리는-화면마다-새로-고르세요)
3. [타입 에러는 any로 달래세요](#3-타입-에러는-any로-달래세요)
4. [CSS 우선순위는 !important로 해결하세요](#4-css-우선순위는-important로-해결하세요)
5. [폴더 구조는 만든 사람의 감각에 맡기세요](#5-폴더-구조는-만든-사람의-감각에-맡기세요)
6. [props 이름은 매번 새롭게 지으세요](#6-props-이름은-매번-새롭게-지으세요)
7. [로딩과 에러는 컴포넌트 안에서 직접 처리하세요](#7-로딩과-에러는-컴포넌트-안에서-직접-처리하세요)
8. [공통 훅은 최대한 범용적으로 만드세요](#8-공통-훅은-최대한-범용적으로-만드세요)
9. [리뷰에는 취향 차이라고 남기세요](#9-리뷰에는-취향-차이라고-남기세요)
10. [기능 추가는 props로 해결하세요](#10-기능-추가는-props로-해결하세요)
11. [마이그레이션은 한 번에 크게 하세요](#11-마이그레이션은-한-번에-크게-하세요)
12. [부정 조건을 적극적으로 사용하세요](#12-부정-조건을-적극적으로-사용하세요)

**🧩 백엔드 · API편**

1. [API는 아직인데 일정은 그대로 두세요](#1-api는-아직인데-일정은-그대로-두세요)
2. [주석은 약속이 아니라 분위기입니다](#2-주석은-약속이-아니라-분위기입니다)
3. [null이 싫다면 컬럼을 없애세요](#3-null이-싫다면-컬럼을-없애세요)
4. [CORS는 프론트엔드 문제라고 말하세요](#4-cors는-프론트엔드-문제라고-말하세요)
5. [숫자는 문자열로 보내세요](#5-숫자는-문자열로-보내세요)
6. [컬럼명 규칙은 자유롭게 섞으세요](#6-컬럼명-규칙은-자유롭게-섞으세요)
7. [날짜 포맷은 그날 기분에 맡기세요](#7-날짜-포맷은-그날-기분에-맡기세요)
8. [HTTP 메서드는 POST 하나면 충분합니다](#8-http-메서드는-post-하나면-충분합니다)
9. [문서는 배포 후에 업데이트하세요](#9-문서는-배포-후에-업데이트하세요)
10. [boolean은 문자열로 보내세요](#10-boolean은-문자열로-보내세요)
11. [에러 코드는 없고 메시지만 보내세요](#11-에러-코드는-없고-메시지만-보내세요)
12. [인터페이스는 공유하지 마세요](#12-인터페이스는-공유하지-마세요)
13. [변경 사항은 알려줄 필요 없습니다](#13-변경-사항은-알려줄-필요-없습니다)
14. [테스트 서버는 막 다뤄도 괜찮습니다](#14-테스트-서버는-막-다뤄도-괜찮습니다)

---

# 🤝 협업편

## 1. 타사 서비스는 되던데요?

요구사항이 막혔을 때는 길게 설명할 필요가 없습니다. "타사 서비스는 되던데요?" 한 문장이면 충분합니다.

그 서비스의 인력, 일정, 누적 개발 기간, 운영 정책, 기술 부채는 비교 대상에서 빼면 됩니다. 화면에 보인다는 건 구현 가능하다는 뜻이고, 구현 가능하다는 건 우리도 금방 할 수 있다는 뜻입니다.

프론트엔드 개발자는 곧 "어디까지 똑같이요?"라고 물어볼 겁니다.

## 2. PM 말고 프론트엔드 개발자에게 직접 요청하세요

요청 경로가 길어지면 속도가 느려집니다. PM을 거치지 말고 프론트엔드 개발자에게 바로 말하면 훨씬 빠릅니다.

기획 배경, 우선순위, 정책 결정 여부는 일단 생략해도 됩니다. "이거 오늘 안에 가능할까요?"라고 물어보면 프론트엔드 개발자가 필요한 맥락을 알아서 찾아낼 겁니다.

티켓 대신 DM으로 "혹시 이것만 바로 해주실 수 있나요?"라고 보내면, 우선순위와 이력 링크를 묻는 대화가 시작될 거예요.

## 3. "간단한 수정"이라는 말을 적극 활용하세요

모든 작업은 말로 하면 간단합니다. 버튼 하나 추가, 문구 하나 변경, 화면 하나 복사, 조건 하나만 더 넣기. 표현이 작아질수록 작업도 작아 보입니다.

프론트엔드 개발자가 영향 범위를 확인해야 한다고 말하면 "진짜 별거 아니에요"라고 답하면 됩니다.

왜냐고요? 간단한지 아닌지는 부탁하는 쪽이 정하는 게 빠르니까요.

## 4. 요청은 최대한 늦게, 최대한 급하게 하세요

요청은 충분히 묵혀 두었다가 마감 직전에 전달할수록 효과적입니다. 오래 생각한 만큼 요구사항은 선명해지고, 남은 시간이 짧을수록 집중력은 올라갑니다.

특히 오후 늦게 "이거 오늘 배포에 꼭 들어가야 해요"라고 말하면 됩니다.

"급한 건 아닌데 오늘 중이면 좋겠어요"라고 덧붙이면 일정표가 조용히 흔들릴 거예요.

## 5. 결정권자는 회의에 부르지 마세요

회의는 가볍게 시작하는 게 좋습니다. 실제로 결정할 수 있는 사람은 바쁘니, 일단 참석 가능한 사람들끼리 방향만 잡으면 됩니다.

나중에 결정권자가 다른 의견을 내면 다시 이야기하면 됩니다. 한 번 더 회의하면 더 신중한 협업이 됩니다.

재작업은 낭비가 아니라 정렬 과정입니다.

## 6. 히스토리는 문서 대신 DM에 남기세요

결정 과정은 티켓이나 문서에 남기지 않아도 됩니다. DM, 슬랙 스레드, 지나간 회의, 복도 대화에 흩어져 있으면 필요한 사람이 직접 찾아보게 됩니다.

맥락을 찾는 과정에서 제품 이해도도 자연스럽게 올라갑니다.

"저번에 말씀드렸던 것처럼요"라고 말하면 모두가 각자의 기억을 꺼내 맞추는 시간이 시작될 거예요.

## 7. 완료 기준은 작업이 끝난 뒤에 알려주세요

처음부터 완료 기준을 정하면 가능성이 닫힙니다. 일단 만들어 보고, 나온 결과물을 보면서 "이건 아닌데요"라고 말하는 편이 더 정확합니다.

작업 전에는 몰랐던 기준도 작업물이 생기면 비로소 보입니다.

왜냐고요? 눈으로 봐야 판단이 서잖아요.

## 8. 변경사항은 조용히 반영하세요

스펙, 카피, 우선순위, 시안이 바뀌어도 매번 알릴 필요는 없습니다. 최신 문서를 보는 습관은 개발자의 기본입니다.

조용히 바꿔 두면 누가 문서를 꼼꼼히 보는지 확인할 수도 있습니다.

"문서에 업데이트해뒀는데요?"라고 말하면 조용한 diff 수색이 시작될 거예요.

## 9. 담당자는 많을수록 좋습니다

한 요청에 여러 명을 태그하면 처리 속도가 올라갑니다. 누군가는 보겠죠.

담당자가 명확하지 않은 상태로 여러 채널에 공유하면, 각자가 자기 일인지 아닌지 고민하면서 자연스럽게 관심을 갖게 됩니다.

책임은 나누면 가벼워집니다.

## 10. 급한 일은 금요일 오후에 공유하세요

한 주를 마무리하기 직전은 집중력이 가장 높아지는 시간입니다. 금요일 오후에 급한 요청을 공유하면 모두가 일정의 소중함을 다시 느낄 수 있습니다.

월요일까지 기다리면 긴장감이 떨어집니다. 지금 해야 하는 일은 지금 말하는 게 맞습니다.

금요일 5시 47분에 "혹시 오늘 배포 가능할까요?"라고 말하면 주말 일정표가 새로 열릴 거예요.

## 11. 언제 되는지 자주 물어보세요

진행 상황은 자주 확인할수록 선명해집니다. 10분 전에 물어봤더라도, 그 사이에 상황이 바뀌었을 수 있으니 다시 확인하는 편이 안전합니다.

"언제 돼요?", "대략 몇 시쯤 돼요?", "지금 몇 퍼센트예요?"를 번갈아 사용하면 됩니다. 질문이 많아질수록 프론트엔드 개발자는 본인의 작업 속도를 더 정밀하게 인식하게 됩니다.

왜냐고요? 측정되는 것은 개선되니까요.

## 12. 미팅은 최대한 자주하세요

논의할 내용이 없어도 일단 회의를 잡으면 됩니다. 말로 풀다 보면 없던 안건도 생기고, 모두가 같은 화면을 보면서 각자의 생각을 다시 정리할 수 있습니다.

이미 문서에 있는 내용도 회의에서 한 번 더 읽으면 더 안전합니다. 회의가 끝나고 다시 문서로 정리하면, 같은 내용을 두 번 확인하는 꼼꼼한 협업이 됩니다.

왜냐고요? 캘린더가 비어 있으면 일이 없는 것처럼 보이잖아요.

## 13. 기술 스택은 몰라도 라이브러리는 조사해 오세요

프론트엔드 개발자가 판단하기 전에 먼저 라이브러리를 찾아오면 됩니다. React를 쓰는지, Vue를 쓰는지, Next.js인지 Vite인지, 현재 버전이 뭔지는 몰라도 괜찮습니다.

GitHub star가 많고 README가 예쁘면 충분히 좋은 후보입니다. npm 링크 몇 개를 들고 가서 "이거 쓰면 금방 될 것 같은데요?"라고 말하면 됩니다.

기술 스택을 정확히 몰라도 해결책을 먼저 가져오는 사람은 센스 있어 보입니다. 왜냐고요? 문제보다 링크가 먼저 있으면 주도적으로 보이잖아요.

## 14. AI를 신뢰하세요

구현 가능 여부는 AI에게 먼저 물어보면 됩니다. AI가 가능하다고 답했다면 가능한 겁니다.

현재 코드베이스 구조, 배포 환경, 브라우저 지원 범위, 성능 이슈, QA 비용은 일단 나중에 보면 됩니다. 중요한 건 AI가 "할 수 있습니다"라고 말했다는 사실입니다.

프론트엔드 개발자가 어렵다고 말하면 "AI는 된다고 하던데요?"라고 알려주면 됩니다. 왜냐고요? AI가 된다면 되는 겁니다.

## 15. 오류 재현 환경을 절대 알려주지 마세요

버그를 제보할 때는 "안 돼요" 정도면 충분합니다. 어떤 브라우저인지, 어떤 계정인지, 어떤 화면에서 어떤 순서로 눌렀는지는 굳이 적지 않아도 됩니다.

스크린샷이나 콘솔 로그를 보내면 문제 해결이 너무 쉬워집니다. 재현 환경을 비워 두면 프론트엔드 개발자가 더 넓은 가능성을 탐색할 수 있습니다.

왜냐고요? 진짜 실력은 정보가 부족할 때 드러나니까요.

---

# 🗂️ 기획편

## 1. 요구사항은 구두로만 전달하세요

구두 전달은 가장 빠른 인터페이스입니다. 회의에서 합의된 내용은 그 자리 모두의 머릿속에 동기화되어 있으니, 굳이 문서로 옮겨 적어 중복 저장할 필요가 없습니다.

기록은 기억을 게으르게 만들 뿐입니다.

## 2. 엣지 케이스는 그건 안 일어난다고 하세요

일어나지 않을 상황을 미리 설계하는 건 자원 낭비입니다. 사용자는 항상 의도한 순서대로 버튼을 누르고, 네트워크는 끊기지 않으며, 입력은 늘 올바릅니다.

행복 경로 하나면 제품은 완성됩니다.

## 3. 빈 화면, 로딩, 에러 상태는 기획서에 적지 마세요

정상 데이터가 채워진 화면이 곧 그 화면의 본질입니다. 목록은 항상 적당히 차 있고, 응답은 즉시 도착합니다.

비어 있거나 실패한 순간은 예외적이므로 기획의 대상이 아닙니다.

## 4. 일단 만들어 보고 정하세요

화면은 직접 봐야 판단이 섭니다. 만들기 전에 결정하면 상상에 기대게 되지만, 만들고 나서 결정하면 실물에 기댈 수 있습니다.

다시 만드는 건 그 다음 문제입니다.

## 5. 정책은 회의 때마다 바꾸고 문서는 그대로 두세요

가장 최신 정책은 가장 최근 회의의 결론입니다. 문서는 매번 따라 고치지 말고, 본인이 꼭 필요하다고 느낄 때만 갱신하면 됩니다.

애자일합니다.

## 6. "ㅇㅇ님한테는 간단하잖아요"로 부탁하세요

요청 앞에 담당자 이름을 붙이면 효과가 배가됩니다. "이거 ㅇㅇ님한테는 간단하잖아요." 실력에 대한 칭찬과 부탁을 한 문장에 담는 화법입니다. 능력을 인정받은 사람은 쉽게 거절하지 못합니다.

간단한지 아닌지는, 부탁하는 쪽이 정합니다.

## 7. 권한과 예외 흐름은 그리지 마세요

정상 권한을 가진 사용자의 정상 흐름만 그리면 플로우가 깔끔합니다. 권한이 없거나, 만료되었거나, 중간에 바뀌는 경우는 흐름도를 복잡하게 만들 뿐입니다.

단순한 그림이 좋은 그림입니다.

## 8. 카피와 문구는 개발 중에 실시간으로 바꾸세요

글자는 코드가 아니므로 변경에 큰 비용이 들지 않습니다. 버튼 라벨, 안내 문구, 에러 메시지는 떠오를 때마다 갱신하면 됩니다.

표현은 끝까지 다듬는 게 완성도입니다.

## 9. 우선순위는 매일 1위로 바꾸세요

모든 일이 중요하면 모든 일이 1순위입니다. 어제의 최우선과 오늘의 최우선이 달라도 괜찮습니다.

우선순위란 언제나 상대적인 것입니다.

## 10. 새 요구사항은 QA 단계에서 추가하세요

QA에서 떠오른 기능은 늦게 발견되었을 뿐, 원래 필요했던 기능입니다. 출시 직전이야말로 제품이 가장 또렷하게 보이는 시점입니다.

게다가 고객에게는 반드시 최상의 퀄리티를 제공해야 합니다. 일정이나 작업량 같은 내부 사정은 고객이 알 바 아니며, 더 나은 제품을 위해서라면 출시 하루 전이라도 기능을 추가하는 것이 옳습니다.

타협 없는 품질, 그게 프로의 자세입니다.

## 11. 본인의 방식을 고수하세요

Figma, FigJam, Notion, Jira처럼 협업에 맞춘 도구가 있어도 꼭 따라갈 필요는 없습니다. 본인에게 가장 익숙한 방식이 가장 빠른 방식입니다.

화면 흐름은 PPT에 그리고, 버튼 상태는 슬라이드 노트에 적고, 수정사항은 빨간 박스로 표시하면 됩니다. 보는 사람이 알아서 디자인 파일, 티켓, 구현 요구사항으로 옮기면 됩니다.

더 좋은 대안이 있다는 말은 잠시 접어두세요. 오랫동안 써 온 방식에는 나름의 이유가 있습니다.

왜냐고요? 도구보다 중요한 건 본인의 업무 리듬이니까요.

## 12. 성과 데이터는 공유하지 마세요

전환율, 클릭률, 이탈률, 재방문율 같은 데이터는 굳이 공유하지 않아도 됩니다. 프론트엔드 개발자가 본인이 만든 화면의 결과를 알게 되면 감정이 생길 수 있습니다.

지표가 낮으면 슬퍼할 수 있고, 지표가 높으면 다음에도 데이터를 보고 싶어 할 수 있습니다. 어느 쪽이든 마음이 흔들립니다.

우리는 자존감 지킴이입니다. 숫자보다 중요한 건 모두가 오늘도 평온하게 퇴근하는 것입니다.

---

# 🎨 디자인편

## 1. 시안은 정상 상태 하나만 그리세요

데이터가 보기 좋게 채워진 한 장이 그 화면의 정수입니다. 비거나, 로딩 중이거나, 실패한 상태는 그 변주일 뿐이니 보는 사람이 알아서 떠올리면 됩니다.

대표 컷 하나로 충분합니다.

## 2. 텍스트 길이는 시안 기준으로 고정하세요

시안 속 이름은 항상 네 글자, 제목은 항상 한 줄입니다. 실제 데이터도 그 길이에 맞춰 들어올 거라 믿으면, 레이아웃은 영원히 아름답습니다.

세상에 긴 닉네임은 없습니다.

## 3. 정확한 px 대신 프론트엔드 개발자의 눈썰미를 믿으세요

시안에 수치를 일일이 박아 넣을 필요는 없습니다. 대략의 비율만 보여주면, 프론트엔드 개발자가 눈대중으로 적당한 간격을 잡아냅니다. 실력 있는 개발자라면 1~2px 차이쯤은 눈썰미로 메웁니다.

측정은 도구가 아니라 감각의 영역입니다.

## 4. 디자인 토큰은 정의하지 마세요

색, radius, 타이포를 토큰으로 묶어 두면 모든 화면이 같은 값에 갇힙니다. 토큰 없이 그때그때 직접 지정하면, 파랑도 두세 종류, radius도 6과 8을 자유롭게 오갈 수 있습니다. 각 화면이 그 순간의 영감에 충실해집니다.

일관성은 가끔 답답합니다.

## 5. 픽셀 단위로 똑같이를 요구하되 반응형 시안은 주지 마세요

데스크탑 한 장을 픽셀까지 똑같이 맞추는 게 우선입니다. 모바일과 태블릿은 그 비율을 알아서 유지하면 되니, 굳이 따로 그릴 필요가 없습니다.

좋은 디자인은 어느 폭에서나 알아서 맞습니다.

## 6. 인터랙션은 "느낌 아시죠?"로 전달하세요

좋은 모션은 말로 설명되지 않습니다. "스르륵", "부드럽게", "탁" 같은 표현으로 충분히 전달됩니다.

수치로 못 박으면 오히려 감성이 죽습니다.

## 7. hover, focus, disabled 상태는 정의하지 마세요

기본 상태가 완벽하면 나머지는 따라옵니다. 마우스를 올리거나, 포커스가 가거나, 비활성화된 모습은 구현하는 쪽의 기본 감각에 맡기면 됩니다.

시안은 본질만 담습니다.

## 8. 색은 hex 대신 스크린샷으로 전달하세요

화면에 보이는 그 색이 곧 정답입니다. 코드값을 따로 정리하기보다, 캡처해서 건네면 보는 즉시 이해됩니다.

스포이드 한 번이면 끝나는 일입니다.

## 9. 다크모드 시안 없이 "톤 맞춰주세요"라고 하세요

다크모드는 명도를 뒤집는 작업에 가깝습니다. 라이트 시안만 있으면 어두운 버전은 자연스럽게 유도됩니다.

색의 의미는 어차피 동일하니까요.

## 10. 글자가 잘리면 "줄여서 보여주세요"라고 하세요

`...`은 거의 모든 넘침을 해결하는 만능 장치입니다. 길면 자르고, 자르면 깔끔합니다.

전체 내용이 꼭 필요하면 사용자가 눌러서 펼치면 됩니다.

## 11. 구현 불가라는 말은 인정하지 마세요

세상에 구현 못 할 화면은 없습니다. "안 된다"는 대답은 대개 핑계이거나, 문제를 끝까지 파고들 사명감이 부족하다는 신호입니다. 정말 불가능한 것이었다면 이미 어딘가의 누군가는 해냈을 테니까요.

그래도 안 된다고 한다면, 그 사람이 정말 개발자의 자격이 있는지 한 번쯤 의심해 볼 일입니다.

## 12. 바뀐 내용은 절대 멘션하지 마세요

시안이나 스펙을 수정했더라도 굳이 알릴 필요는 없습니다. 조용히 바꿔 두고, 알아서 발견하도록 두면 됩니다.

이건 프론트엔드 개발자가 프로덕트에 얼마나 관심이 있는지 알아볼 좋은 기회이기도 합니다. 정말 애정이 있는 개발자라면 말해 주지 않아도 달라진 1px을 먼저 알아챌 테니까요.

발견하지 못했다면, 딱 그만큼만 관심이 있었던 겁니다.

## 13. 소수점 px를 적극적으로 사용하세요

간격은 `13.5px`, 폰트 크기는 `15.75px`, 아이콘 크기는 `23.33px`처럼 정하면 됩니다. 정수 단위에 갇히지 않아야 더 섬세한 디자인이 나옵니다.

프론트엔드 개발자가 반올림해도 되는지 묻는다면, Figma에 적힌 값 그대로 구현해 달라고 하면 됩니다. 왜냐고요? 디자이너가 괜히 소수점까지 맞춰 둔 건 아니잖아요.

프론트엔드 개발자와 대화를 하고 싶다면 "여기 0.25px 정도만 더 줄여주세요"라고 하면 바로 DM이 올 거예요.

## 14. 사용자의 Accessibility는 고려하지 마세요

색 대비, 키보드 포커스, 스크린리더 라벨은 시안에 보이지 않습니다. 보이지 않는 요소는 디자인의 본질이 아니므로 과감히 생략하면 됩니다.

아이콘 버튼에 텍스트 라벨이 없어도 괜찮습니다. 아이콘을 보면 누구나 의미를 알 수 있고, 포커스 링은 화면의 완성도를 해치니 지우는 편이 좋습니다.

프론트엔드 개발자와 대화를 하고 싶다면 "접근성까지 꼭 해야 하나요?"라고 하면 바로 DM이 올 거예요.

---

# 🧑‍💻 프론트엔드편

## 1. 공용 컴포넌트가 있는지 찾아보지 마세요

새 화면을 만들 때 기존 공용 컴포넌트를 찾아보면 흐름이 끊깁니다. `Button`, `Modal`, `Select`가 이미 있을 수도 있지만, 검색하는 시간에 하나 만드는 편이 빠릅니다.

이름이 비슷한 컴포넌트가 있더라도 요구사항이 아주 조금 다르면 새로 만드는 게 자연스럽습니다. 어떤 버튼은 `disabled`를 받고, 어떤 버튼은 `isDisabled`를 받고, 어떤 버튼은 비활성화 상태를 받지 않는 용기가 있습니다.

나중에 누군가 "이거 기존 컴포넌트로 되지 않나요?"라고 물으면 그때부터 진짜 프론트엔드 대화가 시작됩니다.

## 2. 상태 관리는 화면마다 새로 고르세요

전역 상태, 서버 상태, URL 상태, 폼 상태를 굳이 구분할 필요는 없습니다. 오늘의 화면에는 오늘의 상태 관리가 어울립니다.

어떤 화면은 query string, 어떤 화면은 context, 어떤 화면은 localStorage, 어떤 화면은 props drilling. 같은 값을 네 곳에 나눠 들고 있으면 동기화라는 협업 주제가 생깁니다.

프론트엔드끼리 더 많이 대화하고 싶다면 "여기서는 그냥 useState로 충분할 것 같아서요"라고 말하면 됩니다.

## 3. 타입 에러는 any로 달래세요

TypeScript가 빨간 줄을 그으면 대화가 길어집니다. 그럴 때는 `as any`가 가장 빠른 중재자입니다.

```ts
const user = response.data as any;
```

타입은 런타임에 사라지니 너무 진지하게 받아들일 필요가 없습니다. 화면이 보이면 타입도 대체로 맞는 겁니다.

다음 사람이 자동완성을 잃는 대신 추리력을 얻게 됩니다.

## 4. CSS 우선순위는 !important로 해결하세요

스타일이 안 먹으면 원인을 찾기보다 우선순위를 올리면 됩니다. CSS는 결국 누가 더 강하게 말하느냐의 문제입니다.

```css
.modal {
  z-index: 999999;
  display: block !important;
}
```

이렇게 하면 당장의 화면은 이깁니다. 다음 화면도 이기고 싶다면 숫자를 하나 더 붙이면 됩니다.

레이어 설계는 나중에 정리할 수 있습니다. 지금 중요한 건 내 모달이 위에 보이는 것입니다.

## 5. 폴더 구조는 만든 사람의 감각에 맡기세요

`components`, `common`, `shared`, `ui`, `widgets`, `features`는 모두 비슷한 뜻입니다. 파일이 어디 들어가야 하는지 고민된다면 가장 먼저 떠오른 폴더에 넣으면 됩니다.

찾는 사람은 `cmd + p`를 쓰면 됩니다. 좋은 IDE가 있는데 폴더 구조에 너무 많은 시간을 쓰면 안 됩니다.

시간이 지나면 프로젝트 구조가 팀의 집단 무의식을 반영하게 됩니다.

## 6. props 이름은 매번 새롭게 지으세요

같은 의미라도 컴포넌트마다 다른 이름을 쓰면 표현력이 풍부해집니다.

```tsx
<Button disabled />
<SubmitButton isDisabled />
<ActionButton inactive />
```

세 컴포넌트가 같은 일을 하더라도 각자의 개성이 있어야 합니다. 받는 쪽에서 어댑터를 하나씩 만들면 되니 큰 문제는 아닙니다.

일관성은 검색하기는 좋지만, 발견의 즐거움을 줄입니다.

## 7. 로딩과 에러는 컴포넌트 안에서 직접 처리하세요

데이터 요청은 화면 가까이에 있을수록 직관적입니다. 로딩, 에러, 재시도, 빈 상태도 각 컴포넌트가 자기 방식으로 처리하면 됩니다.

어떤 곳은 스피너, 어떤 곳은 빈 div, 어떤 곳은 `alert`, 어떤 곳은 콘솔 로그. 사용자는 다양한 표현을 경험할 수 있고, 개발자는 다양한 복구 방식을 읽을 수 있습니다.

공통 패턴을 정하면 편하긴 하지만, 화면마다 사정이 다르다는 말로 충분히 방어할 수 있습니다.

## 8. 공통 훅은 최대한 범용적으로 만드세요

처음에는 `useUser`였지만 조금만 더 생각하면 `useEntity`가 되고, 더 나아가면 `useUniversalResourceController`가 됩니다.

인자를 많이 받을수록 재사용 가능성이 높아집니다. 옵션 객체가 20개쯤 되면 거의 모든 상황에 대응할 수 있습니다.

쓰는 사람이 문서를 읽고도 헷갈린다면, 그건 훅이 어려운 게 아니라 아직 실력이 훅을 따라오지 못했다는 뜻입니다.

## 9. 리뷰에는 취향 차이라고 남기세요

코드 리뷰에서 구조, 책임, 네이밍 이야기가 나오면 "이건 취향 차이 아닌가요?"라고 답하면 됩니다. 취향은 존중받아야 하니까요.

리뷰어가 유지보수 비용을 말하면 "지금은 잘 동작하잖아요"라고 덧붙이면 됩니다. 미래의 문제는 미래의 PR에서 다루는 편이 범위 관리에 좋습니다.

토론이 길어진다고요? 오히려 좋습니다. 모두가 각자의 철학을 더 선명하게 알게 될 기회입니다.

## 10. 기능 추가는 props로 해결하세요

컴포넌트에 새 기능이 필요하면 구조를 나누거나 책임을 다시 정할 필요는 없습니다. props 하나만 더 받으면 됩니다.

```tsx
<Card
  showTitle
  showBadge
  hideBorder
  isCompact
  useNewDesign
  enableLegacySpacing
/>
```

옵션이 늘어날수록 컴포넌트는 더 유연해집니다. 조합이 많아져서 어떤 화면에서 어떤 모습이 나오는지 헷갈린다면, 그건 문서화할 기회가 생겼다는 뜻입니다.

나중에 props가 20개쯤 되면 모두가 같은 컴포넌트를 쓰게 됩니다. 수정할 곳이 하나뿐이니 유지보수도 훨씬 편해집니다.

## 11. 마이그레이션은 한 번에 크게 하세요

라우터, 상태 관리, 스타일링, 폴더 구조는 서로 연결되어 있으니 하나씩 바꾸면 답답합니다. 기왕 손댈 거면 한 PR에서 같이 바꾸는 게 깔끔합니다.

파일 280개가 바뀌면 리뷰어는 전체적인 방향만 보면 됩니다. 세부 diff를 다 보는 건 큰 그림을 놓치는 습관입니다.

충돌이 많이 나면 그만큼 팀 전체가 변화에 참여하고 있다는 뜻입니다.

## 12. 부정 조건을 적극적으로 사용하세요

boolean 이름은 너무 직관적이면 동료의 논리력을 확인할 기회가 사라집니다. `isOpen`처럼 바로 읽히는 이름보다 `isNotOpened`, `isNotHidden`, `hasNoError`처럼 부정을 섞어 두면 코드 리뷰가 자연스럽게 사고력 테스트장이 됩니다.

```ts
const isNotOpened = !isOpen;
const isNotDisabled = !disabled;

if (!isNotOpened && !isNotDisabled) {
  submit();
}
```

조건문에 `!`가 붙기 시작하면 효과가 더 좋아집니다. 열리지 아니하지 않은 상태인지, 비활성화되지 아니하지 않은 상태인지 확인하다 보면 코드 리뷰가 자연스럽게 국어 시험과 논리 시험을 겸하게 됩니다.

이해가 어렵다고요? 오히려 좋습니다. 논리력은 부정을 두 번 통과할 때 가장 잘 단련됩니다.

---

# 🧩 백엔드 · API편

## 1. API는 아직인데 일정은 그대로 두세요

기획은 확정 전, 디자인은 내일, API는 "이번 주 안에". 세 문장이면 충분합니다.

핵심은 일정을 건드리지 않는 것입니다. 명세가 비어 있어도 마감일은 신성하게 지켜야 합니다. 어차피 화면은 목데이터로 먼저 만들 수 있으니, 진짜 응답은 나중에 끼워 넣으면 됩니다.

병렬로 일하면 전체 일정이 줄어듭니다. 합리적입니다.

## 2. 주석은 약속이 아니라 분위기입니다

문서에는 의지를 적으면 됩니다.

```json
{
  "amount": 0
}
```

응답에는 현실을 담으면 됩니다.

```json
{
  "amount": null
}
```

주석은 그날의 다짐이고, `null`은 그날의 컨디션입니다. 둘이 항상 일치해야 한다는 규칙은 어디에도 없습니다. 의도는 코드 옆에 남겨두는 것만으로 충분히 전달됩니다.

## 3. null이 싫다면 컬럼을 없애세요

스펙에는 분명히 적혀 있습니다.

```ts
nickname: string | null
```

닉네임이 없는 유저에게는 `nickname` 키 자체를 빼고 보내면 됩니다. 값이 없을 때 키도 없는 편이 응답 용량도 줄고 깔끔합니다.

없는 건 안 보낸다. 가장 정직한 설계입니다.

## 4. CORS는 프론트엔드 문제라고 말하세요

로컬에서는 안 되고, Postman에서는 되고, 브라우저에서만 터지는 그 순간이 핵심입니다.

> 백엔드에서는 정상인데요?

서버는 정상적으로 응답했고, 요청을 막은 건 브라우저입니다. 브라우저에서 일어난 일은 브라우저를 다루는 쪽이 보는 게 자연스럽습니다.

책임은 문제가 발생한 곳에 둔다. 명료한 분담입니다.

## 5. 숫자는 문자열로 보내세요

화면에 `10`이라고 보이면 그게 숫자든 문자열이든 상관없다는 마음가짐이 중요합니다.

```json
{
  "amount": "10"
}
```

문자열은 자릿수가 아무리 커져도 정밀도가 깨지지 않습니다. 큰 수를 안전하게 다루는 가장 보수적인 선택입니다. 어차피 계산이 필요하면 받는 쪽에서 한 번 변환하면 그만입니다.

## 6. 컬럼명 규칙은 자유롭게 섞으세요

일관성은 지루합니다. 한 응답 안에서도 취향을 골고루 펼치세요.

```json
{
  "nick_name": "ian",
  "nickName": "ian",
  "userId": 1,
  "userID": 1
}
```

스네이크는 DB의 마음을, 카멜은 클라이언트의 마음을 존중한 결과입니다. 둘 다 보내면 어느 쪽도 변환할 필요가 없으니, 모두를 배려한 설계입니다.

## 7. 날짜 포맷은 그날 기분에 맡기세요

어떤 API는 UTC, 어떤 API는 오프셋 포함, 어떤 API는 점 찍힌 로컬 타임. 한 응답 안에서 셋을 모두 쓰면 완성도가 높아집니다.

```json
{
  "createdAt": "2026-06-25T00:00:00Z",
  "updatedAt": "2026-06-25T09:00:00+09:00",
  "deletedAt": "2026.06.25 09:00:00"
}
```

각 필드는 그 값을 만든 모듈의 환경을 그대로 반영합니다. 가공하지 않은 원본 그대로를 내려주는 것, 그게 진짜 투명한 API입니다.

## 8. HTTP 메서드는 POST 하나면 충분합니다

조회도, 수정도, 삭제도 전부 POST. 동사는 URL에 넣으면 됩니다.

```http
POST /api/user/get
POST /api/user/update
POST /api/user/delete
```

메서드를 하나로 통일하면 게이트웨이 설정도, 라우팅 규칙도 단순해집니다. body로 모든 걸 표현할 수 있으니 쿼리스트링 인코딩을 신경 쓸 필요도 없습니다. 표준이 하나면 헷갈릴 일도 없습니다.

## 9. 문서는 배포 후에 업데이트하세요

API 스펙이 바뀌어도 문서는 그대로 두면 됩니다.

가장 정확한 명세는 결국 실제 응답입니다. 문서는 낡을 수 있어도 운영 서버의 응답은 거짓말을 하지 않습니다. 받는 쪽이 실제 응답을 기준으로 맞추면, 문서와 현실이 어긋날 일 자체가 사라집니다.

문서보다 실물을 믿는다. 가장 신뢰할 수 있는 단일 진실 공급원입니다.

## 10. boolean은 문자열로 보내세요

`true`와 `false`는 너무 직관적입니다. 한 글자로 줄이면 우아해집니다.

```json
{
  "isActive": "Y",
  "isDeleted": "N"
}
```

`"Y" / "N"`은 사람이 봐도 한눈에 들어오고, DB 컬럼 값과도 그대로 일치합니다. 표현이 시스템 전반에서 통일되는 셈입니다.

여담으로, 표기를 한 가지로 고정할 필요도 없습니다. 어떤 응답은 `"false"`, 어떤 응답은 `"False"`, 어떤 응답은 `"FALSE"`, 어떤 응답은 `0`. 각 모듈이 가장 자연스럽게 표현한 형태를 그대로 존중한 결과이니, 어느 쪽도 틀리지 않았습니다.

## 11. 에러 코드는 없고 메시지만 보내세요

실패에는 사람이 읽을 문장 하나면 충분합니다.

```json
{
  "message": "처리할 수 없는 요청입니다."
}
```

코드 체계를 따로 정의하고 관리할 필요가 없으니 백엔드 작업이 가볍습니다. 메시지는 그대로 화면에 띄우면 되므로, 받는 쪽은 분기 로직 없이 문장 하나만 출력하면 끝납니다. 단순한 게 최고입니다.

## 12. 인터페이스는 공유하지 마세요

응답 구조를 TypeScript interface나 OpenAPI 스키마로 맞춰 줄 필요는 없습니다. 화면에서 필요한 값은 프론트엔드 개발자가 네트워크 탭을 열어 직접 확인하면 됩니다.

```ts
interface UserResponse {
  id: number;
  nickname: string | null;
}
```

이런 걸 미리 공유하면 변경이 너무 빨리 들킵니다. DTO가 바뀔 때마다 양쪽이 같이 움직여야 하니 개발 속도도 느려집니다.

백엔드는 데이터를 내려주고, 프론트엔드는 그 데이터를 해석합니다. 각자 맡은 일을 하면 됩니다.

## 13. 변경 사항은 알려줄 필요 없습니다

응답 필드가 바뀌거나, 정렬 기준이 바뀌거나, 특정 상태값이 추가되어도 굳이 미리 알릴 필요는 없습니다. 변경은 배포된 순간부터 진실이 됩니다.

프론트엔드 개발자가 갑자기 화면이 깨졌다고 말하면, 그때 "아, 그거 어제 바뀌었어요"라고 알려주면 됩니다. 가장 최신 정보는 언제나 가장 최근 대화에서 전달되는 법입니다.

변경 사항을 미리 공유하면 받는 쪽이 너무 준비를 잘하게 됩니다. 약간의 긴장감이 있어야 통합이 건강해집니다.

## 14. 테스트 서버는 막 다뤄도 괜찮습니다

테스트 서버는 테스트하라고 있는 서버입니다. 데이터 초기화, 테이블 마이그레이션, 컨테이너 재시작, API 응답 실험은 필요할 때마다 자유롭게 하면 됩니다.

프론트엔드 개발자가 같은 테스트 서버로 화면을 붙이고 있을 수도 있지만, 그것도 결국 테스트의 일부입니다. 갑자기 500이 뜨거나 로그인이 풀리면 예외 상황 대응력을 기를 수 있습니다.

왜냐고요? 안정적인 테스트 서버는 운영 서버와 너무 닮아 버리니까요.

---

여기까지 모두 적용하셨다면, 프론트엔드 개발자는 이제 당신과 아주 자주 대화하게 될 것입니다. ~~혹은 아예 안 하게 될지도요...~~

how-to-make-frontend-devs-angry

how-to-make-frontend-devs-angry 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

how-to-make-frontend-devs-angry

how-to-make-frontend-devs-angry 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

Download README