객체지향 패러다임의 핵심은 역할, 책임, 협력이다. 협력 : 애플리케이션의 기능을 구현하기 위해 객체들이 수행하는 상호작용 책임 : 협력에 참여하기 위해 객체가 수행하는 로직 역할 : 객체가 수행하는 책임들이 모여 구성된 것 협력은 객체지향의 세계에서 기능을 구현할 수 있는 유일한 방법이다. 두 객체 사이의 협력은 하나의 객체가 다른 객체에게 도움을 요청할 때 시작된다. 메시지 전송은 객체 사이의 협력을 위해 사용할 수 있는 유일한 커뮤니케이션 수단이다. 결과적으로 객체를 자율적으로 만드는 가장 기본적인 방법은 내부 구현을 캡슐화하는 것이다. 캡슐화를 통해 변경에 대한 파급 효과를 제한할 수 있다. 그렇기 때문에 자율적인 객체는 변경하기 쉬워진다. 만약 Movie가 캡슐화를 하지 않는다면, 내부 구현을 ..
객체와 객체 지향 진정한 객체지향 패러다임으로의 전환은 클래스가 아닌 객체에 초점을 맞출 때에만 얻을 수 있다. 첫째, 클래스 이전에 어떤 객체들이 필요한지 고민하라. 클래스의 윤곽을 잡기 위해선 어떤 객체들이 어떤 상태와 행동을 가지는지 먼저 결정해야 한다. 둘째, 객체를 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 일원으로 봐야 한다. …이것은 설계를 유연하고 확장 가능하게 만든다. 프로그램이 사용되는 분야를 도메인이라고 부른다. 객체지향 패러다임이 강력한 이유는 요구사항 분석 단계부터 프로그램 구현 단계까지 객체라는 동일한 추상화 기법을 사용할 수 있기 때문이다. 인터페이스와 구현의 분리 클래스의 내부와 외부를 구분해야 하는 이유는 무엇일까? 경계의 명확성이 객체의 자율성을 보장하..
초심은 참 지키기 어렵다. 대학교에서 c언어를 배울 때만 해도 초심이 있었다고 생각한다. 포인터가 어떻게 동작하고, 컴퓨터에 데이터가 어떤 식으로 저장되는지 호기심을 갖고 공부할 때가 있었다. 포인터의 크기가 64 비트 os상에서 8바이트라는건 아직도 바로 기억이 난다. 데이터구조, 알고리즘 등도 비슷했다. 원리에 대해서 나 스스로 곱씹어보고 호기심을 해결해나갈 때 기분이 좋았다. 그러나 백엔드 프로젝트를 해가면서 조금씩 초심이 무너졌다. 정확히 말하자면 나의 게으름이 그 원인이다. 프로젝트를 처음 할 때만 해도, 김영한님의 강의들을 보고 토이프로젝트를 만들어보면서 호기심을 하나 하나 풀어갔다. 스프링은 어떻게 요청을 받고 어떻게 응답을 처리하는지, 스프링은 DB와 커넥션을 어떻게 만드는지 찾아봤었다. ..
‘오브젝트: 코드로 이해하는 객체지향 설계’를 읽고 공부한 내용입니다. 공부하며 작성한 내용이기 때문에 오류 사항이 있을 수 있습니다. 잘못된 부분은 피드백 부탁드립니다. 1장 내용 의존성 : 다른 객체 내부를 알면 알수록 변경에 취약해진다 초기의 코드는 Theater (극장) 객체에서 관객, 관객의 가방, 초대장, 티켓, 티켓 판매원, 티켓 판매소를 알고 있는 상태입니다. 그리고 티켓 구매 로직까지 모두 책임지고 있습니다. 전형적인 절차지향적 프로그래밍이라고 할 수 있습니다. public class Theater { private TicketSeller ticketSeller; public Theater(TicketSeller ticketSeller) { this.ticketSeller = ticket..
2023년은 작년보다 조금 더 바쁘게 지내며 크고 작은 결실을 맺은 해였다. 요약하자면, 스프링 백엔드 개발자가 되기 위해 노력한 해이다. 스프링 전향, 공부 시작 올해 1월부터는 자바 스프링 백엔드 개발이 유망하다고 생각해 스프링으로 전향하게 되었다. 김영한님 강의를 들으며 공부했다. 아무래도 이전에 django, node.js 프로젝트를 했어서인지 전반적인 흐름을 빠르게 파악할 수 있었다. 가장 어려웠던건 IoC, DI 등 객체지향 언어의 프레임워크로써 갖는 스프링의 특징들이었다. 솔직히 OOP도 감으로만 익힌 상태였어서, 이것들이 왜 필요하고 어떻게 동작하는지 바로 이해하기 힘들었던 것 같다. 이때 크게 느낀게, 나는 이론만 공부하는 것보다는 구현하면서 부딪혀보면서 빠르게 배우는 타입이라는 점. 올..
💡 발단 아침에 일어나자마자 섬뜩한 슬랙 알림을 보게됐다. EC2 CloudWatch를 확인해보니 CPU 사용률이 99%를 찍고 사실상 중지된 모습. DB 커넥션은 급락했다. 서버가 정상 작동하지 않는다는 간접적인 신호인 것으로 파악했다. 원인 파악 시나리오 1 : 누군가의 무분별한 요청 ❌ 몇주동안 잘 작동하고 있었기 때문에 외부 변수부터 찾으려고 했다. CloudWatch에서 서버 요청 로그를 확인했다. 무분별한 해외 IP 요청 때문에 스레드 풀이 초과됐다는 레퍼런스를 봤었기 때문이다. https://mopil.tistory.com/128 아래는 서버가 죽을 당시의 로그 기록. 확인해보니 헬스 체크 컨트롤러로 계속해서 요청이 들어오고 있었다. 그런데 이게 의문사의 원인이라고는 생각하지 않는다. 해외 ..
💡 발단 앱을 런칭하기 전부터 불안한 점이 있었다. "만약 서버가 터진다면... 어떻게 해결하지?". 그래서 생각한게 로깅이었다. 로깅이 모든 문제를 해결할 수는 없겠지만, 문제를 해결하는데 필요한 결정적인 실마리를 줄 수 있다고 생각했다. 적어도 비정상적인 요청 혹은 서버내의 에러를 파악할 수 있다고 생각해서 바로 적용하게 됐다. 물론 서버에 SSH 접속해서 직접 로그를 확인하는 방법도 있다. 그래서 해당 프로젝트에선 docker를 사용해서, docker log 명령어를 사용해서 확인해왔다. 그러나 만약 서버가 죽는다면? SSH 접속 자체가 안된다면 원인을 파악할 방법이 없어지게 된다. 외부의 어딘가에 로그들을 저장해둘 필요가 있었다. 그래서 찾아본게 AWS CloudWatch. 공식적으로 로그 기능을..
프로젝트의 요구사항과 전반적인 맥락은 여기에 정리해놓았습니다 : 실시간으로 적재되는 데이터와 부모 엔티티 한번에 가져오기 ⚠ 발단 실시간 혼잡도 데이터가 계속해서 쌓이면서 60만개가 넘어가던 상황이었다. 앱을 켜보니 응답이 너무 오래 걸리는 상태가 지속됐고, 나중에는 아예 에러가 터졌다. 스프링의 기본 read timeout(서버의 response time에 대한 제한) 시간은 5초인데, 이를 초과한 것. 직접 쿼리를 날려봤더니... 무려 6초를 넘기고 있었다 혼잡도 데이터는 매일 몇만개씩 쌓여가고 있기 때문에, 정상적인 서비스를 위해선 빠르게 개선해야만 했다. 💡 해결 과정 : 기존 쿼리문 안에서 INDEX 사용 🤔문제 파악 기존의 쿼리에서 가장 문제가 됐던 부분은, 가장 최근의(실시간) 혼잡도를 가져..
기아 상태가 무엇인가요? : 스레드가 스케줄링 과정에서 선택되지 못한 채 오랫동안 준비 리스트에 있는 상황 우선순위를 기반으로 하는 시스템에선 높은 우선순위의 스레드가 계속 준비 리스트에 들어오면서 발생하며 실행 시간이 짧은 스레드를 우선 실행시키는 알고리즘이 사용되는 경우엔 계속 더 짧은 스레드가 준비리스트에 들어오면서 발생한다. 기아 상태를 어떻게 해결할 수 있나요? : 에이징(aging) 기법으로 해결할 수 있습니다. 에이징이란 스레드가 준비 리스트에 머무르는 시간에 비례하여 우선순위를 높여주는 기법입니다. CPU 스케줄링에 대해 설명해주세요. : 준비(Ready) 상태에 있는 스레드들 중 하나를 선택하여 CPU를 할당하는 과정입니다. CPU 스케줄링의 기본 목표는 CPU 활용률 (CPU Utili..
💡서론 분명 컴퓨터공학과에서 공부를 하고 있는데, 채워지지 않는 부분들이 있었습니다. 개발을 하면서 지식을 응용한다는 생각이 들지 않고 별개로 느껴졌습니다. 그건 시험, 과제만을 위해서 공부했기 때문이라고 생각합니다. 휘발되지 않게 장기 기억으로 저장하고 싶었습니다. 그래서 블로그를 시작했고 소기의 목적은 달성했지만, 사람들에게 정말 지식을 공유한다고 생각하지 못해서 개인 메모장의 느낌으로 작성하게 되었습니다. 그래서 스터디를 꾸려보기로 했고 팀원을 구하기 시작했습니다. 복수전공 초기였기 때문에 당시의 유일한 소통창구는 에브리타임이었습니다. 감사하게도 생각보다 많은 학생분들이 관심을 가져주셨고 총 4명의 팀으로 시작하게 됐습니다. 🖊본론 진행 방식에 대한 고민 목표는 컴퓨터공학에서 다루는 주요 CS 지식..
