지난 글에서 배드민턴 레슨 예약 서비스를 만들었습니다.이전 글 보기서비스는 만들어졌는데 실제 사용 환경은 거의 모바일이었습니다.문제는 매번 브라우저를 열고 예약 페이지에 들어가야 한다는 점이었습니다.물론 홈 화면에 바로가기를 만들어도 됩니다.그런데 여기까지 만들었는데

JunctionX Korea 2026 참가 후기 보안 서비스를 만들러 해커톤에 갔다가 랜섬웨어에 걸렸습니다. 제목을 자극적으로 지은 것이 아닙니다. 정말 개발 중이던 서버에 이상이 생겼고, 결국 비트코인을 요구하는 랜섬노트까지 확인했습니다. 더 웃긴 건 당시 저

고객은 한 명이었습니다.실사용자는 16명이었습니다.외주비는 5만 원이었습니다.그리고 유지보수는 아직도 진행 중입니다.고객님, 5만 원에 평생 수정은 너무한 거 아닌가요?어느 날 남자친구가 물어봤습니다."배드민턴 레슨 예약하는 거 웹으로 만들 수 있어?"처음 들었을 때는

주식으로 돈도 벌고 개발도 순조로운 줄 알았습니다. 6월 전까지는요. 버튼 하나 뒤에 엔진·서버·외주·고객사까지 줄줄이 따라온 개발자 2년 차의 생존형 상반기 회고록.....

프론트엔드 프로젝트를 진행하다 보면 처음에는 대부분 직접 화면을 눌러보면서 기능을 확인하게 됩니다. 버튼을 클릭해보고, 검색어를 입력해보고, 목록이 잘 나오는지 보고, 상태가 바뀌는지도 직접 확인합니다. 처음에는 이 방식이 제일 빠르게 느껴집니다. 눈으로 바로

프론트엔드 개발을 하다 보면 한 번쯤 이런 요구사항을 만나게 됩니다.“새 알림이 오면 바로 화면에 보여주세요.”“상태가 바뀌면 새로고침 없이 반영되게 해주세요.”“채팅처럼 실시간으로 메시지가 오가야 해요.”“AI 답변이 한 글자씩 출력되면 좋겠어요.”처음에는 이런 요구

개발을 하다 보면 한 번쯤 이런 상황을 겪으셨을 겁니다.“파일도 있고, 경로도 맞는데 왜 이미지가 안 나오지…?”분명히 dist-electron 안에 파일도 있고,상대 경로도 맞는데…이미지가 안 보입니다.이럴 때 대부분 이렇게 생각합니다.그런데 의외로 진짜 원인은 따

안녕하세요, 프론트엔드 개발자 송연지입니다.…네, 하반기 회고도 또 늦었습니다. 하하 😇상반기 쓸 때만 해도 “이번엔 제때 써야지!” 했는데역시나 현실은 늘 예상보다 빠르고, 저는 늘 예상보다 바빴습니다.2025년 하반기도 마찬가지로,,,솔직히 말하면 너무 정신없어서

크리스마스가 오면 사람들은 트리를 꺼내고,개발자는 콘솔을 켭니다.그리고 이렇게 생각합니다.“별 찍고 공백 맞추는 트리…나도 한 번쯤은 만들어봤지.”이 트리의 문제점은 명확합니다.재미가 없습니다.너무 빨리 끝납니다.그리고 GPU가 전혀 아프지 않습니다.그래서 문제가 됩니

— 비동기 때문에 흔들리던 UI를 React가 직접 통제하기 시작한 순간프론트엔드 개발을 하다 보면 자연스럽게 하나의 고민이 생깁니다.“왜 로딩 UI가 이렇게 많지?”“왜 페이지 이동할 때 깜빡이지?”“데이터 패칭 실패하면 화면이 바로 죽는 이유가 뭘까?”“컴포넌트마다

— 다시 빌드하기 싫을 때 꼭 필요한 꿀팁입니다Electron 개발을 하다 보면, 이런 순간이 꼭 찾아옵니다.개발 모드에서는 정말 말 잘 듣던 앱이배포 모드(Prod)만 올라가면 갑자기 태도가 달라지는 순간이요.무한 로딩만 뱅글뱅글 돈다든지특정 페이지에서 멈춘다든지엔진

React로 개발하다 보면, 분명히 useEffect에 한 번만 API를 넣었는데… API 요청 로그가 두 번씩 찍히는 현상을 경험하신 적 있으신가요? 저도 Electron + React 기반 사내 프로젝트를 하다가, “어? 내 코드가 잘못된 건가? 서버가 중

Electron + Vite로 개발하면서 VM 환경에서 패키징을 하다 보면,“같은 코드, 같은 설정인데 엔진이 안 열린다”는 이상한 상황을 겪는 경우가 있습니다.처음에는 단순한 VM(가상머신) 속도 문제겠거니 하고 넘어갔지만,문제는 하루이틀이 아니라 빌드할 때마다 가끔

프론트엔드 개발자라면 누구나 한 번쯤 console.log("확인")을 찍어본 경험이 있을 겁니다. 저도 그랬습니다.디버깅의 든든한 친구, 언제 어디서나 호출하면 나타나는 log 친구.하지만 Electron 프로젝트에선 이 친구가 성능 병목의 주범이 될 수도 있습니다.

안녕하세요! 프론트엔드 개발자 연지입니다. 정신없이 달리다 보니 벌써 2025년 반이 지나갔네요. 지난 6개월은 정말 제 커리어에서 다이내믹하고 가장 진심이 담긴 시기였어요. 처음으로 프로젝트를 리딩했고, 처음으로 데스크탑 앱을 만들었고, 처음으로 스스로 부

시스템 커널 단에 접근하거나 드라이버를 후킹하고, 보안 모듈을 붙이는 작업을 진행하다 보면 이런 생각이 듭니다.“이 작업, 잘못 붙였다간 블루스크린(BSOD) 뜨는 거 아닌가요?”실제로 커널 단 작업은 단 하나의 실수만으로도 시스템이 멈추거나 부팅이 불가능해질 수 있습

Electron 앱을 개발하다가 .env 파일로 API 주소 같은 환경변수를 넣고 싶어서 이렇게 작성했어요.Node 환경에서 이 방식은 너무 당연하잖아요?그런데 Electron에서는… 왜 이게 안 될까요?Electron의 메인 프로세스(Main Process)는 실제로

프론트엔드 개발을 하다 보면 코드 리뷰에서 이런 말을 자주 듣게 됩니다.“이거 구조분해 안 했어?”“props에서 구조분해 해주세요”“store 값 구조분해해서 써주세요”그렇다면 이 구조분해란 정확히 무엇일까요?그리고 왜 쓰는 게 좋고, 언제 쓰면 오히려 독이 되는 걸

프론트엔드 프로젝트를 하다 보면 함수 이름 앞에 \_(언더스코어)가 붙은 코드를 종종 보게 됩니다.예를 들면 \_getUser, \_registerLeader 같은 함수들이죠.처음엔 단순한 스타일 차이 정도로 생각하기 쉽지만,실제로는 이 방식이 실무에서 꽤 널리 쓰이는

웹소켓 기반 애플리케이션을 운영하다 보면 가장 많이 마주치는 이슈가 바로👉 "연결이 끊겼는데도 UI는 멀쩡해 보이는 문제"입니다.특히 절전모드(슬립)나 노트북 덮기, 탭 전환 후 장시간 방치 같은 상황에서는브라우저가 웹소켓을 끊었음에도 readyState === OP