1. 오늘의 몰입: 안정화, 그리고 새로운 고민의 시작
주요 목표
- SkyStat 프론트엔드 안정화: 실서버 배포 후 발견된 UI/UX 버그 픽스
- 모달(Modal) 창 동작 오류 수정
- 모바일 환경에서의 Input 창 렌더링 및 사용성 개선
- 신규 기능 설계 및 아키텍처 고민: ‘공항 이름으로 검색’ 기능 추가를 위한 백엔드 구조 구상
- 기술 확장: MSA(Microservices Architecture) 개념 학습 시작
달성률: 70% (SkyStat의 자잘한 버그들을 잡아내며 서비스 완성도를 높였으나, 아키텍처 설계에 대한 깊은 고민에 빠져 코딩 테스트 훈련을 진행하지 못했다.)
2. 오늘의 난관 (반성)
- 알고리즘의 부재: 어제의 휴식 이후, 오늘은 다시 코딩 테스트 문제 풀이로 복귀했어야 했다. 하지만 프론트엔드 버그 수정과 백엔드 아키텍처 고민에 시간을 모두 쏟아버렸다. 프로젝트와 알고리즘 사이의 밸런스 붕괴가 계속되고 있어 강력한 의식적 노력이 필요하다.
- 학습의 곡선 (MSA): 새로운 공항 검색 기능을 분리하고 싶어 MSA를 들여다보기 시작했지만, 아직 내 지식수준으로는 이 거대한 아키텍처를 당장 프로젝트에 올바르게 적용하기엔 무리가 있다는 것을 뼈저리게 느꼈다.
3. 배움과 기록: ‘공항 검색 API’는 어디에 두어야 할까?
오늘 하루 내 머리를 아프게 했던 기술적 고민이다. SkyStat에 사용자들이 ICAO 코드뿐만 아니라 ‘공항 이름’으로도 검색할 수 있는 기능을 추가하려고 한다. 이를 위해 다음 두 가지 벽에 부딪혔다.
💡 1. 데이터 소스의 확보
전 세계 공항의 ICAO, IATA, 공식 명칭, 위치 좌표(위도/경도) 등을 담은 신뢰할 만한 정적 데이터를 어디서, 어떻게 수집하고 동기화할 것인가? (Open Data API나 CSV 덤프 활용 방안 모색 중)
💡 2. 도메인 경계와 책임의 분리
“이 기능을 현재 운영 중인 weather-api 서버에 함께 구현하는 것이 맞는가?”
내 직감은 ‘아니다’라고 강하게 말하고 있다. 기상 정보(Weather)를 파싱하고 통계를 내는 핵심 도메인과, 단순히 공항의 메타데이터(Airport Info)를 제공하는 도메인은 그 성격과 책임이 완전히 다르기 때문이다.
이러한 고민의 연장선에서 MSA(마이크로서비스 아키텍처) 공부를 시작했다. 당장 이 거창한 아키텍처를 도입할 수는 없겠지만, 적어도 ‘멀티 모듈’이나 ‘서비스 분리’에 대한 힌트를 얻고, 왜 기존 통짜(Monolithic) 구조에서 벗어나려 하는지 그 ‘Why’를 내 프로젝트에 직접 투영해 보는 귀중한 시간이었다.
4. 내일의 다짐: 기본기로의 회귀
- 코딩 테스트 복귀: 내일 1순위 목표는 무조건 코딩 테스트다. 아키텍처 고민은 잠시 접어두고, 다시 알고리즘 문제 풀이(그리디 5문제)에 돌입하여 멈춰있는 코딩 뇌를 깨운다.
- 루틴의 회복: 프로젝트 유지보수 시간과 취업 준비(CS/알고리즘) 시간을 명확하게 분리하여 하루 일과를 통제하겠다.