fkfkfk9 Learn CODE | Feed

루비로 배우는 객체지향 디자인

Sun, 24 Oct 2021 23:13:33 GMT

루비로 배우는 객체지향 디자인

책 소개

10월에 읽을 책은 루비로 배우는 객체지향 디자인이다. 유튜브 개발바닥 채널에서 추천받은 책이다.
아직 읽어보지 못해서 정확한 내용은 모르지만 객체지향 디자인에 대해 설명되어 있으며 앱을 개발함에 있어 유지보수와 코드를 쉽게 고도화 하기위한 디자인에 대해 루비언어로 쉽게 설명하고 있다고 한다.
기존에도 여러 프레임워크에서 MVC패턴을 이용하여 막연하게 프레임에 정해진대로 소스코드를 넣었는데 이 책을 통해 왜 이런 패턴들이 생긴건지 알 수 있을 것 같아 기대중이다.

그림으로 배우는 Http & Network Basic

Sun, 12 Sep 2021 23:13:33 GMT

책 정보

그림으로 배우는 Http & Network Basic

책 소개

근 1년간 서버 셋팅을 하기도 하고 3년 넘게 웹개발을 하고있는데 네트워크에 대해 이론적으로 너무 모르고 있고 Http같은 경우 꼭 알아야 함에도 최소한의 정보 말고는 잘 모른다는것에 최근 부끄러움을 느낄때가 있었다.
유튜브에서 추천하는 분들이 있었고 책 후기에도 책에대한 칭찬이 많아 바로 구매하게 되었다. 네트워크 관련 내용들은 학교에서도 자격증을 취득하기 위해서도 공부했지만 항상 너무 어려웠는데 그림으로 얼마나 쉽게 설명해줄지 기대된다.

후기

제목만 보면 굉장히 쉬운 책일것 같은데 생각보다 어려웠다. 물론 네트워크나 서버를 다루시는 분들이라면 깊게 다루지 않는 책이 쉬워보일 수 있겠으니 일반적인 사람들은 어려울수도 있겠다고 느꼈다. 게다가 내용들중에 웹 개발자가 몰라도 될 내용까지 전부 다루는 느낌도 있어서 아쉬웠고 또 웹 개발자가 꼭 알아야 하는 부분을 깊게 다루던가 예를 들어 알려줬다면 좋았을 탠대 대상자가 웹 개발자가 아닌 정보통신쪽 전공자들이 아닌가 싶은 느낌이었다.

1. 웹과 네트워크에 대한 기본

HTTP

우리가 URL을 입력하면 해당 URL에 대한 화면이 출력된다. 이처럼 우리는 브라우저(클라이언트)를 통해 서버에 요청을 보내고 서버는 그에대한 응답을 해주는데 이런 클라이언트에서 서버까지 일련의 흐름을 결정하고 있는 것이 웹 HTTP라는 프로토콜이다.
프로토콜이란 약속을 의미하고 웹은 HTTP라는 약속을 사용한 통신으로 이루어져 있습니다.
최초의 인터넷은 자료를 보내기위해 하이퍼텍스트에 의해 상호간에 참조할 수 있는 WWW의 기본개념의 시스템이었다. WWW를 구성하는 기술은 문서기술로 HTML, 문서 전송 프로토콜로 HTTP, 문소의 주소를 지정하는 방법으로 URL 등이 제안되었다. HTTP/1.1은 1997년 1월에 공개되었고 현재 가장 많이 사용되는 버전이다. 이 당시에 주로 텍스트를 전송하기 위한 프로토콜이었지만 프로토콜 자체가 심플해서 여러 가지 응용 방법을 고려해 기능이 계속해서 추가되었다.

TCP/UDP

인터넷을 포함하여 일반적인 인터넷은 TCP/UDP라는 프로토콜에서 움직이고 있기 때문에 HTTP를 이해하기전에 TCP/UDP 프로토콜에 대한 이해를 해야한다.
클라이언트와 서버가 통신을 하기 위해선 서로 같은 방식으로 통신해야 하는데 통신 상대를 찾는 방법, 언떤 언어를 사용할건지 통신을 시작하는 방법과 종료하는 방법 같은 규칙들을 결정해야한다. 이렇게 서로 통신을 하기 위한 규칙들을 프로토콜이라 부른다.
인터넷과 관련된 프로토콜들은 TCP/IP라 부른다.
TCP/IP에서 중요한 개념은 계증인데 애플리케이션 계층, 트랜스포트 계층, 네트워크 계층, 링크 계층 4가지의 계층으로 나뉜다.

애플리케이션 계층 : 유저에게 제공되는 애플리케이션에서 사용하는 통신의 움직임을 결정한다. TCP/IP에는 여러가지의 공통 애플리케이션이 있는데 FTP나 DNS도 포함되고 HTTP또한 이계층에 포함된다.
트랜스 포트 계층 : 애플리케이션 계층에 네트워크로 접속되어 있는 2대의 컴퓨터 사이의 데이터 흐름을 제공한다. 트랜스포트 계층에는 서로다른 성질을 가진 TCP, UDP가 존재한다.
네트워크 계층 : 네트워크 상에서 패킷의 이동을 다룬다. 패킷은 전송하는 데이터의 최소단위를 의미한다. 상대방의 컴퓨터까지 도달하는 동안에 여러 네트워크 장치를 거치게 되는데 이런것을 설정해주는 계층이다.
링크 계층 : 네트워크에 접속하는 하드웨어적인 면을 다룬다.

통신의 흐름 HTTP 클라이언트 -> TCP -> IP -> 네트워크 -> 네트워크 -> IP -> TCP -> HTTP 서버 이런 과정속에 스택처럼 TCP에는 TCP헤더가 IP에는 IP헤더, 네트워크에는 이더넷 헤더가 붙고 서버에서는 반대로 사용된 헤더를 계층을 지나갈때마다 삭제한다. 이렇게 정보를 감싼는 것을 캡슐화라고 한다.

ip : 네트워크 계층에 해당하고 인터넷을 활용하는 대부분의 시스템이 IP를 이용하고 있다. IP는 프로토콜 명이지 IP주소와는 다르다. IP의 역할은 개별적인 패킷을 상대방에게 전달하는 것이다. 이렇게 상대방에게 전달하려면 여러 가지 정보가 필요한데 그 중 IP주소와 MAC주소가 가장 중요하다. IP주소는 각 노드에 주여된 주소를 가르키고 MAC 주소는 각 네트워크 카드에 할당된 고유 주소이다. IP주소는 변경이 가능하지만 MAC주소는 변경이 불가능하다. 송신할 떄 수신할 IP주소를 설정해준다면 이후 ARP프로토콜이 다음 경로의 MAC주소(라우터)를 찾아주고 해당 네트워크 장비로 이동해가면서 수신할 IP주소로 찾아간다. 결국 IP통신은 처음부터 전송할 경로를 알고 있는것이 아니라 대략적인 목적지만 알고 여러 네트워크 장비들을 거쳐 찾아가게 되는데 이런 과정을 라우팅이라고 한다.
TCP : 트랜스포트 계층에 해당한다. 특징으로는 신뢰성 있는 바이트 스트림 서비스를 제공하여 대용량의 데이터를 보내기 쉽게 작은 단위의 패킷으로 분해하여 상대방에게 보내고 정확하게 도착했는지 확인하는 역할을 하고있다. 데이터를 보내주는지 확인하는 과정을 쓰레웨이 핸드셰이킹이라 하는데 SYN, SYN/ACK, ACK 플래그들을 통해 확인하기 때문이다. 이 과정중에 통신이 끊긴다면 재전송한다.
DNS : HTTP와 같은 응용 계층 시스템에서 도메인 이름과 IP 주소 이름 확인을 제공한다. DNS는 도메인명을 IP주소로 조사하거나 IP 주소로 부터 도메인명을 도사하는 역할을 한다.

URL과 URI

우리가 일반적으로 브라우저에서 입력하는 사이트 주소가 URL이다.
URI의 경우 Uniform Resource Identifiers의 약자이다.

Uniform : 통일된 서식을 결정하는 것, 여러 가지 종류의 리소스 지정 방법을 같은 맥락에서 구별없이 취급할 수 있게 한다.
Resource : 리소스는 식별 가능한 모든 것을 의미한다. 도큐먼트 파일뿐 아니라 이미지와 서비스 등 다른 것과 구별할 수 있는 것은 리소스이다.
Identifier : 식별 가능한 것을 참조하는 오브젝트이며 식별자로 불립니다. 결국, URI는 스키마를 나타내는 리소스를 식별하기 위한 식별자 입니다.

HTTP의 경우에는 http를 사용한다. 그 외에도 ftp, mailto, telnet, file 등이 있다.
URI는 리소스를 식별하기 위해 문자열 전반을 나타내는데 비해 URL은 리소스의 장소(네트워크 상의 위치)를 나타내고 URL은 URI의 서브넷이다.

URL포맷

http:와 https:같은 스키마를 사용하여 리소스를 얻기 위해 사용하는 프로토콜을 지시한다.

id:pw를 입력하여 자격정보를 입력할수도 있는데 이것은 옵션이고 실제로 사용해본적이 없다.

완전 수식 형식인 URI에서는 서버 주소를 지정할 필요가 있다. DNS이름 또는 IP주소를 입력해준다.

서버주소를 입력하였다면 뒤에 :를 입력한 후 포트를 입력할 수 있다. 이는 접속 대상이 되는 네트워크 포트 번호를 지정한다. 이것은 옵션으로 생략하면 보통 80포트가 동작한다.

파일의 경로 또는 서버의 컨트롤러에서 동작하는 매핑주소가 입력된다.

쿼리 문자열이 추가 되기도 하는데 ?변수명=값의 형태로 추가해주면 GET방식으로 데이터를 전송할 수 있다.

서브 리소스를 가리키기 위한 프래그먼트 식별자를 사용할 수 있는데 이는 옵션이다.

2. 간단한 프로토콜 HTTP

HTTP는 클라이언트와 서버간의 통신을 한다. HTTP는 클라이언트에서 서버로 리퀘스트를 보내면 그 결과를 서버는 리스폰스 해준다.

리퀘스트 : 서버에 요구하는 종류를 요구하는 메서드(GET,POST)가 포함되고 리소스의 위치인 URI가 포함된다. 또 HTTP의 버전이 포함되며 리퀘스트 헤더 필드와 엔티티가 포함된다.
리스폰스 : 리스폰스 또한 HTTP의 버전을 포함하고 있고 해당 요청에 대한 처리결과를 상태 코드와 상태코드에 대한 설명을 포함하고 있다. 또 리스폰스 헤더 필드와 바디로 구성되어있다.

HTTP는 상태를 저장하지 않기 때문에 사용자의 로그인 정보 같은것은 페이지마다 저장하여 넘길 수 없다. 때문에 세션이나 쿠키를 사용하여 정보를 저장해준다.

HTTP 메서드

GET : GET 메서드는 리퀘스트 URI로 식별된 리소스를 가져올 수 있도록 요구합니다. 개발에서 GET은 전송될 데이터가 노출되는 단점이 있지만 URI에 붙여서 보내는 편리함이 있어 노출해도 되는 데이터를 전송한다면 사용된다.
POST : POST 메서드는 엔티티를 전송하기 위해서 사용된다. 주로 회원가입, 로그인 같이 보호되야할 데이터가 있을 경우 사용된다.
PUT : PUT 메서드는 파일을 전송하기 위해 사용된다. 다만 PUT 자체에 인증 기능이 없어 누구든지 업로드가 가능하다는 보안 상의 문제가 있어 일반적으로 사용되지 않는다.
HEAD : HEAD 메서드는 GET과 같은 기능을 가지고 있지만 메시지 바디는 돌려주지 않는다. URI의 유효성이나 리소스의 갱신 시간을 체크하는 용도로 사용된다.
DELETE : DELETE메서드는 파일을 삭제하기 위해 사용된다. PUT과 같은 이유로 일반적으로는 사용되지 않으나 REST와 같이 사용되기도 한다.
OPTION : OPTIONS 메서드는 리퀘스트 URI로 지정한 리소스가 제공하고 있는 메서드를 조사하기 위해 사용된다.
TRACE : TRACE 메서드는 웹서버에 접속해서 자신에게 통신을 되돌려 받는 루프백을 발생시킨다. 이것은 프록시 등을 중계하여 오리진 서버에 접속할 때 그 동작을 확인하기 위해서 사용되는데 거의 사용되지 않는다.
CONNECT : TCP 통신을 터널링 시키기 위해서 사용된다. 주로 SSL이랑 TLS 등의 프로토콜로 암호화된 것을 터널링 시키기 위해서 사용된다.

HTTP의 지속적 연결

초기 HTTP는 접속할 때마다 TCP연결을 하였다. 이는 초창기에 HTTP로 주고받는게 대부분 텍스트였기 때문인데 웹이 발전함에 따라 이미지들이 다수 포함되면서 쓸대없이 통신량이 늘어나기 시작했다.
이런 문제를 해결하기 위해 HTTP 1.0버전 이후 지속연결을 지원하여 한쪽에서 연결을 종료시키지 않는 이상 TCP연결을 지속시키도록 변경되었다. 지속연결은 여러 리퀘스트를 보낼 수 있도록 파이프라인화를 가능하게 하여 리스폰스가 끝나지 않아도 리퀘스트를 여러번 보낼 수 있도록 할 수 있다.
지속연결이 가능하다고 해도 이전 연결에 대한 정보는 가져올 수 없어 매번 다시 접속해주어야 하는데 이를 해결하기 위해 쿠키를 사용할 수 있다. 쿠키는 클라이언트쪽에 저장되어 리퀘스트에 기존의 정보를 보내준다.

3. HTTP 정보는 HTTP 메시지에 있다

HTTP에서 교환하는 정보를 HTTP 메시지라고 부른다. 리퀘스트시에는 리퀘스트 메시지 리스폰스 할때는 리스폰스 메시지이다.
HTTP 메시지는 복수 행의 데이터로 구성된 텍스트 문자열이다. 또 메시지는 메시지 헤더와 메시지 바디로 구성되어있다. 처음으로 나오는 개행문자(CR+LF)로 둘을 구분할 수 있다.

메시지 헤더 : 서버와 클라이언트가 꼭 처리해야 하는 리퀘스트와 리스폰스 내용과 속성

메시지 바디 : 꼭 전송되는 데이터 그 자체

메시지 헤더 구조

리퀘스트 라인(리퀘스트) : 리퀘스트에 사용하는 메서드와 리퀘스트 URI와 사용하는 HTTP버전이 포함
상태 라인(리스폰스) : 리스폰스 결과를 나타내는 상태코드와 상태코드에 대한 설명, HTTP 버전이 포함
헤더필드 : 리퀘스트와 리스폰스의 여러 조건과 속성등을 나타내는 각종 헤더 필드 포함(일반 헤더 필드, 리퀘스트 헤더 필드, 리스폰스 헤더 필드, 엔티티 헤더 필드)

인코딩

HTTP로 데이터를 전송할 경우 그대로 전송하는것도 가능하지만 인코딩을 함으로써 효율을 높일 수 있다.

메시지 : HTTP 통신의 기본 단위로 옥텟 시퀀스로 구성되고 통신을 통해서 전송된다.
엔티티 : 리퀘스트랑 리스폰스의 페이로드로 전송되는 정보로 엔티티 헤더 필드와 엔티티 바디로 구성된다.

HTTP 메시지 바디의 역할은 리퀘스트랑 리스폰스에 관한 엔티티 바디를 운반하는 일인데 기본적으로 메시디 바디와 엔티티 바디가 같지만 전송 코딩이 적용되면 엔티티 바디의 내용이 변화한다.

콘텐츠 코딩 : 엔티티에 적용하는 인코딩을 가리킨다. 엔티티 정보를 유지한 채로 압축
청크 전송 코딩 : 사이즈가 큰 데이터를 전송하는 경우에 데이터를 분할해서 조금씩 표시할 수 있는데 이런 엔티티 바디를 분할하는 기능을 청크 전송 코딩이라고 부른다.

여러 데이터를 보내는 멀티파트

HTTP는 멀티파트에 대응하고 있어 하나의 메시디 바디 내부에 엔티티를 여러 개 포함시켜 보낼 수 있다. 주로 이미지나 문서 등을 업로드할 때 사용되고 있다.

mulitpart/form-datya : Web form으로부터 파일 업로드에 사용된다.
multipart/byteranges : 상태 코드 206 리스폰스 메시지가 복수 범위의 내용을 포함하는 때에 사용된다.

4. HTTP 상태 코드

상태 코드 클래스

1xx(Informational) : 리퀘스트를 받아들여 처리 중

2xx(Success) : 리퀘스트를 정상적으로 처리

3xx(Redirection) : 리퀘스트를 완료 하기 위한 추가 작업 필요.

4xx(Client Error) : 서버는 리퀘스트 이해 불가

5xx(Server Error) : 서버는 리퀘스트 처리 실패

200 : 성공
204 : 성공했으나 해당 리소스가 없는 상태
206 : 범위가 지정된 리퀘스트에 일부만 반환
301 : 해당 리소스에 새로운 URI가 부여되어 URI를 업데이트하라는 코드
302 : 301과 같지만 해당 리소스가 임시로 이동한 상태
303 : 302와 같지만 GET 메소드를 얻어야한다고 명시해줌
304 : 리소스에 대한 엑세스는 허락하지만 조건이 충족되지 않음
307 : 302와 같지만 POST에서 GET으로 치환하지 않는다.
400 : 리퀘스트 구문 에러
401 : HTTP 인증정보가 필요.
403 : 리소스에 대한 엑세스 거부
404 : 해당 리소스가 서버에 없음
500 : 서버에서 리퀘스트 처리 중 에러
503 : 서버가 과부하 중이거나 점검중

5. HTTP와 연계하는 웹 서버

HTTP/1.1 에서는 하나의 HTTP 서버에 여러 개의 웹 사이트를 실행할 수 있도록 가상 호스트 기능을 사용하고 있다.

HTTP는 클라이언트와 서버 이외에 프록시, 게이트웨이, 터널과 같은 통신을 중계하는 프로그램과 서버를 연계하는것도 가능하다.

프록시

서버와 클라이언트의 양쪽 역할을 한다. 클라이언트로부터 리퀘스트를 서버에 전공, 서버로부터 리스폰스를 클라이언트에 전송한다.

캐싱 프록시 : 프록시로 리스폰스를 중계하는 때에 프록시 서버 상에 리소스 캐시를 보존하여 다시 같은 리소스를 요청할 때 서버가 아닌 캐시를 리턴해준다.
투명 프록시 : 리퀘스트와 리스폰스를 중계할 때 메시지 변경을 하지 않는다. 반대로 비투과 프록시가 있다.

게이트웨이

다른 서버를 중계하는 서버, 클라이언트로부터 수신한 리퀘스트를 리소스를 보유한 서버인 것처럼 수신한다. 클라이언트는 상대가 게이트웨이라는걸 알지 못하는 경우도 있다. 프록시와 유사하지만 HTTP 서버가 아닌 서버와 통신한다. 주로 결제, DB 쿼리호출에 사용된다.

터널

서로 떨어진 두대의 클라이언트와 서버 사이를 중계하며 접속을 주선하는 중계 프로그램, 다른 서버와의 통신 경로를 확립한다. SSL 같은 암호화 통신을 통해 서버와 안전하게 통신을 하기 위해 사용된다.

6. HTTP 헤더

메시지 헤더는 클라이언트나 서버 처리에 필요한 중요 정보가 들어있고 메시지 바디에는 사용자와 리소스를 필요로 하는 정보가 있다.

HTTP 헤더 필드

HTTP 헤더 필드는 메시지 바디의 크기나 사용중인 언어, 인증 정보 등을 브라우저나 서버에 전달한다.
구조는 헤더 필드 명 : 필드 값 으로 구성되어 있다. 하나의 필드 명이 여러개의 필드 값을 가질 수 있는데 ,로 구분한다.

Connection 헤더 필드

Connection 헤더 필드는 두가지 역할을 한다.

프록시에 더 이상 전송하지 않는 헤더 필드를 저장
지속적 접속 관리

Date

Date 헤더 필드는 HTTP 메시지를 생성한 날짜를 나타낸다.

Trailer

메시지 바디의 뒤에 기술되어 있는 헤더 필드를 미리 전달할 수 있다. 청크 전송 인코딩을 사용하고 있는 경우에 사용 가능하다.

Transfer-Encoding

메시지 바디의 전송 코딩 형식을 지정하는 경우 사용

Upgrade

HTTP 및 다른 프로토콜의 새로운 버전이 통신에 이용되는 경우 사용

Via

클라이언트와 서버 간의 리퀘스트 혹은 리스폰스 메시지의 경로를 알기 위해서 사용된다. Via 헤더 필드는 전송된 메시지의 추적과 리퀘스트 루프의 회피 등에서 사용되기 때문에 프록시를 경우하는 경우 반드시 부가해야한다.

Warning

리스폰스에 관한 추가 정보를 전달하는데 그 내용은 기본적으로 캐시에 관한 경고를 전달해준다.

리퀘스트 헤더 필드

클라이언트 -> 서버 송신된 리퀘스트 메시지에 사용되는 헤더로 리퀘스트의 부가 정보, 클아이언트의 정보, 리스폰스 콘텐츠에 관한 우선순위가 포함된다.

Accept : 유저 에이전트에 처리할 수 있는 미디어 타입과 미디어 타입의 상대적인 우선 순위를 전달하기 위해서 사용
Accept-Charset : 유저 에이전트에서 처리할 수 있는 문자셋으로, 문자셋의 상대적인 우선 순위를 전달하기 위해서 사용
Accept-Encoding : 유저 에이전트가 처리할 수 있는 콘텐츠 코딩과 콘텐츠 코딩의 상대적인 우선 순위를 전달하기 위해서 사용
Accept-Language : 유저 에이전트가 처리할 수 있는 자연어의 세트와 자연어 세트의 상대적인 우선순위를 전달하기 위해 사용 Authorization : 유저 에이전트의 인증정보(크리덴셜 값)을 전달하기 위해서 사용된다.
Expect : 클라이언트가 서버에 특정 동작 요구를 전달, 서버가 응답하지 못할 경우 상태코드 417코드를 반환
From : 유저 에이턴트를 사용하고 있는 유저의 메일 주소를 전달
Host : 리퀘스트한 리소스의 인터넷 호스트와 포트 번호를 전달한다. HTTP/1.1에서 유일한 필수 헤더 필드이다. 이는 하나의 IP에 복수 도메인이 적용되어 있을때 이를 체크하기 위한 호스트명을 넣어준다.
if-xxx : 조건부 리퀘스트로 if-뒤에 붙는 종류에 따라 지정된 조건에 맞는 경우에만 리퀘스트를 받는다.
Max-Forwards : 리퀘스트를 할 때에 전송해도 좋은 서버 수의 최대치를 10진수로 지정할 수 있다. 서버를 지나갈때마다 1씩 빼서 0이되면 리스폰스해준다.
Proxy-Authorization : 프록시 서버에서의 인증 요구를 받아들인 때에 인증에 필요한 클라이언트 정보를 전달한다.
Range : 리소스의 일부분만 취득하는 Range 리퀘스트를 할 때 지정 범위를 전달한다. 리퀘스트를 처리 할 수 있는 경우 상태코드 206을 반환하고 처리할 수 없다면 200을 반환한다.
Referer : 리퀘스트가 발생한 본래 리소스의 URI를 전달한다. 기본적으로 Referer 헤더 필드는 전송되어야 하지만 브라우저 주소창에 직접 입력하거나 보안상 바람직하지 않다고 판단하면 보내지 않아도 된다. 리소스 URI 쿼리에 ID와 PW가 들어있다면 Referer을 통해 다른 서버에 누설 될 수 있다.
TE : 리스폰스로 받을 수 있는 전송 코딩의 형식과 상대적인 우선순위를 전달합니다.
User-Agent : 리퀘스트를 생성한 브라우저와 유저 에이전트의 이름 등을 전달하기 위한 필드

리스폰스 헤더 필드

서버 측으로부터 클라이언트 측으로 송신되는 리스폰스 메시지에 적용된 헤더

Accept-Ranges : 서버가 리소스의 일부분만 지정해서 취득할 수 있는 Range 리퀘스트를 접수할 수 있는지 여부를 전달
Age : 얼마나 오래 전에 오리진 서버에서 리스폰스가 생성되었는지를 전달한다. 필드 값의 단위는 초이다.
ETag : 엔티티 태그라고도 불리며 임의적으로 리소스를 특정하기 위한 문자열을 전달한다. 서버는 리소스마다 ETag 값을 할당한다.
Location : 리스폰스의 수신자에 대해서 Request-URI 이외의 리소스 엑세스를 유도하는 경우에 사용
Proxy-Authenticate : 프록시 서버에서의 인증 요구를 클라이언트에 전달
Retry-After : 클라이언트가 일정 시간 후에 리퀘스트를 다시 시행해야 하는지를 전달합니다.
Server : 서버에 설치되어 있는 HTTP 서버의 소프트웨어를 전달
Vary : 캐시를 컨트롤하기 위해 사용, 오리진 서버가 프록시 서버에 로컬 캐시를 사용하는 방법에 대한 지시를 전달한다.
WWW-Authenticate : HTTP 엑세스 인증에 사용, Request-URI에 지정했던 리소스에 적용할 수 있는 인증 스키마와 파라미터를 나타내는 challenge를 전달

엔티티 헤더 필드

Allow : Request-URI에 지정된 리소스가 제공하는 메소드의 일람을 전달, 서버가 받을 수 없는 메소드를 호출한 경우 405코드와 함께 수신 가능한 메소드들을 기록한 Allow 헤더 필드를 반환한다.
Content-Encoding : 서버가 엔티티 바디에 대해서 실시한 콘텐츠 코딩 형식을 전달
Content-Language : 엔티티 바디에 사용된 자연어를 전달
Content-Length : 엔티티 바디의 크기를 전달한다.
Content-Location : 메시지 바디에 대응하는 URI를 전달, 메시지 바디로 반환된 리소스의 URI를 나타낸다.
Content-MD5 : 메시지 바디가 변경되지 않고 도착했는지 확인하기 위해 MD5 알고리즘에 의해서 생성된 값을 전달한다.
Content-Range : 범위를 지정해서 일부분만을 리퀘스트하는 Range 리퀘스트에 대해서 리스폰스를 할 때에 사용된다.
Content-Type : 엔티티 바디에 포함되는 오브젝트의 미디어 타입을 전달, Charset 파라미터는 문자셋을 지정한다.
Expires : 리소스의 유효 기한 날짜를 전달
Last-Modified : 리소스가 마지막으로 갱신되었던 날짜 정보를 전달

쿠키를 위한 헤더필드

쿠키는 유저 식별과 상태 관리에 사용되고 있는 기능이다. 유저의 컴퓨터 상에 일시적으로 데이터를 기록하고 서버에 엑세스하 해 왔을 때 쿠키를 송신한다. 쿠키가 호출될때는 유효 기한과 송신지의 도메인, 경로, 프로토콜 등을 체크하기 때문에 도난당하는일은 없다.

Set-Cookie : 서버가 클라이언트에 대해 상태관리를 시작할 때 다양한 정보를 전달한다. Expires를 통해 유효 기한을 조정할 수 있고 domian속성을 통해 호출될 도메인을 설정할 수 있다.(뒤가같은 도메인에 넘겨줄 수 있어 위험) Secure 속성을 사용하여 HTTPS에서만 호출할 수 있도록 할 수 있다. HTTPOnly속성을 통해 JS를 경유해서 쿠키를 취득하지 못하도록 할 수 있다.
Cookie : HTTP의 상태 관리 지원을 원할 때 서버로부터 수신한 쿠키를 이후에 리퀘스트에 포함하여 전달

그 외 헤더 필드

X-Frame-Option, X-XSS-Protection, DNT, P3P

7. HTTPS

HTTP의 단점

암호화 하지 않았기 때문에 도청의 위험이 있다

HTTP를 사용한 리퀘스트나 리스폰스 통신에는 암호화 하는 기능이 없다. 이는 TCP/IP 구조의 통신은 통신 경로의 도중에 엿볼 수 있기 때문에 매우 위험하다. 클라이언트와 서버가 통신을 할때 다이렉트로 연결되지 않고 여러 통신경로를 거치기 때문에 중간에 가로챌수도 있고 네트워크상에서 패킷을 수집하여 가로챌수도 있다.
이런 위험을 방지하고자 HTTP 프로토콜에 SSL이나 TLS 프로토콜을 조합함으로써 통신내용을 암호화 할 수 있는데 이를 HTTPS라고 부른다.
이 외에도 HTTP 환경에서 서버에서 컨텐츠를 암호화 하고 클라이언트에서 복호화하는 방법이 있는데 일반적으로는 사용되기 어렵다.

통신 상대를 확인하지 않기 때문에 위장 가능

HTTP를 사용할 경우 리퀘스트가 도달하는 서버가 고객이 진짜 원했던 서버인지 리스폰스가 도달해야하는 곳이 진짜 클라이언트가 있는곳인지 확인할 수 없다. 즉 서버와 클라이언트를 속임으로써 다른곳으로 보내질 수 있는 위험이 있다. 이 또한 SSL에서 지원하는 인증서 기능으로 상대를 확인할 수 있다.

완전성을 증명할 수 없기 때문에 변조가 가능

리퀘스트하여 서버로 가는 데이터나 리스폰스 되어 클라이언트로 돌아가는 데이터를 중간에 누군가 가로체어 변조를 한 후 원래 경로로 전달했을 때 검증을 할 방법이 없다. 아직까지 이를 해결할 완벽한 방법은 존재하지 않고 해시값을 사용하여 검증하거나 디지털 서명을 하는 방식을 활용하여 결제같은 주요 기능에만 변조를 막는 방법이 있다.

HTTPS

SSL을 덮어쓴 HTTP

HTTPS는 HTTP에서 통신을 하는 소켓 부분을 SSL이나 TLS 프로토콜로 대체하고 있다.
보통 HTTP는 TCP와 직접 통신을 하지만 HTTPS의 경우 HTTP가 SSL과 통신을 하고 SSL이 TCP와 통신을 하게된다.

공개키 암호화 방식

통신을 할 때 하나의 키로 관리 된다면 위험성이 높겠지만 HTTPS는 공개키, 비밀키 페어로 관리되며 공개키를 보내 암호화를 하고 그 암호화된 데이터를 복호화하는 방법인 비밀키는 보내지 않음으로써 돌아오지 않는 데이터는 복호화가 불가능해 안전하다.

증명서

공개키, 비밀키 페어의 방식에도 문제가 있는데 애초에 전달하는 공개키에 변조가 있을 경우이다. 이를 방지하고자 제 3의 기관에 인증을 받고 해당 공개키에 디지털 서명을 하여 클라이언트가 해당 공개키가 인증서를 받은 증명된 공개키라는 것을 확인할 수 있다.

단점

HTTPS를 사용할 경우 HTTP에 비하여 2배에서 100배까지 느릴 수 있다. 리퀘스트와 리스폰스 외에 SSL과 통신을 추가하였기 때문에 통신의 과정에서 지연이 되고 데이터를 암호화와 복호화 하기 때문에 그만큼 CPU와 메모리의 리소스를 사용하게 되어 짧은시간에 여러번 엑세스하는 작업을 할 경우 매우 효율이 떨어질 수 있다.
또 증명서가 필요하기 때문에 신뢰성 있는 기관의 증명서가 필요한데 추가적인 비용이 발생한다.

8. 누가 액세스하고 있는지 확인하는 인증

인증

클라이언트가 서버에 본인이 누구한태 알려줄 때 이름만 밝힌다면 조작된 데이터인지 알 수 없다. 이런 정보를 확인하기 위해 사용되는것이 password, 토큰, 전자 증명서, 생체인식(지문,얼굴,홍체), IC카드 등이 있다.

HTTP에서 사용하는 인증 방법

BASIC : 인증에 필요한 리소스에 리퀘스트가 있을 경우 서버가 상태코드 401코드를 리스폰스해주고 클라이언트는 인증 정보를 Base64로 전송하는 방식으로 이는 암호화가 아니어서 안전하지 않아 거의 사용하지 않는다.
DIGEST : BASIC의 약점을 보완한 방식으로 챌린지 리스폰스 방식으로 상대방이 보낸 챌린지 코드를 사용하여 리스폰스를 계산한다. 하지만 이 역시 HTTPS에 비해 부족하며 위장을 방지할 수 없기 때문에 거의 사용되지 않는다.
SSL 인증 : 앞에 단원에서 설명한 방식으로 안전하나 리소스를 많이 이용하고 비용이 발생한다.
폼 베이스 인증 : HTTP에 등록되어진 방법이 아닌 서버에서 만들어진 로직대로 정보를 등록하여 인증하는 방식으로 가장 일반적이다.(회원가입, 로그인 방식)

9. HTTP에 기능을 추가한 프로토콜

HTTP 프로토콜은 오래 되었기 때문에 제한이나 한계가 있다. 특히 최근에는 SNS같은 수많은 접속자가 수많은 데이터를 올리고 받아오는 작업들을 HTTP만으로는 빠르게 처리할 수 없다.
병목현상이 생기는 이유

1개의 커넥션에 1개의 리퀘스트만 가능
리퀘스트는 클라이언트가 이벤트를 해야 가능하다.
리퀘스트/리스폰스에서 메시지는 압축되지 않아 많은 데이터를 전송하는데 효율적이지 못하다.
헤더에 들어가는 필드들이 너무 많다.

AJAX

javascript를 이용하여 웹 페이지의 일부분만 사용하는 비동기 통신방식이다. 일부부만 갱신되어 기존의 동기식 통신에 비해 전송되느 데이터를 줄일 수 있다.

Comet

서버측에서 콘텐츠의 변경이 있을 경우 클라이언트의 리퀘스트를 기다리지 않고 전송한다. 실시간 갱신은 가능하지만 커넥션을 유지하는 시간이 길어져 리소스를 소비한다.

SPDY

구글이 발표한 기술로 병목현상의 개선을 프로토콜 레벨에서 해결하기 위한 개발중인 프로토콜이다. 트랜스포트 계층과 TCP/IP 계층 사이에 세션 계층을 추가하는 형태로 동작한다. 기존에 HTTP만 사용할때보다 장점은 HTTP 리퀘스트를 무제한으로 처리하기 때문에 한번의 접속으로 효율이 높다. 또한 이렇게 무제한으로 오는 리퀘스트에 우선순위를 할당할 수 있어 중요한 리퀘스트부터 처리가 가능하다. 또 무제한 처리를 할 경우 헤더의 용량이 커 부하가 갈 수 있는데 압축을 지원한다.
이 외에도 서버가 클라이언트에게 리퀘스트를 받지 않고 푸시해주는 기능과 리퀘스트할 리소스를 제안하는 기능도 추가된다.

WebSocket

서버와 클라이언트가 한번 접속을 하면 그 뒤의 통신은 모두 전용 프로토콜로 하는 방식이다. 접속을 유지하기 때문에 서버에서 클라이언트로 먼저 요청할 수 있고 자주 접속을 시도하는 오버헤드를 줄일 수 있다.

10. 웹 콘텐츠에서 사용하는 기술

HTML

웹 상에서 하이퍼텍스트를 보내기 위해서 개발된 언어, 2014년 HTML5가 발표되었다. 브라우저 별로 버전이 달라 규격이 통일되지 않은 문제가 있다.

CSS

HTML 요소들을 어떻게 표시할지 지시하는 것으로 스타일 시트라고 불린다.

Javascript

웹 페이지를 동적으로 변경해준다. DOM을 사용하여 HTML내의 요소를 오브젝트로 다룬다.

웹 어플리케이션

CGI는 웹 서버가 리퀘스트를 프로그램에 전달하기 위한 구조로 CGI를 사용하는 프로그램으로는 PHP, Ruby 등이 있다. 서블릿은 서버 상에 HTML 등의 동적 컨텐츠를 생성하기 위한 프로그램인데 Java에서 사용한다.

데이터 송수신용 언어

XML은 목적에 맞게 확장 가능한 범용적인 마크업 언어이다. HTML과 비슷하지만 Tag를 사용자가 커스트마이징하여 사용한다. RSS/Atom은 블로그나 뉴스의 갱신 정보를 송신하기 위한 문서 포맷의 총칭으로 XML을 사용한다.
JSON은 Javascript의 Object로 단순한 형태로 되어있기 때문에 가볍게 빠르게 보낼 수 있고 브라우저에서 쉽게 작업할 수 있다.

11. 웹 공격 기술

HTTP는 보안 상의 문제가 일어날 정도로 복잡한 프로토콜이 아니기 때문에 공격 대상이 되는 경우는 거의 없다. HTTP를 사용하는 서버와 클라이언트 그리고 서버 상에서 동작하는 APP이나 리소스 등이 공격받는다.
HTTP에는 보안 기능이 없기 때문에 웹 애플리케이션에서 개발자가 설계하고 구현해야 한다. 이런 공격의 경우 리퀘스트를 통해 실행되며 특정 데이터를 빼가거나 권한 자체를 뺏는 일들이 발생할 수 있다.

서버를 노리는 능동적 공격

공격자가 직접 웹 APP에 엑세스하여 공격 코드를 보내는 타입의 공격이다. 대표적으로 SQL 인젝션과 OS 커맨드 인젝션이 있다.

유저를 노리는 수동적 공격

유저를 함정으로 유도하는 방법으로 공격자는 함정을 만들고 유저가 해당 함정에 리퀘스트하도록 유인한다. 이후 리퀘스트를 할 경우 공격코드를 통해 유저의 데이터에 접근하거나 권한을 뺏어온다. 대표적으로 크로스 사이트 스크립팅과 크로스 사이트 리퀘스트 포저리 등이 있다.

백엔드에서 유효성 체크

JS를 이용한 프런트엔드에서의 체크는 사용자에게 실수를 지적해주는 정도로 사용해야 하고 백엔드 단에서 체크를 해주어야 한다. 이는 공격자가 프런트단을 통하지 않고 바로 리퀘스트로 공격할 수도 있기 때문이다.

크로스 사이트 스크립팅

XSS는 취약성이 있는 웹 사이트를 방문한 사용자의 브라우저에서 부정한 HTML 태그나 JS 등을 동작시키는 공격입니다. 동적으로 HTML을 생성하는 부분에서 취약성이 발생할 수 있다. 이는 공격자가 작성한 스크립트가 함정이 되고 유저가 브라우저 상에서 움직이는 수동적 공격이다.

가짜 입력폼에 의해 개인정보를 가져간다.
스크립트에 의해 쿠키 값을 가져간다.

SQL 인젝션

웹 APP을 이용하고 있는 DB에 SQL을 부정하게 실행하는 공격으로 개인 정보나 기밀 정보가 누설될 수 있다. 만약 SQL의 호출 방법에 미비가 있을 경우 의도하지 않는 SQL문이 삽입될 수 있다.

DB내의 데이터를 열람하거나 변조
인증 회피
DB 서버를 경유한 프로그램 실행

AOP, Filter, Interceptor의 차이

Sat, 21 Aug 2021 23:13:33 GMT

AOP, Filter, Interceptor의 차이점

앨리스터 코오번의 유스케이스

Sat, 21 Aug 2021 23:13:33 GMT

책 정보

앨리스터 코오번의 유스케이스

책 소개

작년부터 프로젝트 관리부분 문서 작성 부분의 일이 꾸준히 늘고 있는데 잘 알지도 못하는 유스케이스를 다른 문서들을 보면서 어떻게 따라하면서도 스스로 납득이 가지 않는 문서를 보며 이걸로 고객 또는 팀과 공유하며 업무 프로세스를 이해하기는 힘들다는 걸 느꼇다.
비슷한 책을 구매하긶 했지만 대부분 UML에 대한 설명은 매우 길어도 그 UML안에 유스케이스의 경우 정말 조금 다루기 때문에 정확하게 유스케이스를 어떻게 그려야하는지 항상 난감했다.
그래서 이번 8월달에 공부하고 싶은내용은 유스케이스 작성법이다. 이 책은 오로지 유스케이스 작성에 대한 내용만을 담았기 때문에 그동안 여러번 유스케이스를 작성하면서도 단순히 순서도 개념으로만 작성하는게 아닌 제대로 된 문서 작성법을 배우게 되지 않을까 기대감을 가지고 있다.

유스케이스?

유스케이스는 이해관계자와 시스템 간의 행위와 관련된 계약 내용을 담고 있다. 유스케이스는 일차 액터라 불리는 이해관계자의 요청에 응답을 하는 시스템을 서술하는데, 요청과 응답 행위는 다양한 조건 아래서 이루어진다. 일차 액터는 어떤 목표를 달성하기 위해 시스템과 상호작용을 시작한다. 시스템은 응답하되, 모든 이해관계자의 입장을 고려한다. 서로 다른 일련의 행위, 또는 시나리오는 특정 요청이나 그 요청을 둘러싼 조건에 따라 전개할 수 있다. 유스케이스는 서로 다른 여러 시나리오의 묶음이다.
이런 유스케이스를 작성하는 이유는 해당 프로젝트에 관련된 모든 이해관계자들간의 의사교환 수단이라는 것이다. 실무자부터 개발자, 관리자들까지 모든 사람들은 이 문서로 해당 시스템이 어떻게 구축할 지 이해할 수 있고 중간에 개발자든 담당자가든 변화가 있더라도 해당 문서를 통해 개발 범위에 대해 이해할 수 있다.

1장 소개

1.1 유스케이스는 어떻게 생겼나?

유스케이스는 플로차트나 시퀀스 차트, 페트리 네트, 프로그래밍 언어 등으로 작성할 수 있지만, 근본적으로 문장 형태다. 보통의 경우 개발자가 아닌 사람들도 같이 보고 의소소통 수단으로 사용하는 문서이기 때문에 단순한 문장으로 쓰는것이 가장 좋은 방법이다.
유스케이스는 사용하는 팀에 따라 요구사항을 정의하는 목적으로, 최종 설계를 위한 문서로 사용하기도 한다. 이렇게 유스케이스는 프로젝트의 규모나 단위에 다라 다르게 작성될 수 있다.
소프트웨어 개발에 필요한 요구사항을 유스케이스로 기록할 때, 목표 시스템은 바로 컴퓨터 프로그램이다. 즉 나는 개발할 웹 사이트이다. 이해관계자는 사이트를 이용하는 사용자, 관리하는 기관, 연계되는 시스템 등이다.일차액터는 사이트에 접속하는 사용자나 연계되는 시스템이다.
유스케이스를 작성할 때 유스케이스 전체에 적용되는 세 가지 개념을 완전히 이해해야 한다. 이 세가지 개념은 범위(무엇이 진짜 목표 시스템인가, 일차 액터(누구의 목표인가), 수준(그 목표 수준이 얼마나 높은가)이다.
책에는 실제 유스케이스의 예들이 들어있으니 궁금하면 책을 읽어보는게 좋다.

1.2 상황에 따라 사용하는 유스케이스가 다르다.

유스케이스는 다양한 케이스가 존재한다.

비지니스 프로세스 서술
목표 시스템 요구사항에 대한 논의
시스템의 기능 요구사항 서술
시스템 설계
소규모 단위 그룹이나 대규모 분산 그룹에서 작성하는 간결한 양식

유스케이스는 이렇게 다양한 상황을 모두 커버할 수 있는 문서라는 장점도 있지만 그만큼 어떤 유스케이스를 작성할지에 대한 고민을 작성자에게 안겨준다.

1.3 요구사항과 유스케이스

요구사항 식별을 목적으로 유스케이스를 작성한다면 두가지가 중요하다.

유스케이스는 그 자체가 요구사항이다. 이것을 행위 요구사항 형태로 변환할 필요는 없다. 제대로 작성하였다면 시스템의 행위를 정확하고 상세하게 표현한다.
유스케이스는 요구사항의 전부가 될 수 없다. 외부 인터페이스, 데이터 포맷, 비지니스 규칙, 복잡한 공식들을 다루지 않는다. 유스케이스는 요구사항의 한 부분이지 전체가 아니라는걸 기억해야한다.

유스케이스가 전체가 아닌 한 부분임에도 프로젝트의 핵심인 이유는 유스케이스 밖의 요구사항들은 유스케이스로 연결되기 때문이다.

1.4 유스케이스가 가치를 발하는 시점

유스케이스가 가장 가치를 발하는 첫 번째 순간은 시스템이 지원할 사용자 목표에 유스케이스 이름을 붙이고 목록을 작성할 때다. 이 목록은 시스템이 해야 할일과 시스템의 범위, 목적을 나타낸다. 이 목록을 통해 이해관계자 간의 의사교환을 할 수있다. 주요 내용은 어떤 기능을 먼저 구현하고 어떻게 팀을 구성할지에 대한 협상을 한다. 이 목록은 복잡성, 비용, 시간, 상태에 대한 측정을 부가하기 위한 프레임워크이다.
두 번째는 작성자가 성공 시나리오에서 잘못될 수 있는 모든 경우에 대해 브레인스토밍 하며, 그 결과를 나열하고, 시스템 응답을 문서로 작성할 때이다. 이를 통해 고객이나 개발자가 생각도 못했던 것들을 발견할 수 있다. 더 이상 실패조건이 나올 수 없을때까지 계속 찾다보면 새로운 이해관계자, 시스템, 목표, 비지니스 규칙을 발견할 수 있다.

1.5 에너지 관리

유스케이스 작성에 필요한 에너지를, 요구되는 에너지의 양과 각 단계 후 가지는 휴식의 가치에 따라 네 단계 정밀도로 구분해 보았다.

시스템에 지원할 액터와 목표를 나열한다. 팀과 릴리스별로 목표를 할당하고 우선순위를 정한다.
유스케이스에 대해 주요 성공 시나리오를 스케치한다. 시스템이 이해관계자의 이해관계를 정확히 반영하고 있는지를 확인한다.
성곤 시나리오를 완서앟고 발생 가능한 모든 실패 상황에 대해서 브레인스토밍을 한다. 시스템의 실패 처리방법에 대한 초안 수준의 전체 목록을 작업 전에 작성한다.
시스템의 각 실패 상황에서 대처하는 방법을 작성한다.

1.6 사용 이야기

사용 이야기는 유스케이스를 진행하는 상황의 한 예로 시스템을 사용하는 어떤 액터의 특정한 예다. 사용 이야기는 유스케이스도 아니고 산출물도 아니지만 매우 유용하다. 새로운 프로젝트를 시작할 때 개발자나 고객은 정확하게 어떤 시스템이 필요한지 정확하게 알지 못할 수 있다. 이럴 때 특정 액터를 만들어 해당 시스템을 어떤 방식으로 사용할지 이야기를 만들어 본다. 이야기는 간결하면서도 상세함과 동기, 감성적인 내용 역시 중요하다.

2장 행위에 대한 계약, 유스케이스

목표 시스템은 하나의 메커닞므으로서 다양한 이해관계자 간의 계약을 이행한다. 유스케이스는 그 계약에서 행위 부분을 서술한다. 두 액터의 상호작용을 서술하거나 이해관계자의 이해관계를 보호하기 위해 시스템이 내부에서 해야하는 일을 서술한다.

2.1 목표를 가진 액터 간의 상호작용

시스템에는 목표가 있다. 예를들어 전화로 서비스 요청을 받는 직원이 있다면 서비스 요청을 등록하고 시작할 목표가 있다. 자신의 책임을 수행하기 위해 시스템은 하위목표를 세운다. 내부에서 수행할 하위목표도 있지만 외부 지원 액터의 도움이 필요할 수 있다.
서비스 약속을 이행하는 것이 가장 중요한 목표이고 이 목표는 하위목표 달성을 통해 이루어진다. 하위목표 또한 하위-하위... 쭉 이어질 수 있다.
또 목표는 실패할 수 있는데 극단적으로 전화를 받는 중 컴퓨터가 다운된다면 시스템을 사용할 수 없다. 이럴 경우를 대비해서 예비 목표를 세워야 한다. 하위목표를 세우다 보면 이렇게 실패 할 수 있는 목표들을 볼 수 있다. 이런 실패들을 만났을때 예외처리를 하는것은 중요하기 때문에 유스케이스를 작성은 큰 장점이 있다.

String, StringBuilder, StringBuffer

Sat, 21 Aug 2021 23:13:33 GMT

Java의 문자열 API String, StringBuilder, StringBuffer

코딩인터뷰 완전분석

Sat, 14 Aug 2021 23:13:33 GMT

책 정보

코딩인터뷰 완전분석

책 소개

최근 카카오뱅크의 코딩인터뷰를 보고나서 알고리즘의 중요성을 깨달았다. 그동안 꾸준히 알고리즘 준비를 헀으면 기회가 왔을 때 잡았을탠대 하는 아쉬움이 있지만 지금이라도 늦지 않았다는 생각으로 공부를 시작해보려고 기존에 구매했던 코딩인터뷰 189가지 프로그래밍 문제와 해법 완전분석이라는 책을 읽기로했다.
무려 900page이기 때문에 9월이나 10월까지도 읽게 될것 같아서 이달의 책이란 관점이 아닌 꾸준히 보려고 한다.
책 자체는 외국에서 나온책의 번역서이고 실제 대상도 외국기업들을 취업하려는 사람들을 위한 책이지만 워낙 두껍고 바이블 같은 책이라 알고리즘을 공부하는 누구에게나 좋은책이라고 들었다. 실제로 아마존에서도 가장 많이 팔리는 면접책이라고 하고 일단 두께에서 나오듯 왠만한 알고리즘 문제를 전부 커버한다고 보면 된다. 초반 면접이나 회사들에 대한 내용은 정리하고 알고리즘 부분은 소스코드가 있다면 깃에 업로드 후 링크만 추가하려고 생각중이다.

지식 기반 문제

자바

C와 C++ 챕터가 먼지이지만 내가 다루는 언어이므로 건너 뛰도록 하겠다.

개발자 인터뷰 가이드

Mon, 09 Aug 2021 23:13:33 GMT

개발자 인터뷰 가이드

채용

고전적인 채용 절차

고전적인 채용 절차는 [채용공고] - [서류전형] - [면접] - [임원 면접]의 과정을 거친다.

고전적인 채용 절차의 문제

이력서 내용의 사실 여부 판단이 어렵다.
지원자의 코딩 실력을 알기 어렵다.
지원자가 많으면 너무 많은 서류를 검토해야 한다.
지원자당 긴 시간을 면접하게 되면 시간이 너무 많이 소비된다.
서술형 질문에 대한 답변을 암기해서 올 수 있다.
여전히 코딩 실력은 판단하기 힘들다.
비용이 발생한다.
지원자 성격에 따라 평소 실력을 발휘하지 못할 수 있다.

변하고 있는 채용 절차

기존처럼 채용공고는 이루어 지지만 지원자들이 접수하기만을 기다리는게 아니라 적극적으로 구직중인 개발자를 찾아(링크드인, 깃허브) 먼저 면접을 제의한다. 이렇게 함으로써 좀 더 직무에 안맞은 사람을 찾을 수 있다.
면접 이전에 코딩 테스트를 봄으로써 인력 비용을 최소화 하는 형태로 운영하고 이렇게 본 코딩테스트를 면접에서 다시한번 체크한다.이럴때는 문제를 푸는걸 중요하게 생각하는게 아닌 어떻게 풀었는지를 확인한다.
코딩 스킬뿐 아니라 협업능력도 체크하니 협업에서 본인이 어떤 역할을 했었는지 생각해두는것이 좋다.

대면면접의 구성

45분 면접에 15분을 휴식한다.
5분동안은 간단한 질문들로 시작한다.
15분까지는 소프트 스킬을 물어본다.
40분까지 하드 스킬 및 소프트 스킬을 검증한다.
45분까지 질문을 받는다.

채용공고 작성법

많은 잠재적인 동료가 공감할 수 있도록 작성한다.

구성

회사, 팀 업무 소개
필수 자격 요건 및 우대 사항
공지 및 지원 절차 안내

업무 소개시 원하는 인재상

고객중심의 업무, 코딩기술의 발전을 추구, 수평적인 문화 등 회사의 업무 분위기를 표현해주면 된다.

업무 소개는 간결하면서도 명료하게

단순히 시스템 유지보수, SI 등 애매모호하게 작성하면 안된다.
공공기관 홈페이지 개발 및 배포, 성능 및 구조 개선

기술 외적인 부분을 적어 지원자에게 안좋은 이미지를 주면 안된다.

사원들끼리 자주 워크숍을 간다던가 업무 외 활동에 관련된 내용을 적는다던가 하는것은 다수의 사람이 꺼리게 된다.
교육 지원비로 책 또는 온라인 강의를 지원 한다는 내용같은 복지부분은 좋게 작용할 수 있다.

이력서 검토

확인할 내용

경력 및 이력이 채용 공고의 필수 자격 요건에 준하는지 확인
이력서에 기술 및 경험을 구체적으로 서술하고 있는지 확인
회사 또는 팀에서 추구하는 중요한 가치가 드러나는 경험이 적혀있는지 확인

주의사항

편견에 주의할 것
이력서에 적힌 기술, 경험 및 가치관 이외에 사항은 철저히 무시한다.
블로그 또는 깃헙으로 편견을 가지면 안된다. 개발자가 좀 더 자신을 드러내고 싶을 수 있다 정도이지 절대적일 수 없다.
전공 학과 또한 편견이다. 요즘은 여러 교육기관이나 독학으로도 충분히 잘 할 수 있는 개발자들이 있다.

구직

면접 준비

평소에 준비하지 않았다면 3개월 정도가 필요하다.

자료구조와 알고리즘 공부
매일 코딩 퀴즈 최소 한 문제씩 풀기
예상 질문(본인이 주로 사용하는 기술)에 대한 답변 준비하기
프로그래밍 관련 서적 꾸준히 읽기(이펙티브 자바, TDD, 객체지향, 리팩토링 등)
코딩

자료 구조와 알고리즘

Big O
배열, 리스트, 스택, 큐, 해시 테이블, 힙, 트리 등의 자료 구조
정렬 알고리즘(외우는게 아니고 이해를 해야한다.)
본인이 사용하는 언어의 콜렉션즈
BFS, DFS(순회 알고리즘)

면접 실전

이력서

개인정보는 요구하지 않는다면 적지 않는다.(편견을 줄 수 있어 -가 될 수 있다.)
프로젝트 경력은 자세하게 적는다.(제목만 적으면 뭘 했는지 알 수 없다.)

면접 질문에 답하기

동료와 애기하듯 편안하고 솔직하게
실제 경험했던 사례를 구체적으로 설명한다.
근거를 들어 논리적으로 설명한다.

코딩 인터뷰

아는 문제일 경우 : 좋은 내색을 구지 할 필요는 없다. 절차에 맞게 풀이를 한다.
모르는 문제일 경우 : 흔히 있을 수 있으며 업무 중에도 모르는일이 있을 수 있기 때문에 당황하지 말고 대처를 잘 해야한다. 절차에 맞게 진행하면서도 면접관에게 질문하면서 풀이를 찾아간다. 코딩 인터뷰는 같이 풀이를 한다는걸 잊으면 안된다. 만약 자신있다고 면접관의 질문을 무시한다면 협업에 문제가 있다고 생각할 수 있다.

면접 결과

결과가 좋지 않다면 실망할 필요가 없다. 기회는 많고 일자리도 많기 때문에 이번 면접을 통해 배운것을 정리하고 경험많으로도 큰 이득이다.

연봉협상

기본급
사이닝 보너스(이직 보너스) : 거의 없으니 기대하지 않는다.
성과급 : 내규를 따르기 때문에 바꿀 수 없다.
주식
스톡옵션(주식을 살 수 있는 기회를 준다.)
ESPP(사내 주식 저렴하게 살 수 있는 프로그램)

희망 연봉을 제시할 때 이전 직장의 연봉이 아니라 지원한 회사의 직급별 평균 연봉을 참고한다.

사람인
외국
연봉비교

연봉은 이직할 때 크게 올릴 수 있어도 매년 하는 연봉협상에선 크게 올릴걸 기대할 수 없으니 최대한 올려서 받아야 한다.

계약전 확인사항

본인에게 잘 맞는 부서인지 회사인지 확인해야한다.

구체적으로 본인의 직무가 어떻게 되는지 확인한다.
부서에서 본인이 같이 일을 하게 될 동료 구성
운영 업무와 개발 업무의 비중
하루 일과

이직 후 업무 적응

팀에 적응하는 속도가 빨라야 중요한 일을 맡을 수 있다.

생소한 키워드를 문맥별로 모아서 물어볼 것(기술적인 용어가 아닌것도 많으니 물어보는것이 좋다.)
간단한 질문이 아니라면 30분 ~ 1시간 가량 미팅을 잡는게 좋다.
처음부터 너무 많은 정보를 파악하려고 하지말고 나눠서 정복하는 전략을 사용할 것.

긍정적인 피드백을 받도록 노력해야 한다.

기술적인 다양성과 포용력일 키울 것
맡은 업무에 대한 책임감
결과를 만들어 내려고 최선을 다할 것
장기적으로 또는 단기적으로 개선하고 싶은 것들을 정리해서 공유

핵심역량

핵심역량 파트에서 가장 중요한건 거짓말을 하면 안된다는 것이다. 이 파트의 내용들을 모두 정리했더라도 본인이 했던것들을 거짓으로 말한다면 꼬리에 꼬리를 무는 질문에 결국 탄로날것이고 오히려 역효과가 될 것이다.

고객중심

고객 중심적인 사고를 가지고 일하는지 확인

고객의 이슈 파악 및 해결
고객의 요구 파악 및 기대치 만족 또는 뛰어 넘기
꼭 기업 외부 고객일 필요는 없고 사내 다른 팀의 직원도 고객일 수 있다.

고객 중심 역량 파악 질문 예

외부 또는 내부 고객의 요구를 만족 시켰던 서비스를 제공한 경험이 있나요?
또는 반대로 외부 또는 내부 고객의 기대에 만족하는 서비스를 제공하기 힘들었던 경험이 있나요?
고객이 가지고 있는 문제를 해결하는 업무를 해본 경험이 있나요?

후속질문

어떻게 해당 업무에 참여했으며 결과는 어땠는지?
(성공적이었다면)그 업무가 성공적일 수 있었던 핵심적인 이유는?
(실했었다면)다시 그런 업무를 하게 된다면 어떻게 다르게 접근할 수 있는지?

좋지 못한 답변 특징

해당 경험이 없어 사례를 제공하지 못한다.
해당 업무에 적극적으로 참여하지 않았다.
스스로 고객의 이슈를 해결하지 못하고 도움을 받거나 다른 팀원에게 일을 넘겼다.

좋은 답변 특징

책임감을 가지고 주기적으로 고객의 요구와 이슈를 파악하려는 시도를 했던 경험이 있다.
고객의 요구와 기대를 조사하기 위한 피드백 시스템을 구축하거나 운영했다.
고객의 요구와 기대를 조사해 제품이나 서비스에 적용한 경험이 있다.

결과 도출

비지니스에 필수적으로 필요한 업무에 집중하고 적절한 품질과 기간 내에 결과를 만들어 내는 역량

문제를 효율적으로 해결할 것
책임감을 가지고 일할 것
비지니스에 필요하며 도전적인 업무를 맡을 것.
동료가 신뢰할 수 있는 행동을 할 것

결과 도출 역량 파악 질문 예

프로젝트 목표를 달성하기 어려웠던 경험에 대해 설명해 주세요.
장기적인 프로젝트에서 오너쉽을 가지고 일한 경험이 있는지? 각각의 마일스톤을 제때 맞추기 위해 어떤 노력을 했었나요?
도전적인 프로젝트였지만 동료들과 함계 해낸 경험이 있나요?

후속 질문

해당 프로젝트에는 어떻게 참여하게 되었나?
과정중에 생긴 문제점을 어떻게 해결했는지?
다시 돌아봤을 때, 어떤 점 때문에 해당 프로젝트를 성공적으로 마무리 할 수 있었는지? 아니면 다르게 시도해 보고 싶은 것이 있는지?

좋지 못한 답변 특징

주도적인 다른 동료의 지시에 따르기만 한 경우
충분한 회의나 분석을 거치지 않고 문제 해결을 시도하는데 급급한 경우
프로젝트 또는 업무의 기한을 맞추는데 필요한 중요한 의사소통의 결여

좋은 답변 특징

예정됐던 일정 안에 긍정적인 결과를 만들어 낸 경우
문제를 해결하는데 필요한 정량적인 데이터를 수집해 본 경험
목표를 달성하는데 필요한 업무를 주관적으로 제안하고 실행에 옮긴 경험
지속적으로 목표 달성에 필요한 데이터를 모니터해 본 경험

영향력

다른 동료 또는 팀을 설득하고 좋은 영향을 주는 능력

커뮤니케이션을 효율적이고 논리적으로 하는 능력
긍정적인 관계 형성으로 업무 효율을 높이는 능력

영향력 파악 질문 예

업무를 위해 누군가를 설득하거나 당신의 입장을 이해시켜야하만 했던 경험이 있나요?
같이 일하는 동료와의 좋은 관계 형성으로 프로젝트에 긍정적인 영향을 끼친 경험이 있나요?
다양한 견해를 가지고 있는 주요 관계자들의 요구를 성공적으로 만족시킨 경험이 있나요?
동료나 다른 팀을 설득해 프로세스를 개선해야 했던 경험이 있나요?

좋지 못한 답변 특징

설득에 필요한 정량적인 데이터를 활용하지 못한 경험
주요 관계자와 신뢰를 쌓지 못한 경험
개인 관심사를 중심으로 업무를 진행한 경험
비효율적이거나 논리적이지 않은 방법으로 관계를 형성하려 했던 경험

좋은 답변 특징

데이터를 근거삼아 설득한 경험
주요 관계자와 강한 신뢰를 쌓은 경험
주요 관계자들의 견해와 입장을 이해하고 그런 이해를 바탕으로 업무에 도움을 준 경험
설득을 통해 본인의 팀 또는 다른 팀까지 좋은 영향을 주었던 경험

적응력

변화하는 환경에 효율적으로 반응하는 능력

끈임없이 탐구하고 학습한다.
스트레스가 심한 상황에서도 건설적인 자세를 유지한다.

적응력 파악 질문 예

조직 개편 (새로운 팀장이 오거나, 팀을 이동하거나) 등으로 스트레스를 받았던 경험이 있나요?
업무 처리 방법에 변화를 시도했던 경험이 있나요?
가이드나 정보가 거의 없이 시작했던 프로젝트를 완료했던 경험이 있나요?

부적절한 답변

스트레스를 잘 처리하지 못한 경험
정보가 부족한 경우 비효율적으로 일을 처리한 경험
변하는 상황에 맞추려는 노력이 부족했던 경험

적절한 답변

변화하는 상황에 효율적으로 또는 즉각적으로 대응했던 경험
정보가 부족한 경우에도 효율적으로 일을 하거나, 그 자체를 새로운 기회로 삼았던 경험
스트레스가 심한 상황에서도 건설적인 자세를 유지했던 경험

판단력

여러 대안과 관점을 고려하여 결정

해결하려는 문제의 볌위를 정의한다.
가정하지 않고 근거를 가지고 증명한다.

판단력 파악 질문 예

업무에서 치명적인 실수를 했던 경험이 있나요?
여러가지 대안이 있는 상황에서 어떤 과정을 통해 가장 적절한 방법을 선택했나요?
복잡했던 문제를 해결하기 전에 필요한 지식을 습득해야 했던 경험이 있나요?

부적절한 답변

여러 대안을 충분히 검토하지 않고 결정했던 경험
서두르거나 충분한 정보없이 섯부른 판단을 했던 경험
동료 또는 다른팀의 도움이 필요한 상황인데도 도움을 요청하지 않았던 경험

적절한 답변

판단에 필요한 정보를 다양한 방법으로 수집하고 검토한 다음 결정했던 경험
필요한 정보를 기반으로 적절한 시간 내에 좋은 판단을 했던 경험
필요한 상황에서 적절한 도움을 요청했던 경험

협업

동료 또는 다른 팀간의 팀웍 또는 공조를 통해 업무를 해내는 능력

여러 동료 또는 팀의 리소스와 노력을 조합하여 일을 한다.
개인의 목표가 아닌 공동의 목표를 달성하려 노력한다.

협업 파악 질문 예

치명적인 이슈를 해결하는데 필요한 다른 팀과 같이 일헀던 경험이 있나요?
여러 팀이 함께 일해야 했던 프로젝트가 잘 돠지 않았던 경험이 있나요?
동료와 마찰이 생겼던 경험이 있나요?

부적절한 답변

협업이 필요한 상황에서 최소한의 기여만 했던 경험
요청 받은 경우에만 협업했던 경험
협업을 증진시켰던 좋은 사례를 들지 못하는 경우

적절한 답변

협업에서 의미있고 중요한 업무를 했던 경험
필요한 경우 헙엽을 제시하거나 주도했던 경험
협업을 증신시켰던 좋은 사례를 제시한 경우

STAR 프레임워크

S(Situation): 어떠한 상황에서 T(Task) : 어떤 업무를 하거나 또는 목표를 달성했는지 A(Action) : 본인이 무엇을 어떻게 했는지 R(Result) : 결과는 어떠했는지? 실패했다면 배운것은?

면접관에게 질문하기

면접이 끝나기 전에 면접관에게 궁금한 것을 물어볼 수 있는 시간이 주어진다.

좋은 질문을 남기면 면접관의 인상에 남는다.
여기서도 핵심역량을 드러낼 수 있다.

좋은 질문의 예

이곳에서 일하며 배우거나 경험한 가장 중요하거나 가치있는 것은 무엇인가요?
이 회사 또는 팀에서 현재 직면한 기술적인 이슈는 무었인가?
새로운 팀원이 합류하면 업무 적응은 어떤식으로 이루어 지는지? 참고할 문서가 있거나 멘토가 있는지?
사외 또는 사내 고객과 주기적인 회의나 모임을 갖는지? 고객과 어떤 방법으로 소통하는지?
어떤 업무의 해결책이 여러개일 때 어떤 과정을 통해 결정하는지?
일정은 그대로인데 프로젝트의 요구사항이 계속 바뀐적이 있는지? 이 팀이나 회사에서는 보통 어떻게 대처하는지?

나의 질문

프로젝트가 시작되면 일정은 어떻게 관리되는지? 기존회사는 WBS 엑셀 문서를 통해 관리하였다.
일정을 진행하면서 클라이언트의 요구사항이 변화가 생길 경우 어떻게 해결되는지 이런 고객과의 의논을 개발팀에서 직접하는지 한다면 메일로? 직접 만나서? 전화로?
이직을 하게 된다면 인수인계를 위한 문서나 멘토가 있는지?
기존에는 서버나 DB, 산출물들을 직접 관리했는데 관리해주는 사람들이 따로 있는지?
학습을 위해 지원을 얼마나 해주는지?
주요하는일의 특징은?

코딩 인터뷰

일반적인 환경에서 코딩 -> 손코딩 -> 입으로 설명하면서 코딩 순으로 연습한다.
개발환경에서도 못하는 코딩이 갑자기 손으로 써지지는 않는다. 인터뷰에서 설명을 해야하기 때문에 입으로 설명하는 연습도 빼먹으면 안된다.
문제를 보고 다짜고짜 문제부터 푸는게 아닌 문제에 대한 정의를 내리고 어떤 절차로 진행할지 설명한 후 문제를 푸는것이 좋다. 문제를 푸는 중 해결이 되지 않을 때 면접관이 힌트를 제공한다면 그 힌트를 이용해서 어떻게 적용시킬지 대답해주어야 한다.

코딩 인터뷰 프레임워크

문제를 해결함에 있어 면접관과 인터뷰를 한다는 느낌보다는 동료와 같이 해결한다는 관점으로 접근해야하고 문제를 푸는 주체가 본인이라고 생각해야한다. 중요한건 동료이기 때문에 같이 풀어나간다고 접근해야한다.

가장 먼저 해당 문제를 정리하고 본인이 이해한것이 맞는지 면접관에게 확인한다.
입력, 출력 범위, 타입같은것 등 문제에서 명확하지 않은것을 체크한다.
위에 내용들을 실제 예를 들어가며 다시 한번 체크한다.
이제 문제에 대한 고민을 하고 어떤 방식으로 구현할지 결정한다.
해당 로직을 설명하고 해당 시간과 공간 알고리즘 복잡도를 설명
로직대로 코드를 작성한다.
3번에 예시를 케이스로 테스트한다.

알고리즘 복잡도

빅 오 노테이션: O(n), O(logN), O(1), O(n제곱)

함수에서 엄밀한 점근적 상한을 나타내는 표기법
수자는 다 빼고 가장 증가율이 높은 수식만 남긴다.
f(n) = 4 O(1)
f(n) = 3n + 3n + 3 O(n)
f(n) = 8n제곱 + n + 3 O(n제곱)
f(n) = 8n + log(n) +3 O(n)
O(1)은 여러개의 매개변수가 들어와도 리턴값이 고정되는걸 의미한다.
O(n)은 매개변수가 들어오는거에 비례하는 리턴값을 의미한다.
O(n제곱)은 주로 2중 포문같은것을 의미하는데 면접관은 이런 코드를 바라지 않을 확률이 높으므로 이런방식으로 답을 구하려 한다면 다시 생가해보는것이 좋다.
매개변수가 배열인 함수에서 리턴값이 고정된 인덱스 값을 호출한다면 이건 시간복잡도가 O(1)이고 메모리에 변화가 없기 때문에 공간복잡도도 (1)이다.
숫자 배열이 들어와 합을 구하는 함수라면 같은 반복문을 계속하기 때문에 시간 복잡도는 O(n)이고 더하면서 하나의 변수에만 값을 저장하기 때문에 공간복잡도는 O(1)이다.
재귀함수의 경우 반복문이 없어도 계속 본인을 호출하기 때문에 시간복잡도가 O(n)이고 재귀함수는 스택영역을 사용하기 때문에 메모리를 계속 사용하여 공간복잡도 또한 O(n)이다.
숫자 배열에서 특정 숫자를 찾기위해 보통 바이너리 서치를 사용하는데 이는 가운데 인덱스를 가져와 특정값과 비교하고 작다면 -1을 크다면 +1을 하여 총 인덱스에 절반씩 버려가며 찾을 수 있다. 이런 바이너리 서치의 경우 절반씩 날라가기 때문에 시간 복잡도가 O(logN)이다. 공간 복잡도의 경우 들어오는 값에 상관없이 저장용 변수만 선언되므로 O(1)이다.

간단한 예제

매개변수를 인트형 List로 받는데 해당 리스트에는 같은 숫자가 2개씩 있는데 오직 하나의 숫자만 한개가 있다. 하나만 있는 숫자를 리턴한다.
기본적으로 매개변수를 반복시키기 때문에 n이 존재하고 또 새로생성한 리스트에 해당 데이터가 있는지 검사하면서 반복을 하기때문에 n이 존대한다. 그래서 시간복잡도는 O(n제곱)이다.
공간 복잡도의 경우에도 해당 매개변수 리스트에 같은 숫자들이 연속으로 나온 전제가 없으므로 한번에 몇개까지 리스트에 데이터가 들어갈지 모르므로 O(n)이다.
하나의 리스트를 선언하고 매개변수로 넘어온 리스트를 반복하면서 새로 생성한 리스트에 반복문으 숫자가 들어있다면 제거하고 없다면 숫자를 추가해준다. 이렇게 반복하다보면 같은숫자들은 같은숫자가 나올경우 제거되기 때문에 하나만 있는 숫자만 리스트에 남게된다. 만약 같은 문제를 맵으로 한다면 맵의 키를 해당 리스트이 숫자로, 맵에서 해당 키가 있다면 값을 불러와 +1해주어 해당 숫자의 카운트를 값으로 넣어준다.
이럴경우 시간복잡도는 리스트와는 다르게 맵은 반복하는 형태가 아니므로 O(n)의 방식이고 공간복잡도는 여전히 매개변수에 따라 맵의 크기가 변하므로 O(n)이다.
마지막으로 xor를 활용하는 방법이 있다. xor같은 경우 같은 숫자라면 0으로 0과 다른숫자라면 원래대로 보여준다. 그렇기 때문에 하나의 변수만 선언해서 작업을 완료할 수 있다. 반복문을 사용하기 때문에 시간복잡도는 여전히 O(n)이지만 공간복잡도의 경우 O(1)이다.

배열

배열은 연속된 메모리 영역에 저장된 데이터로 조회가 O(1), 추가 및 삭제가 O(n)의 복잡도를 가지고 있다. 조회는 빠르고 추가 및 삭제는 느리다.

자바에서 배열은 만들 때 크기를 정해야 하며, 추가 및 삭제 기능은 없다.
다른 자료구조를 구현하는데 사용하는 가장 기본적인 데이터 구조다.

배열문제는 우선 정렬이 되어있는지 체크한다.
인트형 배열에서 같은 숫자가 하나라도 있다면 true를 리턴해주는 문제가 출제되었을때 i,j로 2중포문으로 해결한다면 시간복잡도는 O(n제곱), 공간복잡도는 O(1)이다. 하지만 O(n제곱)의 형태는 출제자가 원하는 방향이 아닐 확률이 높으므로 다시한번 생각해보는게 좋다.
Arrays.sort를 사용하여 정렬을 한다면 구지 반복문을 2번할 필요없이 현재인덱스 값과 다음인덱스 값만 검색해도 답이 명확해진다. 반복문을 2번하는것보다 Arrays.sort를 사용하는것이 시간복잡도에서 이득이니 정렬한 뒤에 문제를 풀자
또 다른 방법으로는 set을 사용하는것이 있는데 set은 중복을 허용하지 않고 시간복잡도가 O(1)이다.

실습 소스코드

리스트

자료구조에서 리스트와 자바의 컨렉션즈의 리스트와는 조금 다르다. ArrayList는 개념적인 배열과 비슷하다. 배열은 사이즈가 고정되고 리스트는 크기가 동적으로 알아서 조절된다.
Vector와 ArrayList는 배열기반의 리스트이고 링크드 리스트는 노드기반의 리스트이다. Vector은 하나의 쓰레드만 접근할 수 있고 ArrayList는 여러 쓰레드가 접글할 수 있어 성능적으로 더 빠르고 자주 쓰인다.
ArrayList는 index기반이다. ArrayList에 데이터를 추가할 때 배열처럼 추가된다면 새로운 데이터를 추가할때 공간을 만들어주기 위해 새로운 List를 추가하여 복사하는일이 벌어질탠대 이러면 O(n)이 되지만 ArrayList는 처음 생성될때 여유공간을 만들어 놓기 때문에 O(1)방식으로 처리할 수 있다. 다만 중간의 index에 값을 넣어줘야 한다면 무조건 O(n)이 된다.
삭제의 경우도 배열이라면 중간에 삭제한 공간을 없에기 위해 다시 리스트를 만들어줘야 겠지만 ArrayList는 중간에 비어있는 공간을 두고 나중에 한번에 작업하기 때문에 O(1)이다.
ArrayList의 조회는 get을 이용할 경우 index를 사용하기 때문에 O(1)이고 contains를 사용한다면 값을 찾아 비교해야 하기 때문에 모든 데이터를 조회하므로 O(n)이다.
링크드 리스트는 개념적인 Index는 있지만 실제로는 Index는 없다. 그럼에도 index로 데이터를 가져오는것은 처음 데이터에서 해당 index만큼 연결된걸 추적해서 가져오는것이다. 만약 100번째를 가져온다면 100번 이동 후 가져온다. 그렇기 때문에 링크드 리스트는 조회가 O(n)이다. 하지만 중간에 새로 추가하거나 삭제하는 경우는 양쪽 데이터에 이어진 링크만 바꾸면 되므로 O(1)이다. 하지만 마지막 인덱스에 넣을 경우 모두 조회를 하기 때문에 O(n)이 될 수 있다. 이렇게 이론적으로는 O(1)이지만 프로그램에서는 사용자가 Node를 모르기 때문에 값으로 조회해야하기 때문에 결국 O(n)이 될 수 밖에 없다.

스택

리스트와 비슷한 구조이지만 데이터를 입출력하는 쪽이 한군데라는점이 다르다. FILO의 특징을 가지고 있다.
데이터를 넣는 작업을 push라고 하고 꺼내는것을 POP이라 한다. 현재들어가 있는 데이터 수를 peek 또는 top이라 한다. 데이터가 추가되면 top을 새로온 값으로 설정하고 pop이 되면 해당 데이터를 보여주고 그 아래 데이터를 top으로 변경해주면 된다.
java에는 stack를 제공하지만 Deque를 사용할것을 권장하고있다.

개발자 이력서 작성법

Sat, 07 Aug 2021 23:13:33 GMT

개발자 이력서 작성법

개인 프로필

개인정보의 경우 블라인드로 진행한다면 요구하지 않을 수 있기 때문에 회사별로 다르다. 사진을 넣어야 한다면 당연하게도 단정한 사진이 좋다. 프로필 영역이 단순히 프로필만 적는 곳이 아니다. 본인이 신업으로 구직하고 있다면 포트폴리오, 경력직이라면 경력기술서의 링크를 입력하여 살펴볼 수 있도록 해야한다.
포트폴리오나 경력기술서를 단순히 블로그나 깃허브 링크로 입력하게 된다면 인사 담당자가 링크를 타고 들어온다고 해도 어디를 봐야할지 몰라 관심을 가지기 힘들다.
깃허브라면 다른사람에게 별을 받았다던지 fork를 한 다른 사람들이 있다면 fork로 어필을 해도 되고 해당 구직공고에서 요구하는 기술들로 한 프로젝트가 있다는 것을 어필해좋다.
블로그도 마찬가지이다. 본인이 포스팅한 내용중에 공고에 올라온 기술에 대해 업로드한 게시물의 수나 얼마나 많은 사람들이 접속하였는지 어필하는것도 좋다.
여기서 주의할점은 만약 블로그나 깃허브의 링크를 남겼는데 포스팅한 내용들이 생각보다 공고에 걸맞지 않거나 단순 과주수준, 남의 프로젝트를 포크하여 별 내용이 없다면 오히려 마이너스가 될 수 있다.

핵심 역량

핵심 역량을 기록할 때는 강조하고 싶은 부분을 앞쪽에 적는다. 내용은 당연히 공고에서 요구하는 능력들을 보유한 기술과 경험을 중심으로 적고 구체적인 기술 키워드를 적어준다. 아래는 그 예시이다.

Spring, Spring Boot, 전자정부프레임워크 등 스프링 기반의 프래임워크를 활용한 프런트엔드, 백엔드 개발 경험 실제 서버에서 Vmware를 사용하여 CentOS7를 설치하고 리눅스 환경에서 Mysql 5, tomcat, jdk를 셋팅하여 테스트 서버 구축 경험 WBS, 요구사항 정의서, 유스케이스, 화면설계서, 테이블 정의서 등 서비스 요구사항 분석 경험

보유기술

보유기술을 입력할 때 단순나열은 본인의 역량을 전달하기 힘들다. 상중하 같은 표기도 큰 도움이 되지 않는데 이런 보유기술 기입은 특정 양식에선 요구하기도 한다.
당연하게도 공고에 나와있는 기술들을 강조해서 작성해야하고 어설프게 알고 있는 기술들은 적지 않는게 오히려 좋다. 한번 학교에서 다뤄봤다거나 인간한번 본 정도의 기술들을 전부 나열한다면 신뢰도가 낮아지니 실제로 작은 프로젝트로라도 경험이 있는 언어들을 넣는게 좋다.
1~5나 상중하로 적는것 보단 기술별로 사용할 수 있는 범위가 좋다.
아래는 예시이다.

JAVA: 주로 1.8버전으로 작업하였고 Spring 레거시, 전자정부 프레임워크를 주로 프로젝트를 진행햐였다. MVC로 작업하면서 ArrayList, HashMap을 주로 사용하였다.
WAS :TOCAT을 주로 사용하며 테스트환경 구축을 위해 리눅스에 설치하여 운영하여 보았고 하나의 서버에 2개의 톰캣을 설치하여 운영, 하나의 톰켓에 war를 2개 배포하여 구성도 해보았습니다. 도메인 연결을 위해 mod_jk를 사용해 apache와 연동도 해보았습니다.
DB : MySQL을 사용하였고 주로 사용한 버전은 5버전입니다. 리눅스에서 DB를 설치하여 계정을 생성하여 테스트환경 구축을 하였고 작은 규모의 프로젝트 시 테이블 설계, Mybatis, ibatis를 이용하여 웹에서 데이터 처리를 하였고 수준은 서브쿼리와 조인문을 사용하는 정도입니다.
javascript : 주로 jquery와 같이 사용하였고 DOM구조를 이해하여 원하는 태그를 가져온다던지 생성할 수 있습니다. Ajax를 사용하여 서버와 통신을 할 수 있습니다.

경력

단순하게 회사이름과 직무만 적을 수 있는데 이전에 있던 회사가 어떤 업무를 했는지 또 본인이 담당한 직무에서는 어떤일을 했는지 자세하게 적어준다.
직무를 적을 때에도 단순하게 서버개발, 백엔드 개발 이런식으로 적어주면 어느정도의 일을 했는지 알 수 없다.
구체적인 내용을 적어야 하지만 그렇다고 너무 길어도 안된다.

국가기술표준원과 그 하위 기관들과 SI,SM 사업을 하는 회사에서 주로 SI업무를 했고 주 개발 업무는 게시판, 파일업,다운로드, 엑셀을 업로드하여 DB에 저장하는 기능을 많이 하였고 프로젝트 준비 단계에서 각종 산출물과 프로젝트를 셋팅하여 SVN에 등록하고 테스트 서버에 TOMCAT, MySQL을 설치하여 협업환경을 구축하였습니다.

프로젝트

프로젝트의 규모, 목적, 참여인원, 내 역할, 사용기술, 성과 등을 구체적으로 기술해야 한다. 나의 개발 역량을 잘 표현해야 하고 만약 프로젝트가 없었다면 개인이 진행한 일도 추가해주어야 한다.

제품안전 R&D / 풀스택 개발, 팀원
2020.09 ~ 2021.06
국가기술표준원에서 솔루션으로 동작하던 리콜시스템을 제거하여 리콜 전 단계인 안전성조사 시스템, 리콜 후에 진행하는 이행점검 시스템과 연동하는 R&D 사업 참여. 사업을 관리해주는 PM, 안전성 시스템과 연계하는 작업 담당과 리콜시스템 개발 담당 총 3명이서 참여한 프로젝트
기존의 솔루션을 Java와 Spring 프레임워크를 사용하여 변경 하였고 이미 Java와 Spring로 구현된 안전성조사 시스템과, 이행점검 시스템과 연계하였다. 프로젝트 수행 결과 같은 데이터임에도 불구하고 리콜 시스템에 데이터를 입력/관리 할 필요 없이 자동으로 처리 할 수 있게 되었고 파일로 관리되던 데이터들이 DB로 관리됨으로써 편의성이 증가되었다.
맡은 업무 : 산출물(유스케이스, 화면설계서, 요구사항 정의서, ERD, 테이블 정의서, 연구일지)작성, 안전성조사 시스템과 리콜 시스템 연계(데이터 표준화 및 코드화)

학교 / 자격증 / 교육기관 수료

회사가 선호하는 학교나 전공이라면 강조해야 한다.
비전공자라면 교육기관이나 개발 동아리, 현재 하고있는 스터디 등을 어필한다.
학교가 아닌 다른 활동은 구체적으로 작성하고 증빙 자료가 있다면 넣어주어야 한다.
블라인드가 아니라면 학교에 대한 내용을 적을 때 IT관련 전공이 유리하다. 개발관련 활동은 있다면 기입해야 유리하다.
스터디나 교육기관에서 학습한 경우라면 공고와 관련된 학습내용들은 구체적으로 적어주어야 하고 포트폴리오의 형태나 깃허브, 테스트서버에 띄워서라도 보여주는것이 유리하다.
자격증의 경우 직무관련 자격증만 기입해야 한다.

자기소개

단순 취미나 자라온 환경같은 경험 소개 보다는 본인의 직무관련 역량을 보여주는 내용이 유리하다.
꾸준히 개발관련 공부를 하였다던가 공고에 나온 기술 관련 직무에 대한 내용, 협업에 대한 경험을 적어주면 유리하다.
개발자가 된 계기나 이력서를 넣을 회사의 지원 동기를 자세히 적는다.
보유기술 뿐만 아니라 문제해결 능력이나 커뮤니케이션 능력을 어필한다.

7월의 책 함께 자라기 애자일로 가는 길

Mon, 26 Jul 2021 23:13:33 GMT

책 정보

함께 자라기 애자일로 가는 길

책 소개

1달 책한권 2021년 7월에 읽을 예정인 책은 함께 자라기 애자일로 가는 길이다.
원래는 Head First PMP를 읽고 있었지만 600페이지가 넘는 이론서이기 때문에 다음달까지 읽는걸로하고 이번달은 가벼운 책을 읽으려한다.
현재 다니는 회사에서 다른직원들과 성장하고 싶기도 하고 애자일 방식으로 프로젝트는 어떻게 진행하는지 궁금했었기 때문에 이 책을 골랐다.

후기

정리를 마치고 마지막 후기를 남긴다.
이번 책은 얇았던만큼 생각보다 깊이있는 책은 아니었다. 3년차가 되면서 설계에 대한 중요성도 느끼고 도제학습하는 고등학생들이나 피텍을 하는 대학생들도 있어 함께 성장하고 싶어 함께 자란다는 말이 매우 궁금했다.
책은 200p정도인데 솔직히 아무리 압축해도 이런 심오한 내용들이 들어가기엔 부족하다. 솔직히 말하면 개발관련 서적보단 자기개발 서적에 가까웠다.
하지만 팀적으로 동기부여를 하고싶고 애자일을 팀에 도입하고 싶다면 한권정도 구매하여 팀원들과 같이 읽어보는것도 좋지 않을까 싶다.
개인으로서는 이책에서 애자일에 대한 상세 프로세스를 전혀 보지 못했기에 또 다른 서적을 찾아 추가 공부해야겠다는 생각을 했다.

자라기

개발자를 뽑을 때 경력만 보는 경우 실패할 확률이 높다. 최근에는 경력이 훤씬 모잘라도 더 일을 잘하는 경우가 많다. 때문에 기업에선 테스트나 협업에 대한 경험을 통해 뽑는것이 더 현실적으로 도움이 된다.
어떻게 채용을 해도 실패할 수 있기 때문에 새롭게 채용된 직원이 성장할 수 있는 시스템을 만드는것이 중요하다.
애자일 방식으로 프로젝트를 진행한다면 설계이후 오랜뒤에 개발을 하는게 아닌 설계와 개발이 거의 같이 진행되기 때문에 피드백을 빠르게 자주 받을 수 있어 개발자의 성장을 돕는다.
잡코리아의 조사에 따르면 일반적인 직장인은 40%정도가 1~2시간 정도의 자기계발을 하는걸로 조사되었다. 만약 본인이 1시간도 자기계발에 투자를 하지 않는다면 1년을 생각해보면 어마어마한 격차가 생길것이다.
개인이 성장하는것보다 집단으로 성장하는것이 속도가 훨씬 빠르다. 현재하는 업무를 A라고 한다면 이런 업무를 개선하는 작업인 B가 필요하고 업무를 개선하는 작업을 발전시키는 C작업이 필요하다.
새로운 지식을 배웠다면 기존것과 같이 사용하면서 어떻게 발전할 수 있을지 고민하라
내부적으로만 개선하는게 아닌 외부적인 평가도 간혹 필요하다.
혼자 작업하는것도 작업 결과물에 대해 개선할 점을 회고하는 과정과 그런 개선을 찾는 방법들을 발전시킬 방법들을 찾아야한다.
이런 평가가 동반되는 작업들은 자주 일어날수록 좋다. 1년짜리 큰 실험을 하기보단 1달, 1주 정도되는 작은 단위로 프로세스를 구성해라
성과를 보이기위해 작업하는것과 학습을 위해 작업하는것 중 학습을 위해 작업하는것이 성장에 도움이 된다.
설계부터 협상까지 전반적으로 다루는 소프트웨어 개발자가 프로그램만 작성하는 컴퓨터 프로그래머보다 유망하다.
실력을 개선할 동기가 있어야하고 적절한 피드백을 자주 받을 수 있어야 한다.
실력이 보다 난이도가 높은 일을 받으면 불안감이 커지고 실력에 비해 낮은 난이도의 일을 받으면 지루해진다. 이 사이에 적절한 난이도의 일을 해야 몰입할 수 있다.
만약 현재 주어진 일이 지루하다거나 불안하다면 몰입할 수 있는 전략이 필요하다.
만약 지루하다면 운동선수들이 모래주머니를 차고 훈련하듯 에디터의 도움을 최소화 한다던가 키보드로만 작업한다던가 하는 패널티를 부여한다. 또는 일을 일부러 어렵게 만드는 방법도 있다. 1시간 만에 일을 종료한다는 조건을 걸거나 디버그 없이 작업한다거나 테스트 코드를 상세하게 만들거나 리펙토링에 신경쓰는 등 하는업무에 제약을 걸어 난이도를 올린다.
불암감을 느낀다면 더 잘하는 개발자에게 질문을 하던가 협업을 요청하여 배우면서 작업을 한다던가 지루한 경우와 반대로 최대한 에디터의 최신기능의 도움을 받으면서 작업한다. 반대로 업무의 난이도를 낮추는것도 가능한데 최소한의 핵심기능만 들어간 버전을 목표로 작업함으로써 좀 더 쉬운 업무를 진행하는게 가능하다.
새로운 개발언어를 공부할때 이론을 보면서 단순히 이론만 보는게 아니라 실재라면 어떻게 적용시킬지 구상해보던가 직접 코딩하면서 공부한다. 표준 라이브러리를 찾아 읽어보며 해당 언어의 스타일을 파악한다. 오픈소스를 찾아 기능을 추가해본다.
실수를 예방하는것이 아니라 관리하는 것이다. 예로 미국의 산림청에서는 예전에는 예방을 하려했으니 예방을하려다 보면 가끔 일어나는 사고로 인해 오히려 더 큰 사고가 다는걸 알게되고 화재발생을 막는게 아닌 발생할 수 밖에 없는 화재들을 관리하도록 바뀌었다.

함께

뛰어난 개발자는 이미지와 다르게 협력과 커뮤니케이션 능력이 뛰어나고 개발에 들어가는 시간은 일반적인 개발자와 크게 다르지 않다.
같은일을 혼자할때보다 둘이한다면 추상화 규칙이 많아진다. 같은 일도 개인마다 보는 시각이 다른데 서로 다른 생각을 공유하다보면 서로다른것을 이어주기 위한 추상화가 필요하기 때문이다.
탑다운은 문제 해결 과정을 추상적인 숲에서 구체적인 나무로 내려오는 접근법이고 바텀업은 나무에서 출발해서 숲으로 올라오는 과정이다. 큰 그림을 보는 탑다운이 전문가 처럼 생각할 수 있지만 전문가일수록 탑다운과 바텀업을 업무에 특성에 따라 바꿔가며 작업한다. 명확한 목표가 있는 작업일수록 탑다운이 좋고 작업에 목표가 불문명할수록 이것저것 확인해보면서 작업하는 바텀업이 유리하다.
연구에 따르면 프로그램을 이해할 때 고수는 상호 참조 전략을 쓴다. 프로그램을 연구하면서 이해한 것을 도메인 어휘로 번역하고 이 도메인 어휘를 다시 프로그램상의 어휘로 바꿔 검증한다.
세계에서 뛰어난 개발팀들이 공통적으로 가지고 있는 특징이 있는데 그 중 하나가 삼투압적 의사소통이다. 팀이 가까운 거리에서 일하고 편하게 질문하며 각각의 멤버들이 본인들의 생각을 애기하며 정보를 공유한면서 본인에게 스며들게 되는걸 의미한다.
개발의 추상화는 전략, 범위, 구조, 뼈대, 비주얼의 과정이 필요하고 개발은 분석, 설계, 구현, 테스트, 전개의 과정이 필요한데 프로젝트 전체 범위에서 이런 순차적인 단계의 일을 계획할게 아니라 이런 일정들을 최대한 빠르게 구현해서 자주 결과물을 보여주고 피드백 받아야 한다.
구글에선 관리자가 없는 팀을 만들기 위한 실험을 했지만 실패했고 관리자의 특징에 대한 연구를 지속하였다. 이런 연구에 대한 결과가 일부 공개되었는데
첫번째는 팀에 전문가가 있는것보다 서로 어떻게 상호작용하고 자신의 일을 어떻게 바로보는지가 훨씬 중요하다는 것이다.
두번째는 성공적인 팀은 심리적 안전감을 가지고 있다. 심리적 안전감이란 내 생각이나 의견을 애기하거나 질문을 해도 처벌하거나 놀리지 않고 실수하는것에 대한 두려움이 없는 조직문화가 있는것을 애기한다.
세번째는 이런 심리적 안점감을 위해 토론이나 교육을 제공하는것이 좋다는 것이다.
일반적으로 개발자들이 개발에 걸리는 시간을 예측할 경우 틀릴 확률이 매우 높고 오류가 난다던가 디버깅, 배포, 셋팅 등의 변수들과 또 개발하는 사람이 1명이 아니기 때문에 여러명이 같이 작업을 하기 때문에 예측한 것보다 훨씬 많은시간이 소요된다. 실제로 일반적인 보통 개발자들이 예측한 시간보다 2배에서 3배정도의 시간이 걸리는 경우가 많다는 소프트웨어공학 연구가 있다고 한다.
관리자가 팀에게 일을 부여할 때 보통 각각의 일을 주고 개별적으로 일을 주는 경우가 많은데 애자일에서는 팀 전체에 3가지 일을 주고 완료되면 또다시 3가지 일을 주는 식으로 일을 팀이 전체적으로 해결하게 한다. 이런식으로 일을하면 매번 새로 조직화하고 일을 분배하며 서로 일을 배우는 시너지가 생길 수 있다.
애자일에서는 이렇게 모두가 같이 일을 한다. 위에서 말한것처럼 여러명이서 일을 할때 일정관리를 실수 없이 하는것은 매우 어렵지만 애자일에서는 다같이 하기 때문에 먼저 일을 마친사람이 다른사람들을 도우면 되어 리스크가 분산된다. 또 같이 하기 때문에 이번 프로젝트로 뭔가 새로운 발견이 있을 때 팀적으로 성장할 수 있다.

애자일

이전에 소프트웨어 프로젝트를 진행할 때 주로 사용되던 방법은 계획주도의 방식이었는데 이런 방식을 사용했던 것은 초반에 계획을 정교하게 함으로 써 실행단계는 간단해지고 모든 변수들을 예측가능하게 만들 수 있다고 생각했기 때문이다. 애자일은 이런 변수들을 완벽하게 통제할 수 없다는걸 인정하고 불확실성에 어떻게 대처할지 고민한 결과물이다. 이런 애자일은 불확실성이 높은 프로젝트에 적합하고 불확실성을 제거하기 위해 짧은 주기로 개발 사이클을 완료하여 피드백을 더 많은 사람들에게 자주 받아 완성도를 높인다.
애자일을 한문장으로 압축하면 고객에게 매일 가치를 전하라입니다. 고객에게 어떻게 보다 일찍 보다 자주 피드백을 받을 것이며 이런 피드백을 자주 받음으로써 이번 프로젝트에서 고객에게 중요한것이 무엇인지 파악하여 완성도를 높여야 합니다.
70여개의 회사에 애자일을 도입한 후 만족도에 대해 조사를 했는데 73%의 회사는 만족스럽다는 답변을 했다. 이런 조사를 통해 어떤점이 애자일을 성공하게 했는지 분석하였는데 고객참여가 가장 높은 순위였다. 즉 애자일의 중요한점은 고객에게 자주 피드백을 받아야 한다는 것이다. 이외에도 리펙토링, 코딩 후 자동화 단위테스트 붙이기, 코드 공유가 주요 원인으로 뽑혔다.

CentOS7 MySQL 셋팅

Sun, 18 Jul 2021 23:33:33 GMT

CentOS7 MySQL 셋팅

wget를 설치한다.
net-tools를 설치한다.(ifconfig)
gcc gcc-c++설치한다. (컴파일)
mysql 그룹, 계정 추가 및 mysql 다운로드
gz압축을 푼다.
압축푼 경로로 들어간다.
옆에 코드를 입력 ./configure --prefix=/usr/local/mysql --localstatedir=/usr/local/mysql/data --sysconfdir=/etc --with-mysqld-ldflags=-all-static --with-client-ldflags=-all-static --without-debug --enable-assembler --with-charset=utf8 --with-plugins=innobase --with-extra-charsets=all
No curses/termcap library found 오류가 발생 시 옆에걸 설치하고 다시 한다. yum install libtermcap-devel ncurses-devel
make / make install 입력해준다.
cp ./support-files/my-medium.cnf /etc/my.cnf 파일 이동(오버라이트 옵션이 뜬다면 y를 눌러준다.
/usr/local/mysql/bin/mysql*installdb 입력해준다.
![mysql 권한설정](11.각종권한설정.png)
chown -R mysql.mysql /usr/local/mysql/data mysql계정에 권한부여
cp support-files/mysql.server /usr/local/mysql/bin chmod 755 /usr/local/mysql/bin/mysql.server /usr/local/mysql/bin/mysql.server start 입력 스타트 파일을 복사하고 권한주소 서버를 시작한다.
/usr/local/mysql/bin/mysqladmin -u root password '원하는대로' 여기서 패스워드 설정을 한다.
mysql을 실행시키고 로그인한다.
pkill mysqld