꾸준하게

다같이 계속 하다보니 서로 사는얘기하는 빈도도 늘어나는 것 같다~ ㅋㅋ다같은 취준생 입장이다 보니 공감대 형성이 잘 되는 것 같아서 좋다. 이번에 나는 preparedstatement 와 statement차이점에 대해 정리하였다. https://www.notion.so/319025901eb8802a98cbf0abeda56183?v=319025901eb880a2a618000c2d63983e&p=35dfa15530f78008b75dd9f6e49f8c48&pm=s 우리의 애플리케이션에서 PreparedStatement는 어떻게 동작하고 있는가 | Notion이 글의 목적:www.notion.so사실 이 부분까지 깊게 볼 일이 없어서 잘 모르는 부분이긴 했다. 하지만 평소에 사용하는 db io와 연관되어 있어서..

이 책은 작년 여름에 인프런 멘토한테 추천받았던 책이다. 그 회사에서 교과서로 취급받는 정도로 유명하고 좋은 책이다라고 들었다.나도 처음에 도서관에서 우연히 발견했을 때 제목부터 흥미로워서 빌렸다가 1~2장에서 그만둔 기억이 있었다. (글을 읽어도 이해가 잘 안돼서..)읽어야지 하다가 올 해 3월부터 완독을 목표로 시작하였다. 내용은 5~9장이 나한테 큰 도움이 되었던 것 같다. 분산환경에서 어떤 문제가 발생하고 해결책들이 있는지 이 과정들을 자세히 설명해주었다. 4월에 1회독 마무리를 했지만 뭔가 배운것이 제대로 머릿속에 정리가 안 된 것 같아서 노션에 정리하기도 하였다.https://www.notion.so/35afa15530f7804ebf24c5e2e6c7a192 (노션 정리 링크) 분산환경에서 ..

늦었지만 저번주에 진행한 면접 스터디 내용을 복기하려고 한다. ㅈㅎ님과 나 이렇게 발표했다. ㅈㅎ님 내용은 토스 테크 블로그의 https://toss.tech/article/34481 캐시를 적용하기 까지의 험난한 길 (TPS 1만 안정적으로 서비스하기)TPS가 평균 1만, 최대 2만까지 늘어난 약관(terms) 서버에 안정적인 서비스 제공을 위해 캐시를 적용한 이야기를 들려드리려고 해요.toss.tech해당 아티클을 발표해주셨다. 내용은 약관 서비스를 캐시 처리를 통해 db 부하를 감소시키려는 목적이었다. 조건: Strong Consistency를 유지해야 된다.약관은 개인정보와 밀접하여 철회한 이후에도 개인정보 공유가 되는 문제가 발생하면 안되기에 전략: Look-aside 패턴 이유: db의 정..

4월 초에 벚꽃 핀다고 감성에 빠져서 카페에서 회고 썼던게 엊그제 같은데 벌써 4월 마지막 날이다..4월은 그래도 몇번의 면접 경험이 생겼어서 실전 경험을 쌓을 수 있는 시간들이 되었던 것 같다. 처음에는 스타트업, 중소기업 등등 아무 곳이나 붙여주면 간다는 마인드였지만, 그래도 이왕 가는거 더 준비해서 좋은데 가고 싶은 마음이 요즘 들고 있다. 한게 아까워서.. 3 곳의 면접을 봤다. 첫번째 면접1. 우리회사 뭐하는지 아냐 -> 설명해봐라 2. btree랑 클러스터링/논클러스터링 부분 3. 자바 동시성 제어4. 이력서 기반으로 트러블 슈팅 2개 정도 확인 및 한 단계 정도 꼬리질문5. 궁금한 것 있는지 두번째 면접1. 인사담당자가 기본적인 이력 확인 및 자기소개2. 우리회사가 어떤 일을 하는지 아는지 ..

ㅈㅎ님 ㅎㅌ님과 3명이서 진행하였다.나는 토스 테크블로그의 레거시 코드 정산&배치 처리&배포 워크플로우 를 다룬 아티클을 선택하여 정리 발표하였다. https://www.notion.so/feat-335fa15530f780328bdfd1e288b7dc51 대규모 배치 시스템(feat. 토스 페이먼츠) | Notion토스 기술 블로그, 토스 테크 레거시 정산 개편기: 신규 시스템 투입 여정부터 대규모 배치 운영 노하우까지www.notion.so ㅈㅎ님은 여기어때의 Redis&Kafka를 활용한 선착순 쿠폰 이벤트 개발기 (feat. 네고왕) 아티클을 다루었다.대규모 트래픽 환경에서 선착순 쿠폰 이벤트의 정합성과 성능을 동시에 잡는 방법을 공유하였다. 요구사항1. 이벤트 기간 동안, 매일 특정 시간 오픈하..

가상 스레드에 대해 알려주는 책이다. pinning 현상에 해결된 JDK24버전까지 인지하여 작성되었다. 가상 스레드의 pinning 현상, thread local 문제점, scoped value와 같은 핵심 내용들을 포함하고 있다. 가상 스레드로 오기까지의 동시성 내용들도 순차적인 흐름으로 작성되어 있어 이해하며 머릿속으로 정리하기 편했다. 논블로킹 방식, 리액티브 프로그래밍에 대해서도 나와서 좋았다. 최근 나온 책이기도 하고 가상 스레드에 마침 공부하고 있었어서 빠르게 사서 읽어보았다. 예제가 많이 포함되어 있어 생각보다 빨리 읽었던 것 같다. 1회독으로는 아쉬운 책이라 예제 직접 돌려보며 곱씹으며 다시 볼 예정이다. 정리 링크: https://www.notion.so/33efa15530f780b..

1~2월은 거의 개인 공부하는 시간을 가졌다. 3월은 이력서를 보완하는 시간을 가진 뒤 조금씩 다시 서류제출을 시작했다. SQLD도 일단은 따면서 정량적인 스펙 하나는 추가되긴했다. 요즘 느끼는 것인데 사소한 기술 하나라도 내가 모르는, 그리고 핵심 메커니즘이 숨겨져 있을 수 있다.귀찮더라도 깊이있게 탐구해야 메리트있는 인재가 될 것 같다. (항상 그랬겠지만)그리고 AI 글이 난무하는 시대에서 진짜 내 생각을 정리하며 진정성있게 잘 표현하는 것이 중요하다고 생각이 든다. 개인 블로그를 따로 2월에 만들기도 했지만 요즘들어 이 블로그에 대한 추억이 떠오르면서 다시 애정이 가기 시작한다..템플릿을 바꾸면서 리프래시를 해보았다. 면접 스터디에 들어가며 오늘 진행 하면서 확실히 말하면서 내가 했던거를 정리하는..

현재 Buy Now 클릭 → 주문 생성 → 재고 감소 의 흐름으로 인해,결제 창에서 취소하면 재고 복구가 안되는 현상이 발생하고 있습니다. 재고 감소를 어느 시점에 하냐에 따라 로직이 변경될 수 있습니다. 저는 현재 테스트를 위해 결제 창을 껐다 켰다 하는데 재고는 계속 줄어들기에 결제 완료를 하면 재고를 감소하는 방향으로 수정하였습니다. 하지만 그 전에 이렇게 하면 생길 문제를 먼저 말씀드리겠습니다.Overselling 현상으로 예를 들어 재고 1개, 동시 결제하는 사람이 2명이면 상대적으로 늦은 사람은 0 -> -1로 재고소진하게 됩니다. 해결 방안낙관적 락 @Version OptimisticLockException을 통해 두번째 요청을 눌렀을 때는 이미 소진되었다는 문구를 띄워주는 방식으로 하면..

결제 시스템에서 가장 중요한 것은 돈은 정확하게 한 번만 나가야 한다는 것 입니다. 네트워크 불안정이나 사용자의 실수로 인해 동일한 결제 요청이 중복으로 들어오더라도, 서버는 항상 동일한 응답을 내려주어야 합니다. 이를 멱등성이라고 합니다. 저는 이를 보장하기 위해 Redis 분산 락과 캐싱 전략을 조합하였습니다. 요청이 들어오면 먼저 Redis에 해당 멱등 키로 락을 획득하려고 시도합니다. Redis의 SET NX EX 40 명령어를 사용하는데, 이는 "키가 없을 때만 값을 설정하고, 40초 후 자동 만료"를 원자적으로 수행합니다. 이 시점에 캐시가 있다면 이미 다른 요청이 처리를 완료한 것이므로, 락을 해제하고 캐시된 결과를 그대로 반환합니다. 캐시가 없다면 실제 결제 검증 로직을 수행하고, 완..

캡스톤 디자인 우수상을 받게 되었습니다...! (ㅎㅇ이가 홍보를 야무지게 잘해주심) 티모지지는 정말 2024 겨울부터 기획하여 7월까지 진행한 프로젝트로 프론트 개발까지 하느라 고생이 많았습니다..(챗지피티가 올 해 초만 하더라도 정말 바보같았다..) 에타, 단톡방에 홍보도 하며 나름 유저를 40명까지 채워봤지만 서비스가 상용화 되기에는 한계가 있었네요.... 그래도 캡스톤디자인 프로젝트로 시작해서 기승전결이 좋았기에 우수상까지 받을수도 있었나 싶습니다. 거의 6월까지는 티모지지 서비스만 생각하고 살았던 것 같습니다. 이제 AWS 프리티어도 끝나기도 했고 비즈니스적 한계가 명확하기에 보내줘야 될 때인 것 같습니다. 열심히 기획하고 개발했던 티모지지.... ㅎㅇ, ㅅㅇ 모두 고생했다.. 2026년 1..