Join Log

포텐업 최종 회고

원티드 백엔드 코스 3기 수료 후기코스 초반 강사님이 이런 취지의 질문을 던졌다. 어떤 문제나 학습한 내용을 What, How, Why의 관점에서 설명할 수 있겠느냐. 그때 나는 What 정도만 설명할 수 있다고 느꼈다. 수료한 지금, 그 질문에 다시 답해 보려고 한다.지원과 코스 초반지원하기 전에는 본가로 이사한 뒤 이것저것 정리하면서 취업을 어떻게 시작해야 할지 알아보고 있었다. 내 개발 역량은 예전에 CRUD까지 구현할 수 있었던 수준 정도라고 생각했다.여러 교육 과정을 찾아봤다. KT 에이블스쿨, SW 마에스트로를 비롯해 다른 선택지도 고민했다. 그런데 찾아볼수록 부트캠프나 국비교육이나 결국 비슷한 결을 띠는 건 아닐까, 정말 차별화된 부분이 있을까 하는 생각이 들었다.그러던 중 2026년 2월 ..

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

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

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

보호되어 있는 글입니다.

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

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

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

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

단순히 구글에 "가비지 컬렉션(GC)이 뭔가요?"라고 검색하면 쏟아지는 교과서적인 정의들. 면접이나 실무에서 써먹기에는 깊이가 턱없이 부족했습니다. 그래서 AI를 단순 검색기가 아닌 '10년 차 시니어 사수'로 설정하고, 능동적으로 학습을 주도해 보았습니다.내가 만든 프롬프트AI에게서 원하는 수준의 통찰을 이끌어내기 위해, 아래와 같이 4단계로 프롬프트를 설계하여 질문했습니다. 긴 텍스트 대신, AI에게 요구한 핵심 지시어를 중심으로 정리했습니다.1단계 (개념 쪼개기)"... 자바에서 GC가 무엇이고 왜 필요한지, 예시를 포함해서 설명해 줘. 직관적으로 이해할 수 있게 쪼개서 설명해."2단계 (비교 분석)"... C/C++의 '수동 방식'과 자바의 '자동 방식(GC)'을 비교해 줘. 두 방식의 장단점을 ..