개린이의 일기장

과거의 애플리케이션은 아마도 충분한 계획을 기반으로 개발되었으며, 변경점도 비교적 많지 않았습니다. 그리고 대부분 SI 식 개발로 비즈니스가 분리되었기에, 지속성보다는 요구 사항 충족과 납기일이 우선 되었었습니다. 이때에는 단어조차 생소한 개발 문화는 중요하지 않았으며, 위에서 내려온 계획에 맞는 개발을 하나라도 더 하는 게 미덕이었습니다. 하지만 현대의 애플리케이션은 긴 생명 주기와 모호해진 개발과 운영의 경계로 개발보다는 운영하면서 더 많은 이슈를 만나게 됩니다. 그러다 보니 자연스럽게 개발의 지속성에 대해 생각하게 되고 그것들을 아우르는 것으로 개발 문화가 나오게 되었습니다. 이제는 개발이 비즈니스의 성공에 직결적인 요소가 되었기에 개발 문화의 중요성이 업계 전반에 퍼져 있고 채용에도 중요한 화두가..

pagination은 백엔드 구현에서 가장 많이 고려해야 되는 기술 중 하나입니다. 일반적으로 알려진 pagination 기술에는 page, slice 가 있고 특수한 경우에 사용되는 noOffset과 Covering Index 기술이 있는데요. 이번 글에서는 실무에서 만난 특이한 pagination 사례에 대해 각색하여 기록해봅니다. 업무 요건 전체고 조회가 필요합니다. 상품군이 신설되었습니다. 기존에는 회사와 상품이 존재했으며 M:N 관계입니다. 상품군과 상품은 1:N 관계입니다. 상품군과 회사의 관계는 M:N 관계입니다. 서로 다른 재고처에 있는 재고를 합쳐야 합니다. 각 상품군별, 회사별로 소계를 보여주어야 합니다. 페이지당 300개 안팎은 허용 범위입니다. 기술적 배경 각 도메인별 조인이 많이 ..

처음 개발을 시작할 때를 돌이켜보니 잘 모르기도 했고, 가격적인 부담이 있어 제대로 세팅하지 못해 버벅거렸던 기억이 있습니다. 그러다 이번에 코드 스쿼드 TA를 하게 되면서 초보 개발자 분들에게 도움이 되고자 기록을 남겨봅니다. 지금 제가 사용 중이거나 좋다고 생각하는 조합을 개인적인 관점에서 작성한 내용이니 참고해서 세팅하시면 됩니다. 1. 개발 장비 MacBook 사용을 권장합니다. 네카라쿠배의 백엔드 개발자를 목표로 하신다면 매우 높은 확률로 MacBook을 사용하실 것이고, IDE 사용법이나 애플 생태계의 앱을 사용하는 것에 있어 Window와는 조금 차이가 있습니다. 생산성 차이도 있고 특히 Shell은 지금부터 익숙해지는 것이 좋습니다. M1부터는 가격적인 부담도 내려갔고 학습을 위해서는 Ma..

String 은 Java에서 가장 오래되고 많이 다루는 자료형 중 하나입니다. 그만큼 다루는 방법도 여러 가지인데요. 실무를 하면서 헷갈리기 Best Practice를 기록해 봅니다. 단 String의 반복 연산은 일반적이지 않기에 다른 개선에 비해 드라마틱하지 않습니다. 그리고 실무에서는 팀 컨벤션으로서의 코드 일관성이 우선이기에 무조건적인 적용은 권장하지 않습니다. 각 항목별 제목으로 Best Practice가 기록되어 있습니다. 그래프의 수치는 높을수록 좋은 성능을 의미합니다. 1. String 은 Immutable 합니다. 워낙에 많은 블로그에 잘 소개되어 있기에 이어질 내용의 배경으로서 기록은 하지만 내용은 생략합니다. String과 Mutable, Immutable에 대해서 헷갈린다면 검색해보..

개발하면서 Component와 Configuration 어노테이션은 많이 만났었지만 이 글을 작성하기 전에는 @Configuration 은 설정 클래스에 사용하는 어노테이션 @Component는 Bean 클래스에 사용하는 어노테이션 정도로만 알고 있었습니다. 하지만 공부하다 보니 모호하게 알고 있던 부분을 좀 더 알게 되었고, 이 내용을 기록해 봅니다. # 비교 @Component @ComponentScan 을 통해 검색됩니다. @SpringBootApplication에 래핑 되어 있기에 일반적으로는 신경 쓰지 않아도 됩니다. 용도에 맞춘 스테레오 타입의 어노테이션을 가지고 있습니다. @Controller @Service @Repository @Configuration 가능하면 스테레오 타입을 사용합니다..

개발 초기에는 AWS 구성을 하는 것도 일이기에, 지금까지는 프론트 개발자가 백엔드 소스를 받아서 local에서 서버를 띄우는 방식으로 진행했습니다. 물론 매번 DB를 올리지 않아도 되도록 local h2 구성을 해주고, 실행 편의 방법과 README를 제공해줬지만 프론트 개발자 입장에서는 불편한 게 현실이었습니다. 그러던 중 슬슬 목표한 앱의 한바퀴가 성공했기에 AWS 구성을 해보았고 그 기록을 남겨봅니다. ⚠️ 주의! 이 글은 사이드 프로젝트 구성을 위한 삽질기이기에 접근 제어 및 보안이 실무 수준에 미치지 못합니다. 실무에서 고려해야될 사항이나 도움이 될만한 내용은 코멘트했지만, 개인적인 경험에서 나온 기록이기에 선별적으로 이해해주시면 감사하겠습니다. # 계획 작업 전 배경 지식 실물 장비 기반의 ..

옛날에 채널에 글을 작성하는 슬랙 연동을 했을 때는 webhook으로 했던 것 같은데, 다시 해보니 잘 안됐습니다. 정확히는 local 에서는 됐지만 github에 올리면 webhook url 이 바뀌는 현상이 발생했습니다. 이상해서 검색해보니 요즘은 slack API 를 연동하는 것이 최신이기도 하고 webhook 보다 다양하게 쓸 수 있을 것 같아서 연동해본 내용을 기록합니다. 사전 조사 Using Slack APIs Every Slack app has access to a bag of tricks—a range of APIs that provide access to read, write, and update all kinds of data in Slack. api.slack.com 먼저 slack ..

GitHub - Hyune-c/blog-code: https://hyune-c.tistory.com/ 의 예제 code https://hyune-c.tistory.com/ 의 예제 code. Contribute to Hyune-c/blog-code development by creating an account on GitHub. github.com 팀으로 진행하고 있는 사이드 프로젝트에서는 회원 관리를 자체적으로 구현했습니다. 로그인도 별 문제없고 잘 되는 줄 알았는데, 어느 순간 로그인이 되지 않는 현상이 발생했습니다. 다행히도 문제는 금방 해결했지만 생각할게 많아진 주제였기에 기록을 남겨봅니다. 1. 회원 구현 @Entity public class Member { @Id @GeneratedValue(..

Step 3. 비동기 로직 @Configuration @EnableAsync public class AsyncConfiguration implements AsyncConfigurer { } 먼저 비동기 사용을 위한 설정을 추가합니다. @RestController public class AsyncTestController { private final AsyncService asyncService; @GetMapping("/api/test/async") public void asyncTest() throws InterruptedException { for (int i = 1; i { if (copyOfContextMap != null) { MDC.setContextMap(copyOfContextMap); }..

이전에 코드스쿼드에 공개해서 반응이 뜨거웠던(?) 표준 예외 처리가 있습니다. 하지만 실무를 하다 보니 부족한 점이 보이고, 고도화하는 김에 로깅까지 해야겠다고 생각해서 글을 작성해봅니다. 이전의 repository 도 남기지만 굳이 참고하지 않고 본 코드만 따라오셔도 무방합니다. [deprecated] 표준 예외 처리 표준 예외 처리에서 로깅까지 Step 1. 리팩터링 이전에 작성한 표준 예외 처리를 리팩터링 하는 것으로 시작하겠습니다. 1. ExceptionAdvice 분리 2. 테스트 케이스 이 정도로 장애 원인을 추적할 수 있나? 실무에서는 장애를 추적하기 위해 장애 난 시점만이 아닌 연관된 흐름을 봐야 합니다. 하지만 Step 1 에서는 logId 가 에러 발생 시점에만 존재하기 때문에 동시에 ..