본문 바로가기

Loopers

 (7)
머물러 있던 자리를 벗어난 10주 10주 회고10주가 지났다. 시작할 땐 이 시간이 멀게만 느껴졌는데, 막상 끝에 서서 돌아보니 눈 깜짝할 사이에 지나간 것 같다.매일이 벅찼다.하나를 겨우 이해하면 그 사이에 두세 개가 새로 밀려들었고, 못 끝낸 숙제는 다음 날의 나에게 그대로 넘어갔다.머릿속은 늘 무언가로 가득 차 있었다.다행히 내 업무는 생각보다 여유 시간이 꽤 있는 편이라,그 틈을 과제와 개념을 다시 들여다보는 데 썼다.막히는 부분을 붙들고 클로드와 이런저런 이야기를 나누며 답을 찾곤 했다. 예전엔 10시 전이면 잠들던 사람이었는데, 멘토링에 과제에 청강까지 겹치면서 잠드는 시간이 12시, 1시로 밀렸다. 힘들다는 말로도 부족한 날들이었다.그런데 이상하게도, 그 시간을 떠올리면 나쁘지 않은 기분이 남는다. 처음엔 지난 일을 미화하는..
Week 6. 이론과 수치 결제 흐름을 짜고 나서 "이 정도면 됐다" 싶었다. @Transactional 하나가 전체를 감싸고, PG 호출이 실패하면 자동으로 롤백된다. 구조도 단순하고, 동작도 맞다. k6를 돌리기 전까지는 그랬다.DB 커넥션은 유한하다. HikariCP 기본 풀 사이즈는 10이다.트랜잭션이 커넥션을 들고 있는 동안 다른 요청은 기다린다.평소엔 트랜잭션이 짧아서 문제가 없다. PG처럼 응답이 100~600ms씩 걸리는 외부 호출이 트랜잭션 안에 있으면 얘기가 다르다. 커넥션 10개가 전부 PG 응답을 기다리는 순간, 나머지 요청들은 줄을 선다.k6로 80명의 가상 유저를 붙여봤다.pool_timeout_rate가 7.02%였다. 100건 중 7건이 커넥션을 얻지 못하고 503으로 떨어지고 있었다.트랜잭션을 나눴다..
Week 5. 인덱스와 캐시 몇 백/천 줄 되어가는 쿼리의 탑을 보고 있자니 답답하기 그지없다.어느 부분을 어떻게 건드려야 할지 감이 오지 않을 때도 있고,건드렸다가 다른 곳이 무너질 것 같은 불안감도 있다.그럴 때마다 드는 생각이 있다."어디서부터 봐야 하지."---실행 계획부터 본다.쿼리가 길어도 DB 입장에서 실제로 무거운 구간은 따로 있다.전체를 다 이해하려 할 게 아니라, 비용이 가장 큰 구간을 먼저 찾는 게 맞다.EXPLAIN을 보면 각 단계의 예상 비용이 나온다.그 중 rows가 튀거나 type이 ALL인 구간이 병목이다.긴 쿼리도 결국 여러 단계의 조합이다.병목 구간 하나를 찾으면 나머지는 잠깐 눈을 감아도 된다.---그 다음엔 왜 그 구간이 비싼지를 따진다.크게 세 가지 중 하나다.첫째, 너무 많은 데이터를 읽고 있..
Week 4. 동시성 제어 동시성 문제는 무엇일까 내가 프로시저를 수정하고 있는데 다른 사람이 끼어들어 같은 프로시저를 수정한다 가정했을 때,수정 완료 후 커밋 시점엔 최종 결과가 어떻게 될까. 애초에 하나의 프로시저를 유저 여러명이서 수정할 수 있을까. 이런 고민을 하게 만드는 게 동시성 문제가 아닐까 싶다. 즉, ' A 트랜잭션이 수행되는 와중에 B가 개입하는 경우. 어떻게 할 것인가'를 고민하는 문제이다. -- 트랜잭션과 동시성 제어는 면접 단골 질문이라고 한다. 개념은 물론이거니와 이걸 어떻게 잘 설명할 수 있을지가 관건이다. 기계적으로 개념만 읊을 게 아니라 내 경험 혹은 구체화가 필요하다.그러기 위해서는 이번주차에 정확한 개념을 잡고 넘어가야한다. -- DB 트랜잭션은 안전한 데이터 처리를 위한 데이터베이스의 "실제 기..
Week 3. 도메인 주도 설계 도메인 주도 설계는 말 그대로,기술적인 인프라나 DB 스키마를 먼저 고민하는 것이 아닌비즈니스 규칙과 프로세스가 우선인 도메인 중심으로 설계를 진행한다는 것이다. 어떤 도메인들이 필요한지, 각 도메인 비즈니스 규칙과 도메인 간의 결합 등이 어떻게 유기적으로 맞물릴 수 있는가를 고민하고, 전체 구조와 흐름을 정하는 것이이번 주차의 핵심이었다. 가장 큰 틀이 되는 아키텍처부터 생각했다. -- 여러 아키텍처들이 있지만 그중 레이어드/헥사고날/클린, 이 세 가지를 비교 분석했다. 레이어드야 주로 사용하던 것이니 나름 익숙했으나 나머지 둘은 개념조차 모를 정도로 생소했다.하지만 레이어드 또한 알면 알 수록 내가 깊이 있게 이해하고 있지 않았구나 싶었다. 셋 모두 비즈니스 로직이 인프라를 몰라야 한다는 동일한 문제..
Week 2. 설계는 선택의 연속이다. 화면 개발 기획서를 받아 볼 때마다데이터를 어떻게 긁어와 보여줄지 쿼리부터 생각하곤 한다. 체계적으로 문서화가 되어 있는 게 아니다 보니 경험에 많이 의존하는 편이다. 요구사항 분석 > DB 설계 > 서비스 API 설계 > 구현 순으로 진행되며,분석/설계와 구현의 비율이 대강 6:4정도 되는 듯하다. 그렇기에 지난주와 마찬가지로 이번 주차의 요구사항 분석/설계도 살짝 어색했다.이론이야 대학, 교육, 면접준비로 학습했었으나 실무에 적용하지 않으면 무용지물이다. 유저 시나리오는 TDD처럼 여러 케이스를 상정하고 개발하고 있다쳐도,다이어그램은 실서비스에 적용한 적이 없었다. 그럼 이번 과제는 어떻게 할까. 일단 클로드에게 시켜보자.기본 요구사항은 '사용자' 입장에서의 '상품', '좋아요', '주문'에 대한 액..
Week 1. 모든 게 처음이었다. 하나부터 열까지 다 생소했다. 3년 넘게 전자정부프레임워크 기반 스프링프레임워크만을 사용하며,형상관리는 SVN 통해 진행하다 보니 스프링 부트와깃허브는 손에 익지 않아 어색하기만 했다. 이름들만 들어봤던 레디스, 카프카, 살짝 발만 담갔던 도커,그리고 클로드 코드 첫 결제까지. 통계 자료나 보고서 형식의 화면 단위를 개발하다 보니,레거시 코드에서 새롭게 추가하거나 변형을 하기에는 어려움이 있어 약간의 조회 속도 개선이나 코드 경량화 외에는 계속해서 쿼리만 작성했다. 그렇기에 발제를 듣고 프로젝트를 열어봤을 땐 한 없이 막막하기만 했다. 사실 신청 이전에 전기수들의 WIL을 훑어보고,어떤 커리큘럼으로 진행되겠구나 정도는 파악하고 왔다. 하지만 막상 귀로 듣고 눈으로 보고 있자니,'저 사람들이 무슨 말을 하..

티스토리툴바