noobdev25 님의 블로그

프로세스란?컴퓨터에서 실행되고 있는 프로그램을 말하며, CPU 스케쥴링의 대상이 되는 작업(task)이라는 용어와 거의 같은 의미로 쓰임.프로세스 = 현재 실행되고 있는 프로그램 하나- 프로그램 파일이 그냥 하드디스크에 있을 땐 프로세스가 아님. 그 프로그램이 메모리에 올라가서 실제로 돌아가기 시작해야 프로세스라고 부름 스레드란?프로세스 내 작업의 흐름을 지칭스레드 = 프로세스 안에서 실제로 일이 진행되는 흐름 하나프로세스의 상태프로세스는 여러가지 상태 값을 갖음.생성: 프로세스가 막 만들어진 상태. fork, exec 함수를 통해 생성함. 이때 PCB(프로세스의 신상정보 카드 같은 것. 아래에서 후술함)가 하나 발급됨fork() - 부모 프로세스의 주소 공간을 그대로 복사하여 자식 프로세스를 생성하는 ..

첨부파일 API(업로드/다운로드/삭제)는 만들어놨는데, 게시글 기능이랑 따로 놀고 있었다. 게시글을 지워도 파일은 안 지워지고, 글 쓸 때 파일을 붙이려면 API를 두 번 불러야 했다. 좀 이걸 개선해보려고 한다 - 게시글 삭제 시 파일이 안 지워지는 버그files 테이블은 board_id를 ON DELETE CASCADE로 참조하고 있어서, 게시글을 지우면 DB의 files 행은 자동으로 같이 지워진다.근데 이건 DB 얘기고 디스크에 있는 실제 파일은 CASCADE가 손댈 수 없는 영역이다. BoardService.deleteBoard를 보니 boardRepository.deleteBoard(id)만 부르고 끝이었고, 그래서 게시글을 지울 때마다 디스크에 안 쓰는 파일이 계속 쌓이고 있었다. // F..

솔직히 이번 파트가 제일 오래 걸린거 같다쿼리에 익숙하지 않아서인지 한줄 한줄 해석하는데 시간이 오래 걸렸다.요구사항을 보면1. 제목/작성자/내용 텍스트 검색 2. 카테고리 필터 3. 등록일 검색, 디폴트 최근 1년 4. 페이징 (10개씩, 총 건수) 5. 목록에 첨부파일 유무 표시이렇게 되있었다. 동적 SQL을 사용했는데, 조건이 있을 수도 있고 없을수도 있으니, SQL을 상황에 따라 조립해야 했다.//"selectBoardList라는 이름의 SQL이고, 실행 결과 각 행을 BoardEntity 객체에 담아라"는 선언.//board 테이블(별명 b)에서 가져올 컬럼들 나열. BoardEntity의 필드 이름과 매칭돼서 자동으로 채워짐. SELECT b.id, b.category_id, b.title,..

게시판 만들기 요구사항을 보면 서버 측 유효성 검증 조건이 있었다.작성자 3~4자, 비밀번호 4~15자(영문/숫자/특수문자 포함), 제목 4~99자, 내용 4~1999자, 카테고리 필수 어떻게 유효성 검증을하지?Spring이 제공하는 spring-boot-starter-validation을 쓰면, DTO 필드 위에 애노테이션만 붙여서 검증 규칙을 선언할 수 있다.// build.gradleimplementation 'org.springframework.boot:spring-boot-starter-validation'gradle에 넣고 싱크 돌려주면 사용이 가능하다! 어떻게 사용하지?다양한 어노테이션을 지원하는데 대표적으로 @Size, @Pattern, @Min, @Max, @Email 등이 있다 // B..

결국 이번에도 늦어버렸다. 언제쯤이면 바쁘다는 구차한 핑계로 스스로 정당화하지 않을수 있을까..반성 또 반성한다.그치만 바쁜걸 이잉 업로드, 다운로드에 이어 삭제. 파일은 디스크와 DB 두 곳 모두에 흔적이 남아서 삭제도 두 곳 다 지워야 완전하다. 순서가 왜 중요한가?두 작업을 순서대로 실행하다가 중간에 하나가 실패하면 어떻게 될까. 1. 디스크 먼저 지우고 DB가 실패하면 → DB엔 있는데 실물이 없는 "유령 파일" (목록엔 뜨는데 다운로드하면 에러)2. DB 먼저 지우고 디스크가 실패하면 → 실물은 있는데 DB엔 없는 "고아 파일" (아무도 못 찾지만 용량만 차지)둘 다 완벽하진 않은데, 고아 파일 쪽이 낫다고 판단했다. 조용히 방치돼도 사용자는 아무 문제를 못 느끼지만, 유령 파일은 사용자가 클..

HTTP애플리케이션 계층으로서 웹 서비스 통신에 사용HTTP/1.0 부터 발전을 거듭해 현재는 HTTP/3 HTTP/1.0- 한 연결당 하나의 요청을 처리하도록 설계- 서버에서 파일을 가져올 때마다 TCP의 3-way-handshake를 계속 열어야 하므로 RTT가 증가하는 단점이 있음. RTT : 패킷이 목적지에 도달하고 나서 다시 출발지로 돌아오기까지 걸리는 시간. 즉 패킷 왕복 시간 RTT의 증가를 해결하기 위한 방법이미지 스플리팅- 이미지가 합쳐진 하나의 이미지를 다운 이를 기반으로 background-image의 position을 이용하여 이미지를 표기 코드 압축- 코드를 압축해 개행 문자, 빈칸을 없애 코드의 크기를 최소화 하는 방법 이미지 Base64 인코딩- 이미지 파일을 64진법으로 이..

네트워크란?노드와 링크가 서로 연결되어 있으며, 리소스를 공유하는 집합을 의미노드 : 서버, 라우터, 스위치 등 네트워크 장치링크 : 유선 또는 무선 처리량과 지연 시간좋은 네트워크를 구축하는것이 중요좋은 네트워크 : 많은 처리량을 가지고, 지연 시간이 짧고 장애 빈도가 적으며 좋은 보안을 갖춤 처리량 : 링크 내에서 성공적으로 전달된 데이터의 양단위로 bps(초당 전송or수신되는 비트 수) 사용.처리량은 트래픽, 대역폭, 에러, 하드웨어 스펙에 영향을 받음 트래픽 : 링크 내에 '흐르는' 데이터의 양트래픽과 처리량은 다른 개념- 트래픽이 많아졌다 = 흐르는 데이터가 많아졌다.- 처리량이 많아졌다 = 처리되는 트래픽이 많아졌다. 대역폭 : 주어진 시간동안 네트워크 연결을 통해 흐를 수 있는 최대 비트 수..

요구사항에 보면 ' 해당 첨부의 서버 URI 링크가 아닌, 바이너리 다운로드 형태로 구현되어야 함' 이라는 조건이 있다URI 직링크는 왜 안 되나편한 방법은 uploads 폴더를 웹에 노출시키고 http://서버/uploads/uuid_파일명.png으로 직접 접근하게 하는 것이다. 하지만 이러면 저장 폴더 구조와 실제 파일명이 외부에 노출되고, 주소만 알면 누구나 아무 검증 없이 파일을 가져갈 수 있다. 나중에 권한 검사 같은 걸 넣을 자리도 없는게 문제다 그래서 모든 다운로드가 API를 통과하게 만든다. 클라이언트는 파일 id만 알고, 실제 파일 위치는 서버만 안다.클라이언트: GET /api/files/1/download (id만 앎) ① 서버가 DB에서 id=1 조회 → 저장명(UUID),..

이건 글을 쓰기 전에 미리 반성하고 시작한다바쁘다는 핑계로 결국 리액트도 백엔드 API도 제대로 다 구현을 못했다..부끄럽지만 시간 대비 효율이 안나오는 인간인지라 진득하게 의자에 앉아 있는 시간을 늘려도 아직 한참 모자른거 같다. 빠르게 진행해 보겠습니다 게시판에 첨부파일 기능을 붙이기 시작했다..왜 JSON으로는 파일을 못 보낼까?지금까지 만든 API는 전부 요청 본문에 JSON을 실어서 보냈다. 그런데 파일 업로드는 JSON으로 할 수가 없다. JSON은 텍스트 형식이라서, 이미지나 zip 같은 바이너리 데이터를 담을 그릇이 아니기 때문이다.요청 본문(body)은 그냥 "데이터를 싣는 화물칸"일 뿐이고, 거기에 뭘 싣는지는 그때그때 다르다. 뭘 실었는지는 Content-Type 헤더가 알려준다. J..

면접을 준비하면서 느낀건데 CS 지식이 많이 부족한거 같습니다. 그래서 모자른 지식을 채우기 위해 책을 읽고 있는데, 그 내용을 기반으로 정리해 보려고 합니다그 첫 번째 챕터로 '디자인 패턴과 프로그래밍 패러다임'을 선정했습니다.방대한 양의 패턴들을 무작정 외우기보다는 각 패턴이 '어떤 문제를 해결하는가?'에 초점을 맞추어 제가 사용하고있는 자바 언어 기반으로 재해석해 보았습니다 1. 싱글톤(Singleton) 패턴[개념] 애플리케이션 내에서 특정 클래스의 인스턴스가 오직 하나만 생성되도록 보장하고, 이 인스턴스에 접근할 수 있는 전역적인 접촉점을 제공하는 생성 디자인 패턴 [쉬운 풀이] 회사에 있는 '공용 프린터'를 생각해보자. 직원(객체)들이 프린트를 할 때마다 새로운 프린터를 사오는 것이 아니라, ..