카테고리 없음

[유레카 4기 후기 : 5월 마지막 주 TIL 5/25-5/31]

superpark 2026. 5. 31. 21:52

[TIL] 2026.05.31 - 백엔드 & 프론트엔드 핵심 기술 심화 정리

1. 백엔드 - 데이터 저장과 제어의 진화

① MyBatis - SQL 완전 통제

  • 작동 원리: Java 코드와 SQL을 XML이나 어노테이션으로 분리해. @Mapper 인터페이스와 XML의 id를 연결해서 SQL을 실행하지.
  • 언제 써?: 복잡한 통계 쿼리, 여러 테이블 조인, 정밀한 성능 튜닝이 필요할 때 최고야.
  • 단점: 테이블 100개면 SQL도 100세트... 단순 CRUD 반복 작업이 피로를 유발해.
  • 핵심 포인트: SQL을 직접 관리하니까 DB에 어떤 쿼리가 날아가는지 100% 알 수 있어. 오늘 member를 members로 잘못 써서 에러 난 것처럼, 사소한 SQL 오타가 에러의 원인이 되는 걸 직접 겪어봤어.. ㅠ  하나씩 가까워지고 있다는..

② JPA -객체 중심의 혁명

  • 핵심: ORM 기술로 DB 테이블을 Java 클래스(엔티티)와 1:1로 매핑해. SQL 없이 자바 객체만으로 DB를 제어하지.
  • JPQL: 테이블이 아닌 객체를 기준으로 쿼리를 짜는 JPA 전용 언어야.
  • 주의사항 (SQL 필수): SQL을 모르면 JPA 내부 쿼리를 파악할 수 없어. 그래서 MyBatis로 SQL 기초를 먼저 다지는 게 정석이야.
  • N+1 문제: 회원 100명을 조회하면서 각 회원의 주문 정보까지 가져올 때, 쿼리가 1번(회원 조회) + 100번(각 주문 조회)으로 나가는 현상이야. 이거 모르면 성능 박살 나니까 무조건 기억해야 해.

③ MongoDB - 유연한 비정형 데이터 창고

  • 구조: 스키마가 없는 JSON 형태의 문서(Document)를 저장해. MySQL이 칸이 정해진 표라면, 얘는 자유로운 창고지.
  • 활용: 클릭 로그, 에러 로그, 접속 기록처럼 형태가 제각각이고 엄청나게 쌓이는 데이터를 처리할 때 유리해.
  • 실무 하이브리드: 사원 정보나 예매 내역은 정확한 MySQL에, 사용자 행동 로그는 유연한 MongoDB에 저장하는 식으로 같이 쓰는 게 실무 국룰이야.

2. 프론트엔드 - 사용자 경험(UX) 설계의 핵심

① RBAC (권한 기반 접근 제어)

  • 설계: GUEST, USER, AGENT, ADMIN 등 권한별로 인터페이스를 다르게 구성해.
  • 조건부 렌더링: 단순히 버튼을 숨기기만 하면 개발자 도구로 다 뚫려. 서버에서 받은 권한 정보를 바탕으로 컴포넌트 자체를 다르게 그려줘야 해.
  • 인터셉터 패턴: 권한 체크 로직을 한곳에 모아두면, 나중에 등급이 추가되어도 관리가 너무 편해. 오늘 코드에서 loggedInRole 하나로 전체 버튼 상태를 제어한 게 이 원리야.

② 동적 필터링과 데이터 렌더링 (최적화)

  • 메모리 필터링: 검색어 입력할 때마다 DB에 쿼리를 날리면 너무 느려. 처음에 데이터를 메모리에 다 올려두고 필터링하면 화면이 훨씬 부드러워져.
  • 테이블 렌더링: tableModel.setRowCount(0)으로 기존 데이터를 비우고, addRow()로 새 데이터를 채우는 방식을 써. 화면 전체를 다시 그리지 말고, 변경된 데이터만 교체해서 화면 깜빡임을 없애는 게 핵심이야.

③ 상태 관리와 UI 피드백

  • 상태 관리: loggedInMemberId, loggedInRole처럼 화면을 바꿔야 하는 조건들을 관리하는 거야.
  • 방어적 UI: 로그인 전에 예매 버튼 누르면 로그인하세요 팝업 띄우는 것! 잘못된 흐름을 아예 막아서 서비스를 안전하게 지키는 거지.
  • 피드백: 로그인 성공 시 statusLabel 색상 변경, 텍스트 변경, 버튼 활성화/비활성화가 동시에 일어나야 해. 시스템이 내 행동에 즉각 반응한다는 걸 사용자가 느껴야 서비스가 살아있는 느낌을 받거든.

이거 뭔 말이야? 어려웠던 부분 다시한번 정리 

1. N+1 문제, 왜 이렇게 강조해?

JPA가 코드를 줄여주니까 너무 편하잖아? 근데 시스템이 뒤에서 쿼리를 100번 넘게 날리고 있다면? 사용자는 화면 보려고 몇 초씩 기다려야 해. 편한 도구 뒤에 숨겨진 비용을 파악하는 게 고수의 조건이라서.

2. 인터셉터 패턴, 한 곳만 수정하면 된다는 게 무슨 뜻이야?

만약 네가 100개의 페이지마다 로그인했어? 라는 코드를 다 넣었다고 쳐. 나중에 AGENT 등급도 추가해줘 하면 100군데를 다 수정해야겠지? 근데 인터셉터는 모든 요청이 지나가는 관문이야. 여기서 로그인했나? 권한은 있나? 딱 한 번만 체크하면 100개 페이지가 알아서 보호받아. 유지보수 생산성이 차원이 다르지.

3. 상태 관리와 UI 피드백, 왜 이렇게까지 신경 써?

사용자는 기계가 아니야. 버튼을 눌렀을 때 아무 반응이 없으면 어? 고장 났나? 하고 계속 누르거나 창을 닫아버려. 상태가 바뀌면 반드시 UI로 표현(피드백)해 줘야 사용자가 아, 잘 되고 있구나 하고 안심하게 되는 거야. 이게 좋은 서비스랑 나쁜 서비스의 차이거든.