Google Sheets + Apps Script로 실제 예약 서비스를 만들어본 이야기

고객은 한 명이었습니다. 실사용자는 16명이었습니다. 외주비는 5만 원이었습니다.

그리고 유지보수는 아직도 진행 중입니다.

고객님, 5만 원에 평생 수정은 너무한 거 아닌가요?

어느 날 남자친구가 물어봤습니다.

"배드민턴 레슨 예약하는 거 웹으로 만들 수 있어?"

처음 들었을 때는 정말 간단해 보였습니다.

날짜 고르고, 시간 고르고, 예약 버튼 누르면 끝.

저도 가볍게 대답했습니다.

"이 정도면 만들 수 있겠는데?"

그렇게 외주비 5만 원을 받고 프로젝트를 시작했습니다.

물론 저는 이때 몰랐습니다.

예약 서비스에서 가장 쉬운 기능이 '예약하기'라는 것을.

예약 하나만 만들면 되는 줄 알았습니다

처음 기획했던 서비스는 단순했습니다.

배드민턴 레슨을 받는 회원들이 자신의 이름을 선택하고, 가능한 날짜와 시간을 확인한 뒤 예약하는 웹페이지.

실사용자는 약 16명이었습니다.

회원가입이 필요한 것도 아니었고, 대규모 트래픽이 들어올 서비스도 아니었습니다.

딱 배드민턴 레슨 회원들을 위한 작은 예약 페이지였습니다.

그런데 실제 사용하는 방식을 듣다 보니 하나씩 조건이 붙기 시작했습니다.

"사람마다 한 달에 신청 가능한 횟수가 달라."

아, 그러면 회원별 예약 횟수를 따로 관리해야겠네.

"학교 일정 때문에 특정 날짜에는 수업을 안 해."

그럼 휴무일 관리도 필요하겠네.

"신규 예약은 바로 되면 좋은데 변경이나 취소는 확인하고 싶어."

그럼 승인 프로세스도 있어야겠네.

"그리고 누가 입금했는지도 볼 수 있으면 좋겠어."

...네?

처음에는 분명

날짜 선택
→ 시간 선택
→ 예약

이었는데 어느 순간 관리자 페이지가 생겼습니다.

지금은 관리자 페이지에서

• 회원 관리
• 레슨 가능 요일 설정
• 시작/종료 시간 설정
• 예약 시간 간격 설정
• 휴무일 관리
• 회원별 월 예약 가능 횟수 관리
• 변경/취소 승인 및 반려
• 입금 여부 관리

까지 할 수 있습니다.

여기쯤 와서 슬슬 깨달았습니다.

이거 그냥 예약 버튼 하나 만드는 일이 아니었구나.

사용자 16명을 위해 서버를 만들어야 하나?

프론트엔드는 익숙한 조합으로 시작했습니다.

React
TypeScript
Vite
Tailwind CSS

문제는 데이터를 어디에 저장할 것이냐였습니다.

예약 서비스니까 당연히 DB는 필요합니다.

평소라면 자연스럽게 이런 구조를 먼저 생각했을 겁니다.

React
↓
Node.js / Spring Boot
↓
Database

그런데 프로젝트 규모를 다시 봤습니다.

실사용자 약 16명.

여기서 갑자기 서버를 띄우고, DB를 만들고, 배포 환경을 구성하고, 운영까지 하는 게 맞을까?

서비스보다 인프라가 더 거창해질 것 같았습니다.

그래서 이번에는 조금 다르게 접근해보기로 했습니다.

내가 직접 운영해야 하는 서버를 최대한 만들지 말자.

그렇게 선택한 게

Google Spreadsheet + Google Apps Script였습니다.

구조는 단순했습니다.

React
↓
Google Apps Script
↓
Google Spreadsheet

정확히 말하면 진짜 '서버가 없는' 것은 아닙니다.

Apps Script 역시 Google 서버에서 실행됩니다.

다만 제가 서버 인스턴스를 만들거나 프로세스를 띄우고 상태를 관리할 필요가 없는 Serverless에 가까운 구조로 사용한 것입니다.

서버 비용?

0원.

DB 비용?

0원.

외주비?

5만 원.

수익률이 상당히 좋아 보입니다.

아직 제 인건비를 계산하지 않았기 때문입니다.

계산하면 안 될 것 같습니다.

그런데 Firebase도 무료 아닌가요?

여기서 당연히 Firebase도 후보에 있었습니다.

사용자가 많지 않은 만큼 Firestore 무료 범위에서도 충분히 운영 가능한 규모였습니다.

그래서 단순히

"무료라서 Apps Script를 선택했습니다."

라고 하면 사실 이유가 부족합니다.

Firebase도 무료로 시작할 수 있으니까요.

제가 당시 Apps Script를 선택한 가장 큰 이유는 이번 규모에서 조금 더 가볍게 백엔드를 구성해보고 싶었기 때문이었습니다.

예약 데이터를 저장하는 것만 놓고 보면 정말 단순합니다.

이름
날짜
시간

그런데 실제 예약 하나를 확정하려고 하니 저장 전에 확인해야 할 조건이 꽤 많았습니다.

등록된 회원인가?
↓
지난 날짜인가?
↓
레슨 가능한 요일인가?
↓
휴무일인가?
↓
정상적인 시간인가?
↓
이미 예약된 시간인가?
↓
이번 달 예약 가능 횟수가 남았는가?
↓
예약

결국 필요했던 것은 단순한 저장소가 아니라 예약 규칙을 판단해 주는 작은 백엔드였습니다.

Firestore를 React에서 직접 사용하는 방법도 있었지만, 저는 최종 예약 판단을 프론트에 두고 싶지는 않았습니다.

프론트는

"19시 30분 예약할게요."

라고 요청만 하고,

백엔드에서는

회원 맞음. 휴무일 아님. 횟수 남음. 빈자리 맞음. 그럼 저장.

을 판단하는 구조를 원했습니다.

Firebase를 사용하면서 Cloud Functions 같은 백엔드 레이어를 함께 구성할 수도 있었지만, 당시에는 다시 이런 생각이 들었습니다.

사용자 16명인데, 일단 이렇게까지 필요한가?

대규모 데이터도 없고, 복잡한 검색도 없고, 초 단위 실시간 동기화도 필요하지 않았습니다.

그래서 Firebase를 배제했다기보다는,

Apps Script로 실제 서비스가 어디까지 가능한지 한 번 경험해보자는 쪽에 가까웠습니다.

Spreadsheet를 DB처럼 써봤습니다

구조를 정한 뒤 Spreadsheet도 역할별로 나눴습니다.

Settings
Members
Blackouts
Bookings
Quotas

Settings에는 레슨 시작·종료 시간이나 예약 간격, 가능 요일 같은 기본 설정을 저장했습니다.

Members에는 회원과 활성화 여부를 관리했습니다.

사용자가 자신의 이름을 직접 입력하지 않고 등록된 회원 중 선택하도록 한 이유도 있습니다.

자유 입력을 받으면 언젠가는 반드시

송연지
송 연지
연지
송연지님

같은 데이터가 생깁니다.

그리고 이걸 정리하는 사람은 저입니다.

싫습니다.

그래서 선택형으로 만들었습니다.

Blackouts에는 예약이 불가능한 특정 날짜를 저장했고, Quotas에서는 회원별 월 예약 가능 횟수를 관리했습니다.

가장 중요한 건 역시 Bookings입니다.

단순히 이름과 날짜만 저장하는 대신 예약의 상태까지 함께 남겼습니다.

id
name
date
slot
status
requestType
supersedesId
createdAt
decidedAt
note

신규 예약은 조건을 통과하면 바로 확정합니다.

requestType: new
status: approved

반면 변경이나 취소는 기존 예약에 영향을 주기 때문에 관리자 승인을 받도록 했습니다.

requestType: change / cancel
status: pending

그리고 supersedesId를 이용해 어떤 기존 예약에 대한 변경 또는 취소 요청인지 연결했습니다.

기존 예약 자체를 먼저 수정해버리지 않고 새로운 요청 데이터를 하나 추가하는 구조입니다.

그래서 변경 요청이 반려돼도 원래 예약은 그대로 남습니다.

처음에는 16명짜리 예약인데 이렇게까지 해야 하나 싶었는데, 실제 사용되기 시작하니 오히려 이런 부분이 중요했습니다.

그런데 Spreadsheet 세팅도 직접 하기 싫었습니다

여기까지 만들고 보니 새로운 Spreadsheet를 만들 때마다

Settings 만들고
Members 만들고
Bookings 만들고
헤더 적고
기본값 넣고...

하는 것도 귀찮았습니다.

그래서 Apps Script에 initSpreadsheet()를 만들었습니다.

한 번 실행하면 필요한 Sheet가 존재하는지 확인하고, 없다면 자동으로 생성한 뒤 헤더와 기본값까지 넣습니다.

덕분에 기본 구조는

Spreadsheet 생성
↓
Apps Script 연결
↓
initSpreadsheet()
↓
기본 데이터 구조 완성

정도로 만들 수 있게 됐습니다.

분명 Google Spreadsheet를 사용하고 있는데,

어느 순간 DB Migration 비슷한 걸 만들고 있었습니다.

그래서 Apps Script는 어떻게 연결했냐면

Google Spreadsheet에는 자체적으로 Apps Script를 연결할 수 있습니다.

상단의

확장 프로그램
→ Apps Script

로 들어가면 해당 Spreadsheet와 연결된 프로젝트를 만들 수 있습니다.

그리고 Apps Script에서는 별도의 npm 라이브러리 없이 Spreadsheet에 바로 접근할 수 있습니다.

const spreadsheet =
  SpreadsheetApp.getActiveSpreadsheet();

const sheet =
  spreadsheet.getSheetByName('Bookings');

const values =
  sheet.getDataRange().getValues();

Spreadsheet에

id | name   | date
1  | 연지   | 2026-08-01
2  | 홍길동 | 2026-08-02

가 있다면 JavaScript에서는 대략

[
  ['id', 'name', 'date'],
  ['1', '연지', '2026-08-01'],
  ['2', '홍길동', '2026-08-02']
]

같은 배열로 가져옵니다.

여기까지 하고 처음 생각했습니다.

어라...? 이 정도 규모면 진짜 DB처럼 써볼 만한데?

물론 MySQL이나 PostgreSQL 같은 데이터베이스를 대체한다는 뜻은 아닙니다.

다만 이 프로젝트 규모에서는 충분히 재미있는 선택지였습니다.

doGet, doPost로 API도 만들 수 있습니다

Apps Script를 Web App으로 배포하면 HTTP 요청도 받을 수 있습니다.

GET 요청은

doGet(e)

POST 요청은

doPost(e)

로 들어옵니다.

Express를 사용해봤다면 대충

app.get(...)
app.post(...)

와 비슷한 역할이라고 생각하면 됩니다.

예를 들어 프론트에서

?action=getState

로 요청했다면

function doGet(e) {
  const action = e.parameter.action;

  if (action === 'getState') {
    return jsonResponse(getState());
  }
}

형태로 조회할 수 있습니다.

예약 요청은 POST로 보냈습니다.

await fetch(APPS_SCRIPT_URL, {
  method: 'POST',
  headers: {
    'Content-Type': 'text/plain;charset=utf-8',
  },
  body: JSON.stringify({
    action: 'submitRequest',
    name: '송연지',
    date: '2026-08-22',
    slot: '19:30',
  }),
});

Apps Script에서는 다시 JSON으로 파싱합니다.

function doPost(e) {
  const body = JSON.parse(e.postData.contents);

  if (body.action === 'submitRequest') {
    return jsonResponse(
      submitRequest(body)
    );
  }
}

요청마다 URL을 따로 만들기보다

submitRequest
decide
saveSettings
saveMembers
...

처럼 action으로 분기했습니다.

사용자가 16명인데 Router 프레임워크부터 만들고 있으면 그건 서비스 문제가 아니라 제 문제일 가능성이 높습니다.

배포 버튼을 누르면 진짜 API 주소가 생깁니다

Apps Script에서

배포
→ 새 배포
→ 웹 앱

으로 배포하면 /exec 형태의 URL을 받을 수 있습니다.

https://script.google.com/macros/s/xxxx/exec

이걸 React 환경변수에 넣었습니다.

VITE_APPS_SCRIPT_URL=...

이후 프론트에서는 그냥 일반적인 API처럼 호출하면 됩니다.

fetch(`${API_URL}?action=getState`);

결국 프론트 입장에서는 평범합니다.

React
↓
HTTP Request
↓
JSON Response
↓
렌더링

그 뒤에 있는 서버가 Apps Script일 뿐입니다.

AWS 없습니다.

EC2 없습니다.

Docker 없습니다.

Nginx 없습니다.

그런데 API 주소는 있습니다.

이 맛에 해봤습니다.

그렇게 완성...인 줄 알았는데요

예약도 됐습니다.

관리자 페이지에서도 수정할 수 있었습니다.

신규 예약은 즉시 확정되고, 변경과 취소만 관리자의 판단을 받도록 만들었습니다.

모바일 반응형도 맞춰뒀습니다.

여기까지만 보면 잘 끝난 것 같았습니다.

실사용자들이 들어오기 전까지는요.

직접 사용하기 시작하니 가장 먼저 보인 건 속도였습니다.

한 번 화면을 조회할 때마다

Settings
Members
Blackouts
Bookings
Quotas

를 Spreadsheet에서 읽다 보니 묘하게 기다리는 시간이 생겼습니다.

사용자는 서버가 Google인지 AWS인지 관심 없습니다.

그냥 느리면 느린 겁니다.

그래서 처음 넣은 게 CacheService였습니다.

상태 조회처럼 자주 불리지만 매초 바뀌지는 않는 데이터는 일정 시간 Apps Script 캐시에 저장했습니다.

getState()
↓
캐시 있음?
↓
YES → 바로 반환

NO
↓
Spreadsheet 조회
↓
캐시 저장

그런데 캐시를 넣고 보니 새로운 문제가 생깁니다.

누군가 예약했는데 이전 상태가 캐시에 남아 있으면 안 됩니다.

그래서 쓰기 작업이 일어나는 순간 캐시를 삭제하도록 했습니다.

조회
→ Cache 사용

예약/변경
→ Cache 무효화

다음 조회
→ Spreadsheet 최신 데이터
→ 다시 Cache

이때 느꼈습니다.

캐시는 넣는 것보다 언제 버릴지 정하는 게 더 어렵구나.

사용자는 16명인데 Cache Invalidation을 고민하고 있습니다.

결국 브라우저에도 캐시를 만들었습니다

Apps Script만 캐싱하지 않고 프론트에서도 마지막으로 받아온 상태를 localStorage에 저장했습니다.

결국 구조가

Browser Cache
↓
Apps Script CacheService
↓
Spreadsheet

가 됐습니다.

예약처럼 데이터가 변경되면 프론트 캐시도 지우고, 다음 조회에서는 새로운 값을 가져옵니다.

분명 가볍게 시작한 프로젝트였습니다.

점점 안 가벼워지고 있습니다.

예약 하나 때문에 전체 Sheet를 다시 쓸 필요도 없었습니다

초기에는 Spreadsheet 전체 데이터를 읽고 다시 setValues()로 저장하는 방식도 사용했습니다.

그런데 예약은 계속 쌓이는 데이터입니다.

예약 한 건을 추가하기 위해

전체 Bookings 읽기
↓
새 예약 추가
↓
전체 삭제
↓
전체 다시 작성

하는 건 비효율적이었습니다.

그래서 신규 예약은

appendRow(...)

를 사용해 한 줄만 추가하도록 수정했습니다.

작은 최적화이지만 데이터가 누적될수록 차이가 날 수 있는 부분이었습니다.

솔직히 16명인데 굳이 여기까지 해야 하나 싶었습니다.

하지만 한 번 비효율이 보인 이상 그냥 지나가기는 어려웠습니다.

사용자 16명이어도 Race Condition은 생깁니다

그러다 예약 시스템다운 문제도 만났습니다.

19시 30분 자리가 하나 남았다고 해보겠습니다.

A와 B가 거의 동시에 예약 버튼을 누릅니다.

둘 다 데이터를 읽었을 때

19:30 → 예약 가능

이라면 둘 다 저장될 가능성이 있습니다.

사용자가 수만 명일 필요도 없습니다.

두 명이면 충분했습니다.

그래서 데이터를 변경하는 요청에는 Apps Script의 LockService를 사용했습니다.

A 예약
↓
Lock 획득
↓
예약 가능 여부 다시 검사
↓
저장
↓
Lock 해제

B 예약
↓
Lock 대기
↓
A 처리 완료
↓
다시 검사
↓
이미 예약됨

대신 단순 조회에는 Lock을 걸지 않았습니다.

읽기까지 모두 줄 세우면 괜히 느려지기 때문입니다.

이 프로젝트를 하면서 동시성 문제는 사용자 수보다

같은 공유 자원을 동시에 수정할 수 있느냐

가 더 중요하다는 걸 직접 체감했습니다.

Apps Script를 쓴다고 프론트 문제가 사라지는 건 아니었습니다

프론트에서 Apps Script로 요청을 보내면서 CORS도 만났습니다.

POST를 일반적인 application/json으로 보내면 preflight 문제가 생길 수 있어서

Content-Type: text/plain;charset=utf-8

로 보내고 body에는 JSON 문자열을 담았습니다.

fetch(API_URL, {
  method: 'POST',
  headers: {
    'Content-Type': 'text/plain;charset=utf-8',
  },
  body: JSON.stringify(data),
});

Apps Script에서는 다시

const body =
  JSON.parse(e.postData.contents);

로 변환했습니다.

서버를 직접 만들지 않으면 서버 문제가 사라지는 줄 알았습니다.

아닙니다.

종류가 조금 바뀔 뿐입니다.

실패했다고 다 재시도해도 안 됐습니다

네트워크 요청이다 보니 재시도 처리도 필요했습니다.

처음에는 단순하게 생각했습니다.

실패했으면 다시 보내면 되지.

그런데 예약 요청에서는 위험합니다.

Apps Script에서는 이미 저장했지만 응답을 받는 과정에서 네트워크 오류가 발생했다면, 프론트는 실패했다고 생각합니다.

그 상태에서 자동 재시도를 하면 같은 요청이 두 번 처리될 수도 있습니다.

그래서 상태 조회처럼 다시 실행해도 안전한 요청과

상태 조회
설정 조회

중복 실행되면 안 되는 요청을

예약
승인/반려

나눠서 처리했습니다.

결국

"실패했나?"

뿐만 아니라

"이 요청은 다시 실행해도 안전한가?"

까지 생각하게 됐습니다.

fetch() 하나에서 시작했는데 어느새 멱등성을 고민하고 있습니다.

5만 원입니다.

실시간까지 WebSocket을 쓸 필요는 없었습니다

누군가 새로 예약하면 다른 사용자 화면에도 어느 정도 빠르게 보여야 했습니다.

하지만 이 서비스에서 초 단위 실시간 동기화는 필요하지 않았습니다.

그래서 일정 시간마다 다시 조회하는 Polling 방식을 사용했습니다.

그리고 현재 브라우저 탭이 백그라운드라면 굳이 API를 계속 호출할 필요가 없으니

document.visibilityState

를 확인해 화면이 보이는 경우에만 갱신했습니다.

페이지 보고 있음
→ Polling

다른 탭 보고 있음
→ 요청 생략

WebSocket도 없고 Firebase의 실시간 Listener도 없지만,

현재 규모에서는 이 정도로 충분했습니다.

실제 사용자가 있다는 건 생각보다 재미있었습니다

이 프로젝트는 처음부터 실제 사용할 사람이 있었습니다.

그래서 개인 프로젝트와는 확실히 달랐습니다.

혼자 만드는 프로젝트에서는 제가 예상한 방식으로만 사용합니다.

만든 사람도 저고, 테스트하는 사람도 저니까요.

그런데 실제 사용자가 생기면 제가 생각하지 않은 사용 방식이 나옵니다.

"여기서 바로 변경할 수 있으면 좋을 것 같아."

"이 기능도 있으면 편할 것 같은데?"

"여기 조금 다르게 보이면 좋겠어."

이런 피드백이 실제 사용자에게서 들어왔고, 그걸 하나씩 반영하면서 기능이 계속 늘어났습니다.

처음에는

예약

하나였던 서비스가

회원별 예약 가능 횟수
휴무일
변경/취소
관리자 승인
입금 여부
관리자 페이지
모바일 반응형
캐시
Lock
Polling
재시도

까지 왔습니다.

처음 프로젝트를 시작했던 저에게 지금 코드를 보여주면 아마 이렇게 물을 겁니다.

"우리 5만 원 받은 거 맞지?"

네.

맞습니다.

실사용자의 가장 무서운 말

배포 후 가장 기분 좋은 말은

"잘 쓰고 있어."

였습니다.

그런데 이 말에는 높은 확률로 다음 문장이 붙습니다.

"근데 혹시 이것도 되나?"

업데이트 +1.

며칠 뒤,

"여기 이것만 조금 바꾸면 더 좋을 것 같은데."

업데이트 +1.

다시 며칠 뒤,

"아 그리고 하나만 더."

업데이트 +1.

그리고 고객은 제 남자친구입니다.

연락을 차단할 수도 없습니다.

결국 저는 한 번 통보했습니다.

고객님, 외주비 5만 원에 평생 무료 수정은 너무한 것 같습니다.

그런데 오늘도 GitHub에는 커밋이 올라갑니다.

유지보수 계약은 별개라는 사실을 다음 프로젝트 전에는 명확히 해야겠습니다.

그래도 사용자가 있다는 게 이 프로젝트의 가장 큰 장점이었습니다

말은 계속 업데이트한다고 투덜거리지만, 사실 개인적으로는 이게 이 프로젝트에서 가장 좋았던 점입니다.

포트폴리오용 프로젝트라면 보통

기능 구현
↓
배포
↓
끝

이 됩니다.

하지만 이 프로젝트는

기능 구현
↓
실제 사용
↓
피드백
↓
수정
↓
다시 사용
↓
새로운 요구사항

이 계속 반복됐습니다.

덕분에 기능을 만들 때도

"내가 보기 좋은가?"

보다

"실제 사용하는 사람이 편한가?"

를 더 많이 생각하게 됐습니다.

그리고 화면 하나를 추가할 때도 단순히 PC 화면만 보는 게 아니라 이미 만들어둔 모바일 반응형 화면에서

이 버튼 누르기 편한가? 이 정보가 한눈에 들어오는가? 예약 과정이 너무 길지는 않은가?

를 같이 보게 됐습니다.

만들고 끝나는 프로젝트가 아니라 실제로 굴러가는 서비스를 만들어본 것.

이게 가장 큰 경험이었습니다.

여기서 끝일까요?

아직은 아닐 것 같습니다.

현재도 모바일에서 사용할 수 있도록 반응형으로 만들어져 있지만, 실제 사용 패턴을 보면 휴대폰으로 접근하는 경우가 많아서 다음에는 PWA로 만들어 홈 화면에 설치해서 조금 더 앱처럼 사용할 수 있게 하는 것도 생각하고 있습니다.

프론트는 지금의 React 구조를 유지하면서 Web App Manifest와 Service Worker를 추가하고, Apps Script는 지금처럼 API 역할을 맡기는 방식입니다.

그러면 사용자는 매번 브라우저에서 주소를 찾아 들어오기보다 홈 화면 아이콘으로 바로 예약 페이지를 열 수 있습니다.

이것도 아직은

"꼭 해야 한다."

보다는

"이 구조로 어디까지 해볼 수 있을까?"

에 가까운 실험입니다.

Apps Script 자체를 모바일 앱으로 배포하는 것은 아니지만, 현재 React 웹을 PWA로 만들어 설치 가능한 웹앱 형태로 사용하는 것은 충분히 가능하니 이것도 한 번 해볼 만할 것 같습니다.

그리고 기능이나 회원 수가 지금보다 훨씬 많아지면요?

그때는 Apps Script를 끝까지 붙잡기보다는 Firebase 같은 구조로 가볍게 옮길 생각입니다. 하하.

Apps Script를 써본 것 자체가 꽤 재미있는 경험이었습니다

여기까지 보면 제가 Apps Script를 엄청 추천하는 것처럼 보일 수도 있는데,

그렇지는 않습니다.

이번 프로젝트에서 가장 재미있었던 건

"작은 실제 서비스라면 이런 구조로도 굴려볼 수 있구나."

를 직접 경험했다는 점입니다.

평소 같았으면 자연스럽게

Frontend
↓
Backend
↓
Database

를 만들었겠지만,

이번에는 Google에서 이미 제공하는 도구들을 조합했습니다.

React
↓
Apps Script
↓
Spreadsheet

그리고 그 구조 안에서도

• API 설계
• Validation
• Cache
• Cache Invalidation
• Race Condition
• Lock
• Polling
• 재시도 전략

같은 문제를 직접 만났습니다.

서비스가 작다고 고민까지 작아지는 건 아니었습니다.

오히려 작은 규모였기 때문에 이런 구조를 부담 없이 실험해볼 수 있었습니다.

마무리

처음 시작은 정말 단순했습니다.

"배드민턴 예약 웹 하나 만들어줄 수 있어?"

저는

"응."

이라고 했고,

5만 원을 받았습니다.

그리고 지금은 실제 16명의 회원들이 사용하는 예약 서비스가 됐습니다.

처음에는 Apps Script와 Spreadsheet를 사용해서 가볍게 만들어보자는 생각이었는데,

실제로 운영하다 보니 캐시도 넣고, 동시성도 처리하고, API 재시도 전략도 고민하게 됐습니다.

무엇보다 개인 프로젝트에서는 쉽게 경험하기 힘든

내가 만든 서비스를 실제 누군가가 계속 사용한다는 경험

을 할 수 있었습니다.

지금은 모바일 반응형까지 적용돼 실제 예약 페이지로 사용되고 있고,

다음에는 PWA도 한번 붙여볼까 생각하고 있습니다.

그리고 회원이 정말 많이 늘어난다면?

그때는 Firebase로 가볍게 이사할 생각입니다. 하하.

아마 그때는 또 이런 글을 쓰고 있지 않을까요.

"16명이라 Apps Script 썼는데 진짜 서비스가 되어버렸다 — Firebase 이사기"

그리고 마지막으로 하나 더 배웠습니다.

연인에게 외주를 받을 때는 유지보수 기간을 정해두자.

고객님.

5만 원에 평생 수정은 조금 그렇습니다.

...라고 말하면서 오늘도 수정하고 있습니다.

안녕하세요. 프론트엔드 개발자 송연지입니다.

뭐가 이렇게 시간이 빠른지, 2026년 상반기가 끝난 지도 벌써 한 달이 다 되어가네요.

스물일곱 살이 된 게 엊그제 같은데요. 이제 시간이 빠르다는 말을 입에 달고 사는 걸 보니 저도 착실하게 늙어가고 있나 봅니다.

예전에는 어른들이 “나이 들면 시간이 더 빨리 간다”고 말하면 그냥 바쁘게 살아서 그런 줄 알았습니다. 그런데 진짜더라고요.

1월이 시작된 지 얼마 안 된 것 같은데 정신을 차려보니 7월이었고, 상반기 회고를 쓰려고 메모장을 열었더니 8월이 코앞이었습니다.

왜 이렇게 늦게 쓰게 됐냐고요?

저도 알고 싶지 않았어요.

정확히는 7월이 저를 놓아주지 않았습니다.

원래는 상반기가 끝나자마자 멋지게 회고를 올리려고 했습니다. 1월부터 6월까지 배운 점을 차분히 정리하고, 앞으로의 계획까지 적은 다음 “하반기도 열심히 살아보겠습니다”라고 마무리할 생각이었습니다.

그런데 7월에 통합 테스트와 납품 일정이 한꺼번에 시작되면서 회고는커녕 제가 무슨 일을 했는지도 기억하기 어려워졌습니다.

상반기는 지나갔고, 7월은 저를 지나갔습니다.

그래도 더 늦으면 2026년 연말 회고에 상반기 이야기를 섞어 써야 할 것 같아서 이제라도 적어보려고 합니다.

이번 상반기를 한 문장으로 정리하면 이렇습니다.

화면을 구현하던 프론트엔드 개발자에서, 제품의 구조와 운영까지 고민하는 개발자로 강제 확장된 반년이었습니다.

제가 자발적으로 영역을 넓혔느냐고요?

일부는 맞습니다.

나머지는 일이 저를 찾아왔습니다.

저는 피하지 않았습니다.

피할 곳이 없었거든요.

그럼 2026년 상반기 회고를 시작해보겠습니다.

1월

별로 한 게 없다고 생각했는데, 기반 구조를 다시 만들고 있었습니다

처음 1월을 떠올렸을 때는 별다른 기억이 없었습니다.

“작년에 개발하던 거 계속 고쳤던 것 같은데?”

정말 이 정도였습니다.

업무 기록을 다시 보기 전까지는요.

기록을 살펴보니 1월에는 별일이 없었던 게 아니라, 너무 많은 일이 동시에 진행되어서 기억이 하나로 뭉쳐 있었습니다.

작년에 만들던 기능을 수정하는 동시에 제품 구조와 시스템을 다시 설계하고 있었습니다. 여기에 보안 인증 시험 일정까지 겹치면서 새로운 기능을 빠르게 분석하고 구현해야 했습니다.

새로운 기술이 들어왔지만, 기존 제품 구조는 그 기술을 자연스럽게 받아들일 준비가 되어 있지 않았습니다.

그렇다면 어떻게 해야 할까요?

구조부터 다시 봐야 합니다.

당시에는 이 답을 몰랐습니다.

그래서 처음에는 일단 기능부터 붙이려고 했습니다. 기존 코드에 새로운 기능을 연결하고, 화면에 버튼을 만들고, 엔진에서 값을 받아오면 끝날 줄 알았습니다.

끝나지 않더라고요 ㅎㅎ

왜냐고요?

저도 알고 싶지 않았어요.

버튼 하나를 추가하면 Electron 메인 프로세스와의 연결이 필요했고, 메인 프로세스에서는 다시 보안 엔진으로 요청을 전달해야 했습니다. 엔진에서 응답을 받으면 그 값을 다시 화면까지 보내야 했습니다.

화면에서는 버튼 하나였는데, 버튼 뒤에는 등장인물이 너무 많았습니다.

프론트엔드, Electron 메인 프로세스, IPC, 로컬 엔진, 서버가 각자의 방식으로 움직이고 있었습니다.

누구 하나라도 기분이 좋지 않으면 기능이 동작하지 않았습니다.

특히 매체 제어 기능을 연결하면서 엔진 통신을 본격적으로 다루기 시작했습니다.

엔진이 문제인가 싶어서 로그를 요청했습니다.

로그에는 정상이라고 적혀 있었습니다.

모두가 정상이라고 하는데 제품만 꺼지고 있었습니다.

이런 상황이 개발자를 가장 힘들게 합니다.

누군가 명확하게 실패하면 그 부분을 고치면 됩니다. 그런데 각 영역에서는 정상이라고 말하면서 전체 제품만 실패하면 어디서부터 봐야 할지 알기 어렵습니다.

결국 화면에서 엔진까지 요청이 이동하는 경로를 처음부터 하나씩 확인하기 시작했습니다.

사용자가 버튼을 눌렀는지, 렌더러 프로세스에서 이벤트가 발생했는지, IPC를 통해 메인 프로세스까지 전달됐는지 확인했습니다.

엔진에 전달하는 데이터가 올바른지, 엔진 프로세스가 실행 중인지, 요청과 응답의 ID가 일치하는지, 제한 시간 안에 응답이 돌아왔는지도 모두 확인해야 했습니다.

이때부터 제가 보는 로그의 분위기도 달라졌습니다.

예전에는 이런 로그를 봤습니다.

선택된 값: true
API 요청 성공
화면 렌더링 완료

평화롭습니다.

1월부터는 이런 로그를 보기 시작했습니다.

Pipe connection failed
Request timeout
Engine process terminated
Unknown response ID

문장에 살기가 있습니다.

화면 렌더링 완료는 저를 안심시키는데, Engine process terminated는 저에게 새로운 하루를 선물합니다.

시제품을 제품으로 바꾸려면 구조부터 달라져야 했습니다

기능을 하나씩 연결할수록 기존 구조의 한계도 보이기 시작했습니다.

당시 구조는 시제품을 빠르게 만드는 데에는 문제가 없었습니다. 기능을 구현하고 내부에서 실행해보는 수준에서는 충분히 동작했습니다.

하지만 보안 인증 시험과 실제 납품을 생각하자 이야기가 달라졌습니다.

시제품은 특정 환경에서 한 번 잘 동작하면 됩니다.

제품은 사용자가 매일 사용해도 계속 잘 동작해야 합니다.

시제품은 오류가 발생하면 옆에 있는 개발자가 설명할 수 있습니다.

제품은 오류가 발생하면 사용자가 혼자 상황을 이해해야 합니다.

시제품은 개발자가 직접 실행해줄 수 있습니다.

제품은 사용자가 직접 설치하고 실행해야 합니다.

생각해야 할 범위가 갑자기 넓어졌습니다.

처음에는 기존 구조에서 필요한 부분만 고치면 될 줄 알았습니다. 그런데 기능 하나를 수정하면 다른 기능이 영향을 받고, 그 부분을 고치면 다시 다른 곳에서 문제가 생겼습니다.

소프트웨어 구조가 서로 손을 잡고 있는 정도가 아니었습니다.

팔짱을 끼고 있었습니다.

하나를 움직이면 모두가 같이 움직였습니다.

결국 1월에는 눈에 보이는 기능을 만드는 것보다 제품 구조와 시스템 흐름을 다시 정리하는 데 더 많은 시간을 사용했습니다.

서버에서 관리할 데이터와 로컬에서 관리할 데이터를 나누고, 화면과 엔진 사이의 책임도 정리했습니다. 요청과 응답을 어떻게 연결할지, 통신이 실패하면 어떤 방식으로 처리할지도 고민했습니다.

이 작업은 생각보다 성취감이 적었습니다.

화면을 새로 만들면 캡처라도 남길 수 있습니다.

버튼을 추가하면 직접 눌러볼 수도 있습니다.

그런데 구조를 정리하는 일은 며칠 동안 고민해도 화면이 전날과 똑같아 보입니다.

그래서 퇴근할 때마다 생각했습니다.

“나 오늘 뭐 했지?”

분명 하루 종일 일했는데 보여줄 수 있는 것이 없었습니다.

하지만 지금 돌아보면 1월에 구조를 다시 보지 않았다면 이후 기능을 추가할 때 훨씬 더 힘들었을 것 같습니다.

당시에는 진도가 나가지 않는다고 느꼈지만, 사실은 앞으로 나아가기 전에 바닥을 다시 다지고 있었습니다.

1월에 배운 것은 화려한 프론트엔드 기술이 아니었습니다.

화면 뒤의 흐름을 이해하지 못하면 결국 화면도 제대로 만들 수 없다.

프론트엔드 개발자라고 해서 브라우저와 컴포넌트만 볼 수는 없었습니다.

사용자가 보고 있는 상태가 어디에서 만들어지고, 어떤 경로를 거쳐 화면까지 전달되는지 알아야 제대로 된 사용자 경험을 만들 수 있었습니다.

그리고 새해 첫 달부터 생각했습니다.

“올해 쉽지 않겠는데?”

예상은 정확했습니다.

2월

개발은 트레이드오프라는데, 포기할 수 있는 게 없었습니다

납품 일정이 다가오자 구조를 다시 보게 됐습니다

2월에도 1월에 시작한 개발을 이어갔습니다.

보안 인증 시험을 위해 추가한 기능을 다듬고, 엔진 통신을 안정화하면서 제품 구조도 조금씩 정리했습니다.

개발자의 행복 기준은 상황에 따라 낮아질 수 있습니다.

세 번 실행했을 때 한 번 성공하던 기능이 두 번 성공하면 발전입니다.

당시에는 정말 그 정도의 변화에도 안도했습니다.

그러던 중 납품 일정이 점점 가까워지기 시작했습니다.

시험을 위해 빠르게 만든 기능은 있었지만, 실제 사용자가 매일 사용하는 제품으로 보기에는 부족한 부분이 많았습니다.

내부에서는 개발자가 직접 프로그램을 실행하고, 문제가 생기면 바로 로그를 확인할 수 있습니다. 하지만 제품이 고객사에 전달된 뒤에는 개발자가 항상 옆에 있을 수 없습니다.

설치부터 사용, 오류 대응, 업데이트까지 모두 사용자가 직접 경험하게 됩니다.

이제는 기능이 단순히 ‘존재하는 것’만으로는 부족했습니다.

사용자가 기능을 발견할 수 있어야 했고, 현재 상태를 이해할 수 있어야 했으며, 문제가 생겼을 때 다음에 무엇을 해야 하는지도 알 수 있어야 했습니다.

결국 기존 일정을 일부 조정하고 제품 구조부터 다시 보기로 했습니다.

일정을 바꾸는 결정은 쉽지 않았습니다.

마감일은 이미 정해져 있었고 해야 할 일도 많았습니다. 구조를 다시 설계하는 동안에는 눈에 보이는 기능 개발이 느려질 수밖에 없었습니다.

하지만 기존 구조 위에 기능을 계속 쌓으면 당장은 빨라 보여도, 나중에는 더 큰 비용을 치르게 될 것 같았습니다.

개발은 트레이드오프라는 말을 많이 듣습니다.

속도를 선택하면 구조를 어느 정도 포기해야 하고, 안정성을 높이면 개발 시간이 길어집니다. 단순한 구조를 선택하면 확장성이 줄어들고, 확장성을 고려하면 초기 구현이 복잡해집니다.

저도 그렇게 알고 있었습니다.

그런데 실제 제품을 개발해보니 포기할 수 있는 것이 생각보다 많지 않았습니다.

빠르게 만들어야 하지만 안정적으로 동작해야 했습니다.

보안은 강해야 하지만 사용하기 쉬워야 했습니다.

기능은 많아져도 화면은 복잡해지지 않아야 했습니다.

서버 상태가 불안정해도 프로그램이 바로 무너져서는 안 됐고, 그렇다고 사용자에게 잘못된 상태를 보여줄 수도 없었습니다.

엔진의 응답을 기다려야 했지만 사용자를 무한 로딩 화면에 가둬둘 수도 없었습니다.

속도, 안정성, 보안, 사용성 중 무엇을 포기해야 할까요?

아무것도 쉽게 포기할 수 없었습니다.

고객에게는 모두 필요한 조건이었기 때문입니다.

물론 모든 조건을 완벽하게 만족하는 구조는 없습니다. 결국 우선순위를 정하고 선택해야 합니다.

다만 지금 빠르게 구현하기 위해 내린 선택이 이후 어떤 문제와 비용으로 돌아올지는 미리 생각해야 했습니다.

2월에는 코드를 작성하는 시간만큼, 이런 선택의 기준을 고민하는 데 많은 시간을 사용했습니다.

코드를 짜기 전에 기준부터 만들어야 했습니다

제품 구조를 다시 살펴보면서 운영 방식도 함께 정리해야 했습니다.

기능이 어떤 범위에 적용되는지, 서로 다른 설정이 겹쳤을 때 무엇을 우선할지, 사용자마다 다른 환경과 예외 상황을 어떻게 처리할지 기준이 필요했습니다.

화면을 만들려고 했는데 먼저 제품이 어떻게 동작해야 하는지를 정해야 했습니다.

버튼을 추가하려고 했는데 그 버튼이 어떤 상황에서 보여야 하는지부터 결정해야 했습니다.

상태를 표시하려고 했는데 어떤 조건을 정상으로 보고, 어떤 조건을 예외로 처리할지도 정리해야 했습니다.

개발을 시작하려고 할수록 기획 문서가 계속 늘어났습니다.

이때 과거의 제가 했던 생각을 반성했습니다.

“요구사항만 잘 정리하면 되는 거 아닌가?”

아니었습니다.

요구사항을 잘 정리하는 일이 가장 어려웠습니다.

사용자가 “조금 더 쉽게 사용할 수 있게 해주세요”라고 말하면, 개발자는 처음에는 화면이나 버튼을 하나 바꾸면 될 것 같다고 생각합니다.

하지만 실제로는 수많은 질문이 따라왔습니다.

어떤 상황에서 필요한 기능인지, 기존 방식과 무엇이 달라져야 하는지, 예외 상황에서는 어떻게 동작해야 하는지, 변경된 결과를 어디까지 유지해야 하는지 모두 결정해야 했습니다.

짧은 요구사항 하나가 새로운 기능 하나로 끝나는 것이 아니라, 새로운 흐름과 예외 상황을 함께 만들었습니다.

기획자가 하는 일은 단순히 화면을 그리는 것이 아니었습니다.

애매한 상황마다 기준을 만들고, 서로 충돌하는 요구사항 사이에서 우선순위를 정하는 일이었습니다.

코드는 잘못되면 오류라도 발생합니다.

정책과 흐름은 잘못 설계돼도 정상적으로 동작할 수 있습니다.

다만 사용자가 계속 불편할 뿐입니다.

오히려 더 무서운 문제였습니다.

2월에는 개발보다 제품의 시스템과 운영 흐름을 고민한 시간이 더 많았습니다.

회의를 하면 해야 할 일이 정리될 줄 알았습니다.

그런데 회의를 할수록 할 일이 늘어났습니다.

회의 전에는 기능 하나였는데, 회의가 끝나면 정상 상황과 실패 상황, 사용자 화면과 관리 화면, 기록과 예외 처리까지 여러 갈래로 나뉘어 있었습니다.

회의는 업무를 줄이는 자리가 아니었습니다.

그동안 보이지 않던 업무를 발견하는 자리였습니다.

이때 다시 한번 배웠습니다.

기획자를 쉽게 본 개발자의 최후는 직접 기획을 하게 되는 것입니다.

2월 말쯤에는 제품이 어떤 흐름으로 동작하고 운영되어야 하는지 조금씩 보이기 시작했습니다.

그리고 전체 흐름이 보이자 앞으로 해야 할 일도 함께 보였습니다.

모를 때가 조금 더 행복했습니다.

범위를 파악하니 무서워졌습니다.

3월

P2P가 대체 뭔데요?

프론트엔드도 통신 구조를 알아야 했습니다

3월부터는 P2P와 서버 통신 구조를 본격적으로 공부하기 시작했습니다.

처음 P2P라는 단어를 들었을 때는 알고 있다고 생각했습니다.

Peer to Peer.

기기나 사용자가 서로 연결되는 방식.

여기까지는 알고 있었습니다.

하지만 “우리 제품에서는 정확히 어떻게 동작하는데요?”라는 질문에는 대답할 수 없었습니다.

그래서 공부를 시작했습니다.

WebSocket과 SSE를 사용해본 경험은 있었지만, 여러 PC와 서버, 관리자 페이지, 로컬 엔진이 동시에 상태를 주고받는 구조는 생각보다 훨씬 복잡했습니다.

누가 연결을 시작해야 하는지, 연결이 끊기면 어느 쪽에서 복구해야 하는지, 사용자가 오프라인일 때 발생한 요청을 어떻게 처리할지 정해야 했습니다.

서버의 상태와 로컬의 상태가 다를 때 어느 쪽을 기준으로 화면을 보여줄지도 고민해야 했습니다.

처음에는 생각했습니다.

“P2P가 대체 뭐야?”

조금 공부한 뒤에는 생각했습니다.

“이걸 왜 프론트엔드가 알아야 하지?”

조금 더 공부한 뒤에는 알게 됐습니다.

프론트엔드도 알아야 하더라고요.

결국 사용자는 모든 결과를 화면에서 보기 때문입니다.

사용자가 보고 있는 연결 상태가 정확하려면 실제 통신 구조를 이해해야 했습니다. 연결이 끊겼을 때 어떤 기능을 제한하고 어떤 기능은 계속 사용할 수 있게 할지도 시스템의 상태를 알아야 결정할 수 있었습니다.

서버에서는 정상적으로 처리됐더라도 로컬 환경에 반영되지 않았다면 사용자 입장에서는 실패였습니다.

반대로 내부적으로는 처리가 완료됐어도 화면에 결과가 나타나지 않으면 사용자는 아무 일도 일어나지 않았다고 느낄 수 있었습니다.

이때 서버의 성공과 사용자의 성공은 다를 수 있다는 것을 많이 배웠습니다.

3월부터는 서버 개발자분과도 이야기를 자주 나눴습니다.

그러던 중 예상하지 못한 사실도 알게 됐습니다.

서버 개발자분의 지인 중 제 벨로그를 읽고 계신 분이 있다는 것이었습니다.

회사에 벨로그를 들켰습니다.

사실 숨긴 적은 없습니다.

그렇다고 보여드린 적도 없습니다.

공개된 블로그이니 누구나 볼 수 있지만, 실제로 아는 사람이 읽고 있다는 사실을 알게 되니 느낌이 완전히 달라졌습니다.

그전까지는 개발 중 겪었던 오류와 해결 과정을 비교적 편하게 적었습니다. 회사나 제품을 특정할 수 있는 내용은 제외하고, 제가 어떤 문제를 만났고 어떻게 해결했는지를 중심으로 기록했습니다.

하지만 회사 사람이 볼 수 있다고 생각하니 문장 하나하나가 신경 쓰이기 시작했습니다.

“이거 너무 힘들어 보이나?”

“회사에 대한 불만처럼 읽히지는 않을까?”

“이 내용을 보면 내부 구조를 유추할 수 있지 않을까?”

글을 쓰다가 지우기도 하고, 제목을 바꾸기도 했습니다. 작성해놓고 올리지 않은 글도 생겼습니다.

벨로그를 들킨 뒤 잠깐 주춤했습니다.

그래도 나쁜 일만 있었던 것은 아닙니다.

벨로그 이야기를 계기로 서버 개발자분과 더 편하게 대화하게 됐고, 서로 어떤 방식으로 공부하고 문제를 해결하는지도 나눌 수 있었습니다.

기술적인 협업뿐 아니라 개발자로서 어떤 고민을 하고 있는지도 자연스럽게 이야기하게 됐습니다.

화면 몇 개가 아니라 운영 생태계를 만들고 있었습니다

3월에는 제품의 운영 프로세스도 본격적으로 설계하기 시작했습니다.

이전까지는 시제품에 가까웠습니다.

필요한 기능을 구현하고, 내부 환경에서 실행해본 뒤, 시연까지 무사히 끝나면 어느 정도 목표를 달성한 셈이었습니다.

하지만 제품을 실제로 판매하고 운영하려고 하니 전혀 다른 세계가 열렸습니다.

먼저 고객이 제품을 확인하고 구매할 수 있는 페이지가 필요했습니다.

구매 이후에는 고객사가 제품을 설정하고 사용 현황을 확인할 수 있는 관리자 페이지가 필요했습니다. 사용자가 외부에서도 필요한 정보를 확인할 수 있도록 모바일 서비스도 연결해야 했습니다.

여기에 여러 고객사와 전체 서비스 상태를 관리하는 별도의 서비스 관리자 페이지까지 필요했습니다.

처음에는 기존 제품에 화면 몇 개만 추가하면 될 줄 알았습니다.

구매 화면 하나.

관리 화면 몇 개.

모바일 화면 조금.

정말 그 정도로 생각했습니다.

하지만 운영 흐름을 하나씩 정리해보니 구매 페이지, 고객사 관리자 페이지, 모바일 서비스, 서비스 관리자 페이지가 각각 필요했습니다.

화면 몇 개를 추가하는 수준이 아니었습니다.

제품을 하나 더 만드는 것도 아니었습니다.

하나의 제품이 실제로 판매되고, 설치되고, 사용되고, 관리되기 위해 필요한 전체 생태계를 만들고 있었습니다.

더 어려운 점은 각각의 서비스가 따로 움직이면 안 된다는 것이었습니다.

구매 페이지에서 만들어진 정보는 고객사 관리자 페이지와 연결되어야 했고, 고객사가 변경한 설정은 실제 제품에도 반영되어야 했습니다.

모바일 서비스와 서비스 관리자 페이지 역시 서로 다른 데이터를 바라보면 안 됐습니다.

서비스는 여러 개였지만, 데이터와 흐름은 하나로 이어져야 했습니다.

겉으로 보면 서로 다른 화면과 서비스였지만, 사용자에게는 결국 하나의 제품이었습니다.

이쯤 되니 개발 범위가 우후죽순으로 늘어난 이유도 이해할 수 있었습니다.

기능 하나를 추가하는 것이 아니라, 제품이 실제로 굴러가기 위해 필요한 앞뒤 과정을 전부 만들고 있었기 때문입니다.

처음에는 기능만 완성하면 제품이 되는 줄 알았습니다.

하지만 실제 운영에서는 구매 이후의 과정, 처음 사용하는 사람의 흐름, 고객사가 제품을 관리하는 방식, 전체 서비스를 운영하는 방식까지 함께 설계해야 했습니다.

화면을 만드는 것보다 화면과 화면 사이의 관계를 정하는 일이 더 어려웠습니다.

그때 생각했습니다.

“설마 이걸 제가 다 개발하는 건 아니겠지?”

물론 모든 코드를 혼자 작성한 것은 아니었습니다.

다만 시간이 지날수록 예상했던 것보다 훨씬 많은 영역이 제 업무 범위 안으로 들어오고 있었습니다.

3월의 저는 아직 그 사실을 정확히 모르고 있었습니다.

모를 때가 조금 더 평화로웠습니다.

4월

개발실 밖으로 나가니 제품이 다르게 보였습니다

개발 환경에서 잘되는 것만으로는 부족했습니다

4월에는 납품 예정인 고객사를 직접 방문했습니다.

실제 사용 환경을 점검하고, 제품을 사용할 분들의 요구사항을 직접 들었습니다.

개발실에서는 대부분의 조건이 개발자에게 유리하게 맞춰져 있습니다.

네트워크는 비교적 안정적이고, 필요한 권한도 있으며, 문제가 발생하면 바로 개발자 도구와 로그를 열어볼 수 있습니다.

설치 과정에서 오류가 발생해도 원인을 확인할 수 있고, 설정이 잘못됐다면 바로 수정할 수도 있습니다.

하지만 고객사의 환경은 달랐습니다.

운영체제의 버전도 달랐고, 네트워크 구성과 보안 정책도 달랐습니다. 이미 설치되어 있는 프로그램과 충돌할 가능성도 확인해야 했습니다.

개발 환경에서는 설치 파일을 실행하고 몇 번 클릭하면 끝났던 과정이, 고객사에서는 설치 파일을 전달하는 방식부터 달라질 수 있었습니다.

관리자 권한이 필요한지, 내부 네트워크에서 서버와 정상적으로 통신할 수 있는지, 기존 프로그램과 충돌하지 않는지 하나씩 확인해야 했습니다.

코드가 정상이라고 제품이 정상인 것은 아니었습니다.

설치되지 않으면 사용할 수 없었고, 설치되더라도 사용자가 사용 방법을 이해하지 못하면 제품의 역할을 다할 수 없었습니다.

사용자가 이해하더라도 운영하는 사람이 관리하기 어렵다면 오래 사용하기 힘들었습니다.

개발실에서는 기능이 정상적으로 동작하는지를 주로 확인했습니다.

하지만 고객사를 직접 방문한 뒤부터는 기능을 구현할 때 다른 질문도 함께 하게 됐습니다.

“이 제품을 처음 보는 사람도 이해할 수 있는가?”

“현재 상태에서 다음에 무엇을 해야 하는지 알 수 있는가?”

“문제가 생겼을 때 사용자가 혼자 해결할 수 있는가?”

“개발자가 옆에 없어도 계속 사용할 수 있는가?”

개발자에게는 익숙한 화면과 문구도 처음 사용하는 사람에게는 전혀 다르게 보일 수 있었습니다.

우리가 중요하게 생각한 기능보다 사용자는 설치 과정이나 버튼의 위치, 안내 문구를 더 크게 불편해하기도 했습니다.

기술적으로 복잡한 기능을 구현하는 것도 중요했지만, 사용자가 제품을 처음 접하는 순간부터 불편하지 않게 만드는 것도 제품의 완성도였습니다.

이때부터 단순히 “동작하는가?”만 확인하지 않고, “실제로 사용할 수 있는가?”를 함께 생각하게 됐습니다.

개발실 안에서 제품을 볼 때와 실제 사용 환경에서 제품을 볼 때는 시선이 달랐습니다.

개발실에서는 코드와 기능이 먼저 보였고, 현장에서는 사람과 환경이 먼저 보였습니다.

외주 개발에서 가장 어려운 것은 같은 결과를 상상하게 만드는 일이었습니다

이 시기에는 모바일 프로젝트의 외주 개발 관리도 맡았습니다.

외주 관리는 이번이 두 번째였습니다.

두 번째라면 조금은 익숙할 줄 알았습니다.

그렇지 않았습니다.

프로젝트가 달라지면 어려운 이유도 새로 생겼습니다.

이번에는 내부 구조를 모두 공개하기 어려운 상황에서, 외부 개발자가 필요한 기능을 정확히 구현할 수 있도록 설명해야 했습니다.

내부 정보는 보호해야 했지만, 개발에 필요한 내용은 충분히 전달해야 했습니다.

“내부 구조는 자세히 설명할 수 없지만, 기능은 정확하게 구현해주세요.”

이렇게 말해서는 당연히 원하는 결과가 나올 수 없었습니다.

그래서 외부에 전달해도 되는 정보와 그렇지 않은 정보를 나눴습니다.

내부 구조 자체를 설명하는 대신, 외부에서 필요한 인터페이스와 데이터 형식, 화면의 동작 규칙을 중심으로 문서를 작성했습니다.

정상적으로 동작하는 경우만 적어서도 부족했습니다.

응답이 늦을 때는 어떤 화면을 보여줘야 하는지, 사용 가능한 기능이 제한되는 상황에서는 어떻게 안내해야 하는지, 알림이나 데이터 수신에 실패했을 때는 어떤 상태로 처리해야 하는지도 정리했습니다.

처음에는 기능 목록과 화면 디자인만 전달하면 충분하다고 생각했습니다.

하지만 같은 문장을 읽어도 사람마다 완성된 모습을 다르게 상상할 수 있었습니다.

예를 들어 ‘로그인 기능 구현’이라는 한 문장만으로는 완료 기준을 알 수 없습니다.

화면만 만들어지면 완료인지, 실제 데이터 연결까지 포함하는지, 로그인 상태를 유지해야 하는지, 실패했을 때 안내 메시지도 보여줘야 하는지 모두 다르게 해석할 수 있었습니다.

결과물을 받은 뒤에 “제가 생각한 건 이게 아닌데요”라고 말하지 않으려면, 개발 전에 기준을 더 명확하게 정해야 했습니다.

입력값은 무엇인지, 어떤 결과가 나와야 하는지, 실패했을 때 어떻게 처리해야 하는지, 어느 상태까지 구현돼야 완료로 볼 수 있는지를 함께 전달해야 했습니다.

이 과정에서 외주 관리에서 가장 어려운 것은 개발을 대신할 사람을 찾는 일이 아니라는 것을 배웠습니다.

제가 머릿속으로 알고 있는 제품을 상대방도 같은 모습으로 상상할 수 있도록 만드는 일이 가장 어려웠습니다.

문서를 길게 작성한다고 항상 정확한 것은 아니었습니다.

설명이 많아도 해석할 수 있는 방향이 여러 개라면 결과도 여러 개가 나왔습니다.

반대로 문장이 짧더라도 조건과 결과, 완료 기준이 명확하면 서로 같은 방향을 바라볼 수 있었습니다.

좋은 문서는 많은 내용을 담은 문서가 아니라, 서로의 해석 차이를 줄여주는 문서였습니다.

4월에는 직접 코드를 작성하는 것만큼, 다른 사람이 정확한 코드를 작성할 수 있도록 설명하는 일도 중요하다는 것을 배웠습니다.

그리고 제품을 잘 만드는 것만큼, 제품을 사용하는 사람과 함께 만드는 사람이 같은 모습을 바라보게 하는 일도 중요했습니다.

5월

아직은 각자의 자리에서 평화로웠습니다

외주 개발을 관리하며 각자의 개발을 마무리했습니다

5월에는 외주로 진행 중이던 모바일 프로젝트를 계속 관리하면서, 제가 담당한 개발도 하나씩 마무리하고 있었습니다.

외주 개발은 직접 코드를 작성하는 것과는 또 다른 어려움이 있었습니다. 제가 머릿속으로 이해하고 있는 기능을 상대방도 같은 모습으로 이해할 수 있도록 설명해야 했고, 화면이 보이는 것만으로 완료라고 볼 수 있는지, 실제 데이터 연결과 예외 처리까지 포함해야 하는지 기준도 명확하게 전달해야 했습니다.

처음 외주 관리를 맡았을 때는 요구사항을 자세히 적으면 충분할 것이라고 생각했습니다.

하지만 ‘자세한 문서’와 ‘정확한 문서’는 달랐습니다.

설명이 길어도 해석할 수 있는 방향이 여러 개라면 결과도 여러 개가 나왔습니다. 반대로 문장이 짧더라도 입력값과 결과, 예외 상황, 완료 기준이 명확하면 서로 같은 결과를 바라볼 수 있었습니다.

5월에는 전달받은 결과물을 확인하고, 실제 동작과 예상한 흐름이 다른 부분을 정리해 다시 전달하는 일을 반복했습니다.

예전에는 문제가 보이면 바로 코드를 열어 확인했습니다. 외주 프로젝트에서는 제가 직접 코드를 고치는 대신, 어떤 조건에서 문제가 발생했고 기대한 결과와 실제 결과가 어떻게 다른지 설명해야 했습니다.

덕분에 적어도 스크린샷 한 장과 함께 “여기 이상해요”라고 보내는 사람에서는 조금 벗어난 것 같습니다.

회사 프로젝트에서는 제가 담당한 영역을 중심으로 개발을 이어갔습니다.

당시에는 역할이 어느 정도 나뉘어 있었습니다. 각자 맡은 기능을 개발하고, 마지막에 서로 연결하면 제품이 완성될 것이라고 생각했습니다.

각자의 개발 환경에서는 기능이 잘 동작했습니다.

제가 만든 부분도 동작했고, 다른 영역도 각자의 기준에서는 정상적으로 진행되고 있었습니다. 화면도 하나씩 완성되고 있었고, 일정도 생각보다 크게 밀리지 않는 것처럼 보였습니다.

그래서 5월에는 비교적 편안한 마음으로 제가 맡은 개발에 집중했습니다.

“이 정도면 일정에 맞출 수 있겠는데?”

당시에는 그렇게 생각했습니다.

물론 지금 생각하면 통합 테스트도 시작하지 않은 개발자의 순진한 자신감이었습니다.

각자의 영역에서 잘 동작하는 것과, 모든 영역을 연결했을 때 하나의 제품으로 잘 동작하는 것은 완전히 다른 문제였습니다.

하지만 5월의 저는 아직 그 사실을 온몸으로 경험하기 전이었습니다.

서로 다른 영역에서 사용하는 데이터의 기준과 상태가 완전히 같은지, 한쪽에서 변경된 값이 다른 쪽에는 언제 반영되는지, 실패했을 때 어느 영역에서 책임져야 하는지까지는 충분히 확인하지 못했습니다.

통합 전에는 모두가 자신의 환경에서 정상입니다.

통합을 시작하는 순간, 각자가 생각하는 ‘정상’이 얼마나 달랐는지 알게 됩니다.

그 사실을 몰랐던 5월은 비교적 평화로웠습니다.

개발 공부 대신 주식 공부에 빠졌습니다

그리고 이 시기에는 개발 공부보다 주식에 조금 더 관심을 두고 있었습니다.

마침 시장 분위기도 괜찮았고, 초반에는 수익도 조금 생겼습니다. 차트를 보고 관련 뉴스를 찾아보는 일이 생각보다 재미있었습니다.

개발하다가 오류를 만나면 로그를 보고, 퇴근 후에는 주식 차트를 봤습니다.

어느 순간부터는 기술 문서보다 기업 뉴스를 더 많이 읽고 있었습니다.

수익이 생기니 자신감도 같이 생겼습니다.

“혹시 개발 외에 새로운 재능을 발견한 건 아닐까?”

잠깐은 정말 그렇게 생각했습니다.

개발자로 일한 지도 2년 정도가 지나면서 업무에 익숙해졌고, 처음처럼 퇴근 후 매일 새로운 기술을 찾아보지는 않게 됐습니다. 회사에서 하루 종일 개발하고 있으니 별도의 공부를 조금 쉬어도 괜찮다고 생각했습니다.

그 빈자리를 자연스럽게 주식 공부가 채웠습니다.

돌이켜보면 이 시기의 수익은 실력보다는 시장 분위기와 운에 가까웠던 것 같습니다.

하지만 사람은 수익이 날 때는 자신이 운이 좋다고 생각하지 않습니다.

분석을 잘했다고 생각합니다.

5월의 저는 아직 금융에 새로운 가능성이 있다고 믿고 있었습니다.

그리고 회사 프로젝트 역시 제가 맡은 영역만 잘 마무리하면 된다고 생각했습니다.

두 가지 생각 모두 6월에 조금 달라지게 됩니다.

6월

통합을 시작하자 평화가 끝났습니다

6월에는 통합 테스트를 준비하며 그동안 각자 개발한 영역을 하나의 흐름으로 연결하기 시작했습니다.

5월까지는 개별 기능들이 각자의 환경에서 잘 동작하고 있었습니다. 그래서 마지막에 연결만 하면 자연스럽게 하나의 제품이 될 것이라고 생각했습니다.

하지만 실제로 연결하기 시작하자 이전에는 보이지 않던 문제들이 하나씩 나타났습니다.

한쪽에서 변경한 정보가 다른 영역에는 예상한 시점에 반영되지 않거나, 같은 상태를 서로 다르게 해석하는 경우가 있었습니다.

각 기능은 분명 정상적으로 동작했습니다.

다만 함께 동작하는 방식은 충분히 정리되지 않은 상태였습니다.

개별 기능의 성공과 전체 제품의 성공은 달랐습니다.

한 영역에서 요청을 정상적으로 처리했다고 해도, 최종 결과가 다른 영역까지 이어지지 않으면 사용자에게는 실패였습니다. 반대로 내부적으로는 처리가 끝났지만 화면에 적절한 상태가 표시되지 않으면 사용자는 아무 일도 일어나지 않았다고 느낄 수 있었습니다.

통합 테스트는 이미 만든 기능이 잘 동작하는지 확인하는 과정이라고 생각했습니다.

실제로는 각자가 만든 기능이 같은 세계관 안에 존재하는지 확인하는 과정에 가까웠습니다.

그리고 생각보다 세계관이 잘 맞지 않았습니다.

처음에는 데이터 연결 몇 군데와 화면 일부를 수정하면 해결될 것이라고 생각했습니다.

그런데 문제를 하나씩 따라가다 보니 단순한 화면 문제가 아니었습니다.

화면이 복잡하게 느껴지는 이유는 디자인이 복잡해서가 아니라, 제품의 흐름과 각 영역의 관계가 화면에 충분히 정리되지 않았기 때문이었습니다.

결국 관리 영역의 화면과 구조도 다시 살펴봐야 했습니다.

원래는 서버 개발자분이 담당하고 있던 부분이었지만, 통합 과정에서 사용자 흐름과 화면 전반을 다시 정리할 필요가 생겼습니다.

그렇게 관리 페이지가 제게 돌아왔습니다.

제가 맡겼던 것은 아니었지만, 어쨌든 돌아왔습니다.

처음에는 기존 화면의 배치와 문구를 조금 수정하면 될 줄 알았습니다.

그렇지 않았습니다.

화면을 바꾸려면 사용자가 어떤 순서로 서비스를 이용해야 하는지부터 다시 확인해야 했고, 그 흐름을 정리하려면 서버와 다른 영역이 어떤 상태를 공유하는지도 알아야 했습니다.

관리 화면 하나를 수정하려고 시작했는데 다른 영역의 동작까지 다시 확인하고 있었습니다.

처음 열었던 파일과 전혀 다른 위치에서 원인을 발견하는 일도 많았습니다.

화면에서 이상한 점을 발견해 따라가 보면 데이터 흐름의 문제였고, 데이터 흐름을 확인하다 보면 처음 정한 운영 기준이 모호한 경우도 있었습니다.

프론트엔드의 문제처럼 보였지만 프론트엔드만 수정해서는 해결되지 않았습니다.

이때부터 제가 담당하는 범위도 빠르게 넓어졌습니다.

기존 개발을 진행하면서 관리 화면의 구조를 다시 정리했고, 외부에서 전달받은 결과물도 확인했습니다. 통합 테스트를 준비하고, 고객에게 전달할 문서와 매뉴얼도 함께 작성했습니다.

개발하다가 문서를 쓰고, 문서를 작성하다가 화면을 수정하고, 화면을 수정하다가 다시 로그를 확인했습니다.

오전에는 개발자였고, 오후에는 기획을 정리했으며, 저녁에는 테스트 담당자가 되어 있었습니다.

다양한 직무를 경험할 수 있었습니다.

물론 체험을 신청한 적은 없습니다.

기능을 구현하는 것과 사용자가 실제로 사용할 수 있도록 만드는 것이 다르다는 점도 다시 느꼈습니다.

개발자는 이미 제품 구조를 알고 있기 때문에 짧은 단어나 버튼만 봐도 의미를 이해합니다. 하지만 처음 접하는 사람에게는 현재 상태와 다음 행동이 명확하지 않을 수 있습니다.

그래서 단순히 화면에 상태를 보여주는 것에서 끝내지 않고, 처음 사용하는 사람도 전체 흐름을 이해할 수 있도록 화면 순서와 안내 문구를 다시 살펴봤습니다.

이 시기에는 프론트엔드 개발자가 단순히 화면을 그리는 사람이 아니라, 여러 시스템에 흩어진 정보를 사용자가 이해할 수 있는 언어로 번역하는 사람이라는 생각을 많이 했습니다.

서버와 여러 영역의 상태를 하나의 화면으로 정리하고, 개발팀 내부에서만 이해하던 흐름을 사용자가 따라갈 수 있는 경험으로 만드는 것도 프론트엔드의 역할이었습니다.

금융 천재의 꿈도 6월에 끝났습니다

업무가 본격적으로 바빠진 것과 비슷한 시기에 주식 수익도 줄어들기 시작했습니다.

4월과 5월에는 수익이 조금 생기면서 제가 기업 분석에 재능이 있는 줄 알았습니다.

6월에는 아니었다는 것을 알게 됐습니다..

뭐,, 유럽여행 다녀왔다 친거죠

개발에서는 문제가 발생하면 로그를 확인할 수 있습니다.

어떤 함수에서 오류가 발생했는지, 어떤 값이 예상과 달랐는지 확인하고 수정할 수 있습니다.

주식에는 로그가 없었습니다.

가격이 내려가도 오류 메시지가 나타나지 않았고, 새로고침을 해도 원래 값으로 돌아오지 않았습니다.

이미 체결된 주문에는 Ctrl+Z도 없었습니다.

그제야 개발이 생각보다 친절한 분야라는 것을 알게 됐습니다.

적어도 코드는 제가 틀렸다는 사실을 명확하게 알려줍니다. 시장은 별다른 설명 없이 제 돈을 가져갔습니다.

그렇게 짧았던 금융 천재의 꿈은 끝났고, 저는 다시 개발에 집중하게 됐습니다.

개발에 대한 뜨거운 열정이 저를 돌아오게 한 것은 아니었습니다.

손실이었습니다.

그래도 돌아왔으니 됐습니다.

주식 공부를 완전히 그만둔 것은 아니지만, 적어도 개발 공부보다 더 열심히 하지는 않기로 했습니다.

시장이 이미 충분한 수업료를 받아갔기 때문입니다.

새 기술이 나왔는데 저장만 해뒀습니다

6월에는 Claude 쪽에서 fable이라는 새로운 기술도 공개됐습니다.

새로운 기술이나 도구가 등장하면 일단 사용해보고, 기존 방식과 어떤 차이가 있는지 확인하는 것을 좋아합니다. 평소 같았으면 관련 자료를 찾아보고 작은 예제라도 만들어봤을 것 같습니다.

이번에도 소개를 보자마자 흥미가 생겼습니다.

관련 내용을 찾아봤고, 나중에 사용해보려고 저장도 해뒀습니다.

그리고 저장한 것으로 끝났습니다.

새로운 기술이 나왔는데 직접 실행해보지도 못할 정도로 바빴습니다.

다른 사람들이 먼저 사용해본 결과를 보면서 저도 나중에 써봐야겠다고 생각했습니다. 하지만 통합 테스트 준비와 기존 개발, 화면 수정, 문서 작업이 계속 이어지면서 그 ‘나중’은 계속 뒤로 밀렸습니다.

배우고 싶은 것이 없어서 공부하지 않은 것은 아니었습니다.

새로운 것을 시작하기 전에 이미 벌여놓은 일을 끝낼 시간이 필요했습니다.

6월은 새로운 기술을 많이 배운 달이라기보다, 새로운 기술을 살펴볼 여유도 없이 현재의 제품을 완성하는 데 집중한 달에 가까웠습니다.

fable은 여유가 생기면 제대로 사용해보고 싶습니다.

그 여유가 언제 생길지는 아직 모르겠습니다.

예상하지 못한 연락도 받았습니다

정신없이 일하던 중 벨로그를 통해 예상하지 못한 연락도 받았습니다.

작성한 글을 보고 서비스 후기를 작성해달라는 제안이 왔고, 별도로 함께 프로젝트를 진행해보자는 연락도 받았습니다.

처음에는 조금 신기했습니다.

벨로그는 제가 해결한 방법을 다시 잊지 않기 위해 시작했습니다. 며칠 동안 어렵게 해결한 문제도 시간이 지나면 방법을 잊어버렸고, 몇 달 뒤 같은 문제를 만났을 때 다시 처음부터 찾아보는 일이 반복됐기 때문입니다.

미래의 저를 위해 남긴 메모에 가까웠습니다.

그런데 제가 작성한 글과 프로젝트를 보고 누군가 제 의견을 듣고 싶어 하거나 함께 무언가를 만들어보고 싶다고 연락해준다는 것이 감사했습니다.

제안받은 서비스도 충분히 사용해본 뒤 개발자의 시선에서 솔직하게 리뷰해보고 싶었습니다. 프로젝트 제안 역시 어떤 것을 만들려는지 자세히 이야기해보고 싶은 마음이 있었습니다.

하지만 당시에는 새로운 일을 시작할 수 있을 만큼 시간과 체력이 남아 있지 않았습니다.

서비스를 잠깐 사용한 뒤 형식적인 후기를 작성하고 싶지 않았고, 외부 프로젝트를 무리해서 시작했다가 회사 일과 새로운 프로젝트 양쪽 모두 제대로 마무리하지 못할 것 같았습니다.

결국 두 제안 모두 참여하지 못했습니다.

좋은 기회를 놓친 것 같아 아쉬웠지만, 제가 남긴 기록이 누군가에게 닿고 있다는 사실은 다시 벨로그를 꾸준히 작성해야겠다는 동기가 됐습니다.

회사에서 제 벨로그를 알고 있다는 사실을 알게 된 뒤 한동안 글을 쓰는 것이 조심스러웠습니다. 민감한 내용이 드러나지 않는지, 회사에 대한 불만처럼 읽히지는 않는지 계속 신경 쓰다 보니 기록 자체를 미루기도 했습니다.

하지만 기록하지 않으면 몇 달 동안 고민했던 일도 결국 “그때 뭔가 어려웠다”는 한 문장으로만 남았습니다.

처음에는 어떤 방식으로 접근했고, 왜 잘되지 않았으며, 결국 어떤 기준으로 구조를 변경했는지를 남겨야 경험도 제대로 쌓인다는 생각이 들었습니다.

앞으로는 내부 정보는 제외하면서도 제가 어떤 문제를 만났고 어떤 판단을 내렸는지는 계속 기록해보려고 합니다.

완성된 결과만 보여주는 글보다, 실패했던 접근과 수정한 이유까지 함께 보여주는 글을 쓰고 싶습니다.

상반기를 돌아보며

2026년 상반기에는 새로운 프론트엔드 라이브러리보다 하나의 제품이 실제 사용자에게 전달되기 위해 필요한 것들을 더 많이 배웠습니다.

화면이 잘 동작하는 것은 끝이 아니었습니다.

화면에서 보낸 요청이 서버에 저장되어야 했고, 처리 결과는 다시 에이전트와 엔진에 적용되어야 했습니다. 그 상태가 사용자 화면에도 정확히 표시되어야 했습니다.

이 중 하나라도 실패하면 사용자는 전체 기능이 실패했다고 느낍니다.

이전에는 사용자 경험을 주로 화면 안에서 생각했습니다.

이제는 설치 파일을 받고 프로그램을 실행하는 순간부터, 연결이 끊겼을 때 복구되는 과정과 관리자가 승인하는 순서까지 모두 사용자 경험이라고 생각합니다.

상반기에는 이런 복잡한 시스템을 이해할 수 있는 형태로 번역하는 일을 많이 했습니다.

엔진의 상태를 문구로 바꾸고, 서버의 권한 구조를 화면으로 옮겼습니다. 운영 정책을 관리자 페이지의 순서로 만들고, 내부 아이디어를 외주 개발자가 이해할 수 있는 문서로 정리했습니다.

처음에는 개발과 조금 떨어진 일이라고 생각했지만, 결국 제품을 완성하기 위해 모두 필요한 과정이었습니다.

조금 솔직한 상반기 평가

상반기 내내 성실하게 공부한 것은 아닙니다.

개발 공부가 느슨해진 시기도 있었고, 주식으로 잠깐 돈을 벌고 새로운 재능을 발견한 줄 착각하기도 했습니다.

회사에 벨로그를 들킨 뒤 글쓰기가 조심스러워졌고, 좋은 제안을 받았지만 여유가 없어 놓친 기회도 있었습니다.

그래도 완전히 멈추지는 않았습니다.

익숙하지 않은 엔진 통신을 공부했고, 제품 구조를 다시 설계했습니다. 고객사의 환경을 확인하고 외부 개발자와 협업하기 위한 문서를 만들었습니다.

관리자 페이지와 에이전트, 서버, 엔진을 하나의 흐름으로 연결하며 문제를 바라보는 범위도 넓어졌습니다.

예전에는 화면에 문제가 생기면 컴포넌트와 상태부터 확인했습니다.

이제는 서버 데이터, 엔진 연결, 사용자 권한, 운영 순서까지 함께 확인합니다.

알아야 할 것이 늘어난 만큼 오히려 더 조심스러워졌습니다.

예전에는 모르는 것이 적어서 자신감이 있었고, 지금은 고려해야 할 것이 많다는 사실을 알아서 신중해졌습니다.

이것도 성장이라고 생각합니다.

이 시기에는 몇몇 회사에 지원서를 넣으며 현재 제 상태도 함께 점검했습니다.

저는 도태되고 있다는 감각을 가장 싫어합니다.

한 환경에서 오래 일하면 제가 실제로 성장한 것인지, 단순히 현재 업무에 익숙해진 것인지 구분하기 어려울 때가 있습니다.

지원서를 작성하면서 그동안 했던 일을 다시 정리했습니다. 어떤 기술을 사용했는지 나열하는 것보다, 왜 구조를 변경했고 어떤 문제를 해결했으며 그 과정에서 제가 담당한 범위가 어디까지였는지를 설명해야 했습니다.

아직 지원한 곳이 아주 많지는 않았지만 서류 합격률은 약 60~70% 정도였습니다.

이 수치가 제 실력을 완전히 증명한다고 생각하지는 않습니다. 회사마다 필요한 경험이 다르고, 채용 시기와 지원자 구성에 따라서도 결과가 달라지기 때문입니다.

그래도 지금까지 쌓아온 경험이 외부에서도 완전히 의미 없는 것은 아니라는 작은 확인은 됐습니다.

아직은 잘 살아가고 있는 것 같았습니다.

그래서 하반기에는

상반기가 끝났다고 일이 잠잠해지지는 않았습니다.

7월에는 해커톤 준비와 회사 일정이 겹쳤고, 여기에 주말 출근과 야근까지 이어졌습니다. 상반기 회고를 쓰려고 몇 번이나 메모장을 열었지만, 글을 쓰기 전에 당장 처리해야 할 일이 계속 생겼습니다.

퇴근 후에는 해커톤 지원서를 다듬고, 프로젝트 아이디어와 역할을 정리했습니다. 회사에서는 통합 테스트와 납품 준비가 본격적으로 시작됐고, 평일에 끝내지 못한 일은 자연스럽게 주말까지 따라왔습니다.

7월은 개발도, 해커톤 준비도, 체력 관리도 모두 놓치고 싶지 않아 욕심을 냈던 달이었습니다. 결과적으로 무엇 하나 가볍게 지나가지는 않았습니다.

상반기는 제품의 구조와 운영을 배우는 시간이었다면, 7월은 그동안 준비한 것들을 실제 일정 안에서 버텨내는 시간이었던 것 같습니다.

자세한 이야기는 하반기 회고에서 풀어보려고 합니다. 아직 8월이 되지는 않았지만, 그때는 조금 더 긍정적인 이야기를 적을 수 있으면 좋겠습니다.

“7월에는 정말 힘들었지만, 그래도 결국 잘 마무리했다.”

다음 회고에서는 이렇게 쓸 수 있기를 기다려봅니다.

2026년 상반기는 프론트엔드 개발자로서 제가 바라보는 범위가 가장 많이 넓어진 시간이었습니다. 화면을 만드는 것에서 시작해 화면 뒤의 서버와 엔진을 이해하게 됐고, 제품이 설치되고 운영되는 과정까지 고민하게 됐습니다.

제품을 완성한다는 것은 기능을 모두 만드는 것이 아니라, 각 기능이 사용자에게 하나의 경험으로 이어지게 만드는 일이다.

그리고 개발자는 코드를 작성하는 사람이기도 하지만, 복잡한 문제 사이에서 기준을 만들고 끝까지 연결하는 사람이기도 합니다.

지금도 일정과 오류, 예상하지 못한 요구사항 사이에서 버티고 있는 개발자분들이 많을 것 같습니다. 개발하다 보면 분명 어제까지 잘되던 기능이 갑자기 안 되고, 거의 끝났다고 생각한 순간 새로운 요구사항이 들어오기도 합니다.

왜 그런 일이 계속 생기는지는 저도 알고 싶지 않습니다.

그래도 결국 하나씩 원인을 찾고, 다시 연결하고, 어떻게든 다음 단계로 넘어가게 되는 것이 개발자의 일인 것 같습니다.

조금 지쳤더라도 우리가 못하고 있어서 힘든 것만은 아닐 겁니다. 책임지는 범위가 넓어지고, 해결해야 하는 문제가 어려워졌기 때문에 힘든 순간도 분명 있을 테니까요.

이상으로 많이 늦은 2026년 상반기 회고를 마치겠습니다.

8월에는 조금 더 여유롭고 긍정적인 회고를 쓸 수 있기를 바라며,

오늘도 각자의 자리에서 버티고 있는 지친 개발자분들, 모두 파이팅입니다.

버튼을 클릭해보고, 검색어를 입력해보고, 목록이 잘 나오는지 보고, 상태가 바뀌는지도 직접 확인합니다.

처음에는 이 방식이 제일 빠르게 느껴집니다. 눈으로 바로 확인할 수 있고, 문제가 있으면 바로 고치면 되니까요.

그런데 기능이 많아지고 화면이 늘어나면서 슬슬 이런 생각이 들기 시작했습니다.

“이거 수정했는데 다른 화면은 안 깨졌을까?” “버튼 클릭했을 때 API 호출이 제대로 나가고 있을까?” “실패 상황에서도 화면이 멈추지는 않을까?” “매번 직접 다 눌러보는 게 맞을까?”

처음에는 제가 사람이 테스트 로봇이 된 줄 알았습니다. 수정하고, 실행하고, 클릭하고, 검색하고, 다시 수정하고, 또 클릭하고.

버튼 하나 고쳤을 뿐인데 확인해야 할 화면이 줄줄이 따라오는 순간, 머릿속에 자연스럽게 한 문장이 떠올랐습니다.

“네...? 이걸 다 수동 테스트하라구요...? 제가요...?”

그래서 이번에는 프론트엔드 단위 테스트 코드를 작성하면서, 어떤 테스트 도구를 사용할지 먼저 비교해보고 프로젝트에 맞는 도구를 선택해보았습니다.

프론트엔드 단위 테스트 도구에는 어떤 것들이 있을까?

프론트엔드에서 단위 테스트를 작성할 때 자주 언급되는 도구는 크게 다음과 같습니다.

- Jest
- Vitest
- Mocha
- Jasmine
- Testing Library

여기서 Jest, Vitest, Mocha, Jasmine은 테스트를 실행하고 검증하는 테스트 프레임워크에 가깝습니다.

반면 Testing Library는 테스트 실행 프레임워크라기보다는, React 컴포넌트를 사용자 관점에서 테스트할 수 있도록 도와주는 라이브러리에 가깝습니다.

즉, 역할을 나누면 이렇게 볼 수 있습니다.

테스트 실행/검증 도구:
Jest, Vitest, Mocha, Jasmine

화면 테스트 보조 도구:
Testing Library

테스트 도구를 고를 때는 단순히 “유명한가?”보다 현재 프로젝트 환경과 잘 맞는지를 기준으로 보는 것이 중요하다고 느꼈습니다.

Jest

Jest는 프론트엔드 테스트에서 가장 많이 알려진 테스트 프레임워크 중 하나입니다.

React 프로젝트에서도 오래전부터 많이 사용되었고, 자료가 많고 안정적인 편입니다.

Jest는 테스트 실행, 단언문, Mock 기능, 스냅샷 테스트 등을 한 번에 제공합니다.

describe('계산 함수 테스트', () => {
  it('두 숫자를 더한다', () => {
    expect(1 + 2).toBe(3);
  });
});

Jest의 가장 큰 장점은 레퍼런스가 많다는 점입니다.

이미 많은 프로젝트에서 사용되고 있기 때문에 문제가 생겼을 때 검색으로 해결하기 좋고, 여러 환경에서 검증된 도구라는 안정감이 있습니다.

다만 Vite 기반 프로젝트에서는 설정이 다소 번거로울 수 있다고 느꼈습니다. TypeScript, TSX, alias 설정 등을 맞추다 보면 추가 설정이 필요할 수 있기 때문입니다.

Jest는 이런 경우에 잘 맞는다고 생각했습니다.

- 기존 프로젝트에서 이미 Jest를 사용하고 있는 경우
- 레퍼런스가 많은 도구를 선호하는 경우
- 안정적으로 검증된 테스트 환경이 필요한 경우
- Vite가 아닌 기존 React 환경에서 테스트를 구성하는 경우

Vitest

Vitest는 Vite 생태계에 맞춰 만들어진 테스트 프레임워크입니다.

Vite 기반 프로젝트에서는 설정 흐름이 자연스럽고, TypeScript와 TSX 테스트도 비교적 편하게 작성할 수 있습니다.

문법도 Jest와 매우 비슷합니다.

describe('계산 함수 테스트', () => {
  it('두 숫자를 더한다', () => {
    expect(1 + 2).toBe(3);
  });
});

Mock도 vi.fn(), vi.mock() 형태로 사용할 수 있습니다.

const mockFetchList = vi.fn();

vi.mock('@/api/sampleApi', () => ({
  fetchList: mockFetchList,
}));

Vitest의 가장 큰 장점은 Vite 프로젝트와 잘 맞는다는 점입니다.

Vite 설정, TypeScript, path alias, 빠른 실행 속도 면에서 장점이 있고, Jest와 문법이 비슷해서 테스트 코드를 처음 작성할 때도 진입 장벽이 낮았습니다.

제가 느낀 Vitest의 장점은 다음과 같습니다.

- Vite 프로젝트와 설정이 잘 맞는다
- TypeScript/TSX 테스트 작성이 편하다
- Jest와 문법이 비슷해서 익히기 쉽다
- 실행 속도가 빠른 편이다
- Mock 기능을 사용하기 쉽다

그래서 Vite + React + TypeScript 기반 프로젝트라면 Jest보다 Vitest가 더 자연스럽다고 판단했습니다.

Mocha

Mocha는 오래된 JavaScript 테스트 프레임워크 중 하나입니다.

Jest나 Vitest처럼 필요한 기능이 한 번에 포함되어 있다기보다는, 필요한 라이브러리를 조합해서 사용하는 방식에 가깝습니다.

예를 들어 단언문은 Chai, Mock이나 Spy는 Sinon을 함께 사용하는 경우가 많습니다.

Mocha는 유연성이 높다는 장점이 있습니다.

하지만 처음 테스트 환경을 구성하는 입장에서는 직접 조합해야 할 것이 많아서 조금 복잡하게 느껴질 수 있습니다.

Mocha는 이런 경우에 어울린다고 생각했습니다.

- 테스트 환경을 직접 세밀하게 구성하고 싶은 경우
- 특정 assertion/mock 라이브러리를 조합해서 쓰고 싶은 경우
- 기존 프로젝트에서 이미 Mocha 기반 테스트 환경을 사용하고 있는 경우

저는 이번 프로젝트에서는 빠르게 단위 테스트 환경을 구성하고 싶었기 때문에 Mocha보다는 Vitest가 더 적합하다고 판단했습니다.

Jasmine

Jasmine은 오래된 JavaScript 테스트 프레임워크입니다.

Jest와 비슷하게 describe, it, expect 같은 구조를 사용합니다.

describe('계산 함수 테스트', () => {
  it('두 숫자를 더한다', () => {
    expect(1 + 2).toBe(3);
  });
});

Jasmine은 자체적으로 assertion, spy 기능을 제공하는 편이라 별도 라이브러리 없이도 테스트를 작성할 수 있습니다.

다만 최근 React + Vite 기반 프론트엔드 프로젝트에서는 Jest나 Vitest에 비해 선택 빈도가 낮다고 느꼈습니다.

기존 Angular 프로젝트나 오래된 테스트 환경에서는 볼 수 있지만, 새로 구성하는 React 프로젝트라면 Vitest나 Jest를 먼저 고려하는 것이 더 자연스럽다고 생각했습니다.

Testing Library

Testing Library는 테스트 프레임워크라기보다는 React 컴포넌트를 테스트하기 위한 도구입니다.

Vitest나 Jest와 함께 사용합니다.

예를 들어 Vitest가 테스트를 실행하고 expect로 결과를 검증한다면, Testing Library는 컴포넌트를 렌더링하고 화면 요소를 찾고 사용자 동작을 재현하는 역할을 합니다.

render(<SampleButton onClick={handleClick} />);

fireEvent.click(screen.getByText('저장'));

expect(handleClick).toHaveBeenCalled();

Testing Library의 핵심은 사용자 관점의 테스트입니다.

내부 함수명이나 컴포넌트의 구현 방식보다, 실제 화면에 보이는 텍스트, 버튼, 입력창을 기준으로 테스트합니다.

예를 들어 “저장 버튼을 클릭하면 저장 요청이 호출된다”처럼 작성할 수 있습니다.

이 방식이 좋은 이유는 내부 구현이 조금 바뀌어도 사용자가 보는 화면과 동작이 같다면 테스트가 크게 흔들리지 않기 때문입니다.

도구별 특징 정리

각 도구의 특징을 간단히 정리하면 다음과 같습니다.

제가 이해한 기준으로는 이렇게 정리할 수 있었습니다.

Vite + React + TypeScript 신규 프로젝트
→ Vitest + Testing Library 조합이 자연스러움

기존 React 프로젝트 또는 레퍼런스 많은 환경
→ Jest + Testing Library 조합이 안정적

테스트 환경을 직접 조합하고 싶은 경우
→ Mocha + Chai + Sinon 조합 가능

기존 Angular 또는 오래된 JS 테스트 환경
→ Jasmine을 사용하는 경우도 있음

그래서 저는 왜 Vitest를 선택했나

제가 Vitest를 선택한 가장 큰 이유는 프로젝트 환경 때문입니다.

현재 프로젝트가 Vite + React + TypeScript 기반이었기 때문에, 같은 생태계에 있는 Vitest가 가장 자연스럽다고 판단했습니다.

Jest도 충분히 좋은 도구이지만, Vite 프로젝트에서 Jest를 사용하려면 추가 설정을 맞춰야 할 수 있습니다.

반면 Vitest는 Vite 설정과 잘 맞고, TypeScript/TSX 테스트 작성도 비교적 수월했습니다.

또한 Jest와 문법이 비슷해서 테스트 코드 작성 방식이 낯설지 않았습니다.

describe('목록 페이지', () => {
  it('진입 시 목록을 조회한다', async () => {
    render(<SampleListPage />);

    await waitFor(() => {
      expect(mockFetchList).toHaveBeenCalled();
    });
  });
});

즉, 제가 Vitest를 선택한 기준은 다음과 같습니다.

1. 프로젝트가 Vite 기반이었다
2. React + TypeScript 테스트를 작성해야 했다
3. Jest와 비슷한 문법이라 학습 부담이 적었다
4. 실행 속도가 빠른 편이라 반복 테스트에 적합했다
5. Mock을 사용해 API와 외부 의존성을 분리하기 쉬웠다

테스트 도구를 고르는 과정에서 가장 크게 느낀 점은 “좋은 도구”보다 “현재 프로젝트에 덜 어색한 도구”가 중요하다는 점이었습니다.

아무리 유명한 도구라도 프로젝트 설정과 계속 충돌하면 테스트 코드를 작성하기 전에 설정에서 지칠 수 있기 때문입니다.

화면 테스트에는 왜 Testing Library를 같이 사용했나

Vitest만으로도 함수 단위 테스트는 작성할 수 있습니다.

하지만 React 컴포넌트나 페이지를 테스트하려면 화면을 렌더링하고, 버튼 클릭이나 입력 같은 사용자 동작을 재현해야 합니다.

그래서 @testing-library/react를 함께 사용했습니다.

render(<SampleListPage />);

fireEvent.change(screen.getByPlaceholderText('검색어를 입력하세요'), {
  target: { value: '검색어' },
});

Testing Library를 사용하면 테스트를 실제 사용자 흐름에 가깝게 작성할 수 있습니다.

예를 들어 다음과 같은 테스트가 가능합니다.

- 화면에 특정 문구가 보이는지
- 버튼을 클릭했을 때 함수가 호출되는지
- 입력창에 값을 입력했을 때 검색 요청이 발생하는지
- 상태 변경 스위치를 눌렀을 때 API가 호출되는지
- API 실패 시에도 화면 흐름이 유지되는지

저는 단순히 내부 함수가 호출됐는지만 보는 테스트보다, 사용자가 실제로 화면에서 하는 행동을 기준으로 테스트하는 방식이 더 적합하다고 느꼈습니다.

제가 작성한 테스트 코드 구조

테스트 파일은 실제 기능 구조와 비슷하게 나눴습니다.

회사 내부 구조가 드러나지 않도록 예시로 표현하면 다음과 같습니다.

tests/
└─ unit/
   ├─ pages/
   │  └─ 화면 단위 테스트
   ├─ components/
   │  └─ 공통 컴포넌트 테스트
   ├─ utils/
   │  └─ 유틸 함수 테스트
   └─ modules/
      └─ 주요 로직 테스트

이렇게 나누면 테스트 파일을 찾기 쉽습니다.

페이지 관련 테스트는 pages, 공통 컴포넌트 테스트는 components, 순수 함수 테스트는 utils, 특정 기능 로직 테스트는 modules처럼 구분할 수 있습니다.

테스트 파일 위치가 정리되어 있으면 나중에 기능을 수정할 때 관련 테스트를 함께 찾기 편했습니다.

테스트 파일 위쪽에는 설명을 적었습니다

각 테스트 파일 위에는 이 테스트가 무엇을 검증하는지 간단히 적었습니다.

/**
 * 테스트 대상
 *
 * 검증 항목:
 * 1. 최초 진입 시 목록을 조회한다
 * 2. 검색 기능이 동작한다
 * 3. 상태 변경 요청을 호출한다
 * 4. 실패 상황에서도 목록을 다시 조회한다
 */

이 설명은 테스트 코드의 목차 역할을 합니다.

테스트 코드가 많아지면 어떤 테스트가 어떤 기능을 보장하는지 한눈에 보기 어려워집니다.

그래서 상단에 검증 항목을 적어두면, 나중에 테스트를 추가하거나 수정할 때 기준을 잡기 쉬웠습니다.

테스트 코드가 단순히 실행되는 코드가 아니라, 해당 기능이 어떤 동작을 보장해야 하는지 보여주는 문서처럼 느껴졌습니다.

기본 테스트 구조

제가 작성한 테스트는 대체로 다음 구조를 사용했습니다.

describe('목록 관리 페이지', () => {
  beforeEach(() => {
    vi.clearAllMocks();
  });

  it('진입 시 목록을 조회한다', async () => {
    render(<SampleListPage />);

    await waitFor(() => {
      expect(mockFetchList).toHaveBeenCalled();
    });
  });
});

각 코드의 역할은 다음과 같습니다.

이 구조를 반복해서 사용하니 테스트 파일의 형태가 어느 정도 통일됐습니다.

테스트마다 작성 방식이 다르면 읽기 어려운데, 구조를 맞춰두면 나중에 유지보수하기 훨씬 편했습니다.

API는 Mock으로 처리했습니다

테스트에서는 실제 API를 호출하지 않고 Mock으로 대체했습니다.

const mockFetchList = vi.fn();
const mockUpdateStatus = vi.fn();

vi.mock('@/api/sampleApi', () => ({
  fetchList: mockFetchList,
  updateStatus: mockUpdateStatus,
}));

이렇게 하면 외부 환경과 관계없이 원하는 상황을 만들 수 있습니다.

목록 조회 성공 상황은 이렇게 만들 수 있습니다.

mockFetchList.mockResolvedValue([
  {
    id: 1,
    name: 'Sample Item',
    enabled: true,
  },
]);

상태 변경 실패 상황은 이렇게 만들 수 있습니다.

mockUpdateStatus.mockRejectedValue(new Error('실패'));

Mock을 사용한 이유는 실제 서버나 외부 환경에 의존하지 않고, 화면 로직만 독립적으로 검증하기 위해서입니다.

성공 응답, 실패 응답, 빈 목록, 특정 상태값 등 다양한 상황을 직접 만들 수 있기 때문에 테스트 흐름을 통제하기 좋았습니다.

오히려 에러 케이스가 더 중요하다고 느꼈습니다

테스트 코드를 작성하면서 가장 신경 쓴 부분 중 하나는 실패 케이스였습니다.

처음에는 자연스럽게 성공 케이스부터 작성했습니다.

- 페이지에 진입하면 목록이 조회되는지
- 검색어를 입력하면 조회 함수가 호출되는지
- 버튼을 클릭하면 상태 변경 API가 호출되는지
- 응답이 성공하면 화면 흐름이 유지되는지

이런 테스트도 물론 중요합니다.

하지만 실제 서비스를 생각해보면 사용자가 문제를 겪는 순간은 대부분 성공 상황이 아니라 실패 상황입니다.

API 요청이 실패하거나, 서버 응답이 늦거나, 상태 변경이 정상 처리되지 않거나, 예상하지 못한 빈 데이터가 내려오는 경우가 있습니다.

개발할 때는 보통 정상 응답을 기준으로 화면을 확인하기 때문에, 실패 상황은 놓치기 쉽습니다.

성공 케이스는 개발자가 직접 확인하기 쉽습니다. 버튼을 누르고 “오 잘 된다” 하고 넘어갈 수 있습니다.

하지만 실패 케이스는 다릅니다.

서버를 일부러 실패시키기도 애매하고, 네트워크 오류를 매번 만들기도 어렵고, 특정 예외 응답을 재현하는 것도 번거롭습니다.

그래서 저는 성공 케이스보다 오히려 에러 케이스를 더 꼼꼼히 확인해야 한다고 느꼈습니다.

실패 케이스 테스트를 작성한 이유

실패 케이스 테스트의 목적은 단순히 오류를 발생시키는 것이 아닙니다.

중요한 건 오류가 발생했을 때 화면이 그대로 멈추거나, 잘못된 상태로 남지 않는지 확인하는 것입니다.

예를 들어 사용자가 상태 변경 버튼을 클릭했는데 API가 실패할 수 있습니다.

이때 화면이 이전 상태와 다르게 표시되거나, 목록이 갱신되지 않거나, 사용자가 현재 상태를 오해하게 되면 문제가 될 수 있습니다.

그래서 실패 상황에서는 다음 흐름을 확인했습니다.

사용자가 버튼 클릭
→ 상태 변경 API 호출
→ API 실패
→ 오류 처리
→ 최신 목록 다시 조회
→ 화면 상태 복구

즉, 실패했을 때도 화면이 다시 안정적인 상태로 돌아오는지를 검증했습니다.

실패 상황은 Mock으로 직접 만들었습니다

실제 테스트에서는 API 실패 상황을 Mock으로 만들었습니다.

mockUpdateStatus.mockRejectedValue(new Error('실패'));

이렇게 하면 실제 서버를 조작하지 않아도, 상태 변경 요청이 실패하는 상황을 테스트 안에서 만들 수 있습니다.

그리고 실패 이후 목록 조회가 다시 실행되는지 확인했습니다.

it('상태 변경 실패 시 목록을 다시 조회한다', async () => {
  mockFetchList.mockResolvedValue([
    {
      id: 1,
      name: 'Sample Item',
      enabled: true,
    },
  ]);

  mockUpdateStatus.mockRejectedValue(new Error('실패'));

  render(<SampleListPage />);

  const toggle = await screen.findByRole('checkbox');

  fireEvent.click(toggle);

  await waitFor(() => {
    expect(mockFetchList).toHaveBeenCalledTimes(2);
  });
});

여기서 mockUpdateStatus는 상태 변경 요청을 의미하고, mockFetchList는 목록 조회 요청을 의미합니다.

테스트의 핵심은 상태 변경 API가 실패했을 때도 목록 조회가 다시 실행되는지 확인하는 것입니다.

최초 진입 시 목록 조회 1회
상태 변경 실패 후 목록 재조회 1회
총 2회 호출

그래서 mockFetchList가 2번 호출되었는지 검증했습니다.

이 테스트는 “에러가 나면 안 된다”가 아니라, “에러가 나도 화면이 안전하게 버텨야 한다”에 가깝습니다.

에러 로그가 보여도 테스트가 통과할 수 있습니다

실패 케이스 테스트를 작성하면 테스트 실행 중 콘솔에 에러 로그가 보일 수 있습니다.

처음에는 이 로그를 보고 “테스트가 잘못된 건가?”라고 생각할 수 있습니다.

하지만 의도적으로 실패 상황을 만든 테스트라면, 에러 로그가 출력되는 것 자체는 이상한 일이 아닙니다.

중요한 건 에러가 발생한 뒤에 프로그램이 기대한 흐름대로 복구되는지입니다.

에러가 발생한다
→ catch에서 처리된다
→ 필요한 후속 동작이 실행된다
→ 테스트가 통과한다

즉, 실패 케이스 테스트에서는 “에러가 안 나는지”보다 “에러가 났을 때도 안전하게 처리되는지”를 확인했습니다.

이 부분이 테스트를 작성하면서 꽤 중요하게 느껴졌습니다.

사용자 입장에서는 내부적으로 어떤 에러가 났는지보다, 화면이 이상한 상태로 남지 않는지가 더 중요하기 때문입니다.

성공 케이스보다 실패 케이스가 더 값질 때도 있습니다

성공 케이스는 개발 중에 직접 확인하기 쉽습니다.

화면을 열고 버튼을 눌러보면 정상 동작 여부를 어느 정도 확인할 수 있습니다.

하지만 실패 케이스는 매번 직접 확인하기 어렵습니다.

서버 오류를 일부러 만들기도 어렵고, 네트워크 실패나 예외 응답을 매번 재현하기도 번거롭습니다.

그래서 실패 상황일수록 테스트 코드로 만들어두는 것이 더 의미 있다고 느꼈습니다.

성공 케이스:
직접 확인하기 비교적 쉬움

실패 케이스:
직접 재현하기 어렵고 놓치기 쉬움
그래서 테스트 코드로 고정해두는 가치가 큼

특히 사용자가 직접 조작하는 기능에서는 실패 처리 테스트가 더 중요하다고 생각했습니다.

사용자 입장에서는 요청이 성공했는지 실패했는지보다, 실패했을 때 화면이 이상한 상태로 남지 않는지가 더 중요하기 때문입니다.

제가 실패 케이스에서 확인한 것들

실패 케이스에서는 단순히 API가 실패하는지만 보지 않았습니다.

실패 이후 화면이 안정적으로 유지되는지를 중심으로 확인했습니다.

- API 실패 시 프로그램이 멈추지 않는지
- 실패 이후 필요한 후속 조회가 실행되는지
- 화면이 이전 상태와 불일치하지 않는지
- 사용자가 잘못된 상태로 오해하지 않도록 복구되는지
- catch 흐름이 실제로 동작하는지

이런 테스트를 작성해두면 나중에 리팩토링을 하거나 API 호출 구조를 바꿀 때도 안정성을 확인할 수 있습니다.

실패 처리는 평소에는 잘 보이지 않지만, 실제 운영 환경에서는 중요하게 드러나는 부분이라고 느꼈습니다.

네...? 이걸 다 수동 테스트하라구요..? 제가요?

테스트 코드를 작성하면서 가장 크게 체감한 부분은 속도였습니다.

기능을 하나 수정할 때마다 확인해야 할 게 생각보다 많았습니다.

화면 실행
→ 메뉴 이동
→ 목록 조회 확인
→ 검색어 입력
→ 버튼 클릭
→ 상태 변경 확인
→ 실패 상황 확인
→ 다른 케이스 반복

처음에는 당연히 직접 눌러보면서 확인했습니다.

그런데 확인해야 할 화면과 케이스가 늘어나니까 어느 순간 이런 생각이 들었습니다.

네...?
이걸 다 수동 테스트하라구요...?
제가요...?

버튼 하나 수정했을 뿐인데, 혹시 다른 기능이 깨졌을까 봐 관련 화면을 다시 들어가 보고, 검색도 해보고, 상태 변경도 눌러보고, 실패 상황도 생각해야 했습니다.

이쯤 되면 개발을 하는 건지, 클릭 노동을 하는 건지 살짝 헷갈리기 시작합니다.

물론 수동 테스트도 필요합니다. 실제 화면에서만 느껴지는 UI 흐름이나 사용성은 직접 확인해야 합니다.

하지만 매번 같은 동작을 반복해서 확인하는 건 너무 비효율적이었습니다.

그래서 반복적으로 확인해야 하는 흐름은 테스트 코드로 옮겼습니다.

수동 확인:
화면마다 직접 이동하고 클릭해야 함
시간이 오래 걸리고 누락 가능성이 있음

테스트 실행:
작성된 케이스를 한 번에 검증
약 50초 안에 주요 흐름 확인 가능

제가 작성한 테스트 기준으로는 수기로 하나씩 확인하면 훨씬 오래 걸릴 작업들이, 테스트 실행으로는 약 50초 안에 끝났습니다.

이때 테스트 자동화가 왜 필요한지 가장 크게 체감했습니다.

테스트 코드를 작성하는 데 처음에는 시간이 들어갑니다. 하지만 한 번 작성해두면 같은 검증을 반복할 때마다 시간을 아낄 수 있습니다.

특히 공통 로직을 수정하거나 리팩토링을 할 때 좋았습니다.

예전 같으면 수정 후에 괜히 불안해서 화면을 하나씩 다시 눌러봤을 텐데, 테스트를 실행하면 최소한 작성해둔 주요 흐름은 빠르게 확인할 수 있었습니다.

목록 조회가 여전히 되는지
검색 기능이 깨지지 않았는지
버튼 클릭 시 요청이 나가는지
실패 상황에서도 화면이 복구되는지

이런 것들을 매번 손으로 확인하지 않아도 된다는 점이 생각보다 크게 느껴졌습니다.

결국 테스트 코드는 단순히 버그를 잡기 위한 코드라기보다, 반복 확인 작업을 줄여주는 자동 점검표처럼 느껴졌습니다.

수동으로 계속 누르다 보면 사람은 지치고, 지치면 놓칩니다. 하지만 테스트는 지치지 않고 같은 흐름을 계속 확인해줍니다.

그게 제가 테스트 코드를 작성하면서 가장 만족했던 부분이었습니다.

테스트 이름은 요구사항처럼 작성했습니다

테스트 이름은 가능하면 코드 설명이 아니라 요구사항처럼 작성하려고 했습니다.

it('진입 시 목록을 조회한다', async () => {});
it('검색어를 입력하면 목록을 다시 조회한다', async () => {});
it('상태 변경 버튼을 클릭하면 변경 요청을 보낸다', async () => {});
it('상태 변경 실패 시 목록을 다시 조회한다', async () => {});

이렇게 작성하면 테스트 목록만 봐도 해당 화면이 어떤 동작을 보장해야 하는지 알 수 있습니다.

테스트 코드가 단순 검증 코드가 아니라, 기능 명세서처럼 읽히는 느낌이 들었습니다.

제가 테스트를 작성하면서 세운 기준

테스트 코드를 작성하면서 다음 기준을 지키려고 했습니다.

1. 한 테스트에서는 하나의 동작만 검증하기
2. 내부 구현보다 사용자 행동 기준으로 작성하기
3. 실제 외부 환경에 의존하지 않기
4. 성공 케이스와 실패 케이스를 함께 보기
5. 특히 실패 케이스는 복구 흐름까지 확인하기
6. 테스트 이름만 봐도 의도를 알 수 있게 작성하기

특히 “한 테스트에서 하나의 동작만 검증하기”가 중요했습니다.

하나의 테스트에 너무 많은 내용을 넣으면, 실패했을 때 어디서 문제가 발생했는지 찾기 어렵습니다.

그래서 목록 조회, 검색, 상태 변경, 실패 처리처럼 동작별로 테스트를 나눠서 작성했습니다.

테스트 코드를 작성하면서 느낀 점

테스트 코드를 처음 작성할 때는 솔직히 조금 번거롭게 느껴졌습니다.

화면에서 직접 한 번 눌러보면 끝날 것 같은데, 그걸 코드로 다시 작성해야 하니까요.

하지만 기능이 많아질수록 테스트 코드의 장점이 보였습니다.

특히 기존 기능을 수정할 때 심리적인 부담이 줄었습니다.

- 이 수정 때문에 목록 조회가 깨지지는 않았는지
- 검색 기능이 여전히 동작하는지
- 버튼 클릭 시 API 요청이 나가는지
- 실패 상황에서도 화면 흐름이 유지되는지

이런 부분을 테스트가 대신 확인해주기 때문입니다.

테스트가 모든 버그를 막아주는 것은 아니지만, 적어도 기존에 보장하던 동작이 깨졌는지 빠르게 확인할 수 있습니다.

그리고 테스트를 작성하면서 느낀 가장 큰 점은, 테스트가 단순히 “성공하는 기능을 확인하는 코드”는 아니라는 것입니다.

오히려 실패했을 때 화면이 어떻게 버티는지 확인하는 코드에 더 가까울 때도 있었습니다.

정리

프론트엔드 단위 테스트 도구에는 Jest, Vitest, Mocha, Jasmine 등이 있고, React 컴포넌트 테스트에는 Testing Library를 함께 사용할 수 있습니다.

그중에서 저는 Vite + React + TypeScript 프로젝트와 가장 잘 맞는 Vitest를 선택했습니다.

Vitest는 Vite 설정과 잘 맞고, TypeScript/TSX 테스트가 편하며, Jest와 문법이 비슷해서 진입 장벽이 낮았습니다.

또한 vi.fn(), vi.mock()을 통해 API나 외부 의존성을 Mock으로 분리하기 쉬웠습니다.

제가 작성한 테스트의 핵심은 다음과 같습니다.

- 화면 진입 시 필요한 데이터가 조회되는지
- 사용자의 클릭, 입력, 검색 동작이 정상적으로 처리되는지
- 상태 변경 같은 주요 기능이 의도한 요청으로 이어지는지
- API 실패 상황에서도 화면이 멈추지 않는지
- 실패 이후 필요한 복구 흐름이 실행되는지
- 외부 환경과 분리해서 화면 로직을 안정적으로 검증할 수 있는지

테스트 코드는 단순히 오류를 찾기 위한 코드만은 아니라고 느꼈습니다.

기능이 어떤 동작을 보장해야 하는지 기록하는 문서이기도 하고, 나중에 코드를 수정할 때 안심할 수 있게 해주는 안전장치이기도 했습니다.

특히 실패 케이스 테스트는 “오류가 발생하지 않는지”를 보는 것이 아니라, “오류가 발생해도 화면이 안전하게 버티는지”를 확인하는 테스트라고 생각했습니다.

그리고 수기로 하나씩 확인하면 오래 걸리는 주요 흐름도, 테스트 코드로 만들어두면 약 50초 안에 한 번에 점검할 수 있었습니다.

처음부터 모든 테스트를 완벽하게 작성할 필요는 없지만, 자주 수정되는 화면이나 중요한 사용자 흐름부터 하나씩 테스트를 추가해보는 것만으로도 유지보수에 꽤 도움이 된다고 느꼈습니다.

“새 알림이 오면 바로 화면에 보여주세요.”

“상태가 바뀌면 새로고침 없이 반영되게 해주세요.”

“채팅처럼 실시간으로 메시지가 오가야 해요.”

“AI 답변이 한 글자씩 출력되면 좋겠어요.”

처음에는 이런 요구사항을 들으면 자연스럽게 WebSocket이 떠오릅니다.

“실시간이면 WebSocket 아닌가?”

저도 처음에는 이렇게 생각했습니다.

그런데 공부해보니 실시간 통신이라고 해서 전부 WebSocket을 써야 하는 건 아니었습니다.

상황에 따라서는 SSE(Server-Sent Events)가 더 단순하고, 더 적절한 선택이 될 수 있습니다.

이번 글에서는 SSE와 WebSocket이 어떻게 다른지, 어떤 상황에서 어떤 방식을 선택하면 좋은지 정리해보겠습니다.

1. 실시간 통신이 필요한 이유

일반적인 웹 통신은 대부분 HTTP 요청과 응답 구조로 동작합니다.

클라이언트가 서버에 요청합니다.

데이터 주세요.

서버가 응답합니다.

여기 있습니다.

이 방식은 단순하고 안정적입니다.

하지만 서버의 데이터가 바뀌었을 때 클라이언트가 그 사실을 바로 알 수 없다는 문제가 있습니다.

예를 들어 승인 요청 목록 화면을 보고 있다고 가정해보겠습니다.

사용자는 현재 승인 목록을 보고 있습니다.

그런데 다른 사용자가 새로운 승인 요청을 등록했습니다.

서버에는 새로운 데이터가 생겼지만, 클라이언트 화면은 그대로입니다.

왜냐하면 클라이언트가 서버에 다시 요청하지 않았기 때문입니다.

이 문제를 해결하려면 클라이언트가 계속 서버에 물어보거나, 서버가 클라이언트에게 직접 알려줘야 합니다.

이때 자주 등장하는 방식이 다음 세 가지입니다.

2. 먼저 Polling부터 보면

Polling은 가장 단순한 방식입니다.

setInterval(() => {
fetch('/api/notifications');
},5000);

5초마다 서버에 물어봅니다.

새 알림 있어요?
새 알림 있어요?
새 알림 있어요?

구현은 쉽습니다.

하지만 약간 귀찮은 친구처럼 계속 물어보는 구조입니다.

문제는 알림이 없어도 계속 요청을 보낸다는 점입니다.

서버 입장에서는 이렇게 느낄 수도 있습니다.

없다니까...
아직 없다니까...
아직도 없다니까...

그리고 5초마다 요청한다면, 실제 데이터가 생겨도 최대 5초 늦게 화면에 반영될 수 있습니다.

그래서 실시간성이 더 필요하거나 불필요한 요청을 줄이고 싶다면 SSE나 WebSocket을 고려하게 됩니다.

3. SSE란?

SSE는 Server-Sent Events의 약자입니다.

이름 그대로 서버가 보내는 이벤트입니다.

클라이언트가 서버에 한 번 연결을 열어두면, 서버는 연결을 유지하다가 필요한 시점에 데이터를 보내줍니다.

클라이언트 → 서버 : 연결할게요.
서버 → 클라이언트 : 새 알림이 있습니다.
서버 → 클라이언트 : 상태가 변경되었습니다.
서버 → 클라이언트 : 작업이 완료되었습니다.

여기서 중요한 점은 SSE가 단방향 통신이라는 것입니다.

즉, 기본 흐름은 이렇습니다.

서버 → 클라이언트

클라이언트는 서버가 보내주는 이벤트를 받습니다.

하지만 같은 연결로 서버에게 메시지를 보내지는 않습니다.

프론트엔드에서는 EventSource를 사용합니다.

consteventSource=newEventSource('/api/events');

eventSource.onmessage= (event) => {
constdata=JSON.parse(event.data);
console.log(data);
};

코드만 보면 꽤 간단합니다.

SSE는 쉽게 말해 라디오 방송에 가깝습니다.

방송국이 말을 합니다.

청취자는 듣습니다.

방송국 → 청취자
서버 → 클라이언트

서버가 “새 알림 왔어요”, “상태 바뀌었어요”, “진행률 80%예요”라고 알려주면 클라이언트는 그것을 받아서 화면에 반영합니다.

4. WebSocket이란?

WebSocket은 서버와 클라이언트가 하나의 연결을 유지하면서 양방향으로 데이터를 주고받는 방식입니다.

클라이언트 → 서버 : 채팅방 들어갈게요.
서버 → 클라이언트 : 입장 완료입니다.
클라이언트 → 서버 : 메시지 보낼게요.
서버 → 클라이언트 : 새 메시지가 도착했습니다.

핵심은 양방향입니다.

서버 ↔ 클라이언트

클라이언트도 서버에게 메시지를 보낼 수 있고, 서버도 클라이언트에게 메시지를 보낼 수 있습니다.

프론트엔드에서는 이렇게 사용할 수 있습니다.

constsocket=newWebSocket('wss://example.com/socket');

socket.onopen= () => {
socket.send(JSON.stringify({
    type:'JOIN_ROOM',
    roomId:1,
  }));
};

socket.onmessage= (event) => {
constdata=JSON.parse(event.data);
console.log(data);
};

WebSocket은 쉽게 말해 전화 통화에 가깝습니다.

나도 말하고, 상대방도 말합니다.

나 ↔ 상대방
클라이언트 ↔ 서버

그래서 채팅, 게임, 협업 편집처럼 서로 계속 데이터를 주고받아야 하는 기능에 잘 맞습니다.

5. SSE와 WebSocket 비교표

두 기술의 차이를 표로 정리하면 다음과 같습니다.

표만 보면 WebSocket이 더 강력해 보입니다.

양방향도 되고, 데이터 형식도 자유롭고, 다양한 기능을 만들 수 있기 때문입니다.

하지만 강력하다고 항상 좋은 선택은 아닙니다.

칼이 좋다고 해서 종이 한 장 자를 때도 꼭 식칼을 꺼낼 필요는 없습니다.

요구사항에 맞는 도구를 쓰는 것이 더 중요합니다.

6. 실제로 어디에 쓰일까?

개념만 보면 조금 추상적입니다.

그래서 실제 사용 사례를 보면 이해가 더 쉽습니다.

SSE가 잘 어울리는 경우

SSE는 서버가 클라이언트에게 정보를 알려주기만 하면 되는 기능에 잘 맞습니다.

예를 들면 이런 기능입니다.

예를 들어 AI 답변 스트리밍을 생각해볼 수 있습니다.

사용자가 질문을 보냅니다.

그다음 서버는 생성된 답변을 조금씩 내려보냅니다.

서버 → 클라이언트 : 안녕하세요.
서버 → 클라이언트 : 요청하신 내용을
서버 → 클라이언트 : 아래와 같이
서버 → 클라이언트 : 정리해드리겠습니다.

클라이언트는 서버에게 계속 말할 필요가 없습니다.

처음 질문을 보낸 뒤에는 서버 응답을 받기만 하면 됩니다.

이런 구조에서는 WebSocket보다 SSE가 더 단순하고 자연스럽습니다.

WebSocket이 잘 어울리는 경우

WebSocket은 서버와 클라이언트가 서로 계속 데이터를 주고받아야 하는 기능에 잘 맞습니다.

예를 들어 채팅은 전형적인 WebSocket 사례입니다.

사용자 A → 서버 : 안녕하세요.
서버 → 사용자 B : 사용자 A가 메시지를 보냈습니다.
사용자 B → 서버 : 반갑습니다.
서버 → 사용자 A : 사용자 B가 메시지를 보냈습니다.

이 구조에서는 클라이언트도 서버에게 계속 메시지를 보내야 합니다.

그래서 SSE만으로는 부족하고 WebSocket이 더 적합합니다.

7. 실제 회사나 서비스에서는 어떻게 쓸까?

SSE와 WebSocket은 실제 서비스에서도 많이 사용됩니다.

SSE 예시

AI 서비스의 응답 스트리밍은 SSE와 잘 어울리는 대표적인 사례입니다.

사용자가 질문을 보내면 서버가 답변을 한 번에 완성해서 내려주는 것이 아니라, 생성되는 토큰을 순차적으로 내려보냅니다.

그래서 화면에서는 답변이 실시간으로 작성되는 것처럼 보입니다.

이런 구조는 클라이언트가 서버에 계속 메시지를 보낼 필요가 없고, 서버가 생성한 결과를 클라이언트가 받기만 하면 되기 때문에 SSE와 잘 맞습니다.

또한 관리자 페이지의 알림, 서버 작업 진행률, 로그 스트리밍 같은 기능도 SSE를 적용하기 좋은 영역입니다.

WebSocket 예시

WebSocket은 채팅 서비스나 협업 서비스에서 많이 사용됩니다.

예를 들어 Discord 같은 채팅 기반 서비스는 실시간 메시지 송수신이 핵심입니다.

사용자가 메시지를 보내고, 서버는 그 메시지를 같은 채널에 있는 사용자들에게 즉시 전달해야 합니다.

Figma 같은 협업 도구도 WebSocket과 잘 어울리는 사례입니다.

여러 사용자가 동시에 같은 파일을 보고 수정하면, 한 사용자의 변경 사항이 다른 사용자 화면에도 거의 실시간으로 반영되어야 합니다.

이런 기능은 단순히 서버가 알려주기만 하는 구조가 아닙니다.

클라이언트의 입력과 서버의 상태가 계속 오가야 합니다.

그래서 WebSocket이 더 자연스럽습니다.

8. 선택 기준을 질문으로 정리하기

기술을 선택할 때는 “SSE가 좋은가요, WebSocket이 좋은가요?”보다

“내 기능은 어떤 데이터 흐름을 가지고 있나요?”라고 묻는 것이 더 좋습니다.

아래 질문으로 판단하면 조금 쉬워집니다.

Q1. 서버가 클라이언트에게 알려주기만 하면 되나요?

그렇다면 SSE를 먼저 고려할 수 있습니다.

예시:

새 알림
상태 변경
작업 진행률
실시간 로그
AI 응답 스트리밍

이런 기능은 대부분 서버에서 클라이언트로 데이터가 흐릅니다.

서버 → 클라이언트

Q2. 클라이언트도 서버에게 실시간으로 계속 보내야 하나요?

그렇다면 WebSocket이 더 적합합니다.

예시:

채팅 메시지 전송
타이핑 중 표시
사용자 위치 전송
게임 조작 이벤트
협업 편집 내용 전송

이런 기능은 서버와 클라이언트가 서로 데이터를 주고받습니다.

서버 ↔ 클라이언트

Q3. 실시간성이 아주 중요하지 않나요?

그렇다면 Polling도 충분할 수 있습니다.

예를 들어 30초마다 한 번 갱신되어도 괜찮은 관리자 통계 화면이라면 굳이 SSE나 WebSocket을 도입하지 않아도 됩니다.

무조건 실시간 기술을 붙인다고 좋은 구조가 되는 것은 아닙니다.

9. 상황별 추천 정리

10. 프론트엔드 개발자 입장에서 느낀 차이

공부하면서 가장 크게 느낀 점은, SSE와 WebSocket은 경쟁 관계라기보다 역할이 다른 기술이라는 점이었습니다.

처음에는 실시간 통신이라고 하면 WebSocket이 먼저 떠올랐습니다.

하지만 실제 요구사항을 보면 굳이 WebSocket까지 필요하지 않은 경우도 많았습니다.

예를 들어 알림이나 진행률처럼 서버가 알려주기만 하면 되는 기능은 SSE가 더 단순합니다.

서버야, 바뀌는 거 있으면 알려줘.

반대로 채팅이나 협업 편집처럼 클라이언트도 계속 서버에게 말해야 하는 기능은 WebSocket이 더 자연스럽습니다.

서버야, 나도 계속 말할게. 너도 계속 알려줘.

이렇게 생각하면 선택 기준이 꽤 명확해집니다.

SSE는 구독에 가깝고, WebSocket은 대화에 가깝습니다.

11. 결론

SSE와 WebSocket은 둘 다 실시간 기능을 구현할 때 사용할 수 있는 기술입니다.

하지만 두 기술은 목적이 다릅니다.

SSE는 서버에서 클라이언트로 이벤트를 보내는 단방향 통신입니다.

그래서 알림, 상태 변경, 작업 진행률, 로그 스트리밍, AI 응답 스트리밍처럼 서버 이벤트를 받기만 하면 되는 기능에 잘 어울립니다.

WebSocket은 서버와 클라이언트가 서로 메시지를 주고받는 양방향 통신입니다.

그래서 채팅, 게임, 협업 편집, 실시간 위치 공유처럼 클라이언트도 계속 서버에 데이터를 보내야 하는 기능에 적합합니다.

정리하면 이렇게 볼 수 있습니다.

서버가 말하고 클라이언트가 듣기만 하면 SSE

서버와 클라이언트가 서로 대화해야 하면 WebSocket

실시간 통신이라고 해서 무조건 WebSocket을 선택할 필요는 없습니다.

중요한 것은 기술 이름이 아니라 데이터가 어느 방향으로 흐르는지입니다.

이번에 SSE와 WebSocket을 비교하면서 느낀 점은, 기술 선택은 “더 좋아 보이는 것”을 고르는 일이 아니라 “현재 요구사항에 더 잘 맞는 것”을 고르는 일이라는 것이었습니다.

범인은 경로가 아니라 CSP(Content Security Policy) 입니다

개발을 하다 보면 한 번쯤 이런 상황을 겪으셨을 겁니다.

“파일도 있고, 경로도 맞는데 왜 이미지가 안 나오지…?”

분명히 dist-electron 안에 파일도 있고,

상대 경로도 맞는데…

이미지가 안 보입니다.

이럴 때 대부분 이렇게 생각합니다.

1. 경로 문제인가?
2. 빌드 문제인가?
3. asar 문제인가?

그런데 의외로 진짜 원인은 따로 있습니다.

👉 CSP(Content Security Policy)

오늘은 이 CSP가 무엇인지,

그리고 왜 Electron에서 자주 문제를 일으키는지

재밌고 쉽게 정리해보겠습니다.

CSP 한 줄 정리

“이 페이지에서 어떤 것만 실행해도 되는지 미리 정해두는 보안 규칙”

1. 왜 이런 게 필요할까요?

웹에는 아주 유명한 공격이 하나 있습니다.

XSS (스크립트 삽입 공격)

예를 들어 어떤 입력창에 이런 코드가 들어왔다고 가정해보겠습니다.

<scriptsrc="https://evil.com/hack.js"></script>

CSP가 없다면 브라우저는 이렇게 생각합니다.

오 스크립트네?
→ 실행

결과는…?

• 쿠키 탈취
• 세션 탈취
• 계정 해킹

CSP가 있으면?

script-src 'self'

브라우저 판단:

👉 즉, 허용된 것만 실행됩니다

2. CSP의 핵심 개념 (이거 하나면 끝입니다)

CSP = 허용된 것만 된다

3. CSP는 어떻게 생겼을까요?

보통 HTML에 이렇게 들어갑니다.

<metahttp-equiv="Content-Security-Policy"
content="default-src 'self'">

이걸 해석하면

"우리 것만 써"

입니다.

4. 주요 규칙 구조

CSP는 리소스별로 따로 설정할 수 있습니다.

5. 허용 값 종류

6. 그럼 왜 내 이미지가 안 나왔을까요?

여기서 핵심입니다.

현재 상황

<metacontent="default-src 'self'">

그리고 코드

<imgsrc="data:image/png;base64,..."/>

브라우저 내부 판단 과정

콘솔 에러

Refused to load image because it violates CSP

7. 해결 방법

딱 한 줄입니다.

img-src 'self' data:

수정 후

<metahttp-equiv="Content-Security-Policy"
content="default-src 'self'; img-src 'self' data:;">

의미

👉 보안은 유지하면서 문제만 해결됩니다

8. Electron에서 특히 자주 터지는 이유

Electron은 그냥 앱처럼 보이지만 내부는 이겁니다.

Chromium 브라우저

그래서 CSP가 그대로 적용됩니다.

자주 터지는 상황

9. 개발하면서 가장 많이 하는 착각

10. 개발자 현실 한 줄 요약

"경로 문제인 줄 알았는데 CSP였다"

⚠️ 헷갈리지 마세요 (CSP 2가지)

여기까지 읽으면서

혹시 이런 생각 드신 분 있을 수 있습니다.

“CSP? AWS 같은 그 CSP 말하는 건가?”

👉 아닙니다.

지금 이 글에서 말하는 CSP는 클라우드가 아니라 ‘보안 정책’입니다.

이 글에서의 CSP

🔐 Content Security Policy

default-src 'self';
img-src 'self' data:;

👉 브라우저(Electron 포함)가

어떤 리소스를 실행할 수 있는지 제한하는 보안 규칙

그런데 또 하나의 CSP가 있다

개발하다 보면 또 다른 CSP를 보게 됩니다.

Cloud Service Provider

• AWS
• Azure
• GCP

👉 서버, DB, 인프라 제공하는 클라우드 서비스

핵심 차이

마무리

CSP는 처음엔 굉장히 까다롭게 느껴집니다.

하지만 한 번 이해하면

👉 보안을 유지하면서 원하는 것만 허용할 수 있는 강력한 도구가 됩니다.

…네, 하반기 회고도 또 늦었습니다. 하하 😇 상반기 쓸 때만 해도 “이번엔 제때 써야지!” 했는데 역시나 현실은 늘 예상보다 빠르고, 저는 늘 예상보다 바빴습니다.

2025년 하반기도 마찬가지로,,, 솔직히 말하면 너무 정신없어서 시간이 어떻게 지나갔는지도 잘 기억이 안 날 정도였어요.

지난 상반기 회고록을 보실 분들은 여기루 ㅎㅎ 상반기 회고록 보기

근데 신기하게도, 막상 돌아보려고 하니까 머릿속에 제일 먼저 떠오른 단어는 이거였습니다.

테스트. 사용자. 구조. 그리고 책임.

상반기가 ‘처음’을 많이 겪은 시기였다면, 하반기는 그 처음들의 결과를 끝까지 책임지면서 진짜로 부딪힌 시간이었어요.

코드는 잘 짰다고 생각했는데 무너졌고, 설계는 괜찮다고 믿었는데 사용자 앞에서 깨졌고, 문서는 미뤄둔 만큼 되돌아와서 저를 괴롭혔습니다.

그리고 저는 그 모든 걸 배포하고, 고치고, 다시 확인하고, 또 배포하는 반복 속에서 조금 더 단단해졌던 것 같아요.

웃으면서 시작했지만 내용은 전혀 웃을 수 없었던(?) 2025년 하반기 이야기를 이제 하나씩 꺼내보려고 합니다.

그럼, 본격적으로 시작해볼게요.

🧨 7월 — 통합 테스트를 시작한 순간, 평화도 같이 종료되었다

7월은 제가 단위 테스트를 했다는 사실에 괜히 뿌듯해하던 나 자신을 가장 세게 반성한 달이었습니다.

5월에 단위 테스트를 도입했을 때는 솔직히 이런 마음이었어요.

“이 정도면 꽤 단단하지 않나?”

“적어도 큰 건 다 잡았겠지?”

지금 와서 말하자면,

그건 정말 순진한 착각이었습니다.

단위 테스트와 통합 테스트는 전혀 다른 이야기였다

7월에 본격적으로 통합 테스트 시나리오를 작성하고, 실제로 테스트를 돌리기 시작했어요.

그리고 거의 바로 깨달았습니다.

“아… 이건 단위 테스트랑 차원이 다르네.”

단위 테스트는

• 함수가 잘 도는지
• API 응답을 잘 처리하는지
• 특정 조건에서 에러가 나는지

를 보는 개발자 중심의 테스트였다면,

통합 테스트는

• 사용자가 처음 이 화면을 봤을 때 뭘 할지
• 어떤 버튼을 누를지
• 실수했을 때 어디서 막히는지

를 전부 보는 사람 중심의 테스트였어요.

그리고 이 ‘사람’은 개발자가 아니었습니다.

개발자가 쓴 통합 테스트 시나리오의 문제

처음엔 당연하게도 통합 테스트 시나리오를 개발자들이 직접 작성했어요.

결과요?

• 내부 상태를 이미 알고 있다는 전제
• “정상 케이스 기준”의 흐름
• 전문 용어가 자연스럽게 섞인 문장들

딱 보자마자 이런 생각이 들었습니다.

“이거… 개발 안 한 사람은 못 하겠는데?”

통합 테스트는 개발을 전혀 모르는 사람도 문서만 보고 그대로 따라 하면 테스트가 가능해야 했어요.

• 여기서 뭘 클릭해야 하는지
• 이 화면이 뜨는 게 정상인지
• 잘못했을 땐 어떤 메시지가 보여야 하는지

모든 걸 ‘사용자 언어’로 다시 써야 했습니다.

이 과정에서 처음 느꼈어요.

“사용자 입장에서 쓴다는 게

이렇게까지 어려운 일이었구나.”

그리고… 버그가 미친 듯이 튀어나오기 시작했다

통합 테스트를 본격적으로 돌리자, 그동안 잠잠하던 시스템이

마치 기다렸다는 듯이 무너지기 시작했습니다.

• 단위 테스트에선 한 번도 안 났던 버그
• 특정 순서에서만 터지는 문제
• 상태가 살짝만 어긋나도 바로 깨지는 흐름

그제야 깨달았어요.

“단위 테스트 때 수월했던 게 아니라,

그냥 그때는 안 보였던 거였구나.”

7월의 제 하루는 거의 이랬습니다.

배포한다

테스트한다

어, 또 터진다

고친다

다시 배포한다

다시 테스트한다

그리고 이 루틴을

하루에도 몇 번씩 반복했습니다.

퇴근하고 나면 아무것도 하고 싶지 않았고,

“오늘은 뭘 배웠지?”보다는

“오늘은 그래도 큰 사고는 없었다.”

이 문장으로 하루를 정리하던 날들이었어요.

배포–테스트–배포–테스트, 그리고 지연의 시작

이 반복이 계속되다 보니 자연스럽게 일정이 밀리기 시작했습니다.

처음엔 “오늘만 좀 더 보자”였고,

그 다음엔 “이번 주까지만 마무리하자”였고,

어느새 지연이 지연을 낳는 구조가 되어버렸어요.

이때 처음으로 통합 테스트의 진짜 무서움을 느꼈습니다.

통합 테스트는 문제를 ‘만들어내는’ 테스트가 아니라 문제를 ‘숨길 수 없게 만드는’ 테스트구나.

그리고 이 여파는 7월로 끝나지 않았습니다.

이 통합 테스트의 후폭풍은 8월까지 고스란히 이어지게 됩니다.

🧩 8월 — 통합 테스트의 후폭풍, 그리고 “이건 코드 문제가 아니었다”

7월이 통합 테스트의 시작이었다면,

8월은그 테스트가 남긴 후폭풍을 전부 떠안은 달이었습니다.

7월 말쯤에는 이런 희망 섞인 생각을 했어요.

“그래도 큰 건 다 나왔겠지…?”

“이제 좀 안정되겠지…?”

네.

역시나 틀렸습니다.

통합 테스트는 끝났지만, 문제는 이제 시작이었다

8월이 되자 통합 테스트에서 발견된 문제들이

하나씩 정리되는 게 아니라,

서로 엮이기 시작했습니다.

• 이 버그를 고치면 저쪽이 깨지고
• 이 흐름을 맞추면 다른 시나리오가 어긋나고
• 한 화면을 고치면 전체 동작이 미묘하게 변하고

이쯤 되니 머릿속에 계속 맴돌던 생각이 하나 있었어요.

“이거… 뭔가 이상한데?”

코드가 아니라, 구조가 문제라는 걸 깨닫다

처음엔 당연히

“로직을 더 꼼꼼히 보자” , “예외 처리를 추가하자”

이렇게 접근했습니다.

근데 아무리 봐도 문제는 코드 몇 줄이 아니었어요.

그때 처음으로 명확하게 느꼈습니다.

“이건 구조 문제다.”

• 흐름이 한눈에 안 보이고
• 상태가 여기저기 흩어져 있고
• 책임이 애매하게 나뉘어 있고
• 테스트 기준도 흔들리고 있고

결국

“왜 이런 문제가 반복되지?”라는 질문의 답은

“전체 구조를 제대로 그린 적이 없어서”

였습니다.

결국 시퀀스 다이어그램을 꺼내 들었다

사실 시퀀스 다이어그램은 원래 문서 설계 단계에서 했어야 하는 작업이었어요.

하지만 우리는 늘 그렇듯,

• “일단 개발부터”
• “시간 없으니까 나중에”
• “지금은 돌아가잖아”

이런 이유로 미뤄두고 있었죠.

그리고 8월이 되어서야 그 ‘나중에’가 찾아왔습니다.

시퀀스를 그리기 시작하자 비로소 보이기 시작했어요.

• 이 요청이 왜 여기로 가는지
• 이 상태가 왜 여기서 바뀌는지
• 이 타이밍에 이 로직이 왜 호출되는지

그리고 동시에 이런 생각도 들었습니다.

“아… 이걸 처음에 했으면

덜 고생했겠구나.”

구조 변경이라는 지옥문이 열리다

시퀀스를 정리하고 나니

선택지는 딱 두 개였습니다.

1. 지금 구조를 유지한 채 계속 땜질하면서 버틴다

2. 지금 아프더라도 구조를 다시 잡는다

결국 선택한 건 두 번째였습니다.

그리고 솔직히 말해서요.

구조 변경은 정말 미친 경험이었습니다.

• 어디까지 고쳐야 하는지 감이 안 오고
• 하나 고치면 다 고친 것 같고
• 근데 또 하나 안 고치면 전체가 흔들리고

이때는 진짜로

“다시는 구조 변경 안 하고 싶다…”

라는 말이 입 밖으로 몇 번이나 나왔어요.

문서를 미룬 대가를 몸으로 치르다

8월의 가장 큰 교훈은 기술적인 것보다 이거였습니다.

“문서는 귀찮아서 미루는 게 아니라, 나중에 나를 살리기 위해 쓰는 거다.”

문서를 제대로 정리하지 않은 상태에서의 개발은

• 기억에 의존하고
• 감에 의존하고
• “아마 이랬던 것 같아”로 움직이는 개발

이게 얼마나 위험한지 8월에 제대로 배웠습니다.

이때부터는 코드를 고치기 전에

• 흐름을 적고
• 조건을 정리하고
• 상태 변화를 글로 써보고

그 다음에야

코드를 손대기 시작했어요.

8월의 체감 난이도는 ‘멘탈’

7월이 체력 싸움이었다면, 8월은 멘탈 싸움이었습니다.

“이게 맞나?” “지금 방향이 맞는 걸까?” “괜히 더 망치고 있는 건 아닐까?”

이런 생각이 하루에도 몇 번씩 들었어요.

근데 아이러니하게도 그 와중에 느낀 게 하나 있었습니다.

“아… 나 지금

진짜 실무 개발하고 있구나.”

편한 선택이 아니라 맞는 선택을 하려고 고민하는 시간이었으니까요.

8월을 지나고 나서

제 개발 태도는 확실히 바뀌었습니다.

• “일단 고치자”보다 ** “왜 이렇게 됐지?”** 를 먼저 묻게 됐고

• 코드보다 흐름을 먼저 보게 됐고

• 문서를 귀찮은 게 아니라 필수 장비로 보게 됐어요.

그리고 무엇보다,

“통합 테스트는 끝이 아니라, 진짜 개발의 시작이다.”

라는 걸 이 달에 확실히 배웠습니다.

🧯 9월 — 사용자성이라는 벽, 그리고 “우리는 아무것도 몰랐다”

9월은 제가 개발자로 일하면서

가장 큰 충격을 받은 달이었습니다.

7–8월이 테스트와 구조의 지옥이었다면,

9월은 그 모든 걸 통과한 뒤에 만난

현실 사용자라는 보스 스테이지였어요.

시험성적서와 납품, 그리고 동시에 시작된 사용자성 개발

9월에 들어서자

일정표에 새로운 단어가 추가됐습니다.

시험성적서. 그리고 납품.

이 두 단어가 등장한 순간, 개발의 기준이 완전히 바뀌었어요.

이전까진 “기능이 된다”가 기준이었다면,

이제는

• 이걸 처음 보는 사람이 이해할 수 있는가
• 실수했을 때 당황하지 않는가
• 다시 시도할 수 있는가

이 질문들이 모든 기능 위에 올라탔습니다.

“개발자들끼리는 다 알잖아요?”

솔직히 말하면 저희는 이런 착각을 하고 있었어요.

“이 정도면 설명 안 해도 알겠지.”

“이건 개발자면 바로 이해하지 않나?”

근데 사용자 테스트를 돌리는 순간 그 착각은 바로 깨졌습니다.

사용자들은

• 어디서 시작해야 하는지 모르고
• 다음 단계가 뭔지 모르고
• 잘못 눌렀는지조차 몰랐어요

그걸 보면서 진짜로 멍해졌습니다.

“어… 이게 그렇게 어려워?”

사용자성은 ‘조금 다듬는 문제’가 아니었다

처음엔 라벨을 바꾸고, 툴팁을 달고,

설명을 한 줄 추가하면 될 줄 알았어요.

근데 아니었습니다.

문제는 훨씬 깊었습니다.

• 시작 지점이 모호했고
• 중간 단계가 많았고
• 실패했을 때의 길이 없었어요

그래서 결국 프로세스를 다시 만들기 시작했습니다.

한 번 만들고

돌려보고

다시 부수고

또 만들고…

이걸 거의

10번 가까이 반복했습니다ㅜㅜㅜㅜ

개발자에게 당연한 흐름은, 사용자에게 공포였다

9월에 가장 충격이었던 건 이거였어요.

개발자 기준으로는 “자연스러운 흐름”이,

사용자 기준에서는 “이거 잘못하면 큰일 나는 거 아냐?” 로 느껴진다는 사실.

보안 제품이라는 특성까지 겹치니

사용자 입장에서는

• 한 번의 실수가
• 시스템 전체에 영향을 줄 것처럼 느껴졌고
• 그래서 더 아무것도 못 하게 되더라구요

그때 처음으로 이해했습니다.

사용자성은 편의성이 아니라, 심리적 안전감이다.

구현보다 어려웠던 것: ‘안심시키는 설계’

이 시점에서

개발보다 더 어려웠던 건

• 어디까지 막아야 할지
• 어디까지 자유를 줄지
• 어디서 “괜찮아요”라고 말해줘야 할지

이 판단들이었습니다.

그래서 9월엔

• 한 단계씩 진행 상황을 보여주고
• 되돌릴 수 있다는 걸 명확히 하고
• 잘못된 선택은 미리 막고

사용자가 불안해하지 않게 만드는 것에

집중하게 됐어요.

야근과 주말 출근, 그리고 웃픈 현실

이 과정은 시간이 정말 많이 들었습니다.

9월에서 끝날 줄 알았던 작업은 10월까지 이어졌고,

야근은 자연스러워졌고 주말 출근도 생겼어요.

월급날 야근수당과 주말수당이 찍힌 금액을 보고

잠깐이나마 아 이게 내 진짜 월급이면 좋겠다....

라는 생각이 들었다는 겁니다.ㅎㅎ,,,,야근수당 최고,,,

(+ 웃픈 토스 보이스피싱,,,)

이렇게 사용자성 때문에 정신이 혼미해지던 와중에

갑자기 토스에서 문자가 하나 왔습니다.

순간 심장이 철렁해서

“혹시 상반기에 지원했던게,,,?” 했다가 확인해보니

그냥 보이스피싱이었습니다.

토스가 나한테 직접 연락할 리가 없잖아요…

잠깐 설렜던 나 자신 매우 반성합니다.

그리고 다시 현실로 복귀했습니다.

🏸 현실 도피가 아니라, 현실 불편 해결용 사이드

9월에 회사 프로젝트 때문에 머리가 계속 터지고 있던 와중에

웃기게도(?) 하나의 사이드 프로젝트를 만들게 됐습니다.

남자친구가 배드민턴 점수랑 득실차를

매번 수기로 계산하면서 너무 힘들어하길래

“아 그냥 내가 만들어줄게…” 하고

급하게 점수 계산 사이트를 하나 만들었어요.(사실 클로드 코드 썼어요,,,잘하더라고요,,)

솔직히 UI는 엉망이었고 사용자성도 좋다고 말하기는 어려웠지만,

적어도 이제 계산이 틀릴 일은 없다는 것 하나로

그 사이트는 존재 이유가 충분했습니다.

프로젝트 구경은,,,,,여기 클릭 나만보는 배드민턴 점수집계 +혹시 사용자성이나 의견 좀 주세여,,,,,ㅠ 인덱스 db만 썼습니다...

회사에선 사용자성을 고민하느라 미치고 있었는데

사이드에서도 결국 똑같이 “사람이 덜 힘들게 하는 게 개발이구나”를

또 한 번 느끼게 된 순간이었어요.

9월을 지나고 나서 저는 확실히 알게 됐어요.

• 사용자는 우리가 생각한 대로 행동하지 않는다
• 설명 없는 자유는 오히려 독이다
• 제품은 기능이 아니라, 신뢰로 평가된다

라는 걸요

10월 — 시험성적서, 구조 개편, 그리고 “그래도 내가 잘 가고 있구나”

10월은 제가 개발자로서

도망치던 것들과, 동시에 처음으로 보상받은 것들이 한꺼번에 밀려온 달이었습니다.

9월이 사용자성으로 멘탈을 흔들었다면,

10월은 기술적으로도, 감정적으로도

꽤 복합적인 달이었어요.

시험성적서가 등장한 순간, 개발의 기준이 바뀌었다

10월에 들어서자 일정표에 본격적으로 등장한 단어가 하나 있었습니다.

시험성적서.

이 네 글자가 등장하자마자

그동안 “괜찮겠지”로 넘어가던 모든 것들이

전부 질문으로 바뀌었어요.

• 이 기능은 정말 안정적인가?
• 에러가 나면 얼마나 빨리 캐치할 수 있는가?
• 성능 저하는 없는가?
• 이 동작을 문서로 설명할 수 있는가?

이제는 “개발자의 감”이 아니라

완성도와 근거로 증명해야 하는 단계였습니다.

완성도를 요구받는 순간, 구조의 민낯이 드러났다

시험성적서를 기준으로 하나하나 점검하다 보니 확실히 보였습니다.

폴더 구조가 너무 비효율적이었다는 것.

그동안은

• “여기서도 쓰고”
• “저기서도 쓰고”
• “이 파일이 이 역할도 하고, 저 역할도 하는”

상태였는데,

시험성적서 기준으로 보니까

• 수정 범위가 너무 넓고
• 에러 추적이 어렵고
• 테스트 기준도 모호해지고

결국 결론은 하나였습니다.

“역할 기반 구조로는 한계다.”

그래서 10월에

역할 기반 → 기능 기반 폴더 구조로 프론트엔드 구조를 아예 갈아엎었습니다.

이미 일정이 촉박한 상황에서

이 결정을 내린 건

솔직히 말해서 도박에 가까웠어요.

근데 동시에 이런 생각도 들었습니다.

“지금 안 바꾸면

이건 평생 고통이다.”

그래서 시간내서 빠르게 바뀌버렸습니다..

그리고 회의 중, 나를 찌른 한 순간

10월 즈음, 에러 원인을 찾기 위한 회의 중에

이야기가 자연스럽게

• 프로세스
• 스레드
• 내부 동작 구조

이쪽으로 흘러갔습니다.

그런데 그때 제가 이 흐름을

명확하게 설명하지 못하겠더라구요.

순간 머릿속이 하얘졌어요.

“나는 프론트엔드 개발자인데…”

“이건 나중에 공부해도 되지 않나?”

그동안 프론트엔드라는 이유로

OS, 프로세스, 스레드 같은 영역을

은근슬쩍 피해왔던 게

그 순간 그대로 드러났습니다.

부끄러웠어요. 진짜로.

“프론트엔드라서”라는 변명을 버리기로 했다

회의가 끝나고 혼자 앉아서 이런 생각이 들었습니다.

“이건 프론트 범위를 벗어난 문제가 아니라,

지금 내가 다루는 시스템의 일부잖아.”

그래서 그때부터 마음속에서 이 말을 지웠어요.

“나는 프론트엔드 개발자니까.”

대신 이렇게 바꿨습니다.

“나는 이 시스템을 만드는 개발자니까.”

완벽하진 않지만,

프로세스와 스레드, OS 기본 구조를 다시 공부하기 시작했고,

적어도

“왜 이런 문제가 터질 수 있는지”는

설명할 수 있어야겠다고 다짐했습니다.

그런데, 이 모든 와중에 찾아온 작은 보상

정신없이 구조를 바꾸고,

시험성적서를 준비하던 10월에

뜻밖의 연락 하나를 받았습니다.

코드잇 스프린트 커리어 프로그램 우수수료자 선정.

이력서 공개와 함께

짧은 인터뷰를 진행하게 됐고,

우수수료자로 뽑혔다는 이야기를 들었을 때

솔직히 기분이 정말 좋았습니다.

네이버 포인트 5만 원도 받았고요. (이건 중요합니다 😄)

하지만 그보다 더 좋았던 건,

현직 대기업 개발자분이 제 포트폴리오와 이력서를 보고 “잘했다”고 평가해줬다는 사실이었어요.

“아… 나, 방향은 맞구나”

10월은 계속해서 부족함을 느끼고,

자존심도 많이 흔들렸던 달이었는데,

이 작은 인정 하나가 제 마음을 꽤 단단하게 잡아줬습니다.

“아, 내가 완벽하진 않아도

헛되게 가고 있는 건 아니구나.”

그래서 그때 처음으로

이런 생각이 들었어요.

“앞으로도 그냥, 꾸준히만 하자.”

조급해하지 말고,

비교하지 말고,

지금처럼 계속 쌓아가면 된다고.

10월은

힘들고, 아프고, 많이 반성했던 달이었지만

동시에 처음으로 ‘외부에서의 인정’을 받은 달이기도 했습니다.

• 구조의 중요성을 몸으로 배웠고
• “프론트엔드라서”라는 변명을 내려놓았고
• 그리고, 내가 잘 가고 있다는 신호도 받았습니다.

그래서 10월을 한 문장으로 정리하자면 이거예요.

“아직 부족하지만, 그래도 계속 가도 되겠다고 느낀 달.”

🧪11월 — 시제품 이후, 그리고 “제품은 개발자 뜻대로 쓰이지 않는다”

11월은 제가 처음으로

‘이제 이건 팔만한 제품용이 아니다.’라는 말을

몸으로 실감한 달이었습니다.

10월까지는 “그래도 아직 내부용이지” “시연 단계니까 괜찮겠지”

라는 마음이 아주 조금은 남아 있었는데,

11월에 들어서면서 그 여지는 완전히 사라졌어요.

시제품 다음 단계는, 생각보다 훨씬 어려웠다

11월부터는 명확하게 기준이 바뀌었습니다.

“이건 나중에 시장에 나가도 되는 기능인가?”

이 질문이 모든 개발의 출발점이 됐어요.

그리고 솔직히 말하면,

시제품보다 이 단계가 훨씬 더 어려웠습니다.

시제품 단계에서는 조금 불편해도, 조금 투박해도,

“컨셉은 보여줬잖아”로 넘어갈 수 있었거든요.

근데 제품은 아니었습니다.

• 한 번 더 눌러야 하는 버튼
• 헷갈리는 용어 하나
• 설명 없는 화면 전환

이 모든 게

바로 ‘문제’가 됐어요.

기술 시연, 그리고 예상 못 한 장면들

11월에는 인천으로 기술 시연도 진행했습니다.

이 시연에서 제가 가장 크게 충격받은 장면이 하나 있어요.

그냥, 정말 그냥

‘닫기 버튼’을 하나 추가해준 기능이 있었거든요.

개발자 입장에서는 “있으면 편하겠지” 정도의 버튼이었는데,

사용자는 그 버튼을 눌러서

아예 다음 단계를 진행하지 않고 그대로 종료해버렸습니다.

그 장면을 보는 순간

머릿속이 잠깐 멈췄어요.

“어… 아니… 그게 그 용도가 아닌데…”

사용자는 항상 ‘가장 쉬운 탈출구’를 찾는다

그 시연을 계기로 확실히 깨달은 게 있습니다.

사용자는 우리가 의도한 흐름을 따르지 않는다.사용자는 가장 쉬운 길을 선택한다.

개발자 입장에서는 “이건 중간에 나가면 안 되는 단계”였지만,

사용자 입장에서는 “지금 안 해도 되는 것”이었던 거죠.

이걸 보고 나서

선택지에 대한 기준이 완전히 바뀌었습니다.

• 정말 필요한 선택인가?
• 사용자가 도망가도 괜찮은 지점인가?
• 아니면 반드시 안내하고 붙잡아야 하는 단계인가?

이걸 하나하나 다시 정의하기 시작했어요.

자유는 안내 없이는 독이 된다

11월에 가장 크게 바뀐 제 생각은 이거였습니다.

“사용자에게 선택지를 많이 주는 게 항상 좋은 건 아니다.”

우리는 “선택이 많으면 좋겠지”라고 생각했지만,

실제 사용자는 선택이 많을수록 더 불안해했습니다.

특히 보안 제품이라는 특성 때문에

사용자 입장에서는

• 한 번의 실수가
• 큰 문제로 이어질 것처럼 느껴졌고
• 그래서 아예 아무것도 안 하게 되는 경우도 많았어요.

그때 깨달았습니다.

사용자성은 편의성이 아니라, ‘안심시키는 설계’라는 걸요.

11월이 남긴 가장 큰 깨달음

11월을 지나고 나서 제 머릿속에 남은 문장은 이거였습니다.

“제품은 개발자가 만드는 게 아니라, 사용자가 완성한다.”

아무리 구조가 좋아도, 아무리 코드가 깔끔해도,

사용자가 이해하지 못하면 그건 아직 제품이 아니었습니다.

11월은 이 사실을 가장 정직하게 마주한 달이었어요.

🔐 12월 — 안정성, 로그, 그리고 “사용자보다 먼저 고치는 사람”

12월은 화려하지 않았고, 눈에 띄는 새 기능도 많지 않았지만,

지금 돌이켜보면

하반기에서 가장 중요한 걸 만든 달이었습니다.

11월까지 사용자성과 제품의 무게를 배웠다면,

12월은 그걸 ‘지속 가능한 상태’로 만드는 달이었어요.

보안기능 인증시험, 그리고 현실의 시작

12월의 시작은 보안기능 인증시험 준비였습니다.

이건 단순히 “기능이 있다”를 증명하는 시험이 아니었어요.

• 실제 환경에서도 안정적인지
• 예상 못 한 상황에서도 버티는지
• 문제가 생기면 추적 가능한지

이걸 전부 보여줘야 했습니다.

그리고 이 과정에서 그동안 모르고 지나쳤던 사실 하나를 뒤늦게 알게 됐어요.

OS가 다르면, 에러도 다르다

이미 나간 기능들에서 OS별로 전혀 다른 에러가 발생하고 있다는 걸

12월에 와서야 명확하게 인지했습니다.

그게 정말 무서웠던 이유는 이거였어요.

에러는 있었는데, 우리는 그걸 모르고 있었다.

사용자는 그냥 “뭔가 이상한데?” 하고 넘어가거나,

아예 말을 안 했을 수도 있고,

우리는 “잘 돌아가겠지”라고 생각하고 있었던 거죠.

이걸 깨달은 순간, 등골이 살짝 서늘해졌습니다.

로그가 없으면, 아무것도 아니다

그래서 방향을 완전히 바꿨습니다.

12월의 키워드는 로그였습니다.

• 모든 에러를 파일로 남기고
• 그 로그를 자동으로 서버로 수집하고
• 원격에서 바로 확인할 수 있도록

에러를 ‘기록되지 않는 사고’가 아니라

‘관리 가능한 이벤트’로 바꾸는 작업이었어요.

Redis를 도입해서

에러 상태를 빠르게 확인할 수 있게 만들었고,

이제는

• 언제
• 어떤 환경에서
• 어떤 에러가
• 어떤 흐름에서 났는지

를 한 번에 볼 수 있는 구조를 만들었습니다.

안정성이란, 에러가 없는 상태가 아니었다

12월을 지나며 제가 완전히 바뀐 생각이 하나 있습니다.

이전엔 “안정적이다”라는 말을

에러가 없는 상태라고 생각했어요.

근데 아니었습니다.

안정성이란 에러를 빨리 알아차리고, 빨리 고칠 수 있는 상태였습니다.

이미 자동 업데이트 기능을 넣어둔 덕분에,

• 에러를 발견하고
• 수정하고
• 사용자 개입 없이 배포하는 흐름을

꽤 빠르게 만들 수 있었어요.

그때 처음으로 이런 생각이 들었습니다.

“아… 이 정도면

그래도 사용자한테 미안하지는 않다.”

그리고, 정말 오랜만에 나를 위한 개발

12월 내내 회사 일에 치여 살다 보니

사이드 프로젝트는 거의 손도 못 댔는데,

연말에 딱 하나 꺼낸 게 있었습니다.

3D 크리스마스 트리.

three.js로 만들었고, GPU를 살살 녹이면서

불빛이 반짝이는 트리를 만들었어요.

이 프로젝트는 완성도를 따지기보단,

“아, 나 아직 개발 좋아하네.”

이 감정을

다시 확인하기 위한 작업이었습니다.

사실 이 시점엔 체력도, 멘탈도 꽤 바닥이었어요.

그래도 전구가 반짝이는 걸 보면서

• 내가 만든 게 눈앞에서 움직이고
• 코드가 실제 화면이 되고
• ‘재밌다’는 감정이 다시 올라오는 순간

그게 참 좋았습니다.

개발을 좋아해서 시작했는데,

중간에 그 이유를 잠깐 잊고 있었구나 싶었어요.

크리스마스 트리 구경하러가기 3D 크리스 마스 트리 회고록 보러가기

🌙 2025년 하반기를 닫으며

2025년 하반기는

솔직히 말해서 정말 많이 무너지고, 많이 지치고, 많이 배웠던 시간이었습니다.

단위 테스트로 안심했던 코드들은 통합 테스트에서 깨졌고,

구조를 미뤄둔 대가는 일정과 멘탈로 돌아왔고,

“개발자끼리는 알겠지”라고 만든 기능들은 사용자 앞에서 전부 멈췄습니다.

그 과정 속에서 저는

코드를 잘 짜는 개발자가 아니라

끝까지 책임지는 개발자가 되어가고 있었다는 걸

뒤늦게 깨닫게 된 것 같아요.

혼자 야근하면서 좌절하던 순간도 많았지만,

회사 분들의 응원과 믿음,

특히 상사분들이 늘 이뻐해주시고 격려해주신 덕분에

끝까지 버틸 수 있었습니다.

그래서 이 하반기는

힘들었던 기억보다도

“그래도 나는 계속 가고 있구나”라는 감정으로 남아 있습니다.

Electron을 통해

웹 밖의 세계를 처음 경험했고,

솔루션과 시스템을 만드는 재미를 알게 되었고,

그래서 더 넓은 개발 영역에도 욕심이 생겼습니다.

2026년에는

three.js를 제대로 공부해보고 싶고,

vue.js도 깊게 다뤄보고 싶고,

언젠가는 로봇과 같은 하드웨어와 맞닿은 개발에도 도전해보고 싶습니다.

아직은 부족한 게 너무 많지만,

올해를 지나며 확실히 느낀 건 하나예요.

개발자는 무너지면서 자라고,

버틴 만큼 결국 다음 단계로 나아간다.

그래서 저는 내년에도

겁먹지 않고, 미루지 않고,

계속 배우고 실험하면서 나아가 보려고 합니다.

프론트엔드 개발자 송연지,

2026년에도 성장 중으로 살아가겠습니다. 🚀💙

마지막으로 이 긴 하반기 회고를

여기까지 읽어주신 분들께 진심으로 감사드립니다.

저는 여전히 느리고, 부족하고,

남들보다 돌아가고 있다는 느낌을 받을 때도 많지만

그래도 올해를 지나면서 한 가지는 확실히 믿게 됐어요.

속도는 늦을 수 있어도

방향만큼은 맞는 개발자로 가고 싶다.

빠르게 성장하는 개발자도 멋있지만,

저는 실수하더라도 배우고,

무너지더라도 기록하고,

결국엔 단단해지는 개발자가 되고 싶습니다.

혹시 이 글을 읽고 있는 누군가도

지금 느리다고 느껴지거나, 비교 때문에 힘들다면

우리 그냥 이렇게 말했으면 좋겠어요.

“늦어도 괜찮다. 멈추지만 않으면 된다.”

개발자는 결국

계속 배우는 사람이 이긴다고 저는 믿습니다.

그래서 저는 내년에도 계속 배우고, 도전하고, 버틸 거고

이 글을 읽는 모든 개발자 분들도

각자의 자리에서 원하는 방향으로 끝까지 나아가시길

진심으로 응원합니다.

우리 모두 2026년도 화이팅입니다. 🚀💙!

크리스마스가 오면 사람들은 트리를 꺼내고,

개발자는 콘솔을 켭니다.

그리고 이렇게 생각합니다.

“별 찍고 공백 맞추는 트리…

나도 한 번쯤은 만들어봤지.”

    *
   ***
  *****
 *******
*********

이 트리의 문제점은 명확합니다.

재미가 없습니다.

너무 빨리 끝납니다.

그리고 GPU가 전혀 아프지 않습니다.

그래서 문제가 됩니다.

🎅 이 정도로는 만족하지 못합니다

문득 이런 생각이 들었습니다.

“three.js를 아직 안 써봤는데

이걸 크리스마스까지 미루면 영영 안 쓰는 거 아닐까?”

공부 목적으로 시작하기엔 귀찮고,

사이드 프로젝트로 하기엔 애매한데

마침 트리가 있었습니다.

그래서 결론은 간단했습니다.

트리를 3D로 만들자. 느리면 느린 대로 두자.

🌲 그래서 나온 결과물

👉 https://3-d-christmas-tree.vercel.app/

• 마우스로 돌릴 수 있고
• 전구가 깜빡이고
• 눈이 내리고
• 설정 패널까지 있습니다

그리고 제일 중요한 특징 하나.

컴퓨터가 크리스마스를 함께 느낍니다. (팬 소리)

🧩 기술 얘기

이번 트리는

Next.js 위에 React Three Fiber를 얹어서 만들었습니다.

three.js를 직접 쓰기엔 연말이었고,

그래서 React스럽게:

• group으로 장식들을 묶고
• useFrame으로 전부 움직이게 만들고
• 전구는 배열로 쭉 만들었습니다

전구 깜빡임은 사실 굉장히 단순합니다.

Math.sin(time + offset)

하지만 이 한 줄 덕분에

전구들이 “나 각자 살아있다”는 태도를 보입니다.

🎛️ 괜히 만들어본 설정 패널

전구 개수, 속도, 눈 내림 여부, 자동 회전.

없어도 되는데

있으면 더 만지고 싶어집니다.

이걸 만들면서 느낀 점은 하나였습니다.

설정 패널은 기능보다

괜히 있는 게 더 중요하다.

🐢 최적화는요? 안 했습니다

왜냐하면

이 트리는 실무용이 아니라

연말 감성용이기 때문입니다.

• 전구 많음
• 라이트 많음
• 눈 계속 떨어짐

그래서:

• 노트북이 따뜻해지고
• 팬이 돌고
• 크리스마스 분위기는 최고입니다

🎄 성능을 희생하여 연말을 얻었습니다.

🎁 이 프로젝트의 진짜 목적

이 트리는

잘 만든 트리가 아닙니다.

하지만:

• 만들면서 재밌었고
• three.js를 “써봤다”는 기록이 남았고
• 내년에 또 트리를 만들 핑계가 생겼습니다

그럼 이걸로 충분하지 않겠습니까.

✨ 마무리

개발자라면

별 한 번 찍고

공백 한 번 맞추고

결국엔 트리를 만들어야 합니다.

올해는 콘솔이 아니라

GPU로 만들었을 뿐입니다.

메리 크리스마스입니다 🎄 그리고 개발자 여러분, 트리는 늘 옳습니다.

— 비동기 때문에 흔들리던 UI를 React가 직접 통제하기 시작한 순간

프론트엔드 개발을 하다 보면 자연스럽게 하나의 고민이 생깁니다.

“왜 로딩 UI가 이렇게 많지?”

“왜 페이지 이동할 때 깜빡이지?”

“데이터 패칭 실패하면 화면이 바로 죽는 이유가 뭘까?”

“컴포넌트마다 isLoading, error를 계속 만들어야 하는 게 맞는 걸까?”

React는 분명 “UI를 선언적으로 그리는 라이브러리”인데,

정작 데이터 패칭·로딩·에러·코드 스플리팅처럼 실제 애플리케이션에 반드시 필요한 비동기 흐름은 React가 직접 관리하지 않았습니다.

그 결과 애플리케이션 구조는 점점 복잡해졌습니다.

• 로딩 UI가 곳곳에 흩어지고
• 에러 처리 방식은 개발자마다 다르고
• 코드 스플리팅은 가능하지만 “대기 UI”는 직접 만들어야 하고
• 렌더링 중 깜빡임(Flash)이 생기고
• 데이터가 늦게 도착하면 빈 화면이 잠깐 노출되고…

React 팀은 어느 순간 이렇게 결론을 내립니다.

“비동기는 UI의 일부이므로, UI 프레임워크인 React가 이걸 직접 통제해야 한다.”

그 결론의 첫 번째 산물이 바로 Suspense입니다.

그리고 나머지 기술들은 이 Suspense라는 개념을 중심으로 확장된 애들입니다.

이 글에서는 기술 이름만 나열하지 않고,

• ✔ 왜 등장했는지 (발생 배경)
• ✔ 어떤 구조적 문제를 해결했는지 (개념)
• ✔ 내부적으로 어떻게 작동하는지 (메커니즘)
• ✔ 언제 쓰는지 (사용 시점 예시)

이 네 가지 축으로 길게 정리해보겠습니다.

1. 🎯 React의 근본적 한계: “UI는 동기적이다”라는 오래된 가정

React는 초기에 “상태 → UI”라는 동기적 렌더링 모델을 기반으로 설계됐습니다.

즉, 렌더링 시점에는 모든 데이터가 이미 존재한다고 가정한 거죠.

하지만 실제 애플리케이션은 다음처럼 비동기 투성이입니다.

• API에서 데이터 가져오기
• Lazy 로딩된 컴포넌트 불러오기
• 사용자 인터랙션에 따른 추가 데이터 조회
• SSR/CSR 간 데이터 교환
• 리소스 로딩(이미지, 폰트, 스크립트 등)

이 비동기 흐름을 React는 “외부 상태”나 “사용자 정의 로직”으로 해결하게 만들었습니다.

그 때문에 애플리케이션 구조는 자연스럽게 이렇게 변해갔습니다.

• ❌ 컴포넌트마다 isLoading, error를 도배
• ❌ 데이터 도착 전 UI가 잠깐 깨져 보임
• ❌ 코드 스플리팅했는데 로딩 UI는 직접 구현
• ❌ 에러 발생 시 화면 전체가 죽어버림
• ❌ 렌더링이 비동기로 인해 뒤틀리는 현상(깜빡임, 빈 화면)

이건 React의 “버그”라기보다는,

애초에 React가 비동기를 렌더링 모델 안에 포함시키지 않았기 때문입니다.

그러니 React는 이런 질문을 하게 됩니다.

“비동기를 UI 렌더링의 일부로 만들 수 없을까?”

Suspense는 바로 그 질문에 대한 첫 번째 대답입니다.

2. 🍱 React.lazy — 코드 스플리팅을 “React의 비동기”로 만들다

2-1. 코드 스플리팅의 등장 배경

프론트엔드 앱이 커지면서 JS 번들은 점점 커졌고,

SPA 특성상 안 쓰는 페이지 JS까지 처음에 다 들고 오는 문제가 생겼습니다.

그래서 Webpack / Vite 같은 도구가 코드 스플리팅을 제공하기 시작했죠.

하지만 이 상태에서는 이런 문제가 남아 있었습니다.

“번들은 쪼개지는데, 그게 로딩 중인지 아닌지 React는 모른 척한다.”

그래서 예전에는 이런 코드가 많았습니다.

// (예전에 흔히 보던 패턴 – 직접 상태 관리)
function LazySettingsWrapper() {
  const [Settings, setSettings] = React.useState<React.ComponentType | null>(null);

  React.useEffect(() => {
    import('./Settings').then(mod => {
      setSettings(() => mod.default);
    });
  }, []);

  if (!Settings) {
    return <div>설정 화면 불러오는 중...</div>;
  }

  return <Settings />;
}

• 모듈 로딩 상태를 직접 관리해야 하고
• 로딩 UI도 매번 직접 짜야 하고
• 에러 처리도 따로 해야 합니다.

React는 이걸 “React가 직접 지원해야 하는 영역”이라고 보고,

React.lazy를 도입합니다.

const Settings = React.lazy(() => import('./Settings'));

이 한 줄은 단순히 “동적 import”가 아닙니다.

내부적으로는 렌더링 중에 Promise를 던지는 컴포넌트가 됩니다.

즉, 렌더링 중에 이 컴포넌트를 만나면 흐름이 이렇게 바뀝니다.

렌더링 → Promise throw → “대기 필요”

근데 아직 React는 이 Promise를 받을 줄 모릅니다.

이 Promise를 받아서, “잠깐 이 UI 대신 다른 걸 보여주자”를 처리해주는 애가 바로 Suspense입니다.

2-2. React.lazy + Suspense 기본 사용 예시

import React, { Suspense } from 'react';

const SettingsPage = React.lazy(() => import('./SettingsPage'));

export function App() {
  return (
    <Suspense fallback={<div>설정 화면 불러오는 중...</div>}>
      <SettingsPage />
    </Suspense>
  );
}

• SettingsPage는 아직 안 받아온 상태일 수 있고
• 그 동안 Suspense가 fallback을 렌더링해줍니다.

여기서 이미 “비동기 로딩을 UI 렌더링의 일부로 넣는다”는 개념이 시작됩니다.

3. 🎬 Suspense — 렌더링 중 비동기 “대기”를 정식 기능으로 넣은 기술

Suspense를 잘 모르면 흔히 이렇게 생각하기 쉽습니다.

“아, 로딩 스피너 보여주는 컴포넌트지?”

절반은 맞고, 절반은 틀렸습니다.

Suspense의 본질은 “렌더링 중 발생한 비동기를 React가 직접 처리하는 것”입니다.

3-1. Suspense는 DOM을 어떻게 다룰까?

중요한 포인트는 이겁니다.

Suspense는 DOM을 직접 조작하지 않고,

“렌더링 과정을 제어”합니다.

대략적인 흐름은 이렇습니다.

1. Suspense 아래에 있는 컴포넌트가 Promise를 던짐
   • 예) React.lazy, React Query suspense: true, 커스텀 리소스 래퍼 등
2. React는 지금 진행 중인 렌더링을 중단함
3. 가장 가까운 Suspense Boundary를 찾음
4. 그 Boundary에 정의된 fallback UI를 대신 렌더링
5. Promise가 resolve되면
   • React가 다시 원래 렌더링을 이어서 수행
   • 기존 fallback DOM은 사라지고, 실제 UI로 자연스럽게 교체

즉, “fallback → 실제 UI”로 부드럽게 전환되는 전체 과정을

React 렌더링 엔진이 직접 관리하게 됩니다.

3-2. Suspense를 쓸 때 체감되는 효과

이 방식 덕분에:

• 로딩 상태가 컴포넌트 깊은 곳에 흩어지지 않고
• “어디까지를 하나의 로딩 단위로 볼 건지”*를 Boundary로 명확하게 자를 수 있고
• 화면이 깜빡이거나, 잠깐 빈 영역이 보이는 문제를 줄일 수 있습니다.

예를 들어 이런 식입니다.

// 대시보드 전체를 하나의 Suspense boundary로 감싸는 예시
function Dashboard() {
  return (
    <Suspense fallback={<div>대시보드 로딩 중...</div>}>
      <UserSummary />   {/* 내부에서 데이터 패칭 */}
      <ActivityChart /> {/* 내부에서 데이터 패칭 */}
      <NotificationList /> {/* 내부에서 데이터 패칭 */}
    </Suspense>
  );
}

각 컴포넌트가 알아서 비동기를 던지고,

Suspense가 그 전체를 하나의 “로딩 화면”으로 묶어줍니다.

좀 더 세분화하고 싶다면, 이런 식도 가능합니다.

function Dashboard() {
  return (
    <div>
      <Suspense fallback={<div>프로필 불러오는 중...</div>}>
        <UserSummary />
      </Suspense>

      <Suspense fallback={<div>활동 차트 로딩 중...</div>}>
        <ActivityChart />
      </Suspense>
    </div>
  );
}

Boundary를 어떻게 나눌지에 따라

“사용자가 어디까지를 하나의 화면으로 인식할지”를 설계할 수 있습니다.

4. 🛡 ErrorBoundary — Suspense와 100% 맞물려 돌아가는 에러 복구 메커니즘

여기까지 보면 Suspense는 “대기(loading)”만 해결합니다.

그러면 “실패(error)”는 누가 처리할까요?

대답: Suspense가 아니라, ErrorBoundary입니다.

4-1. ErrorBoundary의 동작 흐름

React는 렌더링 중 에러가 발생하면 아래와 같이 동작합니다.

1. 렌더링 중 Error가 throw됨
2. React는 렌더링을 중단
3. 가장 가까운 <ErrorBoundary>를 찾음
4. 그 Boundary의 fallback UI를 렌더링하여 안전하게 복구

Suspense = “기다림” 담당

ErrorBoundary = “실패” 담당

둘이 세트라고 보면 됩니다.

4-2. ErrorBoundary 예시

// 클래스형 컴포넌트로만 공식 지원
class RootErrorBoundary extends React.Component<
  { children: React.ReactNode },
  { hasError: boolean }
> {
  constructor(props: any) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError() {
    return { hasError: true };
  }

  componentDidCatch(error: any, info: any) {
    console.error('[ErrorBoundary]', error, info);
  }

  render() {
    if (this.state.hasError) {
      return <div>문제가 발생했습니다. 잠시 후 다시 시도해 주세요.</div>;
    }
    return this.props.children;
  }
}

// Suspense와 함께 사용
function App() {
  return (
    <RootErrorBoundary>
      <Suspense fallback={<div>전체 앱 로딩 중...</div>}>
        <MainRouter />
      </Suspense>
    </RootErrorBoundary>
  );
}

• 비동기 로딩 중에는 Suspense가 처리
• 비동기 실패(또는 동기 에러)는 ErrorBoundary가 처리

이렇게 되면:

• API 하나 터졌다고 전체 앱이 흰 화면이 되는 걸 막을 수 있고
• “특정 영역만 에러 UI로 교체” 같은 UX를 설계할 수 있습니다.

5. 🔗 React Query + Suspense — 데이터 패칭을 React 렌더링 모델에 완전히 편입

React Query를 쓸 때 가장 익숙한 패턴은 이거일 겁니다.

const { data, isLoading, isError } = useQuery({
  queryKey: ['user', userId],
  queryFn: fetchUser,
});

if (isLoading) return <div>로딩 중...</div>;
if (isError) return <div>에러…</div>;

이 방식의 단점은:

• 컴포넌트마다 로딩/에러 조건문이 반복되고
• 로딩 UI가 페이지 전역에서 제각각 만들어지고
• 중첩 컴포넌트 구조에서는 가독성이 급격히 떨어진다는 점입니다.

React 18 이후, React Query는 suspense: true를 지원하면서 완전히 다른 그림이 나옵니다.

// React Query + Suspense 사용
const { data } = useQuery({
  queryKey: ['user', userId],
  queryFn: fetchUser,
  suspense: true,  // 핵심
});

이제 내부적으로는 이렇게 동작합니다.

• 로딩 중 → Promise를 던짐 → Suspense에서 fallback 렌더
• 실패 → Error를 던짐 → ErrorBoundary에서 복구
• 성공 → 정상적으로 데이터 사용

예시를 한 번에 정리하면:

function UserProfile() {
  const { data: user } = useQuery({
    queryKey: ['user', 1],
    queryFn: fetchUser,
    suspense: true,
  });

  return <div>{user.name}님 안녕하세요.</div>;
}

function App() {
  return (
    <RootErrorBoundary>
      <Suspense fallback={<div>사용자 정보를 불러오는 중입니다...</div>}>
        <UserProfile />
      </Suspense>
    </RootErrorBoundary>
  );
}

여기서 포인트는:

• UserProfile 내부에는 isLoading, isError가 사라지고
• 로딩/에러 처리는 “위에서 한 번에” 잡아줄 수 있다는 점입니다.

실제 프로젝트가 커지면, 이 구조가 생각보다 엄청 시원해집니다.

6. 🌊 Server Components + Streaming — Suspense가 만들어낸 SSR 진화

Next.js 13 이후 도입된 Server Components / Streaming도 사실 Suspense 위에 서 있는 기능입니다.

아이디어는 단순합니다.

“서버에서 준비된 부분만 먼저 보내고,

아직 안 된 부분은 Suspense fallback으로 대체해서 보낸 다음,

준비되면 해당 부분만 교체하자.”

6-1. 아주 간단한 예시 느낌

// app/page.tsx (Next.js 13+ 예시 느낌)
import { Suspense } from 'react';
import UserFeed from './UserFeed';

export default function Page() {
  return (
    <><h1>대시보드</h1>
      <Suspense fallback={<div>피드 로딩 중...</div>}>
        {/* 서버에서 데이터 패칭 후 스트리밍 */}
        <UserFeed />
      </Suspense>
    </>
  );
}

실제로는 서버가:

1. <h1>대시보드</h1>와 fallback을 먼저 내려보내고
2. UserFeed 데이터가 준비되면
3. 해당 영역만 치환하는 방식으로 동작합니다.

이 구조 덕분에:

• 초기 렌더링 체감 속도가 빨라지고
• 네트워크 지연이 덜 답답해지고
• JS 번들 크기도 줄어들고
• UX가 훨씬 자연스러워집니다.

이 모든 게 가능한 이유가 바로 “부분적으로 UI를 대체하고 다시 복구한다”는 Suspense 모델이 존재하기 때문입니다.

7. 🎛 결국 이 기술들은 하나의 흐름이다

정리해보면:

즉, 이 기술들은 따로 떨어진 기능 목록이 아니라

“React 렌더링 모델의 진화 과정에서 등장한 한 계보”에 가깝습니다.

공통된 철학은 항상 하나입니다.

“UI와 비동기를, React가 직접 통제하겠다.”

8. 🌱 Suspense를 제대로 쓰기 위한 사전 조건

Suspense는 강력하지만, “그냥 아무 데나 막 꽂아 넣으면 좋은 기능”은 아닙니다.

개인적으로는 아래 같은 상황에서 특히 잘 맞는다고 느꼈습니다.

• ✔ 비동기 로직이 컴포넌트 곳곳에 섞여 있을 때
• ✔ 로딩/에러 UI를 일관되게 관리하고 싶을 때
• ✔ 페이지/기능 단위 코드 스플리팅을 적용하고 싶을 때
• ✔ 여러 API를 병렬로 호출하면서도 깔끔한 UI 흐름을 만들고 싶을 때
• ✔ Next.js처럼 SSR/Streaming까지 염두에 둔 구조를 만들고 싶을 때

이럴 때 “Suspense + ErrorBoundary + (React Query or lazy)” 조합이 진짜 빛을 발합니다.

🎉 마지막 요약

Suspense는 “로딩 스피너 보여주는 컴포넌트”가 아닙니다.

Suspense는 React가 비동기 UI 전체를 스스로 통제하기 시작한 첫 번째 기술입니다.

비동기 → 대기 → 복구 → 렌더링

이 전체 사이클을 React 내부 엔진이 책임지는 구조로 바꾸면서,

• 깜빡임 없는 UI
• 일관된 로딩/에러 처리
• 코드 스플리팅의 자연스러운 적용
• SSR Streaming 같은 차세대 기능

이런 것들이 한 줄로 이어지기 시작했습니다.

개인적으로는,

“Suspense를 이해하는 순간

‘React 생태계 전체가 왜 이런 방향으로 진화하고 있는지’가

훨씬 명확하게 보인다”

라는 느낌이 들었습니다.

— 다시 빌드하기 싫을 때 꼭 필요한 꿀팁입니다

Electron 개발을 하다 보면, 이런 순간이 꼭 찾아옵니다.

개발 모드에서는 정말 말 잘 듣던 앱이

배포 모드(Prod)만 올라가면 갑자기 태도가 달라지는 순간이요.

• 무한 로딩만 뱅글뱅글 돈다든지
• 특정 페이지에서 멈춘다든지
• 엔진 IPC만 Prod에서 실패한다든지
• 심지어 콘솔도 안 찍혀서 뭐가 문제인지 감도 안 잡히는…

게다가 더 난감한 건,

“아… 제가 DevTools를 막아놨죠…”

이겁니다.

보안을 위해 devTools: false 넣어놨거나

빌드할 때 콘솔 제거 플러그인까지 적용해놓아서

배포된 exe에서는 DevTools를 열 수 없는 상황이 됩니다.

이때, 보통 떠올리는 해결책은 두 가지입니다.

1. DevTools 다시 열리게 코드 고치고 →
2. 빌드 → 패키징 → 설치 → 다시 테스트

하지만…

솔직히 이 과정, 한 번 하면 괜찮은데

버그가 계속 바뀌기라도 하면 정말 피곤해집니다.

그래서 저는 결국 방법을 찾아냈습니다.

✨ 결론부터 말하자면,

배포된 exe 그대로 DevTools를 열 수 있습니다.

다시 빌드하지 않아도 됩니다.

코드를 한 줄도 고칠 필요 없습니다.

심지어 devTools를 false로 막아놔도 가능합니다.

Electron의 정체는 결국 Chromium 기반 브라우저입니다.

그리고 Chrome에는 공식적으로 “원격 디버깅 포트(Remote Debugging Port)”라는 기능이 있습니다.

이걸 Electron에서도 그대로 활용할 수 있습니다.

즉, 앱을 실행할 때 아래 옵션 한 줄만 붙이면 됩니다.

--remote-debugging-port=9222

이게 끝입니다.

🔧 방법: 배포된 exe에서 DevTools 강제로 열기

1. CMD(명령 프롬프트)를 실행합니다.

윈도우키 → cmd → 엔터

2. 배포된 exe가 있는 폴더로 이동합니다.

예를 들어 앱이 여기 설치돼 있다고 가정하면:

C:\Users\사용자명\AppData\Local\Programs\YourApp

명령어는:

cd "C:\Users\사용자명\AppData\Local\Programs\YourApp"

3. 앱을 디버깅 포트와 함께 실행합니다.

YourApp.exe --remote-debugging-port=9222

이렇게 실행한 순간부터 Electron 내부의 Chromium은

디버깅용 포트(9222)를 열어놓게 됩니다.

앱은 그대로 정상 실행됩니다.

코드도 건드린 적 없습니다.

하지만 Chromium은 “디버깅 연결 준비 완료” 상태가 됩니다.

4. Chrome 브라우저에서 DevTools로 접속합니다.

Chrome 주소창에 입력합니다:

chrome://inspect

→ “Discover network targets” 클릭

→ localhost:9222 추가

→ 아래쪽 “Remote Target”에 Electron 프로세스가 뜹니다.

→ Inspect 버튼을 클릭합니다.

그러면 바로 DevTools가 열립니다.

Elements, Console, Network, Sources, Performance, Application…

배포 모드에서만 보이는 그 문제들을

그 자리에서 그대로 확인할 수 있습니다.

🎁 이 방법의 장점

✔ devTools: false여도 무조건 열립니다

Electron 옵션으로 막혀 있어도 상관없습니다.

✔ 콘솔 제거 플러그인 적용돼 있어도 Network/Elements는 완전히 보입니다

remove-console 같은 플러그인 적용돼도 콘솔만 사라질 뿐,

디버깅 포트 연결은 그대로 가능합니다.

✔ asar로 압축된 배포 버전에서도 당연히 가능합니다

app.asar이든 unpacked든 관계 없습니다.

✔ 다시 빌드할 필요가 없습니다

코드 수정 → 빌드 → 패키징 → 설치…

이 반복 루프를 피할 수 있습니다.

✔ 생산성 급상승

Prod 환경에서만 터지는 버그를 바로 캐치할 수 있습니다.

💬 마무리

Electron을 쓰다 보면 “개발 모드에서는 안 나는 버그가 왜 배포 모드에서만…” 이런 상황이 흔합니다.

그럴 때 DevTools까지 막혀 있다면 디버깅 자체가 막히기 쉽죠.

하지만 Electron은 브라우저 기반이기 때문에

이렇게 디버깅 포트만 열어주면 언제든 다시 DevTools를 연결할 수 있습니다.

저는 이 기능을 알고 난 후로

배포 빌드 다시 만드는 일이 절반으로 줄었습니다.

똑같은 문제를 겪고 있는 분들께 꼭 도움이 되었으면 합니다.

API 요청 로그가 두 번씩 찍히는 현상을 경험하신 적 있으신가요?

저도 Electron + React 기반 사내 프로젝트를 하다가,

“어? 내 코드가 잘못된 건가? 서버가 중복 응답을 주는 건가?” 하고 한참을 헤맸습니다.

결론부터 말씀드리면, 이건 React StrictMode 때문입니다.

제 삽질 경험을 토대로, 왜 이런 일이 일어나는지, 배포에서는 어떤지,

그리고 제가 얻은 교훈까지 정리해보겠습니다.

1. StrictMode란 무엇인가요?

React의 StrictMode는 개발 모드에서만 실행되는 검증 도구입니다.

• 코드에서 안전하지 않은 패턴을 찾고,
• 메모리 누수 가능성이 있는 코드를 조기에 발견하고,
• 사이드 이펙트(side effect) 실행 과정을 검증하기 위해

React가 일부러 컴포넌트를 더 빡세게 실행합니다.

왜 API 요청도 두 번 갈까?

StrictMode는 단순히 렌더링만 두 번 하는 게 아니라,

useEffect 같은 부작용(side effect) 코드도 마운트 → 클린업 → 다시 마운트 흐름으로 반복 실행합니다.

즉, 코드가 이렇게 생겼다면:

useEffect(() => {
  fetchApi(); // API 호출
}, []);

실행 순서는 이렇습니다:

1. 첫 번째 마운트 → fetchApi() 실행 → API 요청 1회
2. 언마운트 & 클린업
3. 두 번째 마운트 → 다시 fetchApi() 실행 → API 요청 1회

👉 결과적으로 API 요청이 2번 전송됩니다.

즉, 내 코드에는 문제가 없고, React가 일부러 그렇게 하는 겁니다.

개발 모드 vs 배포 모드

• 개발 모드 (npm run start / vite dev 등)

  StrictMode가 활성화되어 API 요청이 두 번 갑니다.

• 배포 모드 (npm run build 후 실행, electron-builder 배포 등)

  StrictMode 자체가 제거됩니다. 따라서 API는 정상적으로 한 번만 호출됩니다.

저도 electron-builder로 패키징해서 실행했을 때는,

로그에 요청이 한 번만 찍히는 걸 확인했습니다.

개발할 땐 두 번, 배포하면 한 번 → 이게 정상입니다.

2. 중복 호출을 막는 방법

개발 모드에서 로그가 두 번 찍히는 게 불편하다면,

간단히 useRef를 써서 가드를 걸 수 있습니다.

const hasFetchedRef = useRef(false);

useEffect(() => {
  if (hasFetchedRef.current) return;
  hasFetchedRef.current = true;

  fetchApi();
}, []);

이렇게 하면 개발 모드에서도 API는 한 번만 호출됩니다.

저는 보통, 조회 API는 두 번 호출돼도 상관없으니 그냥 두고,

중복 호출이 문제가 되는 등록/수정/승인 API만 이런 방어 로직을 넣었습니다.

페이지 클릭 시 조회 API 호출

Electron 프로젝트에서는 페이지 이동(라우터 클릭)마다 조회 API가 다시 호출되는데,

여기에 StrictMode까지 더해지니 “응답이 두 개씩 오는 것처럼” 보여서 헷갈리더군요.

실제로 로그는 이렇게 찍힙니다:

[API ▶ getCpnMember 요청] { cpnId: 2, userId: 2 }
[API ◀ getCpnMember 응답] { result: { pscd: 'OK', data: [], pcsRsltMsg: '응답을 보냈습니다.' } }
[API ◀ getCpnMember 응답] { result: { pscd: 'OK', data: [], pcsRsltMsg: '응답을 보냈습니다.' } }

처음엔 “응답이 두 번 오네?”라고 생각했지만, 사실은 요청을 두 번 보낸 거였어요.

이것도 StrictMode의 영향으로, 배포 모드에선 정상적으로 한 번만 호출됩니다.

다만 페이지 이동 시마다 조회 API가 자동으로 불리는 구조라면,

캐시나 상태 관리 도구를 붙여서 불필요한 호출을 줄이는 게 좋습니다.

3. React Query / SWR 같은 라이브러리 쓰기

이런 문제를 더 깔끔하게 해결하고 싶다면,

React Query나 SWR 같은 데이터 관리 라이브러리를 추천드립니다.

• 같은 API를 여러 페이지에서 불러도 캐시에서 가져오기
• 새로고침 버튼을 눌렀을 때만 refetch 실행
• 상태/에러/로딩을 한 줄로 관리

저는 단순 조회 API는 React Query로 관리하고,

트랜잭션성(등록/삭제/승인) API만 직접 호출하도록 나누니 훨씬 편했습니다.

React Query / SWR이 해결해주는 방식

React Query와 SWR은 단순히 API 호출 라이브러리가 아니라, 데이터 캐싱 계층이에요.

이 캐싱 계층이 있으면 “같은 키(key)”로 요청이 들어올 때 다음과 같은 일이 일어납니다:

1. 디듀플리케이션(Deduplication)

   • 동일한 API 요청이 짧은 시간 안에 여러 번 발생하더라도,

     내부에서 “아 이건 같은 요청이네”라고 판단하고 한 번만 실제로 요청을 보냅니다.

   • 나머지는 캐시된 결과나 동일 Promise를 공유.

2. 캐싱(Cache)

   • 한 번 받아온 데이터를 캐시에 저장하고,

     동일한 키로 다시 조회하면 네트워크 요청 없이 즉시 캐시 데이터 반환.

   • refetch() 같은 명령을 내리면 그때만 새로 요청.

3. 상태 관리 자동화

   • 로딩(isLoading), 성공(data), 에러(error) 상태를 자동으로 관리해 줘서,

     개발자가 직접 loading state 만들고, try/catch 돌릴 필요가 없어져요.

구체적인 예시

// React Query 예시
const { data, isLoading, error } = useQuery(
  ['member', cpnId, userId], // 키
  () => getCpnMember({ cpnId, userId }) // API 호출
);

위 코드를 StrictMode 환경에서 두 번 실행한다고 가정해봅시다:

• 일반 fetch 사용: 요청 2번 → 서버에도 2번 요청

• React Query 사용: 요청은 2번 트리거되더라도,

  내부에서 동일 키(['member', 2, 2])로 관리 → 실제 네트워크는 1번만 발생

  두 번째 호출은 첫 번째 호출의 캐시/Promise를 재활용합니다.

SWR은 어떻게 다르냐?

SWR도 원리는 비슷한데, 차이점은 “자동 새로고침”과 “Stale-While-Revalidate” 전략이 강점이에요.

• React Query: 좀 더 완전한 데이터 관리 플랫폼 (mutate, optimistic update 등 풍부)
• SWR: 단순 조회 중심, 사용법이 직관적이고 lightweight

그래서 왜 좋은가?

개발 모드에서 StrictMode 때문에 네트워크 요청이 2번씩 찍히는 상황에서도:

• 일반 fetch → 서버에 실제로 2번 요청 감

• React Query / SWR → 서버엔 한 번만 요청 감

  (개발자 입장에서는 로그만 2번 찍히고, 실제 요청은 캐시가 막아줌)

게다가 캐시·상태 관리까지 자동이니,

“개발 모드라 로그가 번잡해도 실제 서버 트래픽은 안정적으로 1회”라는 안심을 줍니다.

👉 React Query / SWR은 StrictMode 환경에서 API 중복 호출을 막아주는 안전장치 + 상태 관리 자동화 기능을 제공하기 때문에, “로그가 두 번 찍히는 게 헷갈려요”라는 문제와 “불필요한 서버 트래픽” 문제를 동시에 해결해줍니다.

제가 얻은 교훈

1. 개발 모드에서 API가 두 번 호출되는 건 StrictMode의 정상 동작이다.
2. 배포 모드에서는 정상적으로 한 번만 호출되니 걱정할 필요 없다.
3. 불편하다면 useRef 가드로 중복 호출을 막을 수 있다.
4. 페이지 이동 시마다 조회 API를 다시 호출하는 구조는 필요에 따라 최적화해야 한다.
5. React Query / SWR 같은 라이브러리를 쓰면 중복 호출 문제를 훨씬 깔끔하게 관리할 수 있다.

저는 이 삽질을 통해, 이제는 API 로그가 두 번 찍혀도 당황하지 않습니다.

“아, StrictMode 때문이지~” 하고 바로 넘길 수 있게 되었죠. 😎

혹시 여러분도 비슷한 경험 있으신가요?

만약 API 로그가 두 번 찍힌다면, 이제 안심하셔도 됩니다.

여러분의 코드가 잘못된 게 아니라, React가 일부러 그런 거니까요!

Electron + Vite로 개발하면서 VM 환경에서 패키징을 하다 보면,

“같은 코드, 같은 설정인데 엔진이 안 열린다”는 이상한 상황을 겪는 경우가 있습니다.

처음에는 단순한 VM(가상머신) 속도 문제겠거니 하고 넘어갔지만,

문제는 하루이틀이 아니라 빌드할 때마다 가끔 꼭 나타난다는 점이었죠.

더 이상한 건, 아무것도 바꾸지 않고 다시 빌드하면 또 잘 된다는 것이었습니다.

이쯤 되면 운이 좋은 건지, 빌드가 장난을 치는 건지 알 수 없었습니다.

💡 빌드 산출물과 캐시의 숨겨진 함정

빌드를 하면 dist/, release/, build/ 같은 폴더에 실행 파일과 번들된 JS가 생성됩니다.

이게 바로 빌드 산출물입니다.

문제는 이 폴더에 남아 있는 예전 파일이 다음 빌드에 그대로 섞여 들어갈 수 있다는 점입니다.

여기에 캐시(Cache)까지 더해집니다.

Vite, Webpack, Next.js 등 빌드 도구들은 빌드를 빠르게 하기 위해 캐시를 사용합니다.

변경이 없는 파일은 다시 처리하지 않고 재활용하죠.

하지만 가끔 변경 감지를 놓치면, 오래된 결과물이 그대로 살아남아 버립니다.

캐시는 빌드 속도를 높이는 ‘부스터’이지만, 잘못 쓰이면 발목을 잡는 ‘지뢰’가 되기도 합니다.

🗂 빌드 도구별로 지워야 할 폴더

프로젝트마다 지워야 할 폴더가 다릅니다.

아래 표는 대표적인 빌드 환경에서 청소해야 할 캐시와 빌드 산출물 폴더입니다.

🧹 클린 빌드의 발견

이때부터 “클린 빌드(Clean Build)”라는 개념을 깊이 들여다봤습니다.

클린 빌드는 이전 빌드 산출물과 캐시를 완전히 지우고, 깨끗한 상태에서 새로 빌드하는 과정입니다.

문제의 근본 원인은 단순했습니다.

이전 빌드의 잔여 파일과 캐시가 새 빌드에 섞여 들어가면서

파일 누락, 변경 미반영 같은 기이한 현상을 만든 것이었습니다.

🛠 클린 빌드 실행 방법

수동 삭제

# macOS / Linux
rm -rf dist release out build .vite .webpack-cache node_modules/.cache

# Windows PowerShell
rd /s /q dist release out build .vite .webpack-cache node_modules\.cache

npm 스크립트 자동화

"scripts": {
  "clean": "rimraf dist release out build .vite .webpack-cache node_modules/.cache",
  "build": "npm run clean && electron-builder"
}

rimraf 설치:

npm i rimraf --save-dev

📦 Electron + 엔진 exe 포함 시 주의할 점

Electron 앱에서 엔진 실행 파일을 같이 배포하려면,

electron-builder의 extraResources에 정확한 경로를 지정해야 합니다.

"build": {
  "asar": true,
  "asarUnpack": [],
  "extraResources": [
    { "from": "electron/engine/bin/seph_engine.exe", "to": "public/seph_engine.exe" }
  ],
  "files": [
    "dist/**",
    "electron/**",
    "!**/*.map"
  ]
}

경로를 명확히 해주면 패키징 시 엔진 파일 누락을 방지할 수 있습니다.

🔄 CI/CD 환경에서의 클린 빌드

GitHub Actions, Jenkins, GitLab CI 같은 CI/CD 서버는 매번 깨끗한 환경에서 빌드하지만,

빌드 속도를 높이려고 캐시를 켜면 이 문제가 다시 생길 수 있습니다.

GitHub Actions 예시

steps:
  - name: Clean build
    run: rm -rf dist release .vite .webpack-cache node_modules/.cache
  - name: Install dependencies
    run: npm ci
  - name: Build
    run: npm run build

⚠️ VM 환경에서 자주 발생하는 변수

• I/O 속도 지연 → 파일 복사나 압축이 중간에 누락될 수 있음
• 스냅샷 복원 → 예전 빌드 결과물이 그대로 복귀
• 시간 동기화 문제 → 설치기가 파일 변경을 인식 못 함
• 백신 간섭 → 실행 파일을 격리 또는 삭제

🛡 엔진 실행 전 점검 코드

import fs from 'fs';
import path from 'path';
import { spawn } from 'child_process';

const enginePath = path.join(process.resourcesPath, 'app.asar.unpacked', 'public', 'seph_engine.exe');

function fileExists(p: string) {
  try { return fs.existsSync(p); } catch { return false; }
}

export function startEngine() {
  if (!fileExists(enginePath)) {
    throw new Error(`[Engine Missing] ${enginePath}`);
  }

  const proc = spawn(enginePath, [], { detached: true });
  proc.on('error', (err) => {
    console.error('[Engine Spawn Error]', err);
  });
}

✅ 빌드 실패 원인 체크리스트

• 이전 빌드 결과물을 삭제했는가?
• 캐시 폴더를 비웠는가?
• 앱 버전을 올렸는가?
• 엔진 exe 경로가 정확한가?
• 실행 권한이 있는가?
• 백신에서 차단하지 않았는가?

📍 마무리

클린 빌드는 특정 빌드 도구 전용 기능이 아니라, 모든 개발 환경에서 통하는 안전장치입니다.

캐시는 빌드 시간을 단축시키는 좋은 도구지만, 잘못 쓰이면 발목을 잡는 주범이 되죠.

특히 VM 환경에서는

클린 빌드 + 버전 증가 + 경로 고정

이 세 가지가 빌드 안정성의 핵심입니다.

저도 예전에는 “안 되면 한 번 더 빌드하지 뭐”라고 생각했지만,

이제는 처음부터 깨끗하게 빌드해서 한 번에 성공하는 습관을 들였습니다.

빌드 환경도 집처럼, 주기적인 대청소가 필요합니다.

프론트엔드 개발자라면 누구나 한 번쯤 console.log("확인")을 찍어본 경험이 있을 겁니다. 저도 그랬습니다.

디버깅의 든든한 친구, 언제 어디서나 호출하면 나타나는 log 친구.

하지만 Electron 프로젝트에선 이 친구가 성능 병목의 주범이 될 수도 있습니다.

💻 Electron 환경의 로그, 왜 특별한가요?

Electron은 두 개의 프로세스로 구성됩니다:

✅ 문제는 여기서 시작됩니다

이 둘은 로그를 찍는 방식도, 로그가 시스템에 미치는 영향도 다릅니다.

• Renderer 로그 (console.log)
  • 브라우저 콘솔처럼 작동
  • 많이 찍히면 렌더링 지연, 메모리 누수 가능
  • 개발자 도구를 통해 사용자가 직접 볼 수 있음
  • 무한 루프나 interval 로그가 많을 경우 UI에 영향
• Main 로그 (console.log)
  • Node.js의 stdout으로 출력
  • 로그가 많아지면 디스크 IO 병목, 프로세스 지연, 리소스 누수 가능
  • 특히 보안 솔루션이나 데몬처럼 작동하는 앱일수록, 안정성이 중요

결국, 단순히 “로그 좀 많네” 수준이 아니라 시스템 성능 저하, 사용자 불편, 심지어 보안 이슈로도 이어질 수 있는 구조입니다.

🚨 실전에서 겪은 문제

제가 참여한 보안 솔루션 기반 Electron 프로젝트에서는 다음과 같은 로그들이 지속적으로 발생했습니다:

• Named Pipe 통신 로깅
• 시스템 정보 수집 로그
• JSON 저장/파싱 로깅
• 보안 상태 체크 및 사용자 행동 로그

초당 수십 개의 로그가 찍히다 보니:

• 렌더러 메모리가 지속적으로 증가하거나
• CPU 사용량이 6~8% 이상 고정되거나
• 통신이 비동기적으로 지연되거나
• 개발자 도구를 비활성화했음에도 내부 자원 누수 발생

이런 증상이 실제로 있었습니다.

😅 안일했던 생각: "어차피 배포용은 devtool 막았잖아?"

Electron에선 개발자 도구를 막을 수 있으니, log가 사용자에게 노출되지 않는다고 생각했습니다.

그래서 귀찮아서 수백 줄의 console.log를 안 지웠습니다. 😔

하지만…

console.log("✅ 요청 성공", response);
console.log("📍 현재 상태", status);
console.log("🚨 예외 발생", error)

이런 로그가 계속 쌓이면, 렌더링 지연, 메모리 누수, 디스크 I/O 부하로 이어지는 걸 실제로 경험했습니다.

🦸 구원자 등장 — vite-plugin-remove-console

수동으로 일일이 삭제하는 건 너무 비효율적이었고, 구글링 도중 발견한 라이브러리가 바로 이 구원자입니다.

📦 설치 및 설정

npm i vite-plugin-remove-console -D

// vite.config.ts
import removeConsole from 'vite-plugin-remove-console';

export default defineConfig({
  plugins: [
    react(),
    removeConsole({
      include: ['**/*.ts', '**/*.tsx'],
    }),
  ],
});

✅ 효과

• console.log, console.debug, console.info → 빌드시 자동 제거
• 개발 모드에서는 기존 코드 그대로 유지
• 실수로 배포에 디버깅 로그가 포함될 위험 방지
• Renderer 성능 저하 예방 (특히 많은 로그를 찍는 페이지에서 효과 큼)

+ 관련 라이브러리 비교

✅ 하지만 로그는 필요합니다 — electron-log

Renderer에서는 console.log를 지우지만, Main Process에서는 로그를 반드시 남겨야 합니다.

왜냐고요? Electron 앱의 핵심 기능은 대부분 Main에서 처리되기 때문입니다.

제가 맡은 프로젝트만 해도:

• Named Pipe를 통한 보안 엔진 통신
• 시스템 정보를 수집하고 상태를 기록하는 모니터링 루프
• 정책 초기화, 설정 로딩, 사용자 상태 갱신 등

모든 주요 흐름은 Main에서 일어납니다.

이때 오류가 발생하거나 예상치 못한 상황이 생기면 반드시 로그가 남아 있어야 디버깅이 가능하죠.

그래서 저는 Main에서는 console.log 대신 electron-log를 사용하고 있습니다.

💾 electron-log 기본 사용법

// main.ts
import log from 'electron-log';

log.info("📡 엔진 초기화 시작");
log.warn("⚠️ 중요한 설정 누락됨");
log.error("❌ 오류 발생", error);

🔍 Main 로그를 electron-log로 남기는 이유~!

📂 로그 경로는 여기에 파일로 저장됩니다.

🆚 로그 전략 비교 요약

🏁 결론: 로그도 설계 대상입니다

console.log는 디버깅에 아주 유용하지만, Electron처럼 리소스와 I/O에 민감한 환경에서는 설계 대상이 됩니다.

🧠 로그를 지우는 것이 중요한 게 아니라,

"어떤 로그를 언제, 어디에, 어떻게 남길 것인가" 가 중요합니다.

💬 마무리하며

Electron 기반 앱에서의 로그는 단순한 디버깅 도구가 아니라,

운영 효율성과 사용자 경험을 좌우하는 요소가 됩니다.

지우지 않아도 되는 콘솔 로그?

어쩌면, 그게 병목의 시작일 수 있습니다.

저처럼 "귀찮아서 로그 안 지웠던 그때"의 저를 반성하며…

지금은 자동화된 안전한 로그 전략으로 한층 더 성장한 기분입니다.

정신없이 달리다 보니 벌써 2025년 반이 지나갔네요.

지난 6개월은 정말 제 커리어에서 다이내믹하고 가장 진심이 담긴 시기였어요.

• 처음으로 프로젝트를 리딩했고,

• 처음으로 데스크탑 앱을 만들었고,

• 처음으로 스스로 부족함을 느끼며 공부하고 기록했죠.

그럼, 진심 가득 담아 제 상반기 회고를 써 내려가 볼게요.

🧶 1월 — "생각하는 개발자"로 다시 태어난 순간들

작년 11월 중순, 저는 첫 개발 회사를 퇴사를 선택했습니다.

뭔가 막연한 두려움도 있었고,

“앞으로 뭘 하지?” 하는 허탈함도 있었지만, 마음 한구석에선 뚜렷한 갈망이 있었습니다.

“제대로, 성장하고 싶다.”

그렇게 시작한 게 코드잇 단기심화 6기였어요.

“단기”라는 말이 붙었지만, 그 6주는 제겐 커리어 전체를 재정비하는 6주였습니다.

FitMon 프로젝트 — 실력은 여기서 자라납니다

그 첫 시작은 팀 프로젝트 FitMon이었습니다.

“운동 + 모임 + 일정관리”를 연결하는 헬스케어 웹앱이었고,

그런데 단순히 구현만 하는 게 아니라,

진짜 전반적인 프론트 구조를 갈아엎는 경험을 했어요.

• 역할 기반 → 기능 기반 폴더 구조 전환
• API 응답 객체 기준 설계
• UX 흐름을 고려한 폼 컴포넌트 재사용
• Lighthouse 퍼포먼스 최적화
• eslint/prettier 통일
• 테스트 코드 작성

그리고 무엇보다 처음으로 멘토링을 받았습니다.

멘토님의 피드백은 솔직히 말하면... 좀 무섭기도 했어요.

“이런 구조는 유지보수가 어렵겠죠?”,

“이 부분, 왜 이렇게 작성했는지 설명해보세요.”

그런데 그 무서움 속에서 제가 진짜 성장하고 있다는 걸 느낄 수 있었어요.

'질문이 두려웠지만, 성장하고 있었다'

처음엔 질문하는 것도 어려웠습니다.

"이거 너무 기본적인 질문 아닌가?"

"내가 왜 이걸 모르지?"

이런 생각이 수시로 들었거든요.

그런데 용기 내서 질문하고,

피드백을 기록하고 적용하는 걸 반복하다 보니

정말 시야가 넓어졌습니다.

“기능 구현을 넘어, 생각하는 개발자가 되어간다.”

이걸 처음으로 체감한 순간들이었어요.

그리고... 시간은 남고, 리팩토링은 시작되었다

사실 저희 프로젝트는 꽤 일찍 완성됐습니다.

그래서 남은 기간엔 오롯이 리팩토링과 구조 개선에 집중할 수 있었어요.

코드의 응집도를 높이고,

비즈니스 로직과 UI 분리를 연습하고,

컴포넌트 재사용과 분리 기준도 고민했죠.

또한

정말 좋은 동료 개발자 친구들을 만난 것도 큰 수확이었습니다.

서로 코드리뷰하고, 에러 공유하고,

밤 늦게까지 디버깅하며 생긴 유대감은 아직도 기억에 남아요.

이때의 회고는 여기 👉

FitMon 프로젝트 및 코드잇 단기심화 회고

🚀 2월 — 발표, 입사, 해커톤, 진짜 미쳤던 한 달

1월의 고요하고 밀도 높은 성장기가 끝나자,

2월은 정말 말 그대로 폭풍처럼 몰아쳤습니다.

FitMon 발표 — 준비는 마쳤고, 자랑할 시간

2월 초엔 FitMon 프로젝트의 발표와 정리 과정을 마무리했습니다.

그동안 정리한 구조와 코드, 성능 최적화 포인트들을

발표 자료로 만들고 정리하면서

“아, 이 프로젝트는 정말 자랑할 수 있겠다”는 자신감이 생겼어요.

프로젝트를 남에게 설명할 수 있다는 건

그걸 충분히 이해했다는 뜻이잖아요?

그게 제겐 작지만 확실한 자존감 회복이었어요.

2월 17일, 첫 출근 — 이제부터는 진짜 실전이다

그리고 드디어 2월 17일,

보안 솔루션 회사에 첫 출근을 했습니다.

사실 입사 전까지만 해도

“내가 괜찮은 회사에 가는 게 맞을까?”

“기술적으로 도태되진 않았을까?”

이런 고민들이 있었지만,

첫 출근날 느꼈어요.

“아, 여기서도 나는 계속 배울 수 있겠구나.”

Electron 기반의 프로젝트,

보안 도메인이라는 낯선 분야,

내가 해보지 않은 구조들…

“할 게 너무 많다 = 재밌겠다.”

그게 제 첫 느낌이었습니다.

그런데 동시에... 엘리스 해커톤도 붙어버렸다

네… 맞아요…

이 타이밍에 엘리스 AI Spark Camp 해커톤도 붙어버렸습니다 😅

주제는 생성형 AI였고,

제가 제안한 아이디어인

“블로그 URL만 넣으면 영상 자동 생성”이 채택됐습니다.

그래서 퇴근하고 밤 11시까지는

AI 프로젝트를 개발,

주말엔 팀 회의와 테스트,

출근하면 보안 솔루션 개발…

숨 쉴 틈이 없었습니다.

그런데 이상하죠?

힘든데도 불구하고,

정말 너무 재밌었습니다.

최우수상, 그리고 자동화의 맛

그 프로젝트에서

저는 처음으로 Vercel, GitHub Actions를 연동해서

자동화 배포를 경험했고,

프롬프트 기반 영상 API 설계에도 참여하면서

AI와 프론트의 만남을 직접 체험할 수 있었습니다.

리팩토링을 못 한 건 아쉽지만,

그래도 최우수상이라는 결과로 마무리되면서

“이 미친 일정, 정말 보람 있었구나” 싶었어요.

AI Spark Camp 해커톤 회고 보기 엘리스 AI-Spark-Camp 해커톤 회고록

요약하면…

2월은 한 마디로 정리하면 이랬습니다.

“정신은 없었지만, 진짜 내가 살아있다는 느낌이 났다.”

코드잇에서 쌓은 자신감으로 현업에 뛰어들었고,

퇴근 후에는 창의성과 열정을 쏟아부었고,

그 와중에 좋은 동료와 멘토를 만나며 성장했습니다.

💻 3월 — Electron 입문과 현실 기획, 그리고 “이게 진짜 개발자의 일인가요…?”

3월은 제게 있어

“이게 실무구나”를 처음으로 체감한 한 달이었습니다.

그 전 직장은 체계나 이런것들이 부족해서 몰랐거든요. 이번 회사에서Electron 프로젝트에 본격 투입된 건 좋았는데,

그 안에서 제가 맡게 된 일은 단순한 기능 개발이 아니었어요.

Next.js 미지원? 라우팅 직접 구성하세요~

Electron을 처음 접했을 땐

“오 신기하다, 데스크탑 앱이야!” 하며 설렜지만

금방 현실이 저를 때렸습니다.

“Electron은 Next.js 안 돼요.”

😇 …?

라우팅 자동화도 없고,

스크롤 위치도 수동으로 초기화해야 하고,

상태 공유도 직접 구성해야 했습니다.

그래서 라우터는 react-router-dom으로 구성하고,

레이아웃도 직접 갈라야 했고,

페이지마다 사이드바 유무, 알림 유무, 접근 권한 여부 등을 직접 조건부로 걸어야 했죠.

진짜 귀찮았지만,

그래도 “이게 프론트엔드 기본기다”라고 생각하면서 배워나갔습니다.

근데 그보다 더 힘들었던 건… 문서였습니다

이때부터 제가 처음으로 실무 문서를 직접 작성하게 됐습니다.

그냥 요구사항 적는 수준이 아니라

진짜 ‘기획자처럼’ 정리하는 문서들이었어요.

• 사용자 정의서:

  이 기능은 누가 언제 어떤 조건에서 사용할 수 있는지,

  경고 메시지는 어떻게 뜨는지, 동작 흐름은 어떻게 되는지를 하나하나 정리

• 사용자 인터페이스 설계서 (UI 설계서):

  버튼 하나, 드롭다운 하나의 상태 변화까지 전부 작성.

  빈 화면일 때는 어떻게 표시되는지, 경고 배너는 언제 나타나는지 등

• 메뉴 구조 리스트:

  전체 앱의 좌측 사이드바 구조를 트리 형태로 정리하고,

  접근 권한별로 보이는/안 보이는 메뉴 구분

• 알림 정의서:

  어떤 이벤트에 어떤 메시지가, 어떤 타이밍에 어떤 위치에서 떠야 하는지를 일일이 명시

• 프로그램 명세서:

  어떤 파일이 어떤 기능을 담당하고,

  내부 API 호출 흐름은 어떻게 되며,

  로그는 어디에 저장되는지까지 다 작성

처음에는 진짜 멘붕이었습니다.

“개발자가 코드를 안 짜고 왜 이런 걸 쓰고 있지…?”

그런데 문서를 쓰면서 시야가 확장됐다

하지만 이상하게도

하루 이틀 쓰다 보니 어느 순간 느꼈습니다.

“이 문서들 덕분에 내가 지금 프로젝트 전체를 이해하고 있구나.”

단순히 기능을 ‘어떻게’ 구현하는지를 넘어서,

왜 이 기능이 필요한지,

어떤 예외 케이스를 고려해야 하는지,

내가 만든 코드가 누구에게 어떤 영향을 주는지를

정확히 고민하게 되었어요.

그리고 이런 문서들이 QA, 백엔드, 다른 개발자들과의 소통을 위한 진짜 도구라는 걸 처음으로 깨달았습니다.

“내가 코드만 잘 짜면 되는 줄 알았는데…”

이전까지는 솔직히

코드만 잘 짜면 된다고 생각했어요.

근데 3월을 지나고 나니까

코드는 말의 일부일 뿐이라는 걸 체감했어요.

• 문서를 통해 스펙을 설계하고
• 회의를 통해 기획을 조율하고
• 기록을 통해 협업을 유지하고
• 구현을 통해 책임을 완성하는 것

이게 진짜 실무 개발자의 흐름이라는 걸요.

주말엔 나만의 Electron 공부 시간

그래서 주중엔 문서, 회의, 조율…

그리고 주말엔 나만의 개발 시간이었습니다.

• main.ts, preload.ts의 구조
• contextBridge 통한 IPC API 연결
• 트레이 아이콘 추가
• 자동 실행 등록
• .exe로 배포하는 과정까지

주말마다 하나씩 실험하면서

진짜 “내가 데스크탑 앱을 만들고 있다”는 자각이 들었어요.

솔직히 꽤 짜릿했습니다. 😎

요약하자면...

3월은 “개발자는 코딩만 하지 않는다”는 걸,

그리고 “문서도 코드다”라는 걸

몸으로 배운 한 달이었습니다.

덕분에 이제는 문서 작성에도 자신감이 생겼고,

사람들과 기능을 논의할 때

기획-개발-디자인-사용자 전반을 고려하는 시야가 생겼습니다. 사실 이때 사람들이 개발 할 시간 없다 없다 하는걸 이해했습니다. 하하…

🏫 4월 — 9년 차 용역 개발자를 리딩하다니, 내가 이걸 진짜 해내네?

4월의 키워드는 단연 ‘용역관리’였습니다.

그냥 개발자 역할을 수행하던 제가,

처음으로 누군가를 관리하고 리딩하는 입장이 된 거죠.

게다가 상대는... 무려 9년 차 개발자였습니다. 😳

“제가 이걸 맡아야 하나요…?”

솔직히 처음엔 너무 부담스러웠어요.

“내가 잘못된 피드백을 주면 어쩌지?”

“말투가 날카로워 보이면 실례 아닐까?”

이런 생각이 머릿속에서 빙글빙글 돌았습니다.

하지만 시간이 지날수록 점점 명확해졌어요.

• 개발 연차와 실무 감각은 별개다
• 기술적으로 리딩이 필요한 건 사실이다
• 그리고 지금 내가 이끌지 않으면 프로젝트가 안 굴러간다

그래서 저는 용기를 내기로 했고,

문서 하나하나 작성하면서

전체 흐름을 정리하고,

할 일들을 일간/주간 단위로 쪼개서 공유하고,

그분께 코드 리뷰도 조심스럽게 요청하기 시작했어요.

물론 처음엔 어색했지만,

그분이 정말 너무 착하고 열린 분이라서 다행히 잘 풀려나갔어요.

기술보다 더 어려운 것: 사람과의 거리

이 일을 하면서 깨달은 건

“리딩은 기술보다 소통이 훨씬 어렵다”는 점이었어요.

실제로 제가 코드를 손대는 시간보다,

할 일을 정의하고, 맞는 방향으로 유도하고, 감정을 조율하는 시간이 더 많았거든요.

특히 제가 맡은 프로젝트는 단순한 페이지 개발이 아니라,

보안 정책과 시스템 흐름, 관리 기능을 통합한 중간 규모 프로젝트였기 때문에

이해관계자도 많고, 논의도 복잡했어요.

그래서 문서를 정리하고, 일정표를 공유하고, 회의록을 남기는 게 무기가 되었죠.

“1년 차 같지 않다”는 말

그러다 어느 날,

그 용역분께서 이런 말씀을 해주셨어요.

“사실 연지님 1년 차라고 하셔서 놀랐어요. 진짜 그렇게 안 느껴져요.”

그 말을 듣고

살짝 눈물날 뻔했습니다. (진짜로요...)

도태되지 말자, 스스로 다짐하다

하지만 동시에

그분을 보면서 느낀 것도 있어요.

9년 차임에도

최근 트렌드나 기술 스택에 익숙하지 못한 모습에서,

“기술적으로 도태되면 안 된다”는 공포를 느꼈어요.

정말 죄송한 말이지만,

그게 저에겐 강한 자극이 되었습니다.

“착하기만 해선 안 된다. 능력이 있어야 한다.”

이 문장이 마음속에 박혀서

저는 이달부터 더더욱 공부하고 기록하기 시작했어요.

🧪 5월 — 단위 테스트의 철학, 그리고 커리어 코칭

5월은 제 커리어에서 가장 빡세고 가장 큰 교훈을 준 시기였습니다.

요약하자면,

“원래 용역분이 맡았던 프로젝트를, 결국 다시 제가 도맡게 되었습니다.”

정확히 말하면…

원래도 제가 80%는 다 하고 있었어요.

하지만 보안 정책 처리, 문서화, QA 체크 등

“이건 용역분 몫”이었던 부분이 완성되지 못한 채 남게 됐고

결국 마지막까지 책임지고 다 해야 했던 겁니다.

SI 방식의 민낯

이 시점에서 저는 처음으로

SI 개발 방식의 현실적인 문제를 체감했습니다.

• 단위 테스트? 거의 없음.
• 스펙 문서? 중간에 바뀌고 말로 전달됨.
• 기획자 피드백? 말로 말하고 말로 잊혀짐.
• API 연결? 통합 테스트 하나로 퉁치기.

처음엔 “이런 게 원래 그런가 보다” 했지만,

문제가 쌓이고 쌓이니까

점점 시스템이 무너지고, 버그가 뻥뻥 터졌어요.

그걸 다 조용히 뒷정리하고 있는 저 자신을 보면서

진심으로 빡쳤습니다 😇 (진심)

단위 테스트의 철학: mock부터 써라

그때 대표님께서 해주신 말씀이 있어요.

“단위 테스트는 개발자의 철학이다.

mock 없이 API에 의존하는 테스트는, 개발자가 자신도 못 믿는다는 뜻이다.”

이 말을 듣고, 진짜 머리를 한 대 맞은 기분이었어요.

그래서 저는 테스트 철학을 갈아엎었습니다.

✅ 목데이터로 구성해서 유닛 단위로 동작 검증

✅ 통합 테스트는 이후 단계

✅ API 실패/성공/지연 등 상태를 미리 상상하고 대응

✅ 테스트를 코드 설계의 일부로 받아들이기

이후부턴 제 코드에 자부심이 조금씩 생기기 시작했어요.

그리고... 다시 마무리

결국, 그 용역분과의 협업은 종료됐고

모든 QA 대응과 마무리는 제 몫이 되었습니다.

완벽하진 않았지만,

이 경험은 제가 리딩부터 기획, 설계, 테스트, 배포까지

진짜로 ‘혼자서 다 해봤다’는 자신감을 심어줬어요.

그리고 느꼈습니다.

“이제 나는 진짜 개발자다.”

“이젠 누구의 보조가 아닌, 내가 중심인 프로젝트를 만들어가고 있다.”

동시에, 커리어 프로그램도 병행했습니다

이 바쁜 와중에도,

코드잇 커리어 프로그램을 병행하고 있었어요.

이력서 피드백 — 정호영 멘토님의 현실적 조언

저는 이 과정에서

카카오웹툰 프론트엔드 개발자 정호영님께

이력서 피드백을 받았습니다.

정말 꼼꼼하고 직설적인 피드백이 인상 깊었고,

제가 간과했던 부분들 — 예를 들어

“이건 구현은 했지만 결과만 적혀 있고, 과정이 없어요”

“협업 경험이라 쓰셨지만, 구체적인 협업 방식이 빠져 있어요”

같은 부분을 정확히 짚어주셨어요.

덕분에 이력서를 기술 중심 → 문제 해결 중심으로 고쳐 쓰게 되었고,

‘내가 무엇을 했는가’보다 ‘왜, 어떻게 했는가’를 쓰는 게 더 중요하구나를 처음 체감했습니다.

모의 면접 — 다른 멘토님과 진행한 현실 점검의 시간

이후에 진행된 모의 면접은

다른 프론트엔드 멘토님과 진행됐습니다.

그리고 이 시간이 제겐... 꽤 충격이었어요.

질문을 받을 땐 아는 것 같았는데,

막상 말하려니 단어가 안 나오고, 정리가 안 되더라구요.

“나는 기능은 만들 줄 아는데,

원리를 설명할 수는 없구나.”

“기초 개념이 튼튼하지 않으면, 결국 무너질 수밖에 없겠다.”

이걸 뼈저리게 느꼈습니다.

지금도 시간을 쪼개서 하나씩 정리하고 있어요.

그리고... 토스 광탈

그렇게 코칭을 받으면서

“그래도 이참에 도전해보자!” 하고

토스에 이력서를 넣어봤습니다.

결과는요...

광탈이었습니다. 😇

근데 웃긴 건,

이번엔 진짜 괜찮았어요.

왜냐면 그 전까지는

“떨어지면 내 커리어가 끝난 것 같고,

나는 못난 사람인가?” 같은 감정이 컸는데

이번엔 그냥

"내가 아직 준비 안 됐으니까 그렇지. 괜찮아, 다시 채우면 돼.” 이렇게 생각이 들더라고요.

정리하자면…

“5월은 기술적으로도, 정신적으로도

내가 진짜 성장을 시작한 시점이었다.”

• 용역 프로젝트에서 실제 리딩과 마무리를 경험했고
• 커리어 코칭을 통해 나의 얕음, 조급함, 욕심을 정면으로 마주했고
• 테스트와 협업 방식, 개발자 마인드셋이 크게 성장했습니다.

이때 느낀 감정, 배움은

그 어떤 포트폴리오보다 제 성장의 증거가 되었어요.

🌀 6월 — 스카웃, 제안, 유혹… 그리고 “지금 이 자리를 지킨다는 것”

6월은 뭔가 특별하게도,

많은 제안이 한꺼번에 쏟아진 시기였습니다.

먼저,

예전에 함께 일했던 전 직장 상사에게 연락이 왔어요.

“연지씨, 다시 같이 일해볼 생각 없어요?”

갑작스러운 연락에 놀라기도 했지만,

한편으로는 제가 회사에서의 실력과 태도를 좋게 봐주셨다는 뜻 같아서 감사했습니다.

그 뒤로는 진짜 정신없었어요.

서울에서의 헤드헌터 연락,

클래스101에서 강의 제의,

타 회사에서 '연봉 800만 원 더 얹어줄게요'라는 파격 제안까지.

800이라는 숫자,

솔직히 흔들렸어요.

연봉은 곧 제 가치처럼 느껴졌거든요.

“내가 이만큼 받아도 되나?” “받을 자격이 있을까?”

하지만 곰곰이 생각해봤어요.

지금 떠나면, 내가 배울 수 있는 것들을 놓치는 건 아닐까?

지금 회사에선

• Electron이라는 새로운 도전
• 엔진, 파이프, IPC라는 시스템 레벨의 경험
• 보안 도메인의 실무 지식
• 좋은 동료들

이 모든 걸 함께하고 있는데

너무 짧은 시간에 옮겨버리면, 이 소중한 것들을 제대로 흡수하지 못한 채 떠나는 건 아닐까?

그런 마음이 들었어요.

한편으로는 나를 다시 찾아주는 사람도 있고,

기회를 주는 곳도 있다는 것이

“나, 나름 잘해왔구나” 싶은 작은 위로가 되기도 했습니다.

그동안 해왔던 선택이 틀리지 않았다는 걸,

조금은 증명받은 기분이랄까요.

지금 제 일상이 비록 힘들고 녹초가 될 때도 있지만,

저는 여전히 재미있고, 배우고 있다는 걸 부정할 수 없었어요.

그래서 저는

제안들을 전부 정중하게 거절했습니다.

그리고 그 결정이

지금도 마음에 남습니다.

“잘했다”고 말해줄 수 있는 선택이었다고 생각해요.

🧠 총정리 — 나는 부족하고, 욕심 많고, 그래서 성장한다

상반기를 다 돌아보고 나니 머릿속에 제일 많이 남는 감정은 이겁니다.

“나는 부족하고, 욕심이 많고, 그래서 계속 성장하고 싶다.”

저는 여전히

• 서울로 가야 할까 고민하고,
• 좋은 회사에 가고 싶어 하면서도,
• 대전을 떠나기 싫어하고,
• 커리어도, 인간관계도, 사랑도, 다 지키고 싶어하는...

끝도 없이 고민하는 사람입니다.

누구는 “하나만 선택하라”고 하지만

저는 여전히 모든 걸 욕심내는 사람이고

그 욕심 때문에 저는 움직이게 되고, 계속 배우게 되고, 결국에는 성장하게 된다고 믿어요.

그리고 드디어 알게 된 사실 하나.

“선택은 무섭지만, 아무것도 안 하는 건 더 무섭다.”

그래서 이제는

미뤄왔던 개념 공부를 다시 시작하려고 해요.

어설픈 포트폴리오도 정리하고, 사이드 프로젝트도 하나하나 다시 점검하고,

언젠가 꼭 가고 싶었던 회사들을 향해 하나씩 도전하려고 해요.

그리고 한 가지 더.

개발자를 꿈꾼 지 벌써 3년,

개발자로 실제로 일을 한 지는 1년을 조금 넘은 지금,

한 가지 분명하게 말할 수 있는 게 있어요.

요즘 세상은 AI가 개발자를 없앨 거라고 말하곤 합니다.

그리고 저도 그 얘기를 들을 때마다 두려워요. 정말로요.

하지만 그럼에도 불구하고

저는 여전히 ‘개발’이라는 일이 좋습니다.

코드를 짜서 무언가가 제 손으로 완성될 때마다,

머릿속에서 도파민이, 심장에서 옥시토신이 뿜뿜합니다.

그 짜릿한 이쾌감을 저는

앞으로도 내 힘이 닿는 데까지 계속 느끼고 싶어요.

AI가 개발자를 대체한다는 말, 이제는 익숙하죠. 저도 두려워요.

하지만 두려움에 가만히 있을 수는 없잖아요.

그래서 저는 AI를 두려워하기보다, 활용할 줄 아는 개발자가 되고 싶습니다.

주판에서 계산기로, 수기에서 엑셀로 넘어갔듯

AI도 결국엔 “도구”일 뿐이고,

도구는 잘 쓰는 사람이 이깁니다.

처음 주판에서 계산기로, 수기에서 엑셀로 넘어갔듯

AI도 결국엔 “도구”일 뿐이니까요.

잡아먹히지 않기 위해선

계속 배우고, 변화에 반응하고, 스스로를 계속 단련해야 한다는 것도 알게 됐어요.

그래서 저는 지금도 계속 배우고 있어요.

이 직업, 끝없이 공부해야 하는 게 피곤할 때도 있지만

그만큼 계속 새롭고, 계속 재밌습니다.

그래서 저는요, 다 지키는 욕심쟁이가 되고 싶습니다.

개발도 놓치고 싶지 않고,

내 사람들도 놓치고 싶지 않고,

좋은 커리어도 가지고 싶고,

내 삶도 지키고 싶어요.

겁도 나고, 욕심도 많고,

그래도 저는 계속 배우고 걸어가는 사람이고 싶습니다.

잡아먹히지 않기 위해,

계속 배우고, 계속 실험하고, 계속 도전할 거예요. 올 하반기에도 한 발짝씩 묵묵히 걸어가 볼 생각입니다.

🎬 진짜 마무리

2025년 상반기,

저는 무수히 많은 처음을 겪었습니다.

• 처음으로 데스크탑 앱을 만들고
• 처음으로 9년 차 개발자를 리딩하고
• 처음으로 모든 프로젝트를 내 손으로 마무리하고
• 처음으로 나의 부족함을 명확히 인지하고
• 처음으로 커리어 코칭을 받으며 벽을 느끼고
• 그리고 처음으로 정말 많은 제안을 “거절”했습니다.

이 모든 걸 통해

저는 단단해졌고, 더 넓어졌고, 더 겸손해졌습니다.

누군가는 이 글을 보며 이렇게 말할 수도 있어요.

“그렇게 열심히 했는데, 아직도 이직 못했어?”

“대기업 못 갔어?”

그럴 수 있죠. 하지만 저는 말하고 싶어요.

“저는 천천히 그렇지만, 꾸준히 자랄 거에요.”

하반기엔 더더욱 발전해서

언젠가 다음의 회고록은

“내가 꿈꾸던 곳에 도착했다.”

그런 이야기로 마무리할 수 있기를 바랍니다.

읽어주셔서 진심으로 감사합니다.

이 긴 회고록이 누군가에겐 위로이자, 자극이 되었길 바라며

하반기에도 다시 찾아뵐게요 :)

“이 작업, 잘못 붙였다간 블루스크린(BSOD) 뜨는 거 아닌가요?”

실제로 커널 단 작업은 단 하나의 실수만으로도 시스템이 멈추거나 부팅이 불가능해질 수 있습니다. 그렇기 때문에 많은 개발자들이 가상머신(Virtual Machine, VM)을 사용하여 테스트를 진행합니다.

제 메인 PC가 무너지면 저의 하루는 끝이기 때문입니다.

🤔 가상머신을 사용해야 하는 이유

제가 진행하는 작업은 운영체제 깊숙한 곳, 즉 커널 레벨까지 접근하는 작업입니다.

예를 들어 드라이버를 설치하거나, 보안 소프트웨어처럼 시스템 콜을 가로채는 코드들은 예외 처리 한 줄이 누락되면 블루스크린이 발생할 수 있습니다.

• 테스트 서명(bcdedit)을 잘못 켜거나 끄면 부팅 불가
• 드라이버 서명 인증에 실패하면 OS가 실행되지 않음
• 예외 없는 후킹 코드 테스트 시 전체 시스템이 중단

이러한 위험을 안전하게 분리된 공간에서 테스트할 수 있는 유일한 방법이 가상머신을 사용하는 것입니다.

🧾 주요 가상머신 종류 및 장단점 비교

🛠 저는 VMware Workstation을 선택했습니다

제가 VMware를 선택한 이유는 다음과 같습니다.

• Windows 커널 드라이버 테스트를 안전하게 진행할 수 있습니다.
• 스냅샷 기능을 통해 커널 변경 전 상태로 되돌릴 수 있어 실수 복구가 쉽습니다.
• USB 디바이스 테스트가 필요했는데, VMware의 USB passthrough 안정성이 매우 뛰어났습니다.
• 무엇보다 UI가 직관적이어서 복잡한 설정 없이 가상머신을 구성할 수 있었습니다.

💻 VMware Workstation 설치 및 설정 방법

1. VMware 설치 파일 다운로드

• 공식 웹사이트: https://www.vmware.com
• “VMware Workstation Pro” 또는 비상업용 무료인 “Player” 중 선택하였습니다.

2. 설치

• 다운로드한 .exe 파일을 실행하여 기본값으로 설치하였습니다.
• 설치 후에는 시스템 재부팅을 한 번 진행하였습니다.

3. 가상머신 생성

• VMware를 실행한 뒤, “Create New Virtual Machine”을 클릭하였습니다.
• Typical 모드를 선택하였으며, 테스트용으로 Windows 10 ISO 이미지를 지정하였습니다.

4. 가상 디스크 및 저장 위치 설정

• 가상머신 이름은 DriverTest_VM으로 지정하였고, 저장 위치는 SSD 드라이브로 설정하였습니다.
• 디스크 용량은 60GB로 설정하였으며, 성능을 고려하여 “단일 파일로 저장” 옵션을 선택하였습니다.

5. 하드웨어 커스터마이징

• CPU는 2코어 이상, 메모리는 4GB 이상 할당하였습니다.
• USB 장치 연결을 위해 USB 컨트롤러를 활성화하였고, 네트워크는 NAT로 설정하였습니다.
• 디버깅 중 발생할 수 있는 충돌을 방지하기 위해 3D 가속 기능은 비활성화하였습니다.

6. 운영체제 설치

• ISO 이미지를 통해 부팅 후 일반적인 Windows 설치 과정을 진행하였습니다.
• 설치 후 관리자 권한 계정으로 로그인하여 환경을 구성하였습니다.

🔐 커널 테스트를 위한 사전 준비

• bcdedit /set testsigning on 명령어로 테스트 서명 모드를 활성화하였습니다.

  이 명령은 테스트용 드라이버를 설치하거나 커널 레벨 코드를 실행할 수 있게 해줍니다.

  ⚠️ 명령 실행 후에는 가상머신을 재부팅해야 적용됩니다. (실제 PC는 절대 재부팅 금지!)

• Windows Defender와 기타 실시간 보안 프로그램은 임시로 비활성화하였습니다.

  커널 접근 시 과도한 보안 검사로 인한 충돌을 방지하기 위함입니다.

• 시스템 설정 직전에는 반드시 스냅샷을 생성하여 복구 지점을 확보하였습니다.

  문제가 발생할 경우 몇 초 만에 초기 상태로 복구할 수 있도록 준비해두는 것이 중요합니다.

✅ 마무리하며

가상머신은 단순히 보조적인 개발 도구가 아닙니다.

실수해도 안전하게 복구할 수 있는 실험실이자, 시스템 개발의 생명선입니다.

특히 커널 단 드라이버를 테스트하거나, 시스템 레벨에서 작동하는 후킹 또는 보안 코드를 개발하실 때는 반드시 가상머신에서 진행하시는 것을 추천드립니다.

그중에서도 VMware Workstation은 안정성, 편의성, 확장성 면에서 강력한 선택지였습니다.

Electron 앱을 개발하다가 .env 파일로 API 주소 같은 환경변수를 넣고 싶어서 이렇게 작성했어요.

// main.ts
import * as dotenv from 'dotenv';
dotenv.config();

console.log(process.env.VITE_API_BASE_URL1); // ❌ undefined

Node 환경에서 이 방식은 너무 당연하잖아요?

그런데 Electron에서는… 왜 이게 안 될까요?

❓ Electron 메인은 Node 환경 아닌가요?

Electron의 메인 프로세스(Main Process)는 실제로 Node.js 런타임 위에서 실행됩니다.

fs, child_process, path 같은 Node 내장 모듈도 자유롭게 사용할 수 있고,

console.log(process.platform)도 잘 찍혀요.

그래서 대부분의 개발자(저 포함)는 이렇게 생각합니다:

“Node 환경이니까 .env + dotenv + process.env 조합이면 당연히 환경변수 잘 들어오겠지!”

이 생각, 틀린 건 아니에요. Electron은 분명 Node 기반이니까요.

그런데 여기서 하나 간과한 게 있었습니다.

🧩 바로 "Vite를 쓰고 있다는 점"

Electron 프로젝트를 만들 때 Vite를 사용하는 경우가 많습니다.

렌더링 속도 빠르고, 설정 간단하고, React 기반 UI까지 바로 통합되니까요.

그런데…

⚠️ Vite는 단순 실행기가 아니라 정적 빌드 도구입니다.

즉, 우리가 작성한 코드를 실행하는 게 아니라,

미리 빌드해서 정적인 결과물로 만들어주는 도구라는 점입니다.

이건 메인 프로세스(main.ts)도 예외가 아닙니다.

우리가 Vite로 메인도 같이 번들링하면,

그 순간부터는 Node 런타임에 의한 실행이 아니라

Vite가 만들어낸 JS 결과물의 실행이 되는 거예요.

🔍 그럼… 왜 Vite는 process.env를 무시할까?

Vite는 빠른 개발환경과 빌드 성능을 위해 정적 분석(static analysis) 기반으로 작동합니다.

그래서 “코드 안에서 예측 가능한 부분만” 치환해줍니다.

process.env.XXX는 런타임에 정해지는 값이라

Vite 입장에선 “이 값이 뭔지 미리 모른다” → 아예 무시!

반면 import.meta.env.VITE_XXX는

Vite가 .env 파일을 빌드 타임에 읽어서 코드에 직접 박아 넣어줄 수 있는 "정적인 값"입니다.

📦 예시

// 개발자가 작성한 코드
const apiUrl = import.meta.env.VITE_API_BASE_URL1;

⬇ 빌드 후

const apiUrl = "https://api.example.com"; // 정적 치환됨!

반면 이런 건?

console.log(process.env.VITE_API_BASE_URL1);

⬇ 빌드 후에도 여전히

console.log(process.env.VITE_API_BASE_URL1); // undefined

아무 처리도 되지 않은 채 남아 있다가,

실행 시에도 .env를 읽지 않으니 undefined가 되는 거죠.

🧪 그럼 개발 모드에서는 왜 process.env가 작동했던 거예요?

여기서 많은 개발자가 헷갈립니다.

개발 모드에서는 Vite dev server가 Node 기반으로 돌아가고,

일부 경우 process.env 값이 들어가는 것처럼 보일 수 있어요.

이건 사실 Vite가 define 속성이나 dotenv 로딩을 통해 임시로 넣어준 값일 뿐,

"우연히" 동작하는 것일 뿐입니다.

✅ 개발 모드에서는 동작할 수도 있음

❌ 하지만 빌드 모드에서는 100% 무시됩니다

😵 흔히 겪는 착각들

⚙️ Vite vs Node.js – 환경변수 처리 비교

✅ Electron + Vite 환경에서의 결론 정리

그렇다면 .env만 바꾸면 바로 적용되나요? ❌ 아니요!

Vite는 빌드 타임에 .env 파일을 읽어서 코드를 바꾸기 때문에,

.env 변경 후에는 반드시 vite build 같은 빌드 작업을 다시 해야 반영됩니다.

✅ 최종 요약

Electron 메인은 Node 환경이다 → process.env 가능 BUT Vite로 빌드하면 정적 분석 기반 → process.env 무시됨 → import.meta.env.VITE_XXX 만 써야 함!

Vite를 사용하는 순간, "런타임의 유연성"보다

"빌드 시점의 확정성과 정적 최적화"가 더 중요해집니다.

이 차이를 이해하는 것이 Electron + Vite 개발의 핵심이에요.

프론트엔드 개발을 하다 보면 코드 리뷰에서 이런 말을 자주 듣게 됩니다.

“이거 구조분해 안 했어?”

“props에서 구조분해 해주세요”

“store 값 구조분해해서 써주세요”

그렇다면 이 구조분해란 정확히 무엇일까요?

그리고 왜 쓰는 게 좋고, 언제 쓰면 오히려 독이 되는 걸까요?

실전 예시와 함께 정리된 구조분해 가이드를 알려드릴게요.

✅ 구조분해란?

JavaScript(또는 TypeScript)에서 객체나 배열의 값을 개별 변수로 뽑아내는 문법입니다.

const user = { name: '연지', age: 26 };

// 구조분해 없이
const name = user.name;
const age = user.age;

// 구조분해로
const { name, age } = user;

⭐ 구조분해의 장점

예시: props에서 구조분해

// 구조분해 X
function Profile(props: { name: string; age: number }) {
  return <div>{props.name} ({props.age})</div>;
}

// 구조분해 O
function Profile({ name, age }: { name: string; age: number }) {
  return <div>{name} ({age})</div>;
}

🎯 구조분해가 유용한 경우

1. props, context, hook 등에서 여러 값을 가져올 때

const { t } = useTranslation();
const { userProfile } = useUserStore();

2. API 응답, 상태값 등을 가독성 있게 분리할 때

const { data, error } = await fetchData()

3. 컴포넌트 매개변수에서 바로 속성 꺼낼 때

const MyButton = ({ label, onClick }: ButtonProps) => (
  <button onClick={onClick}>{label}</button>
);

⚠️ 구조분해를 피해야 할 경우 (예외 케이스)

1. 중첩된 객체를 깊게 구조분해할 때

// ❌ 너무 깊은 구조분해
const { a: { b: { c, d } } } = obj;

// ✅ Optional chaining으로 접근하는 것이 더 명확
const c = obj?.a?.b?.c;

2. 필드가 너무 많을 때 (ex. props 10개 이상)

// ❌ 너무 많은 변수 풀림
const { a, b, c, d, e, f, g, h, i, j } = props;

→ 이럴 땐 필요한 것만 부분 구조분해하거나, 그냥 props.xxx로 접근

3. 변수명이 충돌할 수 있는 경우

const { name } = user;
const name = '내 이름'; // 💥 충돌

→ 구조분해 시 변수명을 바꿔주는 것이 안전

const { name: userName } = user;

4. 단일 값만 필요할 때

// ❌ 굳이 구조분해할 필요 없음
const { title } = post;
console.log(post.title);

// ✅ 그냥 post.title로 사용하는 게 더 직관적일 수도 있음

5. 로깅이나 디버깅 시

전체 객체를 로그로 보고 싶을 때는 구조분해하지 말고 객체 통째로 넘기는 것이 낫습니다.

console.log(user); // 전체 구조 확인 가능

🧠 구조분해를 쓸지 말지 결정하는 기준

🔚 마무리 정리

✍️ 한 줄 요약

“구조분해는 잘 쓰면 깔끔한 칼, 남용하면 위험한 칼”입니다. 언제 꺼내 쓸지 잘 판단하는 눈이 중요해요 👀”

예를 들면 _getUser, _registerLeader 같은 함수들이죠.

처음엔 단순한 스타일 차이 정도로 생각하기 쉽지만,

실제로는 이 방식이 실무에서 꽤 널리 쓰이는 네이밍 컨벤션이라는 걸 알게 됩니다.

이번 글에서는

• 왜 함수 앞에 _를 붙이는지
• 언제 쓰고 언제 안 쓰는지
• 어떤 상황에서 유용한지
• 실제로 제가 작업한 코드에서 어떻게 적용했는지를 기준으로 정리해 보려고 합니다.

✅ _는 "이건 내부 전용입니다"라는 뜻이에요

TypeScript에서는 클래스 내부가 아니라면 private 접근 제한자를 사용할 수 없습니다.

그래서 함수 이름에 _를 붙여 개발자끼리의 약속처럼 "이건 외부에서 직접 호출하지 마세요"라는 의미를 표현합니다.

이걸 문법적으로 막을 수는 없지만, 의도를 명확히 드러내는 방식이죠.

예를 들어 아래처럼 구조를 나눕니다:

// 내부 전용 - 순수 API 호출
const _getUser = createPostApi('/api/getUser');

// 외부에 노출할 래퍼 함수
export const getUser = (params) => {
  console.log('[API 요청]', params);
  return _getUser(params).then(...).catch(...);
};

이렇게 하면 _getUser()는 실제로는 외부에서 직접 쓰지 않고,

getUser()만 import해서 사용하게 됩니다.

이런 식으로 작성하면 코드를 읽는 사람 입장에서도

“아, 이 함수는 외부에서 직접 쓰는 게 아니라 내부에서만 호출해야겠구나” 하고 자연스럽게 받아들이게 됩니다.

✅ 그럼 모든 함수에 _를 붙여야 할까? 그렇진 않습니다.

실제로 제가 작업했던 프로젝트에서도 모든 API 함수에 _를 붙이지는 않았습니다.

예를 들어 leader.ts 모듈에서는 _registerLeader, _requestManager 등

내부 전용 함수에 _를 붙인 반면,

department.ts 모듈에서는 getDepartments, addDepartment 같은 함수들을 별도 구분 없이 바로 export했습니다.

이 차이는 구조와 의도에 따라 나뉩니다:

✅ 실무에서는 어떤 기준으로 쓰게 될까?

저는 아래 기준 중 하나라도 해당되면 _를 붙여 내부용 함수로 작성하는 편입니다:

• 해당 함수는 axios 같은 순수 API 호출만 처리하고, 사용자 응답 처리나 로깅은 하지 않을 때
• 로깅, 에러 메시지, 토스트 처리 등을 담당하는 래퍼 함수가 따로 있을 때
• 내부적으로만 재사용하고, 외부에는 노출되지 않아야 하는 유틸 로직일 때
• 테스트나 mocking 대상일 뿐, UI 흐름에는 사용되지 않을 때

반대로 아래 상황에서는 _ 없이 함수명을 바로 export합니다:

• 컴포넌트나 다른 모듈에서 직접 호출될 목적으로 만들어진 함수
• 함수 자체가 간단해서 래핑이 필요 없는 경우 (ex. CRUD 단일 처리)
• 별도 래퍼가 존재하지 않고, 그대로 공식 함수 역할을 할 때

팀 컨벤션으로 정리하면 이런 식입니다

API 네이밍 컨벤션

- `_함수명`: 내부 전용 함수. API 요청만 수행. 예외 처리, 사용자 피드백 없음.
- `함수명`: 외부에서 사용하는 공식 함수. 로깅, 에러 핸들링, 응답 가공 포함.
- `use함수명`: React에서 사용하는 커스텀 훅. get 함수 호출을 감싸서 상태 관리.

실제 디렉터리 구조에 적용해보면

/src
  └── api
        └── user.ts           # _getUser, getUser
  └── hooks
        └── useUser.ts        # useUser

• api 폴더에는 _ 접두사가 붙은 내부 API 함수와 래퍼 함수가 함께 정의되고,
• hooks 폴더에는 외부 API를 감싸는 useXXX 형태의 훅이 정의됩니다.

테스트, 유지보수, 협업 모두에 도움이 됩니다

• _함수는 mocking이나 테스트에서 훨씬 다루기 쉬워요.
• export된 래퍼 함수는 외부에서는 항상 일정한 방식으로 응답을 처리하게 만들어 줍니다.
• 또한 역할이 명확하게 나뉘기 때문에, 협업 중에도 함수가 어떤 용도로 쓰이는지 쉽게 파악할 수 있습니다.

//내부 API 함수만 mocking해서 래퍼 함수는 실제 흐름대로 테스트할 수 있습니다.
jest.mock('@/api/user', () => ({
  _getUser: jest.fn().mockResolvedValue(mockData)
}));

📦 래퍼 함수란?

다른 함수(또는 로직)를 감싸서, 추가 동작을 함께 수행하는 함수를 말합니다.

즉, "기존 기능을 그대로 호출하되, 그 앞뒤로 무언가 더 하는 함수"예요.

포장지(wrap)처럼 감싼다고 해서 "래퍼(wrapper)"라는 이름이 붙었어요.

• 래퍼 함수의 역할 요약

> 이렇게 나누면 **책임이 분리되고 코드가 더 읽기 쉬워지고**, 
실수로 순수 함수만 호출해서 문제가 생기는 걸 막을 수 있습니다.
> 

• 간단한 정의로 정리

  래퍼 함수는 어떤 함수나 로직을 감싸서, 부가적인 동작을 함께 수행하는 함수입니다.

  API 요청뿐 아니라, 로깅, 오류 처리, 응답 정리 등을 포함할 때 주로 사용됩니다.

_를 안 쓰면 생기는 문제도 있어요

• 함수의 역할이 모호해져서, 테스트나 구조 분해가 어렵습니다.
• 실수로 내부 함수 (_getUser)를 외부에서 import해서 써버릴 수도 있어요.
• 에러 처리나 로깅 없이 API가 호출되면, 사용자 입장에선 아무 반응이 없어서 불편할 수 있어요.

이런 이유로 대부분의 실무 코드에서는 _를 통해 책임을 분리하고,

함수의 성격에 맞게 구분하는 방식을 선택하고 있습니다.

📌 마무리: 단순한 스타일이 아닌 설계의 결과

함수명 앞에 _를 붙이는 건 단지 네이밍 스타일이 아닙니다.

코드의 책임과 사용 범위를 명확히 하기 위한 실용적인 컨벤션입니다.

• 실수로 잘못된 함수를 import하지 않도록 도와주고
• 테스트와 디버깅을 쉽게 만들어주며
• 코드 구조에 일관성을 부여합니다

특히 복잡한 API 처리, 민감한 보안 기능, 사용자 피드백이 필요한 영역에서는

순수 API 호출과 부가 로직을 분리하는 구조가 큰 도움이 됩니다.

이런 구조는 협업에서도 이해하기 쉽고, 유지보수 시에 의도를 파악하기 쉬워서 장기적으로 효율적인 패턴이 됩니다.

웹소켓 기반 애플리케이션을 운영하다 보면 가장 많이 마주치는 이슈가 바로

👉 "연결이 끊겼는데도 UI는 멀쩡해 보이는 문제"입니다.

특히 절전모드(슬립)나 노트북 덮기, 탭 전환 후 장시간 방치 같은 상황에서는

브라우저가 웹소켓을 끊었음에도 readyState === OPEN 으로 남아있는 경우도 있습니다.

이 글에서는 다음 내용을 다룹니다:

1. ❌ 왜 웹소켓이 끊겼는지 모르고 방치될까?

WebSocket은 브라우저/OS/네트워크 상태에 따라 "조용히 끊길 수 있습니다".

• 절전모드 → 브라우저 프로세스 일시 정지됨
• 네트워크 재연결 → underlying TCP 소켓 끊김
• VPN 변경/라우팅 오류 → 서버 도달 실패
• 방화벽/프록시 → 일정시간 이후 소켓 정리

📌 문제는 webSocket.readyState가 항상 믿을 수 있는 값은 아니라는 것입니다.

2. 🌙 절전모드 감지: 하트비트 방식

가장 많이 쓰는 방식 중 하나는 바로 하트비트(heartbeat).

setInterval(() => {
  const now = Date.now();
  const drift = now - lastTick;
  if (drift > 10000) {
    console.warn('절전모드 감지, 웹소켓 재연결 시도');
    reconnect();
  }
  lastTick = now;
}, 5000);

• performance.timing.navigationStart 또는 Date.now()를 주기적으로 측정
• 예상보다 오래 걸리면 → 절전모드에서 깨어났다고 판단
• → 이 시점에 WebSocket.readyState !== OPEN이거나 이상하면 재연결

✨하트비트(heartbeat)란?

하트비트는 "앱 레벨에서 주기적으로 연결 상태를 감지하는 로직"입니다.

• setInterval로 5초마다 체크
• 연결 상태를 확인하거나, ping 요청을 날려 응답 확인
• 절전모드 감지, 이벤트 루프 delay 감지, 앱의 주기적 상태확인 등에 쓰임

3. 🛰️ WebSocket Ping/Pong 프레임

WebSocket은 RFC 6455 표준에 따라

프로토콜 레벨에서 ping/pong 프레임을 지원합니다.

Ping/Pong 특징

⚠️ 일반 브라우저 JS에서는 ping 프레임을 직접 보낼 수 없습니다.
→ 서버가 ping, 클라이언트가 pong 응답

4. 🏭 실무에서는 어떻게?

- onclose만 쓰면 안 되는 이유

웹소켓을 감시할 때, 많은 분들이 처음엔 이렇게 처리합니다:

const ws = new WebSocket('wss://...');
ws.onclose = () => {
  console.warn('웹소켓 닫힘 → 재연결 시도');
  reconnect();
};

하지만 실무에서는 매우 불안정합니다:

- 문제점들

• 절전모드에서 onclose 발동되지 않음
• 라우팅 장애, VPN 전환 등에서도 readyState는 OPEN 상태 유지
• 서버가 죽어도 클라이언트는 알 수 없음

- 참고: onclose란?

• WebSocket 연결이 정상적으로 종료되었을 때 실행되는 콜백 함수입니다.
• 예를 들어 ws.close()를 호출했을 때나 서버가 명시적으로 연결을 닫을 때 발생합니다.
• 하지만 네트워크 끊김, 절전모드 등은 비정상 종료이기 때문에 onclose가 호출되지 않을 수 있습니다.

✅ 그래서 실무에서는 이렇게 대응합니다

💡 결론: onclose는 일부 상황에서만 유효

• onclose는 정상 종료에만 잘 작동합니다
• 절전모드, 네트워크 오류, VPN, 방화벽 등 실무에서 자주 발생하는 이슈에는 아예 작동 안 하는 경우도 많습니다
• 그래서 반드시 heartbeat 또는 ping/pong을 보완적으로 사용해야 합니다

실무에서는 "둘 다" 병행합니다.

💡 실무에서는 서버가 ping, 클라이언트가 pong 응답하고

프론트는 30초마다 setInterval로 readyState를 감시하는 구조가 일반적입니다.

5. Electron + React + Vite 환경에서의 적용 예시

Electron 앱의 렌더러 프로세스에서는 다음처럼 heartbeat를 구현할 수 있습니다.

// heartbeat.ts
let lastCheck = Date.now();

setInterval(() => {
  const now = Date.now();
  const delay = now - lastCheck;

  if (delay > 10000) {
    console.warn('[하트비트] 절전모드 감지 → 재연결 시도');
    webSocketManager.manualReconnect(); // 커스텀 재연결 로직
  }

  lastCheck = now;
}, 5000);

또는 WebSocket wrapper 클래스 내에서 다음과 같이 상태를 주기적으로 체크할 수 있습니다:

const ws = new WebSocket('wss://...');
setInterval(() => {
  if (ws.readyState !== WebSocket.OPEN) {
    console.warn('연결 끊김 → reconnect');
    reconnect();
  }
}, 10000);

📌 실전 팁 요약

• WebSocket.readyState는 믿되 너무 믿지 말자

  • readyState별 의미 요약 표

    
      | 상태 코드 | 이름        | 의미                       |
      |-----------|-------------|----------------------------|
      | 0         | CONNECTING  | 연결 중                    |
      | 1         | OPEN        | 연결 완료, 송수신 가능     |
      | 2         | CLOSING     | 연결 종료 중               |
      | 3         | CLOSED      | 연결 종료됨                |

• 절전모드, 탭 전환 등은 하트비트로 감지

• 서버는 ping/pong 설정을 적극 활용하자

• Electron 환경에서도 렌더러에 heartbeat는 유용하게 작동

📚 참고자료

• RFC 6455 - The WebSocket Protocol
• MDN - WebSocket
• Socket.IO Heartbeat 참고

보안 기능을 만들면서 실행 파일 감지를 하는데,

생각보다 이런 경로가 많이 튀어나왔다:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\한셀 2024.lnk

“어? EXE가 아니고 LNK네?”

맞다. 대부분의 사용자는 프로그램을 직접 실행하는 게 아니라 시작메뉴 / 바탕화면 바로가기를 클릭한다.

결국 .lnk 파일을 열어서 실제 실행 대상(EXE 경로)을 뽑아야 한다는 결론에 도달했다.

🔎 LNK 구조 분석 & PowerShell 구현

Windows .lnk 파일은 단순 텍스트가 아니다.

WScript.Shell COM 객체를 통해 접근해야 한다.

PowerShell 스크립트는 간단했다:

powershell
복사편집
$shell = New-Object -ComObject WScript.Shell
$shortcut = $shell.CreateShortcut("C:\경로\한셀 2024.lnk")
$shortcut.TargetPath

이걸 Electron에서 Node.js child_process.spawn()으로 실행하면 끝이다.

그럴 줄 알았다.

💣 문제: “PowerShell에선 되는데 Electron에선 안 된다”

PowerShell 콘솔에선 잘 되는데,

Electron에서 실행하면 결과가 무조건 '' (빈 문자열).

ts
복사편집
// Electron
const result = await execPowerShell('한셀 2024.lnk');
console.log(result); // ''

내가 시도했던 디버깅 1~6단계

🧬 원인 분석

Electron → PowerShell 호출 시, 인자로 전달되는 경로가 한글이면 깨진다.

왜냐면:

• Electron(Node.js)은 기본적으로 UTF-8

• PowerShell은 윈도우 로케일 영향으로 CP949를 쓸 수도 있음

• 그래서 CLI 인자 전달 시 한글이 깨짐

  (CreateShortcut('��� 2024.lnk') ← 이렇게 변형됨)

🤦 “UTF-8로 저장하면 되겠지”는 착각이었다

처음엔 이렇게 생각했다:

“스크립트 파일 자체를 UTF-8 BOM으로 저장하면 되겠지?”

❌ 결과: 안 됨

왜냐하면 깨지는 시점이 스크립트 실행이 아니라, 경로 인자 전달 시점이기 때문이다.

🧠 Base64라는 진짜 해결책

결국 알게 됐다:

Electron → PowerShell 전달 경로를 Base64로 인코딩해서 넘기면 된다.

Base64는 ASCII 문자만으로 구성되어

OS, 로케일, 인코딩 충돌 없이 항상 안전하게 전송된다.

👇 그래서 이렇게 바꿨다:

🔁 Electron:

const encoded = Buffer.from(filePath, 'utf8').toString('base64');
spawn('powershell.exe', ['-File', 'script.ps1', encoded]

🔁 PowerShell:

param($encoded)
$decoded = [System.Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($encoded))
$shell = New-Object -ComObject WScript.Shell
$shortcut = $shell.CreateShortcut($decoded)
$shortcut.TargetPath

Boom! 이제 한글 경로도 완벽하게 처리된다.

🧪 왜 Base64만이 해결책인가?

핵심:

UTF-8은 문자열 인코딩이고, Base64는 전송 인코딩이다.

CLI 인자, 파일 경로, JSON 내 인자처럼 전송이 필요한 곳엔 Base64가 정답이다.

✅ 최종 구현 흐름

1. LNK 경로 Base64 인코딩
2. PowerShell에 전달
3. Base64 디코딩 후 CreateShortcut으로 대상 추출
4. 대상 EXE가 존재하면 해당 경로의 파일 메타데이터도 추출

이제 아래처럼 JSON으로 묶어서 반환된다:

{
  "lnk": {
    "filePath": "C:\\...\\한셀 2024.lnk",
    "targetPath": "C:\\Program Files\\HCell.exe",
    "description": "한글 스프레드시트"
  },
  "exe": {
    "progNm": "한셀 2024",
    "prdNm": "HCell",
    "signValid": true}
}

🧠 마무리 회고

처음엔 단순히 “바로가기도 처리해야겠다”는 생각이었는데,

그 끝엔 인코딩 지옥, CLI 디버깅, PowerShell 삽질이 기다리고 있었다.

그나마 다행인 건,

이제는 한글 포함된 모든 바로가기를 완벽하게 처리할 수 있게 됐다는 점이다.

💡 개발자를 위한 TIP: CLI(Command-Line Interface)란?

CLI란?

Command-Line Interface의 줄임말로,

GUI(그래픽 사용자 인터페이스) 없이 명령어를 텍스트로 입력해서 컴퓨터를 조작하는 방식이다.

• 대표 예시:
  • Windows의 cmd.exe, powershell.exe
  • macOS, Linux의 bash, zsh, terminal

# 예시: 파일 경로를 인자로 받아 처리하는 명령
powershell.exe -File myscript.ps1 "C:\Users\연지\문서\바로가기.lnk"

왜 CLI에서 문제가 발생했을까?

• CLI는 텍스트 기반이라 '한글' → byte → 다시 문자열로 변환되는 과정에서 인코딩 오류가 생기기 쉬움
• 특히 PowerShell은 시스템 로케일(예: CP949)을 따라가는 반면, Electron(Node.js)은 UTF-8을 기본으로 사용함
• 이 차이로 인해 CLI 인자로 한글을 넘길 때 깨지는 현상이 발생했다

👉 그래서 해결책은?

Base64 인코딩으로 경로를 감싼 다음 넘기면, CLI 내부에서 무조건 안전하게 처리 가능

CLI에서는 데이터를 다룰 때 문자 그대로 전달되는 게 아니라 바이트 수준의 처리가 되기 때문에,

ASCII만 사용하는 Base64가 매우 안정적인 해결책이 된다.

👇 개발자 여러분, 이건 꼭 기억하세요:

PowerShell에서 잘 된다고 Electron에서도 잘 되리라는 법은 없다.

CLI 인자엔 무조건 Base64를 써라.

아니면 3시간 날릴 수 있다 😇

"개발 모드에선 100% 완벽하게 작동했는데요?"

그 말, 배포 환경 앞에선 무력하다는 걸 여러분도 아시죠?

이번엔 정말 ‘작동’은 했지만 데이터는 안 왔던 미스터리.

그래서 무려 반나절 동안 머리 싸매고 추적한 로그 로그 로그…

결론부터 말하자면?

엔드포인트 오타 + 개발 모드의 과잉 친절 + 배포의 차가움 = 디버깅 지옥

이 긴 여정, 벨로그에 소환합니다.

🛠️ 세팅 요약

🧨 1. 사건 개요

Electron + React + Vite 조합으로 멋지게 GUI 앱을 개발하던 어느 날…

“개발에선 잘 되던 API 호출이 배포 후엔 아무 반응이 없었다.”

기분 좋게 electron-builder로 .exe를 빌드하고 실행했더니,

API는 침묵. 화면은 정지. 내 심장도 멈췄다.

🔍 2. 이상했던 점

• 엔진은 잘 실행됨 ✅
• Pipe 메시지 정상적으로 주고받음 ✅
• 근데 Axios API 요청만 안 감 ❌
• 심지어 콘솔 로그도 안 찍힘 ❌

이쯤 되면 “Electron 배포하면 CORS 문제 생기나?”,

“env 문제인가?”, “build 설정에서 뭘 빼먹었나?” 하는 의심이 차례로 들기 시작했습니다.…

🧪 3. 브레이크 포인트: 오타였다고?

개발 모드에선 잘 되던 이 코드:

axios.post(`${API_BASE}/@@@@@/rest/getAlwCmmnExePrgList.do`)

배포 후에도 잘 될 줄 알았지. 하지만 실제 API는 이거였음:

axios.post(`${API_BASE}/@@@@/rest/getAllowWebList.do`)

즉,

• getAlwCmmnExePrgList.do → ❌ 오타
• getAllowWebList.do → ✅ 올바름

🧙‍♀️ 4. 개발 모드에서는 왜 괜찮았냐면요…

🌈 개발 모드 마법 세트

👉 즉, 오타가 있어도 mock이 받아줌 → 데이터가 응답됨 → 난 문제를 눈치채지 못함...

잠깐! Vite Proxy가 뭐냐면요?

“개발 모드에서는 API 요청을 그냥 localhost로 보내도 잘 되던데요?”

그건 다 Vite의 proxy 기능 덕분입니다.

🎭 프록시란?

프록시는 중간에서 대신 요청을 전달해주는 대리인입니다.

즉, React 앱(렌더러)이 아래처럼 요청하더라도:

axios.post('/@@@@@/rest/getAllowWebList.do', {...})

브라우저는 그걸 http://localhost:3000/@@@@@/rest/getAllowWebList.do로 해석하고,

Vite dev server는 설정에 따라 실제 서버인 https://*******.com:8443로 요청을 자동 전달합니다.

🧪 개발 환경에서 Proxy가 해주는 일

// vite.config.ts
server: {
  proxy: {
    '/@@@@@/rest': {
      target: 'https://*******.com:8443',
      changeOrigin: true,
      secure: false,
    }
  }
}

위 설정이 있다면 /@@@@@@/rest/xxx.do로 오는 요청을

모두 https://*******.com:8443/@@@@@/rest/xxx.do로 프록시해주는 것!

😈 근데 배포(EXE) 모드에서는?

• Vite dev server가 없으니 proxy도 아예 작동 안 함.
• 상대경로(/@@@@@/rest/...)로 호출하면 브라우저는 그냥 file://에서 찾으려 하거나, 아예 URL을 못 찾음.
• 즉, 프록시 없는 배포 환경에서는 절대경로(https://…)를 무조건 써야 함.

💡 그래서 왜 문제가 생긴 걸까?

1. 개발 모드에서는 /####/rest/... → Vite가 프록시로 넘겨줌 → 작동
2. 배포 모드에서는 프록시 없음 → 요청이 날아가지 않거나, 404 에러

💥 5. 배포 후엔 왜 터졌냐면요…

🔥 배포(EXE) 모드의 진실

그러니까...

• 개발 모드에선 오타도 응답이 오지만,
• 배포 모드에선 진짜 서버가 404를 때려버림

🧯 6. 해결한 방법 총정리

🤡 7. 나의 실수 모음 (반성의 표)

✨ 8. 얻은 교훈

“개발 모드는 착한 척할 뿐, 진짜 배포에서 모든 게 드러난다.”

• ✅ 엔드포인트는 반드시 백엔드 문서랑 대조해서 철자까지 정확히
• ✅ 배포 전에 mock 제거하고 실제 서버에 테스트
• ✅ Vite proxy는 개발 전용이라는 걸 잊지 말 것
• ✅ define 치환 방식으로 env 관리하면 실수 줄일 수 있음

🧠 덤: 내 애착 env 설정

# .env.development
VITE_API_BASE=http://localhost:3000

# .env (프로덕션)
VITE_API_BASE=https://********.com:844

vite.config.ts

define: {
  __API_BASE__: JSON.stringify(env.VITE_API_BASE),
}

api.ts

const API_BASE = __API_BASE__;

export function getAllowedWebsites(...) {
  return axios.post(`${API_BASE}/@@@@@@/rest/getAllowWebList.do`, ...);
}

🎉 마무리

이제는 .exe 빌드만 하면 먹통 되는 이유를 안다!

다음에 비슷한 상황이 오면 무조건 3가지를 먼저 확인하자:

1. 엔드포인트 오타나 환경변수 설정 실수는 배포 전 실서버로 반드시 검증하자
2. Vite define 치환은 빌드 시점에 고정되므로, 런타임 수정 불가
3. mock, proxy는 개발을 편하게 해주지만, 배포와는 완전히 다르다

이게 바로 개발 모드의 마법이 배포 모드에서 재앙이 되는 메커니즘 입니다.

이 글이 비슷한 문제로 멘붕하는 분들께 도움이 되었으면 좋겠습니다 🙏

나처럼 안 헤매고 배포까지 쭉쭉 가세요! 🚀