Join Log

1. 프로젝트 개요이번 프로젝트는 LXP 서비스 설계에 초점을 둔 DDD 프로젝트였다.LXP는 기존 LMS의 단방향 학습 구조에 학습 경험과 상호작용을 더한 플랫폼이다. 기존 LMS가 강의 제공 중심의 일방향 학습에 가까웠다면, 우리가 만들고자 한 LXP는 학습자가 더 능동적으로 참여하고 상호작용할 수 있는 양방향 학습 플랫폼에 가까웠다.주요 사용자는 개발자와 취업 준비생으로 설정했다. 단순히 강의를 듣는 것에서 끝나는 것이 아니라, 학습 과정에서 미션을 수행하고, 의견을 나누고, 댓글과 구독 같은 상호작용을 통해 학습 경험을 확장할 수 있는 서비스를 목표로 했다.프로젝트 기간은 약 1주일이었다. 나는 팀에서 설계와 백엔드 개발을 맡았고, 주요 담당 기능은 구독과 결제 기능이었다. 별도로 고정된 문서 담..

기술적 선택이번 프로젝트에서는 세 가지 방식을 새로 도입했다.첫 번째는 보조 객체 분리였다. 기존 코드에서는 입력값 처리, 검증, 화면 흐름에 필요한 데이터가 한곳에 섞이는 느낌이 있었다. 파일 수가 늘어나는 부담은 있었지만, 역할을 나눠두는 편이 이후 수정에 더 안전하다고 판단했다. 그래서 Form, Request 같은 보조 객체를 분리했다. 다만 이 선택을 할 때 다른 대안을 충분히 비교하지 못한 점은 아쉬웠다.두 번째는 정적 팩토리 메서드였다. 이전 프로젝트에서 다른 사람의 PR을 보며 처음 알게 된 방식이었지만, 당시에는 직접 적용하지 못했다. 이번에는 객체 생성 의도를 메서드 이름으로 드러내고 싶어서 적용했다. 단순히 생성자를 호출하는 것보다 어떤 목적의 객체 생성인지 코드에서 더 잘 보이게 만..

시작 전 계획처음부터 MVP 먼저 구현하고 이후 리팩터링으로 품질을 높이는 방향으로 계획했다. 이 흐름 자체는 맞았는데, 예상 못 했던 건 문서와 코드의 불일치가 생각보다 광범위하다는 점이었다.기존 문서를 수정하기엔 일정이 타이트했다. 그래서 코드를 작성하면서 보완 문서를 따로 만들고, 수정 사항들은 ISSUE와 PR로 남겼다. 깔끔한 해결은 아니었지만 현실적인 선택이었다.잘한 것다른 사람 PR을 먼저 읽고 코멘트를 남기는 습관이 자연스럽게 생겼다. 단순히 코드를 확인하는 게 아니라, 모르는 부분을 질문하고 상대방이 왜 그렇게 작성했는지 이해하려다 보니 사고의 확장을 경험할 수 있었다. 이게 잘한 부분이라고 생각한다.타인의 PR을 보면서 "왜 저렇게 썼지?"라는 의문이 생기면 AI로 추가 학습하는 흐름도..

보호되어 있는 글입니다.

주제Spring IoC / DI / Bean오늘의 핵심 목표IoC, DI, Bean의 의미를 구분해서 설명할 수 있다.객체를 직접 new로 생성하는 방식의 문제를 설명할 수 있다.Spring Container가 객체를 생성하고 의존성을 주입하는 흐름을 설명할 수 있다.생성자 주입을 사용하는 이유를 코드와 함께 설명할 수 있다.1. IoC란 무엇인가?IoC는 Inversion of Control의 약자로, 제어의 역전이라는 의미다.기존 Java 코드에서는 개발자가 직접 객체를 생성하고 연결한다.MemberRepository repository = new MemoryMemberRepository();MemberService memberService = new MemberService(repository);하..

1. 이번 2주를 한 줄로 요약하면재밌는데 너무 지친다.토이 프로젝트를 기획하고 설계하는 과정은 분명 재밌었다.하지만 그만큼 신경 쓸 것도 많았고 생각보다 지치는 부분도 많았다.2. 이번에 했던 것이번 2주 동안은 토이 프로젝트 기획 및 설계를 진행했다.그리고 DDD를 적용했다기보다는DDD 향이 조금 첨가된 토이 프로젝트를 진행했다고 보는 게 맞을 것 같다.처음에는 단순히 기능을 어떻게 구현할지만 생각했는데프로젝트를 진행하면서 도메인 정의나 비즈니스 흐름을 먼저 정리하는 게 중요하다는 걸 느꼈다.3. 가장 크게 배운 것가장 크게 배운 것은 태도의 중요성과 프로젝트에서 DDD를 사용하는 이유다.도메인과 비즈니스가 명확하지 않으면같은 기능을 보고도 서로 다르게 이해할 수 있고그 차이가 커뮤니케이션 문제나 구..

1. 이번에 이해한 핵심DDD 1일차에서 가장 먼저 잡아야 하는 개념은 아래 4가지다.Entity: 속성이 바뀌어도 계속 추적해야 하는 대상Value Object: 동일성보다 값 자체와 그 값의 규칙이 중요한 객체Aggregate: 일관성 규칙을 지키기 위한 경계Factory: 처음부터 유효한 상태의 객체를 만들기 위한 생성 책임즉, DDD를 처음 배울 때는 아래 질문으로 접근하면 된다.이건 계속 추적해야 하는 대상인가?이건 값 자체가 중요한가?이 객체의 규칙은 어디서 지켜야 하는가?생성 책임은 어디에 두어야 하는가?2. Entity정의속성이 바뀌어도 같은 대상으로 계속 식별하고 추적해야 하는 객체다.예시강사강의회원주문예를 들어 강의 제목이나 정원이 바뀌어도 그 강의는 여전히 같은 강의다.중요한 것은 제..

들어가며오늘 실무자분의 특강을 들으며 내가 앞으로 어떤 방향으로 성장해야 할지 조금 더 구체적으로 생각해보게 됐다. 특히 현업의 관점이 담긴 조언들이 인상 깊었고 막연했던 고민들도 몇 가지 축으로 정리되기 시작했다. 감사의 마음을 담아 오늘 얻은 인사이트와 앞으로의 실행 방향을 TIL로 정리해본다.오늘의 한 줄 결론백엔드 개발자로서 단순 구현 역량을 넘어서 가시성·비용·데이터·비즈니스까지 함께 이해하고 설명할 수 있는 방향으로 성장해야 한다는 점이 더 선명해졌다.1. 오늘 정리한 핵심 인사이트마인드셋: 빠르게 배우고 버리고 꾸준히 기록하기오늘 가장 크게 남은 것은 앞으로의 성장 방식에 대한 태도다.이제는 한 번 익힌 방식에 머무르기보다 빠르게 시도하고 잘못된 방식은 빨리 버리는 fail fast와 unl..

부트캠프 시작 전에는 어떤 마음이었는가?시작일이 다가올 때까지 걱정 반 기대 반으로 마음을 졸였다.진행하면서 가장 기억에 남는 일은 무엇이었는가?주도적인 활동들이 많았다는 점.수동적인 사람인지라 힘들게 와닿기도 했지만 결국 도움이 될 거라 생각했고실제로 받아들인다는 마음가짐으로 해보니 굉장히 도움이 됐다.가장 힘들었던 점은 무엇이었는가?출퇴근이 너무 힘들다...오갈 땐 생각보다 피로를 덜 느끼지만 하루하루 쌓일수록 누적되는 피로감이 생각 이상으로 크다.생각보다 괜찮았던 점은 무엇이었는가?노트북 성능이 32GB에 4070이라 너무 괜찮았다전보다 달라졌다고 느끼는 점은 무엇인가?조금 더 적극적으로 행동하고 배우려고 했다끝나고 나서 드는 한 줄 감정은 무엇인가?횡설수설하는 경우가 많긴 하지만 앞으로 열심히 해..

들어가며Git을 로컬에서 혼자 잘 쓰는 것과, 팀과 함께 GitHub 위에서 잘 쓰는 것은 다른 문제입니다.코드 변경에는 항상 맥락이 있습니다. 왜 이 기능을 만들었는지, 왜 이렇게 구현했는지, 이 변경이 어떤 문제를 해결하는지 — 이 맥락이 코드 안에만 있으면 나중에 아무도 알 수 없습니다. GitHub의 Issue, PR, README는 그 맥락을 코드 밖에 기록하는 도구입니다.이 글은 GitHub 협업 도구들을 왜 필요한가의 관점에서 정리합니다.Issue — 코드 변경의 출발점Issue는 단순한 할 일 목록이 아닙니다. 팀의 의사결정 히스토리입니다.Slack에서 "이 버튼 색깔 바꾸자"라고 얘기하면, 6개월 뒤 "왜 이 색깔이야?"라는 질문에 아무도 답할 수 없습니다. Issue에 기록하면 왜 이 ..