유튜브 영상 초반에 나온 말부터 전달해 드리면 모든 기술을 선택할 때는 이유가 있어야 합니다. virtual thread의 소개도입을 고려하게 된 배경으로는 전사 게이트웨이 시스템 개발용 안정성과 처리량에 대한 고민이 필요해서 알아보게 되었다고 합니다Coroutine vs Virtual Thread1. Kotlin Coroutine (실제 선택하셨다고 합니다)2. Java Project Loom (jdk 21 이 나오기 전이라, 테스트 버전이었습니다)경량 스레드 모델로 jdk 21에 정식 feature로 추가됩니다. Virtual Thread의 장점스레드 생성, 스케쥴링 비용이 기존 스레드보다 훨씬 저렴합니다.스레드풀을 사용할 정도로 비용이 기존의 자바 스레드의 생성 비용이 큽니다.최대 2MB까지 차지할..
회사에서 들었던 세션의 내용을 일부분 정리해서 가져온 내용입니다좋은 피드백이란 뭘까요?다른 사람의 행동을 바꾸는 것입니다사람이 쉽게 바뀔 수 있을까요? 대부분 불가능하죠피드백 수업도 있고, 코칭도 있는 이유는 그 힘든 일을 조금 더 쉽게 해내기 위해서일 것입니다피드백은 다른 사람이 받는 것을 너무 싫어하는 상황이면 오늘의 내용보다는 그 상황을 바꾸는 것이 더 중요할 수 있습니다가장 핵심적인 포인트는 받아들일 수 있도록 만드는 것이 가장 중요합니다상대방의 반발심을 누그러뜨리는 것이 가장 중요하죠 피드백을 잘 받아들이게 하는 방법당연히 긍정적인 것만 해주면 가장 받아들이기 쉽지만, 이건 피드백이 아니니 피드백의 역할을 하지 못합니다.이 부분을 해결하기 위한 스킬이 필요한 것이죠피드백을 강하게 주는 것 vs ..
자바 버전 올리려다 과정을 기록해 두면 정말 많은 도움이 앞으로 될 것 같아서 기록해두려고 한 글입니다 이 글을 읽는 모든 분들은 비슷한 문제를 마주했을 것 같지만 천천히 편하게 올리면 결국 다 할 수 있습니다 파이팅 현재 상황은? 현재 저희 팀의 프로젝트는 자바 8로 되어있습니다 당연하지만 스프링부트도 2. 초반의 버전으로 이루어져 있습니다 자바 8이 유지가 되면 어떤 문제가 생길까요? 자바 8의 support 기간은 어마어마하게 많이 남아있는데요? 무려 앞으로 6년 10개월이나 남은 2030년 12월 31일에 서포트가 종료되는데요? 그전에 누군가가 자바 버전을 올려주지 않을까요? (하지만 그 일은 절대로 이루어지지 않습니다) 다른 사람을 설득할 수 있는 자바 버전을 꼭 올려야 하는 이유를 그나마 찾는..
진짜 오랜만에 여유를 찾게 되어서 5개월 동안 토스에서 느꼈던 점들에 대해서 한번 정리해보려고 해요 제가 있는 팀에 대한 간략한 소개는 다음과 같아요 토스 송금팀이란? 송금과 관련된 수많은 제품을 유지보수 하는 역할을 합니다 현재 송금 제품팀에서 맡고 있는 제품은 정말 많은데요 ATM, 하나은행 환전, 정치 후원금, 계좌 송금, 자동이체, 연락처 송금, 사진 찍어 송금, 더치페이 등이 있습니다 이 팀의 특징은 다음과 같아요 대부분이 다 금원 관련된 서버다 보니 실수를 하게 되면 바로 금감원에 보고를 할 수 있다는 압박은 언제나 존재하는 팀입니다 정말 많은 서버를 다루다보니, 하나의 기능에 완벽하게 몰입해서 진행을 하는 것은 힘든 팀입니다 다양한 서버의 코드를 봐야하는 일이 많습니다 정말 안정적인 기능을 ..
이번에 총 4건의 에러가 발생해서 급하게 롤백을 진행했던 사례(정말 다행히 대고객 영향은 없었습니다)에 대해서 말씀드리도록 하겠습니다 정말 간단하게 요약을 하면 과정은 다음과 같습니다 1. 제 서버의 Java의 Dto 클래스를 Kotlin의 data class로 변경했습니다 2. 이를 사내 nexus에 배포하였습니다 3. 이를 sdk 형태로 의존하고 있는 다른 서버를 배포했습니다 4. Jackson Deserialize Exception 이 발생해서 바로 롤백을 했습니다 제 기존 JavaClass 에는 NoArgumentConstructor 가 달려있었지만, data class로 변경한 클래스에는 noArgumentConstructor 가 없습니다 이런 상황을 해결하기 위해서 KotlinModule을 등..
이번주 금요일에 정말 장애와 함께 한 날인데요 크고 작은 총 3번의 장애가 날뻔한 것과, 잘못된 데이터가 내려가는 문제가 있었고, 슬랙 채널에서 승건 님을 포함한 거의 가장 높은 3명을 쭈르륵 만났습니다 가장 처음에 승건님을 만난 것은 어드민 페이지에서 특정 필드가 누락되어, 서빙되는 데이터가 잘못된 부분입니다. 이 부분은 그래도 제가 배포한 부분이랑은 관련이 바로 있지 않아 간접적으로 엮여있어서 좀 덜 신경 쓰였지만, 이후에 2번은 제 배포와 직접 연관이 되어있어 회고를 하기 위해서 글을 작성합니다. 제 사수분이 작성한 코드에서 카프카 토픽을 잘못된 곳에 집어 넣어서, 서비스에서 사용하는 카프카에 데이터를 추가한 것이 아니라, 로그 카프카에 데이터를 추가하면서 Unknown Topic 이 발생했었습니다..
오늘은 자바에서 사용할 수 있는 다양한 동적 쿼리 방법을 알아보고, 왜 Jpa Criteria를 선택했는지 말씀드리려고 합니다 이번에 프로젝트에서 어드민 페이지를 만들던 과정에서 여러 가지 조건으로 필터링되어야 하는 데이터를 쿼리 할 필요가 생겼습니다. 상태가 성공인 데이터를 여러 조건에 맞게 조회해야 하는데요 원본 데이터는 총 3000건 정도이고, 상태가 성공인 건은 1500건 정도입니다. 처음에 생각했던 방법은 총 5가지 정도가 있었습니다. 동적 쿼리의 종류 1. findAll을 사용한 이후에 Application에서 처리한다 @Component class ApplicationQuery( private val userRepository: UserRepository ) { fun findUserByNa..
MSA 환경으로 오면서, 특정 사용자가 어떤 행동을 했는지 파악해서 대응하기 어렵습니다 어려운 이유는 여러 가지가 있을 수 있는데요 1. 로그가 각 서비스마다 흩어져있다 2. 하나의 API 호출에서 발생한 로그들을 묶어서 볼 수 없다 1을 해결하기 위해서 보통 로그를 중앙에서 모아서 관리하게 되는데요 이를 위해 현재 제가 일하고 있는 곳에서는 하나(이중화는 고려하지 않겠습니다)의 거대한 Elastic Search 클러스터를 구성해 두고, 그 클러스터에서 모든 로그를 모아서 관리하고 있습니다 2번째 문제를 해결하기 위해서 API Gateway에서 eventId를 만들어 요청에 헤더에 포함시킨 후 릴레잉 해줍니다. 그 eventId를 로그에 포함시켜서, 이벤트 id 기준으로 묶어서 로그를 확인하고 있습니다...
추석 연휴와 한글날 여유가 생겼는데, 이 연휴를 어떻게 하면 더 의미 있게 보낼 수 있을까라는 고민을 하다 보니 개발자 취업이나, 간단한 질문들을 받아주는 것으로 사용하면 어쩔까 하는 생각이 들었습니다 같은 학교만 볼 수 있는 커뮤니티나, 공개적으로 볼 수 있는 커뮤니티에 올려보고, 거기서 사람들의 질문을 받아봤습니다 학교 커뮤니티에서는 총 12명에게 질문 답변을 진행했습니다 공개적으로 볼 수 있는 커뮤니티의 경우에도 13명에게 질문 답변을 진행했습니다 우테코에서 이력서 피드백을 요청했던 1명도 있었습니다 총 26명과 질문 답변을 진행해 보고 거기에서 나왔던 질문들을 기록해 두고, 어떤 빈도로 질문이 나왔는지 정리해 두면 나중에도 도움이 될 것 같아서 미리 정리를 해두려고 합니다 질문 답변을 끝내고 나니..
문제 상황 같은 형태의 테이블 2개를 하나의 테이블로 합쳤을 때, Auto Increment 때문에 생길 수 있는 문제에 대해서 정리를 해보려고 합니다 편의를 위해서 정말 간단한 엔티티로 설명을 드리도록 하겠습니다 @NoArgsConstructor @AllArgsConstructor @Getter @Entity @Table(name = "transaction_data") public class TransactionData { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @Column(name = "name") private String name; public TransactionData(String name) { thi..
