서문 2024년 1월 18일. 나에게 부족한 점, 그리고 나에게 주어진 피드백을 정리하며 마음을 다 잡았다. 노력의 결과였을까. 서류, 코딩 테스트, 1차 면접, 2차 면접을 통과하여 꼭 가고 싶었던 회사인 트렌비에 합격을 하게 되었다. 취업이라는 목표를 이루었고, 나는 이제 개발자라는 출발선에 다시 서게 되었다. 출발선에서 앞으로 내가 이뤄나가야 할 상반기 목표들을 정리해보고자 한다. 개발 아직 팀이 정해지지 않았고, 어떤 도메인을 도맡아서 개발을 할지에 대해서도 미지수이다. 하지만, 면접을 보면서 회사에서 현재 내 기술 스택과 비교하여 부족한 부분들이 무엇인지 들을 수 있었다. 상반기에는 회사의 문화에 적응하며 기술을 다룰 수 있도록 정진하여 사고치지 않고 1인분을 할 수 있게 됨에 집중해보도록 하자..
최근 4번의 최종 면접 탈락을 겪으면서 자존감이 많이 떨어져있다. 이렇게 죽어있는 상태로 나아가다간 나의 성장은 멈출 것 같다는 느낌이 들었다. 지금 이 글을 작성하고 있는 현재 나는 무엇을 하고 있는지 그리고 이를 토대로 무엇을 개선하면 좋을지에 대해 되돌아보자. 현재의 활동 현재 나의 패턴을 정리해보자. 오전 오전 7시에 일어난다. 데브코스 팀원들과 미라클모닝을 실천한지 어느덧 1달차가 되어간다. 미라클 모닝은 더욱 일찍 일어나야 하지만, 우선 7시에라도 일어나서 활동하자는게 취지이다. 벌써 1달이 거의 다 되어가지만, 아직도 일어나는 일은 쉽지가 않다. 몸을 뒤척이다 핸드폰으로 유튜브를 잠깐 볼까 하지만 머릿속으로 아침에 일어나자마자 보는 유튜브는 이후의 두뇌의 활동을 무너뜨린다는 얘기를 들은 적이..
칼바람이 불던 2023년이 지나고 어느덧 2024년이 되었다. 달마다 연마다 나의 한해는 어땠는지 되돌아보는 회고 시간이 가장 중요하기 때문에 작성을 해나가며 회고를 진행해보고자 한다. 2022.12 ~ 2023.02 2022년도 10월부터 진행했던 캡스톤 프로젝트를 혼자서 가져가게 되면서 여러모로 부족한 부분이 많이 보였던 프로젝트였다. 당시에 js, http 자체를 이해하기 버거워해서 프론트를 다루는게 너무 어려워했었다. (지금와서 생각해보면 부딪혀가면서 했으면 어땠을까 싶기도 하다) 12월에 팀을 다시 새로 만들고 코드 자체도 리팩토링을 하면서 프로젝트를 다시 진행을 했었다. 당시에 테스트 코드를 작성하면서 테스트 코드를 작성하는 시간이 너무 많이 소요된다는 이유로 테스트 코드 작성을 소홀히 했었다..
N + 1 문제를 해결하는 과정에서 발생하는 성능 차이 개요 프로젝트 도중 N + 1 문제를 해결하는 과정에서 예상하지 못한 성능 문제가 발생하였습니다. N + 1 문제를 해결하고 성능을 개선하면서 1 + 1 쿼리로 바꿨음에도 불구하고 성능이 떨어지는 이슈가 발생한 사례를 소개하도록 하겠습니다. N + 1 문제란 N + 1 문제를 해결하는 과정을 살펴보기 전에 N + 1 문제가 무엇인지 먼저 간단하게 알아보도록 하겠습니다. N + 1 문제는 연관관계가 설정된 엔티티 사이에서 한 엔티티를 조회하였을 때, 조회된 엔티티의 개수(N) 만큼 연관된 엔티티를 조회하기 위해 추가적인 쿼리가 발생하는 문제입니다. N + 1 문제의 해결 방법 N + 1 문제를 해결하기 위한 방법으로는 상황에 따라 FetchJoin, ..
Redis Template 사용 시 주의사항 최근 Redis 학습 테스트를 진행하면서 발생했던 이슈를 하나 공유하고자 합니다. Redis의 자료구조 중 set 자료구조를 테스트하고자 하였습니다. 해당 테스트 코드는 다음과 같습니다. @DisplayName("restTemplate key-value(Set) 형식으로 저장한다.") @Test void saveSetForOps() { // given SetOperations stringObjectSetOperations = redisTemplate.opsForSet(); String KEY = "setKey"; LocalDateTime serverTime = LocalDateTime.now(); Fruits apple = Fruits.createFruit("..
들어가기전, EC2 서버 환경은 Amazon-Linux-2023 입니다. 프로그래머스 데브코스 기간 중 서버가 매일 오전 10시에 켜지고 새벽 2시에 꺼지도록 자동으로 설정이 되어있었습니다. 인프라를 담당하고 있던 제가 만약 누군가가 서버를 사용해야 한다면 새벽 2시까지 기다렸다가 서버를 켜주어야 하는 불편함이 있었습니다. 개발을 할 때부터 EC2 서버가 켜지면 필요한 Docker-Container 들이 실행되었으면 하는 생각이 있었습니다. 프로젝트 종료 이후 해당 방법을 해결하기 위한 방법을 찾아봤고, 비교적 간단한 방법으로 설정 할 수 있었습니다. 1. systemctl 을 등록 할 수 있도록 service 들이 모여있는 directory 로 이동 cd /etc/systemd/system 실제로 많은..
Spring Data Redis는 Key-Value 구조의 자료구조만 사용하기 때문에 다른 자료구조도 테스트 해보기 위하여 RedisTemplate를 직접 만들어서 학습 테스트를 진행해봤습니다. redisTemplate.opsForValue(); 를 사용하여 key-value 자료구조에 대해서 Primitive Type, Reference Type 두 경우에 대해서 테스트를 진행해보고자 하였습니다. @DisplayName("redisTemplate key-value 형식으로 기본형 타입 저장") @Test void saveValueOpsPrimitiveType() { // given ValueOperations stringObjectValueOperations = redisTemplate.opsForVa..
Redis TTL 이슈 레디스의 학습 테스트를 진행 하던 중 TTL 설정 시 발생하는 이슈를 확인 할 수 있었다. 다음과 같은 도메인이 있다. @Getter @NoArgsConstructor(access = AccessLevel.PROTECTED) @RedisHash(value = "fruits", timeToLive = 1) public class Fruits { @Id private String id; private String name; private Integer stock; @Indexed private LocalDateTime createdAt; @Builder private Fruits(String name, Integer stock, LocalDateTime createTime) { thi..
최종 프로젝트를 진행하면서 멀티 모듈 설계에서 겪었던 이슈들을 몇 가지 공유하고자 한다. 먼저, 초기에 계획 된 우리 팀의 멀티모듈 구조는 다음과 같이 설계되었다. 위 사진처럼 멀티모듈 구조를 레이어별로 가져가기로 했다. 레이어별로 구조를 가져가기 이전에 먼저 모듈을 어떻게 가져가는 것이 좋을지에 대해 팀원들과 얘기를 나누었다. 하지만, 프로젝트 기간이 짧은 만큼 도메인이 많이 발생 할 것으로 예상되지 않고 멀티 모듈을 구성했을 때 모듈 별로 부트 서버를 따로 띄울 일이 프로젝트 구조 상 발생하지 않을 것 같다는 전제에서 시작했다. 고민을 레이어별로 모듈을 나누는 것과 도메인 별로 모듈을 나누는 것 두 가지를 고려했기 때문에 자연스럽게 레이어 별로 모듈을 가져가기로 결정하였다. 참고로, 멀티모듈을 어떻게..
프로그래머스 데브코스에 참여한지 이제 거의 6개월이 다 되어간다. 현재는 최종 프로젝트 기간 중 QA 기간이라 포스팅을 쓸 시간이 생긴 것 같아 하루에 겪었던 이슈들을 하나씩 정리해보려고 한다. 그 중에서는 일정 관리 부분이 가장 중요했던 것 같다고 생각하여 이를 얘기해보고자 한다. 서론 프로젝트를 진행하기 전에 프로그래머스에서 '일하는 우리'의 지윤정님의 강의를 통해 협업에 임하기 전에 배워야 할 태도와 애자일 방식의 프로젝트 관리를 방법을 간단하게 배우게 되었다. 저번 1차 클론 코딩 프로젝트에서는 제대로 진행이 되지 않았지만, 최종 프로젝트에서는 애자일한 협업을 한 번 해보고자 마음을 먹었다. 팀원분들이 대부분 내향적인 성격을 가지신 MBTI I로 구성이 되어있었다. 스크럼을 이끌어가는 것은 그래도..
서두 동작을 설명하기 이전에 지역 데이터를 스프링의 캐시 기반으로 조회를 하려고 했던 배경에 대해서 먼저 소개하겠습니다. 현재 진행 중인 프로젝트에서는 사용자들이 자신의 선호지역 혹은 자신이 검색하고자 하는 지역들을 선택 할 수 있습니다. 이를 클라이언트에서 불러오기 위한 방법을 2가지를 떠올렸습니다. 1. 먼저 시를 선택하면 시에 해당하는 id 값을 서버에 보내서 구를 가지고 오는 api를 호출한다. 2. 구가 도착하면 다시 구를 선택하고 구에 해당하는 id 값을 서버에서 보내서 동을 가지고 오는 api를 호출한다. 3. 마지막으로 동을 선택한다. 위와 같은 과정은 먼저 3번의 네트워크를 타야하고, 유저가 어떤 시, 구, 동을 선택할지 예상 할 수 없었습니다. 캐시를 사용한다고 하더라도 각 시에 호출,..
1차 면접 글을 올리고 난 후 많은 시간이 흘렀다. 포스팅을 준비해둔 주제는 정말 많았는데, 우선순위를 정하면서 포스팅을 뒤로 미루다보니 이제서야 적게 되었다. 하지만, 면접 당시 그 날의 기억은 뚜렷하고 내용을 잘 정리해두었기에 늦었지만 작성을 해본다. 면접 전 임원 면접은 첫 경험이었다. 따라서, 무엇을 준비해야 하는지 어떤 것을 준비해가야 할 지 면접에 대한 질문은 무엇이 나올지에 대해서 준비를 많이 했던 것 같다. 하지만, 여러가지 예상 질문들을 미리 준비를 했었는데, 임원 면접을 봤던 동료들에게 조언을 구하니 사실 그런 질문들은 미리 준비한다고 해서 예상 질문들로 보통 나오지 않는다. 그런 것 보다는, 다른 분야를 준비하다가 왜 이쪽 분야를 준비하게 되었는지에 대한 시나리오가 더 중요 할 것 같..
멀티 모듈을 적용한 계기 우리 팀이 진행한 캐치 테이블을 클론 코딩한 Dev-table 에서는 다음과 같은 기능을 구현하고자 하였다. 유저의 예약, 웨이팅 점주의 예약, 웨이팅 예약, 웨이팅을 알려줄 수 있는 알림 처음에는 이러한 기능들을 모두 하나의 모듈에서 처리하도록 구성을 해두었다. 즉, 다음과 같은 패키지 구조가 나타나게 된다. devtable ㄴ src ㄴ main ㄴ domain ㄴ reservation ㄴ application ㄴ OwnerReservationService ㄴ UserReservationService ㄴ presentation ㄴ OwnerReservationController ㄴ UserReservationController ㄴ waiting ㄴ application ㄴ O..
NHN의 T면접은 매번 채용시장에서 찾고자 하는 인재에 따라 인터뷰 방식이 달라지는 느낌이었다. T 면접을 보기 전에 도움이 될 만한 다른 포스팅 자료가 있는지를 알아봤는데 참고할 만한 자료가 많이 없었다. NHN T 면접에 대해서 어디까지 얘기를 할 수 있을까? 생각을 해봤을 때 어떤 문제가 나왔는지보다 어떤 방식으로 진행되는지만 간략하게 얘기를 하는 것이 좋을 것 같다. 기술 인터뷰 진행 전 인터뷰 방식에 써있는 것처럼 알고리즘 문제를 풀 수 있는 시간이 주어진다. 해당 시간동안 주어진 문제를 풀고 해당 문제를 바탕으로 기술 면접관들과 어떻게 풀어나갔는지, 더 좋은 해결 방안은 없을 지 서로 소통을 하면서 문제를 풀어나가는 방식이다. 준비를 해나가는 과정에서 알고리즘을 어느정도까지 알아야 하나요? 라..
왜 시작했는가 대학교를 다니면서 개발을 좋아하지만 막상 어떻게 개발해야 하는지 알지 못한 채. 그저 만들고 싶은것만 구글링 해가면서 만들어나갔다. 결과물을 만들어 낼 수는 있었지만 막상 얻게된건 구글링으로 검색하여 다른 사람의 코드를 덕지덕지 붙여서 완성하게 된 그런 결과물. 해당 결과물에 대해서 설명 할 수 있는가. 라고 하면 설명 할 수 없는 그런 결과물이었다. 졸업 이후 취업 준비를 하게 되면서 다른 사람은 코드를 어떻게 작성하는지 어떻게 짜는 코드가 좋은 코드인지 저 사람들에 비해 내가 부족한 것은 무엇인지. 메타인지를 하기 시작했다. 그렇게 차근차근 기본기를 쌓아가면서 6월부터 시작하게 된 프로그래머스 데브코스 백엔드 과정 부트캠프에서 코드 리뷰를 통해 내가 지금까지 무엇을 잘 못 알고 있었는지..
지원 이전 NHN은 Java 컨벤션에 대한 문서가 잘 정돈되어있는 만큼 평소에도 개발 문화가 좋은 곳이구나. 라고 생각을 하며 꼭 서류를 작성해보고 싶은 부분이었다. 이 때, 남들과 다르게 특별한 부분이 있었는데 지금까지 웹 백엔드 개발자를 준비해왔지만 직무를 게임 서버 개발자라는 직무에 지원하였다. 이 부분은 C 면접 파트에서 후술하도록 하겠다. 서류 매달 자신에 대해서 회고를 진행하면서 추가 할 내용이 있는지 이력서를 검토하면서 업데이트를 해나갔기에 추가 할 부분들만 추가하여 이력서를 제출하였고, 자기소개서 양식은 자유 양식이라 본인이 어떠한 가치관으로 개발을 하고 개발을 어떻게 진행해왔는지 실제로 나라는 사람은 어떠한 가치관으로 인생을 살아가고 있는지에 대해서 서술하였습니다. 코딩 테스트 문제는 총..
서론 이번 주차에는 특별한 일들이 많았다. 하나씩 차근차근 있었던 일들을 정리해 볼 필요가 있었다. 프로젝트의 설계 먼저, 캐치테이블을 클론 코딩을 하기 위한 애플리케이션의 분석 및 erd 설계, 유저 스토리 정리가 마감이 되고 월요일 날 멘토님에게 컨펌을 받을 필요가 있었다. 캐치 테이블을 클론 코딩을 하기 위해 도메인을 분석하면서 나타나게 된 도메인은 7개 정도로 추려졌다. 하지만, 3주 동안의 클론 코딩을 진행하면서 7개의 모든 핵심 도메인을 구현한다는 것은 욕심이라고 생각이 들었고, 팀원들에게 다음과 같은 의견을 제시했다. "캐치 테이블이라는 애플리케이션은 본래 어떤 것을 목적으로 만들어졌을까요? 제가 생각하기에는 손님과 점주간의 관계에 있어서 예약과 웨이팅이라는 서비스를 편리하게 제공하고자 하는..
이번 주 또한 쉬어가는 주여서 부족했던 부분을 보충 할 수 있는 주였다. 특히, 앞으로의 프로젝트 과정에서 모니터링이 중요하다고 생각하여 그라파나, 프로메테우스와 같은 모니터링에 대해서 공부를 했었다. 월요일날에는 타다 본부장님인 지두현님의 세션이 있었다. 세션에 대한 내용은 타다의 스프린트 방식에 대해서 알아볼 수 있는 내용이었는데, 말로만 들어오던 애자일 방식의 업무 진행이 어떻게 이루어지는지에 대해서 지두현 본부장님께서 잘 설명을 해주셔서 이해가 정말 잘 되었다. 그리고 지두현님께서 모든 세션에 대한 강의를 마치고 질문을 5개 정도 받는다고 말씀을 해주셨다. 나는 최근에 본 구현을 해야 할 용기에 대한 내용을 바탕으로 조금 예민할 수 있는 질문을 드렸다. 어떠한 유저들에게 굉장히 도움이 되는 아이디..
이번 주는 쉬어가는 주차였다. 프로젝트를 어떻게 설계하는 것이 좋고 컨벤션은 어떻게 가져가는 것이 좋은지, 프로젝트를 진행하면서 어떤 툴 들을 주로 사용하고 실무에서는 어떤 형태로 진행을 하고 있는지에 대한 내용 폭포수 방식의 개발과 애자일 방식의 개발의 차이, 그리고 PO, 스크럼 마스터의 역할과 스크럼을 어떻게 진행하는 것이 좋은지 이러한 두 가지 방식에 대한 학습이 이루어졌다. 이전까지보다 편하게 들을 수 있었고 프로젝트 진행 간 어떻게 진행을 해야되는지 고민을 하다가 미루고 미뤄두었던 깊게는 알지 않더라도 UI 부분을 처리하기 위한 리액트 프레임워크에 대한 학습을 지금 해야 될 것 같다는 생각을 하였다. 프레임워크로써 정해진 것만 수행하면 편하게 할 수 있는 Vue와 React 중에 결국 Reac..
서론 Spring Security를 Security 5로 공부를 진행해나가면서 Security6 에서 많은 부분이 변경되었다는 얘기를 듣고 공식문서를 보면서 학습한 내용에 대해 Security5를 Secuirty6로 Migration을 진행 해 나갔습니다. 그 중에서 SecurityFilterChain에 등록을 할 때 정적 자원들에 대해서 ignoring 설정을 해주지 않으면, SecurityFilterChain에서 이전에 등록되어있는 정적 자원들에 대해 모든 Filter들이 적용이 되기에 쓸데없는 메모리 낭비가 발생하고, ignoring설정을 해서 새로운 SecurityFilterChain을 만들어 주되 Filter 들은 추가되지 않는 방향으로 성능 개선을 진행한 사례를 볼 수 있었습니다. 이에 대해,..
OAuth2(Open Authenticaiton, Open Authorization) 표준 인증 프로토콜이다. 사람들은 타 사이트의 비밀번호를 제 3의 서버에서 노출하기를 꺼린다. → 노출되며 다른 정보도 노출 될 것이 자명하기 때문. 사용자가 타 사이트의 비밀번호를 변경하게 되면 제 3의 서버에 저장된 비밀번호도 바꿔야 해서 정상적인 서비스가 불가능하다. 주요 용어 Resource Owner : 서비스를 이용하는 사용자, 즉 리소스 보유자 Client : Resource Server에 자원을 요청하는 제 3 서버, RO를 대신하여 리소스를 요청한다. Resource Server : 클라이언트의 요청을 수락하고 응답할 수 있는 서버, ex) 네이버, 카카오 등 Authorization Server : 성..
어느새 프로그래머스 10주차가 되었다. 이번 주차에서는 Spring Security를 배웠다. Spring Security의 기본 아키텍쳐를 시작으로 자주 쓰이는 Filter들에 대해서 강의가 진행되었다. 강의 내용이 Security 5로 진행이 되었지만 Spring Boot 3.1.2 버전에서는 어떻게 적용되는지 궁금해서 강의 내용은 Security5로 구조에 대해서 공부를 하고 실습을 진행하면서 Spring Security 6로 리팩토링을 진행하였다. Spring Security 5에서 6로 변경되면서 Deprecated 된 부분이 많아서, 리팩토링하는데 조금 고생했지만 리팩토링을 하면서 디버깅 하는 방법에 대해서도 익숙해질 수 있었고, 그리고 공식문서를 읽는 것도 조금 익숙해졌다. 블로그 글을 보는..
데브코스를 시작한 지 어느덧 6주차이다. 많은 생각을 했던 주차 인 것 같다. 개인 과제도 해야하고, 코드리뷰 미션도 진행해야 하는 상황이었는데 멘토님에게 코드 리뷰를 받으면서 리팩토링을 크게 크게 거쳐서 진행을 했다. 그 과정에서 오버 엔지니어링을 여러 번 하게 되면서 수 차례 좌절을 겪었다..! 오버 엔지니어링을 하지 않도록 하는 연습도 정말 중요한 것 같다. 그리고 이번 주 다짐으로는 꾸준한게 중요한 것 같다. 열정보다는 시스템을 그리고 열정 과다로 지치지 말자. 또 하나 중요하게 생각해야 될 부분이 있다. 하나를 배우더라도 정확하게 알고 넘어가자. 복습을 꼼꼼하게 하자. 최근에 프리팀에서 같이 활동한 근우님과 학습 방향에 대해서 같이 말씀을 나누었다. 근우님도 꾸준하게 회고를 작성하시는 모습을 볼..
어느 새 프로그래머스 백엔드 데브코스 부트캠프를 시작한지 1달이라는 시간이 지났다. 해당 코스를 수행을 하면서 1달 동안 경험 한 작은 이야기들을 적어내려고 한다. 백엔드 개발자가 되기를 희망하는 분들께서 해당 글을 읽고 부트캠프를 선택하는데에 있어서도 도움이 되었으면 좋겠다. 데브코스에 들어오기 전 데브코스에만 해당하지 않고, 왜 부트캠프를 들어오게 되었는지에 대해서 부터 시작을 해야 할 것 같다. 하나의 졸업 프로젝트와 많이 관여는 하지 않았지만 하고 싶어서 만들게 된 게임 프로젝트, 모바일 플랫폼 프로젝트 등 다양한 프로젝트를 경험해봤다. 이러한 여러 개의 프로젝트를 진행하고 완성을 해내다 보니 학교를 다닐 때에는 주변에서도 "너 정도면 충분히 어디든 취업 할 수 있을 것이다.", "너 정도면 잘하..
먼저 해당 글을 작성하게 된 계기는 예외처리 테스트를 하던 와중에 assertThatThrownBy()로 예외가 발생하지 않는 경우를 처리를 하려고 했는데, 처리가 되지 않아 해당 내용에 대해 자세하게 알아보게 되었다. 그 과정에서 동료와 얘기를 나누면서 좋은 자료를 공유해주어서 정리하게 되었다. 설정 spring-boot-starter-web 을 선택했다면 spring-boot-start-test 의존성이 추가되어있다. 최근 버전은 Junit5가 기본적으로 되어 있어서 바로 Junit5를 사용할 수 있으나, 자바 프로젝트에서는 바로 주입이 안되어 있으므로 따로 설정이 필요하다. Maven Repository: org.junit.jupiter » junit-jupiter-api 해당 레포지토리에서 Jun..
타입 추론 var 타입추론은 개발자가 변수의 타입을 명시적으로 적어주지 않고도, 컴파일러가 알아서 이 변수의 타입을 대입된 리터롤로 추론하는 것. JDK 10에서 type-inference(타입 추론)이 적용되었다. JDK 10 이전과 이후의 차이를 한 번 살펴보자 String str = "Hello"; // JDK 10 이후의 var 적용 var str = "Hello"; 그리고 컴파일러는 var을 String으로 컴파일 단계에서 타입 추론을 해준다. 하지만 var은 아무때나 사용 할 수 있는 것은 아니다. 💡 Var은 초기화 값이 있는 지역변수로만 선언이 가능하다. 즉, var은 멤버변수, 파라미터, 리턴 타입으로는 사용이 불가능하다는 것이다. 혹시나 멤버변수를 final을 사용해서 var을 적용하면..
프리팀 기간이 이번 주를 기준으로 종료되게 되었다. 프리팀을 정말로 잘 만나서 앞으로 공부를 해나가야 할 방향성이라고 해야 할까? 정말 얼마만큼 공부를 해야 될지에 대해서 메타 인지를 할 수 있는 좋은 시간이었다. 못한 점 잘한 점 보다 못한 점 부터 먼저 파악을 해야겠다. 전반적으로 정말 바쁜 시간을 보냈지만, 나 자신과 지키지 못한 약속이 있다. 일일 TIL을 꼭 적기로 하였는데, 적지 못하였다. 정말로 시간을 쪼개고 쪼개어서 한다면 솔직히 가능한 영역이었다고 생각했지만 TIL보다 다른거에 더 치중해야겠다고 생각한 개인의 판단이다. 하지만, 이건 핑계일 수 있고 어떻게 TIL을 효율적으로 써내려갈지에 대해서 고민을 할 필요가 있는 것 같다. 현재 방향성은 일단 전반적으로 먼저 하루 공부한 내용에 대해..
클라우드와 AWS에 대해서 학습을 하였다. 그 과정에서 EC2 의 구매옵션에 대해서도 다루게 되었는데 종량제 방식인 On-demand 옵션, Reserved 옵션, Spot Instance에 대해서 배우게 되었다. 하지만 여기서 기존의 알고 있던 Spot Instance를 잘 못 알고 있었기에 다루게 되었다. Spot Instance Spot Instance 방식은 사전 약정없이 사용 할 수 있는 EC2 Instance 이다. 위의 사진처럼 스팟 인스턴스는 사용자 제시 가격(입찰가격)을 정해놓고 저렴할 때 이용하는 방식이다. 일반적으로 On-Demand 방식 대비 80 ~ 90%의 저렴한 가격으로 구매를 할 수 있다. 하지만 여기서 내가 잘 못(?) 이라기 보다 얕게 알고 있던 개념으로 Spot Inst..
화요일 날 진행했던, 팩토리 패턴과 싱글톤 패턴 발표자료 중 싱글톤 패턴의 발표 자료이다! 싱글톤 패턴 : 애플리케이션에 단 하나의 유일한 객체를 만들기 위한 패턴 싱글톤을 사용해야 하는 이유 위 처럼 각 각 독립된 기능을 수행하는 클래스를 클라이언트 각각이 클래스를 생성해서 사용하게 되면, 메모리 누수가 발생하게 됩니다. 물론 새롭게 생성된 객체들이 GC 를 통해서 자동으로 비워지기는 할 테지만 잦은 GC는 Stop the World 를 발생시켜 프로그램 사용에 있어서 느려짐을 겪을 수 있습니다. 또한, 만약 해당 클래스를 생성하는데 발생하는 리소스가 많다면 이는 더 심하게 발생할 것입니다. 따라서, 싱글톤은 한 번 생성하고 돌려쓰는 용도로 사용을 하는 방식이고 싱글톤 방식을 채택한다면 다음과 같아집니..
매일 매일 적었어야 했는데..! 발표에 과제에 너무나도 치였다..! 몰아적는건 좋지 않지만 그래도 했던 기록은 남기고자 한다. 다음 날 있을 디자인 패턴 스터디의 발표 자료를 준비했다! 해당 발표 자료를 올리고자 한다. 기본적으로 간단한 팩토리는 패턴으로 사용하지 않고 관용구로 사용한다고 하는데, 팩토리 메서드 패턴과 추상 팩토리 패턴의 기본적인 틀은 Simple Factory를 따라가는 것 같아서 위와 같이 표현을 했다. Simple Factory 자체는 프로그래밍에서 자주 쓰이는 관용구이고, 디자인 패턴은 아닙니다. 하지만 같은 개념을 확장한 Factory Method와 Abstract Factory는 패턴입니다. 팩토리 : 주로 객체 생성을 처리하는 클래스를 의미합니다. 팩토리 패턴은 왜 사용하는가..
