아키텍처

1. 이벤트 트래킹 통합 아키텍처 설계와 구현

   이마트앱 프론트엔드에는 GTM, Airbridge, shinsegae.ai 검색 행동 로그, EAPP Tracker가 공존했습니다.

2. CDN 동적 캐싱 전략 재설계 — CloudFront + Nginx 콘텐츠별 정책 분리

   이미지 리사이징 서버 앞단에 CloudFront CDN이 구축되어 있었습니다. 그러나 CDN이 있다는 것과 CDN이 효과적으로 작동한다는 것은 다른 문제입니다.

3. E2E 및 통합테스트 시스템 구축 — 자동화 검증 체계 구축

   릴리즈 검증이 전부 수동으로 이루어졌습니다. 릴리즈마다 QA팀이 TC(테스트 케이스) 항목을 하나씩 수동으로 확인해야 했고, 영향도가 큰 릴리즈는 최소 2일 이상의 QA 기간이 소요됐습니다. 핵심 사용자 흐름(주문·결제 등)에 대한 자동화 검증이 전혀 없었습니다.

4. iframe navigation abort에서 호출별 생성 전환으로 네이티브 브릿지 안정화

   대형 유통사의 하이브리드 앱에서 웹뷰와 네이티브 간 통신은 URL scheme 기반 브릿지로 이루어진다. 기존에는 CDN에서 전역 함수(emart.app.cmd, emart.util)를 로드하고, 숨겨진 iframe 싱글톤의 src 속성에 scheme URL을 할당하는 방식으로 네이티브…

5. $goWithRouter 라우팅 개선

   SCRUM-14378 | 커밋 수: 23개 | 기간: 2025.06

6. jsp에서 호출할 vue 컴포넌트 모듈 구현

   현재 jsp에서 vue 리소스를 받아 서빙하는 구조로 프로젝트가 이루어져 있습니다. jsp 댓글 이벤트 페이지에서 vue에서 사용하는 댓글 목록(CommentList) 및 댓글 작성 박스(CommentBox) 컴포넌트를 사용하고 싶어하는 요구사항이 있었습니다.

7. Vuex → Pinia 마이그레이션

   상태관리 아키텍처 전환 — 번들 사이즈, DX, 마이그레이션 전략 문서화

8. 상품 아키텍처 리팩토링

   이커머스 상품 도메인 구조 재설계 — 컴포넌트 수/복잡도 감소 수치 필요

9. 아키텍처 리뷰에 대한 답변

   스토어를 사용하는 이유가 없어지는 것 같아요 데이터 관련 비즈니스 로직은 store에 집중시키고 UI 관련한 공통화 필요한 비즈니스로직이 hook에서 처리하는게 현재 프로젝트 구조에 더 맞을 것 같습니다

10. 아키텍처 제안

    아키텍처 관련해서 여쭤보고 싶은게 있습니다ㅎㅎ 바쁘시면 여유 있으실 때 천천히 답변주셔도 괜찮습니다ㅎㅎ

11. 네이티브 브릿지 아키텍처 리팩토링 — 단일 파일에서 모듈 시스템으로

    이마트앱 프론트엔드에서 네이티브 앱과의 통신(79개 인터페이스)을 담당하는 코드가 utils/native.ts 단일 파일에 집중되어 있었습니다. 워크이마트, 웰컴체크인 등 네이티브 연동 서비스가 늘어나면서 유지보수 한계에 도달했습니다.

12. 갤럭시 폴드8 보험·교체 전략 (2026.07 기준)

    갤럭시 폴드8 구매 시점에 두 가지 의사결정이 필요했습니다.

13. 회의록 두 줄짜리 결정에서 그릴링 세션으로 설정 3단 분리 아키텍처와 구현 이슈 5개를 도출하기

    AI 기반 SDLC 플랫폼(specflow)의 설정 화면은 처음에 하나의 전역 설정으로 시작했다. Jira 인스턴스 주소, 개인 액세스 토큰(PAT), 프로젝트 키, LLM 키가 전부 한 곳에 섞여 있었다. 사용자가 늘고 프로젝트가 여러 개가 되자 문제가 드러났다.

14. 직무 흡수 방향 판단 — 흡수는 스택이 아니라 명세의 원천이 결정한다

    AI 에이전트가 코드 생산 비용을 급격히 낮추면서 채용 시장의 직함이 "프론트엔드", "백엔드"에서 "프로덕트 엔지니어"로 수렴하고 있다. 이 흐름 앞에서 프론트엔드 개발자가 흔히 던지는 질문은 "FE가 BE에 흡수되는가, 그러니 백엔드를 배워야 하는가"다.

15. 서브에이전트 초안은 주장 단위로 재검증한다

    네이티브 브릿지 레이어를 리팩토링한 PR에 아키텍처 관점의 리뷰 코멘트가 여러 건 달렸다. 답변을 쓰기 위해 서브에이전트에게 변경 범위를 조사시키고 답변 초안을 받았다. 초안은 잘 읽혔다. 논지도 맞았고, 문단 구성도 리뷰어의 질문 순서를 따라가고 있었다.

16. 규칙 문서 이중화와 판정 권위 — 인라인 요약이 정본을 배신할 때

    코드 품질 규칙을 문서로 외재화하다 보면 자연스럽게 두 겹 구조가 만들어진다. 진입점 문서에는 "이 규칙들을 이런 순서로 검사한다"는 인라인 요약을 두고, 상세 판정 기준은 별도 references 문서에 둔다.

17. 역량의 시장 환금 원칙 — 증거물로 변환되기 전까지 판단력의 시장 가격은 0원

    AI 도구가 코드 생산을 대체하면서, 개발자의 차별화 지점은 "무엇을 만들 수 있는가"에서 "무엇이 맞는지 판단하고 검증할 수 있는가"로 이동하고 있다. 판단력과 검증 능력이 실재하는 해자라는 데까지는 쉽게 동의할 수 있다.

18. 검증 게이트 오너십 — 자동화되는 것은 실행이고, 남는 것은 기준이다

    AI가 작성하는 코드의 비중이 빠르게 늘고 있다. 동시에 검증 도구 자체도 벤더화되고 있다 — Playwright 기반 E2E 에이전트가 테스트를 대신 돌리고, VLM이 시각 회귀 diff를 판정한다. "검증마저 자동화되면 개발자에게 남는 게 뭔가"라는 질문이 자연스럽게 나온다.

19. 웹뷰 브릿지 플래그는 OS 판별자가 아니다 — isIOS/isAndroid의 실제 의미

    하이브리드 앱의 웹 코드에는 거의 항상 "지금 iOS인가 안드로이드인가"를 묻는 전역 플래그가 있다. 이름은 대개 isIOS, isAndroid다. 앱 안에서 동작하는 화면이라면 이 플래그가 편하고, 실제로 대부분의 분기가 이걸 쓴다.

20. 2026 세제개편안 ISA 정책 변경 (2027년 시행)

    2026년 세제개편안이 발표되면서 ISA(개인종합자산관리계좌) 제도에 큰 변화가 예고되었다. 2027년 1월 1일부터 신규 가입자에게 적용되는 변경 사항과, 기존 가입자에게도 일괄 적용되는 규정이 혼재되어 있어 정확한 이해가 필요하다.

21. 소유자를 확정할 수 없는 크리덴셜 앞에서 자동 귀속 대신 폐기+재입력을 택해 파생 정책 연쇄 오염을 차단하다

    크리덴셜(외부 시스템 토큰, API 키)을 전역 설정 한 곳에 두고 모두가 공유하던 시스템을, 사용자별 개인 설정으로 전환하는 마이그레이션이었다.

22. 랜덤 추첨 리소스라는 제약에서 전체 재조회 대신 실패 페이로드 국소 패치로 — 리소스 결정성이 데이터 갱신 전략과 API 계약을 결정한다

    리테일 앱의 웰컴 체크인 구매미션 기능을 구현했다. 사용자에게 상품 구좌 10개가 노출되는데, 이 구좌는 서버가 요청 시점마다 랜덤 추첨 + 개인화 재정렬로 구성한다. 같은 사용자가 같은 API를 두 번 호출해도 다른 상품 목록이 내려올 수 있다.

23. 선착순·보상이 걸린 화면에서 판정을 서버에 귀속시키는 경계 설계로 레이스 없는 정합성 확보

    리테일 앱의 온보딩성 이벤트 화면을 만들었다. 사용자가 지정된 상품 중 하나를 구매하면 보상(e머니)을 지급하는 구매 미션인데, 두 가지 제약이 겹쳐 있었다.

24. 설정 3단 분리와 자격증명 귀속 설계 — 개인×리소스 교차 테이블과 폴백 차등

    사내 도구를 만들다 보면 설정 계층은 자연스럽게 세 단으로 갈라진다. 조직이 관리하는 시스템 설정, 사용자마다 다른 개인 설정, 작업 단위로 오버라이드되는 프로젝트 설정. 여기까지는 흔한 구조다.

25. 웰컴체크인 구매미션 FE/BE 경계 판단 명문화 (SCRUM-18336)

    리테일 앱의 매장 체크인 서비스에 구매미션 기능을 구축했다. 사용자가 미션 상품을 선택해 응모하면 서버가 자격을 판정하고 보상을 적립하는 구조다. 돈(적립 보상)이 걸린 도메인이라 클라이언트 상태와 서버 상태가 어긋나는 순간이 곧 정합성 사고로 이어진다.

26. FE/BE 경계 모호성에서 효과 기반 배치 원칙으로 일관된 로직 배치 달성

    커머스 서비스를 개발하면서 프론트엔드와 백엔드 사이에 비즈니스 로직을 어디에 배치할지 반복적으로 논의가 발생했습니다. 팀 내에서도 "로직은 서버에 있어야 한다"는 의견과 "클라이언트가 이미 상태를 갖고 있으니 거기서 처리하는 게 낫다"는 의견이 공존했고, 기능마다 개인 성향에 따라 결정…

27. 상태관리 라이브러리 pinia 마이그레이션

    이마트앱 프로젝트의 프론트엔드에서는 현재 Vuex를 활용하여 상태 관리를 진행하고 있습니다. Vuex는 Vue2에서 가장 널리 사용되는 상태 관리 라이브러리입니다.

28. 워크이마트 풀 피처 개발 — 기획 리뷰부터 QA 5차까지

    이마트앱의 걷기 미션 기반 시즌제 서비스 "워크이마트"를 신규 개발했습니다. QR 체크인, 걸음수 미션, 바코드 스캔, 건강 다이어리, 리워드 뽑기 등 복합 기능과 네이티브 앱 연동이 필요한 프로젝트였습니다.

29. 프론트엔드 코드 품질 시스템 구축 — ESLint 커스텀 룰부터 CI 게이트까지

    AI 코딩 도구(DevX Code, Amazon Q) 도입으로 팀의 코드 생성 속도가 급증했습니다. 하지만 AI 생성 코드의 품질 저하(Slop) 문제가 발생하여, as any 남용, 아키텍처 경계 위반, 과도한 함수 길이 등이 리뷰에서 반복적으로 발견되었습니다.

30. [SCRUM-17074] 워크이마트 프론트엔드 신규 서비스 구축 — 상태머신 설계 + 네이티브 브릿지 비동기 조율 + Composable 아키텍처

    이마트 모바일앱 내 신규 O2O 게이미피케이션 서비스 "워크이마트"의 프론트엔드 전체를 구축했습니다. 오프라인 매장 QR 스캔에서 걸음수 측정, 7종 미션 수행, 랜덤 리워드 지급, 결제 연동까지의 전체 사용자 플로우를 단독으로 설계·구현하고, QA 5차 대응을 거쳐 운영 배포를 완료했…

31. 흩어진 유틸함수(throttle/debounce/cloneDeep) → utils 중앙화 + 타입 안전 재구현

    임팩트: hooks/common.ts에 산재한 throttle·debounce·cloneDeep을 utils/index.ts로 중앙화하고, 제네릭 기반 타입 안전 구현으로 재작성. ApiResponse 인터페이스도 types/common.d.ts로 이동하여 관심사 분리 완성.