개발 일지 · 팁5 개발 일지 · 팁 현업에서 git tree 한줄로 관리하기 [Fast-Forward**] [merge] [pull] [rebase] [squash-merge] 레거시 프로젝트의 git tree를 열어보면 이런 모습이다.수십 개의 브랜치 선이 무지개처럼 얽혀 있고, Merge branch 'main' into develop가 끝없이 반복된다. 어떤 커밋이 어떤 작업이었는지, 언제 무엇이 배포됐는지 히스토리만 봐서는 도무지 읽히지 않는다.신규 프로젝트를 시작하면서 우리 팀은 이 부분을 먼저 손봤다. 거창한 도구를 도입한 게 아니라, git을 다루는 몇 가지 컨벤션을 정하고 그것만 지켰다. 그 결과 지금은 dev / stg / prod 같은 배포 브랜치의 히스토리가 한 줄(single line)로 깔끔하게 유지된다. 히스토리가 한 줄이면 실무에서 얻는 이점이 분명하다. 커밋 하나하나가 어떤 작업 단위였는지 그래프만 봐도 읽히고, 코드 리뷰의 단위가 명확해진다. 문제.. 2026. 8. 12. 개발 일지 · 팁 JPA 연관관계를 안 쓰면 조회는 어떻게 하나 — FK 참조, QueryDSL on 조인, 애플리케이션 조립 지난 글(JPA 연관관계, 쓸까 말까 — @ManyToMany도 써도 될까?)에서 우리 팀이 객체 매핑을 거의 쓰지 않는 쪽으로 흘러왔다는 이야기를 했다. 그 글을 쓰고 나서 스스로 찜찜했던 부분이 하나 있었다. "안 쓴다"까지는 말했는데, "그럼 조회는 어떻게 하느냐"에 대한 답을 안 했다는 것이다.연관관계를 걷어내면 문제가 하나 생긴다. order.getCustomer().getName() 한 줄이면 끝나던 게 안 된다. 주문에서 고객 이름을 가져오려면 고객을 따로 조회해서 붙여야 한다. 이게 매번 불편하다면 그 컨벤션은 오래 못 간다. 실제로는 안 불편했으니 몇 년째 유지되고 있는 건데, 그 "안 불편한 방법"이 뭔지를 정리해 두려고 한다.이번에는 감이 아니라 코드를 직접 세어 봤다. 우리 팀이 운.. 2026. 8. 2. 개발 일지 · 팁 1400개의 경력직 백엔드 이력서를 읽으며 좋게 읽혔던 이력서의 5가지 공통점 (2편) 들어가기 전에 — 1편의 반대편 이야기지난 글에서 1400개의 경력직 백엔드 이력서를 검토하면서 반복적으로 아쉬웠던 점들을 정리했다. 1400개의 경력직 백엔드 이력서를 읽으며 반복해서 보였던 아쉬운 점들 (1편)그 글의 마지막을 이렇게 마무리했었다. "다음 글에서는 반대로 잘 읽혔던 이력서들은 어떤 특징이 있었는지, 그리고 내 이력서가 지향하는 방향은 무엇인지를 정리해보려고 한다." 이번 글이 그 내용이다.전제는 1편과 같다. 채용에는 정답이 없고, 나는 1차 서류를 검토하는 검토자 중 한 명일 뿐이다. 최종 결정은 여러 사람의 의견과 팀 상황, 채용 인원이 함께 얽혀서 난다. 그래서 이 글도 "이렇게 쓰면 합격한다"가 아니라 "내가 검토하면서 이런 이력서는 확실히 좋게 읽혔다" 정도로 읽어주면 좋겠다.. 2026. 8. 2. 개발 일지 · 팁 1400개의 경력직 백엔드 이력서를 읽으며 반복해서 보였던 아쉬운 점들 (1편) 들어가기 전에 — 이 글은 합격과 불합격의 기준이 아니다채용에는 정답이 없다. 회사마다 기준이 다르고, 같은 회사 안에서도 면접관마다 보는 포인트가 다르다. 그래서 이 글은 "이렇게 쓰면 탈락한다"는 기준을 이야기하려는 글이 아니다. 내가 약 1400개의 경력직 백엔드 개발자 이력서를 검토하면서 반복적으로 자주 보였던 사례들을 정리한 회고에 가깝다.먼저 내 위치를 정확히 밝혀두고 싶다. 나는 1차 서류를 검토하는 검토자 중 한 명이다. 내가 혼자 합격을 결정하는 자리가 아니다. 1차 검토 결과는 여러 사람의 의견과 함께 취합되고, 거기에 팀의 현재 상황, 채용 인원, 필요한 포지션의 성격이 더해져 최종 결정이 난다. 그래서 이 글에 나오는 이야기들은 "이런 이력서는 떨어진다"가 아니라 "내가 1차 검토를.. 2026. 8. 1. 개발 일지 · 팁 내가 겪은 AI를 도입했을 때 생겼던 문제들 AI가 업무 방식을 빠르게 바꾸고 있다. 기획서를 쓰고, 코드를 만들고, 문서를 정리하는 일까지 이제는 몇 분이면 끝난다. 예전에는 하루가 걸리던 일이 몇 시간, 때로는 몇 분으로 줄었다. 생산성은 분명 올라갔다.그런데 여러 프로젝트에서 AI 도입을 지켜보면서 한 가지 공통된 현상을 발견했다.AI를 잘 쓰자 보다, AI에게 일을 맡기자 하는 조직이 점점 많아지고 있다.겉으로는 둘 다 AI를 쓰는 것처럼 보인다. 하지만 결과는 전혀 다르다.AI는 뛰어난 도구다. Skill, Agent, MCP, Workflow 같은 기술도 계속 좋아지고 있다.그런데 내 생각에는 그보다 더 중요한 원칙 하나가 빠져 있다. 그 원칙이 없다면, 차라리 AI를 쓰지 않는 편이 조직에는 더 나을 수도 있다고 생각이 들었다.이 글에.. 2026. 7. 19. 이전 1 다음
