1주차 - WIL (Weekly I Learned)

＊계획 : WIL에 적은 것들을 뽑아서 제목에 맞춰 다시 정리 필요 (WIWL은 깃헙 프로젝트 칸반보드로 관리)＊

- 배운것 <2026-03-03 ~ 2026-03-06>

<DB 관련>

- mongodb는 nosql이라 데이터의 정렬 기준이 없음

  - 1000개 이상의 데이터를 정렬 해야한다면, 백엔드에서 db로 정렬 처리를 해서 데이터를 뿌려주는 것이 좋다. 하지만 그보다 적을 경우는 프론트에서 정렬을 사용해도 문제가 없다.

 

- 동시성 문제 제어

- 낙관적 락(Optimistic Lock)과 비관적 락(Pessimistic Lock)

  - 기존에 알고 있던 방식은 OracleDB를 사용할 경우, 조회 쿼리에 FOR UPDATE; 문만 추가해주고 하나의 트랜잭션으로 엮으면 되었다. (RDBMS) 이 방식은 비관적 락으로 낙관적 락이란 개념을 처음 알게 되었다.

  - 둘 다 동시성 제어(Concurrency Control)로 동시에 같은 데이터를 수정할 때 발생하는 충돌을 처리하기 위한 방법

  - 큰 차이

구분	비관적 락	낙관적 락
락 위치	DB	애플리케이션
충돌 처리	충돌을 미리 방지	충돌 후 감지
방식	DB row lock	version 검사
대기 여부	대기(blocking)	즉시 실패
성능	충돌 많을 때 안정적	충돌 적을 때 유리
충돌 지점	UPDATE	UPDATE

  - 비관적 락으로 (하나의 트랜잭션 안에 아래 SELECT FOR UPDATE (행 락)가 존재하는 개념)

SELECT ... FOR UPDATE;

- 낙관적 락으로 (버전 관리를 통해 처리 가능)

  - 버전관리는 데이터를 프론트에서 지정해서 넘겨주는 작업임

  - 만약 삭제 시 version이 4로 업데이트가 된 상태로 있는 거면 삭제가 불가능!!

  - 업데이트는 3을 찾았는데 없으면 version이 4로 업데이트 된 상태라는 의미!!

DELETE FROM post
WHERE id=1 AND version=3;


UPDATE post
   SET version = 4
 WHERE version = 3;

- 위와 다르게 Atomic Update (UPDATE likes = likes + 1)로 버전이 아닌 숫자값으로 관리하는 방법이 있음 (보통 예시와 같이 좋아요 같은 것과 관련이 있음)

 

- INSERT 관련 동시성 제어

  - 이것은 DB에 Unique 컬럼을 둬서 관리

 

<백엔드관련>

- JINJA2 에 대해서

  - SSR(Server Side Rendering) 서버에서 알고 있던 게 JSP 밖에 없었는데, JINJA2 라는 것을 새롭게 배웠다.

  - 백엔드를 다루지 않고 프론트만 다뤄봐서 {{}} {% if %} {% end if %} {% for %} {% end for %} 안에 데이터를 집어넣는다는 것은 아는데, 제대로 사용해보진 못했던 것 같다. (ajax로 거의 다 처리)

  - 초기 화면 렌더링 시 (달력을 그렸을 때 사용했었고) 나머지는 ajax를 통해 화면 일부를 갱신하는 데 다 사용했다.

  - 프로젝트를 업데이트 할 경우 만들어야겠다.

 

- Flask란?

  - Python으로 웹 서버와 웹 애플리케이션을 만들 수 있는 가벼운 웹 프레임워크

  - Python으로 웹사이트나 API서버를 만들 때 사용하는 도구

 

<프론트관련>

- 실시간 통신 개념

- 기존 AJAX(비동기 통신) API는 실시간으로 통신을 주고 받는다고 착각하고 있었다.('polling'이라 진짜 실시간은 아니라고 한다.)

  - 'polling'이란

    - 하나의 장치(또는 프로그램/클라이언트)가 다른 장치(또는 서버)의 상태를 일정한 주기마다 주기적으로 검사하여 데이터를 송수신하거나 상태 변경을 확인하는 방식

    - 만약 ajax로 실시간 웹 사이트를 구축하기 위해서는 setInterval을 사용해 30초나 15초로 설정을 해야하는게 가장 부담이 덜함(몇 초 늦게 반영되어도 서비스 가치가 크게 떨어지지 않는 경우에 주로 사용 - 이메일의 알림 개수 갱신)

    - 따라서 실제로 지속 실시간 서비스에는 WebSocket과 Server-Sent Event (SSE) 서버 방식을 채택한다고 함

  - ' WebSocket'

    - 클라이언트와 서버가 하나의 연결을 계속 유지하면서 양방향으로 실시간 데이터를 주고받는 통신 방식

    - 기존 HTTP는 Request -> Response 구조 : 클라이언트가 요청해야만 서버가 응답 가능

    - 하지만 WebSocket은 연결을 한 번 맺으면 지속적으로 연결 유지 (Full-Duplex 통신)

    - WebSocket도 처음에는 HTTP Request로 시작하고, 서버가 응답하면, HTTP -> WebSocket 프로토콜로 업그레이드 (TCP 기반 WebSocket 연결 유지)

    - 강력하지만, 운영 비용이 있음(인프라 부담이 있다고 함)

  - 'Server-Sent Event (SSE) 서버'

    - 서버 -> 클라이언트로 계속 데이터를 흘려보내는 방식

    - HTTP 연결을 길게 유지하는 것

      - 사용자가 서버에 계속 보낼 필요가 없을 경우 사용 (새 알림, 댓글 알림, 좋아요 알림)

      - ChatGPT 같은 서비스도 SSE방식을 사용함 (아래처럼 하나씩 응답을 생성해서 보내줌)

        - Hello

        - Hello wor

        - Hello world

- READ 목적이 아닌 화면이고, 데이터수정변경이 생겨야 하는 화면일 경우 모달창 쓰면 안되고, '페이지 이동' 으로 구현해야 함.

  - 모달창은 리다이렉트 시 다시 열리지 않으므로 (UX적으로 이상함)

  - 실시간 체크를 위해 비동기 통신(ajax)를 시간단위로 여러번 보내면 되긴 한데 실시간이 힘듦

  - 따라서 사용했던 방식 (prepend로 직접 댓글을 올릴 때마다 삽입해주는 방식)

    - 문제점1 : 댓글 모달창을 열고 있는 다른 사람은 댓글이 올라온 것을 확인하려면 다시 또 새로고침하고 모달 창을 열어야 한다.

 

 

<AI관련>

1. 프롬프트 엔지니어링은 특정 ID를 둬 계속해서 기록을 저장해두는 것이 좋다. (하지만 프로젝트하지 않는 이상은 평상시에는 귀찮아서 사용하지 않을 예정)

 

2. ChatGPT, Gemini, XAi, Claude, Cursor 또 뭐가 있을까? AI LLM툴들을 많이 알아두는 것도 좋을 듯 하다.

 

<알고리즘 관련>

 

---

전체적으로 정리해야할 내용 (학습하면서 정리가 확고하게 되면 - 안되면 안되는데...)

1. 동시성 문제 제어

2. 실시간 통신 개념