했다. 요즘 글 작성이 뜸했다.면접 일정을 너무 빡빡하게 잡은 탓에 소화하기가 쉽지 않았다. 정글을 수료한 이후 한동안 나는 취업에만 몰두했다.오로지 취업을 위해 프로젝트를 진행하고, 취업을 위해 이력서를 다듬고, 취업을 위해 네트워킹에 열중했다. 그러나 결과는 처참했다.거듭된 서류 탈락으로 정신적으로 지쳤고, 내가 왜 공부하고 코딩을 하는지조차 잊을 정도로 목적은 희미해졌다. 하지만 기회는 누구에게나 예기치 않게 찾아오는 법이다.크래프톤 정글 협력사 1차 서류에 합격했고, 코딩 테스트를 치렀다.준비 시간이 촉박했고, 내가 해낼 수 있을까 하는 불안감에 사로잡혔지만,시스템 아키텍처와 테스트 코드의 중요성을 강조한 해당 공고를 보고 부랴부랴 공부를 시작했다. 결과는... 아직 연락이 없다는 걸 보면 떨어진..
도메인 주도 설계(DDD)를 채택한 프로젝트에서 엔티티의 생성 시점(createdAt)과 수정 시점(updatedAt)을 자동으로 관리하려면 어떤 방식이 더 적합할까? 특히, 도메인 계층과 데이터 계층이 분리되어 있고, merge를 통해 업데이트가 이루어질 가능성이 높다면 설계 선택에 신중해야 한다. 이번 글에서는 @PreUpdate와 @UpdateTimestamp를 비교하며, DDD 방식에 적합한 구현 방법을 제안해보겠다. 1. DDD 관점에서의 엔티티 상태 관리 DDD에서는 도메인 계층이 핵심이다. 따라서 엔티티의 상태(createdAt, updatedAt) 관리는 애그리거트 루트에서 책임지거나, 이를 데이터 계층에서 투명하게 처리할 수 있어야 한다. 이러한 요구사항을 충족하기 위해: • 도메인 계층..
솔직히 최근까지 나는 방향을 잃고 방황하고 있었다.코딩 자체는 분명 즐거운 일이었지만 무엇을 어떻게 깊게 파고들어야 할지 판단하지 못한 채, 그저 눈에 보이는 기술에만 집착했던 것이다.그 결과, 원래 세웠던 학습 계획은 무너졌고, 사용하고 있던 기술 스택마저 어중간한 상태에 머물렀다.매일 풀던 알고리즘 문제나 사이드 프로젝트조차 더는 큰 의미를 주지 못했다. 그런데 이제야 그 원인을 명확히 알게 되었다.나는 줄곧 혼자 개발해왔고, 오직 나만 이해할 수 있는 코드로 충분하다고 여겼다.문제 해결을 위한 개략적 구상과 간단한 플로우차트, API 명세 정도가 있으면 바로 구현 단계로 들어갔고, 발생할 수 있는 예외 상황들은 대수롭지 않게 넘겼다.비록 SOLID, OOP 같은 개념은 익히고 있었지만, 이를 실제 ..
최근 아키텍처와 테스트의 관계에 대해 깊이 고민하게 되었다. 특히 "테스트하기 쉬운 코드가 곧 잘 짜여진 아키텍처"라는 말이 계속 머릿속을 맴돌았다. 이를 통해 깨달은 점들을 정리해보려 한다.아키텍처란 무엇인가?아키텍처는 단순한 설계 도구가 아니다. 비즈니스 문제를 해결하기 위해 준수해야 하는 제약을 넣는 과정이라고 생각한다. 이는 테스트 코드가 일종의 규약으로 작용한다는 점과 맥을 같이 한다. 중요한 건 아키텍처를 도입할 때는 반드시 그 이유에 대한 구성원들의 공감이 필요하다는 점이다. 공감 없는 아키텍처는 그저 장애물일 뿐이니까.아키텍트의 진정한 목적아키텍처를 다루는 아키텍트의 주요 목적은 결국 인적 자원의 절감이다. 이를 위해서는 다음과 같은 요소들이 필수적이다:동시 작업이 가능한 구조명확한 관심사..
BDD는 내가 가장 애착을 가지고 시도했던 방법론 중 하나다. 테스트를 통한 안정적인 코드 작성이라는 매력적인 약속 때문이었다. 하지만 이번 과제를 통해 그 도구를 제대로 다루지 못했을 때의 문제점을 뼈저리게 경험하게 되었다. 첫 도메인 개발: BDD의 빛나는 순간첫 번째 도메인을 개발할 때는 시간이 걸리더라도 BDD 원칙을 철저히 지켰다. Given-When-Then 패턴을 따라가며 시나리오를 작성하고, 테스트를 먼저 작성한 뒤 구현하는 방식으로 진행했다. 결과적으로 안정적이고 견고한 코드가 완성되었다. 시간 압박과의 타협하지만 첫 도메인 개발에 예상보다 많은 시간이 소요되면서, 남은 도메인들에 대해서는 BDD를 적용하지 않기로 했다. '일단 기능부터 빠르게 구현하자'는 조급한 마음이 앞섰던 거다. 회..
@Builder 어노테이션은 내가 가장 애용하는 도구 중 하나다. 객체 생성 시 높은 유연성을 제공하며, Spring을 사용할 때 자주 활용했다. 하지만 이러한 의존성이 때로는 과도했음을 돌아보게 되었다.@Builder의 유연성@Builder의 가장 큰 장점은 객체 생성의 유연함이다. 모든 매개변수를 한꺼번에 전달할 필요 없이, 가독성 있고 깔끔하게 객체를 생성할 수 있다. 이는 특히 복잡한 객체나 선택적 필드를 가진 객체를 생성할 때 매우 유용하다. 하지만 강력한 도구일수록 신중하게 사용해야 한다.Entity 클래스에서 @Builder의 문제점특히 DDD(Domain-Driven Design) 관점에서, 엔티티는 무결성과 캡슐화를 엄격히 준수해야 한다. @Builder가 제공하는 유연성은 이러한 원칙을..
소프트웨어 개발에서 "의존성"은 피할 수 없는 개념이다. 의존성을 적절히 관리하지 않으면 코드가 복잡해지고, 유지보수와 테스트가 어려워진다. 이번 포스팅에서는 의존성, 의존성 주입(DI), 의존성 역전(DIP) 개념과 이들이 테스트 가능성과 어떤 연관이 있는지 정리해보려고 한다.의존성이란?컴퓨터공학에서 말하는 의존성은 결합과 같은 개념으로, 한 객체가 다른 객체의 동작이나 데이터를 필요로 하는 관계를 의미한다.A가 B를 사용하면 A는 B에 의존한다.예: A 객체가 B 객체의 메서드를 호출하거나 데이터를 참조하면, A는 B에 의존성을 가진다.의존성은 소프트웨어에서 자연스럽게 발생하지만, 이 의존성이 과도하거나 명확히 드러나지 않으면 설계와 유지보수에 문제가 생길 수 있다.의존성 주입(DI, Dependen..
소프트웨어 개발에서 테스트는 단순한 "코드 검증" 이상의 역할을 한다. 특히, TDD(Test-Driven Development)와 BDD(Behaviour-Driven Development)는 테스트를 통해 설계와 개발 방향성을 잡아가는 접근법이다. 이번 포스팅에서는 TDD와 BDD를 중심으로, 테스트와 관련된 다양한 개념들을 정리해보려고 한다.SUT란?테스트하려는 대상을 SUT(System Under Test)라고 부른다.즉, 테스트의 주요 대상이 되는 시스템, 메서드, 혹은 클래스를 지칭하는 용어다.SUT를 잘 정의하는 것은 테스트의 초점을 명확히 하는 데 중요하다.BDD (Behaviour-Driven Development)BDD란?BDD는 TDD에 "행동(Behaviour)"을 강조한 방식이다...
TDD를 하면서 많은 사람들이 빠지는 함정이 있다. 바로 "테스트 커버리지에 집착하는 것"이다. 테스트는 어디까지, 어떻게 작성해야 할까? 그리고 모든 메서드를 테스트해야 할까? 이런 질문에 답을 찾기 위해 이번 포스팅에서는 TDD의 핵심과 테스트 코드 작성의 방향성을 정리해보려고 한다.너무나 명확한 코드는 테스트하지 말자모든 코드를 테스트하려는 강박은 때로는 비효율적이다. 특히, 너무 단순하거나 명확한 코드라면 테스트를 작성하지 않아도 될 수 있다. 예를 들어, 단순한 getter/setter, 혹은 너무 기본적인 로직은 테스트 작성 없이도 충분히 신뢰할 수 있다.테스트 작성에서 피해야 할 것무의미한 테스트단순히 "테스트 코드 커버리지를 높이겠다"는 목적만으로 작성된 테스트는 아무런 가치를 주지 못한다..
이번 포스팅에서는 Mockito를 활용해 Mock 객체를 만들고, 원하는 동작을 지정(Stubbing)하고, 메서드 호출 여부나 호출 순서를 검증하는 방법에 대해 정리해보려고 한다. 예제 코드는 JUnit5와 Mockito를 사용하고 있으며, @ExtendWith(MockitoExtension.class)를 통해 Mockito 관련 설정을 편리하게 적용했다.Mockito 기본 개념Mock 객체란?실제 객체처럼 동작하지만, 프로그래머가 원하는 대로 그 객체의 행위를 설정(Stubbing)할 수 있는 가짜 객체다. Mockito를 사용하면 아주 간단히 Mock 객체를 만들고 관리할 수 있다. Mock 객체를 통해 외부 의존성을 가진 코드(예: DB 접근, 외부 API 호출)를 테스트 시점에 격리시키고, 원하..
