이 글은 얼마 전 회사에서 동료분들과 함께 나누었던 사내 기술 발표 내용을 조금 더 편하게 읽으실 수 있도록 정리해 본 글입니다.

한동안 '좋은 거짓말'과 '나쁜 거짓말'이라는 생각에 푹 빠져 있던 적이 있었어요. 문득 "우리 개발자가 할 수 있는 좋은 거짓말에는 어떤 게 있을까?", "작업 거의 다 끝났다는 안도감일까?", 아니면 "AI가 도와줬지만 내가 다 짰다고 둘러대는 귀여운 거짓말일까?" 같은 이런저런 생각이 꼬리를 물더라고요.

그러다 문득 '프론트엔드 개발자가 유저의 사용성을 높이기 위해 할 수 있는 착한 거짓말은 무엇일까?'라는 고민으로 이어지게 되었습니다. 관련 자료와 웹 브라우저의 동작 원리를 찾아보면서 꽤 흥미롭고 유용한 내용들을 많이 발견하게 되었고, 이렇게 블로그에 정돈해서 공유해 드립니다.

"우리 앱은 왜 이렇게 느린가요?"

프론트엔드 개발을 하다 보면 누구나 한 번쯤 가슴이 철렁 내려앉았을 질문이에요.

이런 이야기를 들으면 우리는 보통 개발자 도구를 열어 네트워크 탭을 확인하고, 번들 크기를 줄이거나 백엔드 개발자분과 함께 API 응답 시간을 단 0.1초라도 줄여보려고 열심히 고민하곤 합니다.

하지만 많은 시간과 리소스를 들여서 실제 응답 속도를 줄여도, 사용자가 느끼는 만족도는 기대만큼 올라가지 않는 경우가 많아요.

이유는 생각보다 단순합니다. 화면을 바라보고 느끼는 최종 주체는 기계가 아니라 '사람'이기 때문입니다.

실제 속도(Actual Speed) vs 체감 속도(Perceived Speed)

서버 처리가 0.5초 만에 끝났다고 하더라도, 그 시간 동안 화면이 하얗게 멈춰 있으면 사용자는 "앱이 왜 이렇게 버벅이지?"라고 느끼게 됩니다.

결국 프론트엔드 개발자가 고민해야 할 진짜 목표는 단순히 숫자로 찍히는 로딩 시간을 줄이는 것을 넘어, 사용자가 느끼는 '심리적 대기 시간'을 어떻게 편안하게 만들어줄 것인가에 닿아 있습니다.

사용자의 불안감을 덜어주고 반응성을 즉각적으로 느끼게 만들어주는 두 가지 대표적인 기법을 소개합니다.

1. 불확실성을 낮춰주는 '스켈레톤 UI (Skeleton Screen)'

예전에는 데이터를 불러올 때 화면 가운데에 빙글빙글 도는 스피너(Spinner)를 주로 띄워두곤 했습니다.

하지만 스피너는 언제 끝날지 알 수 없는 막연한 기다림을 주기 때문에, 사용자를 지루하게 만들고 이탈하게 만드는 원인이 되기도 해요.

이런 아쉬움을 해결해 주는 방법이 바로 스켈레톤 스크린(Skeleton Screen)입니다. 유튜브나 인스타그램처럼 데이터가 도착하기 전에 회색 박스로 화면의 뼈대를 먼저 보여주는 방식이에요.

왜 스켈레톤 UI가 더 빠르게 느껴질까요?

• 심리적 안정감: 화면이 이미 준비되고 있다는 느낌을 주어 답답함을 크게 덜어줍니다.
• 화면 덜컹거림(CLS) 방지: 데이터가 들어갈 자리를 미리 잡아두기 때문에 화면이 갑자기 밀려나는 현상을 막아줍니다.
• 체감 대기 시간 단축: 실제로 점진적으로 채워지는 뼈대를 볼 때, 사람들은 빈 화면에 스피너가 돌 때보다 대기 시간을 실제보다 훨씬 짧게 인지한다고 합니다.

2. 서버 응답을 기다리지 않는 '낙관적 UI (Optimistic UI)'

인스타그램이나 트위터에서 '좋아요' 버튼을 누를 때 로딩을 기다려보신 적이 있으신가요?

버튼을 누르자마자 0.1초 만에 하트가 예쁘게 채워지는 것을 보셨을 거예요. 사실 그 순간에는 서버가 요청을 받아서 데이터베이스에 저장하지도 못한 상태입니다.

프론트엔드에서 "특별한 문제가 없다면 이 요청은 당연히 성공할 거야!"라고 긍정적으로 가정하고, 화면의 색상이나 숫자부터 먼저 싹 바꿔주는 기분 좋은 눈속임 기법입니다.

낙관적 UI는 이렇게 흘러가요

1. 사용자 터치: 유저가 '좋아요'나 '북마크' 버튼을 누릅니다.
2. 화면 선반영: 서버 응답을 기다리지 않고 로컬 화면의 상태를 성공 상태로 즉시 변경합니다.
3. 비동기 요청: 백그라운드에서 조용히 서버로 실제 저장 API를 전송합니다.

왜 100ms(0.1초) 안에 반응해야 할까요?

서버의 확인을 받기도 전에 화면부터 먼저 바꿔야 하는 이유는, 인간의 뇌가 컴퓨터의 반응을 인지하는 시간 기준 때문이에요.

실제 서버 응답에 1초가 걸리더라도 프론트엔드가 0.1초 안에 기분 좋은 피드백을 먼저 주면, 사용자는 자신이 이 앱을 완벽하게 다루고 있다는 쾌적함을 느끼게 됩니다.

착한 거짓말의 철칙: 실패했을 때의 롤백(Rollback)과 안전 구역

사용자에게 기분 좋은 착시를 선물하는 만큼, 개발자는 뒤에서 철저한 안전장치를 마련해 두어야 합니다.

1. 실패했을 때 자연스럽게 되돌리기 (Rollback)

네트워크가 불안정하거나 서버 오류로 요청이 실패할 때를 반드시 대비해야 합니다.

• 먼저 바꿔두었던 화면 상태를 이전 상태로 부드럽게 원상복구합니다.
• "일시적인 네트워크 오류로 처리되지 않았습니다"처럼 친절한 토스트 메시지로 상황을 안내해 드려야 합니다.
• TanStack Query(React Query) 같은 도구를 사용하면 onMutate와 onError 옵션을 통해 이전 상태를 안전하게 기억해 두고 복구할 수 있어요.

2. 적용하면 안 되는 조심스러운 기능들

모든 곳에 낙관적 UI를 적용하면 오히려 큰 사고가 날 수 있습니다.

• 적용하기 좋은 곳: 좋아요, 북마크, 다크 모드 전환, 간단한 댓글 등록 등 실패해도 리스크가 작은 기능
• 절대 쓰면 안 되는 곳: 결제 승인, 계좌 송금, 회원 탈퇴처럼 데이터의 정확성이 생명인 금융 및 보안 관련 작업

마치며: 유저의 시간을 배려하는 프론트엔드 개발자

"진정한 프론트엔드 개발자는 단순히 코드를 치는 사람을 넘어, 유저가 느끼는 시간을 세심하게 연출하는 사람입니다."

주어진 디자인 시안을 화면으로 옮기는 것에 그치지 않고, 어떻게 하면 사용자의 대기 시간을 덜 지루하게 만들고 기분 좋은 즉각적인 반응을 줄 수 있을지 함께 고민해 보면 좋겠습니다.

복잡하고 거대한 아키텍처 개선도 물론 멋지지만, 오늘 소개해 드린 스켈레톤 UI나 낙관적 UI처럼 사람의 심리를 배려한 작은 코드 몇 줄로도 유저에게는 훨씬 더 완성도 높은 경험을 선물할 수 있으니까요.

AI 시대, '딸깍' 한 번에 코드는 나오는데... 왜 제 머리는 굳어가는 느낌일까요?

AI가 개발 현장에 깊숙이 들어온 지도 시간이 제법 흘렀습니다. 저 역시 클로드(Claude)나 제미나이(Gemini) 같은 도구들을 업무에 적극적으로 활용하면서, 확실히 생산성과 일 처리 속도가 눈에 띄게 빨라졌음을 체감합니다.

에러 로그를 분석하고 원인을 파악하는 일까지는 제 몫이지만, 막상 코드를 수정하거나 UI를 하나하나 고치고 HTML 태그를 적재적소에 다듬는 작업은 이제 AI에게 몇 줄 적어주면 '딸깍' 한 번에 해결되는 경우가 대부분입니다.

분명 일은 빨라졌고 퇴근도 원활해졌는데, 이상하게 마음 한구석이 찝찝합니다. 전처럼 머리를 쥐어짜며 코드를 수정하지 않다 보니, 진짜 제 머리가 점점 굳어가는 것만 같은 불안함이 들기 시작했습니다.

딸깍의 달콤함 뒤에 찾아온 묘한 부채감

주변을 둘러보면 지라(Jira) 티켓 내용을 그대로 복사해서 AI에게 넣고, 나온 결과물을 그대로 붙여넣은 뒤 남은 시간에 편하게 쉬는 모습을 보기도 합니다. 물론 주어진 일감을 빠르게 끝내는 것도 능력이고 효율이지만, 그렇게 하루를 보내고 나면 "내가 오늘 엔지니어로서 무슨 고민을 했지?"라는 질문이 남습니다.

AI가 다 해주는 환경에서 단순 코딩 노동을 덜어낸 것은 축복이지만, 그 자리에 깊이 있는 고민을 채워 넣지 않으면 정말 사고 회로가 정지해 버릴 것 같다는 위기감이 들었습니다.

"내가 진짜 머리가 굳어가고 있는 걸까, 아니면 그냥 요즘 생각이 없는 상태인 걸까?"

생각의 방향을 바꾸기 위한 작은 몸부림

이대로 AI가 주는 정답에 끌려다니는 '프롬프트 전달자'가 되고 싶지는 않았습니다. 그래서 요즘은 다 내려놓았던 책을 다시 집어 들기 시작했습니다.

다만 예전처럼 단순한 언어 문법이나 코드 작성법을 다룬 책보다는, 생각의 결이 조금 다른 책들에 눈이 갑니다.

• 코드 리팩토링과 좋은 구조: AI가 짜준 코드가 당장 잘 동작하더라도, 이것이 과연 우리 프로젝트 아키텍처에 모범적인 코드인가를 판단하기 위해 리팩토링 서적을 다시 읽고 있습니다.
• AI 프로세스 연동과 생산성 아키텍처: 단순히 웹 브라우저 창에서 질문하는 수준을 넘어, 클로드나 제미나이를 지라(Jira) 같은 협업 툴과 어떻게 연동해서 개발 프로세스 자체의 효율을 높일 수 있을지 고민하고 있습니다.

단순히 HTML, CSS, JS 문법을 손으로 치는 수고는 AI에게 맡기되, "이 아키텍처가 최선인가?", "AI를 이용해 우리 팀의 워크플로우를 어떻게 혁신할 것인가?" 같은 더 높은 차원의 고민으로 제 머리를 쓰기로 했습니다.

여러분은 이 시기를 어떻게 건너가고 계신가요?

여전히 문득문득 "내가 지금 머리를 잘 쓰고 있는 게 맞나?" 하는 생각이 들 때가 있습니다. AI라는 강력한 도구가 생겨난 전환기 속에서 다들 한 번쯤은 이런 혼란을 겪고 계시지 않을까 싶습니다.

여러분은 AI 시대에 코딩 손맛이 줄어들고 머리가 굳어가는 듯한 이 기분을 어떻게 극복하고 계신가요? 본인만의 고민 해결법이나, 사고력을 유지하기 위해 새로 시작하신 루틴이 있다면 편하게 댓글로 나눠주시면 감사하겠습니다.

우리가 개발하며 정보를 찾고 문제를 해결하는 방식이 완전히 바뀌었습니다. 과거에는 모르는 게 생기거나 에러가 나면 구글에 일일이 검색해서, 여러 블로그와 스택오버플로우(Stack Overflow) 글을 하나씩 찾아 조합해야 했습니다.

하지만 생성형 AI가 일상화된 지금, 개발자의 업무는 '검색'에서 'AI와의 대화 그리고 검증'으로 넘어가고 있습니다. AI는 이제 단순한 검색 도구가 아니라, 개발 속도를 획기적으로 올려주는 든든한 동료가 되었습니다.

1. 대충 물어보지 않고 '구체적인 상황' 알려주기

AI를 쓸 때 가장 흔한 실수는 너무 모호하게 물어보고, 기대와 다른 뻔한 답변이 나오면 실망하는 것입니다. 내가 무엇을 만들고 싶은지, 어떤 제약이 있는지를 구체적으로 알려줄수록 AI는 훨씬 똑똑한 답을 냅니다.

앞으로는 질문을 잘하는 것을 넘어, AI에게 일하는 배경과 환경(Context)을 제대로 세팅해 주는 능력이 필요합니다.

• 내가 쓰는 개발 환경 밝히기: 사용 중인 프레임워크 버전(React 19, Next.js App Router 등), 상태 관리 도구, 브라우저 지원 범위를 미리 알려줍니다.
• 원하는 데이터 모양 알려주기: 다루고자 하는 데이터의 타입(TypeScript Interface)과 결과로 나와야 하는 함수의 형태를 명확히 제시합니다.
• 진짜 목적 전달하기: 단순히 "이 에러 고쳐줘"라고 하기보다, "화면이 버벅이지 않도록(INP 성능 최적화) 메인 스레드 부담을 줄이는 방향으로 코드 바꿔줘"처럼 명확한 목표를 줍니다.

2. AI가 준 답을 무작정 믿지 말고 '검증하기'

AI는 그럴듯하고 멋진 코드를 금방 만들어 주지만, 그 코드가 내 프로젝트에 항상 완벽하게 들어맞는 것은 아닙니다. 잘 모르고 그대로 가져다 쓰면, 나중에 원인을 알 수 없는 버그가 생기거나 메모리가 새어 나가는 등 기술 부채가 크게 쌓일 수 있습니다.

결국 AI를 잘 쓴다는 것은 AI가 짜준 코드를 그대로 복사하는 것이 아니라, 웹이 작동하는 원리(CRP, V8 엔진의 메모리 관리, 렌더링 주기)를 바탕으로 그 코드가 정말 안전한지 꼼꼼하게 검사하고 통제하는 능력을 뜻합니다.

AI 코드를 검토할 때 스스로 던져야 할 질문

• 이 코드가 메모리나 실행 시간에 부담을 주지는 않는가?
• 브라우저가 화면을 빠르게 그리는 데 방해가 되지 않는가?
• 우리 팀의 작성 규칙과 타입 안정성에 잘 맞는가?

3. 마치며: AI를 똑똑한 보조자로 만드는 기본기

AI 덕분에 우리는 사소한 문법을 외우거나 반복적인 코드를 치는 데 걸리는 시간을 엄청나게 줄일 수 있게 되었습니다. 이렇게 아낀 시간은 전체적인 프로그램 구조를 고민하고, 사용자 경험(UX)을 높이며, 비즈니스 문제를 해결하는 데 써야 합니다.

AI라는 성능 좋은 도구를 제대로 조종하려면, 역설적이게도 개발자 자신의 기본기와 원리 이해가 훨씬 더 단단해야 합니다. AI에 휘둘리지 않고 중심을 잡을 때, 비로소 진짜 실력 있는 개발자로 성장할 수 있습니다.

요즘 웹 시장을 관통하는 핵심 트렌드 3가지와, 이 변화 속에서 우리가 앞으로 어떻게 살아남아야 할지 가볍지만 진지하게 정리해 보았습니다.

1. 무너진 경계: 하이브리드 아키텍처와 엣지 컴퓨팅

과거에는 브라우저 내부(클라이언트 사이드 렌더링, CSR)에만 집중하면 됐지만, 요즘은 서버와 클라이언트의 경계가 완벽히 무너졌습니다.

• 서버 컴포넌트(RSC)의 대중화: 이제 컴포넌트 단위에서 서버 리소스에 직접 접근하고, 클라이언트가 다운받아야 할 자바스크립트 번들 크기를 제로에 가깝게 줄이는 설계가 기본이 되었습니다.
• 엣지(Edge)로 가는 연산: 글로벌 다국어 처리(i18n)나 사용자 맞춤형 동적 콘텐츠가 사용자와 가장 가까운 서버인 '엣지 단'에서 처리됩니다.

엔지니어의 과제

이제 프론트엔드 개발자는 단순히 화면만 그리는 게 아니라, "이 데이터 연산은 서버, 엣지, 클라이언트 중 어디에 두는 게 최적일까?"를 네트워크 레이어 수준에서 고민하고 구조를 짤 줄 알아야 합니다.

2. 이제는 진짜 런타임 성능 싸움: INP 중심의 최적화

구글이 웹 성능 지표에서 FID를 폐기하고 INP(Interaction to Next Paint)를 전면에 내세운 지 시간이 좀 흘렀습니다. 이제 성능 최적화의 기준은 완전히 바뀌었습니다.

과거에는 "페이지가 처음에 얼마나 빨리 뜨는가(로딩 속도)"가 중요했다면, 요즘은 "사용자가 페이지 내에서 버튼을 누르고 화면을 조작할 때 얼마나 버벅임 없이 즉각 반응하는가(런타임 반응 속도)"가 핵심입니다.

초기 자바스크립트 파일 크기를 줄이는 것을 넘어, 브라우저 메인 스레드를 잡아먹는 무거운 연산을 쪼개고 프레임 드롭을 방지하는 런타임 최적화 역량이 개발자의 진짜 실력을 증명하는 지표가 되었습니다.

3. AI 시대, 코더(Coder)가 아닌 프로덕트 엔지니어의 부상

Cursor나 GitHub Copilot 같은 생성형 AI 툴이 개발자의 일상에 깊숙이 들어왔습니다. 솔직히 단순한 마크업을 치거나 피그마 시안을 컴포넌트 코드로 바꾸는 '기계적인 구현'은 이제 AI가 더 빠르고 정확하게 합니다.

그렇다 보니 시장에서는 단순 코더가 아닌 '프로덕트 엔지니어'를 원하고 있습니다.

• 비즈니스 가치 고려: 기술적인 완벽함에만 집착하기보다, 마감 일정과 서비스의 비용을 고려해 유연하게 타협점을 찾을 줄 아는 시야.
• 도메인 복잡도 해결: AI가 건드리기 힘든 거대한 모노레포/멀티레포의 의존성 관리, 공통 디자인 시스템 컴포넌트 설계 같은 고차원적인 구조를 짜는 능력.

마치며: 결국 본질은 변하지 않는다

기술의 유행은 계속 바뀌지만, 브라우저 런타임의 본질과 문제를 해결하는 엔지니어링 스킬은 결코 변하지 않는다고 생각합니다.

프레임워크의 새로운 API를 외우는 데 급급하기보다, 브라우저가 화면을 그리는 원리(CRP)를 이해하고, 메모리 누수를 추적하며, 비즈니스 문제를 주도적으로 해결하는 기본기에 집중하는 것. 그것이 이 거대한 변화의 파도 위에서 롱런할 수 있는 유일한 생존 전략이 아닐까 싶습니다.