소년스튜디오

예제 시나리오를 통해 머신러닝의 일반적인 프로젝트 진행 순서를 훑어본다. 1. 큰 그림을 본다. 2. 데이터를 구한다. 3. 데이터를 탐색하고 시각화 하여 특성을 파악한다. 4. 데이터를 정제한다. 5. 모델을 선택하고 훈련한다. 6. 모델을 튜닝한다. 7. 솔루션을 제시한다. 8. 운영, 유지 그리고 보수. 큰 그림을 본다 문제 정의 목적을 정확히 파악한다. 현재 시스템이 어떻게 구성되어있는지를 파악한다. 문제 유형을 파악한다 : 지도여부는? 알고리즘 유형은? 학습형태는? 성능 측정 지표 선택 RMSE MAE 아니면 다른것? 가정 검사 "내가 내린 가정"이 머신러닝 파이프라인에 어떤 영향을 주고 받을지를 미리 검토해본다. 입력 데이터가 예상과 다르게 들어올 수 도 있고, 출력 데이터를 사용하는 시스템에..

머신러닝의 공학적 정의 어떤 작업 T에 대한 컴퓨터 프로그램의 성능을 P로 측정했을 때 경험 E로 인해 성능이 향상됐다면, 이 컴퓨터 프로그램은 작업 T와 성능 측정P에 대해 경험 E로 학습한 것이다. by Tom Mitchell, 1997 머신러닝을 사용하는 이유 규칙이 동적으로 변할 필요가 있는 문제를 풀때. 전통적인 방식으로는 너무 복잡하거나, 알고리즘이 없는 문제를 해결할때. 대용량 데이터를 분석하여 보이지 않는 규칙을 도출할때. 머신러닝 시스템의 종류 사람의 감독 여부 머신러닝 시스템을 훈련하기 위한 데이터들(훈련 세트)이 주어질때 각 데이터에 정답을 표기한 경우 그 정답을 레이블 이라고 한다. 구분 비지도 학습 준지도 학습 지도학습 강화 학습 레이블 없다 일부 있다 전부 있다 계속 추가한다. ..

버져닝 새 개념은 새 URI로 의미론 적으로 새로운 기능을 제공하는 경우 새 URI 를 사용한다. 의미론 적으로 같다면 URI 가 바뀌어서는 안된다: URI 는 버져닝을 하지 않는다. 요약자 주. 본 서적에서는 URI 로는 버져닝을 하지 말것을 제시하고 있다. 개념적으로 같은 기능에 버져닝이 들어간다는것은 "유일한 식별자" 로서의 제약사항을 위배하기 때문이라 생각된다. 그러나 현재의 RESTful API 는 필수적으로 버져닝을 다루고 있다. URI에 추가 query parameter 로 받기 custom header 컨텐츠 협상 추정컨데, 본 서적은 WRML 기반의 REST API 구현론을 제시하는 책이므로 URI 에서 버져닝을 하는 대신 WRML 스키마를 통해 버져닝을 대신할 수 있다고 판단하기 때문에..

본 챕터는 OINLY WRML 에 관한 내용이므로 스킵한다.

바디 정보 Content-Type 요청 또는 응답의 BODY 데이터 타입을 기술. Content-Length 바디의 크기를 byte 단위로 기술한다. 드물게, utf-8 처리를 제대로 하지 않아 한글을 자소단위로 처리하여 Content-Length 를 잘못 구성하는 라이브러리도 존재 하므로 오류 발생시 이 부분도 고려. Location 새로 생성한 리소스의 URI 를 나타낸다. Content-Location 과는 다르다! 조건부 요청 GET, POST, DELETE 는 리소스에 대한 변경을 수행하며, 서버는 조건부 수행을 지원해야 한다. Last-Modified 리소스의 마지막 변경 시점을 나타낸다. Last-Modified 와 관련하여 아래의 조건식을 사용할 수 있다. If-Unmodified-Sinc..

HTTP 요청 메서드 REST API 리소스 모델에서 각 메소드는 고유한 의미를 가진다. GET - 리소스 상태의 표현 HEAD - 메타데이터 조회 PUT - 새 리소스 생성 또는 갱신 DELETE - 자식 리소스 제거 POST - 새 리소스 생성 또는 컨트롤러 실행 세부 규칙 터널링 금지 터널링이란 원래 의도와 맞지 않게 HTTP 를 사용하는 행위를 뜻한다. GET 리소스의 상태 표현을 조회한다. HEAD 응답 헤더(메타데이터)를 조회한다. 바디가 없다. PUT 리소스 삽입, 갱신 을 위해 사용한다. 변경한 값을 갖는 메시지 바디를 포함할 수 있다. POST 새로운 리소스 생성 시 사용한다. 새 메시지를 나타내는 메시지 바디를 포함할 수 있다. 컨트롤러 리소스를 실행할 수 있다. DELETE 오직 특정..

URI 형태 마지막 슬래시(/) 를 포함하지 않는다. 가독성을 높이기 위해 하이픈(-)을 사용한다. 밑줄(_)은 사용하지 않는다. 소문자를 사용한다. 확장자는 사용하지 않는다. URI 경로 도큐먼트 이름 - 단수 명사. 컬렉션, 스토어 이름 - 복수 명사. 컨트롤러 이름은 동사(구). 변하는 부분은 유일한 값으로 대체. CRUD 는 포함하지 않는다.

웹 아키텍쳐의 제약사항 클라이언트/서버 클라이언트와 서버의 역할을 명백히 분리한다. 균일한 인터페이스 인터페이스는 일관성 있게 분리되어야 한다. 자원 식별 - 요청 자체만으로 대상 자원을 식별할 수 있다 ( ex: uri ). 기술을 통한 자원 처리 - 요청에 포함된 메타데이터를 비롯한 자원에 대한 기술만으로 대상을 충분히 수정하거나 삭제할 수 있다. 자기 서술적 메시지 - 메시지는 자신을 어떻게 처리할 지에 대한 충분한 정보를 제공한다. HATEOAS - 클라이언트의 동작을 위해 별도의 하드코딩이 필요 없으며, 응답 또는 문서 만으로 모든 동작을 기술할 수 있다. 계층 시스템 - 보안, 부하 분산, 응답 속도 개선등의 목적으로 네트워크의 중간 매체를 이용하되, 사용자는 이를 인지하지 못하도록 배치할 수..