"테스트 데이터 만들다가 탄소 배출량 전문가가 된 건에 대하여"
🎯 오늘의 미션
회사에서 EcoNiPass라는 탄소관리 플랫폼을 개발하고 있다.
문제는... 로컬에서 테스트를 하려면 데이터가 있어야 하는데, 매번 수동으로 넣기엔 너무 귀찮다.
"그냥 테스트 데이터 좀 넣으면 되는 거 아냐?"
라고 생각했던 과거의 나에게 전하고 싶다.
탄소 배출량 데이터는 생각보다 복잡하다. 🤯
📚 오늘 배운 것들
1. Scope 1, 2, 3이 뭔데?
처음엔 "스코프가 뭐야, 망원경 얘기야?" 했다.
알고보니 GHG Protocol(온실가스 프로토콜)에서 정한 배출량 분류 체계였다.
| Scope | 뭔가요? | 예시 |
|---|---|---|
| Scope 1 | 직접 배출 | 회사 차량 기름값, 보일러 가스 |
| Scope 2 | 간접 배출 (에너지) | 전기세 💡 |
| Scope 3 | 기타 간접 배출 | 출장, 통근, 원자재 구매... |
Scope 3가 진짜 보스다. 무려 15개 카테고리가 있다.
카테고리 1: 구매한 물품
카테고리 2: 자본재 (기계 샀다!)
카테고리 3: 연료 관련 활동
카테고리 4: 상류 운송 (물건 배달받음)
카테고리 5: 폐기물 (쓰레기!)
카테고리 6: 출장 ✈️
카테고리 7: 직원 통근 🚗
...
카테고리 11: 제품 사용 (고객이 쓸 때)
카테고리 12: 제품 폐기 (버릴 때)
💡 인사이트: 회사가 직접 뿜는 탄소(Scope 1+2)보다, 간접적으로 연결된 탄소(Scope 3)가 훨씬 많다. 마치 빙산의 일각처럼!
2. 일본 회계연도의 비밀 🇯🇵
테스트 데이터를 만드는데 자꾸 에러가 났다.
"FY2025 데이터가 없습니다"
뭐지? 2025년 데이터 다 넣었는데?
알고보니 일본은 회계연도가 4월에 시작한다.
| 우리가 생각한 것 | 실제 일본 회계연도 |
|---|---|
| 2025년 = 1월~12월 | FY2025 = 2025년 4월 ~ 2026년 3월 |
💡 인사이트: 글로벌 서비스 개발할 때 "연도"라는 개념도 나라마다 다를 수 있다. 절대 가정하지 말자!
3. "에러가 안 나요" 에러 🐛
로그인은 되는데 매번 빨간 팝업이 떴다.
❌ Error: 시스템 에러가 발생했습니다
Network 탭을 열어보니 범인 발견:
GET /global_ip → (failed) net::ERR_CONNECTION_REFUSED
global_ip가 뭐냐면... 사용자의 공인 IP를 가져오는 API였다.
문제는 localhost에는 공인 IP가 없다는 것. 🏠
해결책:
// 개발 환경에서는 그냥 넘어가자
if (isDev) {
console.warn("[Dev] global_ip 실패, 대신 localhost 사용");
setGlobalIP("localhost");
} else {
showErrorPopup(error); // 프로덕션에서만 에러 표시
}
💡 인사이트: 로컬 개발 환경과 프로덕션 환경의 차이를 항상 고려하자. "내 컴퓨터에서는 되는데?"의 90%는 환경 차이다.
4. 개발자 경험(DX)의 중요성 ✨
테스트할 때마다 아이디/비밀번호 치는 게 너무 귀찮았다.
Email: econipass_support@wingarc.com
Password: password123
매일 50번씩 입력하다 보니...
"그냥 자동으로 넣어주면 안 되나?"
// 개발 환경에서만 자동 입력
const isDev = process.env.NODE_ENV === "development";
const [id, setId] = useState(isDev ? "test@email.com" : "");
const [password, setPassword] = useState(isDev ? "password123" : "");
그리고 로그인 페이지에 이쁘게 표시까지:
┌─────────────────────────────────────┐
│ 🔧 Test Account (Dev Only) │
│ Email: econipass_support@... │
│ Password: password123 │
└─────────────────────────────────────┘
💡 인사이트: 사소한 불편함이 쌓이면 큰 생산성 저하가 된다.
반복 작업은 무조건 자동화하자. 미래의 나에게 주는 선물이다. 🎁
5. 테스트 데이터는 코드다 📝
예전에는 테스트 데이터를 DB에 직접 INSERT 했다.
INSERT INTO users VALUES ('test', 'test@test.com');
-- 야 그거 어디갔어?
-- 몰라 내 로컬에서만 됨
이번엔 제대로 스크립트로 관리했다:
./scripts/manage_test_data.sh seed # 데이터 넣기
./scripts/manage_test_data.sh status # 현황 확인
./scripts/manage_test_data.sh reset # 초기화
./scripts/manage_test_data.sh clean # 삭제만
결과:
- 692줄의 SQL 스크립트
- 158개의 테스트 레코드
- 버전 관리 가능
- 팀원 누구나 동일한 환경 재현 가능
💡 인사이트: "나중에 정리해야지"는 거짓말이다. 처음부터 스크립트로 만들자.
🏆 오늘의 교훈 TOP 3
🥇 1등: 환경 차이를 존중하라
로컬 ≠ 개발 서버 ≠ 스테이징 ≠ 프로덕션
각 환경의 특성을 이해하고, 환경별 분기 처리를 두려워하지 말자.
🥈 2등: 반복은 자동화의 신호다
같은 작업을 3번 이상 했다면, 스크립트로 만들 때가 됐다.
🥉 3등: 도메인 지식은 무기다
"탄소 배출량"이라는 도메인을 이해하니까 코드가 보였다.
Scope 1/2/3, 회계연도, 카테고리...
코딩 실력만으로는 좋은 소프트웨어를 못 만든다.
📊 오늘의 성과
커밋: 4개
새 파일: 8개
추가된 코드: 5,899줄
해결한 버그: 2개
마신 커피: ☕☕☕
🚀 다음 할 일
- Keycloak 사용자 ID 동기화 검증
- 새로 추가한 기능 테스트 코드 작성
- MCP 서버 실제 구현 (지금은 스펙만 있음)
"좋은 개발자는 코드를 짜고, 더 좋은 개발자는 미래의 자신을 위한 코드를 짠다."
— 오늘 테스트 데이터 스크립트 만들면서 느낀 점
이 글이 도움이 되셨다면, 당신의 Scope 3 배출량(공유 버튼 누르기)도 잊지 마세요! 🌍💚