개발 일지 · 팁4 개발 일지 · 팁 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 다음
