굳건하게

안녕하세요, 여행벌입니다.

감사하게도 2022 카카오 신입 공채 (카카오 Programming)에 합격을 했습니다. 

전형별로 제가 느낀 후기랑 어떻게 준비했는지 정리해보도록 하겠습니다.

1. 1차 코딩테스트

개인적인 생각으로 카카오는 네카라 회사 중에 가장 알고리즘 능력을 중요시하는 것 같습니다. 1차 코딩 테스트에서 다른 회사에 비해 깊은 알고리즘 문제도 출제합니다. 보통 7문제가 출제되고 4문제에서 커트라인이 형성되는 것 같습니다. 지금까지 공채 기출을 보면 6번, 7번 문제는 알고리즘 경시대회 준비할 때 풀었던 수준으로 굉장히 높은 수준이고, 1번부터 5번까지는 풀만한 수준인 것 같습니다. 5문제는 꼭 푼다는 마인드로 도전하면 좋을 것 같습니다! 가장 좋은 점은 카카오 코테는 채점 결과를 바로바로 확인할 수 있기 때문에 제대로 풀었는지, 놓친 사이드 테케가 있는지 확인할 수 있습니다.

저는 이번에 5.5 솔브를 했고 통과할 수 있었습니다. 작년에 지원했을 때 6솔을 했었는데 이번 문제가 조금 더 어려웠던 것 같습니다. 1차 코딩테스트는 잘 보면 잘 볼수록 뒤에 전형을 진행하는데도 유리하다고 생각합니다. 프로그래머스 사이트에서 카카오 공채 기출들을 모두 풀어볼 수 있으니 꼭꼭! 풀어보시길 추천드립니다.

https://programmers.co.kr/learn/challenges

2. 2차 코딩테스트

2차 코딩 테스트는 우리가 흔히 알고 있는 코딩 테스트와 다른 방식으로 진행됩니다. API 호출을 통해 정보를 받아와야 되고, 그 정보를 기반으로 API 호출을 통해 자신만의 알고리즘을 동작시켜야 됩니다. 따라서, API 호출 및 Json 형태의 데이터를 파싱하는 코드를 미리 작성하는 것이 유리합니다. 미리 작성한 코드를 코테에서 사용할 수 있으므로 꼭 꼭!! 필요한 코드를 작성해두시길 바랍니다.

마찬가지로, 프로그래머스에서 2차 코딩 테스트 기출을 동일한 환경에서 풀어볼 수 있습니다. 저는 카카오 2차 코테를 처음 치러보기 때문에 프로그래머스에서 기출을 3번 정도 풀어보면서 API 호출 및 Json 데이터 파싱하는 코드를 미리 작성했습니다. 1차 코테는 C++로 치렀지만, API 호출 및 Json 데이터 파싱을 위해 2차 코테는 Java로 지원했습니다. 

이번 2차 코테는 크게 매칭, 등급 조정하는 2가지 알고리즘을 작성해야 했습니다. 저는 2가지 알고리즘을 가장 단순하게 만든 V1부터 알고리즘을 돌려보며 점수를 모니터링했고, 계속 리팩토링해서 V6까지 만들었습니다. 또, 2차 코테는 실시간으로 랭킹을 확인할 수 있습니다. 다른 상위권 분들이 어느 부분에서 점수를 많이 획득했는지 확인해가며 제 알고리즘을 맞춰서 수정했습니다. 그 결과, 400등대로 2차 코테를 마무리했던 것 같습니다.

!꿀팁!

기술 면접에서 2차 코딩테스트 코드 리뷰를 진행하기 때문에, 코딩 테스트지만 구조화를 잘하시면 좋을 것 같습니다. 저는 MVC 패턴과 유사하게 코드를 구현했고, API 호출을 Controller 패키지에서 처리하고, Json 데이터 파싱은 Model 패키지에서 처리하고, 핵심 알고리즘은 Service 패키지에서 처리하도록 구조화했습니다. 이 부분을 면접에서 굉장히 좋게 평가해주셨고 합격할 수 있었던 포인트 중에 하나이지 않을까 싶습니다.

https://programmers.co.kr/

3. 기술면접

기술면접은 크게 2차 코딩테스트 리뷰, 기초 CS 지식, 이력서 기반 질문으로 나눌 수 있을 것 같습니다. 2분의 면접관님과 1시간 정도 면접을 진행했습니다.

면접 분위기는 카카오답게 정말 좋았습니다. 카카오 면접은 '면접관이 지원자를 심사하는 것이 아니라 지원자가 그동안 쌓아온 역량을 선배 개발자에게 자랑하는 자리'라고 표현할 수 있을 것 같습니다.

코딩테스트 리뷰

면접관님이 2차 코딩테스트 문제를 다시 화면 공유해주시며 기억을 되살려 주십니다. 저는 이미 2차 코테 코드를 한 번 정리하고 면접을 들어갔던 상황이라 바로 2차 코테 코드 리뷰를 진행했습니다. 어떤 아이디어를 가지고 2차 코딩 테스트를 진행했는지 질문을 해주셨고, 최종 점수를 얻기까지 어떤 아이디어로 계속 리팩토링을 해왔는지 설명드렸습니다. V1부터 스코어보드와 비교해가며 리팩토링을 진행한 점을 좋게 봐주셨고, 코드 구조화 부분에서 칭찬을 들을 수 있었습니다.

기초 CS 지식

자세한 내용은 다룰 수 없지만 정말 정말 기초 CS 지식에 대해서 물어보셨습니다. 네이버, 라인 면접과 달리 기본적인 CS 지식을 많이 여쭤보셨습니다. 같이 기술 면접을 준비했던 친구들과 얘기해봐도 모두 기초 CS 지식수준에서 질문을 받았습니다. 대학생(취준생)이 답을 할 수 있는 수준에서 질문을 해주시는 만큼 겁먹지 말고 그동안 공부해 온 운영체제, 네트워크, 데이터베이스, 알고리즘과 자료구조를 다시 한번 정리하면 면접 준비하는데 큰 도움이 될 것 같습니다. 질문이 쉬운 만큼 답을 못하면 감점이 크지 않을까 싶습니다. 저는 운 좋게도 모든 질문에 대해 다 대답할 수 있었습니다.

이력서 기반 질문

이력서에 기재한 프로젝트에 대해 질문을 해주셨습니다. 프로젝트를 진행한 이유, 사용한 기술 스택에 대해서 잘 알고 계시면 될 것 같습니다. 다른 회사들은 분산 처리나 스케일 아웃에 대해서 많이 질문이 들어왔는데 카카오는 취준생 입장에서 경험하기 어려운 부분에 대해서는 질문을 하지 않아 주셔서 면접을 진행하기 편했습니다.

4. 최종면접

최종 면접도 기술 면접과 동일하게 2분의 면접관님과 진행했습니다. 이력서 기반으로 질문을 해주셨고, 카카오 회사와 지원자가 잘 맞는지 판단하는 시간이었던 것 같습니다. 면접은 40분 동안 진행한다고 안내받았지만 저는 20분 정도 진행하고 두 분 모두 더 질문할 부분이 없다고 하셔서 짧게 끝났던 것 같습니다.

면접관님이 저의 Git과 블로그를 모두 직접 보고 오신 점이 인상 깊었고, 어떤 개발자가 되고 싶은지, 어떤 프로젝트를 해왔는지, 카카오에서 어떤 일을 하고 싶은지에 대해서 편한 분위기에서 얘기할 수 있었습니다.

이번 포스팅에서는 2022 카카오 블라인드 공채 후기를 정리해보았습니다.

더 궁금하신 점이나 조언을 구하시고 싶은 분은 댓글에 남겨주시면 답변드리도록 하겠습니다 :))

안녕하세요, 여행벌입니다. 정말 오랜만에 (1년 만에) 글을 다시 써보려고 합니다.

올해 하반기에 취업 시장에 뛰어들어야 되는 시기가 되다 보니 블로그 포스팅을 못했던 것 같습니다.

감사하게도 이번 첫 취준에서 네이버웹툰에 합격할 수 있었습니다.

네이버웹툰은 지금까지 인턴으로 신입 개발자를 뽑다가 처음으로 공채를 연 것이라 준비할 때 정보가 없어서 막막했던 기억이 나네요.

자세한 내용은 다루지 못하지만 어떤 방식으로 공채가 진행되고, 저는 어떻게 준비했었는지 제 기준에서 공유해보도록 하겠습니다.

1. 서류와 코딩테스트

당연히 네카라답게 코딩테스트를 뚫어야됩니다. 네이버웹툰은 코딩테스트 결과와 서류를 같이 판단해서 합/불 결과를 알려줬습니다. 코딩 테스트는 서버 직군은 '자바' 만 지원해줬던 것으로 기억나네요. IDE 도 사용이 불가능해서 프로그래머스에서 바로 코딩을 했고 자바 레퍼런스는 지원을 해준 것으로 기억합니다. 평소에 C++ 로 알고리즘을 풀다 보니 자바 언어가 살짝 부담스럽게 느껴졌지만 문제가 어렵게 나오지 않아 올솔브를 했던 것 같습니다. ( 채점을 해주는 것이 아니라 정확하지는 않습니다...!! ) 문제가 어렵게 느껴지지는 않았고 프로그래머스 기준으로 Lv2 ~ Lv3 문제들을 '자바' 로 풀 수 있으면 문제없지 않을까 싶습니다.

2. 기술면접 

네이버웹툰 채용 절차에서 가장 어려운 구간이 아닐까 싶습니다. 면접을 3시간을 진행하고 면접 중에 라이브로 코딩 테스트를 진행합니다.... 처음 안내받았을 때 내가 메일을 잘못 본 것이 아닐까... 싶을 정도로 3시간에 라이브 코테는 어떤 방식으로 준비해야 될지 감이 안 잡혔던 것 같습니다.

면접은 1시간씩 3번 진행됩니다. 일대일 면접으로 시간이 되면 면접관님이 한 분씩 들어오십니다. 면접 진행 방식은 면접관님들마다 조금씩 차이가 있었는데, 라이브 코테를 먼저 보시고 기술 질문을 하시는 분도 계셨고, 기술 질문을 하시다가 라이브 코테를 보시는 분도 계셨습니다. 평균 라이브 코테 25분, 기술 질문 25분 마지막 어필 5분 쉬는 시간 5분으로 진행이 된 것 같습니다.

라이브 코테는 알고리즘과 DB 테이블 설계 질문을 해주셨는데 어렵지 않았습니다. 개인적인 생각으로 1차 코테와 서류를 뚫으신 분들이라면 라이브 코테에서 못 풀 문제는 없다고 생각합니다. 그만큼 기본적인 구현 문제들을 내주셨습니다. 긴장하지 않는 게 중요한 것 같습니다! 또, 라이브 코딩 특성상 면접관님들이 코딩하는 것을 보고 계시기 때문에 저는 변수명이랑 메소드로 기능을 빼는 부분에 신경을 많이 썼던 것 같습니다. ( 아마 이런 부분이 면접관님이 보기에 좋게 보이지 않았을까요....?? )

기술 질문은 굉장히 어려웠습니다. 그만큼 너무 어려웠고 부족한 부분을 많이 느꼈던 면접이었습니다. 생전 처음 들어보는 기술에 대한 질문도 많았고 기초 CS 지식도 되게 깊게까지 물어보셨습니다. 이번 하반기에 경험했던 카카오, 라인, 토스 통틀어 가장 어려웠던 기술 면접인 것 같습니다. 모르는 부분은 솔직하게 모른다고, 아직 공부 안 해봤다고 말씀드렸고 아는 부분은 최대한 밑바닥까지 다 말씀드렸습니다.

!꿀팁!

기술 면접을 준비할 때 하나의 키워드에 대해 깊게까지 정리해보시는 것을 추천드립니다! 예를 들어, HTTPS 동작 원리에 대해서 나름 깊게 이해하고 있다고 생각하고 설명드렸는데 'HTTPS를 이용하면 HTTP 메시지 헤더, 바디가 모두 암호화되는가?? 패킷을 까보면 어느 정보들이 암호화되어 있는가??' 를 추가로 물어보셨습니다. 당연히 답변을 못 드렸고 그런 부분까지 공부를 해야 된다는 조언을 받았던 기억이 나네요...

특히 두 번째 면접관님의 질문은 대부분 처음 들어보는 용어들이라 대답을 거의 못했습니다. 면접을 보고 나서 내가 그동안 공부를 잘못해왔나... 모르는 게 왜 이렇게 많지...라는 체념에 빠져서 바로 친구랑 술을 마셨던 기억이 나네요.... 그래도 붙었으니... 첫 신입 공채라 면접 질문 수준이 너무 높았던 게 아닐까 추측해봅니다...!!! 내년에 네이버웹툰 신입 공채에 지원하시는 분들도 기술 면접보고 너무 상심하지 말고 아는 부분에 대해서 최대한 잘 어필하시면 좋을 것 같습니다!

3. 최종면접

당연히 떨어진 줄 알았던 기술 면접에 합격하고 마지막 최종 면접 기회가 주어졌습니다.

`CTO 찬규`님과 1시간 면접을 진행하고, `HR Lead` 님과 30분 면접을 진행하는 방식이었습니다. 대표님이신 찬규님이 직접 1시간씩 면접을 진행하다는 점이 정말 인상 깊었고, 개발자를 중요시 여기는 회사라는 것을 느낄 수 있었습니다. 또, 면접 중에 '대표님' 이라는 표현 대신 '찬규님' 이라고 불러달라고 하신 부분에서도 수평적인 문화를 느낄 수 있었습니다.

찬규님과의 1시간 면접은 정말 만족감이 높았던 면접입니다. '나'라는 사람에 대해서 굉장히 궁금해하셨고, 그 궁금증을 해결해드리는 방식으로 면접이 진행되었습니다. 왜 수학과에 진학했는지, 늦은 나이에 왜 개발자를 꿈꾸기 시작했는지, 그중에 왜 서버 개발자를 선택했는지, 많은 기술 스택 중에 왜 스프링 공부를 시작했는지, JPA는 왜 공부를 시작했는지, 비전공자로 힘들지는 않았는지, 프로젝트는 왜 진행했는지 등등 타임라인 순으로 제 인생에 대해서 궁금해하셔서 정말 재미있게 면접을 진행했습니다. `HR Lead`님과의 면접도 굉장히 편안한 분위기 속에서 나는 이런 사람이에요!라고 제 자신을 표현하면서 면접을 진행했습니다. 두 분 모두 지원자를 굉장히 배려해주시는 분위기였습니다.

저는 이력서를 한 번 더 읽어보고 내가 왜 네이버웹툰에 입사하고 싶은지, 나의 강점은 무엇인지를 혼자 정리하면서 준비를 했습니다. 비전공자에 배포 경험도 없고, 플젝도 개인 플젝 1개가 전부인 상태였기 때문에 다른 지원자들에 비해 경험이 많이 부족할 것이라고 판단했습니다. 그래서, '경험은 부족하지만 비전공자라 개발자가 되기 위해 능동적으로 이렇게 학습해왔습니다!!!!' 를 저의 강점으로 뽑고 어필하려고 노력 했습니다. 또, 내가 네이버웹툰 서비스를 얼마나 오래 이용해왔고, 애정을 가지고 있는지를 면접 때 표현하려고 노력을 많이 했습니다.

최종 면접 준비는 네이버 웹툰이 나랑 잘 맞는 회사인가?? 네이버 웹툰에 합류해서 어떤 개발자가 되고 싶은가?? 를 판단하는 시간이었던 것 같습니다. 나는 어떤 사람인지, 왜 내가 네이버 웹툰에 오고 싶은지를 머릿속에서 명확히 정리했고, 면접 때 큰 도움이 됐던 것 같습니다.

4. 여담

개인적으로 결과 발표가 늦어지면 늦어진다고 안내를 해주는 점이 굉장히 취준생 입장에서 좋았습니다. 이번에 처음으로 취준을 하다 보니 10개가 넘는 회사에서 코테가 잡히고, 면접들이 잡히니까 하나하나 기다리고 일정 체크하기가 힘들었는데 네이버웹툰에서는 지원자들을 배려해주는 느낌을 많이 받았습니다.

정말 오랜만에 블로그에 포스팅을 하는 것 같네요.

저처럼 네이버웹툰에 들어오고 싶은 분들에게 이 글이 도움이 되면 좋을 것 같습니다!

아직 입사하기 전이지만 면접을 진행하면서 회사에 대한 애사심이 많이 생겼던 것 같습니다.

더 궁금하신 점은 댓글로 남겨주시면 답변드리도록 하겠습니다 :))

안녕하세요, 여행벌입니다.

오늘은 가상호스트, 프록시, 게이트웨이, 터널에 대해서 정리해보겠습니다.

[ 가상호스트 (Virtual Host) ]

 HTTP/1.1 부터 하나의 HTTP 서버에 여러 개의 웹 사이트를 띄우는 가상 호스트 기술이 가능해졌다. 즉, 하나의 웹 서버로 여러 웹 사이트를 운영할 수 있다. 같은 IP 주소에서 다른 호스트명과 도메인 명을 가진 여러 개의 웹 사이트가 실행되고 있으므로 HTTP 리퀘스트를 보내는 경우에 호스트명과 도메인 명을 완전하게 포함한 URI를 지정하거나, 반드시 Host 헤더 필드에서 지정해야 한다.

naver.com / mail.naver.com / comic.naver.com 는 모두 같은 IP 주소(네이버가 운영하는 서버) 지만 호스트명, 도메인 명을 다르게!!

[ 프록시 (Proxy) ]

 서버와 클라이언트의 양쪽 역할을 하는 중계 프로그램으로, 클라이언트로부터의 리퀘스트를 서버에 전송하고, 서버로부터의 리스폰스를 클라이언트에 전송한다. 서버와 클라이언트 사이에 중계기로서 대리로 통신을 수행하는 것을 프록시, 그 중계 기능을 하는 것을 프록시 서버라고 부른다.

 주로 보안을 위해 사용되어 모든 웹 트래픽 흐름 속에서 신뢰할 만한 중개자 역할을 해준다. ( 회사 내부망에서 외부로 요청하는 내용들이 신뢰할만한 요청인지 프록시에서 확인해 액세스 제한 등을 할 수 있다. )

[ 게이트웨이 (Gateway) ]

 게이트웨이도 프록시와 마찬가지로 서버와 클라이언트의 중계 역할을 하는 프로그램이다. 게이트웨이의 경우에는 리퀘스트를 전달하는 서버가 HTTP 이외의 서비스를 제공하는 서버다. 즉, HTTP 트래픽을 다루는 다른 프로토콜로 변환하기 위해 게이트 웨이를 사용한다. 또, 클라이언트와 게이트웨이 사이를 암호화하는 등으로 안전하게 접속함으로써 통신의 안전성을 높이는 역할도 한다.

[ 터널 (Tunnel) ]

 터널은 요구에 따라서 다른 서버와의 통신 경로를 확립한다. 이때, 클라이언트는 SSL 같은 암호화 통신을 통해 서버와 안전하게 통신을 하기 위해 터널을 사용한다. 터널 자체는 HTTP 리퀘스트를 해석하려하지 않고 그냥 다음 서버로 중계한다.

안녕하세요, 여행벌입니다.

오늘은 클라이언트의 요청에 따른 응답 상태를 나타내주는 상태코드에 대해서 정리해보도록 하겠습닏.ㅏ

[ HTTPNetwork 상태코드 ]

상태코드는 클라이언트가 보낸 요청의 처리 상태를 리스폰스에서 알려주는 기능입니다. 상태코드를 통해 서버가 리퀘스트를 정상적으로 처리했는지, 결과가 에러였는지를 알 수 있습니다.

[ 1xx (Informational) ]

100번 대 상태코드는 "요청이 수신되어 처리중"이라는 뜻으로 거의 사용되지 않습니다.

[ 2xx (Success) ]

200번 대 상태코드는 "리퀘스트를 정상적으로 처리했음" 이라는 뜻입니다.

• 200 OK

  클라이언트가 보낸 리퀘스트를 서버가 정상 처리한 상황입니다. 리스폰스에서 상태 코드와 함께 되돌아 오는 정보는 메소드에 따라 다르고, GET 메소드의 경우에는 리퀘스트 된 리소스에 대응하는 엔티티가 보내지고, HEAD 메소드의 경우에는 리퀘스트된 리소스에 대응하는 엔티티 헤더 필드가 메시지 바디를 동반하지 않고 되돌아옵니다.

• 201 Created

  클라이언트가 보낸 리퀘스트를 서버가 정상 처리하여 새로운 리소스가 생성된 상황입니다. 생성된 리소스는 리스폰스의 Location 헤더 필드로 식별해줍니다.

• 202 Accepted

  클라이언트가 보낸 리퀘스트가 접수되었으나 아직 처리가 완료되지않은 상황입니다. 배치 처리 같은 곳에서 사용되는 코드입니다.( 요청 접수 후 1시간 뒤에 요청을 처리하는 배치 프로세스 등 )

• 204 No Content

  서버가 리퀘스트를 받아서 처리하는데 성공했지만 리스폰스에 보낼 데이터가 없어서 엔티티 바디를 포함하지 않는 상황입니다. 클라이언트에서 서버에 정보를 보내는 것으로 족하고, 클라이언트에 대해서 새로운 정보를 보낼 필요가 없는 경우에 사용됩니다.

• 206 Partial Content

  Range에 의해서 범위가 지정된 리퀘스트에 의해서 서버가 부분적 GET 리퀘스트를 받은 상황입니다. 리스폰스에는 Content-Range로 지정된 범위의 엔티티가 포함되게 됩니다.

[ 3xx (Redirection) ]

300번 대 상태코드는 "요청을 완료하기 위해 유저 에이전트의 추가 조치가 필요함" 이라는 뜻입니다. 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동합니다.

• 301 Moved Permanently ( 영구 리다이렉션 )

  리퀘스트된 리소스의 URI 가 영구적으로 변경된 상황입니다. 원래의 URL 를 사용하면 안되고, 새로운 URI를 사용해야한다는 것을 나타내고 있습니다. 리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있습니다.

• 308 Permanent Redirect ( 영구 리다이렉션 )

  301과 기능 면에서는 동일하나 리다이렉트시 요청 메서드와 본문을 유지해준다. 즉, POST 로 처음에 요청을 보내면 리다이렉트시에도 POST를 유지해준다.

• 302 Found ( 일시적인 리다이렉션 )

  리퀘스트된 리소스의 URI가 변경되어있기 때문에 새로운 URI를 참조해 주길 바란다는 의미로 301과 달리 영구적으로 변경된 상황이 아니라 이동하는 곳의 URI는 앞으로도 이동 가능성이 있습니다. 리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있습니다.

• 303 See Other ( 일시적인 리다이렉션 )

  302와 기능 면에서는 동일하나 리다이렉트시 요청 메서드가 무조건 GET으로 변경됩니다. 즉, 리퀘스트에 대한 리소스는 다른 URI에 있기 때문에 GET 메소드를 사용해서 얻어야 한다는 뜻입니다.

• 307 Temporary Redirect ( 일시적인 리다이렉션 )

  302와 기능 면에서는 동일하나 리다이렉트시 요청 메서드와 본문을 유지해야됩니다. 즉, POST로 요청할 시 POST로 리다이렉트 해줍니다.

처음 302 스펙의 의도는 HTTP 메서드를 유지하는 것이였으나 웹 브라우저들이 대부분 GET 으로 바꾸어버렸다.

--> 모호한 302를 대신하는 명확한 303, 307이 등장!

• 304 Not Modified

  클라이언트가 조건부 리퀘스트를 했을 때 리소스에 대한 액세스는 허락하지만, 조건이 충족되지 않음을 표시합니다. 304를 되돌려 줄 경우에는 리스폰스 바디에 어떤 것도 포함되어 있어서는 안됩니다. 캐시를 목적으로 사용되고 3xx에 분류되어 있디만 리다이렉트와는 관계가 없습니다.

참고!

301, 302 상태코드의 사양은 POST 메소드를 GET 메소드로 바꾸는 것을 허용하지 않았지만 대부분의 브라우저가 그렇게 구현을 해놓아서, GET 으로 변하고 본문이 제거될 수 있다고 스펙이 변경되었습니다.

[ 4xx (Client Error) ]

400번 대 상태코드는 클라이언트의 원인으로 에러가 발생했음을 나타냅니다. 클라이언트의 요청에 잘못된 문법이 포함되어있는 등 오류의 원인이 클라이언트에 있는 상황입니다. 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에 재시도를 해도 똑같이 실패합니다.

• 400 Bad Request

  요청 구문, 메시지 등등 리퀘스트 구문이 잘못되었음을 나타냅니다. 이 에러가 발생한 경우, 리퀘스트 내용을 재검토해서 재송신해야합니다.

• 401 Unauthorized

  해당 리소스에 유효한 인증 자격 증명이 없기 때문에 요청이 적용되지 않았음을 나타냅니다. 401 오류 발생시 응답에 WWW_Authenticate 헤더와 함께 구체적인 인증 방법을 명시해줍니다.

• 403 Forbidden

  리퀘스트된 리소스의 액세스가 거부되었음을 나타냅니다. 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우에 발생하고 서버 측은 거부의 이유를 엔티티 바디에 기재해서 유저 측에 표시합니다. ( 로그인은 했지만, 내 계정 권한으로 접근할 수 없는 정보를 접근하는 경우 )

• 404 Not Found

  리퀘스트한 리소스가 서버 상에 없는 경우 혹은 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶은 경우에 발생합니다.

[ 5xx (Server Error) ]

500번 대 상태코드는 서버 문제로 오류가 발생했음을 나타냅니다. 서버에 문제가 있기 때문에 재시도하면 성공할 수도 있습니다.

• 500 Internal Server Error

  리퀘스트를 처리하는 도중에 서버 내부 문제로 오류가 발생한 경우입니다.

• 503 Service Unavailable

  서버가 일시적인 과부하 또는 예정된 작업으로 현재 리퀘스트를 처리할 수 없는 경우입니다. Retry-After 헤더필드로 얼마 뒤에 복구되는지 보낼 수 있습니다.

이상으로, Response StatusCode 정리를 마치겠습니다.

안녕하세요, 여행벌입니다.

오늘은 HTTP 프로토콜 메소드에 이어서 HTTP 프로토콜의 정보에 해당하는 메시지에 대해서 알아보겠습니다.

[ HTTP 메시지 ]

HTTP 프로토콜에서 교환하는 정보를 HTTP메시지라고 부릅니다. 리퀘스트 측 HTTP메시지를 리퀘스트 메시지, 리스폰스 측 HTTP메시지를 리스폰스 메시지라고 부르고 다음과 같은 형태를 유지한다.

시작라인 / 메시지헤더 / CRLF(개행) / 메시지바디 순으로 이루어져있으며 메시지바디는 없을 수도 있습니다. 저번 포스팅에서 다뤘던 GET 메소드는 대부분 메시지 바디가 없습니다.

• 시작 라인 : 시작라인은 리퀘스트에서는 리퀘스트라인, 리스폰스에서는 상태라인 이라고 불립니다.
  • 리퀘스트라인 : 리퀘스트에 사용하는 메소드 / 리퀘스트 URI / HTTP 버전이 포함.
  • 상태라인 : 리스폰스 결과를 나타내는 상태코드와 설명 / HTTP 버전이 포함.
• 헤더 필드 : HTTP 전송에 필요한 모든 부가정보가 담겨있는 곳으로, 리퀘스트와 리스폰스의 여러 조건과 속성 등을 나타내는 각종 헤더 필드가 포함됩니다.
• 바디 필드 : 실제 전송할 데이터를 담고 있는 필드로 HTML 문서, 이미지, 영상, JSON 등 byte로 표현할 수 있는 모든 데이터가 들어갈 수 있다.

[ HTTP 인코딩 ]

 HTTP로 데이터를 전송할 경우 그대로 전송할 수도 있지만, 인코딩을 실시함으로써 전송 효율을 높일 수 있습니다. 전송할 때 인코딩을 하면 CPU 등의 리소스는 많이 사용하지만 더 효율적으로 데이터를 전송할 수 있습니다.

• 메시지 : HTTP 통신의 기본 단위로 옥텟시퀀스(Octet sequence)로 구성되고 통신을 통해서 전송.
• 엔티티 : 리퀘스트랑 리스폰스의 페이로드(Payload, 부가물)로 전송되는 정보로 엔티티 헤더 필드와 엔티티 바디로 구성.

 HTTP 메시지 바디는 리퀘스트랑 리스폰스에 관한 엔티디 바디를 운반해줍니다. 인코딩을 한다는 것은 엔티티 정보를 인코딩을 해서 메시지 바디에 실어서 보낸다는 뜻입니다.

참고!

콘텐츠 코딩(Content Codings)

엔티티에 적용하는 인코딩을 가리키는 용어로 엔티티 정보를 유지한 채로 압축을 해줍니다. 콘텐츠 코딩된 엔티티는 수신한 클라이언트 측에서 디코딩을 해서 이용합니다.

[ 청크 전송 코딩(Chunked transfer Coding) ]

 HTTP 통신에서는 리퀘스트했었던 리소스 전부에서 엔티티 바디의 전송이 완료되지 않으면 브라우저에 표시되지 않습니다. 그래서 사이즈가 큰 데이터를 전송하는 경우에는 데이터를 분할해서 조금씩 브라우저에 표시하는 청크 전송 코딩을 이용해야합니다.

청크 전송 코딩은 엔티티 바디를 청크 단위로 분해해서 전송합니다.

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

 메일의 경우에는 메일의 본문이나 복수의 첨부 파일을 붙여서 함께 보낼 수 있습니다. MIME( Multipurpose Internet Mail Extensions, 다목적 인터넷 메일 확장 사양 ) 은 이미지, 텍스트, 영상 등 다양한 데이터의 바이너리 데이터를 아스키 문자열에 인코딩하는 방법과 데이터 종류는 나타내는 방법등을 규정하고 있습니다. 이 MIME 의 확장 사양에 있는 Multipart 라고 하는 여러 다른 종류의 데이터를 수용하는 방법을 HTTP 에서도 사용해 하나의 메시지 바디 내부에 엔티티를 여러 개 포함해서 보낼 수 있습니다.

multipart/form-data : Web 폼으로부터 파일 업로드에 사용됩니다.

multipart/byteranges : 상태코드 206 리스폰스 메시지가 복수 범위의 내용을 포함하는 때에 사용됩니다.

[ 레인지 리퀘스트(Range Request) ]

 HTTP 통신에서 커넥션이 끊어지게 되면 엔티티 정보를 처음부터 다시 전달받아야합니다. 따라서, 문제가 생겼을 때 이전에 전달받은 범위 뒤에서부터 전달을 다시 받는 레인지 리퀘스트가 등장했습니다. 이름 그대로 엔티티의 범위를 지정해서 해당 범위 만을 리퀘스트 하는 방법입니다.

[ 콘텐츠 네고시에이션(Content Negotiation) ]

 같은 콘텐츠(내용)이지만 여러 개의 페이지를 지닌 웹 페이지가 있습니다. ( 구글 영어판, 한국어판 ) 이러한 웹 페이지에서 같은 URI에 액세스할 때에 적절한 웹 페이지를 표시해주는 구조를 콘텐츠 네고시에이션이라 합니다.

콘텐츠 네고시에이션은 제공하는 리소스를 언어와 문자 세트, 인코딩 방식 등을 기준으로 적합한 리소스를 판단합니다.

Accept / Accept-Cahrset / Accept-Encoding / Accept-Language / Content-Language

참고

- 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식

- 그림으로 배우는 HTTP&Network Basic