WOONY's 인사이트

TL;DR: 핀테크라면 닥치고 DECIMAL이다 명심해라 Introduction 지난 달까지 넥스트스텝에서 진행하는 ATDD(Acceptance Test Driven Development) 강의를 들었다. 지난 TDD 강의와 마찬가지로 이번 강의 역시 아주 훌륭했다. 특히 실무에 적용한다는 관점에서 볼 때 TDD는 단위 테스트 위주라 서비스 레이어에 비즈니스 로직이 올라가있는 레거시 환경에서는 실천하기가 꽤나 어려웠다. 반면 ATDD는 도메인 레이어부터 짜는 방식이 아니었다. 인수 조건을 설정하고 가장 바깥에서부터 Integration test를 작성했다가 다시 가장 안쪽으로 돌아와 도메인 테스트를 작성하는 등, 작성자가 입맛에 맞게 그때그때 편한 방향을 추구하면서 자유롭게 테스트를 짤 수 있어 실무에 ..

Introduction 시작부터 꽤나 자극적이긴 한데.. 어느 정도는 맞다고 생각한다. 내가 그런 생각으로 이벤트를 신청했기 때문이다. 개발자 관련 도서 출판사로 유명한 제이펍에서 인스타를 통해 서평단을 모집한다는 공고를 발견하고 지원했다. 지원글에 이렇게 작성했다. 폴리글랏을 꿈꾸는 백엔드 개발자입니다. 회사에서는 자바/코틀린, 사이드 프로젝트는 파이썬을 쓰고 있는데요. 러스트는 이전부터 배워야지, 배워야지 생각만 하고 차마 시도는 해보지 못했던 언어입니다. 워낙 접할 경로가 없다보니 낯설어서 그런 게 가장 큰 이유인 것 같습니다. 이때 이런 책이 있다면 마음에 큰 부담을 덜어줄 것 같습니다. 꼭 당첨돼서 러스트를 재밌게 공부할 수 있는 기회가 주어지면 좋겠습니다 :) 개발자에게 있어 프로그래밍 언어는..

Introduction 예제는 깃허브에 업로드해뒀습니다. 얼마 전, 우테코 블로그에 올라온 한 아티클이 화제였다. 바로 라는 제목의 글이었다. 사내 슬랙 채널에 리드님께서 해당 글을 공유해주셨더라. 그러면서 스레드에 아래와 같은 화두를 던지셨다. 아예 데이터(Ticket 엔티티)에 락을 안 걸고 만들 수 있는 방법은 어떤 게 있을까요? 여기서 전제는 "기존 환경 그대로에서"였다. 즉, 위에 다른 분께서 언급하신 것처럼 메시지큐를 사용한다거나 싱글 스레드 모델을 적용하는 등 아키텍쳐를 변경하지 않고도 바꿀 수 있는 지였다. 이에 많은 팀원들이 여러 가지 방법을 제안해주셨다. 흥미로운 이야기들이 많이 오고갔는데(사실상 거의 모든 동시성 해결 기술이 언급된듯), 결과적으로 리드님께서 원하는 방향은 테이블 구조..

TL;DR회사에서 쓰는 오픈소스 공부하다 리팩토링 욕구가 샘솟았다.리팩토링해서 PR 올렸는데 머지됐다.오늘부터 오픈소스 컨트리뷰터 ㅋBackground2주 전을 기점으로 Payment 파트에서 Loan 파트로 팀이 옮겨졌다. 지난 6개월 동안은 유저에게 비즈니스 가치를 전달하는 피쳐 위주 개발을 경험했다. 잘 이끌어주신 덕분에 좋은 성과 역시 낼 수 있었다. 그래서 이번에는 비즈니스의 코어 쪽으로 더 파고들 수 있는 Loan platform 팀으로 가보는 게 어떻겠냐는 제안을 받았다. 나 역시 예전부터 코어 쪽을 들여다보고 싶은 마음이 컸던 지라 기쁜 마음으로 흔쾌히 수락했다. 현재 우리 회사의 전체 아키텍쳐를 개략적으로 살펴보면 유저들이 사용하는 앱을 관장하는 Balance-API 서버와 그 뒷단에서 ..

Background 사내 MSA 서버에 들어갈 외부 설정값들은 Spring cloud config 서버에서 중앙 관리하고 있다. 그런데 config 서버가 꽤나 오랫동안 존재했던지라, properties로 관리되는 설정값이 대다수였다. 그런데 YML 파일로 관리했을 때의 이점이 더 많기 때문에, 해당 설정값을 만질 일이 있을 때마다 Properties를 YML로 바꾸자는 것이 사내 컨벤션이었다. 이때 잠깐, 왜 properties보다 YML로 관리하는 게 더 좋을까? 이는 이전 글에서도 언급한 내용이지만 간단히 짚고 넘어가면 계층 구조 → 중복 코드를 줄일 수 있음. 가독성이 좋음(중복코드가 줄어들고 계층이 나뉘니까) 하나의 YML 파일에서 여러 profile을 관리할 수 있음 기존 properties의..

Background 거의 한 달 넘게 블로그 글을 쓰지 않았다. 한창 쓸 때는 밀리거나 안 쓰면 근질거렸는데, 안쓰는 날이 더 길어지니 역관성이 생긴듯.. 다시 이 글을 쓰기까지 많은 시일이 걸렸다. 여러 가지 이유가 있었는데, 바빠서 후술하겠지만, 지난 2월부터 4월 말까지 (그리고 지금도 계속) 회사 KPI Top 3 안에 드는 프로젝트에 참여했다. 자세한 이야기는 KPT에서 회고하기로 하고, 무튼 이것 때문에 많이 바쁘긴 바빴다..(변명과 핑계 맞음..) ChatGPT의 등장으로 요근래 개발하면서 웬만한 검색은 구글링을 하지 않는다. 대부분 ChatGPT로 검색하고 결과값을 받아오는데, 그도 그럴 것이 너무나도 편리하기 때문이다. 그러면서 이제까지 꾸준히 했던 블로그 작업에 회의가 들었다. 나조차도..

Introduction 드디어 도커 스터디가 막을 내렸다. 그간 수업을 진행하면서 정리할 게 산더미인지라 하나씩 블로그에 올려볼 계획이다. 그러고 보니 간만에 올리는 기술 아티클인듯. 그 간만에 올리는 글이 데브옵스 관련이라는 게 아이러니하지만.. 시작은 Docker Desktop for Mac을 쓰면서였다. 책 으로 수업을 진행하던 중, 책의 개발 환경은 리눅스인 것과 달리 우리의 실습 환경은 유닉스(맥북 로컬)이다보니 차이가 여럿 발생했다. 그 중 하나가 바로 플랫폼을 설정하는 것. 맥북 M1은 ARM 기반인지라 도커 데스크탑 환경에서 이미지를 빌드할 때 역시 ARM 기반 이미지를 사용해야 한다. 그런데 실습 과정에 Linux/amd64 기반의 MySQL 5.7 버전 이미지를 빌드해야 하는 실습이 있..

Keep 1일 1커밋 재개 with owlRoutine→ good 현재 운영 중인 개발자 자기계발 커뮤니티 올루틴 덕분에 1일 1커밋을 재개했다. 결과는 아래 이미지와 같이 성공적!(주말은 쉬어가기로 했다 ㅎ..) 역시 사람은 환경설정의 동물이다. 앞으로도 목표를 이루려면 의지 따윈 믿지 않고 철저하게 내가 하게끔 만드는 환경을 구성할 것. 스케줄러 작업 Divide & Conquer → 성공! 시작부터 끙끙 앓게 만들었던 대규모 프로젝트. 내가 맡은 파트는 한 달 안에 총 6개의 스케줄러를 만들어야 하는, 만 1년이 채 되지 않은 신입에겐 다소 빡센 작업이었다. 처음에는 무엇부터 접근해야 좋을지 몰라 설계서에 주어진 대로 하나씩 만들어야겠다 했다.(설계서 내 순서에는 따로 큰 의미가 없음) 그런데 설계..

Intro 오랜만에 주간 회고 복귀했다. 역시 일요일은 온전히 나만의 시간으로 만들 필요가 있다. 그래야 이렇게 한 주간 어떻게 지냈는지 체크하면서 부족한 부분을 채울 고민도 하지. Keep 도커 스터디 → 반환점 돌았다!(4/8) 도커 스터디가 어느덧 4주차를 마쳤다. 총 8주차로 기획했던 스터디가 어느새 절반을 끝냈다니. 참여해주고 계신 분들도 잘 따라와주고 계시고. 다만 수업 한 번 할 때마다 1시간 반 ~ 2시간 가량 진행되다 보니 어떻게 하면 더 잘 참여하게끔 할 수 있을지가 고민이다. 안그래도 저번 주에 BE팀 주니어들끼리 KPT 회고하는 세션에서 이에 대해 문의했다. 피드백으로는 “스터디할 때는 큰 맥락을 이해할 수 있도록 & 타이핑 과정에서 에러가 생기면 스터디 진행 속도에도 차질이 생기니..

Intro 2월도 순삭이네.. Keep 첫 PR 드디어 Merge! 와..드디어... 아마 블로그를 예전부터 꾸준히 봐왔던 사람이라면 이게 얼마나 감동적인지 알 것이다..때는 바야흐로 작년 8월 23일. 프로덕션 코드베이스에 처음으로 PR을 올렸던 날이다. 그리고 동료 분들의 사랑을 뜨겁게 받기도 한 날이고(리뷰 124개 실환가 진짜). 저때 이후로 리뷰 지옥에 파묻혀 지내다가 더 우선순위가 높은 일들을 받으면서 점차 밀려나갔던 일이었다. 백로그 한 켠에 고이 잠들어 있던 아이였는데..마침 2월에 잠깐 여유가 생긴 틈을 타 후다닥 해치워버렸다. 작년 10월 월간 회고에 보면 에 대한 이야기가 나온다. 자신이 맡은 일, 작성한 코드는 주인의식을 갖고 끝까지 책임져야 한다는 게 골자인데 저때 이후로도 계속 ..