📅 2026-03-17 개발 일지 요약
1. 작업 분포
| 카테고리 | 비중 | |
|---|
| 백엔드/아키텍처 구현 및 리팩토링 | 40% | ████░░░░░░ |
| 인터뷰 대비 및 기술 문서화 (TF/EKS/Docker) | 35% | ███░░░░░░░ |
| MCP 교육 커리큘럼 기획 | 15% | █░░░░░░░░░ |
| 커리어/잡 오퍼 상담 | 10% | ░░░░░░░░░░ |
2. 집중 영역 / 시간 소모 포인트
🟢 생산적 작업
- 데이터 구조 리팩토링 (BigQuery 호환성 확보):
connections 컬렉션의 uids 배열을 uid1, uid2 단일 필드로 분리하여 향후 SQL JOIN 시 UNNEST 없이 쿼리 가능하도록 수정.cards 컬렉션에 urlParams(압축된 blob) 외에 분석용 details 필드(name, title, company, email)를 추가하여 직관적인 데이터 마이닝이 가능하게 구조 변경.
- 기술 문서화:
- 팀프로젝트 테라폼 코드를 기반으로 면접용 답변 정리(
테라폼 20260317.md, EKS 테라폼 20260317.md 생성).
- Docker 개념과 실제 Dockerfile 분석 내용을 정리하여 인터뷰 대비 자료 확보.
🔴 삽질/시간 소모 포인트
- 아키텍처 방향성 고민 (멀티클라우드 vs 단일 스택):
- 메시징 기능 구현을 위해 Google Apps Script + Sheets 샤딩 아키텍처를 고민하며 시간 소모.
- 결론: 현재 MAU(100~300) 규모와 안정성(SLA)을 고려하여 오버엔지니어링 판정, Firestore 단일 스택 유지 및
details 필드 추가 방식으로 선회.
- 보안과 가시성의 트레이드오프:
cards의 세부 정보를 평문(details)으로 저장할 때 발생하는 보안 이슈에 대해 논의. 민감 정보(전화번호 등)는 제외하고 공개용 정보만 노출하는 것으로 합의하여 해결.
3. 타임라인
| 시간 | 화자 | 내용 |
|---|
| 00:18 | 🦦 | Firebase 무료 사용량 분석 및 메시징 기능(단방향 쪽지) 구현 방향 논의 |
| 11:57 | 🦦 | 메시징 속도 제한(Rate Limit) 정책 수립 및 대시보드(UI) 구조 설계 |
| 13:23 | 🦦 | 현재 백엔드 코드의 확장성 리뷰 (Hot Document, N+1 문제 등 식별) |
| 15:29 | 🦦 | 팀프로젝트 테라폼 코드 기반 인터뷰 속성 과외 (VPC, SG, 모듈화 등) |
| 15:33 | 🦦 | 계약직 SM 직무 잡 오퍼 상담 (연봉, 4대보험, 근무 조건 등) |
| 17:21 | 🦦 | 테라폼 및 EKS 실습 내용 인터뷰 대비 문서로 작성 |
| 22:36 | 🦦 | Docker 개념 복습 및 마이그레이션을 위한 데이터 구조 검토 |
| 22:51 | 🦦 | BigQuery 연동 용이성을 위해 connections 및 cards 스키마 리팩토링 계획 수립 |
| 23:14 | 🦦 | GCS 백업 및 BigQuery 로드 파이프라인 제로 비용 구성 계획 수립 |
| 23:19 | 🐹 | 비전공자를 위한 MCP 서버 제작 시리즈 커리큘럼 및 폴더 구조 기획 |
| 23:25 | 🦦 | 리팩토링 된 스키마(uid1/uid2, details 필드) 적용 및 메시징 기능 구현 시작 |
4. 해결한 문제와 인사이트
핵심 문제 해결
- BigQuery 마이그레이션 호환성 확보:
- 기존
connections의 배열 필드는 BigQuery 쿼리 시 불편함을 초래하여 uid1, uid2로 분리하는 방향으로 수정.
- 기존
cards의 압축 필드(urlParams)는 분석이 불가능하여 details 필드를 추가해 직관적인 조회가 가능하도록 변경.
- 비용 효율적인 백업 전략:
- Firestore → GCS → BigQuery 흐름의 무료 백업 파이프라인(Cloud Scheduler 활용) 설계.
- 메시징 기술 스택 선정:
- Apps Script 샤딩 등 복잡한 아키텍처보다 현재 트래픽에 적합한 Firestore 기반 구조를 선택하여 안정성 확보.
인사이트
- 신입 면접 준비: 본인이 작성한 코드를 기반으로 설명하는 연습(Terraform 변수,
depends_on 등)이 이론 암기보다 훨씬 효과적임.
- 개발 vs 문서화: 기술 블로그 형태(MkDocs)로 프로젝트를 문서화하면 지식 정리와 포트폴리오 겸용이 가능함.
- 데이터 설계의 중요성: 초기 설계 단계에서 마이그레이션과 분석(BigQuery)을 고려하지 않으면 나중에 스키마 변경 비용이 크게 발생함.
Supported by ai-log-sync & GLM-4.7