DevLog 😶

사실 발표가 난 지는 꽤 됐지만 블로그에 기록으로 남겨두면 좋을 것 같아서 쓰는 글 😊 추후 2024 NEXT가 진행되었을 때 도움이 된 분들이 있었으면 좋겠다! 🌱 준비 여정 올해 6월 말 정도, 토스에서 2023 NEXT 개발자 챌린지를 통해서 3년 이하의 개발자를 채용한다는 공고를 냈다. 사실 우테코를 진행하면서 올해 안에는 본격적인 취업 준비를 할 생각이 없었어서, 그냥 경험 한 번 해보자는 생각으로 당당하게 지원했다. Core Banking이랑 Server 중에 어떤 걸 할지 고민했는데, 금융 관련 도메인에 대한 이해도가 현저히 낮은지라 Server 쪽 직무로 지원하게 되었다. 분야별 어디 파트를 하고 싶은지도 처음에 넣을 수 있는데, 그때는 토스랑 토스뱅크를 넣었다. 코딩 테스트 > 직무 인터..

🌱 들어가기 전 우리 팀의 경우 E2E 테스트 환경을 구축하기 위해서 @SpringBootTest를 통해 테스트 코드를 작성하고 있는데, 우리 팀의 팀원분이 아래와 같은 오류를 만나게 되었다. failed to lazily initialize a collection of role: co.kirikiri.domain.roadmap.RoadmapContent.nodes.values: could not initialize proxy - no Session 상황은 아래와 같다. (추후 코드로 더 잘 살펴볼 예정이다.) A라는 생성 API와 B라는 조회 API가 있을 때, 팀 내에서 기능을 세분화한 다음 각자 개발을 진행하다 보니 B를 개발하는 시점에 A라는 API가 없어, 통합 테스트 때 repository를 ..

🌱 들어가기 전 우리 팀은 CI 플로우 과정 중에서 Jacoco를 활용하여 테스트 리포트를 발행하고, 커버리지를 체크하고 있다. (테스트를 정말 철저하게 하자는 취지인데, 팀원 모두가 테스트를 정말 꼼꼼하게 작성해 주셔서 좋다 👍) CI에 대한 글은 다음에 완전하게 구축된 이후에 작성하는 게 좋을 것 같아서, 오늘은 Jacoco에 대해서만 가볍게 짚고 넘어가고자 한다. 🌱 Jacoco 설정하기 Jacoco는, 테스트 코드 커버리지를 분석해주는 자바의 무료 라이브러리이다. Jacoco 플러그인에는 JacocoTestReport와 JacocoTestCoverageVerification Task 등이 존재한다. (여기서는 이 2가지를 위주로 알아보도록 하자.) - JacocoTestReport: 커버리지 결과..

🌱 들어가기 전 JPA에서 @OneToMany 단방향 매핑보다는 다대일 양방향 매핑을 권장한다는 말을 보았을 것이다. 하지만, 객체지향으로 코드를 설계하다 보면 다대일의 상황보다는 1인 엔티티를 기준으로 N인 엔티티를 조회하는 경우가 더 많고, (적어도 내 경험에서는 그랬다) N인 엔티티가 굳이 1인 엔티티에 대한 정보를 몰라도 됐던 적이 많았다. 그러다 보니 자연스럽게 일대다 단방향 매핑을 많이 사용했었는데, 왜 그랬던 것인지 궁금해서 나름대로 실험을 해보고자 한다. (ex. 게시글과 게시글 이미지의 관계에서, 게시글 이미지를 기준으로 게시글 정보를 찾아오는 것보다는 게시글을 기준으로 게시글 이미지 정보를 가져오는 게 더 많았음) 🌱 기본 엔티티 설계하기 @Entity class Board( @Id @..

🌱 디스크 읽기 방식 💬 HDD (하드 디스크 드라이브) / SSD (솔리드 스레이트 드라이브) 메모리에 비해 실제 하드웨어 장치의 발전은 비교적 느리게 발전한다는 소리를 들은 적이 있을 것이다. 특히 HHD는 플래터(원판)을 돌려서 읽고나 쓰다 보니 성능이 매우 느릴 수밖에 없다. 이를 보완하기 위해 등장한 SSD의 경우 기존 하스크 드라이브에서 데이터 저장용 플래터(원판)을 제거하고 그 대신 플래시 메모리를 장착해서 빠르게 데이터를 읽고 쓸 수 있다. 플래시 메모리는 전원이 없어도 데이터가 삭제되지 않으며, 메모리보다는 느리지만 그래도 하드 디스크 드라이브보다는 훨씬 빠르다. 💬 랜덤 I/O와 순차 I/O 디스크 읽기 연산에서 '랜덤 I/O'와 '순차 I/O'라는 말을 들은 적이 있을 것이다. 랜덤 ..

🌱 코끼리끼리팀 결성! 드디어 레벨 3이 시작하면서 본격적인 팀 프로젝트가 진행되었다. 앞서 레벨 2 회고 때 언급했던 것처럼, 운이 좋게도 내가 아이디어를 냈던 주제로 프로젝트를 진행할 수 있게 되었다. 두 달 동안 함께 할 크루는 두둠, 썬샷, 밀리, 우디, 네이브, 부엉이였다. 약 일주일 정도 함께 진행하면서, 우리 팀의 밸런스가 상당히 좋다는 생각이 자주 들었다. 기본적으로 다들 대화할 때 눈을 마주치고 경청을 잘해주시기도 하고, 그렇다고 말이 없는 것도 아니고 회의도 꽤 재밌게 진행되는 부분이 있어서 좋다. 적당히 내향적이면서 외향적인 사람들이 잘 만난 긍정적인 케이스를 보는 느낌....? 특히 토론할만한 주제에 대해서 20분, 30분도 심도있게 토론하는 시간들이 굉장히 좋았다. 앞으로도 계속 ..

🌱 JPA 기본 키 생성 전략 JPA에서 제공하는 기본 키 생성 전략은 크게 5가지로 나누어진다. - TABLE, SEQUENCE, IDENTITY, UUID, AUTO 각 전략에 대해서 하나씩 알아보도록 하자. 🌱 TABLE 💡 Indicates that the persistence provider must assign primary keys for the entity using an underlying database table to ensure uniqueness. - 데이터베이스 테이블을 사용하여 엔티티에 기본 키를 할당해야 한다. 💬 엔티티 설정 @Entity class User( @Id @GeneratedValue(strategy = GenerationType.TABLE) val id: Lon..

🌱 들어가기 전 지난 포스팅에서는 CascadeType.REMOVE에 대해서 중점적으로 알아봤었는데, 이번에는 orphanRemoval=true 옵션에 대해서 한 번 알아보자. 엔티티 세팅은 지난 번과 거의 동일하기 때문에 변화가 생긴 부분에 대해서만 따로 짚도록 하겠다. 🌱 엔티티 수정하기 이번에는 CascadeType.REMOVE 대신에 orphanRemoval=true를 적용하자. @Entity class Concert( @Id @GeneratedValue(strategy = GenerationType.IDENTITY) val id: Long = 0L, @Column(nullable = false) val name: String, @Column(nullable = false) val ticketLi..

🌱 들어가기 전 JPA를 공부하면서 CascadeType.REMOVE와 orphanRemoval = true 옵션에 대해서 어떤 차이가 있는지 제대로 인지한 적이 없는 것 같아서, 이번에 공부할 겸 여러 가지 테스트를 진행해보며 두 옵션의 차이를 공부해보았다. 결과적으로 말하자면 Cascade 옵션은 부모 엔티티와 자식 엔티티의 영속 상태를 관리하는 것이고, orphanRemoval은 조금 더 세부적으로 고아 객체에 대한 관리라는 생각이 들었다. 지금부터 여러 케스트를 테스트하며 하나씩 알아보자. 🌱 엔티티 세팅하기 1:N 관계를 담당해줄 '콘서트' 엔티티와 '콘서트 티켓' 엔티티를 생성하였다. 둘 사이의 관계는 양방향으로 설정하였으며, 하나의 콘서트는 여러 개의 콘서트 티켓을 보유할 수 있도록 설계하였..

🌱 들어가기 전 DB 공부하다가 '네임드락'에 대해서 알게 되었는데, 네임드락을 사용하면 분산락을 구현할 수 있다는 글을 보고 한 번 테스트해보고 싶어서 글을 작성해보고자 한다. 전체 소스코드는 여기에서 확인 가능하다. (뭔가 테스트용 레포 만들기 애매해서 그냥 안 쓰는 레포에다가 하려다 보니 코틀린으로 작성하게 되었다.) 🌱 분산락이란? 분산락이란 멀티 스레드 환경에서 공유 자원에 접근할 때, 데이터의 정합성을 지키기 위해 사용하는 기술이다. 여기서 여러 스레드가 공유 자원을 접근하며 경쟁하는 상황을 'Race Condition (경쟁 상태)'라고도 부르며, 자바에서는 'synchronized'라는 키워드를 통해서 하나의 스레드만 접근할 수 있도록 동기화 기능을 제공한다. 하지만, 스프링 웹 애플리케이..