hojak99 의 블로그

어쩌다보니 테크스펙 문서들을 작성해보게 되었다. 테크스펙 문서가 어떤 문서인지에 대해서는 다른 곳에서 너무 잘 이야기해주고 있어서 패스하겠다. https://blog.banksalad.com/tech/we-work-by-tech-spec/ https://infraeng.dev/tech-spec/ 처음엔 누군가 시켜서 작성을 하게 되었다가 장점을 맛본 뒤에는 누가 시키지 않더라도 테크 스펙 문서를 작성하게 되었다. 아래에 상황들에 놓여져 있다보니 자연스럽게 테크 스펙 문서를 작성하게 되었던 것 같다. 특정 서비스의 히스토리와 관련 도메인을 아는 사람들이 퇴사하면서 나 밖에 남지 않았고 서비스를 개선하려거나 기능 추가를 하려고 할 때, 관련 배경이나 도메인을 모르는 팀원들이 대부분이라 리뷰를 받기 어렵다. ..

보호되어 있는 글입니다.

chatGPT 라는 놈을 요즘 아주 유용하게 사용하고 있다. 예전엔 질문들을 할 곳이 마땅치도 않아서 블라인드 it 엔지니어 게시판에 질문글 올리거나 했는데.. 나는 로그를 수집하고 프로세싱 과정을 거쳐 어딘가에 저장을 할텐데 어떤 식으로 처리를 하는지 일련의 과정들이 궁금해졌다. kinesis 와 spark 를 사용한다는 전제 하에 얘기를 해보겠다. kinesis 와 spark 는 어쨌든 실시간 데이터를 분석하고 처리하는 시스템인데.. 큰 차이점이 있다고 한다. kinesis 는 aws 에서 제공하는 서비스로 실시간 데이터를 수집하고 처리 및 분석을 하고 spark 는 오픈소스이며 대량의 데이터를 병렬로 처리할 수 있다고 한다. 그리고 데이터를 처리하기 위해 여러 라이브러리들을 제공하는 것으로 보인다...

먼저, 테스트 코드를 짜기 쉬운 코드가 있고 테스트 코드를 짜기 어려운 코드가 있을 것 같다. 내가 생각하는 테스트 코드를 짜기 쉬운 코드는 다음과 같다. 막상 생각하려니 잘 생각이 나질 않는다. SOLID 원칙을 적절히 지킨 코드 하나의 메소드가 여러 행위를 구현하지 않은 코드 (1의 연장선이겠지만) 길이가 짧은 메소드 (2의 연장선이겠지만) if, else 가 적은 메소드 만약 이런 코드가 존재한다면 어떻게 테스트 코드를 짜야할까? fun register(request: Request) { checkValidPhone(request.phone) checkValidEmail(request.email) checkAgreeMarketing(request.isAgreeMarketing) val user = ..

보호되어 있는 글입니다.

나중에 귀농을 한다고 생각해보자. 나는 비닐하우스에서 어떠한 작물을 키우는데 이 작물은 귀해서 키우기 굉장히 까다로웠다. 나는 이런 까다로운 조건을 알기 귀찮아서 자동화 작업을 외주로 맡겼으며, 자세한 조건은 모르지만 작물을 키우기 위해선 아래와 같은 조건들을 지켜야 한다고 가정해보자. 1. 매일 작물이 말랐을 때마다 물을 줘야 한다. 이때 작물의 성장에 따라 말라가는 속도가 다르다. 2. 물을 줄 때 작물의 성장 정도에 따라 물의 양을 다르게 주어야만 한다. 3. 이 작물은 해가 가장 높게 떴을 때에 해당하는 시간 대에 햇살을 쐬게 해주어야 한다. 4. 이 작물은 병에 잘 걸린다. 잎사귀가 썩고 나서부터 1시간 뒤 내에 병에 맞는 약을 뿌려주어야 살 수 있다. 이 작물이 걸릴 수 있는 병의 가짓수는 5..

소프트웨어 아키턱처 101 이라는 책을 읽고 있던 중, 아키텍처 카타(atchitecural kata)라는 것이 나왔다. Ted Neward 라는 아키텍트가 초보 아키텍트가 도메인에 관한 설명을 보고 아키텍처 특성을 도출하는 연습을 할 수 있도록 아키텍처 카타라는 것을 고안했다고 한다. 나는 설계하는 경험은 쉽게 얻을 수 없다고 생각한다. 그렇기에 막상 설계를 해야하는 상황이 닥치면 실수를 꼭 한 가지 이상은 하게 될 가능성이 높다. 나도 물론 그랬다. 코드에 대한 예제가 많는 많다. 예를 들어 클린 코드 같은 여러 도서들에선 이런 코드가 낫다고 말하며 코드를 많이 보여준다. 그러나 설계는 그 예가 별로 없다. 있어봤자 유투브에서 외국인이 트위터를 설계하는 동영상 정도? 그렇기에 연습을 꼭 해야한다고 생..

이 글은 데이터 중심 애플리케이션 설계 라는 책의 내용을 기반으로 제가 이해한 것들을 작성했습니다. 데이터 중심 애플리케이션 설계 라는 책에서는 소프트웨어 시스템이 신뢰성, 확장성, 유지보수성 이라는 세 가지 관심사에 중점을 둔다고 한다. 신뢰성: 시스템은 지속적으로 올바르게 동작해야 한다. 확장성: 시스템의 데이터 양, 트래픽 양, 복잡도가 증가하면서 이를 처리할 수 있는 방법이 있어야 한다. 유지보수성: 모든 사용자가 시스템 상에서 생산적으로 작업할 수 있게 해야 한다. 신뢰성 - 사용자가 기대한 기능 수행한다. - 사용자가 범한 실수, 예상치 못한 사용법을 허용할 수 있다. - 성능은 예상된 부하와 데이터 양에서 필수적인 사용 사례를 충분히 만족한다. - 허가되지 않은 접근과 오남용을 방지한다. 즉..

이제 "판매 상품" 들을 장바구니에 담아보자. 쿠팡에서는 크게 "로켓와우" 라는 정기 구독 상품과 판매자들이 등록한 일반 결제 상품이 존재하는 것으로 보인다. 네이버 스마트 스토어에도 판매자들이 등록하는 정기 구독 상품과 일반 결제 상품이 존재한다. 이렇게 각 서비스들은 "정기 구독 상품" 과 "일반 결제 상품" 이 존재할 수 있다. 그러나 일반적인 서비스들에서는 장바구니에 "정기 구독 상품" 과 "일반 결제 상품" 을 함께 장바구니에 담거나 하지 못하는 것으로 보인다. 그래서 다른 서비스들과 다르게 하나의 장바구니에 "정기 구독 상품" 과 "일반 결제 상품" 을 같이 담아 한 번에 결제 할 수 있도록 하는 기능을 개발하게 된 이야기를 작성해보도록 하겠다. 결과론적으로 보면 이 결정으로 인해서 마이페이지..

''왜" 라는 질문을 계속 던지며 이야기를 해보자. 데이터를 가져올 때 MySQL 과 Redis 의 속도는 뭐가 더 빠를까? 1. 디스크, 메모리 관점 2. redis 는 딕셔너리 기반인데 key 로 찾을 때 어떤 식으로 데이터를 찾는지 3. 메모리 꽉차면 스왑 영역 (디스크를 메모리 대신 이용하는 부분) 4. 메모리 파편화 대해서 5. mysql pk 로 접근하면 왜빠른가? clustered index, nonclustered index