[Week3] WIL - 레디스 부수기

지난주와 비슷한 흐름으로 알고리즘 2주차가 진행되었고, 수요코딩회를 끝으로 한 주를 마무리 하게 되었다. 딱히 전 주차와 다른 점이 없었기 때문에 3주차 첫째날에 계획했던 내용이 얼마나 지켜졌는지를 평가해보고 바로 배운 내용에 대해서 적어보려고한다.

 

핵심 역량 평가

역량	달성도	목표
문제해결	50%	백준 실버1~2 수준의 문제를 AI, 구글링 도움 없이 풀 수 있음.
아직 실버 상위권 문제들을 쉽게 풀어내는 수준까지는 도달하지 못한 것 같다.
설계	70%	최대한 효율적인 코드(시간 복잡도/공간 복잡도 고려)를 짜는 것을 목표로 한다.
최대한 시간 복잡도를 낮추는 방식으로 코드를 짜려고 노력했다.
구현	60%	문제당 실패 횟수를 3회 이하로 한다.
여전히 문제 조건을 똑바로 확인하지 않아 여러번 틀린 문제들이 있었다.
품질	90%	수요코딩회에서 버그없이 돌아가는 결과물을 만든다.
의도한 동작들이 모두 버그없이 돌아가는 미니 레디스 프로젝트를 완성했다.
유지보수	70%	주석을 통해 명확한 풀이를 기록한다.
과정이 복잡한 내용은 주석을 통해 재학습이 편하도록 했다.
협업	50%	코어타임 뿐만 아니라 팀원들과 적극적인 교류를 한다.
코어타임을 2번으로 늘리는 방법을 택했지만, 그 외의 시간에 소통자체는 아직 부족했던 것 같다.
태도	80%	모르겠는 문제에 대해 절대 AI를 사용한 코드 생성을 하지 않는다.
최대한 개념 학습을 할 때만 도움을 받았고, 코드 생성은 최대한 하지 않으려고 노력했다.
AI 활용	80%	맞힌 문제라도 AI에 코드 리뷰를 맡겨 더 최적화된 방법이 있는지를 모색한다.
문제를 해결했어도, 더 좋은 방법이 있는지 AI에게 코드리뷰를 맡겨보았다.
학습 민첩성	80%	수요코딩회에서 레디스에 대한 개념을 탑다운 방식으로 빠르게 학습한다.
처음 접해보는 개념이지만 직접 설계해보고, ai를 통해 탑다운으로 학습함으로써 레디스에 대한 개념을 빠르게 학습할 수 있었다.

 

이번 주의 문제 - 뱀

이분 탐색, 분할 정복, 퀵정렬, 머지정렬, 스택, 큐.. 지난주보다 더 다음단계의 개념들을 다루다보니 문제들의 평균난이도가 확 올라간 느낌이었다. 한 주 동안 문제를 풀면서 가장 기억에 남았던 뱀 문제를 다시 풀이해보며  학습한 내용을 복습해보고자 한다.

 

https://www.acmicpc.net/problem/3190 - 뱀

 

간단히 말해서, 충돌하기 전까지 반복되는 스네이크 게임을 몇 턴 동안 진행할 수 있는지 측정하는 문제이다.

문제를 해결하면서 가장 고민을 많이 했던 부분은 뱀의 방향을 어떻게 돌릴것인지에 대한 것이었다.

쭉 직진을 하는 구조라면 쉽겠지만, 방향을 틀었을때는 그 방향으로 다시 직진을 해야 한다.

처음에는 딕셔너리처럼 방향에 따라 움직이는 로직을 따로 구현해야하나 싶었지만, 뱀을 위에서 보는 시점에서 절대 방향이 바뀌는 것이 아니라 뱀의 머리를 기준으로 방향을 돌려 계산해야했기 때문에 어떻게 해야하는지 감이 오지 않았다.

 

결국 이 부분은 GPT의 도움을 받았고, 실용적인 방법을 하나 배울 수 있었다.

 

dir_x = [0, 1, 0, -1]
dir_y = [1, 0, -1, 0]
direction = 0

 

이런 식으로 x, y 인덱스의 값들을 저장해두고, 머리를 돌릴때마다 direction 값을 +1 혹은 -1 한다. 그리고 다음 머리의 위치를 계산할때 dir_x의 인덱스 값으로 direction을 넣어서 활용한다.

head_x = head_x + dir_x[direction]
head_y = head_y + dir_y[direction]

 

이러면 direction 값 하나만 바꿔도, 머리의 x, y 위치를 적절하게 계산할 수 있다.

 

이렇게 하고 넘어갔는데 다른 분이 상당히 흥미로운 방식으로 문제를 해결하셨길래 따로 추가 학습을 해보았다.

방향을 돌릴때 행렬곱 연산을 하는 방법이다.

 

행렬곱 연산을 통한 회전 인덱스 구하기

회전이란 결국 숫자의 위치를 바꾸는 것이다.

(0, 1)에서 우회전하면 아래 (1,0)이 되어야 한다. 또 아래 (1, 0)에서 우회전하면 왼쪽 (0, -1). 잘 보면 규칙이 있다. 
이런식으로 보면 우회전과 좌회전은 특정 식으로 표현할 수 있다.

우회전 규칙 : (dx, dy) -> (dy, -dx)
좌회전 규칙 : (dx, dy) -> (-dy, dx)

 

코딩을 할 때는 굳이 행렬 형태로 계산을 안하고, 결과 규칙만 외워서 사용하면 되는 것이다.

수학적인 개념을 접목 시키는 방법은 전혀 고려해보지 못했는데 덕분에 문제 푸는 시야가 넓어진 듯한 기분이었다.

 

게임 종료 조건 확인

뱀 문제가 어려웠던 또 하나의 이유는 조건이 굉장히 복잡하다는 것이다.

while True:로 반복을 돌리면서 충돌 조건을 검사하고, 시간을 늘리고, 방향을 조절하는 로직을 반복하였다.

 

1. 다음 머리 위치 계산

while문의 마지막에서 direction 값을 갱신하므로 그 값을 통해 다음 머리의 위치를 계산한다.

 

2. 벽 충돌 체크

머리의 다음 위치가 벽에 충돌하는지를 체크하는 조건문이다. 

 

3. 몸통과의 충돌 체크

뱀이 지나간 곳에는 'snake'라는 문자열을 저장하고 넘어가는 방식으로 구현하였다. 그래서 다음 머리의 위치 값이 snake라면 종료시키는 로직을 수행한다.

 

4. 사과 유무 확인

이 문제에서는 사과를 먹으면 머리만 늘어나고, 꼬리는 그대로 남겨둔다. 따라서 다음칸이 'apple'인지 판별하고, 사과가 아니라면 snake deque 객체에서 popleft를 하여 꼬리칸 인덱스를 제거한다. 그리고 해당 칸을 다시 'X'로 되돌려 놓는다.

 

여기서 3번, 4번 로직을 반대로 짰을때 문제가 생겼었다. 이동할때 사과인지 판별하고 꼬리를 먼저 지워버리면, 해당턴에서 원래 충돌이 나야되는 상황인데 꼬리가 pop 되면서 통과해버리는 문제가 있었다. 3번째 테스트케이스가 자꾸 failed가 떠서 디버깅을 하던 도중 알게된 문제였다.

 

5.  몸통 이동

해당 인덱스로 머리를 이동시킨다. 실제로 이동시키는 개념은 아니고 snake 큐에 해당 칸 인덱스를 튜플로 append하고, 보드에 'snake'라는 문자열을 남긴다.

 

6. 시간 증가 및 방향전환

몸통이 이동했으면 해당 턴이 끝났다는 것을 의미하므로 시간을 증가시키고, 방향을 전환시킨다.

 

문제 조건들이 복잡해보여서 설계를 하는 과정에서 굉장히 오랜시간이 걸렸지만, 재미있게 푼 문제였고 해결했을때 기분이 매우 좋았다.. ㅎㅎ. 근데 앞으로는 일정 시간을 정해놓고 그 안에 못 풀면 AI 도움을 받는 식으로 하는것도 좋겠다는 생각이 들었다. 물론 스스로 문제를 해결하면 학습효과가 더 좋겠지만 해야할 것이 많은 정글 특성상 너무 많은 시간을 하나의 문제에 할애하면 다양한 개념을 학습하는 것에 어려움이 있을 수도 있을 것 같다.

 

수요 코딩회 - Mini-Redis 구현하기

3주차 수요 코딩회 주제는 Mini-Redis 구현하기였다. Redis에서 제공하는 캐시 시스템을 간단히 구현하고, 디스크 접근과 시간차이를 확인해보는것을 주요 목표로 삼고 설계를 진행하였다.

초기 설계

 

처음에는 FastAPI 서버 내에 Mini-Redis, fake_db 파일을 동시에 넣어 두려고 했다. 어차피 캐시가 존재할때 fake_db에 접근하지 않고, 시간이 더 짧게 걸리는 것을 보여주는게 목표였기 때문에 간단하게 하는것을 목표로 했다. 둘 다 서버 내에 있기때문에 속도차이가 안 나는 것은 당연하기 때문에 fake_db 에 접근할때만 sleep()을 걸어서 고의로 시간을 늦추는 방식으로 보여주기식 설계를 한 것이었다. 하지만 실제 Redis는 별도의 서버로 두고 요청하는 구조인데, 우리는 내부 자료구조처럼 접근하고 눈속임으로 sleep만 건 형식이라서 적합하지 않다고 판단했고 결국 오후에 구조를 엎었다.

 

수정한 미니 레디스 구조

 

수정된 구조이다. FastAPI 서버 내에 있던 db와 Mini-Redis를 모두 밖으로 뺐다. db는 로컬 Mongodb를 만들어서 몽고 클라이언트로 접근하게끔 했고, Mini-Redis는 별도의 FastAPI 서버를 열어서 기존 서버와 HTTP 요청을 주고 받게끔 했다. 대시보드 FastAPI 내에 있는 board_service.py가 Mini-Redis에 캐시 Get 요청을 보내고, 리턴값이 dict 타입이면 cache hit로 판단하여 클라이언트에 바로 값을 전송한다. 즉, db를 거치지 않고 바로 값을 응답하는 것이다. 반대로 dict 타입이 아니거나 None이면 db에 가서 원본 데이터를 저장하고, Mini-Redis에 캐시를 저장하고, 클라이언트에 값을 보낸다. 따라서 캐시로 값을 응답 받았을때 시간이 더 빠를 수 밖에 없다.

 

시연용 대시보드

자주 접근하는 게시글을 캐시에 담아두고, 재접근할때 속도가 줄어드는 것을 시각적으로 보여주기 위한 게시판 웹을 Codex를 통해 구현하였다. 처음 누르는 글은 DB READ를 하여 시간이 오래걸리고, 해당 캐시의 TTL이 만료되기 전에 누르면 CACHE READ를 하여 시간이 적게 든다. 테스트 했을때 약 4~6배 정도 캐시 접근이 더 빠른것으로 측정되었다. 우리는 레디스 서버에 HTTP 요청을 하기 때문에 실제 레디스만큼의 성능을 보여줄 수는 없었던 것 같다.

 

프로젝트 피드백

발표 이후, 캐시에 데이터를 저장하는 시점에 대한 고려가 부족하다는 피드백을 받았다.
본 프로젝트에서는 캐시의 조회 성능 향상에 초점을 맞추었으며, 캐시 저장 타이밍에 대해서는 별도의 전략을 수립하지 않았다.

현재 시스템은 Cache Aside 패턴을 사용하고 있다. 즉, 요청이 발생하면 먼저 캐시를 조회하고, 캐시에 데이터가 없을 경우 DB에서 데이터를 조회한 뒤 캐시에 저장하고 응답하는 방식이다. 이후 동일한 요청에 대해서는 캐시를 통해 빠르게 응답할 수 있다. 이 방식은 조회 빈도가 높고 데이터 변경이 적은 경우에 적합하다. 그러나 데이터의 특성에 따라 캐시 저장 전략을 달리 적용할 필요가 있다.

 

먼저, 변경이 잦은 데이터의 경우에는 Write Through 방식을 고려할 수 있다. 이는 DB에 데이터를 저장할 때 동시에 캐시에도 반영하는 방식으로, 캐시와 DB 간의 일관성을 유지할 수 있다는 장점이 있다. 반면, 쓰기 연산 비용이 증가하며 실제로 활용되지 않는 데이터까지 캐시에 저장될 수 있다는 단점이 존재한다.

 

또한, 성능이 중요하고 일부 데이터 유실을 허용할 수 있는 경우에는 Write Back(Write Behind) 방식을 사용할 수 있다. 이 방식은 먼저 캐시에 데이터를 저장한 뒤, 이후 비동기적으로 DB에 반영한다. 이를 통해 높은 쓰기 성능을 확보할 수 있지만, 시스템 장애 발생 시 데이터 유실 가능성이 존재한다는 한계가 있다. 결론적으로, 캐시는 단순히 조회 성능을 개선하기 위한 도구가 아니라, 데이터의 변경 빈도, 정합성 요구 수준, 성능 요구사항 등을 종합적으로 고려하여 저장 시점과 전략을 설계해야 하는 요소임을 확인하였다.