오늘 포스팅은 다소 어이없을(?) 수도 있다. 오늘의 주제는 Java Stream의 일부인데, 모르고 쓴다기보단 막 쓰면 일어나는 일이라고 해야 할 수도 있겠다. 더 나아가자면 Stream의 문제가 아닌 그냥 개발자의 태도의 관한 포스팅이라고 생각하면 편할거 같다. 이전 회사에서는 Stream을 자주 사용하지 않았다. 대부분을 향상된 For문과 조건문을 활용해서 각종 필터링 작업을 진행하고, 그룹핑 해야하는 부분에서만 간혹 사용하곤 했다. 그런데 이번 회사는 신기할정도로 Stream을 자주 쓰고 거의 대부분이 Stream을 통해 구현되어 있다. 적응하면 가독성도 좋아지고 퍼포먼스도 잘 나온다고들 하는데, 나는 사용을 거의 안 해봐서 별로 체감하지 못하고 있었다. 그래도 지금 하는 프로젝트에선 주로 사용하..

안녕하세요! 해피 추석입니다 😋 이전에 다니던 회사에서는 모든 서버에 Swagger UI를 도입하여 사용하였다. Swagger UI를 사용하면 컨트롤러에 설정한 모든 Endpoint나 Parameter들이 개발자가 세팅하지 않아도 화면으로 구성된 칸에 작성만 해주면 알아서 적절하게 API Request를 날려준다. 하지만 지금 다니는 회사에서 한 서버에 Swagger UI를 사용하지 않고 있다. Swagger UI 물론 굉장히 쉽고 간편하지만, 너무 편하게 사용한 나머지 어떻게 사용되는지를 생각하지 않고 개발을 하게 되어서 Swagger UI를 사용하지 않는 서버에서 API 테스트를 하려고 하니 앞이 막막했다. Postman을 사용하여 API를 테스트하는데, 자동으로 세팅해주던 Swagger UI와는 다..

동시성 이슈 문제를 해결했던 업무 회고를 작성했던 지난 포스팅에 이어서 동시성 이슈 문제의 해결 방법 중 하나인 Lock이라는 거에 대해서 좀 더 자세히 알아보고자 한다. 지난 포스팅에서 나는 동시성 이슈를 JPA의 Lock Annotation을 이용하여 대응을 하였다. 동시성 이슈에 대해서 공부 하다보면 대응을 위해서 Redis 데이터베이스를 썼다는 이야기가 많이 나온다. 대략적인 이유를 보면 '단일 스레드 처리 방식과 데이터 잠금의 차이'라고 나와있다. 나는 그래서 Lock을 사용하고자 했던 거고 이번 기회에 Lock에 대해 더 공부를 하게 되었다. Lock? Lock이란 트랜잭션 처리의 순차성을 보장하기 위한 방법으로, 같은 데이터에 동시에 접근하는 경우 데이터의 일관성과 무결성의 유지를 위해 사용..