오늘은 곧 나올 책에 대한 간단한 훑어보기를 진행했다. 실질적인 코드를 작성하고 기술에 대한 학습을 진행했다기보단, 초 간단한 CS 지식과 자바에 대한 부분.. 그러니까 책 전반부를 보았다. 200p 정도 본 듯 한데, 전체 책 분량의 1/3정도이다.
전반적으로 내용이 굉장히 좋았다! 아직 실습 부분은 진행해보지 않아서 모르지만(과제 따라치면서 또 오지게 삽질할수도^^;;)
아래 내용은 꼭 책에 나오지 않았더라도, "신입 자바 개발자 면접"을 주제로 검색하면 자주 나오는 내용이므로 블로그 토픽으로 쭉 작성해본다.
1. 자바
IDE와 소스코드 편집기의 차이는?
IDE는 통합 개발 환경을 의미하며, 기본적인 소스코드 편집 기능 이외에 프로젝트 빌드, 실행, 디버깅, 의존성 관리 등 프로젝트 구현의 전반적인 과정을 도와주는 도구입니다. 소스코드 편집기는 조금 더 편한 소스코드 작성 및 편집을 위해 기본적으로 제공되는 기능(indent 등)을 제공합니다.
IDE가 소스코드 편집기보다 조금 더 넓은 개념입니다.
다른 프로그래밍 언어와 비교되는 자바의 특징은?
자바는 기본적으로 컴파일 언어로 분류되지만, 다른 컴파일 언어와는 다릅니다. C 같은 언어는 컴퓨터에서 구동시키기 위해 컴퓨터 운영체제에 특화된 컴파일러가 필요합니다. 해당 컴파일러가 컴파일 과정을 통해 OS에 맞는 바이너리 실행 파일을 만들고서야 비로소 실행이 가능한데, 해당 실행 파일은 다른 운영체제나 아키텍처 하드웨어에선 동작하지 않습니다.
이에 비해 javac에 의해 컴파일된 자바 클래스 파일은 JVM이 설치된 컴퓨터라면 어디서든지 동작합니다. 따라서 각각의 OS에 특화된 컴파일러가 필요하지 않으며, 이러한 자바의 특성을 보고 "이식성이 높다"라고 말합니다.
또한 메모리 관리에도 차이점이 있는데, C와 같은 언어의 경우 malloc()을 통해 동적으로 할당된 메모리는 개발자가 코드 내에서 꼭 free()를 시켜줘야 합니다. 그러나 new를 통해 할당된 자바 힙 메모리의 경우, 개발자가 해당 메모리 공간을 해제시켜주지 않아도 자바의 GC가 더이상 쓰이지 않는 메모리 공간을 해제해줍니다. 자바는 이렇게 개발자가 직접 메모리를 관리하지 않아도 된다는 편의성을 제공합니다.
객체 지향 프로그래밍이란?
객체 지향 프로그래밍이란, 프로그램을 "책임을 가진 객체들의 협력"으로 구성하는 프로그래밍 패러다임입니다. 객체 지향 프로그래밍에서는 각자의 기능과 그 기능을 수행하기 위한 메소드 및 필드들을 가진 객체들이 서로 메세지를 주고받으며 프로그램의 기능을 완성하는데요.
대표적인 특성으로는 캡슐화, 추상화, 상속, 다형성이 있습니다.
정의된 로직을 수행하는 상세한 과정이나, 해당 로직을 수행하기 위해서 가지는 내부 필드 값을 외부에 드러내지 않는 것이 캡슐화입니다. 객체의 캡슐화를 통해 최소한의 정보만 외부에 드러냄으로써, 객체 내부가 변해도 외부에 변화의 전파를 최소화할 수 있습니다.
추상화는 상위 인터페이스를 통해 구현됩니다. 모든 값들과 메소드 동작 과정이 상세하게 구현되고 정의된 하위 클래스 대신, 잘 변하지 않는 메소드 시그니처만 정의된 상위 인터페이스를 두어 해당 인터페이스의 구현체를 추상화시킵니다.
상위 인터페이스나 클래스를 상속한 하위 클래스 혹은 구현체를 알지 못해도, 다형성이라는 객체지향의 특성 덕에 클라이언트 코드는 추상화된 객체에 요청을 보내고 기대한 값을 전달받을 수 있습니다.
이러한 특성을 바탕으로 객체 지향 프로그래밍은 내부 변화의 전파를 최소화하고, 느슨한 결합을 통해 유연한 로직 설계를 달성할 수 있습니다.
오버라이딩과 오버로딩의 차이?
오버라이딩은 상위 클래스의 메소드를 하위 클래스에서 재정의하는 것입니다. 오버로딩은 같은 이름을 가진 메소드를 인자의 타입과 개수에 따라 여러 개를 정의하는 것입니다.
2. 서버와 클라이언트
프로토콜이란?
프로토콜이란 하나의 "약속"입니다. 네트워크에 참여하는 참여자들이나, 어떤 기능을 위해 협력하는 여러 구성요소는 목적을 달성하기 위해 서로가 협력할 형식을 정하는 과정이 필요합니다. 어떤 포맷으로 데이터를 주고받을지, 그 길이는 어떻게 정할 것인지 등입니다. 해당 과정을 통해 정의된 약속, 규칙이 바로 프로토콜인 것입니다. 네트워크 프로토콜엔 대표적으로 HTTP(S), TCP, UDP, IP 등이 있습니다.
브라우저에 www.google.com을 ~~
- 일단 브라우저가 문자열을 파싱해서 일반 단어에 대한 검색인지 URL 요청인지 확인한다.
- local host 파일을 통해 해당하는 IP 주소를 찾는다.
- local에 없으면 가까운 DNS 서버에 순차적으로 com -> google -> www 하위 도메인 순으로 IP 주소를 검색해 웹 서버의 IP 주소를 받는다.
- 해당하는 IP 주소의 80번 포트로 HTTP GET 요청을 보낸다.
- TCP 핸드셰이킹이 일어나고, 세그먼트에 포트 번호가 붙고, 패킷에 IP 주소가 붙고, 프레이밍 된 데이터가 다시 서버로 간다.
- 구글 서버는 사용자의 요청을 처리해 HTML, CSS, JS를 구성하고 이를 HTTP 응답 메세지에 담는다.
- 서버 측에서 같은 과정이 반복되어 우리의 컴퓨터로 보내진다.
TCP와 UDP
커찮아져서 걍 반말씀
둘은 모두 TCP/IP 4계층에서 3계층 전송 계층의 프로토콜이다. 각각의 PDU 헤더에 출발지와 목적지의 IP 주소가 적혀있으며, 패킷 혹은 데이터그램이 목적지 컴퓨터까지 도착할 수 있도록 하는 역할을 한다.
TCP는 신뢰성 있는 프로토콜로, 송신측에서 보낸 데이터가 수신측에 순서대로 손실없이 잘 도착하는 것을 보장한다. 이를 위해 통신 시작 전후로 handshaking 과정을 거치고 헤더의 sequence number, acknowledge number 등을 이용한다. 네트워크 상태가 혼잡할때를 대비한 혼잡 제어를 위한 헤더 정보도 존재한다. 데이터의 손실이 없긴 하지만, 전반적인 통신이 느리고 HOL 블로킹이 생긴다는 단점이 있다.
UDP는 TCP와 달리 수신측에 데이터가 제대로 도착했는지 확인하지 안고, 보내는 쪽에서 일방적으로 데이터그램을 뿌릴 뿐이다. 가상회선 방식으로 동작하는 TCP와 달리 UDP는 각 데이터그램이 각각의 라우팅을 통해 수신측에 도착하며, 이때 데이터의 도착 순서나 유실 여부는 상관하지 않는다. 일반적으로 TCP보다 전송이 빠르지만 데이터 유실 위험이 있어서, 데이터의 정확성 대신 빠른 전송이 요구되는 실시간 스트리밍 서비스 등에서 사용된다.
공인IP / 사설IP
공인IP는 전세계 단위의 네트워크에서 사용할 수 있는 IP 주소로, IP주소인만큼 유일하다. IPv4 기준으로 40억개 정도 되는 개수를 가지는데, 전세계 모든 네트워크 기기를 표현하기 위해선 부족한 숫자라 사설 IP와 같이 사용된다.
사설 IP는 하나의 네트워크부, 그러니까 하나의 공인IP 내부 네트워크에서 사용하는 IP주소로, 그 내부에서만 유효하다.
하나의 공유기가 존재하는 가정집을 예시로 들어보면, 하나의 공인 IP를 가진 공유기에 컴퓨터나 스마트폰 등 여러 개의 네트워크 기기들이 연결되고, 각 네트워크 기기들은 해당 공유기를 사용하는 내부 네트워크에서만 유효한 사설 IP를 갖는 것이다.
HTTP / HTTPS
HTTP 요청/응답 메세지가 평문인 HTTP와 다르게 HTTPS는 HTTP 메세지를 암호화한다. 이 때 "비대칭키 암호화를 통한 대칭키 교환" 과정을 거친다. HTTP는 80번 포트를, HTTPS는 443번 포트를 사용한다.
3. 프레임워크
스프링 프레임워크 / 스프링 부트
스프링 프레임워크는 자바로 웹 어플리케이션 개발을 할 수 있도록 해주는 프레임워크이다. 그러나 스프링 자체만으로는 어플리케이션 개발을 위해 설정해야하는 의존성의 상세 정보와 버전이 매우 많고, 프레임워크에 사용할 톰캣 등의 WAS를 직접 구성해야 한다는 번거로움이 있었다.
스프링부트는 이러한 스프링의 번거로움을 개선한 것으로, 전반적으로 많이 사용되는 의존성 구성과 버전을 auto configuration을 통해 개발자가 각각을 상세히 설정할 필요 없이 개발을 할 수 있도록 도와준다.
프레임워크 / 라이브러리
프레임워크는 프레임워크를 통한 기능 구현을 위해 개발자들이 개발해야 하는 것들을 정의한다. 개발자들은 자신이 구성하고 싶은 기능, 혹은 비즈니스 로직들을 프레임워크에서 정의한 방식과 프레임워크가 제공하는 기능 및 함수들을 통해 구현한다.
라이브러리는 개발자가 특별한 기능을 구현하기 위해 이용하는 하나의 "도구"이다.
URI / URL
URI는 Uniform Resource Identifier의 약자로, 웹에서 사용하는 리소스를 구별해주는 역할을 한다. URL은 그런 URI의 역할을 수행하는 것들 중 하나로, Uniform Resource Locator의 약자이다. "Locator"의 말 그대로, URL은 웹에서 해당 자원이 존재하는 위치를 통해 해당 자원을 구분한다. 기본적으로 프로토콜을 표현하는 scheme, IP주소(혹은 도메인), 포트번호, path로 표현된다.
추가로 URN은 자원 각각이 가진 고유의 ID 정도로 생각할 수 있다.
CDN
Contents Delivery Network의 약자로, 규모가 큰 서비스에서 정적 리소스를 응답하기 위해서 사용된다. 리소스에 대한 사용자의 요청이 매우 많이 몰리는 서비스에서, 정적 리소스를 모두 웹 서버가 직접 응답하는데엔 서버의 자원이 많이 소모된다. 응답 시간도 길어질테니 사용자 역시 부정적 경험을 할 확률이 높다. CDN은 정적 리소스에 대한 응답에 특화된 구조로 사용자의 리소스 요청에 응답하여 자원절약 및 latency 개선을 이뤄낸다.
언제나와 같이 쿨하게 끝내려고 했는데 벌써 66일 !!! 헐.. 이게 끝나긴 끝나는구나. 사실 그동안 반강제적으로 했던 것도 어느정도로 있었는데(2달 조금 넘는 기간동안 매일매일 불타오르는 감정과 학구열로 참여할 수는 없으니까요^^), 그래도 지금 생각해보면 2달 전의 나와 지금의 나는 많이 달라졌다는 생각이 든다.
