Big Tree

불이나도 해야하는 것은 저장이다. 그리고 개발자들이 제일 많이 써야하는 저장은 Git Commit + Push 아닐까. 그러나 문제는 원격 저장소인 Github에 잘못 파일이 올라가는 일이 발생한다는 것이다. 보통은 .gitignore 를 활용하면, 특정 폴더 혹은 파일에 대해서 예외처리가 가능하다. 허나 나의 경우, 실수로 ignore 처리가 되지 않아 API KEY 값이 업로드된 경험이 있다. 특히 AWS Key 같은 경우, 조심해야 하는게 나쁜녀석들이 키를 크롤링해가서 채굴기로 쓴다고 한다. 그렇게 몇천만원 나온 경우를 검색하면 심심치 않게 볼 수 있다. 물론 가져다 쓰는 녀석들이 잘못된 것이지만, 애초에 Key 값 같은 중요한 데이터들은 확실하게 관리하지 않은 컨트리뷰터의 잘못도 있다. 나 같은 ..

collections 모듈은 Python에서 제공하는 내장 모듈 중 하나이다. 이 모듈은 여러 유용한 자료 구조를 구현하는데 사용되는데, 그 중 하나가 `deque`(Double-Ended Queue) deque는 양쪽 끝에서 삽입과 삭제가 모두 가능한 큐(Queue)와 스택(Stack)의 역할을 동시에 맡는다! 이 자료 구조는 데이터를 양쪽 끝에서 추가하거나 제거할 때 매우 효율적인데, O(1) 의 시간복잡도를 갖는다. list는데이터를 삽입하거나 삭제할 때 맨 끝을 기준으로 작업을 수행하기 때문에, 리스트의 길이가 길어질수록 작업 속도가 느려진다. 시간복잡도가 O(N) 에 수렴한다. 반면, deque 는 데이터를 양쪽 끝에서 추가하거나 제거할 수 있으므로, 길이가 길어져도 빠른 속도로 작업을 수행할 ..

그리디 알고리즘(Greedy Algorithm)은 최적해를 구하는데 사용되는 근시안적인 방법론이다. 즉, 현재 상황에서 가장 최적인 선택을 하여 결과적으로 최적해를 도출하는 방법. 최적화 문제를 그리디 알고리즘으로 풀 수 있는 부분 문제들로 나눈다. 각 부분 문제에 대한 최적해를 구한다. 각 부분 문제의 최적해를 결합하여 전체 문제의 최적해를 구한다. 하지만, 그리디 알고리즘이 항상 최적해를 도출하는 것은 아니다. 때로는 그리디 알고리즘이 최적해를 보장하지 않는 경우도 있다. 그리디 알고리즘이 근시안적인 방법론이라고 말하는 것은, 현재 순간에서만 최적인 선택을 하기 때문에 전체적인 상황에서 최적해가 아닐 수도 있다는 것을 의미한다. 그러나, 그리디 알고리즘이 결과적으로 최적해가 될 수 있는 이유는 부분 ..

Why 서비스를 배포하다보니 계속해서 반복되는 작업이 눈에 띄었다. Spring 경우, 배포를 위한 과정이 python 프레임워크들에 비해 복잡했기 때문. 반복적으로 배포 과정을 불필요하게 진행하는 것보다 반자동으로 편하게 작업할 수 있을 것 같았다. 기존에 Docker 활용할 때도 일일이 입력하는 명령어 집합을 만들어서 종종 썼었으니. 검색해보니까 다양하게 나왔으나, 우선 내가 필요한건 라이트하게 임시로 쓸 수 있는 배포였다. CI/CD 전문화하여 구축하기에는 '시간'이라는 리소스가 한정적이므로 trade-off가 명확했다. HOW 그래서 여러가지 찾아보는데, 이상하게 내용이 오버 스펙처럼 보였다. 굳이 이렇게 까지...? 라는 생각이 계속 들었다. 대게 어떤 방식이냐면... (0) Spring pro..

JPA(Java Persistence API)는 자바 진영의 ORM 기술 표준이다. JPA는 객체와 관계형 데이터베이스 간의 매핑을 제공하여, 객체 지향 프로그래밍과 관계형 데이터베이스를 연결하는 데 도움을 준다. JPA는 엔티티(Entity)라는 개념을 사용하여 객체를 데이터베이스에 저장하고, 조회하고, 삭제할 수 있다. JPA는 ORM 기술의 장점을 살려서, 개발자가 직접 SQL 쿼리를 작성하지 않고도 데이터베이스와 상호작용할 수 있다. 즉 개발자는 객체 지향적인 코드를 작성하면서도 데이터베이스와 효율적으로 상호 작용 할 수 있다. JPA도 인터페이스를 정의한 것이며, 이를 구현한 클래스들이 JPA 구현체다. JPA 구현체는 JPA 표준을 준수하며, JPA가 제공하는 API를 구현하여 객체와 관계형 ..

이전에 한가지 질문에 봉착했다. "SQL에서 Join을 안쓴다면, Join을 안 만들었겠지. 근데 Join을 만들었다는건 쓰라는거잖아?" 내가 Join을 잘 사용하지 않고, 데이터 처리를 하는걸 보고 들은 이야기이다. 물론 필요해서 만들었다가, 생각보다 효율이 안나오는 사례도 있기 때문에 저말이 정답은 아니라고 생각하지만, Join 잘 활용하는 것도 능력이긴 하니까. 그렇다면 Join을 쓰는 사례와 안 쓰는 사례에 대해서 고민을 해보았고, 그 과정에서 Lazy Loading 을 접했다. 우리는 NoticeContent Table 과 NoticeComment Table 을 갖고 있으며, 각 Notice list를 반환시키는 함수를 만든다고 가정하자. content_list = NoticeContent()...

항상 말이 많은 주제이다. CS(Computer Science)에 대한 이론적 지식이 실질적으로 프로덕트를 생산하는 현업에 있어서 정말로 필요한가? 에 대한 논쟁이다. 운영체제/데이터베이스/자료구조와 같은 이름만 보면 상당히 고리타분해 보이는(...) 과목들을 배우는데, 이게 정말로 실제로 우리가 프로덕트를 만드는데 필요하냐는 주장이다. 요즘같은 시대에 널린게 오픈소스인데, 남들이 만들걸 가져다가 쓸줄만 알면 되는거 아닌가? 우리가 자동차를 만듦에 있어서 바퀴를 재발명하는게 옳은 일인가? 라는 논지이다. 결론만 두괄식으로 말하면 나는 CS 지식은 필요하다는 입장이다. 그 이유는 다음과 같다. 1. 지식이 많다는 것은 넓게 볼 수 있는 시야를 갖는다는 것이다. = 아는 것이 많을 수록, 우리는 다양한 요소..

레이어드 패턴은 백엔드에서 다룰 때 쓰는 패턴이다. 개인적인 생각으로는 MVC와 매유 유사하다고 생각한다. 보여주는 곳/로직 처리/디비 접근 3가지 파트로 나누어 처리하는 것인데, 이는 담당 위치를 분리함으로써 명확한 역할군의 분리가 눈에 띈다. 일반적으로 경력 백엔드 개발자들은 이렇게 작업하는게 "당연"한 것이나, 아무래도 백엔드 자체 특성상 신입이거나 배우는 단계인 사람들에게 지식이 타 계열에 비해 적지 않나 싶다. ㄴcontroller (Presenstation Layer) ㄴuser_controller.py ㄴservice (Business Layer) ㄴuser_service.py ㄴmodel (Persistence Layer) ㄴuser_model.py Presentaion Layer #ser..

Monolithic Service vs Micro Service 두 가지 아키텍쳐로 백엔드 구성이 나뉠 수 있다. 전자는 하나의 큰 줄기에 모듈단위로 작업이 처리되는 것이고, 후자는 기능단위로 여러 줄기로 나누어 작업을 처리하는 것이다. 현재 우리 서비스는 전자로 설계되어 있다. 하지만 이번에 마이크로 서비스로 변경하자는 제안이 있었고 해당 작업을 진행중이다. 이러한 작업을 진행하는 이유는 1. 가독성의 문제(=코드간 독립성 증대) = 사실 이건 모놀리식과 마이크로 간에 문제와는 결이 조금 다르지만, A 모델을 다루는 컨트롤러가 B 모델을 다루는 컨트롤러에 직접 접근하는 경우가 많아지면 보기에 매우 불편하다. 이를 서비스 단위로 나눈다면 조금 더 간편해진단 의견이 있었다. 2. 협업의 문제 = 협업하는 ..

플라스크는 정말 micro한 장점이 있다고 생각한다. 타 프레임워크에 비하면 구조나 세팅에 있어서 매우 자유롭다 즉 그만큼, 자동으로 해주는게 적다는 뜻이기도 하다(=내가 고생을 해야한다) 아무튼 Flask를 활용하다 보면 한 파일에 많은 양의 라우팅 함수가 모이는 경우를 볼 수 있다. @app.route('/users/') def show_users(page): users = User.query.all() return render_template('users.html', users=users) @app.route('/') def main(): return render_template('main.html') @app.route('/report') def report(): return render_temp..