siAhn

[Trouble Shooting][Spring] Locale이 왜 비어있지?

대흉근 — Sun, 23 Jun 2024 20:48:02 +0900

1. 배경 지식

LocaleResolver 인터페이스를 사용하면 서블릿 단에서 웹 요청과 응답에 관련된 locale 작업들을 다룰 수 있다.

This interface allows for implementations based on request, session, cookies, etc. The default implementation is org. springframework. web. servlet. i18n. AcceptHeaderLocaleResolver, simply using the request's locale provided by the respective HTTP header

Spring에서 해당 인터페이스의 기본 구현은 AcceptHeaderLocaleResolver 클래스다.

이 클래스는 HTTP 요청 헤더의 Accept-Language 값을 사용하여 사용자 locale 정보를 조회할 수 있는 기능을 제공한다.

LocaleResolver implementation that simply uses the primary locale specified in the Accept-Language header of the HTTP request (that is, the locale sent by the client browser, normally that of the client's OS).

LocaleContextHolder 클래스를 통해 세팅된 locale 정보를 조회하거나 조작할 수 있다.

Simple holder class that associates a LocaleContext instance with the current thread. The LocaleContext will be inherited by any child threads spawned by the current thread if the inheritable flag is set to true.
Used as a central holder for the current Locale in Spring, wherever necessary: for example, in MessageSourceAccessor. DispatcherServlet automatically exposes its current Locale here. Other applications can expose theirs too, to make classes like MessageSourceAccessor automatically use that Locale.

2. 상황

클라이언트에서 요청을 보낼 때 Accept-Language 헤더와 값을 보내주고 있다.

서버에서는 사용자의 locale 정보가 필요한 곳에서 해당 헤더 값을 사용하고자 했다.

Accept-Language 헤더가 존재하지 않는 경우 default locale을 설정하고자, 설정 클래스에서 아래와 같은 bean 정보를 구성했다.

@Bean
LocaleResolver localeResolver() {
    AcceptHeaderLocaleResolver localeResolver = new AcceptHeaderLocaleResolver();
    localeResolver.setDefaultLocale(Locale.KOREA);
    return localeResolver;
}

그리고 비즈니스 로직에서 LocaleContextHolder 클래스의 getLocale() 메서드를 통해 사용자 locale을 조회한다.

Locale locale = LocaleContextHolder.getLocale();
String languageCode = locale.getLanguage();

개발 환경에서 아래 항목들을 테스트해 보았고, 의도한 대로 동작하는 것을 확인하여 운영 환경에도 배포를 진행했다.

Accept-Language 헤더가 존재하지 않으면, default locale(한국)이 세팅되어야 한다.
Accept-Language 헤더가 존재하면, 해당 값이 세팅되어야 한다.
1, 2번에서 세팅된 locale 정보는 LocaleContextHolder.getLocale()으로 조회 가능하며, 늘 존재한다.

3. 이슈 발생

LocaleContextHolder.getLocale()로 조회한 사용자 locale에 기반하여 데이터를 조회하는 비즈니스 로직이 있다.

사용자 locale은 늘 존재한다고 생각했기 때문에, 만약 존재하지 않으면, IllegalStateException을 발생시켰다.

운영 배포하자마자 마법처럼 해당 exception이 발생했고, 사용자는 관련 화면에서 서비스 이용 불가 메세지를 보게 되었다.

장애 경보!!

사용자의 서비스 이용이 우선이었기 때문에 exception을 발생시키는 대신 하드 코딩으로 locale을 설정했고, 디버깅을 위해 조회한 locale에 대한 로깅들을 추가하여 임시 조치했다.

4. 현상 파악

로깅을 통해 Locale 객체가 텅 비어있는 것을 확인했다.

왜?..

좀 더 테스트하다보니, 로그인 사용자의 요청에 한해서만 해당 현상이 나타났다.

로그아웃 상태의 미인증 사용자는 Accept-Language 헤더 자체가 존재하지 않고, LocaleResolver bean에서 설정한 default locale이 잘 적용되었다.

'로그인 사용자의 요청 정보가 잘못되었나?'라는 생각에 요청 정보를 뜯어보았는데, 아래처럼 값이 세팅되어 있었다.

Accept-Language: ko_KR

[후술 할 문제의 원인 두 개가 이미 모두 나왔다]

5. 삽질

로그인 여부에 따라 locale 상태가 달라지니 자연스레 인증 쪽에 먼저 눈길이 갔다. 인증 방식으로 JWT를 사용하고 있고, 관련 filter 클래스들을 뒤져보기 시작했다.

'사용자 인증 필터를 거치면서 내부적으로 Locale 정보를 초기화하는 로직이 있는 건가?' 싶어서 custom locale 필터를 만들어 인증 필터 전후로 붙여보기도 했다.

그러나 해결책을 찾을 수 없었다.

원점으로 돌아와, 사용자 locale 정보를 반환해주는 LocaleContextHolder.getLocale()을 하나씩 벗겨보기로 방향을 틀었다.

6. 디버깅

LocaleContextHolder.getLocale()에 break point를 찍고 Accept-Language 헤더 값에 "ja_JP"를 넣어 요청을 보냈다.

LocaleContextHolder.getLocale()

(line 205) getLocaleContext()로 LocalContext를 조회하고, 그 값을 getLocale() 메서드의 argument로 넘겨준다.

getLocaleContext() 메서드를 먼저 보자.

LocaleContextHolder.getLocaleContext()

(line 121) localeContextHolder.get()으로 조회하여 할당한 변수 localeContext의 상태는 아래와 같다.

(참고로, 변수 localeContextHolder 타입이 ThreadLocal<LocaleContext>이기 때문에 ThreadLocal 클래스의 get() 메서드를 통해 조회한다)

localeContext 상태

defaultLocale은 LocaleResolver bean에서 설정한 값인 "ko_KR"로 잘 세팅되어 있다.

그런데 요청 정보 파싱을 통해 저장된 locale 정보가 이상하다.

"und"? 구글링해보면 undefined의 약자인데, 여기서 무언가 잘못되었음을 느꼈다.

이쯤에서 슬랙을 통해 팀원들에게 상황을 공유했다.

클라이언트 팀원 분이 Accept-Language 헤더의 값으로 넣었던 "ja_JP"에 대해 underscore(_)가 아닌 hyphen(-)이 되어야 한다고 말씀주셨다(ㅠㅠ underscore로 요청이 오고 있는걸요..).

실제로 rfc 문서에서도 언급하고 있다(https://www.rfc-editor.org/rfc/rfc9110#language.tags).

RFC 9110: HTTP Semantics

The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of

www.rfc-editor.org

근본적인 원인은 알았으니 마저 킵고잉.

LocaleContextHolder.getLocale()

(line 222~223) 첫 사진에서 보았던 getLocale() 메서드의 파라미터로 LocaleContext 타입의 값이 not null인 상태로 넘어왔다.

(line 224) localeContext.getLocale()으로 반환되는 값은 바로 위에서 보았던 정의되지 않은 언어 코드인 "und" 값을 담고 있는 Locale 객체이다.

결국, LocaleContextHolder.getLocale()을 통해 조회해 온 Locale 객체는 엄밀히 말해 빈 객체가 아니라, 정의되지 않은 언어 코드("und")를 가진 반쪽짜리 객체다.

클라이언트 팀원에게 전달드려 우선 근본적인 원인 파악과 신규 앱 버전 배포를 통해 일차적인 해결은 했다.

그러나 이전 버전에서는 해결책이 되지 못했고, 그렇다고 강제 업데이트를 하기엔 사용자 경험을 몹시 떨어뜨리기 때문에 서버에서 대비책을 마련해야 했다.

아참, 개발 서버에서 문제가 없었던 이유는 Accept-Language 헤더 값이 hyphen(-)으로 잘 구분되어 있었기 때문이었다.

7. 대비책 마련

대비책으로 Accept-Language 헤더 값이 올바르지 않은 경우에도 default locale이 적용되도록 하고자 했다.

그러기 위해 요청 과정 중 어느 시점에서 LocaleContext 객체를 만들어서 세팅하는지 알아야 했다.

LocaleContextHolder 클래스의 docs를 자세히 읽어보면 아래 빨간색 문구가 있다.

DispatcherServlet에서 현재 locale 정보를 자동으로 노출한다는 것을 보니 여길 조져봐야 할 것 같다.

Simple holder class that associates a LocaleContext instance with the current thread. The LocaleContext will be inherited by any child threads spawned by the current thread if the inheritable flag is set to true.

Used as a central holder for the current Locale in Spring, wherever necessary: for example, in MessageSourceAccessor. DispatcherServlet automatically exposes its current Locale here. Other applications can expose theirs too, to make classes like MessageSourceAccessor automatically use that Locale.

DispatcherServlet #buildLocaleContext

"localeContext"로 검색하니까 금세 나온다.

(line 1179) 실제로 break point를 찍고 요청을 날려보면, LocaleResolver bean 설정대로 AcceptHeaderLocaleResolver 타입의 값이 변수 lr에 할당된다.

(line 1184) lr은 not null이기 때문에 AcceptHeaderLocaleResolver 클래스의 resolveLocale() 메서드를 실행한다.

AcceptHeaderLocaleResolver #resolveLocale()

(line 99) 특정 조건을 만족하면 멤버 변수인 defaultLocale을 반환한다.

그 조건이란 default locale이 설정되어 있고 + Accept-Language 헤더 자체가 존재하지 않아야 한다.

하지만 요청 헤더에 Accept-Language 헤더가 존재하기 때문에 조건문을 만족하지 못하여 default locale을 반환하지 않는다.

LocaleResolver bean을 설정할 때 'default locale만 세팅해 주면 잘못된 요청 정보가 와도 무시하고 default로 세팅해주지 않을까?' 하는 생각을 어렴풋이 했는데 막상 까보니 아니었다.

(line 102) HttpServletRequest에서 locale 정보를 조회하여 변수 requestLocale에 할당한다. 위에서 미리 만나보았던 언어코드 "und"가 있는 반쪽짜리 locale 객체이다.

(line 103) List<Locale> 타입의 supportedLocales 멤버를 조회한다. 해당 멤버의 setter 메서드 docs를 보면 변수명 그대로 지원되는 locale을 나타낸다.

Configure supported locales to check against the requested locales determined via HttpServletRequest.getLocales(). If this is not configured then HttpServletRequest.getLocale() is used instead.

(line 104) 여기서부터 대비책을 적용할 수 있는 중요한 내용들이다. supportedLocales가 없거나 requestLocale이 supportedLocale 중 하나라면 requestLocale을 반환한다, 즉, 요청 정보 그대로 반환한다.

나는 LocaleResolver bean 설정에서 supportedLocales를 세팅해주지 않았기 때문에 이 조건을 만족하여 반쪽짜리 locale 객체를 반환하게 된다.

그 말인즉슨, 조건을 만족시키지 않으면 반쪽짜리 locale 객체를 반환하지 않게 할 수 있다는 말과 동일하다. 그러기 위해선 supportedLocale을 세팅해줘야 한다.

(line 107~111) 이 포스트를 작성하고자 했던 핵심 내용이다. findSupportedLocale() 메서드를 호출하여 찾은 supportedLocale이 null이면 의도대로 defaultLocale을 반환시킬 수 있다.

혹시 모르니 findSupportedLocale() 메서드도 잘 살펴봐야 한다.

AcceptHeaderLocaleResolver #findSupportedLocale()

(line 118) 요청 정보에서 가져온 locale 정보들을 순회하면서 supportedLocales에 속한 locale인지 확인한다.

(line 120~125) supportedLocales 중 요청 정보의 locale과 언어 코드, 나라 코드가 모두 일치하는 경우(Full match) 요청 정보의 locale을 반환한다.

(line 126~135) 그렇지 않은 경우, 언어만 일치하는(language-only match) supportedLocale을 languageMatch 변수에 할당하는 fallback 로직이 실행된다.

(line 137) languageMatch를 반환하는데, 해당 값이 null이어야 생각했던 대비책을 적용시킬 수 있다. 다행히 이 케이스에서는 null이 반환된다. 요청 정보의 locale이 "und"라는 정의되지 않은 언어 코드가 담긴 반쪽짜리 locale이기 때문에 supportedLocale에 "und" 언어 코드를 넣지 않는 이상 어느 조건에도 걸리지 않기 때문이다.

8. 결론

클라이언트에서 요청을 보낼 때 Accept-Language 헤더 값은 언어 코드만 작성하거나 언어 코드와 나라 코드를 hyphen(-)으로 구분해야 한다. 그 외 기호로 구분 시 정의되지 않은(undefined, und) 값이 매핑된다.
서버에서 LocaleResolver bean을 설정할 때, default locale을 설정해 주는 것도 중요하지만, supported locales도 설정해 주어야 코너 케이스를 커버할 수 있다.

끝!

[회고][2023년] 회고를 이제서야 작성하게 된 건에 대하여 ~80여 건의 이력서 제출~

대흉근 — Sun, 9 Jun 2024 14:38:02 +0900

왜냐면 이직(이라 쓰고 구직이라 읽게 된)에 성공하고 작성하려고 했기 때문이다.

??: 라고 쓰여있는데요 박사님?

2023.01Q

작년(22년) 12월에 서비스 '어랏'이 릴리즈 된 후 회사 내에서 큰 변화의 바람이 불기 시작했다.
메인 비즈니스의 방향을 크게 바꾸었고, 재택근무가 전면 폐지되었다.

평가 시스템도 생소한 방식으로 바뀌었는데, 사람들 간에는 직원을 내보내려는 방식이라는 살벌한 루머가 떠돌았다.

그리고 나와 둘이 어랏 서비스를 같이 시작하며 1년 여간 함께했던 사수가 퇴사당했다.
업무적으로 많이 의존하던 사수가 이틀 만에 사라져 정신적으로 힘든 시기였다.
내가 서비스의 백엔드 히스토리를 가장 많이 알고 있게 되어 부담감과 책임감도 컸다.

업무 외적으로는, 지난 10여 년간 해왔던 운동의 패러다임을 바꿔준 재활 전문 트레이너 선생님과 친해지게 되었다.
PT를 받은 건 아니고, 내 자세를 보고 사지 출력과 코어의 중요성 등을 알려주었다. 그동안 운동이 아니라 노동을 했구나 싶었다. 이 시점부터 몸도 드라마틱하게 바뀌었다.
단 몇 분 티칭으로도 굉장히 만족스러워서 부모님, 직장 동료, 사촌 동생 등 지인들을 PT 주선을 해주었다. 한 명도 빠짐없이 만족도가 대단히 높았다. 미대 입시 생활로 생긴 허리 디스크 때문에 일상생활에 지장을 겪던 사촌 동생은 지금은 통증이 거의 사라졌다.

2023.02Q

어랏 서비스의 운명을 크게 뒤흔든 어랏 오브 동네 책방 페스타(이하 어동페)라는 마케팅 이벤트를 진행했다.
(https://www.nextdaily.co.kr/news/articleView.html?idxno=218736)

소규모 동네 서점들의 물건을 어랏에서 중개해 주는 이벤트였다.
기존에는 매년 마포구청에서 진행하다가 종료한 이벤트인데, 갑자기 사업팀에서 어랏으로 끌어오더니 냅다 시작해 버렸다.

상당히 많은 투자 금액 대비 결과는 좋지 않았다.

난 내가 생각했던 어랏 서비스의 본질과는 크게 벗어난 이벤트였다고 생각한다.
그 시간과 돈을 어랏 내에서 [크리에이터]라 칭한 인플루언서들과 [팬]들의 상호작용에 더 집중했어야 하지 않았을까?

여하튼, 이때부터 어랏은 회사의 따가운 눈초리를 받으며 서비스 종료의 길로 접어든다.

업무 외적으로는, 7년간 교제했던 여자친구와 반년 정도 헤어졌다가 다시 만나게 되어 기쁜 기간이기도 했다.
헤어졌던 반년은 몹시 고통스러웠다.

2023.03Q ~ 2023.04Q

회사는 어랏 서비스의 성공 가능성을 낮게 보기 시작했다.

결국 3분기에는 신규 기능 개발이 중단되었고, 4분기에 서비스 종료가 확정되어 2023년 12월에 서버를 내렸다.

그리고 회사는 희망퇴직을 받기 시작했으며, 어랏 개발자 모두 그 대상이 되어 퇴사하게 되었다.

이직이 아니라 구직이 되었다.

2024.01Q ~ 2024.02Q

약 반년 정도 구직 생활을 했다.

군 생활 당시, '나'라는 인간에 대해 정말 많은 고찰과 반성을 했고 앞으로의 인생에서는 이런 시간이 없을 거라 생각했었다.
역시 인생에 100%는 없다.

구직 생활을 하며 군 생활 때와는 또 다른 메타인지를 하게 되었다.

구직 초기에 가장 중요하게 생각했던 요소는 재무 안정성이었다.
그러다 보니 몸집이 큰 회사들의 채용 공고 위주로 볼 수밖에 없었는데, 문제는 금리가 많이 오르고 경기가 안 좋아 채용 문을 꽉 닫고 있었다.

가뭄에 콩 나듯 공고가 나오긴 했지만, 서류에서 탈락하거나 1차 면접에서 탈락하기 일쑤였다.

그러다 아래 제미니님의 유튜브 영상을 보고 생각을 크게 고쳐먹었다.
https://youtu.be/1ifSAFCGiX8?si=K3KFUJ2jXAgqsWdc

나보다 연차도 높고 내로라하는 곳에서 일하시는 분들도 이직이 쉽지 않은 상황인데, 나는 너무 회사의 안정성에만 매몰되어 있다는 생각을 하게 되었다.

그래서 재무 안정성 외에 '내가 좋아하는 비즈니스 도메인' 이라는 구직 요소를 한 가지 더 추가했다.

신기하게도 늘 탈락의 고배를 마셨던 1차 면접에서 합격하게 되었다.

그것도 동시에 두 회사에서.
그리고 최종 면접 역시 모두 합격하였다.

두 회사 모두 내가 좋아하는 도메인이라 많은 고민과 생각을 하였고, 처우가 좀 더 나은 "그래픽"이라는 스타트업에서 근무를 하게 되었다.
아래 블로그 글처럼, 이태원의 랜드마크 중 하나인 그래픽이라는 북카페를 운영하는 신기한 스타트업이다(곧 위례와 일본에도 신규 매장 오픈 예정).
https://m.blog.naver.com/dogbiny/223008844714

서울 이태원 한남동 북카페 :: 용산 '그래픽' GRAPHIC | 이태원 만화카페 서점

GRAPHIC 이태원 그래픽 서울 용산구 회나무로39길 33 그래픽 ▫️영업시간 : 13:00 -...

blog.naver.com

누구나 만화를 업로드하고 모두가 볼 수 있는 서비스 "그래픽" 앱의 백엔드 개발자로 현재 근무 중이다.
입사하자마자 일본 진출에 대비한 서비스 현지화 프로젝트를 진행하고 있다.
https://graphic.fan/

GRAPHIC

graphic cartoon platform

graphic.fan

마무리

첫 번째 이직보다 두 번째 이직이 기간도 더 길고 지원한 횟수도 더 많았다, 대략 80여 곳?..

꽁꽁 얼어붙은 채용 시장 위로 걸어 다니며 참 힘든 시기였지만 좋은 점도 있었다.
가족, 특히 어머니와 매일 같이 밥을 먹으며 헬스장도 같이 가서 운동도 알려드리고, 살면서 가장 이야기를 많이 나눈 기간이었다.

"새옹지마"라는 고사성어를 참 좋아한다.
고사성어 내용을 너무 맹신하면 인생 자체가 재미없어지겠지만, 힘든 기간을 잘 버티면 좋은 일은 항상 일어난다는 내용만 선별적으로 가슴에 품고 산다.

모두 파이팅!

끝!

[Trouble Shooting][Spring boot 3.0.x] request body가 record 타입으로 매핑(역직렬화) 되지 않는다

대흉근 — Fri, 22 Mar 2024 14:14:04 +0900

최근, Java 17 + Spring Boot 3.0.2 버전을 사용하는 프로젝트에서 Jackson과 관련된 이슈를 발견했다.

글 작성의 편의를 위해 아래에서는 회원가입 API를 구현해야 하는 상황을 가정한다.

Jackson의 동작원리와 Introspection이라는 개념에 대해 알고 있어야 한다.

- [Spring] Jackson 라이브러리 이해하기

- [Java] 처음 들어보는 java.beans.Introspector

1. 발단

회원가입에 필요한 정보를 request body로 받기 위해, 아래와 같이 Java 16부터 정식으로 도입된 record 타입으로 생성했다.

record SignUpRequest(
	@NotEmpty String name
	@NotEmpty String address,
	@NotEmpty String phoneNumber
) {
    public SignUpCommand toCommand() {
        return new SignUpCommand(name, address, phoneNumber);
    }
}

그리고 해당 프로젝트에서는 클라이언트와의 네이밍 전략을 Snake Case로 맞추었기 때문에 yml 설정 파일에 아래 내용이 명시되어 있다.

spring:
  jackson:
    property-naming-strategy: SNAKE_CASE

따라서 클라이언트는 아래와 같은 요청을 보낸다.

POST /api/v1/auth/signup
Content-Type: application/json

{
    "name": "대흉근",
    "address": "서울시 강남구",
    "phone_number": "01012345678"
}

2. 전개

postman으로 API를 콜하면(테스트 코드 작성하기 귀찮은거 아님) 400 Bad Request가 발생한다.

INFO 레벨에서의 로깅은 별 정보를 주지 않으니, yml 설정 파일에서 TRACE 레벨 로깅으로 바꾼다.

logging:
  level:
    root: trace

다시 API를 콜해보면, 발생하고 있는 에러를 친절하게 알려준다.

org.springframework.http.converter.HttpMessageNotReadableException: JSON parse error: Can not set final java.lang.String field com.example.test.adapter.in.web.SignUpRequest.phoneNumber to java.lang.String
	...

Caused by: com.fasterxml.jackson.databind.JsonMappingException: Can not set final java.lang.String field com.example.test.adapter.in.web.SignUpRequest.phoneNumber to java.lang.String
	at com.fasterxml.jackson.databind.JsonMappingException.from(JsonMappingException.java:276) ~[jackson-databind-2.14.1.jar:2.14.1]
	at com.fasterxml.jackson.databind.deser.SettableBeanProperty._throwAsIOE(SettableBeanProperty.java:627) ~[jackson-databind-2.14.1.jar:2.14.1]
	at com.fasterxml.jackson.databind.deser.SettableBeanProperty._throwAsIOE(SettableBeanProperty.java:615) ~[jackson-databind-2.14.1.jar:2.14.1]
	at com.fasterxml.jackson.databind.deser.SettableBeanProperty._throwAsIOE(SettableBeanProperty.java:638) ~[jackson-databind-2.14.1.jar:2.14.1]
	at com.fasterxml.jackson.databind.deser.impl.FieldProperty.set(FieldProperty.java:193) ~[jackson-databind-2.14.1.jar:2.14.1]
	at com.fasterxml.jackson.databind.deser.impl.PropertyValue$Regular.assign(PropertyValue.java:60) ~[jackson-databind-2.14.1.jar:2.14.1]
	at com.fasterxml.jackson.databind.deser.impl.PropertyBasedCreator.build(PropertyBasedCreator.java:211) ~[jackson-databind-2.14.1.jar:2.14.1]
	at com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeUsingPropertyBased(BeanDeserializer.java:519) ~[jackson-databind-2.14.1.jar:2.14.1]
	at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.deserializeFromObjectUsingNonDefault(BeanDeserializerBase.java:1405) ~[jackson-databind-2.14.1.jar:2.14.1]
	at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:352) ~[jackson-databind-2.14.1.jar:2.14.1]
	at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:185) ~[jackson-databind-2.14.1.jar:2.14.1]
	at com.fasterxml.jackson.databind.deser.DefaultDeserializationContext.readRootValue(DefaultDeserializationContext.java:323) ~[jackson-databind-2.14.1.jar:2.14.1]
	at com.fasterxml.jackson.databind.ObjectReader._bindAndClose(ObjectReader.java:2105) ~[jackson-databind-2.14.1.jar:2.14.1]
	at com.fasterxml.jackson.databind.ObjectReader.readValue(ObjectReader.java:1481) ~[jackson-databind-2.14.1.jar:2.14.1]
	at org.springframework.http.converter.json.AbstractJackson2HttpMessageConverter.readJavaType(AbstractJackson2HttpMessageConverter.java:395) ~[spring-web-6.0.4.jar:6.0.4]

	...

Caused by: java.lang.IllegalAccessException: Can not set final java.lang.String field com.example.test.adapter.in.web.SignUpRequest.phoneNumber to java.lang.String
    at java.base/jdk.internal.reflect.UnsafeFieldAccessorImpl.throwFinalFieldIllegalAccessException(UnsafeFieldAccessorImpl.java:76) ~[na:na]
    at java.base/jdk.internal.reflect.UnsafeFieldAccessorImpl.throwFinalFieldIllegalAccessException(UnsafeFieldAccessorImpl.java:80) ~[na:na]
    at java.base/jdk.internal.reflect.UnsafeQualifiedObjectFieldAccessorImpl.set(UnsafeQualifiedObjectFieldAccessorImpl.java:79) ~[na:na]
    at java.base/java.lang.reflect.Field.set(Field.java:799) ~[na:na]
    at com.fasterxml.jackson.databind.deser.impl.FieldProperty.set(FieldProperty.java:190) ~[jackson-databind-2.14.1.jar:2.14.1]

Jackson 라이브러리의 FieldProperty 클래스에서 값을 매핑하는 setter 메서드를 실행하던 중, final String인 phoneNumber에 값을 매핑할 수 없는 JsonMappingException이 발생한 것으로 보인다.

가장 아래의 로그를 보면, 그 과정에서 java reflect 기능을 통해 값을 매핑하면서 exception이 던져진 것 같다. 로그에 찍힌 UnsafeQualifiedObjectFieldAccessorImpl.set()을 들어가보면, 아래처럼 isReadOnly라는 값이 true인 경우, throwFinalFieldIllegalAccessException을 던지고 있는 것을 알 수 있다.

public void set(Object obj, Object value)
        throws IllegalArgumentException, IllegalAccessException
    {
        ensureObj(obj);
        if (isReadOnly) {
            throwFinalFieldIllegalAccessException(value);
        }
        ...
    }

isReadOnly는 UnsafeQualifiedObjectFieldAccessorImpl가 상속하고 있는 추상 클래스인 UnsafeQualifiedFieldAccessorImpl에 선언되어 있다.

/**
 * Base class for jdk.internal.misc.Unsafe-based FieldAccessors for fields with
 * final or volatile qualifiers. These differ from unqualified
 * versions in that (1) they check for read-only status (2) they use
 * the volatile forms of Unsafe get/put methods. (When accessed via
 * reflection, finals act as slightly "lighter" forms of volatiles. So
 * the volatile forms are heavier than necessary in terms of
 * underlying reordering rules and memory barriers, but preserve
 * correctness.)
 */

abstract class UnsafeQualifiedFieldAccessorImpl
    extends UnsafeFieldAccessorImpl
{
    protected final boolean isReadOnly;

    UnsafeQualifiedFieldAccessorImpl(Field field, boolean isReadOnly) {
        super(field);
        this.isReadOnly = isReadOnly;
    }
}

주석 내용을 보아하니 record 타입이 가지는 특징 중 하나인 불변성이 슬슬 의심되는데, 좀 더 파본다.

UnsafeQualifiedObjectFieldAccessorImpl의 생성자 파라미터로 받고 있는 isReadOnly 값을 어디서 어떻게 세팅해주는지 따라간다.

class UnsafeFieldAccessorFactory {
    static FieldAccessor newFieldAccessor(Field field, boolean isReadOnly) {
        Class<?> type = field.getType();
        boolean isStatic = Modifier.isStatic(field.getModifiers());
        boolean isFinal = Modifier.isFinal(field.getModifiers());
        boolean isVolatile = Modifier.isVolatile(field.getModifiers());
        boolean isQualified = isFinal || isVolatile;
        if (isStatic) {
            // This code path does not guarantee that the field's
            // declaring class has been initialized, but it must be
            // before performing reflective operations.
            ...
        } else {
            if (!isQualified) {
                ...
            } else {
                ...
                } else {
                    return new UnsafeQualifiedObjectFieldAccessorImpl(field, isReadOnly);
                }
            }
        }
    }
}

한 번 더!!

/** <P> The master factory for all reflective objects, both those in
    java.lang.reflect (Fields, Methods, Constructors) as well as their
    delegates (FieldAccessors, MethodAccessors, ConstructorAccessors).
    </P>

    <P> The methods in this class are extremely unsafe and can cause
    subversion of both the language and the verifier. For this reason,
    they are all instance methods, and access to the constructor of
    this factory is guarded by a security check, in similar style to
    {@link jdk.internal.misc.Unsafe}. </P>
*/

public class ReflectionFactory {
    ...
    //--------------------------------------------------------------------------
    //
    // Routines used by java.lang.reflect
    //
    //
    
    /*
     * Note: this routine can cause the declaring class for the field
     * be initialized and therefore must not be called until the
     * first get/set of this field.
     * @param field the field
     * @param override true if caller has overridden accessibility
     */
    public FieldAccessor newFieldAccessor(Field field, boolean override) {
        checkInitted();

        Field root = langReflectAccess.getRoot(field);
        if (root != null) {
            // FieldAccessor will use the root unless the modifiers have
            // been overridden
            if (root.getModifiers() == field.getModifiers() || !override) {
                field = root;
            }
        }
        boolean isFinal = Modifier.isFinal(field.getModifiers());
        boolean isReadOnly = isFinal && (!override || langReflectAccess.isTrustedFinalField(field));
        return UnsafeFieldAccessorFactory.newFieldAccessor(field, isReadOnly);
    }
    ...
}

아아.. 드디어 찾았다.

결국 위에서 추측했던 대로, record 타입으로 인해 isReadOnly 값이 true로 넘어올 것이라는 것을 확인할 수 있다.

IntelliJ에서 제공하는 기능으로 record 타입인 SignUpRequest를 class 타입으로 변환해보면, 아래처럼 final 범벅 불변 클래스가 만들어짐을 알 수 있다.

final class SignUpRequest {
    private final @NotEmpty String name;
    private final @NotEmpty String address;
    private final @NotEmpty String phoneNumber;

    SignUpRequest(String name, String address, String phoneNumber) {
        this.name = name;
        this.address = address;
        this.phoneNumber = phoneNumber;
    }
    ...
}

정리하자면,

1. Jackson 라이브러리는 HTTP Request Body를 SignUpRequest로 deserialize(역직렬화)한다.

2. 그 과정 중 Java의 reflect 기능을 사용하여 SignUpRequest의 property에 값을 setting 한다.

3. 하지만 SignUpRequest는 record 타입이기 때문에 가지는 불변성이라는 특징 덕에 오류가 발생한다.

3. 위기

오케이, 그럼 SignUpRequest를 class 타입으로 변환하면 될 것 같다.

실제로 잘 동작한다.

그런데 이전에 만들었던 토이 프로젝트에서는 아래 예시처럼 request 객체를 record 타입으로 만들었지만 별 이슈가 없었던 것이 불현듯 떠올랐다.

해당 프로젝트는 Java 17 + Spring Boot 3.2.0 버전을 사용하고 있다.

record ChangeUserInfoRequest(
        @NotEmpty String name,
        @NotEmpty String phoneNumber
) {

    public ChangeUserInfoCommand toCommand() {
        return new ChangeUserInfoCommand(name, phoneNumber);
    }

}

API 호출도 정상적으로 동작하고, 로깅 레벨을 TRACE로 바꿔봐도 에러가 보이지 않는다.

4. 절정

우선 토이 프로젝트의 Boot 버전을 3.1.0으로 낮춰서 다시 테스트 해보았다.

잘 된다.

Spring Boot 3.1 릴리즈 노트를 찾아봤더니, Jackson에 대한 업데이트 내용이 있다.

https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.1-Release-Notes#jackson-215

Spring Boot 3.1 Release Notes

Spring Boot. Contribute to spring-projects/spring-boot development by creating an account on GitHub.

github.com

Jackson 2.15 버전의 변경 내역이 담긴 wiki를 들어가본다.

https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.15

Jackson Release 2.15

Main Portal page for the Jackson project. Contribute to FasterXML/jackson development by creating an account on GitHub.

github.com

record로 검색을 해보니 아래와 같은 이슈들이 발견된다.

사실 이때의 난 네이밍 전략과 관련된 이슈로 생각했기 때문에 이 중 2992번째 이슈를 들어가보았다.

https://github.com/FasterXML/jackson-databind/issues/2992

`@JsonNaming` does not work with Records · Issue #2992 · FasterXML/jackson-databind

Hello, When I try to use a @JsonNaming annotation on a record, I cannot unmarshall json to an object because a mapping exception occurs. I use jackson 2.12.0 with JDK 15. A Test example can be some...

github.com

이슈 작성자의 증상이 나와 동일하다.

작성자와 이야기 나누고 있는 있는 레포지토리 멤버의 말에 따르자면, 네이밍 전략은 deserialization 과정 중에 동적으로 사용되는 것이 아니기 때문에 원인일 것 같지는 않다고 한다.

그러나 꽤나 골 깨지는 이슈라고 말하며 아래처럼 이슈 내용에 대해 정리한다.

마지막에 언급된 discussion에 대해 더 읽고 싶다면 다음 링크로 이동하면 된다.
(https://github.com/FasterXML/jackson-databind/discussions/3719)

멤버들이 소처럼 일해준 덕에 아래 PR에서 수정되었음을 확인할 수 있다.

https://github.com/FasterXML/jackson-databind/pull/3724

Change Records deserialization to use the same mechanism as POJO deserialization. by yihtserns · Pull Request #3724 · FasterXM

New Supports @JsonCreator.mode=DISABLED on canonical constructor. Supports deserialization using "implicit" (i.e. without @JsonCreator annotation) non-canonical constructor when 1/more of its para...

github.com

변경 내역을 완벽히 이해하긴 어렵지만, record 타입인 케이스에 대해 분기 처리를 해준 것으로 보인다.

5. 결말

Spring Boot 3.0.x 버전에서 사용하는 Jackson 2.14.x 버전에서는 record 타입으로 request 객체를 만들면 역직렬화가 실패한다.

Spring Boot 3.1.0 버전부터 사용되는 Jackson 2.15.0 버전부터는 해당 이슈가 수정되었다.

끝!

[Trouble Shooting][Spring] @TransactionalEventListener 이후의 데이터 변경 내역들이 무시된다?

대흉근 — Sun, 29 Jan 2023 20:59:59 +0900

2022년 12월에 런칭된 서비스 "어랏"을 개발하며 발생한 버그에 대한 경험을 작성한 글이다.
본인인증과 관련된 꽤 중요한 기능의 버그였는데, 런칭 전에 찾아내어 다행이었다.

아래 링크들을 참고하여 작성하였다.

- https://kwonnam.pe.kr/wiki/springframework/transaction/transactional_event_listener

springframework:transaction:transactional_event_listener [권남]

kwonnam.pe.kr

- https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/event/TransactionalEventListener.html

TransactionalEventListener (Spring Framework 6.0.4 API)

The event classes that this listener handles. If this attribute is specified with a single value, the annotated method may optionally accept a single parameter. However, if this attribute is specified with multiple values, the annotated method must not dec

docs.spring.io

- https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/event/TransactionPhase.html

TransactionPhase (Spring Framework 6.0.4 API)

Returns an array containing the constants of this enum class, in the order they are declared.

docs.spring.io

- https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/support/TransactionSynchronization.html#afterCompletion(int)

TransactionSynchronization (Spring Framework 6.0.4 API)

Invoked after transaction commit/rollback. Can perform resource cleanup after transaction completion. NOTE: The transaction will have been committed or rolled back already, but the transactional resources might still be active and accessible. As a conseque

docs.spring.io

발단

어랏에서는 사용자가 본인인증을 성공적으로 완료하면, 사내의 여러 서비스(유저, 포인트, 블록체인 등)에 사용자를 온보딩시킨다. 그래야 정상적인 어랏 서비스 이용이 가능하기 때문이다.

최초 본인인증 기능을 구현할 때에는 온보딩 시킬 사내 서비스가 하나였다. 그래서 본인인증이 완료되면 사내 서비스 온보딩 메서드를 직접 호출하는 동기 방식으로 구현했었다.

이후 다른 팀원들이 내가 만든 본인인증 로직에 온보딩 시킬 다른 사내 서비스를 하나 둘 추가하기 시작했다.
점점 가독성이 떨어지고, 한 메소드에서 너무 많은 일들을 처리하게 되어 강결합이 되었다.

런칭 전에는 개선되어야 할 것 같아 백엔드 팀원들과 상의하였고, spring event 방식을 사용하여 리팩토링하기로 했다.

본인인증 트랜잭션 commit이 성공적으로 완료된 후 온보딩 로직이 진행되길 원했기 때문에 @TransactionalEventListener를 사용했고, 리팩토링 작업 자체는 그닥 어렵지 않았다.

대강 아래처럼 동작하도록 개선되었다.

/**
*  본인인증 메소드
*  사용자가 NICE를 통해 본인인증을 성공적으로 완료하면 NICE 측에서 어랏 서버를 콜백
*/
public void verifyIdentity(..) {

    // 개인 정보 관련 작업
    ...
    
    // 본인인증 완료 이벤트 발행
    applicationEventPublisher.publishEvent(new IdentityVerificationCompleted(..));
}

/**
*  사내 서비스 온보딩 메소드
*  IdentityVerificationCompleted 이벤트 수신
*/
@TransactionalEventListener
public void registerUsers(IdentityVerificationCompleted event) {

    // Feign을 통해 사내 서비스 온보딩
    RegisterUserRequest request = RegisterUserRequest.prepare(..);
    ClientResponse<Void> response = client.registerUsers(request);
    
    // 사용자의 어랏 포인트 계좌 생성 후 저장
    PointAccount pointAccount = PointAccount.create(..);
    pointAccountRepository.save(pointAccount);
    
    log.info("[Identity Verification] receive IdentityVerificationCompleted event in registering user");
}

리팩토링 후 로컬 환경에서 이것저것 테스트 해보고, 코드 리뷰를 받고, 개발 환경으로 머지시켰다. (-> 문제점)

전개

며칠 뒤, QA에서 신규 계정으로 본인인증을 했는데 앱 내에서 포인트를 확인할 수 없다는 버그 티켓이 올라왔다.

이슈를 파악해보니 포인트 계좌 뿐만 아니라, 본인인증을 하면 어랏 서버 내에 저장되어야 하는 데이터가 생성되지 않았다.

리팩토링 전후로 바뀐 부분은 메소드 호출 방식뿐이라, 가장 먼저 @TransactionalEventListner가 의심되었다.
문제는 @TransactionalEventListner를 팀원들과의 리팩토링 과정 논의 자리에서 처음 듣고 사용해본 것이라, 어디서부터 어떻게 디버깅할지 감이 안잡혔다.

일단 이전에 자주 사용해보았던 @EventListner로 바꿔봤더니 잘 동작했다, 오잉..?!
확실히 @TransactionalEventListner가 원인임은 알게 되었다.

다시 @TransactionalEventListner로 돌려놓고, TransactionSynchronizationManager의 isActualTransactionActive() 메서드를 통해 실제로 트랜잭션이 활성화 되어 있는 상태를 확인했다.
응 활성화 되어있다..

열심히 헤매고 있는데, 팀원 분이 권남님 블로그를 찾아주셨고 아래와 같은 내용을 볼 수 있었다.

주의 사항

- AFTER_COMMIT phase 에서 JPA Entity에 수정을 가해봐야 반영이 안 된다. 이미 커밋한 상태이고 트랜잭션자체는 기존 것을 유지하고 있다. 기존 JPA Entity 뿐만 아니라 신규 트랜잭션도 실행되지 않는다.

즉, @TransactionalEventListner의 옵션 중 phase의 default 값인 AFTER_COMMIT을 사용하면,
이벤트 발행 시의 트랜잭션 내용은 모두 commit 되지만 트랜잭션 리소스 자체는 계속 살아있고,
이벤트 수신 측에서는 해당 트랜잭션 리소스를 사용하지만 그 뒤 어떠한 데이터 변경이 일어나도 commit이 되지 않는다고 한다.

@TransactionalEventListener의 공식 문서도 뒤져보았다.
phase 옵션의 타입인 TransactionPhase 문서에서 AFTER_COMMIT은 AFTER_COMPLETION의 구체화 된 기능이고,
AFTER_COMPLETION을 좀 더 자세히 알고자 하면 TransactionSynchronization이라는 인터페이스의 afterCompletion(int) 문서를 살펴보라고 작성되어 있어 가보니..

아래와 같은 NOTE가 적혀있었다.

NOTE: The transaction will have been committed or rolled back already, but the transactional resources might still be active and accessible. As a consequence, any data access code triggered at this point will still "participate" in the original transaction, allowing to perform some cleanup (with no commit following anymore!), unless it explicitly declares that it needs to run in a separate transaction. Hence:
Use PROPAGATION_REQUIRES_NEW for any transactional operation that is called from here.

대강 요약하자면,
트랜잭션 리소스는 계속 살아있으며 접근 가능하고, 이 시점에서의 모든 데이터 변경 코드 역시 기존 트랜잭션에 계속 참여되지만,
이러한 데이터 변경은 별도의 트랜잭션에서 진행되어야 함을 명시적으로 선언하지 않는 한, 변경 내역은 commit되지 않는다.
그러므로 PROPAGATION_REQUIRES_NEW를 사용해야 한다고 한다.

결말

해결 방법은 아래 네 가지 정도가 있었다.
우리는 본인인증 트랜잭션이 성공적으로 commit 되어야 한다는 전제가 필요했기 때문에 공식 문서에 적혀있던 것처럼 세번째 방법으로 해결했다.

p.s. 더 시간이 지난 후에는 4번 방식을 사용했다.

(1) @TransactionalEventListner 대신 @EventListner를 사용한다.

(2) @TransactionalEventListner(phase = BEFORE_COMMIT)을 사용한다.
- BEFORE_COMMIT 옵션을 사용하면 이벤트 발행 시의 트랜잭션 내용이 commit 되지 않은 상태로 넘어와, 이벤트 수신 측 코드가 모두 진행된 후에야 commit 된다.

(3) @Transactional(propagation = Propagation.REQUIRES_NEW)를 사용한다.

(4) 비동기(@Aync) 방식을 사용한다.

본문 중 (문제점)이라고 작성한 부분에 대해 좀 더 이야기 해보고 글을 마무리 하고자 한다.

리팩토링 후 로컬 환경에서 이것저것 테스트 해보고, 코드 리뷰를 받고, 개발 환경으로 머지시켰다.(-> 문제점 )

다른 팀원들이 추가한 로직들에 대해 충분히 알아보지 않았기 때문에 완결성이 높은 테스트를 진행하지 못했다.
물론 덩치가 점점 커져가는 서비스의 모든 로직을 다 알기는 힘들지만, 최소 리팩토링 하기 전에 영향을 받을 부분에 대해서는 신중하고 꼼꼼하게 알아봤어야 했다.
설령 그러지 못했더라도, 코드 리뷰를 오프라인 미팅으로 잡는 등의 추가적으로 적극적인 액션이 있었어야 했던 것 같다.
(아무래도 프리랜서 분들이 절반이나 계시다 보니 코드 리뷰가 제대로 이루어지지 않는 어려움이 있기도.. ㅜㅜ)

끝!

[회고][2022년] The Good, the Bad, and the Ugly로 돌아보는 2022년

대흉근 — Fri, 30 Dec 2022 21:23:15 +0900

내가 소속되어 있는 어랏 프로젝트는 매 스프린트 마지막 날마다 다양한 방식으로 회고를 한다.

PM님께서 아래 사이트에서 매번 다른 회고 방식을 가져오는데, 그중 무난한 거 하나 골라서 올해 2022년 회고를 해보려고 한다.

- https://www.funretrospectives.com/category/retrospective/

FunRetrospectives | Have fun, learn from the past and prepare for the future!

Have fun, learn from the past and prepare for the future!

www.funretrospectives.com

내가 사용할 방식은 "The Good, the Bad, and the Ugly"인데, 아래 사이트의 설명에 따르면 이 회고 방식은 다음과 같다.

- https://www.funretrospectives.com/the-good-the-bad-and-the-ugly/

The Good, the Bad and the Ugly | FunRetrospectives

www.funretrospectives.com

The Good: 잘 진행됐던 것들, 그리고 계속 그러한 것들을 반복해 나가고 더 많이 해야 할 것들
The Bad: 다시는 발생되면 안되는 것들, 그리고 반드시 제거해야 함
The Ugly: 잘 진행되지 않았던 것들, 그리고 개선점을 찾아 "The Good"으로 바꿀 수 있는 것들

참고로, 올해 상반기 회고도 작성했었는데 너무 대충 써놨네 ㅎㅎ;

- https://siahn95.tistory.com/entry/%ED%9A%8C%EA%B3%A02022%EB%85%84-%EC%83%81%EB%B0%98%EA%B8%B0-%EB%B0%94%EC%81%98%EB%8B%A4-%EB%B0%94%EB%B9%A0-%EA%B7%B8%EB%9E%98%EB%8F%84-%ED%96%89%EB%B3%B5%ED%95%98%EB%8B%A4

[회고][2022년 상반기] 바쁘다 바빠! 그래도 행복하다!

올해 2월, 이직에 성공하고 벌써 4개월이나 흘렀다. 정말 바쁘면서 알차게 시간을 보내고 있는데, 기록을 좀 남겨보고 싶어서 상반기 회고를 써보려고 한다. 2022년 1월 작년 12월 31일에 최종 합격

siahn95.tistory.com

The Good

1. 활발한 컨텐츠 공유 활동

내가 입사했던 올해 2월, 당시의 사내 평균 연령이 40세를 훌쩍 넘긴 탓인지 슬랙이 매우.. 매우 조용했다.

친구들 사이에서도 온갖 컨텐츠, 뉴스 등을 퍼나르고 공유하길 좋아하는 나에겐 도저히 참을 수 없는 환경이었기 때문에,

OKR 중 하나를 기술 컨텐츠 공유로 잡았다.

내가 일하면서 알게 된 좋은 블로그 포스트, 이곳저곳에서 공유받은 컨텐츠들 등등 개발팀과 백엔드파트에 적어도 주에 3-4개는 공유했던 것 같다.

한편으로 초반에는 나만 너무 오버하나 싶은 걱정도 있었는데, 다행히 점점 많은 팀원들이 좋은 컨텐츠들을 공유하기 시작했다.

요거 덕분에 올해 분기 평가마다 계속 좋은 피드백을 들을 수 있던 것 같다.

(상반기 회고 글에 이은 자랑 짤)

2. 활발한 사내 활동

취업 사기(?)를 당했던 전회사(관련 글)에서는 정말 쥐죽은 듯이, 아무 활동에도 참여하지 않고 지냈었다.

지금 와서 생각해보면 어린 마음에 너무 감정적으로 행동했던 것 같지만..

여하튼 어차피 출근해서 일해야 하기도 하고, 이전 회사에서의 못난 짓들을 반성하면서 동료들과 좋은 관계를 맺고 싶은 마음이 매우 컸다.

그래서 막내 라인들과 "백엔드 운영 혁명 위원회"를 꾸려 백엔드 파트의 각종 경조사와 행사들을 기획하고 진행하기도 했다.

프론트나 네이티브 등 다른 파트들에서 '백엔드는 잘 뭉치고 부럽다'라는 소리가 종종 들려와 잘하고 있구나 생각이 들었다 ㅋ_ㅋ

다른 각종 워크샵이나 행사에도 열심히 참여하고 리액션하고.. 진짜 즐겁게 회사 다녔던 것 같다.

(또 자랑짤, 개발팀 워크샵 때 받은 왕)

The Bad

1. 프리랜서 관리 미흡

올해 초 (지금은 출시된) 신규 서비스 프로젝트에 백엔드는 나를 포함해서 두명으로 시작했다.

기획 분들은 당연히 서비스를 더 풍성하게 내고 싶은 마음에 유니콘을 만드려는 기획서를 들고 오셨는데, 개발 팀에서 내년에 출시하고 싶으면 그렇게 하자고 했음.

하여튼 이것 저것 스펙 다운 시켰음에도 백엔드 신입이나 마찬가지인 나 하나 데리고 사수가 할 일이 너무 많았다.

윗분들도 이 점을 인지하고 있었고 반년 계약 프리랜서 중급 한명, 초급 한명을 고용했다.

초급 프리랜서 분은 의사소통이 정말 잘 되고 일도 잘하셨는데, 프로젝트 인원들이 모두 정직원 전환을 원할 정도였다.

문제는 중급 프리랜서 분인데, 중국인에서 한국인으로 귀화하신 분이라 일단 한국말이 많이 어눌하셨다.

귀화한지 10년이 넘으셨다던데..?

그 때문에 개발자들 사이에서 뿐만 아니라 다른 직무 분들과 의사소통 할 때 같은 내용을 몇 번씩이나 설명하면서 이해시켜야 했다.

설상가상으로 본인 의견 피력도 굉장히 강하고 커리어에 대해 자부심이 엄청나다 못해 과하신 분이라 종종 남들을 깔보는 모습도 보이시며, 사수와도 큰 마찰이 잦았고..

그 때문에 지금도 둘 사이는 남한과 북한 사이보다 안좋다.

이런 저런 일들로 내가 느끼기엔 프리랜서 권한 밖의 언행들을 너무 많이 하셔서 프리랜서랑 일하는지 상사랑 일하는지 종종 혼동될 정도였다.

요즘에는 사수와 그분이 같이 들어가는 미팅에 나도 구글 캘린더 인비가 오면 스트레스 이빠이 받을 정도;

아 아니, 어쨌든 사수는 프리랜서와 일해본 경험이 전혀 없어 어떻게 매니징해야 할지 모르겠다고 초반부터 말씀하셨었다.

전회사에서 프리랜서, 협력사 직원들과만 내내 지낸 내가 초반에 어느 정도 매니징하고 억눌렀어야 했는데..

이것에 대한 액션 아이템으로는, 근래에 이전 회사의 기억들을 되살려 슬금슬금 억누르고 있다.

PO, PM님들은 현 체제가 마음에 들었는지 반년 계약이 끝난 후 그분과 1년이나 재계약을 했기 때문에.

2. 개인 공부 미흡

이전 직장에서 거진 15개월을 이직 준비를 하면서 주말, 공휴일 할 것 없이 매일 퇴근하고 혹은 하루 종일 공부하고 블로그 포스트를 썼다.

근데 이직하고 초반에는 손 대는 모든 일들이 다 공부 거리라 업무만 해도 머리가 터질 것 같았고, 스프린트 일정에 맞추기 위해서 퇴근 후에도 계속 일했다.

그 와중에 종종 포스팅을 하긴 했으나 매우 간단한 내용들 뿐이었다.

가을 쯤부터는 어느 정도 숨통이 트여 퇴근 후에 시간이 남는 날들이 있었는데 귀찮아서 유튜브 보고 놀았던 것 같다.

노션에 포스팅 거리 잔뜩 쌓였는데...

이 회고 글도 귀찮아서 안쓰려다가 개발바닥 오픈 카카오톡 방에서 오늘 모티베이션을 받아 온 힘을 쥐어 짜내고 있다.

이것에 대한 액션 아이템으로는, 내년엔 적어도 한달에 두 개 포스팅은 하고 싶다.

그리고 모든 포스팅은 관련 공식 문서들을 기반으로 글을 쓰려고 한다.

The Ugly

1. 테스트 코드 작성

T.D.D(Test Driven Development)라는 개발 방법론이 대세가 되어가고 있을 정도로 테스트 코드에 대한 중요성은 점점 커져가는 것 같다.

근데 우리 프로젝트에서는 빡빡한 출시 일정에 맞춰 구현해야 하는 기능들이 너무 많아 아무도 주도적으로 테스트 코드를 작성하질 않았다.

핑계라면 핑계일 수도 있겠지만..

그 누구도 테스트 코드에 친숙하지 않은 탓도 있는 것 같다.

이것에 대한 액션 아이템으로는, 출시 이후에도 여전히 기획에서는 수많은 신규 피쳐들을 요구하고 있지만, 내년부터는 유닛 테스트를 최대한 많이 작성하는 버릇을 들여야겠다.

최근에는 사내 권장 API 문서화 도구로 채택된 Spring Rest Docs도 도입했으니 적어도 새로운 기능들에 대해서는 얘로 문서화 시켜야겠다.

내가 남는 시간 쪼개가며 적용해놓고 정작 컨플루언스에 익숙해서 Rest Docs를 쓰고 있질 않으니;

2. 내 코드에 대한 맹신

왜 내가 만든 코드는 완벽할 것 같고 문제가 없을 것 같을까?

마치 시험 전날 벼락치기 공부를 하며 '어 이정도면 엔간한 시험 문제는 다 풀겠는데?' 하는 마인드와 같다.

특히 초반에는 그런 알 수 없는, 근거 없는 자신감과 맹신이 마구 솟아 올라서 기능 구현하고 제대로 테스트를 안했던 것 같다.

정상 케이스만 띡 테스트 해보고 예외 케이스에도 제대로 돌아갈 것이라 상상하는 무지성 무뇌 개발;

몇번 큰코 다치고 나서야 이제는 최대한 다양한 케이스로 테스트 해보려고 하고 있으나 포스트맨 <-> 인텔리제이 왔다 갔다 하기 여간 귀찮은게 아니다.

이것에 대한 액션 아이템으로는, 위 1번 테스트 코드 작성 항목에 대한 액션 아이템을 잘 수행하면 되지 않을까 싶다.

오랜만에 작성해보는 포스팅 정신 못차리겠다.

각 항목마다 한개씩만 쓰고 끝내려다가 채찍질하며 겨우 두개씩 작성했다.

2022년 안녕, 2023년 안녕~

[Java] Method Naming Convention (feat. of vs from)

대흉근 — Sun, 4 Sep 2022 23:09:15 +0900

현재 내가 참여 중인 프로젝트에서는 정적 팩토리 생성자를 이용하여 객체를 생성하는 경우가 많은데,

다른 프로젝트의 코드 리뷰를 하면서 보니 그러한 생성자 네이밍에도 뭔가 규칙이나 컨벤션이 있을 것 같았다.

물론 정적 팩토리 생성자의 장점 중 하나가 create, make 등 생성자 이름에 의미를 부여할 수 있다는 것이지만,

나는 흔히들 쓰는 of, from의 차이가 궁금했다.

우연히 개발자 단톡에서 아래와 같은 Java 공식 문서를 공유 받아, 간략하게 정리해보려고 한다.

- [Oracle] Method Naming Conventions

어떤 문서냐?

위 문서에서는 Java의 Date-Time API에서 사용 중인 여러 클래스의 다양한 메소드 네이밍 컨벤션을 표로 정리했다.

문서를 해석해보자면,

그러한 메소드의 이름들은 가능하면 클래스들 간에 일관성 있도록 만들어졌는데,

예를 들어 now 라는 메소드를 제공하는 많은 클래스들은 해당 클래스와 관련있는 현재 순간의 시간을 return 한다.

또다른 예시로는 하나의 클래스로부터 다른 클래스로 변환하는 역할을 하는 from 이라는 이름의 메소드들도 존재한다.

메소드 이름의 prefix와 관련된 표준화도 존재하여 Java Date-Time API들은 모두 그 표준화를 따르는데,

이 부분이 내가 알고 싶었던 부분이다.

Static Factory Method Prefix Convention

메서드 타입이 instance인 녀석들은 Data-Time과 관련된 인스턴스 prefix 이름들이라 자세히 볼 필요는 없을 것 같고,

나한테 필요한 정보는 메서드 타입이 static factory인 녀석들이다.

of

팩토리 메서드의 파라미터로 넘어온 값들을 검증하여 인스턴스를 생성할 때 사용한다.

DTO 같은 것이 넘어와 걔네들을 인스턴스로 변환하는 것이 아니다.

from

팩토리 메서드의 파라미터로 넘어온 값들을 해당 클래스의 인스턴스로 변환할 때 사용한다.

이 과정에서 파라미터의 값들 중 일부는 유실될 수 있다.

parse

팩토리 메서드의 파라미터로 넘어온 string 값을 파싱하여 해당 클래스의 인스턴스로 만들 때 사용한다.

Java에서 사용하는 Data-Time API에만 적용되는 내용일 수도 있지만,

읽어보면 우리가 코딩하면서 충분히 사용할 수 있는 것들이라고 생각한다.

끝!

[Git] rebase vs merge, 무엇이 더 좋을까?

대흉근 — Sun, 7 Aug 2022 23:22:14 +0900

최근 팀 내에서 git rebase를 사용하다가 조그마한 사고가 있었다는 이야기를 듣고,

482번째 rebase에 대해 다시 검색하면서 알아보다가 이대론 안되겠다 싶어 글로 남겨 기억에 남기고자 한다.

아래 링크에 들어가면 볼 수 있는,

아주 아주 아주 이해하기 쉽게 잘 써놓은 블로그를 우연히 만나 거의 번역 수준으로만 작성할 예정 ㅎ;

다시 보니 Edureka라는 온라인 교육 플랫폼에서 운영하는 블로그 같다.

아래 글은 git이 어떻게 동작하는지, commit은 무엇이고 branch는 무엇인지부터 시작하지만,

그 부분은 건너 뛰고 git에서의 merging 이라는 개념부터 ~~번역을~~ 작성하려고 한다.

- Git Rebase vs Git Merge: Which is Better?

Merging이란?

Merging이란 개념은 보통 무언가를 하나의 개체로 합치는 것을 의미한다.

Git에서의 Merge 개념은 이러한 개념과 유사한데,

하나의 branch에서 발생한 변화들을 다른 branch에 포함시켜 다시 하나의 branch로 합치는 것을 의미한다.

출처) https://www.edureka.co/blog/git-rebase-vs-merge/amp/#What-is-Merging?

위처럼 merging 전의 두 브랜치가 있다고 가정해보자.

파란색 commit들이 있는 branch가 master branch, 노란색 commit들이 있는 branch가 feature branch이다.

master의 '2' commit 이후에 feature를 만들어 'A', 'B' commit을 했고,

그 동안 master에서도 '3' commit 작업이 이루어졌다.

당연히 현재 master 입장에서는 'A', 'B' commit의 존재를 알 수 없고,

마찬가지로 feature 입장에서도 '3' commit의 존재를 알 수 없다.

출처) https://www.edureka.co/blog/git-rebase-vs-merge/amp/#What-is-Merging?

그래서 master branch에 feature branch를 merge 하기 위해,

위처럼 feature를 master에 merge 하여 '4'라는 commit을 만들어냈다.

즉, 이 master의 '4'라는 commit은 '1', '2', '3', 'A', 'B'의 commit 정보들을 모두 담고 있다.

이와 같은 작업을 merging이라 하며,

git에서는 다음 두 가지 기능으로 merging 기능을 제공한다.

Git Merge란?

Git Merge는 branch들의 commit 이력들이 모두 온전하게 보존되는 merging 기법이다.

(이 부분이 Git Rebase와의 가장 큰 차이점)

출처) https://www.edureka.co/blog/git-rebase-vs-merge/amp/#What-is-Merging?

다시 예제를 가져와, 위처럼 master branch에서 '1', '2', '3' commit이 발생하였고,

feature branch에서 'A', 'B' commit이 발생했다고 가정하자.

만약 우리가 master branch에서 Git Merge 작업을 진행한다면,

feature branch의 'A', 'B' commit은 그대로 master branch의 '4' commit에 반영되어 merge 될 것이다.

장점

- commit 로그들이 매우 철저하게 유지되기 때문에 어떻게, 언제 각 meger가 진행됐는지 온전한 히스토리를 파악하는 데에 큰 도움이 된다.

- 이 때문에 실수를 찾기 쉽고 해결하기도 용이하다.

단점

- 아래처럼 여러 branch들이 merge 되는 경우, 보기도 힘들고 다루기도 힘든 log history가 발생할 수 있다.

- 이 때문에 매우 user-friendly 하지 못하다.

출처) https://www.edureka.co/blog/git-rebase-vs-merge/amp/#What-is-Merging?

Git Rebase란?

Git Merge와 매우 유사한 기능을 하는 Git Rebase는 merge 이후에 log들이 수정된다는 차이점이 있다.

Git Merge의 한계를 극복하기 위해 추가된 기능인데, log history를 직선 모양(linear)으로 만들어준다.

출처) https://www.edureka.co/blog/git-rebase-vs-merge/amp/#What-is-Merging?

다시 위와 같은 예제를 가져와 보자.

master branch에서 '1', '2', '3' commit이 발생하였고, feature branch에서 'A', 'B' commit이 발생했다.

만약 우리가 master branch에서 Git Rebase 작업을 진행하면,

'A', 'B' commit들은 master branch의 '4', '5' commit으로 rebase 되고,

feature branch에는 더 이상 log가 존재하지 않게 된다.

장점

- log history가 직선 모양이다.

- 그 덕에 프로젝트를 쉽게 이동할 수 있다.

단점

- feature branch의 log history가 사라지기 때문에 target branch에 언제, 어떻게 commit들이 merge 되었는지 알 수가 없다.

Git Merve vs Git Rebase

Git Merge	Git Rebase
branch들을 merge 할 수 있는 Git의 명령어이다.	개발자들이 하나의 branch에서 다른 branch로 변화들을 통합시킬 수 있는 명령어이다.
merge 이후에도 log history가 온전한 형태로 남아있다.	merge 이후에 log history가 직선 형태로 수정된다.
feature branch의 모든 commit들이 master branch의 단 하나의 commit으로 병합된다.	feature branch의 모든 commit들이 master branch에 같은 수 만큼의 commit들로 rebase되어 추가된다.
target branch가 다른 사람들과 공유되는 branch인 경우 사용된다(ex. master branch).	target branch가 private branch인 경우 사용된다.

언제 어느 것을 사용해야 할까?

출처) https://www.edureka.co/blog/git-rebase-vs-merge/amp/#What-is-Merging?

위 그림에서 볼 수 있듯이,

Git Merge와는 다르게 Git Rebase에서는 'A', 'B' commit들이 어디서 언제 발생했는지 알기가 힘들다.

그러므로 commit log history를 다른 사람들 혹은 팀원들이 알 필요가 없는 경우,

즉, 다른 개발자들이 볼 필요가 없고 볼 수가 없는 개인적인 작업을 하는 branch에서는 Git Rebase를 사용하고,

target branch와 source branch 모두 다른 개발자들이 볼 수 있다면 Git Merge를 사용하자.

Git Merge와 Git Rebase를 함께 사용하는 방법

출처) https://www.edureka.co/blog/git-rebase-vs-merge/amp/#What-is-Merging?

위처럼 master branch에 '1', '2', '3' commit들이 존재하고,

'A', 'B'라는 commit들이 존재하는 feature branch 1,

'C', 'D'라는 commit들이 존재하는 feature branch 2가 존재하고 있는 프로젝트를 가정해보자.

이러한 상황이 만들어진 원인은 다음과 같다.

- 개발자 대흉근은 master branch의 '2' commit 이후에 feature branch 1을 생성하여 개인적인 작업을 하고 있다.

- 본인이 만든 코드에 좀 더 실험을 해보고 싶어서 'A' commit 이후 feature branch 2를 생성했다.

- feature branch 2에서 'C', 'D' commit을 날려 실험을 성공적으로 마무리했다.

출처) https://www.edureka.co/blog/git-rebase-vs-merge/amp/#What-is-Merging?

하지만 대흉근은 feature branch 2라는 private한 branch의 존재를 누구도 알 필요가 없다고 생각했기 때문에,

위처럼 feature branch 1에 feature branch 2를 rebase하는 작업을 진행했다.

출처) https://www.edureka.co/blog/git-rebase-vs-merge/amp/#What-is-Merging?

이제 대흉근은 feature branch 1을 master branch에 merge하는 작업을 진행했고,

위와 같은 commit log history가 최종적으로 만들어졌다.

다음 날, 출근을 한 다른 개발자들이 master branch에서 pull 작업을 진행했고,

'feature branch 1에서 'A', 'B', 'C', 'D' commit이 만들어졌구나' 정도만 알 수 있게 된다.

이제 진짜 더이상 git rebase와 git merge의 차이에 대해 알아보지 않아도 될 것 같다 (ㅋㅋ).

그만큼 글 초반부에 언급했던 블로그가 굉장히 큰 도움이 되었다.

이 포스팅을 작성하면서,

회사에서 내가 작업한 branch를 master에 merge하면 왜 commit history가 지저분하게 나오는지 이해됐다..

끝!

[회고][2022년 상반기] 바쁘다 바빠! 그래도 행복하다!

대흉근 — Sun, 10 Jul 2022 11:08:14 +0900

올해 2월, 이직에 성공하고 벌써 4개월이나 흘렀다.

정말 바쁘면서 알차게 시간을 보내고 있는데, 기록을 좀 남겨보고 싶어서 상반기 회고를 써보려고 한다.

2022년 1월

작년 12월 31일에 최종 합격하고 펑펑 놀았다.

인센티브 때문에 바로 그만두지 못해서 이직 텀이 일주일 정도밖에 없긴 했지만,
다행히 재택근무를 할 수 있어서 인수인계만 하고 나머지 시간은 심신의 휴식을 취했다 ㅎㅎ

취준생부터 쭉 써왔던 블로그도 잠깐 쉬어가기로 결정했는데,
이직하고 바쁘고 정신없어서 지금까지도 이전처럼은 글을 주기적으로 작성하지 못하고 있다.

퇴사 과정에서 인사팀이랑 좀 충돌이 있긴 했지만, 뭐, 좋게 좋게 잘 해결했고..

하여튼 1월은 머리털 나고 이렇게 행복한 적이 있던가 싶을 정도로 놀고 즐겼다.

2022년 2월

코로나에 걸려버렸다....
이전 회사 퇴직일이 2월 4일이었고, 현 회사 입사일이 2월 14일이어서 정말 자유롭게 놀 시간도 얼마 없었는데 ㅠㅠ

하여튼 아슬아슬하게 격리 기간이 딱 끝나면서 무사히 입사할 수 있었다.

지금은 일주일로 바뀐, 신규 입사자 온보딩 기간인 2주 동안 회사 적응에 힘썼다.

그런데 너무 짧게 쉰 탓일까?..
1월 동안 인수인계만 하면서 쉬었다곤 해도, 잔잔바리 일은 계속 처리하기도 해서 그런가?..

입사하자마자 뭔가 번 아웃이 온 느낌이었다.

그래서.. 온보딩 기간을 이용해 최대한 더 쉬었다 ㅋㅋ
짧지만 지금까지 살아오면서 이럴 때, 나는 뭘 더 하려고 하면 항상 역효과가 났기 때문에..

다행히 금방 극복함 ㅎ

2022년 3-4월

올해 말 출시 목표인 신규 서비스 개발에 투입되기로 결정되었다.

서비스의 A부터 Z까지 모든 개발 과정에 참여할 수 있는 기회가 주어져 정말 기쁘기도 했고,
프로젝트 백엔드 메인 개발자 팀원 분께서 기술 스택들과 설계를 굉장히 세련되게 해주셔서 커리어적인 측면에서도 큰 도움이 될 것 같았다.

하지만 백엔드 실무를 처음 겪어보는 만큼, 모르는 것 투성이었다;

Spring은 동영상 강의라도 몇 개 들어봐서 아주 조금 익숙하지만, java는 살면서 거의 안 써봤다고 해도 무방할 정도라, 3, 4월은 거의 맨날 자정이 넘어서까지 야근의 연속이었다 ㅋㅋ

이때까지만 해도 재택근무가 자유로워, 맨날 집에서 일했기 때문에 가능했던 것 같다.

그리고 회사에 슬슬 적응하면서 "팀 내 개발 문화 조성 기여"라는 나만의 작은 목표를 하나 세웠고 개인 OKR에도 작성했다.
각종 SNS의 개발자 커뮤니티와 오픈 카카오톡 방에서 좋은 글들이 많이 올라왔기 때문에 자주 공유할 수 있었다.

2022년 5-6월

백엔드 파트 내 팀원 분과 리더님의 슬랙인데, 3-4월에 세웠던 작은 목표가 생각보다 더 빨리 이루어지고 있는 것 같아서 뿌듯하다 키킼;

이제 어느 정도 API 개발 업무가 손에 익어 가는데, 점점 더 Java와 Spring의 기본기가 탄탄하게 필요로 한다는 것을 느꼈다.
그래서 요즘엔 퇴근 후에 인프런 김영한님 강의를 복습 중이다.

2022년 7월

(220821) 자랑 추가 ㅎ

끝!

[Java][Jackson][Spring] @JsonIgnoreProperties(ignoreUnknown=true)? 꼭 필요한가?

대흉근 — Sun, 26 Jun 2022 21:53:24 +0900

지난 주, 팀에 새롭게 합류하신 계약직 개발자 분의 첫 코드 리뷰를 진행했다.

@JsonIgnoreProperties(ignoreUnknown=true) 라는 처음 보는 어노테이션을 발견했는데,

어떤 역할을 하는 녀석인지, 꼭 필요한 기능인지 등 팀원들과 논의했던 결과를 기록한다.

@JsonIgnoreProperties(ignoreUnknown=true) ?

공식 문서에서 어떤 역할을 하는지 쉽게 예를 들어 설명해주고 있다.

읽어보면 이름을 정말 직관적으로 잘 지었다는 생각이 든다.

Annotation that can be used to either suppress serialization of properties (during serialization), or ignore processing of JSON properties read (during deserialization).

Example:
// to prevent specified fields from being serialized or deserialized
// (i.e. not include in JSON output; or being set even if they were included)
@JsonIgnoreProperties({ "internalId", "secretKey" })
// To ignore any unknown properties in JSON input without exception:
@JsonIgnoreProperties(ignoreUnknown=true)

Annotation can be applied both to classes and to properties.
If used for both, actual set will be union of all ignorals: that is, you can only add properties to ignore, not remove or override. So you can not remove properties to ignore using per-property annotation.

이 어노테이션의 역할은 역직렬화(deserialization) 과정에서,

즉, JSON 데이터를 읽어 객체에 매핑해주는 과정에서 객체에 없는 알 수 없는 property가 JSON 데이터에 있어도 에러를 내뱉지 않고 무시해준다는 것이다.

예시

쇼핑몰의 특정 상품의 가격을 바꾸는 API를 통해 이 어노테이션을 사용하는 예를 러프하게 하나 들어보자.

(1) 클라이언트 측에서는 해당 API의 Request Body에 아래와 같은 JSON 형태의 데이터를 담아 서버에 요청한다.

{
    "price": 24000
}

(2) 서버에서는 요청 정보를 아래와 같은 PriceChangeRequest라는 객체로 받는다.

public class PriceChangeRequest {
    private final int price;
}

근데 만약, 클라이언트 측에서 아래처럼 서버에는 없는 key-value를 추가한다면?

{
    "price": 24000,
    "unknown_property": "yeahyeah"
}

이러한 케이스를 대비하는 설정이 프로젝트에 적용되어 있지 않다면 에러가 발생할 것이다.

이때 @JsonIgnoreProperties(ignoreUnknown= rue)을 아래처럼 PriceChangeRequest 클래스에 붙여주게 되면,

에러가 발생하지 않고 스무스하게 넘어간다.

@JsonIgnoreProperties(ignoreUnknown = true)
public class PriceChangeRequest {
    private final int price;
}

꼭 필요한가..?

이 어노테이션이 어떤 역할을 하는지 찾아보고 난 뒤 의문이 들었다.

평소 API 개발하고 테스트할 때, 위에서 언급한 예시와 같은 상황이 가끔 있었는데 에러가 발생하지 않았기 때문이다.

좀 더 찾아보니, yml 파일에 아래와 같은 설정을 추가하면 @JsonIgnoreProperties 어노테이션을 따로 붙여주지 않아도 동일한 기능이 프로젝트 전체에 적용된다고 하는데, 이런 설정도 되어있지 않았다.

deserialization: fail-on-unknown-properties: false

좀 더 찾아보고 있던 중에 팀원 분께서 아래와 같은 링크와 함께 의문을 해결해주셨다.

https://www.baeldung.com/spring-boot-customize-jackson-objectmapper

Spring Boot: Customize the Jackson ObjectMapper | Baeldung

Learn how to configure the serialization and deserialization options for Jackson using Spring Boot.

www.baeldung.com

이 글의 2. Default Configuration 파트를 보면 아래와 같은 문장들이 나온다.

By default, the Spring Boot configuration will disable the following:

MapperFeature.DEFAULT_VIEW_INCLUSION
DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES
SerializationFeature.WRITE_DATES_AS_TIMESTAMPS

중간에 볼드체로 표시해둔 부분!!

이미 최초 Spring Boot 환경설정에서 알 수 없는 property에 대해 에러가 발생하는 것을 disable 시켜버렸기 때문이다.

결론

1. Spring Boot 최초 환경설정에서 JSON 데이터에 알 수 없는 property가 있어도 무시하는 설정이 되어 있다.

2. 이 설정을 임의로 변경하지 않는 이상 @JsonIgnoreProperties(ignoreUnknown = true)는 필요없다.

[Trouble Shooting][Java] "An enum switch case label must be the unqualified name of an enumeration constant" 해결 방법

대흉근 — Fri, 10 Jun 2022 16:56:27 +0900

public enum UserStatus {
    NORMAL, DORMANT, SUSPENDED
}

위와 같은 enum 클래스가 있다고 가정하자.

UserStatus status = ...;

switch(status) {
    case UserStatus.NORMAL:
        ....
        break;
    case UserStatus.SUSPENDED:
        ....
        break;
}

위처럼 switch 문을 사용하면

"An enum switch case label must be the unqualified name of an enumeration constant" 라는 에러가 발생한다.

아래처럼 바꿔주면 에러는 사라진다.

UserStatus status = ...;

switch(status) {
    case NORMAL:
        ....
        break;
    case SUSPENDED:
        ....
        break;
}

[Lombok] 공식 문서를 통해 알아보는 @Value(feat. @ToString, @EqualsAndHashCode, @AllArgsConstructor, @FieldDefaults, @Getter) + 사용시 주의사항(단점)

대흉근 — Mon, 23 May 2022 00:16:38 +0900

객체를 클래스로 정의할 때, 자주 등장하는 녀석이다.

여러 기능들을 포함하고 있는 간편한 기능인데, 사용 시 주의해야 할 사항도 있으니 함께 알아보려고 한다.

아래 글과 블로그를 참고했다.

- @Value

- Lombok 사용상 주의점(Pitfall)

Overview

@Value 어노테이션은 @Data 어노테이션의 변형된 녀석인데, 특이한 점은 객체를 불변(Immutable)으로 만들어준다는 점이다.

여기서 불변(Immutable)이란, 객체 생성 후 그 상태를 수정할 수 없는 것을 뜻한다.

그렇기 때문에 객체의 상태를 변경할 수 있는 @Setter는 생성되지 않는다.

(@Setter, @Getter는 요즘 Spring 개발자치고 모르는 사람이 없을 정도로 기초적인 어노테이션이기 때문에 이 글에서는 굳이 설명하지 않겠다)

그리고 default 값으로, 객체 내부의 모든 field에 private과 final을 붙여준다.

field 뿐만 아니라 class에도 final을 디폴트 값으로 붙여주는데, 위에서 언급했듯이 객체를 불변(Immutable)으로 만들어주는 기능을 하기 때문이다.

이러한 불변성(Immutability) 때문에 자식 클래스(subclass)를 가질 수 없게 된다.

또한 @Data 어노테이션의 변형이기 때문에, 마찬가지로 유용하게 쓰일 수 있는 toString(), equals() 및 hashCode() 메소드도 자동 생성되며,

각 field의 getter 메소드 또한 자동 생성되고,

모든 argument를 포함하는 생성자(단, field 선언 시 초기화되는 final fields는 제외)도 자동 생성된다.

위와 같은 특성들 때문에, @Value는 아래 다섯 개의 어노테이션을 합친 약어라고 할 수 있다.

단, 아래에서 소개할 어노테이션들 중 관련된 메소드들을 직접 정의해도 warning이나 error는 발생하지 않고, 해당 어노테이션이 구현하는 메소드는 생성되지 않는다.

예를 들어, toString() 메소드를 직접 정의해도 괜찮고, @AllArgsConstructor 어노테이션이 @Value에 포함되어 있지만 클래스에 작성해줘도 괜찮다.

추가로, @Builder와 @Value가 클래스에 같이 붙어 있다면, @Value가 만드는 public allargs constructor 보다 @Builder가 만드는 private allargs constructor 가 우선순위가 높아, @Builder가 만드는 생성자가 생성된다.

1. @ToString

@ToString 공식 문서에 따르면,

이 어노테이션이 붙어있는 클래스는 lombok이 toString() 메소드를 자동으로 생성한다.

toString() 메소드도 워낙 유명하지만 간단히 짚고 넘어가자면,

Java의 모든 객체는java.lang.Object라는 최상위 부모 클래스를 상속받는데, 이 Object 클래스 안에는 아래와 같은 toString() 메소드가 있다.

public String toString() {
    return getClass().getName()+"@"+Integer.toHexString(hashCode());
}

객체에 대한 정보를 String으로 변환해주는 메소드이지만, 보다시피 객체의 이름과 hash code 값의 정보만 준다.

이 두 정보들로는 큰 의미가 없기 때문에 보통 Overriding 하여 프로그래머 입맛에 맞춰 커스터마이징을 하곤 했는데,

이 어노테이션을 사용하면, MyClass(foo=123, bar=234)와 같은 형태로 출력되는 toString() 메소드를 자동으로 만들어준다.

(class 이름이 먼저 나타나고 뒤에 괄호가 나타나며 콤마로 필드들이 구분되는 이 출력 형태는 고정되어 있어 바꿀 수 없다)

하지만 만약 이 쓸모없는 정보를 굳이 원한다면,

default 값이 false인 callSuper라는 옵션에 true 값을 주어 부모 클래스(Object 클래스)에 구현되어 있는, 위처럼 생긴 toString() 메소드의 출력 값을 얻어올 수 있긴 하다.

default 값이 true인 includeFieldNames라는 옵션에 true 값을 주어 표현의 명료성을 나타내며, toString() 메소드의 출력 값에 field 명이 나타나도록 할 수 있기도 하다(하지만 어노테이션 길이가 길어지는 단점이 존재..).

default 값으로 static이 아닌 모든 fields가 출력된다.

만약 특정 fields는 출력하기 싫다면, 해당 field들에 @ToString. Exclude라는 어노테이션을 주면 된다.

혹은 클래스에 @ToString(onlyExplicitlyIncluded = true)처럼 옵션을 주고, 출력되기 원하는 field에 @ToString. Include라는 어노테이션을 주는 방법도 있다.

이 @ToString.Include 어노테이션의 name이라는 옵션을 사용하면 해당 field 명을 다르게 출력할 수 있는데, @ToString.Include(name = "some other name")처럼 사용하면 된다.

또한 field들이 출력되는 순서 또한 rank라는 옵션을 통해 바꿀 수 있는데, @ToString.Include(rank = -1)처럼 사용하면 된다.

이 rank 옵션이 없는 field의 default rank 값은 0이며, rank 값이 높은(숫자가 작은) 순서대로 출력되며, 같은 rank 값이라면 field가 선언된 순서대로 나타난다.

2. @EqualsAndHashCode

(이 어노테이션은 추후 자세히 다뤄볼 생각이 있기 때문에 가볍게만 짚고 넘어가려고 한다)

@EqualsAndHashCode 공식 문서에 따르면,

이 어노테이션이 붙어있는 클래스는 lombok이 equals(Object other)과 hashCode() 메소드를 자동으로 생성한다.

equals(Object other)은 두 객체의 내용이 같은지, 동등성(equality)을 비교하는 메소드이고,

hashCode()는 두 객체가 같은 객체인지, 동일성(identity)을 비교하는 메소드이다.

3. @AllArgsConstructor

이전에 작성한 글 참고!

4. @FieldDefaults(makeFinal = true, level = AccessLevel.Private)

@FieldDefaults 공식 문서에 따르면,

class나 enum에 이 어노테이션이 붙어있으면, 내부의 각 field마다 접근 제어자(access modifier)와 final 키워드를 자동으로 추가한다.

먼저, 모든 field에 접근 제어자를 붙여주려면 level이라는 옵션의 값에 원하는 접근 제어자를 적어주면 된다.

예를 들어, 모든 field를 private로 만들려면 @FieldDefaults(level = AccessLevel.Private)처럼 사용하면 되고,

만약 어떠한 field에 이미 접근 제어자가 작성되어 있어도 @FieldDefaults 어노테이션이 적절하게 바꿔준다.

private로만 사용해야 하는 field가 있다면, 해당 field에 @PackagePrivate라는 어노테이션을 붙여주면 된다.

모든 field에 final 키워드를 추가해주려면 makeFinal라는 옵션의 값에 true를 주면 되고(@FieldDefaults(makeFinal = true)),

만약 final로 만들면 안 되는 field가 있다면, 해당 field에 @NonFinal라는 어노테이션을 붙여주면 된다.

5. @Getter

글 상단부에서 언급했듯이, @Setter와 @Getter는 요즘 모르는 Spring 개발자는 거의 없으므로 패-쓰.

주의사항 및 단점

@Value 어노테이션은 @AllArgsConstructor을 포함하기 때문에 이전에 작성한 글과 동일한 주의사항 및 단점을 갖고 있다.

그 때문에 혹자는 @Value 대신, 아래처럼 사용하는 것을 권장한다.

@Getter
@ToString
public class Customer {
    // private final을 직접 작성하여 field 생성
    // 생성자 혹은 equals(), hashCode() 메소드가 필요하다면 직접 작성
}

끝!

[Lombok] 공식 문서를 통해 알아보는 @NoArgsConstructor, @RequiredArgsConstructor, @AllArgsConstructor + 사용시 주의사항(단점)

대흉근 — Sun, 15 May 2022 23:04:30 +0900

Spring과 Lombok을 사용한다면 꼭 알고 있어야 하는 생성자 관련 어노테이션들이다.

아래 Lombok 공식 문서와 블로그를 참고로 글을 작성하였다.

- @NoArgsConstructor, @RequiredArgsConstructor, @AllArgsConstructor

- Lombok 사용상 주의점(Pitfall)

Overview

@NoArgsConsructor, @RequiredArgsConstructor, @AllArgsConstructor,

이 3형제는 이름에서부터 어떤 역할을 하는 어노테이션들인지 대략 짐작이 간다.

일단 3형제 뒤에 붙은 Constructor라는 단어로부터,

이 3형제는 프로그래머 대신 생성자를 만들어주는 역할을 한다는 것을 유추할 수 있다.

그러니까, 객체 내부에 선언되어 있는 특정 field마다 딱 1개의 값을 생성자 parameter로 받고,

이 값을 단순히 field에 assign 해주는 생성자를 생성한다는 의미다.

그 앞에 prefix처럼 붙은 NoArgs(NoArguments), RequiredArgs(RequiredArguments), AllArgs(AllArguments)도 대충 예상이 가는데 (Argument와 Parameter의 차이는 이 글을 참고),

아래 샘플로 만들어둔 Customer(손님) 객체를 변형해가면서 하나씩 자세히 알아보자.

public class Customer {
    private Long id;
    private String name;
    private int age;
}

@NoArgsConstructor

얘는 파라미터가 없는 기본 생성자를 만들어준다.

즉, @NoArgsConstructor가 붙어있는 객체의 인스턴스를 만들 때,

아래처럼 argument를 하나도 넘기지 않으며 생성자 호출을 할 수 있다.

@NoArgsConstructor
public class Customer {
    private Long id;
    private String name;
    private int age;
}


Customer customer = new Customer();

하지만 만약, 항상 초기화가 필요한 final이 붙은 field가 있는데 @NoArgsConstructor을 사용한다면 compile error가 발생할 것이다.

대신, @NoArgsConstructor(force = true)처럼 force라는 옵션에 true 값을 주면, 모든 final fields는 0 / false / null로 초기화된다.

그런데 field에 final이 아닌 @NonNull 같은 제약이 있는 어노테이션이 붙어있다면,

얘는 force = true 옵션을 주어도 생성자에 들어가지 않기 때문에 나중에 프로그래머가 할당해주어야 한다.

hibernate나 Service Provider Interface 같은 특정 Java 구성에서 필요로 하고,

주로 @Data나 어노테이션을 생성하는 생성자 등과 함께 사용된다.

@RequiredArgsConstructor

얘는 특별한 처리가 필요한 각 field마다 하나의 parameter를 갖는 생성자를 생성해준다.

초기화되지 않은 모든 final fields와,

선언될 때 초기화되지 않은 @NonNull로 표시된 field까지 parameter를 가진다.

특히 @NonNull이 달려있는 field의 경우, 생성되는 생성자 내부에 명시적인 null 체크 로직 또한 생성된다.

그래서 만약 @NonNull이 붙어있는 field 중 어떠한 것이라도 null 값을 포함한다면 NullPointerException이 발생하게 된다.

생성자의 Parameter의 순서는 클래스 내부에서 선언된 field의 순서로 매칭 된다.

사용 방법은 아래와 같다.

@RequiredArgsConstructor
public class Customer {
    private final Long id;
    private String name;
    private int age;
}


Customer customer = new Customer(3L);

@AllArgsConstructor

얘는 클래스 내부에 선언된 모든 field마다 하나의 parameter를 가진 생성자를 생성한다.

@NonNull이 붙어있는 field의 경우, 역시나 생성되는 생성자 내부에 해당 parameter에 null check 로직이 생성된다.

@RequiredArgsConstructor와 마찬가지로, 생성자의 Parameter의 순서는 클래스 내부에서 선언된 field의 순서로 매칭 된다.

사용 방법은 아래와 같다.

@AllArgsConstructor
public class Customer {
    private final Long id;
    private String name;
    private int age;
}


Customer customer = new Customer(2L, "김철수", 23);

Alternate Form

이 3형제는 alternate form, 즉 위 사용법과는 조금 다른 대체 형식으로도 사용이 가능한데, 다음과 같다.

우선 3형제가 생성하는 생성자의 접근자는 모두 private이고,

만들어진 이 private 생성자를 감싸는 추가적인 static factory method를 사용하여 인스턴스 생성이 가능하다는 것이다.

이 모드는 위 어노테이션 3형제의 옵션 중 staticName이라는 것에 값을 주면 되는데,

예를 들어, @RequiredArgsConstructor(staticName="of")라고 주게 되면 of라는 키워드를 사용할 수 있다.

이런 static factory matod를 사용하게 되면,

new MapEntry<String, Ingeger>("foo", 5);와 같이 생성자 호출을 하지 않고

MapEntry.of("foo", 5)처럼 훨씬 짧으면서 뜻이 명확한 코드로 생성자 호출이 가능하다.

주의사항 및 단점

@AllArgsConstructor와 @RequiredArgsConstructor는 심각한 버그를 발생할 수 있어서 사용 시에 주의하거나,

아예 사용을 권하지 않는 경우도 있다.

이번에는 아래와 같은 Order이라는 객체를 만들어 살펴보자.

@AllArgsConstructor
public class Order {
    private int cancelAmount;
    private int orderAmount;
}


// 취소수량 4개, 주문수량 5개
Order order = new Order(4, 5);

위에서 언급했던 것처럼 @AllArgsConstructor 어노테이션은 생성자를 생성할 때,

class 내부에 선언된 field의 순서인 cancelPrice, orderPrice 순으로 생성자 파라미터를 생성한다.

그런데 만약 프로그래머가 orderAmount와 cancelAmount가 선언된 순서가 마음에 들지 않아,아래처럼 바꾸게 된다면?

@AllArgsConstructor
public class Order {
    private int orderAmount;
    private int cancelAmount;
}

이 경우, IDE가 제공해주는 리팩토링은 작동하지 않게 되고, lombok도 변화를 알아채지 못한다.

심지어 orderAmount, cancelAmount는 int라는 동일한 type을 갖고 있어 더욱 버그를 잡기 어렵다.

그래서 기존에 사용하던 new Order(4, 5)로 객체의 인스턴스를 만들어도 아무 에러없이 잘 동작할테지만,

실제로 입력되는 값은 취소수량과 주문수량이 뒤바뀌어 들어가는 심각한 비즈니스 로직 에러를 발생시킨다.

이 때문에 @AllArgsConstructor와 @RequiredArgsConstructor의 사용을 금지하는 것이 좋다는 주장도 있고,

그 대신, IDE 자동 생성 기능 등으로 아래처럼 생성자를 직접 만들고,

필요한 경우에는 직접 만든 생성자에 @Builder 어노테이션을 붙이는 것을 권장하기도 한다.

이 방법은 파라미터 순서가 아닌 이름으로 값을 설정하기 때문에 리팩토링에 유연하게 대응이 가능하다.

public class Order {
    private int cancelAmount;
    private int orderAmount;
    
    @Builder
    private Order(int cancelAmount, int orderAmount) {
        this.cancelAmount = cancelAmount;
        this.orderAmount = orderAmount;
    }
}


// field 순서를 변경해도 에러가 없다.
Order order = Order.builder().orderAmount(5).cancelAmount(4).build();

끝!

[Trouble Shooting][Spring] 파일 업로드 용량 제한 설정 방법

대흉근 — Tue, 19 Apr 2022 17:06:07 +0900

MultiPartFile 타입으로 파일 업로드 테스트를 하던 중 아래와 같은 에러가 발생했다.

The field file exceeds its maximum permitted size of 1048576 bytes

아래 Stack Overflow에서 해결 방법을 찾았음.

https://stackoverflow.com/a/48428279

How to set the max size of upload file

I'm developing application based on Spring Boot and AngularJS using JHipster. My question is how to set max size of uploading files? If I'm trying to upload to big file I'm getting this informatio...

stackoverflow.com

[Java] removeIf 사용법

대흉근 — Fri, 1 Apr 2022 23:27:47 +0900

아래 사이트에 removeIf를 사용하는 다양한 방법이 소개되어있다.

https://www.tabnine.com/code/java/methods/java.util.ArrayList/removeIf

java.util.ArrayList.removeIf java code examples | Tabnine

public boolean revokeApprovalsForUser(String userId, final String zoneId) { return store.removeIf(approval -> userId.equals(approval.getUserId()));

www.tabnine.com

[Algorithm][LeetCode][Easy][Python] 70. Climbing Stairs

대흉근 — Mon, 7 Mar 2022 14:48:03 +0900

문제는 여기서 볼 수 있다.

문제가 정말 심플하면서 Dynamic Programming(이하 DP) 방식의

기초 활용법을 느낄 수 있는 문제라 생각하여 포스팅한다.

분석

문제는 아주 간단하다.

n개의 계단이 있는 꼭대기까지 도달 가능한 경우의 수를 구하는 문제다.

대신 한 번에 1개 혹은 2개의 계단을 올라갈 수 있다.

처음부터 경우의 수를 따져보면 쉽게 패턴을 발견할 수 있다.

(1)은 1개의 계단을 올라가는 기호,

(2)는 2개의 계단을 올라가는 기호로 사용하겠다.

if n == 1:

경우의 수는 아래 딱 한 가지뿐이다.

- (1)

if n == 2:

경우의 수는 아래 두 가지이다.

- (1) (1)

- (2)

if n == 3:

경우의 수는 아래 세 가지이다.

- (1) (1) (1)

- (1) (2)

- (2) (1)

이런 종류의 문제를 많이 풀어본 사람이라면

여기서 벌써 패턴을 발견할 수 있겠지만 두 단계만 더 가보자.

if n == 4:

경우의 수는 아래 다섯 가지이다.

- (1) (1) (1) (1)

- (1) (1) (2)

- (1) (2) (1)

- (2) (1) (1)

- (2) (2)

if n == 5:

경우의 수는 아래 여덟 가지이다.

- (1) (1) (1) (1) (1)

- (1) (1) (1) (2)

- (1) (1) (2) (1)

- (1) (2) (1) (1)

- (2) (1) (1) (1)

- (1) (2) (2)

- (2) (1) (2)

- (2) (2) (1)

풀이

n이 3 이상일 때, 경우의 수는 아래와 같다.

(n의 경우의 수) = (n-1의 경우의 수) + (n-2의 경우의 수)

왜일까?

n-1일 때, n에 도달하려면 딱 1개의 계단만 더 가면 되고,

n-2일 때, n에 도달하려면 1개 혹은 2개의 계단만 더 가면 되기 때문이다.

좀 더 이해하기 쉽도록 n이 4일 때를 보자.

n-1은 3이므로 해당 경우의 수마다 뒤에 (1)을 붙이면

n에 도달하는 경우의 수들 중 일부가 된다.

또한, n-2은 2이므로 해당 경우의 수마다 뒤에 (1) 혹은 (2)를 붙일 수 있는데,

(1)를 붙이게 되면 n-1인 경우의 수와 겹치게 되므로

(2)만 붙여주면 된다.

그래서 위와 같은 식을 구할 수 있는 것이다.

코드는 아래와 같으며 꽤 준수한 퍼포먼스를 보여준다.

class Solution:
    def climbStairs(self, n: int) -> int:
        dp = [1, 2] + ([0] * (n-2))
        for idx in range(2, n):
            dp[idx] = dp[idx-1] + dp[idx-2]
        return dp[n-1]

끝!

[DB] Flyway에 관한 좋은 글

대흉근 — Mon, 21 Feb 2022 13:11:59 +0900

Git, SVN 등을 통해 소스코드 형상 관리를 하는 것처럼 DB도 형상관리가 가능하다.

그러한 tool 중 많이 쓰이는 것이 바로 Flyway이다.

Flyway 공식 홈페이지에서 Documentation을 봐도 좋고,

간단하게 개념을 잡으려면 비록 6년전 글이지만 여기도 괜찮다.

[ETC] Firebase에 관한 좋은 글

대흉근 — Thu, 17 Feb 2022 09:36:36 +0900

취준을 하며 많이 본 서비스이지만,

현재 온보딩 기간 중인 이직한 회사에서 실제로 사용 중인 것을 알게 되었다.

그래서 좀 더 확실히 알기 위해 정보를 찾아보다가

늘 좋은 기초 정보를 얻는 위시캣(IT아웃소싱 업체) 블로그에서 좋은 글들을 찾아서 남긴다.

'파이어베이스'(Firebase)란 무엇인가? 파이어베이스 심층 탐구 : 상편

'파이어베이스'(Firebase)란 무엇인가? 파이어베이스 심층 탐구 : 중편

'파이어베이스'(Firebase)란 무엇인가? 파이어베이스 심층 탐구 : 하편

[회고][2021년] feat. 첫 직장 입사 두 달 만에 이직을 결심하게 된 이유

대흉근 — Sat, 1 Jan 2022 02:57:02 +0900

2020년 10월부터 정말 간절히 작성하고 싶었던 글이다.

1년 여간 엄청났던 스트레스에 밤 잠을 설치고 머리가 빠져가며 땅이 꺼져라 한숨을 폭폭 내쉬었던 나날들이었다.

2021년 회고록

2020년 9월, 첫 정규직 입사를 하고 본격적으로 홀로 운영 업무를 진행했던 해였다.

SQL을 제외하고는 업무를 하며 개발자로서의 역량을 많이 키우지 못했는데,
시스템이 협력사 솔루션 범벅으로 구성되어 있어 무언가 깊게 알아보려고 해도 협력사 측에 따로 요청해야 했기 때문이다.

하지만 고객사의 시스템을 운영하는만큼, 여러 부서의 사람들과 의사소통하며 커뮤니케이션적인 부분에서 많이 성장했음을 느꼈다.

하여튼, 그래서 회고록 파트에서는 개발적인 부분에서 그다지 작성할 것이 없다.
대신 취업 사기(?)를 당했다고 말하고 싶을 정도로 입사하자마자 이직을 결심하게 되고, 심적으로 굉장히 힘들었던 이야기들을 풀고자 한다.

취업 사기(?)

출처)&nbsp;https://job.incruit.com/jobdb_info/jobpost.asp?job=2005250000885

내가 현재 재직 중인 회사와 팀은 이 블로그의 취업 준비 글들과 Notion 이력서를 보면 알 수 있기 때문에 따로 숨기지는 않겠다.

2020년 상반기, 나는 CJ올리브네트웍스라는 회사에서 올라온 채용 공고를 보게 되었다.

'DT DevOps Engineer'라는 직무의 수행업무 부분에서 볼 수 있듯이,
'Live Commerce 서비스 개발 및 Kubernetes 패키징'이라는 업무 내용과 도메인이 내가 생각하고 계획해둔 개발자 커리어와 부합하여 해당 직무로 지원했다.

1차 면접에서는 (지금은 다른 팀으로 가신) 현재 내가 속해 있는 부서의 팀장님과 라이브 커머스 팀의 팀장님이 면접관으로 들어오셨다.
나와 같이 면접을 보았던 지원자 분도 당연히 라이브 커머스 수행 업무를 보고 지원했고, 면접관님들의 질문에 답하며 우리 둘은 라이브 커머스에 관한 이야기를 계속 꺼냈다.

여기서부터 좀 이상했다.

팀장님 한 분께서 이런 말씀을 하신다.
'아니, 왜 지원자들이 다 라이브 커머스 이야기만 하지?'
당황했지만 채용 공고에 그렇게 올라와 있다고 말씀드렸고, '엇, 인사팀에서 채용 공고를 누락해서 올렸네'하고 넘어가셨다.

여차저차 나를 포함한 세 명이 해당 직무로 최종 합격했고,

'내 뼈는 CJ에 묻는다'는 마음으로 입사하여 한 달여간 그룹 및 계열사 교육을 받고 부서 배치를 받게 되었다.

어디로? 'AI팩토리팀'으로..
진짜 심장이 철렁 내려앉았다.

출장이 잦고 소프트웨어적인 부분을 중시하지 않는 경향이 있는 제조업은 취업 준비할 때도 패스했던 도메인이기 때문이다.
대체 왜 이런 대참사가 일어났는지 영문을 모르겠던 중, 부서 배치 며칠 전 진행되었던 '부서 배치 면담'이 불현듯 떠올랐다.

그 면담에서 인사팀 분께서는 사실 라이브 커머스 팀의 TO는 최대 2자리이며, 한 명은 다른 곳으로 가야 한다고 말씀하셨다.
취업 성공에 들떠있고 신나 있던 나는 아래처럼 호기롭고 패기롭게 외쳤었다.

'저는 라이브 커머스가 아니어도 일반적인 IT 서비스를 하는 곳이면 좋습니다!'

왜냐하면 라이브 커머스 팀이 있던 부서에 pg 모듈, 결제 등 담당하는 팀도 있었고,
설마 제조업을 하는 팀이 그러한 IT 서비스 부서에 묶여있을 줄은 상상도 못 해서 제조업 쪽은 기피한다고 언급할 생각도 못했다.

진짜 똥을 한 무더기로 씹은 얼굴로 팀원 분들과 첫인사를 하고 코로나 덕에 쓰고 있던 마스크에 고마운 마음이 들며,
배정된 자리에 앉아 오전 오후 내내 멍 때리고 고민했다.

결국 퇴근 시간이 다 되었고 각 신입 사원에게 배치되었던 팀 내 멘토님에게 현재 내 상황을 오픈하고 조언을 구하기로 결심했다.

면담, 면담, 그리고 면담

다행히 멘토님께서는 내 상황을 이해해주시고 공감해주시며 아래 두 가지 선택지를 주셨다.

(1) 팀장님에게도 오픈하여 최종적으로는 인사팀과 컨택을 취해 팀 옮기기
(2) 2-3년 정도 버티다가 사내 전배 시스템 or 이직

(2)번 선택지는 2-3년을 버텨야 한다는 조건이 있었기에,
도저히 제조업에서 커리어를 시작하기 싫었던 나는 팀 사람들과는 어색해질 수밖에 없는 상황이 오게 될 (1)번 선택지를 결심했고, 다음 날 팀장님께 면담을 신청하여 내 상황을 오픈했다.

하지만 인생이 내 마음대로 흘러간다면 난 이미 요트 위에서 놀고 있었겠지.

멘토님과는 다르게,
'야, 제조업이든 뭐든 뭔 상관이야. 일 해보지도 않았잖아.',
'팀 사람들이랑 좀 더 이야기해보고 그래도 마음이 안 바뀌면 다시 말해.' 등 어느 정도 이해가 되는 부정적인 반응을 보여주셨다.

그래서 다른 팀 분들과도 몇 차례 이야기를 나누어보니,
'아, 여기 있으면 개발자로의 인생은 절단 나겠다'라는 생각이 더욱 확고해졌고,
다시 면담을 신청하여 결국 팀장님 손을 떠나 인사팀으로 사안이 넘어가게 되었다.

채용 담당자였던 인사팀 분도 이 상황을 알게 되었고,
내가 인사팀 높은 분과의 면담을 진행하고 나면 아마 팀이 바뀔 것 같다는 긍정적인 예측을 해주셔서 마음이 한결 가벼워지며 그분과의 면담만 기다렸다.

그 분 별명이 '인사팀 저승사자'인 것을 알게 된 건 한참 뒤의 일이다.

면담 당일, 퇴근 후 회사 옆 건물 스타벅스에서 만나 앉자마자 아래 첫 멘트를 꺼내시며 아직까지도 생생하게 기억나는 이야기가 시작되었다.

인: '혹시 팀에서 누가 괴롭히거나 희롱하는 등의 사건이 있었나요?'

나: '예? 아뇨, 절대 그런 일은 아닙니다.'

인: '그럼 그냥 그 팀에 있으세요.'

나: '예?..'

인: '저는 솔직히 xxx님 팀장님이 요청하셔서 이 자리까지 나온 거긴 한데, 절대 바꿔줄 마음 없이 나왔어요. 그쪽 팀장님이 뭐라고 하셔도 저는 절대 안 바꿔줄 거예요.'

나: '아...'

인: 'xxx님이 팀을 꼭 바꿔야겠다? 그러면 이거 인사팀 임원한테 보고 들어가야 하는데, 그럼 어떻게 될지 알죠? 회사에서도 xxx님 평판 안 좋아질 거고, 그런 거 다 버틸 수 있겠어요?'

나: '알겠습니다. 그냥 다니겠습니다.'

ㅋㅋ 지금 다시 쓰면서도 울컥하네; 신입사원이라 통할 만한 협박성 멘트인건가.

하여튼 저 면담을 마지막으로 더 이상의 팀 이동 이야기는 꺼내지도 않았다.

그래서 결국 취업한 지 두 달여만에 이직을 결심하게 되었고,
부서 배치 후 팀 분들과 면담했을 때 한 분이 아래와 같은 말씀을 해주셨던 것을 다시 가슴에 새기며 이직할 회사를 본격적으로 알아보기 시작했다.

'돈, 사람, 일.
이 세 가지 중 하나라도 나머지 둘을 압도할 만큼 좋다면 지금 회사에 계속 다니면 되는 거고, 아니면 이직을 하는 것이 맞다.'

SI/SM에서 서비스 회사로

'운칠기삼'이라는 말처럼, 인생은 운과 타이밍이 참 중요한 것 같다.

백엔드 개발을 희망했지만 관련 프로젝트나 업무 내용이 없었기 때문에 혼자 공부하고 있는 이론 지식만으로는 경력직 기술 면접을 통과하기 어려웠다.

신입 공고에서는 이제는 손을 놔버린 코딩 테스트가 발목을 잡은 경우가 많았다.

그런데 이직을 결심하고 어쩌다 알게 된 헤드 헌터 분께서 '엔터프라이즈 블록체인'이라는 한화에서 만든 스타트업을 추천해주셨다.

스타트업임에도 스프링 기반의 '요긱'이라는 자체 서비스를 운영하고 있다는 점,
블록체인과 관련된 사업 및 서비스를 상당수 계획 중이고 진행할 것이라는 점,
시니어가 상당히 많고 구성원들 대부분이 흔히들 말하는 '네카라' 출신이라는 점,
회사 사정이 안 좋아져도 '한화'라는 대기업이 뒤에 있다는 점 등 많은 부분에서 끌려 지원하게 되었다.

사실 지원 자격에는 3년 차 이상의 백엔드 개발자를 요구해서 큰 기대를 안 했는데,
기술 면접에서 면접관 분들이 내 연차와 상황을 고려하여 크게 어렵지 않은 질문들을 해주셨고,
내가 1년 여동안 꾸준히 블로그를 작성하며 혼자 공부해왔던 모습과,

이상하리만치 인생에서 손에 꼽을 정도의 침착한 모습으로 답변했던 모습들을 좋게 봐주셨는지 1차 면접에 통과했다.

그 후, 2차 면접까지 진행하게 되었고 2021년 12월 31일에 아래와 같은 최종 합격 메일을 받았다.

사실 회고록보다는 이직기에 가까운 듯싶다.

2022년 회고록에는 이것보다 더 개발적인 내용을 담을 수 있게 되길 기원한다.

끝!

[Network][장비] L1, L2, L3, L4, L5, L6, L7 스위치란?

대흉근 — Sat, 18 Dec 2021 19:45:55 +0900

지난 글에 이어 원래 알아보고자 했던 스위치에 대한 글이다.

이전 글을 읽고 오면 좋다.

라우터(Router)란?

스위치(Switch)와 스위칭(Switching)에 대해 자세히 이해하려면

라우터에 대한 개념도 필수적으로 잡아야 한다.

이전 글에서 간단하게 소개했지만 좀 더 알아보자.

아래에서 소개할 스위치는 '내부 네트워크'간의 통신만이 가능한 한계점이 존재한다.

그래서 기술과 문명의 발달로 탄생한 수많은 네트워크를 이어주는 인터넷(Internet)을 구축하려면

스위치로는 어림도 없다.

내부와 외부 네트워크 신호를 구분할 줄 아는 라우터만이 외부 네트워크와의 통신을 가능하게 한다.

그래서 라우팅(Routing) 기능은 서로 다른 네트워크를 연결하는 기능을 뜻한다.

이전에 OSI 7계층에 대해 알아본 글에서,

MAC 주소를 이용하여 스위칭(Switching)을 하는 2계층(데이터 링크 계층)의 장비는 L2 스위치, 즉, 스위치이고,

IP 주소를 이용하여 스위칭(Switching)을 하는 3계층(네트워크 계층)의 장비는 L3 스위치, 즉, 라우터를 뜻한다.

또한 라우터는 QoS(Quality of Service)와 같은 네트워크 관리 기능을 제공하기도 한다.

그럼 스위치 대신 모두 라우터를 쓰면 더 좋은 것 아닌가?

응, 아니다.

일단 라우터가 겁나 비싸다.

또한 스위치는 대부분의 설정이나 기능 등이 자동이기 때문에 관리나 사용이 쉬운 반면,

라우터는 일일이 수동으로 만져줘야 하는 까다로운 녀석이기 때문이다.

그래서 요즘에는 외부 네트워크 통신도 되고 QoS 기능도 되는

스위치 + 라우터를 합친 스위치도 나온다고 한다.

스위치(Switch)란?

출처)&nbsp;https://blog.naver.com/PostView.naver?blogId=bizblocklll&amp;logNo=222149701305&amp;categoryNo=16&amp;parentCategoryNo=0&amp;viewDate=&amp;currentPage=1&amp;postListTopCurrentPage=1&amp;from=postView&amp;userTopListOpen=true&amp;userTopListCount=5&amp;userTopListManageOpen=false&amp;userTopListCurrentPage=1

역시나 이전 글을 읽고 온 사람이라면 알겠지만 다시 짚고 넘어가자.

스위치는 네트워크 회선과 서버 컴퓨터를 연결하는 네트워크 장비이다.

출처) https://siran.tistory.com/205

한 포트로 들어오는 패킷을 자신과 연결된 장치에게 전달하는 점에서 허브와 유사한 역할을 하나,

위 그림처럼 신호(패킷)를 모든 포트로 전달하는 허브에 비해

스위치는 신호를 필요로 하는 포트로만 전달한다.

따라서 스위치에서는 불필요한 트래픽이 감소하게 되며,

이는 곧 네트워크에서의 데이터 전송 속도의 향상으로 이어진다.

이같은 동작을 위해서는 자신에게 들어오는 신호의 목적지를 정확하게 알아야 하는데,

그래서 스위치에서는 자신과 연결된 장비들의 MAC 주소와 그 장비가 연결된 포트를 기억해 두었다가,

자신이 아는 MAC 주소로 트래픽의 목적지가 설정되어 있으면 해당 포트로 트래픽을 전달한다.

그리고 만약 데이터를 보낸 장비의 MAC 주소가 처음 보는 주소라면,

해당 포트와 MAC 주소를 기억해두었다가

다른 장비가 그 MAC 주소로 데이터를 보내면 기억해두었던 포트로 데이터를 보내기도 하고,

데이터를 보낸 장비의 MAC 주소는 알고 있는 주소인데

데이터의 목적지 MAC 주소가 처음 보는 주소라면 모든 포트로 데이터를 뿌려버린다.

이처럼 스위치는 허브보다는 더 똑똑하며,

신호를 필요로 하지 않는 포트로는 데이터를 전달하지 않기 때문에

Collision Domain을 나누는 데 사용할 수 있다.

참고로, OSI 7계층 중 3계층에서 사용하는 라우터에 붙어있는 네트워크 포트 수가 부족할 때

따로 연결해서 사용하는 기계가 바로 L3 스위치이기도 하다.

L1, L2, L3, L4, L5, L6, L7 스위치란?

ISO라는 국제표준화기구에서 발표한 OSI 7계층이라는 것이 있다(관련 글).

말 그대로 7개의 층으로 나누어져 있는데,

L1(1계층)부터 L7(7계층)까지 각 층에서 사용되는 스위치에 대해 알아보고자 한다.

보통 어떤 주소를 다루는가에 따라(ex. MAC 주소, 프로토콜 주소, 세션 프로토콜,...) 스위치를 구분하며,

상위 계층(숫자가 높은 층)의 스위치는 하위 계층의 기능을 포함하고 있다.

하나씩 자세히 알아보자.

L1 스위치 (허브, 더미 허브)

가장 하위 계층인 1계층(물리 계층)에서 작동하는 녀석으로,

이전 글에서 알아보았던 허브(혹은 더미 허브)를 L1 스위치라고 한다.

허브는 자신에게 꽂혀있는 모든 장비에게 데이터를 전부 전달한다.

L2 스위치 (스위칭 허브)

가장 흔히 볼 수 있는 스위치인 L2 스위치는 2계층(데이터 링크 계층)에서 작동하며,

보통 스위칭 기능이 있는 스위칭 허브를 사용한다.

스위칭 허브란,

자신에게 꽂혀있는 모든 장비에게 데이터를 전달하는 허브와는 달리

각 장비의 MAC 주소를 내부적으로 저장하고 있기 때문에,

들어온 패킷의 MAC 주소를 읽어 해당하는 장비를 찾아 전달해주는 장비를 뜻한다.

OSI 7계층에 대한 글을 읽었다면,

L2(2계층)는 MAC 주소와 밀접한 관련이 있다는 것을 떠올리며

'그래서 스위칭 허브를 사용하는구나'하고 연관 지을 수 있다.

다른 방식에 비해 저렴하면서 성능은 높고 간단한 구조와 신뢰성이 높다는 장점이 있지만,

패킷에 의해 성능 저하가 발생하는(즉, 라우팅이 불가능한) 단점이 있다.

L3 스위치 (라우터, 공유기)

보통 3계층(네트워크 계층)은 라우팅 기능을 하는 층으로,

라우터는 네트워크 패킷을 연결해주는 통로 역할을 하며 대역폭 확장이 주 기능이다.

그래서 L2 스위치는 MAC 주소까지만 알았다면,

L3 스위치는 MAC 주소뿐만 아니라 IP 주소까지 알고 있다.

즉, L3 스위치란 L2 스위치에 라우팅 기능이 추가된 장비로,

그렇기 때문에 고성능 하드웨어를 기초로 하며, 스위치 자체에도 IP 주소가 할당되어 있다.

가정에서 많이 사용하는 공유기도 L3 기능과 WIFI 기능을 포함하고 있다.

보통 이러한 공유기를 AP 장비라고도 부르기도 하는데,

기업용으로 미친 성능과 가격을 갖고 있는 L3 스위치와는 달리

보통 가정용으로 사용하는 공유기는 성능과 가격이 합리적이다.

L4 스위치

4계층(전송 계층)은 외부에서 들어오는 모든 요청을 먼저 받아들이는 계층이다.

여기서 L4 스위치가 활약을 하는데, 그러한 요청들을 먼저 받아 내부의 서버들에게 적절히 분산시켜준다.

즉, L4 스위치의 주요 역할은 여러 대의 서버를 한 대처럼 묶을 수 있는 부하 분산(로드 밸런싱) 기능을 제공하는 것이다.

프로토콜을 기반으로 하여 애플리케이션 별로 우선순위를 두어 스위칭을 한다, 이 말이다.

그래서 L4 스위치는 IP 주소뿐만 아니라 Port 정보도 참고한다.

예를 들어, 웹 서비스를 하나 만들었는데,

공인 IP(125.125.12.5)를 갖고 있는 웹 서버 한대로 모든 요청을 처리한다고 가정하자.

사용자가 늘어남에 따라 트래픽이 감당이 안되어 서버를 증설했는데,

해당 서버의 IP는 125.125.12.6이다.

그럼 우리의 웹 서비스를 이용하는 사용자들에게

125.125.12.5 서버 말고 125.125.12.6 서버로도 접속해달라고 공지를 올려야 할까?

전혀 아니다.

이럴 때 필요한 것이 로드 밸런싱(부하 분산)으로,

사용자들에게 요청할 필요도 없고 일일이 서버에게 요청을 전달할 필요도 없다.

당연히 보안성은 말할 것도 없이 좋다.

이러한 훌륭한 기능을 하는 L4 스위치는,

하나의 서버가 죽어 서비스가 중단되는 경우 다른 서버로 해당 서비스를 대체하는

ACTIVE-ACTIVE / ACTIVE-STANDBY 기능도 한다.

하지만 설정이 많이 복잡하다는 단점이 있다.

L7 스위치 (L5 스위치, L6 스위치)

보통 L7 스위치가 L5, L6 기능까지 같이 하기 때문에 L7 스위치 하나만 알면 된다.

애플리케이션 영역인 7계층(응용 계층) 역시 4계층처럼

일반적으로 스위치로 들어온 패킷을 적절한 서버로 전송해주는 로드 밸런싱을 위해 스위치를 사용하는데,

L4 스위치와는 차이가 있다.

먼저, L4 스위치의 경우 3~4계층에 속하는 IP 주소 및 TCP/UDP Port 정보를 보고 스위칭하지만,

L7 스위치의 경우 3~7계층에 속하는 IP 주소 및 TCP/UDP Port 정보, 패킷 내용까지 모두 보고 스위칭해주는 장비이다.

또한, L4 스위치의 경우 TCP/UDP Port를 이용하여 로드 밸런싱(트래픽 분산처리)을 하지만,

L7 스위치의 경우 7계층 HTTP의 URL, FTP 쿠키 정보 및 바이러스 패턴을 분석하여

보안에 더 유리하고 정교한 로드 밸런싱이 가능하다(ex. Traffic filter, Security, VPN 등).

그래서 L7 스위치를 보안 스위치라고 부르기도 한다.

데이터 분석을 통해 DDoS 공격을 방어하기도 하고 감염 패킷 패터링 등의 기능도 제공하기 때문이다.

예시로 알아보는 스위치 기능

출처) https://siran.tistory.com/205

위와 같은 상황을 가정해보자.

한 가지 문제점이 있는데 뭘까?

바로 보안 문제이다.

먼저 상황 파악을 해보자.

L3 스위치를 통해 사용자는 다른 대역대의 사용자와 네트워킹이 가능해진다.

(ex. 192.168.10.0대의 사용자와 192.168.100.0대의 사용자 간 통신 가능)

피시방이라면 상관없겠지만, 만약 회사라고 가정해보면,

내부 사용자가 마음먹으면 상대방 네트워크로 진입하기 쉬워진다는 문제점이 발생한다.

모든 네트워크가 하나로 묶이게 되기 때문이다.

따라서 보안을 위해 아래처럼 네트워크를 분리시켜야 한다.

https://siran.tistory.com/205

L2 스위치를 두 개 추가함으로 네트워크 간 통신을 막을 수 있게 되었다.

즉, 공공망 사용자와 시스템 관리 사용자,

그리고 일반 사용자 간의 네트워크는 차단되었다.

끝!

[Javascript] 한글 URI 깨짐 현상 해결법

대흉근 — Fri, 10 Dec 2021 16:08:33 +0900

window.location.href로 현재 접속한 url을 받아와 보면

한글 URI 부분이 깨져있는(정확히는 인코딩 된) 현상을 볼 수 있다.

해결 방법은 간단하다.

한글 URI 부분을 decodeURI() 함수의 파라미터로 넘겨 디코딩해주면 된다.

끝!

[Algorithm][LeetCode][Medium][Python] 62. Unique Paths

대흉근 — Mon, 6 Dec 2021 22:05:53 +0900

문제는 여기에서 볼 수 있다.

고등학교 시절 자주 풀던 유형의 수학 문제와 똑같은데,

m행 n열의 그리드가 있을 때

(0, 0)에 위치한 로봇이 (m-1, n-1)까지 도달하는 경로의 수를 구하는 문제이다.

풀이 1

보자마자 수험생 시절 지긋지긋하게 풀었던 수학 문제와 똑같아서

바로 공식을 적용해서 풀어봤다.

m행 n열의 행렬이 있을 때,

유니크한 경로의 수를 구하는 공식은 Combination을 이용하는 것이다.

보통 (m+n-2)C(n-1) 공식으로 쉽게 구할 수 있다.

내가 수험생 시절 다녔던 수학 학원 원장님이 정말 천재여서

이러한 특정 유형의 문제에서의 공식들을 굉장히 매끄럽게 유도하고 알려주셨었다.

하고 싶은 말은 위 공식의 원리는 잘 기억이 안 남.

하여튼 완성된 내 코드는 아래와 같으며 나름 좋은 성능을 보여주었다.

import math

class Solution:
	def uniquePaths(self, m: int, n: int) -> int:
    	return math.comb(m+n-2, n-1)

풀이 2

discussion에서 찾아낸 Dynamic Programming 방법이다.

사실상 위 풀이 1과 원리는 동일하기 때문에 코드가 쉽게 이해 간다.

코드를 보기 전 product라는 함수에 대해 아는 것이 좋다(참고 사이트).

for 문을 돌면서 dp라는 배열에 경로의 수를 계속 누적해나간다.

성능은 풀이 1보다 좀 더 좋았다.

class Solution:
    def uniquePaths(self, m: int, n: int) -> int:
        dp = [[1] * n for _ in range(m)]
        for i,j in product(range(1,m),range(1,n)):
            dp[i][j] = dp[i-1][j] + dp[i][j-1]            
        return dp[-1][-1]

끝!

[Network][장비] Hub(허브), Bridge(브릿지), Switch(스위치), Router(라우터), Gateway(게이트웨이)란?

대흉근 — Wed, 1 Dec 2021 23:21:42 +0900

얼마 전 모 기업 면접에서 L2, L3 스위치에 대한 질문을 받았다.

그 질문을 받고 나서야 내가 여태 네트워크 장비들에 대해

막연하게만 알고 있고 어떤 역할을 하는지 등

정확한 개념은 모르고 있다는 것을 알았다.

그래서 이번에는 네트워크 장비들에 대한 글들을 작성하고자 한다.

시작은 여러 장비들에 대해 간단하게 알아보며,

OSI 7계층에 대한 글을 읽고 오면 좋다.

이번 시리즈는 아래 글들의 도움을 받았다.

- 나무위키 - 허브(시스템)

- 네트워크 장비(리피터, 허브, 브릿지, 스위치, 라우터, 게이트웨이) 한 번에 이해하자!

- 나무위키 - 스위치

- 네트워크 장비(스위치) L2, L3, L4와 네트워크 구성 및 아이피 할당에 대해서..1

- 네트워크 스위치 종류(L2, L3, L4, L7 개념) 정리

- 스위치 (L1, L2, L3, L4, L7 한번에 알고싶은 사람?)

- 해시넷 - 네트워크 스위치

허브(Hub)란?

Hub를 영어 사전에 검색해보면 '중심지'라는 뜻이 나온다.

'물류 허브를 만들겠다', '세계 허브 공항' 등 간혹 뉴스에서 볼 수 있는

허브가 바로 '중심지'라는 뜻의 허브다.

그러한 뜻을 가진 만큼 '중앙 집중'이라는 뜻도 내포하고 있기 때문에

어떤 형태로든 중앙으로 갈수록 처리량이 급속도로 증가하며

(이로 인해 병목 문제 발생)

그만큼 요구되는 안정성도 엄격해진다.

이 때문에 만약 허브가 망가졌다면,

허브 아래에 있는 시스템은 허브가 복구되기 전까지 사용하지 못한다.

네트워크 허브

USB를 여러 개 꼽을 수 있는 USB 허브, 교통 허브 등

여러 분야에서 다양한 개념의 허브가 존재하지만

우리가 알아볼 허브는 '네트워크 허브'다.

보통 컴퓨터 장치에서의 허브는

컴퓨터 신호를 여러 개의 다른 선으로 분산시켜 내보낼 수 있는 장치를 총칭한다.

출처) https://blog.naver.com/PostView.naver?blogId=bizblocklll&logNo=222149701305&categoryNo=16&parentCategoryNo=0&viewDate=&currentPage=1&postListTopCurrentPage=1&from=postView&userTopListOpen=true&userTopListCount=5&userTopListManageOpen=false&userTopListCurrentPage=1

이 중 네트워크에서 사용되는 허브는 (요즘은) 보통 이더넷 허브를 뜻하며,

위 사진처럼 생겼는데 구멍(포트)과 PC를 케이블을 꼽아주면 된다.

허브에 연결된 케이블 중 한 케이블로 신호가 들어오면

똑같은 신호를 다른 '모든' 케이블로 전달하는

'플로딩(flooding)'이라는 동작을 하게 된다.

예를 들어, 허브에 여러 랜 카드가 연결되어 있다고 가정하자.

만약 한 랜 카드에서 허브에 연결된 케이블로 신호를 보내면

다른 랜 카드들은 '무조건' 신호를 받아야 하며

신호를 받은 랜 카드들은 자신에게 온 신호인지 확인하고

자신에게 온 신호가 아니라면 무시한다.

이렇게만 보면 비효율적으로 생각될 수 있지만,

신호를 받고 싶은 랜 카드에게만 신호를 보내려면

어떤 포트에 어떤 랜 카드가 연결되어 있는지 기억하고 있어야 하기 때문에

내부에 별도의 저장장치가 필요하게 될 것이고,

또 저장된 내용을 읽어 어떤 포트로 신호를 내보내야 할지 결정하는 시간이 걸릴 것이며,

이런 동작을 하도록 추가적인 비용이 들어가기 때문에 장비 가격이 더 비싸질 것이다.

그런데 바로 그러한 역할을 하는 것이 '스위치(Switch)'이다.

예전에는 가격 문제 등의 이유로 모든 허브를 스위치로 바꾸기 어려웠지만,

2000년대 이후에는 순수한 허브는 사라졌고 모두 스위치로 교체되었다.

하지만 100 Gbps 이상의 초고속 전송에서는 패킷을 확인하는 오버헤드가 워낙 크기에,

그러한 곳에서는 아직 허브가 사용되고 있다.

또한 케이블의 전송 거리는 한계가 있기 때문에,

과거에는 신호를 받아 다른 선으로 전달해주는 리피터(Repeater)라는 장비를 많이 사용했다.

허브는 신호를 받아 여러 개의 포트로 전달하기 때문에

멀티포트 리피터(Multiport Repeater)라고 말하기도 한다.

공유기와 비슷하게 생겼지만 엄연히 다른 존재이다.

(공유기는 라우터의 NAT 기능과 게이트웨이 + 허브 및 네트워크 관리 도구다)

스위칭 허브(Switching Hub)

간혹 웹 통신 흐름 과정에서 발견할 수 있는 용어이다.

각 포트마다 10 Mbps의 속도를 할당하며,

사용자가 증가하더라도 빠른 속도로 데이터를 전송할 수 있기 때문에

화상 통신이나 DB를 빈번하게 접근하는 등의 경우나

인터넷 서버에 연결하는 허브로 사용하는 녀석이다.

브리지(Bridge)란?

2계층(데이터 링크 계층)에 있는 여러 개의 네트워크 Segment의 연결 기능을 제공한다.

설명만 들어도 허브나 리피터보다는 복잡한 것을 알 수 있으며,

들어오는 데이터 패킷을 분석하여 다른 네트워크로 전송할 수 있는지 결정한다.

또한 네트워크를 분리하는 기능이 있으며,

서로 다른 네트워크를 연결해주기도 한다.

리피터의 기능을 모두 갖고 있으면서 리피터보다 더 지능적이다.

스위치(Switch)란?

네트워크 회선과 서버 컴퓨터를 연결하는 네트워크 장비이다.

위의 허브 부분에서 잠깐 알아보았듯이,

스위치에 연결된 장비들의 IP와 MAC 주소를 모두 저장해 두고 있고

특정 장치에서 패킷이 오면 해당 패킷의 목적지를 파악하여

관련된 장치가 꽂힌 포트로 패킷을 보내준다.

그래서 모든 포트에 패킷을 뿌리는 허브에 비해

트래픽이 현저하게 줄어들어 네트워크 속도가 상당히 빨라졌지만,

만약 스위치도 알 수 없는 목적지를 가진 패킷을 받게 되면

허브처럼 모든 포트에 뿌려버리기도 한다.

허브 vs 스위치

허브는 1차선 도로와 같아서 데이터 전송량이 많아지면 속도가 느려진다.

라우터(Router)란?

3계층(네트워크 계층)에서 사용하는 네트워크 장비로,

스위치들을 서로 연결하여 네트워크 간 최적 라우팅 경로를 설정하고

설정된 경로를 따라 트래픽을 전달하는 역할을 한다.

이때의 최적 라우팅 경로는 일반적으로 가장 빠르게 통신이 가능한 경로이다.

라우터는 지금까지 알아본 장비 중 가장 똑똑한 장치인데,

자신에게 연결된 장치들의 주소를 갖고 있다는 점에서 스위치와 동일하나,

네트워크 상에 자신과 연결된 가장 가까운 라우터의 주소 또한 갖고 있다.

스위치와 다른 몇 가지를 더 살펴보자면,

(1) 라우터는 스위치보다 패킷의 주소 정보에 대해 더 많이 해석 가능하다.

라우터는 목적지가 없는 패킷을 전달받으면,

연결된 모든 장비에 뿌리는 허브나 스위치와는 달리

자신과 연결된 가장 가까운 라우터의 주소(Default Gateway)로 보낸다.

(2) 라우터는 스위치와 달리 패킷의 출발지 주소를 알 수 있다.

즉, 패킷이 내부 네트워크에서 온 것인지, 외부 네트워크에서 온 것인지 구분이 가능하다.

이러한 라우터들의 집합 통해 '인터넷'이 가능하게 되는 것이다.

게이트웨이(Gateway)란?

OSI 모델의 모든 계층을 포함하여 동작하는 장비이다.

두 개의 완전히 다른 네트워크 사이의 데이터 형식을 변환하는 장치로,

프로토콜 구조가 다른 네트워크 환경들을 연결할 수 있는 기능을 제공하는

상당히 똑똑하고 고차원적인 장비이다.

하지만 그런 만큼 비싸고 사용법이 어려우며,

여러 계층의 프로토콜 변환 기능을 수행함으로

네트워크 내 병목 현상을 일으키는 지점이 되기도 한다.

다음 글에서는 본격적으로 스위치에 대해 알아본다.

끝!

[Software Architecture] REST? REST API? RESTful API? - (3) 장단점, REST API 디자인 가이드

대흉근 — Wed, 10 Nov 2021 23:20:21 +0900

REST API에 대해 알아본 지난 1편, 2편에 이은 마지막 3편이다.

이번 글에서는 REST API에 대한 장단점과 디자인 시 참고하면 좋을 가이드에 대해 알아본다.

REST API 시리즈의 글들은 아래 사이트들에서 정보를 얻었다.

- CHAPTER 5 Representational State Transfer (REST)

- REST - 위키백과, 우리 모두의 백과사전

- REST - 나무위키

- REST API와 RESTful API

- REST API(RESTful API, 레스트풀 API)란? 구현 및 사용법

- REST API의 이해와 설계 #1-개념 소개

- REST API의 이해와 설계 #2-API 설계 가이드

- REST API 제대로 알고 사용하기

- 골치아픈 REST API에서 벗어나 효율적인 모바일 네트워크를 구성하는 방법

- [Network] REST란? REST API란? RESTful이란?

- REST API

- SOAP REST 차이, 두 방식의 가장 큰 차이점은?

- API(애플리케이션 프로그래밍 인터페이스)란 - 개념, 기능, 장점

- REST와 SOAP 비교

장점

장점은 아주 심플하다.

HTTP METHOD인 GET, POST, PUT, DELETE 네 개로 서버가 하는 대부분의 일을 설명 가능하다는 것이다.

특히 서버로부터 데이터를 가져오거나 서버의 데이터 일부를 업데이트하는 정도의 기본 데이터 중심 API인 경우에는 아주 충분하다.

출처) https://academy.realm.io/kr/posts/best-practices-pain-points-mobile-networking-rest-api-failures/

그러한 간단한 한 예를 들어보자.

위 그림처럼 사용자에게 "지금 내 주변의 정보"를 제공하는 모바일 앱이 있다고 가정하면,

현재 위치를 통한 현재 날씨를 한 서버에서 가져오거나,

현재 위치 근방에서 벌어진 뉴스를 다른 서버에서 가져오거나,

현재 위치에서 가까운 음식점을 또 다른 서버에서 가져오는 등,

이러한 모바일 앱은 여러 서버에 여러 번 REST API 호출을 하는 "비즈니스 로직"을 갖고 있다.

이러한 예제는 모바일 앱이 두뇌의 역할을 맡고 API는 단순히 데이터를 제공하는 형태이다.

이러한 구조에서 REST API의 장점이 별 것 없어 보이지만, 'Simple is the Best'라는 말도 있듯이, 직관적이고 단순할수록 러닝 커브도 줄어들고 실제 적용했을 때에 문제점도 많이 없다.

단점 및 오해

하지만 위 예제는 오직 모바일 앱만이 비즈니스 로직을 제공하는 아주 단순한 경우로, 만약 앱과 서버가 독립적인 비즈니스 로직을 갖고 있는 형태의 모바일 앱이라면 어떨까?

데이터의 CRUD(Create, Read, Update, Delete) 측면에서 REST API를 통해 서버와 통신하는 동안 여러 문제점이 발생할 수 있다.

1. Schema나 Type 유효성의 부재

말이 좀 어려울 수 있지만,

모바일 앱이 서버에 무언가 데이터 요청을 했는데 해당 데이터가 없을 수 있거나(Schema의 부재),

요청한 데이터가 있지만 모바일 앱이 기대했던 Type과는 다른 Type의 데이터가 반환되는 경우다(Type 유효성의 부재).

Schema 부재에 대한 예를 들어보자.

모바일 은행 앱이 모든 사용자의 계좌 정보를 알기 위해 서버에 GET /accounts라고 요청할 수는 있지만, 서버에 실제로 저런 End-Point가 있으리라는 보장은 없다.

예전 API 버전에는 있었지만, 개발자들이 업데이트하면서 현재 버전에는 없는 경우도 있을 것이다.

만약 /accounts가 존재한다는 가정하에 GET /accounts/153와 같은 형태로 특정 계좌의 상세 정보를 요청했다면, 이 역시 실제로 id가 153인 계정 정보가 존재하는지는 확신할 수가 없다.

전체 계정 목록을 요청한 이후에 다른 사용자가 모바일 앱으로 해당 계정의 정보를 수정하거나 서버에서 삭제할 가능성이 있기 때문이다.

이번에는 Type 유효성 부재에 대한 예를 들어보자.

출처) https://academy.realm.io/kr/posts/best-practices-pain-points-mobile-networking-rest-api-failures/

위 사진을 어떤 모바일 은행 앱의 API를 설계한 두 개발자의 API Return 방식이라고 가정하자.

두 개발자 모두 특정 id의 계좌 요청이 들어올 때 'amount'와 'curreny'라는 같은 정보를 return 하도록 설계했지만, 'amount'가 왼쪽 설계에서는 숫자이고 오른쪽 설계에서는 문자열로 들어오는 차이점이 있다.

물론 이런 일은 개발 과정에서 의사소통을 통해 하나로 통합할 테지만, 만약 실수로 그러지 못했다고 가정했을 때 굉장히 사소한 것으로 보이는 이러한 차이가 모바일 앱의 작동을 멈추게 할 수도 있다.

2. 데이터 변환

로직이 복잡한 모바일 앱에서 데이터 타입을 처리해야 하는 작업이 잦다면, 굉장히 성가실 뿐만 아니라 버그의 원인이 될 수도 있다.

HTTP와 JSON을 사용하는 REST API를 예로 들었을 때, 아래와 같은 flow로 네트워크를 통해 전송되는 데이터가 여러 변형을 거친다고 가정하자.

출처) https://academy.realm.io/kr/posts/best-practices-pain-points-mobile-networking-rest-api-failures/

(1) Native 데이터 모델 정의

-> Native 코드로 데이터 모델을 정의한다.

(2) Serialize (Native 데이터 -> JSON)

-> 문자열, 숫자, 리스트, 딕셔너리 등만을 사용해서 Native 객체들을 JSON에 호환되는 표현으로 변환한다.

-> Native 데이터 Entity를 REST End-point가 요구하는 구조로 바꾼다.

(3) HTTP를 통해 전송

-> 데이터를 JSON 문자열로 Encoding 한 뒤, multipart HTTP 형태의 데이터로 다시 Encoding 하여 POST 요청을 보낸다.

(4) 서버에서 데이터를 Decoding

-> POST 데이터를 Decoding 한 뒤, JSON 문자열을 Decoding 한다.

(5) SQL DB에 데이터를 저장

-> 요청된 아이템을 Cherry-pick 하고, 서버 저장소에 매핑되는 객체를 생성한다.

-> 객체를 SQL DB에 저장할 수 있는 데이터로 변환한다.

이렇게 네트워크를 통해 전송하는 데이터는 형식과 타입이 여러 번 변경된다.

그리고 이러한 변환 과정에서 1번 단점도 발생할 수 있다.

3. Business Logic Wrapping

위의 단점들처럼 반복적으로 데이터를 변환하고 코드를 변환하는 과정뿐만 아니라, 언어 자체를 변경해야 하기도 한다.

출처) https://academy.realm.io/kr/posts/best-practices-pain-points-mobile-networking-rest-api-failures/

위와 같은 예제에서 앱의 코드는 Java와 같은 Business Domain 언어를 사용하여 구현되었다고 가정하자.

그러한 방식은 앱의 목적과도 잘 부합하고, 구현 중인 비즈니스 로직을 구체적으로 처리하도록 설계된 다양하게 표현된 API이다.

특히, 사용 중인 언어의 최신 기능을 사용하도록 앱의 API를 설계한다면 앱을 가장 잘 설명하는 방향으로 데이터 Entity를 설계할 수도 있다.

하지만 이렇게 잘 설계된 시스템이 있음에도, 다시 CRUD 작업들로 표현할 수 있도록 모든 것을 다시 설계해야 한다.

즉, 요구사항을 잘 표현할 수 있도록 설계된 데이터 Entity를 다시 쪼개서 JSON 구조를 만들어야 한다.

이에 따라 잘 만들어둔 API의 표현력과 모델의 풍부함을 잃고, 단지 REST API의 단순함과 유연함만을 중심으로 비즈니스 로직을 Wrapping 하게 된다.

4. 항상 실패 가능성이 있는 네트워크 요청

출처) https://academy.realm.io/kr/posts/best-practices-pain-points-mobile-networking-rest-api-failures/

우리가 생각하는 REST API는 위 그림의 상단 부분처럼 간단해 보이지만, 데이터를 주고받고 요청하는 모든 과정은 네트워크를 통해 이뤄지기 때문에 네트워크 연결이 일시적으로 끊어지거나, 웹 서버에서 문제가 발생하거나, 서버 애플리케이션에서 오류가 발생하는 등 여러 오류가 발생할 수 있다.

모바일 앱 단과 서버 단에서 모두 완벽한 통신 로직 코드를 구현하려면 발생 가능한 모든 Error에 대한 Handling 처리가 필요하다.

위 그림만 봤을 때는 그다지 복잡해 보이지 않을 수도 있지만, 한 번의 요청이 아닌 여러 요청, 심지어 종속적인 요청이 들어온다면 엄청난 복잡한 상황이 펼쳐질 수도 있다.

5. HTTP+JSON에 대한 오해

REST에 대한 잘못된 이해 중의 하나가 HTTP와 JSON을 쓰면 REST라고 부르는 경우가 많다고 한다.

하지만 REST에 대한 속성을 제대로 이해하고 디자인해야 제대로 된 REST 스타일이라고 부를 수 있다.

6. 표준 규약의 부재

REST는 표준이 없다.

그러다 보니 개발에 있어 이를 관리하기가 어렵다.

표준이 존재하고 그 표준을 따르게 되면 몇 가지 Spec에 맞춰 개발 프로세스나 패턴을 만들 수 있는데, REST는 그러한 표준이 없으니 REST 기반 시스템을 설계하려면 사용할 REST에 대한 자체 표준을 정해야 한다.

근래에 들어서는 YAML 등과 같이 REST에 대한 표준을 만들고자 하는 움직임은 있으나, JSON의 자유도를 제약하는 방향이기도 하고 YAML에 대한 Learning Curve가 다소 높기 때문에 그다지 확산되지는 않고 있다고 한다.

이런 표준의 부재에서 오는 관리의 문제점을 해결하려면 제대로 된 REST API 표준 가이드를 만들고, API 개발 전후로 문서(Spec)를 만들어서 리뷰하는 프로세스를 갖추면 된다.

7. RDBMS에 적용하기 어려움

RDBMS(관계형 DBMS)에서 하나의 Row는 하나의 Resource인 경우가 많으며, PK(Primary Key)가 여러 개로 묶여 하나의 PK가 되는 복합 Key 형태로 존재하는 경우가 대다수이다.

하지만 그러한 복합 Key는 "/"에 따라 계층 구조를 가지는 HTTP URI에서 매우 부자연스러운 표현이다.

예를 들어, 어떠한 RDBMS의 Table의 PK가 "세대주의 주민등록번호" + "사는 지역" + "성명"이라고 가정하자.

REST API에서는 이를 userinfo/{세대주 주민등록번호}/{사는 지역}/{성명} 식으로 표현할 수밖에 없는데 다소 이해하기가 어렵거나 이상해 보일 수 있다.

이를 해결하는 방안으로는 Google이 사용하는 REST 방식이 있는데, AK(Alternative Key)를 사용하는 것이다.

의미를 가지지 않지만 Unique 한 값을 AK로 잡아 사용하는 방식인데, DB에 AK 필드를 추가하는 것 자체가 전체적인 DB 설계에 대한 변경을 의미하고, 이는 REST를 위해 전체 시스템 아키텍처에 변화를 준다는 점에서 REST 사용 시 아키텍처 접근의 필요성을 의미한다.

그래서 최근에는 JSON Document를 그대로 넣을 수 있는 구조를 갖추고 있는 MongoDB 같은 Document based NoSQL를 사용하기도 한다.

하나의 Document를 하나의 REST Resource로 취급하면 되기 때문에 REST의 Resource 구조에 매핑하기 수월해진다.

그럼에도 불구하고..

이미 위 단점들에 대한 솔루션이 많이 구현되어 있다.

MSA(Micro Service Architecture)이나 데이터 기반 API는 REST를 통해 뛰어난 자동화 기능을 제공하므로 데이터 변환 등과 같은 반복적인 작업을 구현하는 부담을 줄여준다.

또한 Business Logic을 Wrapping 하기 위해 잘 설계된 End-Point는 특정 요청을 위해 많은 수의 요청을 해야 하는 것과 같은 문제를 해결하는 데에 큰 도움이 된다.

혹은 GET 요청의 매개 변수를 추가하거나, POST 요청의 JSON Payload(전송되는 데이터)를 커스텀하는 등 REST 요청을 보다 지능적으로 만든 작업들도 존재한다.

REST API 디자인 가이드

1. URI는 단순하고 직관적으로 설계

URI만 보고도 REST API를 직관적으로 이해할 수 있을 만큼 URI를 단순하고 직관적으로 설계해야 한다.

또한 Depth를 너무 깊게 들어가는 것보다 최대 2 Depth 정도로 간단하게 만드는 것이 이해하기 편하다.

ex) /accounts

ex) /accounts/153

그리고 URI에 Resource명을 기재할 때에는 동사보다는 명사를 사용하여, REST API는 그러한 명사형 리소스에 대한 행동을 정의하는 형태를 사용한다.

즉, HTTP METHOD에 의해 CRUD의 대상이 되는 리소스여야 한다.

예를 들면, accounts라는 리소스를 생성하라는 의미로 POST /accounts처럼 사용하는 것이 옳은 예이고,

POST /getAccounts 나 POST /setAccountsOwner 은 get과 set 등의 "행위"를 URI에 붙인 잘못된 예시들이다.

이보다는 GET /accounts나 POST /accounts/43/owner/James를 사용하는 것이 좋다.

추가로 가급적이면 리소스의 의미상 단수형 명사(account)보다는 복수형 명사(accounts)를 사용하는 것이 더 이해하기 쉽다.

2. Resource 간의 관계 표현 방식

리소스들 간에는 서로 연관 관계가 있을 수 있는데, 예를 들어 유저가 갖고 있는 애플 제품 목록이나 반려동물 등이다.

이러한 리소스 간의 관계를 표현하는 방법은 크게 두 가지가 있다.

(1) Sub Resource로 표현

유저가 갖고 있는 애플 제품 목록을 예로 들어 표현해보자.

/{Resource명}/{Resource ID}/{관계가 있는 다른 Resource명}의 형태(ex. GET /users/siahn95/appleDevices)일 것이다.

이처럼 siahn95라는 유저가 갖고 있는 애플 제품 목록을 리턴하는 방법이 있다.

(2) Sub Resource에 관계를 명시

만약 리소스 간의 관계가 복잡하게 얽혀있다면, 그러한 관계명을 명시적으로 표현하는 방법이다.

예를 들어, 유저가 "좋아하는" 애플 제품 목록을 이 방식으로 표현하자면 아래와 같다.

ex) GET /users/siahn95/likes/appleDevices

siahn95라는 사용자가 좋아하는 애플 제품 목록을 관계를 표현하여 리턴하는 방식이다.

위 (1), (2) 방법 중 어떤 것을 사용하더라도 문제는 없지만,

(1)의 방법은 일반적으로 소유(has)의 관계를 표현할 때 사용하며,

(2)의 방법은 리소스 간의 관계의 명이 애매하거나 구체적인 표현이 필요할 때 사용한다.

3. Error 처리

REST API에서 에러 처리의 기본은 HTTP Response Code를 사용하여 Response Body에 에러에 대한 상세 사항을 서술하는 것이 좋다.

먼저, 대표적인 IT 기업들의 API 서비스가 어떤 HTTP Response Code를 사용하는지 살펴보자.

Google의 경우 10개(200, 201, 304, 400, 401, 403, 404, 409, 410, 500),

Netflix의 경우 9개(200, 201, 304, 400, 401, 403, 404, 412, 500),

Digg의 경우 8개(200, 400, 401, 403, 404, 410, 500, 503)의 Response Code를 사용한다.

(참고: https://cloud.google.com/blog/products/api-management/restful-api-design-what-about-errors)

(Response Code 관련한 설명은 이전 글 하단부 참고, 혹은 위키백과 참고)

많은 Response Code를 사용하면 자세히 어떤 응답인지 알 수 있겠지만, 코드 관리가 어렵기 때문에 아래처럼 주요 몇 가지 Response Code를 사용하는 것을 권장한다.

- 200 (성공)

- 400 (Bad Request -> field validation 실패 시)

- 401 (Unauthorized -> API 인증, 인가 실패 시)

- 404 (Not found -> 해당 리소스가 없음)

- 500 (Internal Server Error -> 서버 에러)

다음으로는 에러 내용에 대한 상세 사항을 HTTP Response Body에 기술하여 해당 에러의 원인을 전달하는 것이 디버깅에 유리하다.

Twillo의 Error Message 형식의 경우 아래처럼 보여준다고 한다.

- HTTP Status Code : 401

- {"status":"401", "message":"Authenticate", "code":200003, "more info":"http://www.twillo.com/docs/errors/200003"}

이처럼 에러 코드 번호뿐만 아니라 해당 코드에 대한 에러 Docs 링크 또한 제공하는 것이 좋다.

에러에 대한 Document를 제공하는 것은 API에서 국한되는 것이 아니라 Oracle의 WebLogic 같은 잘 정의된 소프트웨어 제품의 경우에는 모두 제공하는데, 개발자에게 많은 정보를 제공하여 디버깅을 좀 더 쉽게 해 준다.

그렇다고 에러에 대한 상세 사항을 기술할 때, Stack 정보까지 포함하게 된다면 내부 코드와 프레임워크 구조를 외부에 노출하게 되므로 해커들에게 해킹을 할 수 있는 정보를 제공하기 때문에 굉장히 위험하다.

그래서 일반적인 서비스 구조에서는 에러 Stack 정보를 API Error Message에 포함시키지 않는 것이 바람직하나,

내부 개발 중이거나 디버깅 시에는 매우 유용하기 때문에 API 서비스를 개발하고 있다면 Server의 모드를 Prod와 Dev로 나누어 Dev인 경우에는 REST API의 에러 메시지에 Stack 정보를 포함해서 리턴하도록 하면 디버깅에 매우 유용하게 사용할 수 있다.

4. API Version 관리

Error 처리와 더불어 API 설계 시 중요한 것이 버전 관리이다.

이미 배포된 API의 경우, 해당 서비스는 계속 유지하면서 새로운 기능이 들어간 API를 배포할 때에는 하위 호환성을 보장해야 하기 때문에, 같은 API여도 버전에 따라 다른 기능을 제공해야 한다.

이러한 API 버전을 정의하는 방법에는 여러 가지가 있는데, 예시를 들어보면 크게 보자면 아래 두 가지가 있다.

- ?v={version}

- {Service Name}/{version}/{REST URI}

조대협 님의 경우 두 번째 형태로 아래처럼 정의하는 것을 권장하는데, 이는 서비스의 배포 모델과 관계가 있다고 한다.

- ex) api.server.com/account/v2.0/groups

account 서비스를 제공하는 위와 같은 Java 애플리케이션이 있다고 가정할 때, account.v1.0.war, account.v2.0.war과 같이 버전이 다른 War로 각각 배포하면 배포 binary를 관리할 수 있다.

또한, 앞 단에 서비스 명을 별도의 URL로 떼어 놓으면 향후 서비스가 확장되어도 account 서비스만 별도의 서버로 분리해서 배포가 가능하기 때문이다.

즉, 외부로 제공되는 URL은 api.server.com/account/v2.0/groups로 하나의 서버를 가리키지만, 내부적으로는 HAProxy 같은 Reverse Proxy를 이용하여 해당 URL을 account.server.com/v2.0/groups로 매핑을 할 수 있기 때문에 향후 서비스가 확장되어도 외부에 노출되는 URL에 대한 변경을 할 필요 없이 서버를 물리적으로 분리해내기 편리하기 때문이다.

5. Paging & Partial Response

만약 Client가 보낸 요청에 대한 응답이 100만 개의 데이터를 담고 있는 엄청난 사이즈의 list 형태라면, 이를 하나의 HTTP Response로 처리하는 것은 서버 성능과 네트워크 비용 등의 이슈가 발생하며 아주 비현실적이다.

그래서 이러한 대용량 데이터를 담고 있는 Response를 처리하기 위해 Paging과 Partial Response 기법이 필요하다.

먼저 Paging 처리 방법은 여러 스타일이 있다.

80번째 record부터 100번째 record까지 받는 API가 있다고 가정하면, 여러 IT 기업에서는 아래처럼 처리하고 있다.

Facebook API -> /record?offset=80&limit=20

Twitter API -> /record?page=4&rpp=20

(RPP는 Record Per Page의 준말로, page 당 record 수를 뜻한다,

rpp가 20이고 page가 4이면 80번째부터 100번째까지의 record이다)

LinkedIn API -> /record?start=80&count=20

구현하는 관점에서 보면 확실히 Facebook이나 LinkedIn 스타일이 직관적이기 때문에, 해당 스타일들을 사용하는 것을 권장한다고 한다.

두 번째로 알아볼 것은 Partial Response 처리 방법이다.

Client가 요청한 Resource에 대한 응답 메시지에서 굳이 모든 Field를 포함하지 않아도 되는 케이스들이 있다.

가령, Facebook의 피드는 User ID, 이름, 글 내용, 날짜, 좋아요 Count, 댓글, 사진 등 여러 정보를 갖는데, API를 요청하는 Client의 용도에 따라 몇 가지 필드만 필요한 경우가 있다.

이처럼 필드를 제한하게 되면 전체 응답의 양이 줄어들어 네트워크 대역폭(특히 모바일 환경에서)을 절약할 수 있고, 응답 메시지가 간소화되어 Parsing 등을 더욱 빠르게 진행 가능하다.

Partial Response 기능을 포함하고 있는 잘 디자인된 IT 기업들의 REST API 형태를 보면 다음과 같다.

Facebook API -> /siahn95/friends?fields=id,name

Google API -> ?fields=title,media:group(media:thumbnail)

(RPP는 Record Per Page의 준말로, page 당 record 수를 뜻한다,

rpp가 20이고 page가 4이면 80번째부터 100번째까지의 record이다)

LinkedIn API -> /people:(id,first-name,last-name,industry)

Facebook과 Google은 비슷한 접근 방법을 사용하는데, 특히 Google의 경우, group(media:thumbnail)처럼 JSON의 Sub-Object 개념을 지원한다.

LinkedIn의 경우, 가독성은 높지만 ":( )"로 구별하기 때문에 HTTP 프레임워크에서는 전체를 하나의 URL로 인식하고 :( 부분을 별도의 파라미터로 구별하지 않기 때문에 Parsing이 어렵다.

그래서 구현이 간단한 Facebook의 Partial Response를 권장한다고 한다.

6. 검색 (전역 검색 & 지역 검색)

사용자 등이 설정한 검색 조건은 일반적으로 HTTP Get의 Query String에 검색 조건을 정의하는데, 다른 Query String과 섞이는 위험이 있을 수 있다.

예를 들어, name=ahn이고 region=seoul인 사용자를 검색하기 위해 Query String만 사용하게 된다면 아래처럼 표현이 가능하다.

- /users?name=ahn&region=seoul

그런데 만약 응답 결과가 대용량 데이터라면 아래처럼 Paging 처리를 추가할 수 있다.

- /users?name=ahn&region=seoul&offset=30&limit=20

이렇게 되면 Paging 처리를 위해 추가된 offset과 limit이 검색 조건인지 Paging 조건인지 구분이 안 가게 된다.

그래서 Query 조건은 URLEncode를 사용하여 아래처럼 하나의 Query String으로 정의하는 것이 좋다.

- /user?q=name%3Dahn,region%3Dseoul&offset=30&limit=10

실제로는 "q= name=ahn,region=seoul"을 뜻하는 "q=name%3Dahn,region%3Dseoul"처럼 구분자 등을 통해 Query String을 작성하게 된다면, 우리가 원했던 검색 조건과 다른 Query String을 분리시킬 수 있다.

다음으로는 검색의 범위에 대해 고려할 필요가 있는데, 전체 리소스에 대한 검색을 하는 전역 검색과 특정 리소스에 대한 검색을 하는 지역 검색으로 나눌 수 있다.

예를 들어, 시스템에 users, cats, keyboards와 같은 리소스가 정의되어 있다고 하자.

이때 id=siahn95인 리소스에 대한 전역 검색과 지역 검색은 아래와 같다.

- 전역 검색 => /search?q=id%3Dsiahn95

- 지역 검색 => /users?q=id%3Dsiahn95

전역 검색의 경우 /search와 같은 전역 검색 URI를 사용하고, 지역 검색의 경우 리소스 명에 Query 조건을 붙이는 식으로 표현이 가능하다.

7. HATEOAS를 이용한 Link 처리

HATEOAS는 Hypermedia As The Engine Of Application State의 약어로,

Hypermedia의 특징을 이용하여 HTTP Response에 다음에 올 Action이나 관계되는 리소스에 대한 HTTP Link를 함께 리턴하는 것이다.

(하이퍼미디어에 대한 설명 글 링크)

예를 들어, 앞서 설명한 Paging 처리의 경우 HTTP Response를 리턴하면서 전/후 페이지에 대한 링크를 아래처럼 제공 가능하다.

{
    [
        {
            "id":"user1",
            "name":"bob"
        },
        {
            "id":"user2",
            "name":"shawn"
        }
    ],
    "links":[
         {
             "rel":"pre_page",
             "href":"http://xxx/users?offset=5&limit=5"
         },
         {
             "rel":"next_page",
             "href":"http://xxx/users?offset=10&limit=5"
         }
     ]
 }

혹은 연관된 리소스에 대한 디테일한 링크를 표시할 수도 있다.

{
    "id":"user1",
    "links":[
        {
            "rel":"friends",
            "href":"http://xxx/users/shawn/friends"
        },
    ]
 }

이처럼 HATEOAS를 API에 적용하게 되면 자기 기술적(Self-Descriptive) 특성이 증대되어 API에 대한 가독성이 증가되는 장점을 갖게 된다.

하지만, Response 메시지 자체가 다른 Resource URI에 대해 의존성을 가지게 되기 때문에 구현이 다소 까다롭다는 단점이 있다.

최근에는 Spring과 같은 프레임워크 차원에서 HATEOAS를 지원하고도 있다.

(https://spring.io/projects/spring-hateoas)

8. 단일 API End-Point 활용

만약 API Server가 물리적으로 분리된 여러 서버에서 동작하고 있을 때, user.apiserver.com, car.apiserver.com과 같이 API가 서비스마다 URL이 분리되어 있으면 개발자가 사용하기 불편하다.

매번 다른 서버로 연결을 해야 하기도 하고, 중간에 방화벽이라도 존재한다면 일일이 해제해야 하기 때문이다.

따라서 API 서비스는 물리적으로 서버가 분리되어 있더라도 단일 URL을 사용하는 것이 좋은데,

4. API Version 관리에서 잠깐 봤던 것처럼 HAProxy나 nginx와 같은 Reverse Proxy를 사용하는 방법이 있다.

예를 들어, HAProxy를 앞 단에 세우고 api.apiserver.com이라는 단일 URL을 구축한 뒤에 HAProxy 설정에서 아래처럼 구현한다.

- api.apiserver.com/user는 user.apiserver.com으로 routing

- api.apiserver.com/car는 car.apiserver.com으로 routing

이렇게 세팅을 해놓으면,

향후 뒷 단에 API 서버가 확장이 되어도 API를 사용하는 Client 입장에서는 단일 End-Point만 보면 되고,

관리자 입장에서도 단일 End-Point를 통해 부하 분산 및 로그를 통한 모니터링이 가능하기 때문에 편리하며,

API에 대한 Routing을 Reverse Proxy를 이용함으로 좀 더 유연한 운용이 가능하게 된다.

REST API에 대해 알아보며 생각했던 것보다 훨씬 방대하고 깊은 내용들이 있다는 것을 알았다.

결국 실무나 프로젝트 등을 통해 경험 쌓는 것이 가장 좋아 보인다.

끝!

[Software Architecture] REST? REST API? RESTful API? - (2) 개념, 특징, 설계 규칙, 안티 패턴

대흉근 — Tue, 2 Nov 2021 00:26:22 +0900

지난 글에서 REST 구조에 대해 알아봤다.

이번 글에서는 본격적으로 REST API의 개념, 특징, 설계 규칙 등에 대해 알아보려고 한다.

REST와 API 각각에 대한 개념에 대해서는 이번 글에서는 다루지 않을 예정이니 REST는 위에 걸어놓은 링크, API는 이전에 작성했던 글을 읽고 오면 좋다.

REST API 시리즈의 글들은 아래 사이트들에서 정보를 얻었다.

- CHAPTER 5 Representational State Transfer (REST)

- REST - 위키백과, 우리 모두의 백과사전

- REST - 나무위키

- REST API와 RESTful API

- REST API(RESTful API, 레스트풀 API)란? 구현 및 사용법

- REST API의 이해와 설계 #1-개념 소개

- REST API의 이해와 설계 #2-API 설계 가이드

- REST API 제대로 알고 사용하기

- 골치아픈 REST API에서 벗어나 효율적인 모바일 네트워크를 구성하는 방법

- [Network] REST란? REST API란? RESTful이란?

- REST API

- SOAP REST 차이, 두 방식의 가장 큰 차이점은?

- API(애플리케이션 프로그래밍 인터페이스)란 - 개념, 기능, 장점

- REST와 SOAP 비교

REST API란?

RESTful API라고도 하는 REST API는 우리가 이전 글에서 알아보았던 REST 아키텍처의 제약 조건을 준수하는 애플리케이션 프로그래밍 인터페이스를 뜻한다.

이러한 RESTful API를 통해 요청자가 어떠한 요청을 하면, 응답자 측은 요청을 받은 리소스 상태에 대한 표현을 RESTful API를 통해 요청자에게 다시 전송한다.

이 정보 또는 표현은 JSON(Javascript Object Notation), HTML, XLT 또는 일반 text와 같은 형식으로 전송된다.

이 중, JSON은 Javascript라는 이름이 들어가는 것과 다르게 사용 언어와 상관없이 인간과 머신 모두 읽을 수 있기 때문에 가장 널리 사용된다.

정리하자면,

(1) Resource를 제대로 정의하고,

(2) 이에 대한 CRUD를 HTTP METHOD(POST/GET/POST/DELET)로 사용하며,

(3) 에러 코드에 대해 HTTP Response Code를 사용해야 한다.

API가 RESTful로 간주되기 위한 기준

아래와 같은 총 6가지 기준이 있다.

읽어보고 '어, 어디서 봤는데?'라는 생각이 든다면 이전 글을 잘 이해하고 숙지하고 있는 것이다.

1. Client-Server Architecture

Client, Server 및 Resource로 구성되어 있으며, 요청이 HTTP를 통해 관리되어야 한다.

Server는 API 제공을 하고, Client는 사용자 인증에 관련된 일들을 관리한다.

자원이 있는 쪽을 Server, 자원을 요청하는 쪽이 Client가 된다.

이렇게 나누면 의존성이 줄어들기 때문에 역할이 확실하게 구분되어 개발해야 할 내용들이 명확해진다.

2. Stateless Client-Server Communication

요청 간에 Client 정보가 저장되지 않으며, 각 요청이 분리되어 있고 서로 연결되어 있지 않는다.

즉, 서버는 각 요청을 완전히 다른 것으로 인식하고 처리한다.

이렇게 상태 정보를 Server 쪽에 저장하지 않으면 각 API Server는 들어오는 요청을 메시지로만 처리하면 되며, Session이나 Cookie 같은 Context 정보를 신경 쓸 필요가 없기 때문에 구현이 단순해진다.

3. Cache

Client-Server 상호 작용을 간소화하는 Cache 기능이 가능해야 한다.

REST는 HTTP의 기존 WEB 표준을 그대로 사용하기 때문에 HTTP가 가진 Caching 기능 적용이 가능하다.

일반적인 서비스 시스템에서 60%~80%가량의 트랜잭션이 Select와 같은 조회성 트랜잭션인 것을 감안하면,

HTTP의 리소스들을 Web Cache Server 등에 캐싱하는 것은 용량이나 성능 면에서 많은 장점을 갖고 올 수 있다.

HTTP 표준에서 사용하는 "Last-Modified" 태그나 E-Tag를 이용하면 쉽게 캐싱을 구현할 수 있다.

출처) https://bcho.tistory.com/953

예를 들어, 위처럼 Client가 HTTP GET을 "Last-Modified" 값과 함께 보냈을 때, 콘텐츠에 변화가 없으면 REST Component는 "304 Not Modified"를 리턴하고 Client는 자체 캐시에 저장된 값을 사용하게 된다.

이런 식으로 캐시를 사용하게 되면 네트워크 응답 시간뿐만 아니라, REST Component가 위치한 Server에 트랜잭션을 발생시키지 않기 때문에, 전체 응답 시간과 성능 그리고 Server의 자원 사용률을 비약적으로 향상할 수 있다.

4. Uniform Interface

정보가 표준 형식으로 전송되도록 하기 위한 구성 요소(Component) 간 통합 인터페이스이다.

HTTP 표준만 따른다면 어떤 언어나 플랫폼에서 사용이 가능하다는 의미이다.

예를 들어, HTTP + JSON 형태로 REST API를 정의했다면,

안드로이드 플랫폼이든, iOS 플랫폼이든, C, Java, Python이든 특정 언어나 기술에 종속받지 않고 HTTP와 JSON을 사용 가능한 모든 플랫폼에서 사용이 가능한 느슨한 결합(Loosely Coupling) 형태의 구조이다.

이러한 통합 인터페이스에 필요한 것은 아래 4가지다.

(1) 요청된 리소스가 식별 가능하며, Client에 전송된 표현과 분리되어야 한다.

(2) 수신한 표현을 통해 Client가 리소스를 조작 가능해야 한다(이렇게 할 수 있는 충분한 정보가 표현에 포함되어 있기 때문).

(3) Client에 반환되는 자기 기술적(Self-Descriptive) 메시지에 Client가 정보를 어떻게 처리해야 할지 설명하는 정보가 충분히 포함되어야 한다. 즉, REST API 메시지만 보고도 쉽게 이해할 수 있어야 한다.

(4) Hypermedia(하이퍼미디어) -> Client가 리소스에 접근한 후 Hyperlink(하이퍼링크)를 사용해 현재 수행 가능한 기타 모든 작업을 찾을 수 있어야 한다.

5. Layered System

요청된 정보를 검색하는 데 관련된 서버(보안, 로드 밸런싱 등을 담당)의 각 유형을 Client가 볼 수 없는 계층 구조로 체계화하는 계층화된 시스템이어야 한다.

즉, Client는 REST API 서버만 호출한다.

6. Code-On-Demand(선택 사항)

Server가 요청을 받으면 Client로 실행 가능한 코드를 전송하여 Client 기능을 확장할 수 있는 기능이다.

REST API 구성

그럼 이제 본격적으로 REST API에 대해 알아보자.

REST API를 사용하기 위해서는 아래 세 가지 구성 요소가 필요하다.

(1) 자원(Resource) : URI

(2) 행위(Verb) : HTTP METHOD

(3) 표현(Representations) : 메시지

즉, URI를 통해 자원을 표시하고

HTTP METHOD를 이용하여 해당 자원의 행위를 정해주며

그 결과를 받는 것을 말한다.

예를 들어, "헬스 운동 중 이름이 벤치 프레스라는 종목을 생성한다"라는 호출이 있을 때,

"종목(헬스 운동)"은 생성되는 자원(Resource),

"생성한다"라는 행위(Verb),

"이름이 벤치 프레스라는 종목"은 표현(Representations)이 된다.

맛보기로 어떻게 REST 형태로 표현하는지 보자면 아래와 같다.

# HTTP POST == '생성한다'는 의미를 갖는 행위
# http://myweb/fitness == 생성하고자 하는 대상이 되는 자원이 표현되는 형태(URI)
# 생성하고자 하는 운동 종목의 디테일한 내용은 JSON 형식을 이용하여 표현됨

HTTP POST, http://myweb/fitness/
{
    "exercise": {
        "name": "Bench Press"
    }
}

각각에 대해 좀 더 자세히 알아보며 설계 규칙까지 같이 알아보자.

1. URI는 정보의 자원을 표현해야 한다

URI는 자원(Resource)을 표현하는데 중점을 두어야 하기 때문에 행위에 대한 표현이 들어가면 안 된다.

즉, 해당 자원을 읽거나 만들거나 수정하거나 삭제하는 등 URI에 동사 표현이 들어가면 안 된다.

그래서 자원의 이름은 동사가 아닌 명사를 사용해야 한다.

ex) GET /users/123

다른 예를 들어, "회원 중 id 1번을 삭제"라는 API를 GET /users/delete/1과 같이 쓰면 안 되고 DELETE /users/1처럼 수정해야 한다.

물론 모든 명령이 이런 명사형으로 정의가 가능한 것은 아니다.

만약 '사용자가 좋아하는 디바이스 목록'을 표현해야 할 경우에는, GET /users/{userid}/likes/devices 와 같은 형태로 사용할 수도 있다.

그래도 되도록이면 리소스 기반의 명사 형태로 정의를 하는 것이 REST 형태의 디자인이 된다.

몇 가지 옳은 예와 옳지 않은 예를 추가로 남겨둔다.

GET /users/show/1 -> (X)

GET /users/1 -> (O)

GET /members/insert/2 -> (X)

POST /members/2 -> (O)

2. 자원에 대한 행위는 HTTP METHOD로 표현한다

그럼 그러한 자원에 대한 행위는 뭘로 표현할까?

바로 HTTP METHOD를 이용한다.

HTTP METHOD에는 GET, POST, PUT, DELETE 등이 있다.

흔히 CRUD(Create, Read, Update, Delete)라고 부르는 데이터베이스 용어가 있는데, C는 POST, R은 GET, U는 PUT, D는 DELETE와 같다.

ex)

GET /users/123 == 유저 ID가 123인 유저의 정보를 가져오기

DELETE /users/123 == 유저 ID가 123인 유저의 정보를 삭제하기

POST /users/123 == 유저 ID가 123인 유저 생성

여기서 한 가지 더 중요한 개념을 짚고 넘어갈 건데, 멱등성(冪等性)이라고도 불리는 Idempotent이다.

거듭제곱을 뜻하는 멱(冪)과 같다는 의미를 가지는 등(等)이 합쳐져, 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미한다.

멱등성을 알아보는 간단한 예를 들자면,

x라는 정수 값을 갖고 있는 변수를 더하는 행위인 x++은 연산을 적용할 때마다 결과가 달라지기 때문에 Idempotent 하지 않다고 하지만(멱등성이 없음),

x=3과 같은 대입 연산은 반복적으로 수행해도 Idempotent 하다(멱등성이 있음).

하여튼, 이 개념을 왜 꺼냈냐 하면 HTTP Method에도 이러한 멱등성 여부를 따질 수 있기 때문이다.

'그게 뭐 어때서!'하고 생각할 수도 있지만, Idempotent 하지 않는 HTTP Method를 사용하는 트랜잭션에 대해서는 각별한 주의가 필요하기 때문이다.

예를 들어, 게시물 조회를 하는 API가 있다고 가정하자.

조회할 때마다 조회수를 +1 해주는 연산을 수행하기 때문에 이 Method는 Idempotent 하지 않고, 만약 조회하다가 실패했을 때는 이미 올라가버린 조회수를 -1 해줘야 한다.

그럼 위에서 본 HTTP METHOD와 멱등성의 개념을 다시 생각해보면, 딱 하나의 HTTP METHOD가 Idempotent 하지 않은 것을 알 수 있다.

바로 리소스를 추가하는 연산인 POST이다.

3. 슬래시(/)는 계층 관계를 나타내는 데 사용한다

Windows의 파일 탐색기를 생각하면 된다.

ex)

http://hellchang.com/users/benchpress

http://hellchang.com/users/deadlift

4. URI 마지막은 슬래시(/)를 사용하면 안 된다

ex)

http://hellchang.com/users/benchpress/ [X]

http://hellchang.com/users/deadlift [O]

5. 언더바(_) 혹은 밑줄 대신 하이픈(-)을, 대문자 대신 소문자를 사용한다

불가피하게 긴 URI를 사용하게 될 경우, 언더바나 밑줄 대신 하이픈을 사용하여 가독성을 높인다.

언더바나 밑줄은 보기에도 어렵고 문자가 가려지기도 하기 때문이다.

또한 URI는 대소문자를 구분하기 때문에 대소문자가 달라지면 각각을 다른 자원으로 인식한다.

그래서 소문자만 사용하는 것이 좋다.

6. 파일 확장자는 URI에 포함하지 않는다

REST API에서는 메시지 body 내용의 포맷을 나타내기 위한 .exe, .txt 등의 파일 확장자를 URI 안에 포함시키지 않는다.

대신 Accept header를 사용한다.

ex) GET /users/soccer/345/photo HTTP/1.1 HOST: restapi.example.com Accept: image/jpg

REST Anti Pattern

지금까지 REST API에 대한 개념과 전체적인 특징에 대해 알아봤다.

이제는 REST 디자인 시, 하지 말아야 할 안티 패턴에 대해 알아보자.

1. GET / POST를 이용한 터널링

먼저 터널링이라는 용어에 대해 간단하게 알아보자면, 용어 그대로 터널을 뚫어 데이터를 조작한다는 것이다.

GET을 이용한 터널링의 한 예를 보자.

GET http://myweb/users?method=update&id=terry

METHOD의 실제 동작은 리소스를 업데이트하는 내용인데, HTTP PUT을 사용하지 않고 GET의 쿼리 파라미터로 method=update라고 넘겨서 이 메서드가 수정 메서드임을 명시했다.

HTTP METHOD 사상을 따르지 않았기 때문에 REST라고 부를 수도 없고, Web Cache 인프라 등의 사용도 불가능하기 때문에 대단히 좋지 않은 디자인이다.

또 많이 사용하는 좋지 않은 터널링 예는 아래와 같은 POST를 이용한 터널링이다.

Create(Insert) 성 명령이 아닌데도 불구하고, JSON Body에 명령을 넘기는 형태이다.

POST http://myweb/users/
{
    "getuser": {
        "id": "terry",
    }
}

위 API는 특정 사용자 정보를 가지고 오는데, GET이 아닌 POST를 이용해서 만든 나쁜 예이다.

2. Self-Descriptive 속성을 사용하지 않음

앞서 API가 RESTful 하기 위한 조건 중 Uniform Interface 항목의 Self-Descriptive(자기 서술성) 속성을 사용하여, REST URI와 METHOD, 그리고 쉽게 정의된 메시지 포맷에 의해 쉽게 API를 이해할 수 있어야 한다.

이러한 Self-Descriptive를 위반하는 가장 대표적인 사례가 바로 전에 알아본 GET / POST를 이용한 터널링 구조다.

3. HTTP Response Code를 사용하지 않음

많이들 하는 실수 중 하나가 HTTP Response Code를 충실하게 따르지 않고, 성공은 200, 실패는 500과 같이 1~2개의 Code만 사용하는 경우이다.

심한 경우에는 에러가 발생해도 HTTP Response Code 200으로 정의하고 별도의 에러 메시지를 200 Response Code와 함께 보내기도 하는데, 이는 REST 디자인 사상에도 어긋남은 물론이고 Self-Descriptive에도 어긋난다.

HTTP 응답 코드

HTTP METHOD를 사용하는 만큼, 응답 코드에 대해서도 숙지해두면 좋다.

2xx -> 성공

200 : Client의 요청을 정상적으로 수행

201 : Client가 어떠한 리소스 생성을 요청, 해당 리소스가 성공적으로 생성됨(POST를 통한 리소스 생성 작업 시)

204 : 요청은 성공, but 응답할 콘텐츠가 없음

3xx -> 리다이렉션(Redirection)

301 : Client가 요청한 리소스에 대한 URI가 영구적으로 변경되었을 때 사용(응답 시 Location Header에 변경된 URI를 적어줘야 함)

302 : 301과 같으나, 임시적으로 주소가 바뀌었을 경우 사용

304 : 이전에 방문했을 때의 요청 결과와 다르지 않을 경우 사용, 캐시 된 페이지를 그대로 사용

307 : 임시 페이지로 redirect

4xx -> Client 오류

400 : Client의 요청이 부적절할 경우 사용

401 : Client가 인증되지 않은 상태(ex. 로그인을 하지 않음)에서 보호된 리소스를 요청했을 때 사용

403 : 유저 인증 상태와 관계없이 응답하고 싶지 않은 리소스(ex. admin 페이지)를 Client가 요청했을 때 사용(403보다는 400이나 404 사용을 권고, 403 자체가 리소스가 존재한다는 뜻이기 때문)

404 : 찾을 수 없는 페이지, 주소를 잘못 입력했을 때 사용, 403 대신 사용 가능(해커들의 공격을 방지하고자 페이지가 없는 것처럼 위장)

405 : Client가 요청한 리소스에서는 사용 불가능한 METHOD를 이용했을 경우 사용

408 : 요청 시간이 초과됨

409 : Server가 요청을 처리하는 과정에서 충돌이 발생한 경우(ex. 회원가입 중 중복된 ID인 경우)

410 : 영구적으로 사용할 수 없는 페이지

5xx -> Server 오류

501 : 해당 요청을 처리하는 기능이 만들어지지 않음

502 : Server로 가는 요청이 중간에서 유실된 경우

503 : Server가 터졌거나 유지 보수 중(이때 유지 보수 중이라는 것을 알려주는 페이지로 전송해주는 것이 좋음)

504 : Server 게이트웨이에 문제가 생겨 시간 초과가 된 경우

505 : HTTP version이 달라 요청이 처리할 수 없음

어우 시간을 너무 많이 잡아먹는데..

다음 글에서는 REST API의 단점과 디자인 가이드에 대해 알아본다.

[Software Architecture] REST? REST API? RESTful API? - (1) 논문으로 알아보는 REST 개념

대흉근 — Sun, 10 Oct 2021 18:42:30 +0900

지난 글에서 API에 대해 알아봤다.

API의 연장선으로,

최근 백엔드 개발에서 필수 요소인 REST API에 대해 알아보려고 한다.

이번 글에서는 REST API 개념을 최초로 제시한 Roy Fielding의 논문을 살펴보며,

REST 구조가 나온 배경에 대해 알아본다.

REST API 시리즈의 글들은 아래 사이트들에서 정보를 얻었다.

- CHAPTER 5 Representational State Transfer (REST)

- REST - 위키백과, 우리 모두의 백과사전

- REST - 나무위키

- REST API와 RESTful API

- REST API(RESTful API, 레스트풀 API)란? 구현 및 사용법

- REST API의 이해와 설계 #1-개념 소개

- REST API의 이해와 설계 #2-API 설계 가이드

- REST API 제대로 알고 사용하기

- 골치아픈 REST API에서 벗어나 효율적인 모바일 네트워크를 구성하는 방법

- [Network] REST란? REST API란? RESTful이란?

- REST API

- SOAP REST 차이, 두 방식의 가장 큰 차이점은?

- API(애플리케이션 프로그래밍 인터페이스)란 - 개념, 기능, 장점

- REST와 SOAP 비교

REST 아키텍처에 적용되는 6가지 제한 조건

Web(HTTP)의 창시자 중 한 사람인 Roy Fielding은 당시의 아키텍처가 웹의 본래 설계의 우수성을 많이 사용하지 못하고 있다고 판단했다.

하여 2000년에 논문을 하나 발표하는데, 웹의 장점을 최대한 활용할 수 있는 네트워크 기반의 아키텍처를 소개한다.

그것이 바로 REST, Representational State Transfer이다.

이 논문에서는 REST라는 아키텍처를 만들기까지의 과정을 적어놨는데, 그대로 따라가 보려고 한다.

0. Starting with the Null Style

출처) https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

아키텍처를 디자인할 때에는 크게 두 가지 관점이 있다.

첫 번째는, 진짜 아무것도 없는 빈 곳에서 시작하여 최종적으로 원하는 시스템의 조건을 충족시킬 때까지 아키텍처를 만드는 것이다.

REST API는 두 번째 관점을 사용하는데,

부가적인 것들이 없는 기본적인 시스템(Null)에서 시작하여 제약(contraint)을 추가하면서 최종적으로 원하는 시스템으로 만드는 것이다.

첫 번째 관점은 창의성을 중시하는 반면,

두 번째 관점은 제약과 시스템 context에 대한 이해를 중시한다.

1. Client-Server

출처) https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

처음으로 추가할 제약은 Client-Server 아키텍처이다.

아키텍처를 단순화시키고 작은 단위로 분리(decouple)함으로써

Client-Server의 각 파트가 독립적으로 개선될 수 있도록 해주는 것이다.

다시 말해,

사용자가 시스템과 상호작용하는 UI(User Interface)와 데이터 저장하는 것을 분리함으로써,

이식성(portability)을 높여 다양한 플랫폼에서 사용 가능하게 하고 서버를 단순화시켜 Scale을 높이기도 쉬워진다.

그러나 Web에서 이러한 것이 가장 중요한 이유는 Client와 Server의 분리를 통해 구성 요소를 독립적으로 발전시킬 수 있게 되고,

그로 인해 여러 조직의 Internet-Scale급 요구 사항을 지원할 수 있게 된다.

2. Stateless

출처) https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

다음으로는 Client와 Server 간의 상호 작용에 제약을 추가할 것이다.

바로 Client와 Server 간의 소통은 Stateless이어야만 한다는 것이다.

Client로부터 Server로 요청(Request)을 보낼 때,

각 요청에는 해당 요청을 이해하기 위한 필수적인 모든 정보를 포함하고 있어야 하고, Server에 저장되어 있는 어떠한 context라도 사용하면 안 된다.

즉, 각 요청 간 Client의 Context가 Server에 저장되어서는 안 된다.

그렇기 때문에 Session State는 Client에 의해서만 관리된다.

이러한 제약을 통해 아래 세 가지 특성을 끌어낼 수 있다.

(1) Visibility(가시성)

Monitoring 시스템이 요청마다의 특성을 파악할 때, 하나의 Request만 보면 된다.

(2) Reliability(신뢰성)

부분적으로 무언가 오류가 발생해도 복구가 쉬워진다.

(3) Scalability(확장성)

요청마다 상태(State)를 서버에 저장하지 않아도 되기 때문에 서버를 구성하고 있는 요소들이 서버 리소스를 빠르게 해제할 수 있고,

더 나아가 서버가 요청 간의 리소스 사용량을 관리할 필요도 없기 때문에 구현(implementation)도 단순화한다.

하지만 Stateless 제약에도 Trade-Off가 존재한다.

(1) 네트워크 퍼포먼스 감소

데이터가 서버의 Shared Context에 저장되지 않기 때문에,

만약 일련의 요청들의 데이터가 중복되더라도 모두 별개의 요청으로 처리하기 때문에 네트워크 퍼포먼스가 감소되는 단점이 있다.

(2) Server 측 제어 감소

또한, 애플리케이션 상태(State)를 Server가 아닌 Client 측에서 관리하게 된다면,

여러 Client 버전이 존재할 경우에 올바르게 구현된 버전에 의존하게 되기 때문에 일관된(consistent) 애플리케이션 동작에 대한 Server 측의 제어가 감소하게 된다.

3. Cache

출처) https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Stateless를 추가하며 네트워크 이슈가 발생해버렸다.

이를 해결하려면 위 그림과 같은 Client-Cache-Stateless-Server 스타일로 아키텍처를 바꿔주면 되는데,

쉽게 말해 Client 단에 Cache 제약을 더하면 된다.

Cache 제약을 사용한다는 의미는 결국 Client의 Cache 기능을 사용한다는 말과 같은데,

이를 사용하려면 Server에서 Client로 보내는 응답(Request) 내의 데이터들이 캐싱이 가능한지 아닌지에 대한 정보가 있어야 한다.

만약 응답 내의 데이터를 캐싱할 수 있다면, Client의 Cache에서는 해당 데이터를 캐싱해두고 이후에 똑같은 응답(Response)을 받게 될 똑같은 요청(Request)을 하게 될 경우, 캐싱해둔 데이터를 재사용할 수 있게 된다.

이렇게 Cache 제약을 추가하게 되면, 일부 상호 작용(Interaction)을 부분적으로 또는 완전히 제거하여 일련의 상호 작용의 평균 대기 시간을 줄일 수 있게 된다.

이로 인해 효율성(Efficiency)과 확장성(Scalability), 그리고 사용자가 느끼는 성능이 향상될 수 있지만,

이 또한 등가교환의 법칙이 존재한다.

Client의 Cache에 있는 오래된 데이터가 Server로 요청(Request)을 보냈을 때 받게 될 응답(Response) 데이터와 크게 다르게 된다면 안정성(Reliability)이 감소하게 된다.

즉, Cache 내의 데이터가 오래되어 실제로 요청을 보내보면 받게 될 응답의 데이터와는 달라질 수도 있다는 이야기다.

그런데 우리가 여기까지 만들어 본 아키텍처인 Client-Cache-Stateless-Server 구조는 사실, 아래 그림과 같은 초기 웹 아키텍처이다.

출처) https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

1994년 이전까지는 인터넷을 통해 오고 가는 데이터들 대부분이 정적인 데이터였기 때문에 위와 같은 디자인이 가능했다.

또, Client와 Server가 의사소통하기 위해 사용되는 프로토콜의 경우, Non-Shared Cache에 대해서만 아주 기초적인 지원만 해줬을 뿐, 모든 리소스에 대한 인터페이스를 제공해주지는 않았다.

그래서 유닉스와 윈도우에서 사용 가능한, 모듈 방식의 클라이언트 사이드 웹 API인 CERN libwww라는 것을 추가로 사용하기도 했다.

하여튼, 지금의 웹 아키텍처 디자인은 우리가 지금까지 알아본 Client-Cache-Stateless-Server 구조를 이미 예~~전에 뛰어넘었다는 것이다.

정적인 데이터들 뿐만 아니라 동적인 데이터도 교환할 수 있게 되었고, Proxy나 Shared Cache 같은 Client와 Server 중간에 위치하는 component도 생겨났다.

그렇기 때문에 지금까지 살펴본 제약들은 과거의 웹 구조를 형성하고 있었다면, 이후부터 살펴볼 제약들은 현대 웹 구조를 형성하고 있는 것들이라 생각할 수 있다.

4. Uniform Interface

출처) https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

요게 REST 아키텍처의 핵심이다.

다른 네트워크 기반의 아키텍처 스타일과는 다르게 component들 사이의 uniform interface를 강조한다.

Uniform Interface라고 거창하게 써놨지만, 별 거 없다.

말 그대로 통일화된 인터페이스를 제공한다는 것이다.

소프트웨어 공학에는 Generality라는 원칙이 존재하는데, 이미 만들어진 것에 대해서는 생각할 필요가 없고 단지 Reuse 하기만 하면 된다는 의미이다(참고 링크).

Component interface에도 그러한 Generality 원칙을 적용함으로, 전체 시스템 구조가 단순화되어 상호 작용 간의 가시성(visibility)이 향상된다.

또한 구현(Implementation)은, 서비스를 제공하는 곳과 분리되어 독립적인 발전 가능성(evolvabilty)을 장려한다.

하지만 역시 trade-off가 존재한다.

모든 것을 통일화하고 균일화하다 보니, 정보가 애플리케이션이 필요로 하는 세부적인 형태가 아닌 표준화된(standardized) 형태로 전송되어 효율성(efficiency)이 떨어진다.

그래서 REST 인터페이스는 대규모 Hypermedia 데이터 전송에 효율적으로 설계되어 일반적인 웹의 경우에 최적화되지만,

다른 형태의 아키텍처 상호 작용에는 최적이 아닌 인터페이스가 된다.

이러한 Uniform Interface를 위해, Component들의 behavior에 대한 아래와 같은 아키텍처 제한들이 추가로 요구되기도 한다.

- Identification of Resources

- Manipulation of Resources through Representations

- Self-descriptive Messages

- Hypermedia as the Engine of Application State

5. Layered System

이제 Internet 규모의 요구사항을 위해 아키텍처를 더욱 향상할 필요가 있다.

출처) https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

그러기 위해 위 그림과 같은 Layered System 제약을 추가하는데,

예를 들면, 각 component는 상호 작용하는 계층 너머를 직접 볼 수가 없도록 제한하며,

그럼 Client는 보통 대상 Server에 직접 연결되었는지, 또는 중간 Server를 통해 연결되었는지를 알 수 없다.

이렇게 component들이 본인들이 속한 단일 layer에 대해서만 데이터를 공유하도록 만듦으로써,

전반적인 시스템의 복잡성(complexity)을 줄이고 독립성을 높이며 보안적인 부분도 강화할 수 있다.

또한 계층을 사용하여 legacy 서비스를 캡슐화(encapsulate)하고 legacy client로부터 새로운 서비스를 보호하기도 하며,

자주 사용하지 않는 기능을 shared intermediary(중개자)로 이동시켜 component들을 단순화할 수도 있다.

이러한 중개자(intermediary)는 여러 네트워크 및 프로세서 사이에서 Load Balancing(로드 밸런싱)을 가능하게 하기 때문에 시스템 확장성(scalability)을 개선할 수도 있다.

하지만, Layered System의 가장 큰 단점은 데이터를 처리할 때 Overhead와 Latency(지연)가 증가하여 사용자가 느끼는 퍼포먼스의 하락을 가져올 수도 있지만, Cache 제약 조건을 사용하는 네트워크 기반 시스템에서는 중개자(intermediary)의 Shared Caching(공유 캐시)의 이점으로 이 단점을 상쇄시킬 수 있기는 하다.

6. Code-On-Demand

출처) https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

드디어 마지막 제약 조건인 Code-On-Demand이다.

이 조건을 통해 REST를 사용하면, Applet이나 Script 형태의 코드를 다운로드하고 실행하여 Client 기능을 확장시킬 수 있게 된다.

이는 Client가 사전에 구현해야 하는 기능의 수를 줄여 Client를 단순화하고, 배포 후에 그러한 기능 다운로드를 허용하면 시스템의 확장성 또한 향상된다.

말이 좀 어렵지만,

Java Applet이나 JavaScript의 제공을 통해 Server가 Client가 실행시킬 수 있는 로직을 전송하여 기능을 확장한다는 것이다.

하지만 그만큼 가시성(visibility)이 낮아지기도 하며, 이 제약 조건은 유일하게 선택적인 조건이다.

요약 및 결론

출처) https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

지금까지 알아본 것처럼 REST 구조는 여러 네트워크 아키텍처 제약으로 구성되어있다.

여기서 '네트워크 아키텍처 제약'이란, 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반을 일컫는다.

간단한 의미로는, WEB 상의 자료를 HTTP 위에서 SOPA이나 Cookie를 통한 Session Tracking 같은 별도의 전송 계층 없이 전송하기 위한 아주 간단한 인터페이스를 말한다.

그리고 이러한 Fielding의 REST 원리를 따르는 시스템을 RESTful이란 용어로 지칭되기도 한다

REST 인터페이스의 원칙에 대한 가이드

1. 자원의 식별

WEB 기반의 REST 시스템에서의 URI처럼, 요청 내에 기술된 개별 자원을 식별할 수 있어야 한다.

자원 그 자체는 Client가 받는 문서와는 개념적으로 분리되어 있는데,

예를 들어, Server는 DB 내부의 자료를 직접 전송하는 대신에 DB 레코드를 HTML, XML, JSON 등의 형식으로 전송하는 것이다.

2. 메시지를 통한 리소스의 조작

Client가 어떤 자원을 지칭하는 메시지와 특정 메타데이터만 가지고 있다면, 이것으로 Server 상의 해당 자원을 변경 및 삭제가 가능하다.

3. 자기서술적 메시지

각 메시지는 자신을 어떻게 처리해야 하는지에 대해 충분히 정보를 포함해야 한다.

예를 들어, MIME type과 같은 인터넷 미디어 타입을 전달한다면, 메세지 안에는 어떤 parser를 이용해야 하는지에 대한 정보도 포함해야 한다.

즉, Client는 미디어 타입만으로도 어떻게 그 내용을 처리해야할 지 알 수 있어야 한다는 것이다.

한 예시로, "application/xml"이라는 미디어 타입은 실제 내용을 다운로드 받지 않으면 그 메시지만 가지고는 무엇을 해야할지에 대해 충분히 알 수 없기 때문에, 메시지를 이해하기 위해 그 내용까지 살펴봐야 한다.

이러한 메시지는 "자기서술적"이 아니다.

4. 애플리케이션의 상태에 대한 엔진으로서 하이퍼미디어

충분한 Context 속에서의 URI를 제공해주는 Hypertext Link처럼, 만약 Client가 관련된 리소스에 접근하기를 원한다면, return되는 지시자에서 구별될 수 있어야 한다.

REST의 주요한 목표

(1) 구성 요소 상호작용의 규모 확장성

(Scalability of component interactions)

(2) 인터페이스의 범용성

(Generality of interfaces)

(3) 구성 요소의 독립적인 배포

(Independent deployment of components)

(4) 중간적 구성요소를 이용해 응답 지연 감소, 보안을 강화, 레거시 시스템을 인캡슐레이션

(Intermediary components to reduce latency, enforce security and encapsulate legacy systems)

글이 또 이렇게 길어질 줄 상상도 못 했다..

다음 글에서는 REST API에 대해 본격적으로 알아볼 예정이다.

끝!

[ETC][일상] 테스트, QA 엔지니어의 소중함을 느껴버렸다

대흉근 — Thu, 7 Oct 2021 09:57:24 +0900

며칠 전 진짜 간단한 기능 추가를 하나 했다.

내가 운영하는 시스템은 나 혼자밖에 없어서

평소에는 테스트나 개발이나 다 나 혼자 해야 하는데,

고도화 프로젝트 진행하며 잠시 들어온 협력사 개발자 분이

추가한 기능에 대해 테스트를 진행해주셨다.

진짜 진짜 진짜 간단한 수정이었는데,

생각도 못한 테스트 케이스가 꽤 여러 개가 있었다;

하필이면 그쪽 소스가 협력사 개발자 분도 건들고 있던 소스라

수정이든 뭐든 테스트를 충분히 해야 한다고 조언해주셨다.

새삼 QA 직무하시는 분들은 진짜 꼼꼼하실 것 같다는 생각도 들고..

좀 더 테스트에 신경을 써야겠다.

[ETC][일상] 백업을! 생활화하자! (부제: 고도화 2차 오픈을 마치며)

대흉근 — Fri, 1 Oct 2021 23:40:20 +0900

작년 말부터 홀로 운영을 맡게 된

사내 웹 포탈의 고도화 프로젝트가

그제 2차 오픈을 하며 완료되었다.

올해 3월부터 시작된 고도화 프로젝트는

6월 말에 1차 오픈을 거쳐,

9월 말에 2차 최종 오픈을 했다.

1차 오픈 때는 굵직한 건들이 없어

무난하게 잘 넘어갔는데,

이번 2차 오픈은 꽤 힘들었다..

그 과정에서 두 가지 배운 점이 있어 글로 남겨본다.

백업의 생활화

이번 2차 오픈을 통해 얻은

가장 큰 깨달음이 아닐까 싶다.

현재 시스템에서 웹 에디터로

namoEditor(나모에디터)를 사용 중인데,

자잘한 버그 이슈가 있어서

최신 버전으로 업그레이드 해야 했다.

그 과정에서 기존 설치 파일을 지우고,

새로운 설치 파일로 설치하고 등의 과정을 거쳤다.

그런데 참..

신기하게도 QA 서버에서는 잘만 되던게

꼭 운영 배포만 하면 뭐 하나씩 어긋난다.

사람들이 웹 포탈에 올린 이미지 파일들이 사라졌다.

기존에 짜여져 있던 로직을 다시 분석해보니,

나모에디터로 글을 작성하며 이미지를 첨부하면

나모에디터 설치 폴더의 특정 내부 경로로 저장이 되는데,

이걸 모르고 그냥 냅다 삭제해버린 것이다.

다행히..

학부 시절에 Ctrl + Shift + Delete를 애용하다가

열심히 만든 발표 자료를 날려 먹은 것이 한 두번이 아니어서

그 뒤론 항상 일반 Delete만 사용하는데,

이 습관 덕에 '파일 유실'이라는

생각만 해도 오금이 저리는 상황을 타개할 수 있었다.

앞으로 무언가 '삭제'나 '수정'을 동반하는

어떠한 행위를 할 때는 무조건 백업을 받아둬야 겠다.

꼼꼼함

점심도 거르며 겨우 2차 오픈 배포가 완료되고,

퇴근 1시간 전..

3주 전부터 예매한

압구정 템퍼 시네마 '007 노 타임 투 다이'를 볼 생각에

가슴 한 켠이 두근두근 삼두근 뛸 때였다.

한 해외 사업장에서 엑셀 업로드가 안된다고 연락이 온다.

엑셀 업로드가 진행되를 담당하는 프로시거자

조금 시간이 오래 걸리는 프로시저이긴 했는데,

이번 2차 오픈에서는 그쪽 관련된 배포가 없었기 때문에

서버의 문제인가 싶었다.

그런데 메모리나 CPU에 문제는 없었고..

협력사 개발자 분과 서버 모니터링을 해보니

엑셀 업로드 프로시저가 돌기 시작하면

Garbage Collecting이 3분, 5분에 한 번씩 돌았다.

평소보다 확실히 자주 돌아서

JVM 메모리를 늘려도 보고,

쓰레드 풀, 커넥션 풀도 좀 더 늘려보고,

협력사 개발자과 여러 조치를 취해봤다.

심지어 그제가 9월 말일이었는데,

월 마감을 위해 꼭 당일 내에 업로드가 되어야 한다고 해서

응아줄이 타들어갔다.

템퍼 시네마 예매도 취소하고..

하여튼 위 조치들을 취해봐도

도저히 나아지는게 없었다.

그러던 중,

추가 근무 3시간 째에 이르러

협력사 개발자 분께서 '으악!!' 괴성을 지르신다.

화들짝 놀라서 이유를 물어보니..

업로드하는 엑셀 파일 내에

Start Date, End Date라는 컬럼이 존재해서

프로시저가 두 날짜 차이를 계산해서

여러 데이터 관련 작업을 수행해주는데..

사용자가 Start Date는 2021xxxx로 잘 적어두고

End Date를 2121xxxx로 적어버린 것이다.

서버는 100년치 데이터를 처리하려니

당연히 뭔 수를 취해도 뻗어버린 것이고..

평소 같았으면 무조건 엑셀 파일을 먼저 체크했을텐데

2차 오픈이 잘 진행되지 않았기도 하고,

고객사 임원과 윗분들이 많은 관심을 갖고 있기 때문에

심적으로 많이 쫄려 있어서

이렇게 시야가 좁아져있던 것 같다.

그래서.. 꼼꼼함에 대해 다시 생각해보게 된 경험이었다....

[Software Architecture] API란?

대흉근 — Mon, 20 Sep 2021 13:42:50 +0900

요즘 백엔드 개발자라면

거의 필수적으로 알고 있어야 할

API와 REST API에 대해 알아보고자 한다.

나도 아직 백엔드 취준생이나 마찬가지이기 때문에,

실무에서 접해봤다거나 직접 구현해보지는 않았고

일단 이론에 대해서만 정리하려고 한다.

이번 글은 API에 대해서만 작성하며,

아래 사이트와 유튜브에서 정보를 얻어 작성했다.

- API - 위키백과, 우리 모두의 백과사전

- API - 나무위키

- API란 무엇일까? API 쉽게 이해하기

- API란? 비개발자가 알기 쉽게 설명해드립니다!

- API란 무엇이고, 기업은 왜 API를 신경 쓸까?

- [IT용어] API란 무엇인가?

- API(애플리케이션 프로그래밍 인터페이스)란 - 개념, 기능, 장점

- UI와API

- API 기초개념 잡아드림. 5분 순삭.

- REST API가 뭔가요?

- 코딩초보들이 헷갈리는 용어 : API가 뭐냐면

API?

API란 Application Programming Interface의 약자이다.

출처) https://www.redhat.com/ko/topics/api/what-are-application-programming-interfaces

위 그림만 봐도 API가 어떤 역할을 하는 지

어렴풋이 감이 오는 것 같지만,

늘 그래왔듯 단어 하나씩 뜯어보자.

그런데 앞 두 단어 Application과 Programming은

이미 많이 보고 잘 알고 있는 단어들이기 때문에

상대적으로 생소한 Interface에 대해 알아보면

API가 어떤 녀석인지 느낌이 올 것 같다.

Interface

위키 백과에 따르면 아래와 같은 의미를 갖고 있다.

인터페이스(interface)는

서로 다른 두 개의 시스템, 장치 사이에서

정보나 신호를 주고받는 경우의 접점이나 경계면이다.

즉, 사용자가 기기를 쉽게 동작시키는데 도움을 주는 시스템을 의미한다.

위키는 읽을 때마다 참 말이나 단어의 조합이 어렵게 느껴진다.

좀 더 쉽게 풀어 쓰자면,

기계와 기계 혹은 기계와 사람, 소프트웨어와 소프트웨어 사이 등에서

정보를 교환하기 위한 수단이나 방법을 의미한다.

우린 이미 실생활에서 수많은 인터페이스를 다루는데,

두 가지 예를 생각해보자.

아침에 기상 후, 뉴스를 보기 위해 TV를 키려고 한다.

이때 필요한 것이 리모컨이고,

TV에게 명령을 내리는 리모컨과

명령받은대로 결과물을 출력해주는 TV 스크린은

(하드웨어적) 인터페이스이다.

그리고 무언가 검색을 하기 위해

스마트폰을 켜고 네이버 앱을 들어갔을 때 나오는 수많은 버튼들은

인간과 기계간의 (소프트웨어적) 인터페이스이다.

그런데 우리가 그러한 리모컨이나 화면의 버튼을 누를 때,

'내가 이걸 누르는 순간, 무슨 무슨 일이 벌어질거야'

생각하면서 내부의 동작 과정을 모두 알고 있던가?

아니다.

구현 방식을 알지 못해도,

서로 커뮤니케이션이 되는 기기 혹은 기능을 사용할 수 있는 것이 인터페이스이다.

추가적으로,

컴퓨터 관련 지식이 좀 있는 사람이라면

여기서 UI(User Interface)를 떠올릴 수 있다.

UI란 유저가 어떠한 시스템을 사용할 때

그 시스템에게 명령을 내릴 수 있는 인터페이스들을 말하는데,

예를 들어,

버튼들이 '얼마나 직관적으로 이해하기 쉽게 만들어졌는지',

'눈으로 볼 때 불필요한 정보는 많이 없는지' 등이 있다.

이러한 UI의 Interface 역시,

우리가 지금까지 주구장창 떠든 Interface이다.

종합

위 세 단어의 뜻을 알아본 결과,

'응용 프로그램에서 사용할 수 있는 인터페이스'를 API라고 하는 것 같다.

즉, 단순하게 말하면 API는 인터페이스이다.

확실치 않으니 API에 대한 위키 백과를 보자.

위키에서는 API를 아래처럼 정의하고 있다.

응용 프로그램에서 사용할 수 있도록,

운영 체제나 프로그래밍 언어가 제공하는 기능을

제어할 수 있게 만든 인터페이스를 뜻한다.

주로 파일 제어, 창 제어, 화상 처리, 문자 제어 등을 위한 인터페이스를 제공한다.

우리가 추측했던 API의 뜻과 나름 유사한 것 같다.

하지만 개인적으로는 아래 나무 위키의 API 정의가 잘 와닿았다.

프로그래밍에서,

프로그램을 작성하기 위한 일련의 부(sub) 프로그램, 프로토콜 등을 정의하여

상호 작용을 하기 위한 인터페이스 사양을 말한다.

이렇게 읽어보니 그동안 코드를 작성하며 썼던 라이브러리가 떠오르며

'라이브러리가 인터페이스인가?' 하는 생각이 든다.

신기하게도 나무위키에서 이 생각에 대한 답을 준다.

라이브러리와 종종 헷갈리곤 하는데,
구현 로직의 유무가 다르다.

API가 단순히 컴퓨터공학 분야의 개념이라면
라이브러리는 이러한 API들을 기반으로 개발자에게 기능을 제공할 수 있도록
실제 구현된 구현체라고 볼 수 있다.

그러니까,

무언가 기능을 만들 때

API는 해당 기능이 어떻게 작동하는지 등에 대해 알 수 있는 사양(명세, Specification)이고

라이브러리는 API를 기반으로 실제로 만들어진 구현(Implementation)이기 때문에,

API는 사양만을 정의한다.

(라이브러리 자체는 API 없이 존재할 수 있고,

Visual C++ Runtime Library, DirectX Runtime 등이 그러하다)

그래서 잘 설계된 API는 프로그램 개발을 보다 쉽게 해준다고 한다.

왜?

구현해야 할 기능들의 명세가 잘 설계되어 있으니깐.

우리가 레고나 가구 등을 조립할 때

설명서가 잘 적혀있으면 쉽게 조립하는 것처럼 말이다.

API와 라이브러리가 함께 제공되는 경우도 있는데,

이러한 것을 SDK(Software Development Kit)라고 한다.

SDK는 일반적으로 API, 라이브러리와 함께

프로그램을 개발하는데 필요한 여러 보조 프로그램을 뜻한다.

API (인증)키?

어떠한 서비스의 API를 사용하려고 웹 사이트에 들어가보면

인증키를 받으라고 하거나 입력하라는 것을 볼 수 있다.

외부에 데이터를 공개하는 회사의 입장에서

아무나 막 데이터를 빼서 임의로 사용하면 안되기 때문에

(인증)키라는 것을 만들어

해당 키를 발급받고 사용하는 유저만이 API를 사용할 수 있도록 하는 것이다.

API 비유

우리의 일상 생활에서 볼 수 있는 예시로

비유를 들어 API를 이해해보자.

API는 식당의 '점원'

출처) http://blog.wishket.com/api%EB%9E%80-%EC%89%BD%EA%B2%8C-%EC%84%A4%EB%AA%85-%EA%B7%B8%EB%A6%B0%ED%81%B4%EB%9D%BC%EC%9D%B4%EC%96%B8%ED%8A%B8/

위 그림만 봐도 뭘 말하려는지 딱 느낌 온다.

식당의 점원은 손님에게 메뉴판을 보여주고

받은 주문을 주방의 요리사들에게 넘겨주는데,

API가 그러한 역할을 한다.

API는 손님(프로그램)이 주문할 수 있게

메뉴(명령 목록)을 정리하고,

주문(명령)을 받으면 요리사(응용 프로그램)와 상호작용하여

요청된 메뉴(명령에 대한 값)를 전달한다.

즉, API는 리소스에 대한 접근 권한을 제공하고

보안과 제어를 유지할 수 있게 해주며,

접근 권한을 어떻게 / 누구에게 제공할지 여부만 결정하면 되는 것이다.

API 예시

Windows API & Web API

우리가 자주 사용하는 Windows 운영체제에도 API가 존재한다.

Microsoft의 Windows API 공식 문서에 들어가보면

Windows에 대한 상세 지식이 없어도

Windows에서 제공하는 기능을 사용할 수 있도록 하는 API들을 볼 수 있다.

그리고 다음 글에서 작성할 RESTful API와도

관련이 깊은 웹 API라는 것도 존재한다.

웹 API는 웹 애플리케이션 개발에서

다른 서비스에 요청을 보내고 응답을 받기 위해

정의된 명세(사양, Specification)를 일컫는다.

예를 들어,

블로그 API를 이용하면

블로그에 접속하지 않고도 다른 방법으로 글을 올릴 수 있다.

그 외에 우체국의 우편번호 API,

구글과 네이버의 지도 API 등 유용한 API들이 많으므로,

요즘은 홈페이지 구축이나 추가 개편 시

따로 추가로 개발하지 않고 이런 오픈 API를 가져와 사용하는 추세다.

도서 유통 회사 예시

도서를 유통하는 회사를 예로 들어

API에 대해 좀 더 이해해보고 이점을 간단하게 생각해보자.

이 도서 유통업체는 어떠한 어플리케이션을 만들었는데,

고객이 그 어플리케이션을 통해 서점 직원에게

특정 도서의 재고를 확인하도록 부탁하는 기능을 한다.

하지만 이와 같은 방식은

애플리케이션 개발 자체에도 많은 시간이 들지만,

플랫폼의 제약을 받을 수 있으며

지속적인 유지 관리가 필요하다.

따라서 어플리케이션 대신

재고 확인용 API를 만들어 외부에 제공하면

아래와 같은 여러 이점을 얻을 수 있다.

(1) 고객이 API를 통해 데이터에 접근하므로 한 곳에서만 재고 정보를 통합 관리하면 된다.

(2) API 작동에 문제가 없는 한, 도서 유통업체는 고객에게 영향을 미치지 않고

내부 시스템을 변경할 수 있다.

(3) 도서 유통업체의 개발자나 도서 판매자, 혹은 제 3자가

API를 이용하여 고객이 원하는 도서를 찾도록 도와주는 애플리케이션을 개발할 수 있으며

이는 매출을 늘리거나 기타 비즈니스 기회를 창출할 수도 있다.

API 역할

지금까지 API가 어떤 녀석인지 알아봤으니

정확히 어떤 역할을 하는 지에 대해 알아보자.

1. 서버와 DB에 대한 출입구 역할

DB에는 수천, 수만, 수억 건의 소중한 개인정보들이 담겨있는 경우가 많다.

아무나 이러한 DB에 접근할 수 있으면 안되기 때문에

API는 이를 방지하는 서버와 DB에 대한 출입구 역할을 하며

허용된 사람들에게만 접근성을 부여해준다.

2. 애플리케이션과 기기가 원활하게 통신할 수 있도록 함

애플리케이션, 즉 우리가 앱스토어나 플레이 스토어에서 다운로드하는

스마트폰 어플이나 컴퓨터 프로그램 등에 대해

API는 기기가 이러한 어플리케이션과 데이터를

원활히 주고받을 수 있도록 돕는 역할을 한다.

3. 모든 접속을 표준화함

말 그대로 API는 모든 접속을 표준화하기 때문에

기계 / 운영체제 등과 상관없이 누구나 동일하게 접근이 가능하다.

즉, 범용 플러그처럼 작동한다.

API 유형

기업이나 기관에서 만든 API들이

항상 외부로 공개되어 있는 것은 아니다.

외부 공개 범위에 따라 크게 아래 3가지 유형으로 나뉜다.

1. Private API

Private이라는 단어가 붙은 것처럼 내부 API를 뜻하며,

회사 개발자가 자체 제품과 서비스를 개선하기 위해

내부적으로 발행한 API이다.

따라서, 외부의 제 3자에게 노출되지 않는다.

2. Public API

개방형 API로, 모두에게 공개된다.

누구나 제한 없이 API를 사용할 수 있다.

3. Partner API

기업이 데이터 공유에 동의하는 특정인들만 사용할 수 있는 API이다.

비즈니스 관계에서 사용되는 편이며,

종종 파트너 회사 간에 소프트웨어를 통합하기 위해 사용된다.

API 장점

1. 개발자의 작업 능률 상승

Private API 같은 경우,

개발자들의 어플리케이션 코드 작성 방법을 표준화함으로써,

간소화되고 빠른 프로세스 처리를 가능하게 한다.

또한, 소프트웨어를 통합하고자 할 때

개발자 간의 협업을 용이하게 만들 수 있다.

2. 풍부한 사용자 경험 창출 & 사용자 증가

Public API와 Partner API를 사용하면,

기업은 타사 데이터를 활용하여 브랜드 인지도를 높일 수 있을 뿐만 아니라,

고객 데이터베이스를 확장하여 전환율까지 높일 수 있다.

예를 들어,

이커머스 기업에게 온라인 결제는 아주 중요한 요소인데

직접 온라인 결제 시스템을 구축하는 대신

타 회사의 검증된 결제 API를 사용하면

안전한 온라인 결제 시스템을 빠르게 구축할 수 있다.

다른 예시로,

소매 체인점을 운영하는 기업에서

본인들의 홈페이지에 전국 체인점 주소를 쭉 나열하는 것보다

Google Maps Embed API와 같은 것을 사용하여

단순히 위치만 알아보는 것에 그치지 않고

더 많은 정보를 얻게 하여 사용자 유치 확률을 높일 수 있다.

왜 API를 사용?

1. 간편하고 빠름

A라는 회사에서 보유한 상품들의 정보를

Z라는 회사에 보내야 한다고 가정하자.

이때, 세가지 정도의 방법을 생각할 수 있다.

(1) 이메일, 웹하드, 외장하드 등의 수동적인 방법으로 A에게 정보를 얻어와

같은 수동적인 방법으로 Z에게 정보를 전달한다.

-> A가 가진 정보가 바뀔 때마다 Z가 실시간으로 받아올 수가 없다, 그리고 매우 귀찮다.

(2) A의 DB 접근 권한을 얻는다.

-> 휴대폰 잠금 비밀 번호나 패턴을 알려주는 것과 다름없다.

(3) API를 사용한다.

-> 앞서 언급된 두 방법의 단점을 모두 커버할 수 있다.

2. 사용자 이탈율 저하

API를 제공하려면,

별도의 규격을 만들어야 하고

그 규격에 대한 설명 문서도 만들어야 하는 등

귀찮은 일이 한두가지가 아니다.

그런데도 왜 수많은 기업들은 API를 만들고 제공할까?

구글, 페이스북, 네이버, 카카오톡 등

대형 플랫폼 대부분이 제공하는

간편 로그인 API를 예로 들어 알아보자.

간편 로그인 API의 목적은

사용자가 여러 사이트를 하나씩 가입하다보면

가입할 때마다 똑같은 정보를 입력해야 하는 번거로움을 줄여

간편하게 회원 가입을 할 수 있도록 하는 데에 있다.

구글 간편 로그인을 이용하여

수십 개의 사이트에 회원 가입을 했다고 가정하자.

구글 아이디를 지우는 순간,

내가 가입했던 수십 개의 사이트에서도 자동으로 회원 탈퇴가 되며

그동안 쌓아온 포인트나 주문 내역 등이 모두 사라지게 된다.

그렇게 본인들의 플랫폼 이탈율을 현저히 줄일 수 있기 때문에

최근 거의 모든 대형 플랫폼은 간편 로그인을 제공하고 있다.

다음은 REST API에 대해 알아본다.

끝!

[Network] 웹 브라우저에 www.google.com / www.naver.com 을 입력했을 때 벌어지는 일들에 대해

대흉근 — Wed, 8 Sep 2021 22:58:25 +0900

"브라우저에 www.naver.com 혹은 www.google.com 입력했을 때,
어떤 일이 벌어지는 지 상세히 설명해주세요"

백엔드 신입 면접 질문 중 아주 단골 질문이다.

나도 몇 번 받은 질문이지만,

눈으로 슥 읽어보며 공부할 때는 다 알 것 같으면서

막상 면접 때 해당 질문을 받으면 제대로 대답을 하지 못하는 경우가 꽤 있었다.

이번 기회에 아주 조져보려고 한다.

이전에 작성했던 [Network] OSI 7계층 & TCP/IP 모델에 대한 자세한 설명을 읽고 오면 이해가 더욱 쉬우며,

이번 글은 아래 블로그들의 내용을 기반으로 작성했다.

- [번역] Browser에 www.google.com을 검색하면 어떤 일이 일어날까?

- What happens when you type a URL in the browser and press enter?

- 브라우저로 웹 사이트에 접속할 때 과정

- [IT 기술면접 준비자료] 당신이 브라우저로 웹사이트에 접속할 때 일어나는 일들 (부제: DNS 이야기)

- [네트워크]google.com을 입력하면 일어나는 일

- Browser에서 Google.com을 검색하면 무슨 일이 발생하나요?

- IP Address와 MAC Address 개념

3줄 요약

1. 웹 브라우저에 원하는 도메인을 입력한다.

(ex. www.naver.com / www.google.com )

2. DNS Server에 해당 도메인에 매핑되는 IP 주소를 요청한다.

3. DNS Server로부터 받은 IP 주소로 웹 서버에 접속한다.

면접에서 지식을 더 뽐내기 위해 각 단계에 대해 좀 더 깊고 자세하게 알아보자.

그 전에, 아래 글을 읽기 위해 알면 좋을 DHCP Server와 DNS Server에 대해 먼저 알아보자.

DHCP Server?

출처) https://preamtree.tistory.com/35

위 그림처럼,

사용자의 PC는 최초 부팅되면서 DHCP Server로부터

사용자 자신의 IP 주소와 가장 가까운 Router의 IP 주소, 가장 가까운 DNS Server의 IP 주소를 받는다.

DHCP Server?

이전에 작성했던 아래 글의 "유동 IP 주소" 부분을 참고하면 된다.
[Network] IP 주소에 대해 - (2) IP 주소 분류, 구분 방법

이후 ARP(Address Resolution Protocol)을 이용하여

가장 가까운 라우터의 MAC 주소를 알아내면 외부와 통신할 준비가 완료된다.

ARP(Address Resolution Protocol) ?

네트워크 상에서 IP 주소를 물리적 네트워크 주소로 대응시키기 위해 사용되는 프로토콜이다.

IP 주소 vs MAC 주소

IP 주소는 통신기기(PC, 스마트폰 등)에 할당된 식별번호다.
통신기기마다 고유하게 할당되어 있는 것이 아니라,
대부분 통신사에 일정 금액을 지불하고 받아오기 때문에 경우에 따라 바뀐다.

MAC 주소도 통신기기의 식별번호를 나타내지만,
임시적으로 다른 주체에 의해 할당되는 IP 주소와는 다르게 통신기기 하드웨어 자체에 부여된 고유한 식별번호다.

제품의 시리얼 넘버라고 봐도 되며, 세상에 단 하나밖에 없는 유니크한 값을 가지고, 변경이 불가능하다.

DNS Server?

이전에 작성했던 IP 관련 글들에서 인터넷이라는 거대한 네트워크 망에 연결된 컴퓨터 혹은 모바일 기기, 웹 서버 등은

택배를 받을 주소처럼 "IP 주소"라는 것이 필요하다고 했었다.

([Network] IP 주소에 대해 - (1) IP 주소란? 글 참고)

그렇기 때문에 우리가 접속하려는 사이트(www.google.com)의 웹 서버 IP 주소를 알고 있다면,

해당 IP 주소를 웹 브라우저에 입력하여 구글에 접속이 가능할 것이다.

하지만 우리가 모든 웹 서버의 IP 주소를 외우거나 메모하여 필요할 때마다 찾고 접속하는 것은 굉장히 무의미하고 멍청한 짓이다.

그래서 IP 주소를 알기 쉬운 문자열로 매핑한 도메인(Domain)이라는 개념이 등장했다.

(여러 도메인을 하나의 IP 주소로 매핑 가능하며, 여러 IP 주소를 하나의 도메인으로도 매핑 가능하다, 후자의 경우 DNS 밸런싱이라고도 부른다)

이러한 도메인 정보를 담고 있는 서버가 바로 아래 그림과 같은 DNS Server다.

(DNS == Domain Name System)

출처) https://preamtree.tistory.com/35

위와 같은 DNS Server는 IP 주소와 도메인의 매핑 정보를 관리하며,

도메인 혹은 IP 주소를 묻는 요청이 오면 응답한다.

또한 DNS Server에도 캐시가 존재해서 자주 요청을 받는 정보는 캐시로 관리를 한다.

1. 웹 브라우저에 원하는 도메인을 입력한다.

1-1. Browser DNS Cache

PC는 가장 먼저 브라우저 내에 존재하는 Browser DNS Cache라는 공간을 뒤져본다.

브라우저 종류마다 공간이 다 다른데,

가장 흔히들 쓰는 크롬의 경우 크롬 브라우저 창에 chrome://net-internals/#dns 라고 입력하면 해당 공간으로 들어갈 수 있다.

(하지만 다른 기능은 없고 캐시 비우기만 가능하다, 타 브라우저의 Browser DNS Cache의 경로는 여기 사이트 참고)

1-2. OS DNS Cache

만약 Browser DNS Cache에서 못 찾으면, OS에 저장된 DNS Cache를 뒤져본다.

hosts라 불리우는 이 OS DNS Cache 파일은

윈도우는 C:\Windows\System32\drivers\etc\hosts에, 맥은 /private/etc/hosts에 위치한다.

1-3. Router DNS Server

만약 OS DNS Cache에서도 못 찾으면, Router DNS Server라는 곳에서 조회를 한다.

Router에서 DNS 기록을 캐싱하고 있기 때문에 접속하려는 도메인의 IP 주소를 얻어올 수 있는 것이다.

1-4. DNS Server

만약 Router DNS Server에도 도메인에 대한 IP 주소가 없다면,

이젠 Root DNS Server부터 조회하며 아래에서 소개할 과정을 통해 IP 주소를 알아내야 한다.

2. DNS Server에 해당 도메인에 매핑되는 IP 주소를 요청한다.

접속하려는 도메인에 해당하는 IP 주소를 알아내기 위해 DNS Server에 Recursive Query를 진행한다.

최종적으로 DNS Server는 해당 도메인에 매핑되는 웹 서버의 IP 주소를 사용자에게 반환하거나

혹은 찾지 못하는 경우 에러를 발생시킨다.

아래 그림을 보면 DNS Server는 계층화되어 있기 때문에

도메인의 최상단인 가장 뒷쪽(.com, .kr 등)을 담당하는 DNS Server는 전세계에 13개 뿐이며,

왜 Recursive라는 단어가 붙는지 이해 가능하다.

출처) https://nesoy.github.io/articles/2018-06/What-happens-search-google

우리가 접속하고자 하는 도메인을 www.google.com 이라고 가정하고,

위 그림을 기억해두며 어떤 식으로 Query가 진행되는지 보자.

DNS Server 질의 과정

(1) 사용자의 PC는 가장 먼저 지정된 DNS Server에 DNS Query를 송신한다.

(우리나라의 경우 통신사 별로 지정된 DNS Server가 존재)

이때, 이 지정된 DNS Server를 DNS Recursor라고 부른다.

단어 뜻처럼 Recursive Query를 수행하는 녀석이다.

(2) 지정된 DNS Server는 Root Name Server에 www.google.com 을 질의하는데,

이때 Root Name Server라는 녀석은

'나는 걔 IP 주소같은 건 모르겠고, .com Name Server IP 주소는 알아, 걔 주소 줄게'

하면서 .com Name Server IP 주소를 넘겨준다.

(3) 그럼 PC는 다시 .com Name Server에 www.google.com 을 질의하는데,

이때 .com Name Server라는 녀석은 또,

'아, 나도 걔 IP 주소같은 건 모르겠고, google.com Name Server IP 주소는 아니까, 걔 주소 줄게'

하면서 google.com Name Server IP 주소를 넘겨준다.

(4) 마지막으로 PC는 google.com Name Server에 www.google.com 을 질의하는데,

드디어 우리가 원하는 구글의 IP 주소를 받을 수 있다.

3. DNS Server로부터 받은 IP 주소로 웹 서버에 접속한다.

DNS Server로부터 웹 서버의 IP 주소를 받았다고 끝난 것이 아니다.

웹 사이트를 브라우저에 띄울 수 있도록 이미지 파일, CSS 등과 같은 컨텐츠를 웹 서버로부터 받아야 한다.

그럼 어떻게 정보를 받아올까?

HTTP Request를 통해 요청을 하고

HTTP Response를 통해 받아오면 된다.

HTTP Request는 그럼 어떻게 이루어질까?

인터넷 프로토콜을 사용해서 해당 웹 서버와 연결을 해야 한다.

3-1. Browser와 웹 서버 간의 Connection

인터넷 프로토콜은 여러 종류가 있지만,

웹 사이트의 HTTP 요청의 경우 일반적으로 TCP를 사용한다.

TCP Connection을 위해 TCP Socket을 개방하고,

TCP 3 Way-Handshake라는 일종의 연결 검증 절차를 무사히 성공해야

데이터를 주고 받을 준비가 끝난다.

TCP 3 Way-Handshake?

본격적으로 통신을 하기 전,
Client와 Server가 잘 연결이 되었는지 확인하는 과정이다.

이름처럼 아래와 같은 3단계의 인증 과정을 거친다.

(1) Client -> Server : TCP SYN 패킷을 서버에 보내 connection 요청
(2) Server -> Client : TCP SYN ACK으로 응답
(3) Client -> Server : TCP ACK 패킷을 보냄

(SYN == Synchronize Sequence Numbers, ACK == Acknowledgement)

출처) https://nesoy.github.io/articles/2018-06/What-happens-search-google

3-2. Browser가 웹 서버에 HTTP Request

TCP로 웹 서버와 무사히 연결이 되었으니,

TCP Socket을 통해 HTTP Request(GET 요청)를 전송한다.

요청 시에 비밀 자료를 포함할 수도 있고,

form을 제출하는 경우에는 POST 요청도 사용될 수 있다.

또한, 아래와 같은 다른 부가적인 정보들도 함께 전달이 된다.

- Browser Identification (User-Agent Header)

- 수신할 Request의 종류 (Accept Header)

- 추가적인 Request를 위해 TCP Connection 유지를 요청하는 Connection Header

- Browser에서 얻은 Cookie 정보

- etc.

아래 사진은 GET Request의 샘플 본이며, 노란색 부분이 Header이다.

출처) https://devjin-blog.com/what-happen-browser-search/

3-3. 웹 서버의 Request 처리 및 Response 생성

웹 서버는 Browser로부터 받은 HTTP Request를 Request Handler에게 전달하여

Request 내용을 읽고 Response를 생성하게 한다.

Request Handler란,

ASP.NET, PHP, Ruby 등으로 작성된 프로그램을 의미하며,

Request와 Request의 Header, Cookie를 읽어서 Request가 무엇인지 파악하고,

필요하다면 웹 서버에 정보를 업데이트 하기도 한다.

그 후, HTTP Response를 JSON, XML, HTML 등의 특정 포맷으로 작성한다.

3-4. 웹 서버의 HTTP Response 전송

HTTP Response에는 아래 정보가 포함된다.

- Browser가 요청한 웹 페이지

- Status Code(현재 Response의 상태)

- Compression Type(Content-Encoding, 인코딩 방식)

- Cache-Control(페이지 캐싱 방법)

- (설정할 Cookie가 있다면) Cookie

- 개인 정보

- etc.

아래 사진은 HTTP Response의 샘플 본이다.

출처) https://devjin-blog.com/what-happen-browser-search/

첫 줄은 Status Code를 의미하는데, 총 5가지의 종류가 존재한다.

- 1xx : 정보만 담긴 메세지

- 2xx : 성공적인 Response

- 3xx : Client를 다른 URL로 Redirect

- 4xx : Client 측 에러 발생

- 5xx : Server 측 에러 발생

3-5. Browser의 HTML Content Rendering

Browser는 HTML Content를 단계적으로 보여주는데,

(1) HTML의 Skeleton(기본 틀)을 Rendering한다.

(2) HTML Tag들을 체크 후, 추가적으로 필요한 Image, CSS, JS 파일 등과 같은 웹 페이지 요소들을 GET으로 요청한다.

정적 컨텐츠들은 Browser에 의해 캐싱이 되어 나중에 해당 페이지를 재방문했을 때,

다시 서버로부터 불러오는 등의 과정이 생략되어 웹 페이지가 띄워지는 속도가 빨라진다

(3) 드디어 우리가 원했던 구글의 모습을 볼 수 있다.

쓰다 보니 글이 엄청 길어졌지만, 이 모든 과정들이 1초도 되지 않아 끝난다.

끝!

[Git][Github] Repository Naming Convention이 있을까?

대흉근 — Wed, 25 Aug 2021 23:06:56 +0900

회사 업무 중에 반복적이고 귀찮은 텍스트 작업이 하나 있어서

정보를 입력하면 원하는 텍스트 파일을 떨궈주는

간단한 프로그램을 하나 작성하려고 한다.

그러기 위해 Github 레포지토리를 하나 생성하는 도중,

문득 레포지토리 이름 규칙(Naming Convention)이 있는지 궁금해졌다.

구글링 해보니 stack overflow에서 바로 찾을 수 있었는데,

링크는 아래와 같다.

https://stackoverflow.com/questions/11947587/is-there-a-naming-convention-for-git-repositories

Is there a naming convention for git repositories?

For example, I have a RESTful service called Purchase Service. Should I name my repository: purchaserestservice purchase-rest-service purchase_rest_service or something else? What's the conventio...

stackoverflow.com

답변 중 가장 마음에 드는 것을 정리해보자면 아래와 같다.

1. 소문자를 사용해라 (use lower case)

2. 대시(-)를 사용해라 (use dashes)

3. 명확하게 작성해라 (be specific)

4. 일관성있게 작성해라 (be consistent)

끝!

[Docker][생활코딩] Container & Docker - (2) 네트워크, 파일 시스템, 실행 명령어, Host와 Container의 연결

대흉근 — Tue, 24 Aug 2021 22:48:31 +0900

지난 1편에 이어 마지막 2편이다.

다시 한번 말하지만,

아래 영상을 함께 보면 좋을 것이며,

이 글은 영상 5번부터 8번까지의 내용을 담고 있다.

- 생활코딩 Docker 입문수업 1. 수업소개

- 생활코딩 Docker 입문수업 2. 설치

- 생활코딩 Docker 입문수업 3. 이미지 pull

- 생활코딩 Docker 입문수업 4. 컨테이너 run

- 생활코딩 Docker 입문수업 5. 네트워크

- 생활코딩 Docker 입문수업 6. 명령어 실행

- 생활코딩 Docker 입문수업 7. 호스트와 컨테이너의 파일시스템 연결

- 생활코딩 Docker 입문수업 8. 수업을 마치며

네트워크로 웹 서버 세팅을?

Docker를 사용하기 위해서는

네트워크에 대해 어느 정도 알아야 한다.

Docker를 동작시키는 많은 소프트웨어가

네트워크를 이용하기 때문이다.

아래처럼,

80번 포트를 사용하는

http://example.com 웹 사이트를 개발하려고 할 때,

index.html 웹 페이지를 접속하고자 하는 과정을 통해 알아보자.

서버, 클라이언트, 포트 등에 대해 잘 모른다면

생활코딩의 WEB1, WEB2-HOME SERVER 강의를 보고 오자.

포트(Port)에 대해서만 간단하게 언급하자면,

Port, 한국말로 항구라는 뜻의 단어는

어떠한 선박이 어떠한 나라에 들어올 때

선박의 종류에 맞는 항구를 선택하여 들어가야 하는 것처럼,

어떠한 요청(request)이

어떠한 나라(server)에 들어갈 때

요청의 종류에 맞는 port로 들어가야 한다.

한 컴퓨터에는 약 65,000개의 포트가 존재하고

보통 웹 서버의 기본 포트는 80번 포트이다.

Docker 없이 웹 서버를 사용하는 방법

먼저 최소 두 대의 컴퓨터가 필요하다.

A라는 컴퓨터에서는 웹 브라우저를 실행해야 하고(클라이언트),

B라는 컴퓨터에서는 웹 서버를 설치해야 한다(서버).

내가 원하는 웹 페이지를 파일로 만든 후,

웹 서버가 설치된 B 컴퓨터 저장 장치의 특정 디렉터리

즉, 파일 시스템에 위치시켜야 한다.

index.html이라는 웹 페이지를 만들고

B 컴퓨터 파일 시스템으로 옮겼다고 가정해보자.

누군가 A 컴퓨터를 이용하여 index.html을 요청하면(request),

B 컴퓨터에서는 index.html이 위치한 경로를 뒤진 후

return 해야 한다(response).

웹 브라우저(A 컴퓨터)에서 http://example.com:80/index.html을 입력하면

웹 서버(B 컴퓨터)에 요청(request)이 들어오고,

웹 서버의 파일 시스템에서 index.html의 경로를 찾고 읽은 후

웹 브라우저에게 전달하면 과정이 끝난다.

Docker를 사용하여 웹 서버를 사용하는 방법

Docker가 설치된 컴퓨터(Host)에서

"docker run httpd"를 실행하여

아파치 서버(웹 서버)를 Container에서 띄운다.

하지만 위의 명령어로 아파치 서버를 띄운 후,

http://example.com:80/index.html을 입력해도

처음에는 접속이 불가능하다.

Container, Host 모두 각각 독립적인 실행 환경이어서

각자의 독립적인 포트와 파일 시스템을 갖고 있기 때문이다.

더 자세히 말하자면,

Host의 80번 포트와 Container의 80번 포트는

연결되어있지 않기 때문에,

Host의 80번 포트로는 요청(request)이 들어왔지만,

Container의 80번 포트까지는 요청(request)이 가지 않는다.

그렇기 때문에,

"docker run -p 80:80 httpd" 명령어를 실행하여

포트 포워딩(Port Forwarding)을 해주면

Host와 Container의 80번 포트가 연결된다.

만약 Host의 8000번 포트를 사용할 것이라면,

"docker run -p 8000:80 httpd" 명령어를 실행하면 된다.

Container의 포트 번호는

보통 해당 이미지를 만든 사람이 미리 지정해둔다.

실행 명령어

실행 중인 Container 내부에서

Linux의 pwd, ls 같은 아래의 명령어들을 실행할 수 있다.

하지만 Container의 기본 덕목은

'적은 용량'이기 때문에 vim, nano와 같은

부가적인 에디터들은 default로 설치되어 있지 않다.

// ws3라는 컨테이너 내부에서 pwd 명령어 실행하기
docker exec ws3 pwd

// ws3 컨테이너 내부에서 bourne shell 실행하기
// shell의 역할은 사용자가 입력한 명령어를 받아 os에게 전달하는,
// 일종의 창구 역할을 함
// 하지만 아래 명령어를 입력하면 바로 연결이 끊김
docker exec ws3 /bin/sh

// ws3 컨테이너 내부에서 지속적으로 사용 가능한 bourne shell 실행하기
// exit를 입력하면 연결이 끊어지고 다시 Host와 연결이 된다
// bourne shell은 기능이 많이 부족하여 /bin/bash (bash shell)을 많이 사용한다
// i == interactive, t = tty
docker exec -it ws3 /bin/sh

여담으로,

httpd(아파치 서버)의 공식 문서를 보면

index.html과 같은 파일이 등록되는 경로를 알 수 있다

(/usr/local/apache2/htdocs/).

Host와 Container의 연결

위에서 우리가 만든 index.html과 같은 웹 페이지를

Container에서 직접 수정하는 것은

번거롭고 위험한 작업이다.

Container를 사용하는 이유가

필요할 때 언제든 만들고,

필요 없어지면 언제든 지우는 것이기 때문에

내가 수정한 파일이 있는 Container 또한

언제든지 사라질 가능성이 있기 때문이다.

그래서 똑똑한 사람들은

Host의 파일 시스템을 Container의 파일 시스템과 연동하여

Host의 파일 시스템 내부에 있는 파일을 수정하면,

Container의 파일 시스템 내부에 있는 파일에도 반영되게 만들었다.

이로 인해,

'적은 용량'의 덕목을 갖고 있는 Container의 단점을 극복하고

Host에서 파일 버전 관리, 백업 혹은 에디터 등을 사용하여

파일 수정 및 관리가 가능하게 되었다.

그러한 파일 시스템 연동 명령어는 아래와 같다.

// docker run 시, option에 -v를 사용하면 연동이 가능해진다
docker run -p 8080:80 -v ~/Desktop/htdocs:/user/local/apache2/htdocs/ httpd

Docker에 대해 기본 개념을 잡기에는

이보다 더 좋은 수업은 없을 것 같다.

끝!

[Docker][생활코딩] Container & Docker - (1) 배경, 개념, 설치, 기본 명령어

대흉근 — Sat, 21 Aug 2021 20:52:28 +0900

이번에 생활코딩이라는 개발자 커뮤니티 및 유튜브를 운영하시는

이고잉님께서 docker에 대한 아주 쉽고 친절한,

영상마다 10분이 넘지 않는 유튜브 강의를 개설하셨다.

도커에 대해 막연하게 알고 있던 내게 큰 도움이 되었으며,

[많은 사람들이 봤으면 하고자 하는 마음] + [복습] 목적으로

영상들의 내용을 두 개의 글로 정리하여 남긴다.

아래 영상을 함께 보면 좋을 것이며,

이 글은 영상 1번부터 4번까지의 내용을 담고 있다.

- 생활코딩 Docker 입문수업 1. 수업소개

- 생활코딩 Docker 입문수업 2. 설치

- 생활코딩 Docker 입문수업 3. 이미지 pull

- 생활코딩 Docker 입문수업 4. 컨테이너 run

- 생활코딩 Docker 입문수업 5. 네트워크

- 생활코딩 Docker 입문수업 6. 명령어 실행

- 생활코딩 Docker 입문수업 7. 호스트와 컨테이너의 파일시스템 연결

- 생활코딩 Docker 입문수업 8. 수업을 마치며

배경

과거

어떠한 애플리케이션을 만들기 위해서는

서버에 OS 등의 여러 기본적인 소프트웨어를 설치해야 하고,

만약 웹 애플리케이션이라면

웹 서버나 DB 등의 추가적인 앱이 필요하다.

이러한 소프트웨어 및 앱 등의 설치는 매우 귀찮고,

까다롭고,

한번에 제대로 되지 않는 경우가 대다수이다.

그래서 사람들은 아래와 같은 생각을 하기 시작한다.

'아, 어떤 설치의 전문가가 PC를 직접 구해서

OS와 웹 서버, DB 등 다 설치하고 주면 얼마나 좋을까?

네트워크로 그 PC에 연결만 하고!'

'아니면, 하나의 컴퓨터에 Vmware이나 VirtualBox 같은 것으로

가상 PC를 만들고 그 위에 OS를 설치한 후

웹 서버 혹은 DB를 설치하는 건 어떨까?

그럼 PC를 따로 장만하지 않아도 되는데!'

하지만, 웹 서버 하나 설치하고자

용량도 크고 리소스를 많이 잡아먹는 OS를 설치하는 것은 비효율적이다.

또한 기존에 존재하는 OS 위에 가상 PC의 OS를

또다시 설치하는 것이기 때문에 PC에도 엄청난 부담이 된다.

현재

그러다가 docker의 시발점이 되는 아래와 같은 생각을 하게 된다.

'그냥 하나의 컴퓨터 안에서 웹 서버, DB 등

각각의 애플리케이션을 실행시키는데,

이 앱들을 [격리된 환경]에서 실행시키면 되지 않나?'

위와 같은 개념을 떠올리며,

사람들은 OS가 설치된 곳을 Host,

Host 위에서 실행되는 격리된 각각의 실행 환경을

Container라고 부르기로 했다.

아까 과거의 생각 중 떠올린

Vmware나 VirtualBox 같은 가상 PC와

다를 것이 없다고 생각이 들 수 있다.

하지만 각각의 Container에는 OS 전체가 아닌,

각각의 앱을 실행하는데 필요한 최소한의 lib과

bin(실행파일)만 존재한다.

이미 Host에 존재하는 OS를 Container가 모두 공유하게 되니

따로 OS를 설치할 필요도 없고,

속도도 느려지지 않게 되며,

설치에 필요한 시간 등의 절약도 가능하게 됐고,

저장장치 용량도 아낄 수 있게 되었다.

이러한 Container 방식은

Linux OS에 이미 내장되어 사용되고 있다.

그와 같은 Container 개념을 이용하는 SW 중

가장 잘 나가는 제품이 바로 Docker인 것이다.

개념 및 설치

앞서 말했다시피,

Docker와 같은 소프트웨어가 사용하는 Container 기술은

Linux OS의 기술이다.

그렇기 때문에 Docker 위에서 돌아가는 Container,

Container 안에서 동작하는 각각의 앱들은

Linux OS에서 실행되는 앱임을 알 수 있다.

그럼 내가 가진 Host의 OS가 Linux가 아니라면

Docker를 사용하지 못하는 것일까?

그렇지 않다.

내가 가진 Host의 OS가 Windows, Mac 등이어도

그 위에 가상 머신을 설치하고,

해당 가상 머신에 Linux를 설치하면,

해당 Linux 안에서 Docker를 사용할 수 있다.

아니, 지금까지 그런 설치가 까다롭고 어렵고

뭐시기 했으면서?

그러한 역할을 바로 Docker가 해주는 것이다.

알아서 가상 머신을 만들어주고 그 위에 Linux를 설치해준다.

그렇기 때문에 어느 정도의 속도 저하는 감수해야 하며

만약 Host의 OS도 Linux를 사용한다면

아주 고성능으로 사용할 수 있지만,

그럼에도 편의성이 어마어마하기 때문에

현대의 백엔드 개발자라면 거의 필수로 사용한다.

(설치는 생활코딩 Docker 입문수업 2. 설치의

1분 58초부터 보면 된다)

Git처럼 Docker 또한 GUI(Graphic User Interface)가 아닌

CLI(Command Line Interface) 환경에서 사용해야

여러 기능을 잘 사용할 수 있다.

나는 현재 M1 맥북을 사용 중인데,

기존에 설치되어 있던 Docker를 간만에 실행시켜 보니

"The data couldn't be read because it is missing"

이라는 에러가 계속 발생했다.

알고 보니, 애플이 독자적으로 개발한 M1칩에서는

기존의 Docker가 정상적으로 작동할 수 없어서 생긴 오류였다.

나 같은 경우는 Docker 홈페이지에서

Apple칩 전용 dmg 파일을 다운로드하여

기존의 Docker 위에 덮어 씌우며 재설치하니 잘 작동했다.

설치 후, 터미널에서 "docker images"를 입력했을 때

오류 메시지가 없다면 정상적으로 설치된 것이다.

Docker의 추가적인 개념

Docker에도 GitHub처럼

Docker Hub라고 하는 Registry 서비스가 존재하여

마치 애플의 App Store에서 앱을 설치하듯이

내가 원하는 "격리된 환경"을 다운로드할 수 있다.

App Store에서 다운로드하여 실행시키는 행위에 비유하며

Docker에 대한 개념을 좀 더 알아보자.

App Store에서 다운로드한 것을 Program이라고 하는 것처럼,

Docker Hub에서 다운로드 한 것은 Image라고 부른다.

다운로드 한 Program을 실행하면 Process가 생기는 것처럼,

다운로드 한 Image를 실행시키면 Container가 생긴다.

Program이 여러 Process를 가질 수 있는 것처럼,

Image도 여러 Container를 가질 수 있다.

이때 Docker Hub에서 다운로드하는 행위를 Pull이라고 부르며,

다운로드 한 Image를 실행시키는 행위를 Run이라고 부르고,

Container 안에 내장되어 있는 여러 설치 프로그램들이 자동으로 설치되어

해당 앱(Apache Server 등)을 사용 가능하게 된다.

(생활코딩 Docker 입문수업 3. 이미지 pull의

1분 40초부터 Image를 Docker Hub로부터

다운로드하는 방법에 대해 볼 수 있다)

우리는 httpd(Apache Server Image)를 사용할 것이기 때문에

아래 명령어들을 통해 Image를 다운로드하고

Image가 잘 다운로드되었는지 확인한다.

// httpd 다운로드
docker pull httpd

// Image가 잘 다운로드 되었는지 확인
docker images

httpd?

생활코딩 Docker 입문수업에서는

Apache Server의 Image를 계속해서 사용할 텐데,

Docker Hub에서는 Apache Server Image를

httpd라는 단어로 지칭하고 있다.

Docker Hub에서 httpd를 검색해보면

"official image"라고 되어있는 문구를 볼 수 있는데,

이는 docker 측에서 직접 관리하는

믿을 수 있는 Image라는 것을 알 수 있다.

기본 명령어 (Run 하는 방법)

(생활코딩 Docker 입문수업 4. 컨테이너 run의

0분 12초부터는 GUI에서,

1분 46초부터는 CLI에서 하는 방법에 대해 볼 수 있다)

위에서 하나의 Image는 여러 Container를

만들 수 있었다고 언급했던 것을 생각하며

영상과 함께 아래 명령어들을 살펴보자.

// httpd 기반의 container 실행
docker run httpd

// httpd 기반의 또 다른 container 실행, 이번에는 container에 ws2라는 이름 지정
docker run --name ws2 httpd

// container 끄기
docker stop ws2[혹은 containerID]

// 지금까지 생성한 실행 중인 container 확인하기
docker ps

// 지금까지 생성한 실행 중이며 stop 된 container까지 확인하기(-a[all] 옵션 추가)
docker ps -a

// 껐던 ws2 container 다시 켜기
// 하지만 아래 명령어로는 log 출력이 되지 않음
docker start ws2

// log 출력시키기
// 하지만 아래 명령어를 입력했을 때만 log가 나오고 바로 종료됨
docker logs ws2

// -f 옵션을 추가하여 실시간으로 계속 log 출력
docker logs -f ws2

// container 삭제
// 실행 중인 container는 바로 삭제가 불가능, stop 후 삭제 가능
docker rm ws2

// stop을 하지 않고 한 방에 삭제하는 방법
docker rm --force ws2

// Image 삭제
docker rmi httpd

다음 글에서는 docker의 추가적인 기본 명령어와

네트워크를 통해 어떤 방법으로 container가 관리되는지,

host와 container는 어떤 관계를 갖고 있는지에 대해 알아본다.

끝!

[Git] fatal: unable to access 'https://github.com//.git/': The requested URL r

대흉근 — Sun, 15 Aug 2021 13:52:22 +0900

증상

오늘, git push 하다가 갑자기 아래와 같은 에러가 발생했다.

remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead.
remote: Please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information.
fatal: unable to access 'https://github.com/***/**.git/': The requested URL returned error: 403

자세히 읽어보니 그간 Github 쪽에서 계속 메일로 알람을 보내왔던

authentication 방식 변경 이슈인 것 같다.

21년 8월 13일 자로 비밀번호 인증 시스템을 완전 폐기하고,

personal access token 방식으로 바꾸었다.

그래서 push 명령어,

아마 remote repository에 무언가를 하는 명령어는 모두 안 먹는 것이었다.

해결 방법

우선 personal access token을 발급 받아야 한다.

해당 방법은 github 공식 문서에 잘 나와있으니 따라하기만 하면 된다.

token에 부여할 scope이나 permission을 선택할 때 머리가 좀 아픈데,

나처럼 혼자 repo에 작업할 거면

"repo" 부분만 체크해주고 생성하면 된다.

마지막 단계까지 완료 후 나오는 token은 복사해서

이메일이나 메모장에 잘 저장해두어야 한다.

발급을 받았으면 이제 적용을 해야 한다.

방법은 여기 블로그를 참고하면 된다.

키체인 비밀번호를 token으로 바꾸고 나면,

정상적으로 잘 작동한다.

끝!

[Network] OSI 7계층 & TCP/IP 모델

대흉근 — Mon, 9 Aug 2021 23:22:10 +0900

나는 여태 OST 7계층이 현업에서도 자주 사용되고,

뭔가 실제로 적용되어 사용 중인 것인 줄 알았다.

하지만 말 그대로 '모델'이다.

네트워크 통신 과정을 계층별로 "개념화"한 모델이다.

이걸 왜 이제 알았지?..

물론, 현업에서도 L3 스위치, L4 스위치 등

OSI 7계층의 개념을 포함한 용어들을 쓰기 때문에

아예 모르면 절대 안된다.

하여튼 아래 글들을 참고로,

OSI 7계층과 현업에서 많이 사용하는 TCP/IP에 대해 글을 작성했다.

OSI 7계층에 대해 알아야 하는 이유?

현대인에게 온라인 통신이란,

붕어빵의 팥만큼이나

뗄레야 뗄 수 없는 관계일 것이다.

이러한 온라인 통신,

즉, 네트워크 통신을 통해 메신저, 이메일 등의

다양한 정보(데이터)를 주고 받는다.

이러한 데이터들은 '0'과 '1'로 이루어진 이진법으로 구성되고

컴퓨터는 '0'과 '1'을 '꺼짐'과 '켜짐'의 전기 신호로 표현하여,

이진법으로 구성되었던 데이터를

'아주 긴 전기 신호'로 변환하여 케이블을 통해 어디론가 보내진다.

하지만 이러한 통신 과정은 우리의 눈에 쉽게 보이지 않기 때문에

그 과정을 체계적으로 이해하고 표준화하기 위해,

또한, 초창기의 네트워크는 각 컴퓨터마다 시스템이 달랐기 때문에

하드웨어와 소프트웨어의 논리적인 변경없이 통신 가능하게 하기 위해,

1984년, 국제표준화기구(International Standard Organization, ISO)는

아래와 같은 'OSI 7계층'이라는 네트워크 표준 모델을 발표한다.

출처) https://www.sharedit.co.kr/posts/7482

이로 인해,

네트워크 통신을 하며 발생하는 각 과정들이 우리의 눈에 보이지 않아도

계층별로 분리하여 구조적으로 이해하고 학습할 수 있게 되었고,

더 나아가 그러한 과정에서 발생한 문제를 추적하여 해결할 수 있게 되었다.

이런 것들을 제외하고도,

본 글 초반부에서도 언급했듯이

현업에서도 'L3 스위치', 'L4 스위치' 등

OSI 7계층에 대한 용어를 사용하기 때문에 알아야 한다.

'프로토콜'이란?

네트워크에 대해 공부하다보면 TCP/IP 프로토콜, HTTP 등

필연적으로 만나는 단어이다.

위키백과에서 정의하는 '프로토콜'의 뜻은 아래와 같다.

"컴퓨터나 원거리 통신 장비 사이에서

메신저를 주고 받는 양식과 규칙의 체계이다"

즉, 내 컴퓨터나 스마트 폰에서 발생한 데이터가

상대방 컴퓨터 혹은 서버로 전달되기 위해서는,

발생된 전기 신호가 냅다 케이블을 타기만 하면 되는 것이 아니라

'프로토콜'이라는 표준화 된 어떠한 약속이나 절차를 따라야한다는 것이다.

OSI 7계층이란?

출처) https://velog.io/@hidaehyunlee/%EB%8D%B0%EC%9D%B4%ED%84%B0%EA%B0%80-%EC%A0%84%EB%8B%AC%EB%90%98%EB%8A%94-%EC%9B%90%EB%A6%AC-OSI-7%EA%B3%84%EC%B8%B5-%EB%AA%A8%EB%8D%B8%EA%B3%BC-TCPIP-%EB%AA%A8%EB%8D%B8

OSI 계층 구조에 대해 자세히 알아보기 전에,

위 그림을 보면 알 수 있는 점이 한가지 있다.

바로 건너뛰어 한번에 맨위 또는 맨아래로 이동할 수 없고

위, 아래 층으로만 이동할 수 있다는 점이다.

즉, 현재 위치한 계층이 '전제 조건'이 되어

다음 계층으로 넘어갈 수 있다는 뜻이다.

또한, 하위 계층(1~4계층)으로 갈수록 하드웨어에 가까워지고

상위 계층(5~7계층)으로 갈수록 소프트웨어에 가까워지는 특성도 있다.

OSI 7계층에 대해 조금 더 자세하게 설명된

아래 그림을 참고해보며 각 계층에 대해 자세히 알아보자.

출처) https://saysecurity.tistory.com/14

PDU(Process Data Unit)?

OSI 7계층에서 알아야 할 개념 중 하나인 PDU란,
각 계층에서 전송되는 단위이다.

출처) https://velog.io/@hidaehyunlee/%EB%8D%B0%EC%9D%B4%ED%84%B0-%EC%84%B8%EA%B7%B8%EB%A8%BC%ED%8A%B8-%ED%8C%A8%ED%82%B7-%ED%97%B7%EA%B0%88%EB%A6%B4-%EB%95%90-PDU%EB%A5%BC-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90

쉽게 생각하면,
사용자는 Data라고 부르는 것을
Transport 계층에서는 Segment라고 부르고,
Network 계층에서는 Packet이라고 부르고,
Data Link 계층에서는 Frame이라 부르며,
Physical 계층에서 컴퓨터 하드웨어는 그것을 Bit로 연산하고 다루는 것이다.

(엄밀히 말하면, Physical 계층에서의 PDU인 Bit는
단위라기보다 단지 전기 신호의 흐름이다)

그렇기 때문에 보통 PDU라 함은,
2계층(Data Link, 데이터 링크)에서 사용되는 프레임(Frame),
3계층(Network, 네트워크)에서 사용되는 패킷(Packet),
4계층(Transport, 전송)에서 사용되는 세그먼트(Segment)정도만 생각하며,

네트워크 통신 과정에 대해 깊게 이해하기 위해
왜 각 계층의 PDU가 다른지,
그 역할은 무엇인지에 대해 알고 있어야 한다.

7계층 - 응용 계층 (Application Layer)

사용자와 바로 연결되어 있으며, 응용 S/W를 도와주는 계층이다.

즉, 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행하는데,

이러한 일반적인 응용 서비스는 관련된 응용 프로세스들 사이의 전환을 제공한다.

응용 서비스의 예로,

우리가 자주 접하는 웹 프로토콜(HTTP),

메일 프로토콜(SMTP, POP3 등) 등을 이용하여

사용자가 네트워크에 접근할 수 있도록 인터페이스를 제공한다.

사용자로부터 정보를 입력받아 하위 계층으로 전달하고,

하위 계층에서 전송한 데이터를 사용자에게 전달한다.

TCP/IP 4계층 모델일 경우,

하위 3계층 TCP/IP 프로토콜 스택을 통해 전달받은 패킷을 다시 파싱해

응용 S/W(네트워크 S/W)를 통해 최종적으로 사용자까지 데이터를 전달한다.

대표적인 예로는,

크롬과 같은 브라우저나 Zoom 등의 여러 가지 응용 프로그램을

네트워크에 연결해주는 역할을 한다.

PDU: 데이터(Data) 또는 메시지(Message)
주요 프로토콜: HTTP, SMTP, FTP, TELNET 등
주요 장비: L7 스위치

6계층 - 표현 계층 (Presentation Layer)

코드 간의 번역을 담당하여

사용자 시스템에서 데이터의 형식상 차이를 다루는 부담을

7계층(응용 계층)으로부터 덜어 준다.

EBCDIC로 인코딩된 문서 파일을

ASCII로 인코딩된 파일로 바꿔 주는 등의

MIME 인코딩이나 암호화 등의 동작이 이 계층에서 이루어지며,

아래의 주요한 세 가지 기능을 갖고 있다.

(1) 수신자 장치에서 적합한 애플리케이션을 사용하여

송신자 장치로부터 온 데이터를 해석하기 위한 7계층 데이터 부호화 및 변환

(2) 수신자에서 압축을 풀 수 있는 방식으로 된 데이터 압축

(3) 전송을 위한 암호화와 복호화

이처럼, 데이터의 표현 방식이나

상이한 부호 체계 간의 변화에 대해 규정하며,

응용 프로그램 혹은 네트워크를 위해 데이터를 '표현'하는 계층이다.

즉, 응용 프로그램 형식을 네트워크 형식으로 변환하거나

네트워크 형식을 응용 프로그램 형식으로 변환하는 일,

다시 말해, 데이터의 변환 / 압축 / 암호화가 발생하는 계층이다.

PDU: 데이터(Data)
주요 프로토콜: 없음
주요 장비: 없음

5계층 - 세션 계층 (Session Layer)

'세션'이라는 이름답게 통신을 구성하는 계층으로,

실제 네트워크 연결이 이뤄지며

포트 번호(Port Number)를 기반으로 연결한다.

계층 이름처럼 두 대의 기기가 '대화'하기 위해서는

하나의 '세션'이 열려야 하며,

TCP/IP 세션을 만들고 없애는 책임을 지는 계층이다.

이러한 통신하는 프로세스 사이의 대화를 제어하고,

통신 과정이 진행될 때 동기화를 유지하는 역할을 한다.

PDU: 데이터(Data) 또는 메세지(Message)
주요 프로토콜: 없음
주요 장비: L5 스위치

4계층 - 전송 계층 (Transport Layer)

양 끝단(End Point 혹은 Host)의 사용자들이 신뢰성 있는 데이터를 주고 받을 수 있도록 해주어,

상위 계층들(5/6/7계층)이 데이터 전달의 유효성이나 효율성을 생각하지 않도록 해준다

(End-to-End Reliable Delivery).

종단의 구체적인 목적지(Process)까지 데이터가 도달할 수 있도록 하며

(Process-to-Process Comunication),

그러한 Process를 특정하기 위한 주소로 Port Number를 사용하여

보내고자 하는 데이터의 용량 / 속도 / 목적지를 처리하는 계층이다.

여기서 종단이란,
가령 내가 PC로 google을 접속하려 할때,
내 PC와 google 웹 서버는 종단(End Point / Host)이다.

즉, 송신지와 수신지 간(End-to-End)의 제어와 에러를 관리하기 위해

패킷의 전송이 유효한지 확인하고, 전송에 실패된 패킷을 다시 보내는 등의

신뢰성 있는 통신을 보장한다.

Port Number에 대해서는 아래의 예시를 보며 간단하게 무엇인지 알아보자.

3계층(네트워크 계층)의 IP 주소를 이용하여

목적지 시스템까지 데이터가 무사히 전달되었다고 가정해보자

(3계층이나 IP 주소 등의 생소한 용어는 아래에서 자세히 알아보고

여기서는 대충 받아들이고 넘어가자).

그 목적지 시스템에는 여러 서비스가 실행되고 있기 때문에,

(ex. 크롬 브라우저, 카카오톡, ...)

어떤 (통신) 프로그램에게 해당 데이터를 전달할지 결정하는 것이

바로 Port Number(포트 번호)이다.

이러한 4계층의 가장 대표적인 프로토콜은

TCP(전송 제어 프로토콜)이며,

보통 TCP는 IP(인터넷 프로토콜) 위에 구축되어 있기 때문에

TCP/IP로 함께 부른다.

이 4계층부터는 송/수신 측의 port number, 순서 번호, 오류 검출 코드(체크섬) 등의

부가적인 정보를 Header에 추가하여

5계층(세션 계층)으로부터 받은 Data 앞에 붙임으로서,

'세그먼트(Segment)'라는 것으로 만든다.

신뢰성 있는 데이터 전송을 위해

데이터 분할 및 재조립, 연결 제어, 흐름 제어, 오류 제어, 혼잡 제어,

주소 설정, 다중화 등을 수행한다.

PDU: 세그먼트(Segment)
주요 프로토콜: TCP, UDP
주요 장비: L4 스위치

3계층 - 네트워크 계층 (Network Layer)

여러 개의 Node(Point)를 거칠 때마다 경로를 찾아주는 역할을 하며

다양한 길이의 데이터를 네트워크를 통해 전달하고,

그 과정에서 4계층(전송 계층)이 요구하는 서비스 품질(QoS, Quality of Service)을

제공하기 위한 기능적, 절차적 수단을 제공하는,

인터넷이 가능하게 만드는 계층이다.

즉, 종단(End or Host) 간 전송을 위한 경로 설정을 담당하기 위해

(End-to-End 혹은 Host-to-Host Delivery),

종단으로 도달하기 위한 최적의 경로를 Routing 알고리즘을 통해 선택하고 제어하며,

라우팅 뿐만 아니라 패킷 포워딩, 세그멘테이션, 인터네트워킹 등을 수행한다.

여기서 'Routing'이란,

송수신 측의 논리 주소(IP 주소) 지정 및

데이터가 최종 목적지에 도달할 수 있도록 경로를 배정하는 것을 의미하는데,

우리가 학창 시절 컴퓨터에 대해 아무 것도 모르던 시절

온라인 게임에서 시비가 붙은 상대방을 겁주며 자주 언급하던 바로 그 'IP 주소'다.

논리적인 주소 구조를 나타내는 'IP 주소'는

네트워크 관리자가 직접 주소를 할당하는 계층적 구조를 가지며

PC 혹은 서버까지 데이터를 도달하게 할 수 있는 '기기의 주소'를 말한다.

다시 돌아와서,

사용자가 송신한 데이터가 목적지까지의 경로를 설정하는 역할을 하는 계층인데,

그 길목에 있는 여러 대의 라우터(Router)들을 바탕으로

Routing 알고리즘을 사용하여 최적의 경로를 선택하고,

송신 측으로부터 수신 측으로 전송한다.

4계층(전송 계층)에서 살펴 보았던 '세그먼트'와 마찬가지로,

4계층으로부터 전달 받은 '세그먼트' 앞 부분에

송/수신 컴퓨터 주소(IP) 등의 부가적인 정보를 Header에 추가한 후 붙인다.

송신 측에서는 그러한 데이터를 '패킷(Packet)'이라는 단위로 분할하여 2계층으로 전송하고

수신 측에서는 이러한 '패킷'들을 받아 다시 합친다.

수신 측 입장에서 좀 더 자세히 말하면,

3/4계층에서 사용하는 TCP/IP 프로토콜 스택이라는 녀석이

2계층에서 받은 데이터(프레임)를 Socket 인터페이스를 통해

7계층(응용 계층, TCP/IP 4계층)으로 올려보낸다

(TCP/IP 프로토콜 스택은 컴퓨터 커널(OS) 내부에 구현되며

하위 2계층(1/2계층)과 디바이스 드라이버(네트워크 드라이버)를 통해

컴퓨터 내부에서 데이터를 통신한다).

아래에서 알아볼 2계층(데이터 링크 계층)의 물리 주소는

패킷이 시스템으로 이동할 때마다 변경되지만,

네트워크 주소는 목적지까지 변하지 않는다.

또한, 2계층이 Node(Point)와 Node(Point) 사이의 전달을 감독한다고 하면,

3계층은 각 패킷이 목적지까지 성공적이고 효과적으로 전달되도록 한다.

(2계층 관련 내용은 아래 내용을 참고)

PDU: 패킷(Packet)
주요 프로토콜: IP, ARP, ICMP, IGMP, RIP, OSPF, IGRP, EIGRP, BGP, RARP 등
주요 장비: 라우터(Router), L3 스위치

2계층 - 데이터 링크 계층 (Data Link Layer)

두 개의 직접적으로 연결된 Point(Node) 간의 신뢰성 있는 데이터 전송을

보장하기 위한 계층으로 (Point-to-Point 혹은 Node-to-Node Delivery),

그에 따라 오류 제어와 흐름 제어가 필요하다.

네트워크 위의 개체들 간 데이터를 전달하고,

단순히 비트(Bit)를 전송하기만 하는 1계층 물리 계층에서 발생할 수 있는 오류를 찾아 내며,

해당 오류를 수정하는 데 필요한 기능적, 절차적 수단을 제공하여 신뢰성을 더한다.

그러한 개체(Point or Point)들의 주소 값은 물리적으로 할당 받는데,

이는 개체 내의 NIC(Network Interface Card)가 만들어질 때부터 정해져 있는

MAC(Media Access Control) 주소이다.

NIC(Network Interface Card, 유/무선)는
전기 신호를 bit 신호로 바꾸는 기능을 하며,
각 NIC마다 고유한 주소인 MAC 주소라는 것을 공장에서 만들어질 때 가진다.

이러한 주소는 체계가 없는 단일 구조이다.

그렇기 때문에 주변의 NIC와 통신하려면 주변 NIC의 MAC 주소가 필요하며
이러한 MAC 주소는 Broadcast Domain에 속한다.

쉽게 말하자면,
내 PC가 연결되어 있는 작은 네트워크 내에서만 사용될 수 있기 때문에
(ex. 이더넷)
다른 네트워크에 존재하는 개체에 데이터를 전달하기 위해서는
상위 계층(3계층 - 네트워크 계층)의 IP 주소를 이용해야 한다.

또한, 데이터 전송 시 오류가 없도록 하기 위해

3계층(네트워크 계층)으로부터 받은 '패킷'을

'프레임(Frame)'이라는 것으로 만들어 1계층(물리 계층)으로 전송한다.

보통 3계층에서 받은 '패킷'의 앞과 뒤에

MAC 주소와 제어 정보를 추가로 넣는다.

보통 1계층과 2계층이 S/W가 아닌 H/W의 통합 칩 형태로 구현되는데

임베디드 시스템보다 더 하위단의 회로 설계 관점으로 생각하면 된다.

일반적으로 컴퓨터 공학에서는 3계층,

즉, OS 커널 단에 구현된 TCP/IP와 7계층(애플리케이션 계층)과의 접점인

버클리소켓 등을 활용해 통신 S/W를 구현하는데,

그럼에도 불구하고 개발자가 2계층 기능에 대해 알아야 하는 이유는

실제 구현하는 것보다는 3계층에서 처리된 패킷이 어떻게 처리되어

통신선로를 타고 흘러가는지에 대한 원리를 설명하기 위함이다

(실제 구현은 정보통신학과나 전자공학에서 심도 깊게 연구된다).

PDU: 프레임(Frame)
주요 프로토콜: PPP, HDLC, ADCCP, LLC, ALOHAX.25, Ethernet, TokenRing, DFFI, FrameRelay 등
주요 장비: L2 스위치, 브릿지(Bridge) 등

1계층 - 물리 계층 (Physical Layer)

실제 장치들을 연결하기 위해 필요한 전기적, 물리적 세부 사항들을 정의한다.

좀 더 자세히 말하자면,

2계층인 데이터 링크 개체 간의 Bit 전송을 위한 물리적 연결을

설정, 유지, 해제하기 위한 수단을 제공한다.

상위 층들과 달리 주소 개념이 없으며,

물리적으로 연결된 Node 간에 신호를 주고 받는다.

즉, 상위 계층(2~7계층)에서 전송된 데이터를

물리 매체(ex. 허브, 라우터, 케이블 등)를 통해

다른 시스템에 전기적 신호(bit, 비트)를 전송하는 역할을 한다.

기계어(디지털 데이터)를 아날로그적인 전기적 신호로 변환하여

와이어에 실어 전송하는 일을 하기 때문에

케이블 종류, 무선 주파수 링크, 핀, 전압 등의 물리적인 요건을 포함한다.

예를 들면,

핀들의 배치나 전압, 전선의 명세 등과

LAN 케이블의 전기적 신호인 유선 LAN 통신,

무선 AP와 통신하는 무선 주파수인 무선 LAN 통신 등이 있다.

라우터나 스위치의 전원이 켜져 있는지,

케이블이 제대로 연결되어 있는지 등에 관한 것도

여기 1계층에 해당되는 이야기다.

그뿐 아니라, 여러 사용자들 간의 통신 자원을 효율적으로 분배하는 데에도 관여한다.

(ex. 경쟁 상태의 해소 or 흐름 제어 등)

PDU: 비트(bit)
주요 프로토콜: X.21, RS-232C 등
주요 장비: 허브(Hub), 리피터(Repeater), 네트워크 카드(NIC, Network Interface Card) 등

캡슐화

어떠한 시스템에서 동작하는 어플리케이션으로부터

다른 시스템에서 동작 중인 어플리케이션에 데이터를 보낸다고 가정하자.

출처) https://saysecurity.tistory.com/14

어플리케이션이 사용하는 데이터는 위 그림처럼 7계층(응용 계층)에 해당한다.

보내려고 하는 메세지(데이터)를 전송하려면 7계층(응용 계층)부터

1계층(물리 계층)까지 타고 내려가야 하는데,

계층을 하나씩 내려갈 때마다 상위 계층으로부터 받은 데이터는

해당 계층에서는 관심 대상이 아니기 때문에 캡슐로 싸고

필요한 정보를 header라는 이름으로 앞에 추가로 달고

아래 계층으로 보낸다.

이러한 과정이 계층을 내려갈 때마다 반복되기 때문에

'캡슐화'라는 용어를 사용하며,

1계층(물리 계층)까지 도착한 데이터는

보내려고자 했던 다른 시스템의 어플리케이션에 도착하여

캡슐화의 반대 과정을 통해 데이터를 얻게 된다.

TCP/IP 모델

하지만 앞서 말했듯이,

OSI 7계층 모델은 참조 정도로만 보는 이론적 표준(De jure)이고,

실제 사용되는 사실상의 표준(De facto)은 TCP/IP 모델이다.

이러한 TCP/IP 모델은 아래 그림에서 볼 수 있듯이,

OSI 7계층 구조를 완벽히 따르지는 않는다.

출처) https://saysecurity.tistory.com/14

대부분은 위 그림의 TCP/IP 모델을 따르며,

데이터의 흐름 관리, 정확성 확인, 패킷의 목적지 보장을 담당한다.

주로 TCP가 데이터의 정확성 확인을,

IP가 패킷을 목적지까지 전송하는 일을 담당한다.

끝!

[Git] Repository 생성 후 Main -> Master 브랜치로 변경하기

대흉근 — Sun, 8 Aug 2021 23:49:48 +0900

최근 PC 관련 논쟁이 거세지면서,

IT 용어들에도 큰 영향을 미쳤는데 그중 하나가 Git 용어다.

바로 Master로 생성되던 default branch 이름이

Main으로 바뀐 것.........

뭐... 음...

하여튼 나처럼 Master로 써오던 사람은 불편한 경우가 꽤 있었는데,

repository 최초 생성 후 기존 소스 코드를 연동할 때

현재 위치한 branch가 main인 상태에서

아래 명령어들로 Main 브랜치를 Master 브랜치로 변경 가능하다.

git remote add origin https://github.com/[GIT_USER_ID]/example.git
git branch -M master
git push -u origin master

git remote나 push 명령어는 이 글을 찾아온 사람이라면 알 것이고,

git branch에 붙은 "-M" 옵션이 핵심이다.

어떤 기능인고 찾아보니, 아래 사이트에서 관련 설명을 찾을 수 있었다.

https://git-scm.com/docs/git-branch

Git - git-branch Documentation

If --list is given, or if there are no non-option arguments, existing branches are listed; the current branch will be highlighted in green and marked with an asterisk. Any branches checked out in linked worktrees will be highlighted in cyan and marked with

git-scm.com

With a -m or -M option, <oldbranch> will be renamed to <newbranch>.
If <oldbranch> had a corresponding reflog, it is renamed to match <newbranch>, and a reflog entry is created to remember the branch renaming.
If <newbranch> exists, -M must be used to force the rename to happen.

git branch -M master을 입력했으니,

현재 위치한 main 브랜치 이름이 master로 변경된 것이다.

끝!

[Trouble Shooting][DB][MSSQL] Incorrect Syntax near ''. / '' 근처의 구문이 잘못되었습니다. 해결 방법

대흉근 — Mon, 2 Aug 2021 10:35:06 +0900

(2021.08.12) 추가

분명 아래 해결 방법으로 수정하여 QA 서버에서 잘 동작하던 쿼리가 운영 서버에서는 또다시 글 제목과 같은 에러가 발생했다.

그래서 '운영 서버 코드에 내가 수정한 내역이 적용 되지 않았나..?' 하는 말도 안되는 일을 의심하며 확인했지만..

역시 그런 일은 없었다. 그럼 뭘까..

SSMS는 자꾸 조회 쿼리의 첫 줄에서부터 에러가 발생한다고 묵묵히 로그를 뱉는다.

진짜 혹시나 해서 SELECT 앞에서 delete 키를 눌러봤는데..

...?

눈에 보이지 않는 글자 하나가 지워진다.

협력사 굇수 형님께 여쭤보니 인코딩 문제일 가능성이 높다고 하신다.

그래서 개발자들 사이에서 이런 환경 세팅을 다 동일하게 해야 한다고.. ㅠ

하여튼 진짜 끝...

SSMS에서 쿼리 수정 후, xml 파일에 복사-붙여 넣기를 했는데 자꾸 글 제목과 같은 에러가 발생했다.

해결책은 아래 사이트에서 발견했다.

- [Stack Overflow] Incorrect syntax near ''

Incorrect syntax near ''

I'm trying to run the following fairly simple query in SQL Server Management Studio: SELECT TOP 1000 * FROM master.sys.procedures as procs left join master.sys.parameters as params on p...

stackoverflow.com

이상한 공백 글자나 줄 바꿈 글자 때문에 발생하는 것으로 추정되어 쿼리 라인을 하나 하나 다시 보니,

라인 끝에 공백이 들어간 몇 줄이 있었다.

그 녀석들을 지우고 다시 배포해보니 잘 돌아감!

추가로 로컬 환경에서 쿼리 수정 후,

reload query와 같은 명령어를 콘솔에서 입력해주어야 메모리 상에서 들고 있던 쿼리들을 비우고 내가 수정한 쿼리를 반영할 수 있다는 것을 알았다.

위 명령어는 협력사에서 편의상 만든 내부 명령어라고 함.

끝!

[DB] 인덱스란? - (3) 인덱스 스캔 방식 [개념]

대흉근 — Sun, 18 Jul 2021 23:10:26 +0900

이전 글들에서 DB 인덱스의 개념과 장단점, 쓰는 이유와

인덱스를 구성하고 있는 구조 등에 대해 알아봤다.

(1편, 2편)

이번 글에서는 그러한 인덱스를 사용하여

원하는 데이터를 찾아가는 과정에서

어떠한 데이터 스캔 방식을 사용하는지에 대해 알아본다.

완전히 동일하지는 않지만 일맥상통한 비유를 들자면,

Searching Algorithm에서 Linear Search, Binary Search 등을

떠올리면 어느 정도 감이 잡힐 것이다.

이번 글은 아래 글들을 참고하여 작성했다.

인덱스 스캔(Index Scan)이란?

이전 글들을 보면 알겠지만,

인덱스라는 녀석도 결국 하나의 Mapping 테이블,

정확히는 아래처럼 Tree 구조로 데이터가 저장되어있다.

(무슨 트리인지는 대충 넘기고 구조만 보자, 구조만)

(구조 관련 자세한 내용은 이전 2편 글을 참고)

출처) https://dataonair.or.kr/db-tech-reference/d-guide/sql/?uid=366&mod=document&pageid=1

그렇기 때문에 이러한 트리 구조에서

어떻게 하면 가장 효율적인 방법으로

원하는 인덱스를 찾을 수 있을 지에 대한 내용이 바로

인덱스 스캔(Index Scan)이다.

인덱스 스캔 방식들에 대해 자세히 알아보기 전에,

위 그림을 토대로 러프하게 핥아보고(?) 가자.

인덱스 탐색 과정은 크게 아래 두 가지로 나눌 수 있다.

'수직적 탐색'과 '수평적 탐색'.

먼저 '수평적 탐색'은 트리의 가장 아래에 있는

리프 노드끼리 연결된 순서에 따라

좌에서 우, 또는 우에서 좌로 스캔하기 때문에

'수평적'이라고 표현한다.

이러한 '수평적 탐색'을 위한 시작 지점을 찾는 과정을

'수직적 탐색'이라고 하며,

루트 노드에서 리프 노드까지 아래로 진행하기 때문에

'수직적'이라고 표현한다.

그럼 위 그림에서 키 값이 51인 레코드를 찾아보자.

1. 먼저 루트 블록에서 51(키 값)이 속한 블록을 찾는다.

2. 3번 블록에 속하므로 3번 블록으로 이동한다.

3. 3번 블록에서 다시 51(키 값)이 속한 블록을 찾는다.

4. 9번 블록에 속하므로 9번 블록으로 이동한다.

5. 9번 블록은 리프 블록이므로 여기서 원하는 값을 찾거나 못 찾거나 둘 중 하나다.

6. 다행히 첫 번째 레코드에 51(키 값)이 존재하므로 함께 저장된 RowID(value 값)을 분석한다.

이 RowID를 분해해 보면, Object 번호 / 데이터 파일 번호 / 블록 번호 / 블록 내 위치 정보

등을 알 수 있다.

7. 위에서 얻은 정보를 통해 실제 테이블에서 원하는 레코드를 찾아낸다.

사실 위 7번에서 끝은 아니다.

위 인덱스들이 Unique 한 인덱스가 아닌 이상,

키 값이 51인 레코드가 더 있을 수 있기 때문이다.

따라서 9번 블록 내에서 레코드 하나를 더 읽어

키 값이 51인 레코드가 또 있는지 확인하며,

51인 레코드가 더 이상 나오지 않을 때까지 스캔하며

7번의 실제 테이블 접근 단계를 반복한다.

만약 9번 블록을 다 읽었는데도 계속 51이 나온다면,

10번 블록으로 넘어가서 스캔을 계속한다.

간단하게 핥아보자고 해놓고 또 길어졌다.

Index Scan vs Full Table Scan

본격적으로 알아보기 전,

진짜 진짜 마지막으로 하나만 더 짚고 넘어가자.

잘 생각해보면 인덱스라는 녀석이 탄생하기 전에는

DB의 전체 테이블을 처음부터 쭈욱 읽어야 했을 것이다.

이것이 무조건 좋지 않은 방법일까?

답은 '아니요'다.

어떠한 테이블의 row의 개수가 10,000개이고,

테이블 내 1 block == 10 row 이면서

인덱스 column의 분포도는 10%,

인덱스 row에 대응하는 테이블의 row는

각 block에 하나씩만 존재(최악의 경우)한다고 가정해보자.

(여기서 '분포도'란, 테이블에 어떠한 컬럼이 평균적으로 분포되어 있는 정도,

즉, [데이터 별 평균 row 수] / [테이블의 총 row 수] * 100 = 1 / [column 값의 종류] * 100이다.

ex. 5개의 사업장을 가진 회사의 '사업장' column 값의 종류는 5이므로,

'사업장' 컬럼의 분포도는 1 / 5 * 100 = 20%이다)

먼저 아래와 같은 Full Table Scan의 수행 방식을 보자.

출처) http://jidum.com/jidums/view.do?jidumId=183

먼저, DB 테이블의 첫 번째 블록부터 순서대로 접근한다.

테이블의 전체 블록이 모두 접근될 때까지 계속 수행한다.

그렇기 때문에 접근하는 총 block의 수,

즉, Scan Cost는 아래와 같이 계산된다.

테이블의 총 row 수 / 블록 내의 row 수 = 10,000 / 10 = 1,000개

다음으로 Index Scan의 수행 방식을 보자.

출처) http://jidum.com/jidums/view.do?jidumId=183

먼저, 이전에 알아보았던 B-Tree 구조를 이용하여

특정 조건을 만족하는 첫 번째 인덱스 row에 접근한다.

해당 인덱스 row에 있는 RowID 정보를 이용하여

대응되는 실제 테이블의 row에 접근한다.

그다음, 인덱스 row가 끝날 때까지

인덱스 row를 차례대로 스캔하며

대응되는 실제 테이블의 row를 찾는 작업을 반복한다.

이 방식의 Scan Cost는 아래와 같이 계산된다.

(1) 총 인덱스 수 = 테이블의 총 row 수 * 인덱스 column 분포도 = 10,000 * 10% = 1,000개

(2) 인덱스에 대응하는 테이블의 row가 각 block 당 1개이므로, 1,000개의 블록 접근 필요

위의 계산을 통해, 두 경우 모두 1,000개의 블록 접근이 필요하기 때문에

인덱스 사용의 손익 분기점은 10% 임을 알 수 있고,

칼럼의 분포도가 10~15% 이상인 경우는

인덱스의 RowID를 통한 Random Access 비용 때문에

Table Full Scan이 더 좋은 것을 알 수 있다.

이러한 이유들 때문에 인덱스는 반드시

적은 양의 데이터를 조회할 때에 유리하고,

그 외에는 Full Scan이 더 유리하다.

위 내용 관련해서 아래 글을 참고하면 더욱 이해가 쉽다.

[mysql] 조회, Index냐 Full Scan이냐

아....

글이 또 너무 길어졌다.

다음 글에서는 진짜 인덱스 스캔 종류에 대해 알아본다..

끝!

[Algorithm][LeetCode][Medium][Python] 56. Merge Intervals

대흉근 — Thu, 1 Jul 2021 10:40:56 +0900

문제는 여기서 볼 수 있다.

특별한 알고리즘 기법이 필요한 문제는 아니다.

내 풀이

바로 코드 먼저 보자.

class Solution:
    def merge(self, intervals: List[List[int]]) -> List[List[int]]:
        if len(intervals) == 1:
            return intervals
        
        result = []
        intervals.sort(key = lambda x: x[0])
        
        leftIdx, rightIdx = 0, 1
        tempElement = intervals[leftIdx]
        while rightIdx < len(intervals):
            if tempElement[1] < intervals[rightIdx][0]:
                result.append(tempElement)
                leftIdx = rightIdx
                tempElement = intervals[leftIdx]
            else:
                tempElement[1] = max(intervals[leftIdx][1], intervals[rightIdx][1])
            rightIdx += 1
            
        if not result or result[-1][1] != intervals[-1][1]:
            result.append(tempElement)
        
        return result

우선, 내가 생각한 핵심 알고리즘을 구현하기 전에

입력 배열에 대해 sorting이 이루어져야

좀 더 쉽게 구현이 가능하다는 생각이 들었다.

입력 배열은 2차원 배열이므로

각 원소 배열의 첫 번째 인자를 기준으로 sorting을 한다.

그 후, 내가 구현한 핵심 알고리즘은 Two-Pointer 방식이다.

left 인덱스, right 인덱스를 두고

마지막에 return할 result라는 리스트에 붙일

tempElement라는 임시 원소 리스트를 만들어간다.

퍼포먼스는 아래처럼 느린 편이다.

예전 내 풀이

이 문제도 역시나 예전에 풀었던 문제인데,

지금 방법보다 훨씬 빠른 퍼포먼스로 풀었더라.

어이-! 똑똑하잖아 과거의 나 -! !

코드는 아래와 같다.

class Solution(object):
    def merge(self, intervals):
        if intervals == []:
            return []
        
        intervals.sort(key=lambda x: x[0])
        n_intervals = [intervals[0]]
        
        x = 0
        for i in range(1, len(intervals)):
            if n_intervals[x][0] <= intervals[i][0] <= n_intervals[x][1]:
                n_intervals[x][1] = max(n_intervals[x][1], intervals[i][1])
            else:
                n_intervals.append(intervals[i])
                x += 1
                
        return n_intervals

핵심 알고리즘 부분 빼고 다 똑같다.

사실 핵심 알고리즘 부분도 원리는 똑같다.

단지, Two-Pointer 방식에서 for문으로 바꿨을 뿐이다.

그런데 퍼포먼스 차이는 아래처럼 차이가 크다.

아마 원인은 tempElement 때문인 것 같다.

최근에 내가 푼 풀이에서는 tempElement라는

임시 리스트를 두어 붙여 나가는 방식을 사용했는데,

예전에 내가 푼 풀이에서는

return할 결과 list에 바로바로 붙여나가는 방식을 사용했다.

러프하게 말하면 append 작업이

2번에서 1번으로 줄어들어 퍼포먼스 또한 좋아진 것 같다.

생각보다 append 작업이 시간을 많이 잡아먹네;

끝!

[ETC][일상] 기업에서 강조하는 협업, 커뮤니케이션 능력?

대흉근 — Mon, 28 Jun 2021 23:06:16 +0900

신입, 경력 채용 공고의 지원 자격을 보면

100이면 100,

협업과 커뮤니케이션 능력 항목이 꼭 있다.

취준생 때, 그런 항목을 보며

'사회적으로 고립되어 있지 않고, 사람들과 대화 잘 나누는 정도면 되는 건가?',

'대학교 조별 과제도 별 사고 없이 해냈는데, 자격 충분한 거 아닌가 ㅋㅋ'

같은 생각을 했었다.

인턴 생활과 정직원 생활을 1년 조금 넘게 지내보며

그러한 생각들은 빙산의 일각의 일각의 일각임을 느끼고 있다.

위와 같은 생각들이 틀리다는 것은 아니다.

다만, 일상적인 생활에서는 접할 수 없는

여러 사람들과 얽힌 복잡한 상황을 고려해 보아야 한다.

예를 들어,

SI 기업에 다니며 고객사 시스템을 운영 중인 나에게

고객사로부터 신규 기능 추가 건이 요청되었다고 가정하자.

그럼 먼저 고객사가 요구하는 사항들의 명세화,

쉽게 말해 신규로 추가할 기능의 자세한 내역들이 필요하다.

고객사는 '아니, 이거 그냥 추가하면 되는 것 아니에요?'라고

말할 가능성이 아~주~높~다~

'예, 아닙니다' 대답하며 왜 아닌지를 설명하고 설득시켜

나도 좋고 고객사도 좋은 요구사항 명세서를 끌어내야 한다.

이 과정에서 필요한 것이 바로 커뮤니케이션 능력이다.

내가 운영 중인 시스템을 정확히 파악 중이라는 전제 하에,

IT를 전혀 모르는 사람도 내 말을 듣고

'아, 그런 이유 때문에 A 기능 구현보다는 B 기능 구현이 낫겠군요'

라는 말을 이끌어낼 수 있어야 한다.

그렇게 상세한 요구사항 명세서를 이끌어냈다면,

이제 협업이 추가된다.

왜?

우리는 혼자 일하지 않기 때문에.

디자이너, 퍼블리셔, 프론트엔드, 백엔드 등등

내가 운영 중인 시스템에 얽힌 업무의 직원 분들과 이야기를 하며

고객사의 요청을 어떤 방식으로 시스템에 녹여낼지,

이야기하고 이야기하고 또 이야기해야 한다.

이러한 과정을 몇 번 거치다 보면,

결국 흔히들 말하는 '교통정리'를 잘해야

일이 수월하고 빠르게 효율적으로 진행된다.

그 '교통정리'에 필요한 것이 바로

협업과 커뮤니케이션 능력인 것이고,

단순히 일상생활에서

친구와, 선배와, 지인들과 이야기가 잘 통한다고

업무적인 커뮤니케이션 능력이 좋다고 단정 지을 수는 없다.

누군가와 협업 혹은 커뮤니케이션을 하게 될 때는

항상 정신 바짝 차려야 한다.

그래야 나도, 그 사람도 번거롭게 일을 두 번, 세 번 하지 않을 수 있다.

끝!

[ETC][일상] 개발자 소양의 1순위 - 꼼꼼함

대흉근 — Wed, 23 Jun 2021 16:53:55 +0900

현재 몸 담고 있는 SI 업 특성 상,

협력사 개발자 분들과 같이 일하며

개발적인 부분에서 많은 도움과 배움을 받는다.

그 중에서도 6년 차 시니어 개발자 분이 계신데,

정말 신중하고 꼼꼼한 개발 스타일을 갖고 계셔서

이분께 이것저것 여쭤 볼 때마다 정말 많이 배운다.

그 때문에 이분의 영향을 크게 받았는지,

누군가 개발에서 가장 중요한 요소 하나를 꼽으라고 한다면

"꼼꼼함"일 것 같다.

예를 들어,

어떠한 화면에서 신규 기능을 추가할 함수를 찾을 때

러프하게 프로그램 로직과 함수 명만 보고 결정하는 것이 아니라,

실제로 화면 로딩에서 해당 함수를 타는 것이 맞는지

꼭 확인을 거치는 습관을 들여야 안전하다는 말씀을 해주셨다.

또한 내가 수정 및 추가한 코드로 인해

발생 가능한 사이드 이펙트를 철저하게 조사하고,

테스트를 정말 꼼꼼하고 다양하게 아주 많이 해야 한다.

그리고 고객이 요청한 단순한 수정 요청을

단지 요청대로만 수정할 것이 아니라,

고객의 입장에서 생각해보며 추가로 수정하거나

신규로 추가할 부분을 찾아보기도 하고,

해당 수정 요청이 정말로 "단순"한지도 생각해보아야 한다.

이러한 부분에서 보면,

결국 협업과 의사 소통 능력 발달에도 이어지는 것 같다.

하여튼, 업무 효율에 방해가 될 정도로 지나치게 꼼꼼하면 안되겠지만

꼼꼼함은 필요하다.

[ETC][DB][SQL] WHERE 뒤에 붙는 '1=1' 의미

대흉근 — Mon, 14 Jun 2021 22:18:50 +0900

업무를 하며 기존에 작성된 쿼리 문들을 보면,

간혹 WHERE 절 뒤에 '1=1'이라는 녀석이 붙은 것을 볼 수 있었다.

어떤 의미인지, 또 언제 사용하는지 궁금하여 알아보았던 내용을 작성한다.

WHERE 절?

이 글을 찾아온 것 자체가

WHERE 절이 무엇인지 알고 있을 것이라 생각한다.

'어디'라는 WHERE의 의미처럼,

내가 DB로부터 가져오고 싶은 데이터의

'조건'을 걸어주는 부분이다.

가정

이 글의 목적이었던 '1=1'의 의미를 얼른 알아보기 전,

아래와 같은 간단한 쿼리 문이 있다고 가정하자.

SELECT
    TOP 100 *
FROM
    GYM_USER
WHERE
    SQUAT >= '160'
    AND BENCHPRESS >= '80'
    AND DEADLIFT >= '180'

GYM_USER라는 테이블로부터

상위 100개의 레코드(행)를 조회해 올 것인데

SQUAT이 '160' 이상, BENCHPRESS가 '80' 이상,

DEADLIFT가 '180' 이상인 녀석들만 조회할 것이다.

그렇게 위의 쿼리 문을 신나게 사용하다가,

고객사로부터 아래와 같은 요구를 받게 된다.

"이번 달 동안만, SQUAT이 '160' 이상인 조건은 빼주세요."

그렇다면 아래 두 가지 프로세스를 거쳐야 한다.

1. "SQUAT >= '160'" 주석 처리

2. "AND BENCHPRESS >= '80'" 부분에서 "AND" 삭제

혹은 해당 라인 주석 처리 후, "BENCHPRESS >= '80'" 새로 입력

WHERE 1=1 ?

아주 간단한 예제라 별 거 없지만,

더욱 복잡한 WHERE 절의 쿼리 문과 요구사항이라면

꽤나 귀찮은 단계를 거쳐야 할 것이다.

이럴 때를 대비하여 사용하는 것이 '1=1'이다.

'1=1'은 '1은 항상 1과 같다'라는 의미처럼

언제나 TRUE인 조건을 뜻하기 때문에,

WHERE 절 뒤에 '1=1'만 적용한다면

사실상 조건을 걸지 않은 것과 동일하여 모든 데이터를 조회해온다.

위에서 보았던 쿼리 문에서 '1=1'을 사용하여 수정해보고,

고객사의 요구 사항을 반영해보자.

SELECT
    TOP 100 *
FROM
    GYM_USER
WHERE 1=1
    --AND SQUAT >= '160'
    AND BENCHPRESS >= '80'
    AND DEADLIFT >= '180'

주석 처리인 '--' 하나만 넣어주면 끝난다, 깔깔.

만약, BENCHPRESS와 DEADLIFT 조건들도 주석 처리를 해주면

"WHERE 1=1"만 남게 되어

GYM_USER 테이블의 상위 100개의 레코드(행)를

아무 조건 없이 모두 불러올 것이다.

아주 사소하지만, 쿼리 문을 작성하거나 수정할 때 사용하면 효율적이다.

끝!

[DB] 인덱스란? - (2) 구조, B-Tree 계열을 쓰는 이유

대흉근 — Mon, 7 Jun 2021 16:05:48 +0900

거의 모든 DBMS는 인덱스 종류에 대해 특별한 언급이 없다면,

B-Tree 계열 인덱스를 사용하는 경우가 대다수이다.

많고 많은 자료구조에서 왜 하필 B-Tree, B+-Tree를 사용하는지에 대해 알아본다.

이 글을 읽기 전에 이전 글을 읽고 오면 좋으며, 아래 사이트들의 내용을 토대로 작성했다.

Tree란?

이 글을 찾아왔다는 것 자체가 Tree에 대한 개념은 이미 알고 있을 것이라 생각하고,

먼저 시간 복잡도에 대해 생각해보자.

출처) https://helloinyong.tistory.com/296

일반적으로 위의 그림처럼 평균적으로 생긴 Tree에서 탐색에 대한 시간 복잡도는

O(log N)이다,

출처) https://helloinyong.tistory.com/296

하지만, 위의 그림처럼 Tree의 형태가 한쪽으로 추욱 늘어진 최악의 경우엔

O(N)이다.

이러한 최악의 경우를 대비해서 Balanced Tree라는 것을 사용한다.

Balanced Tree?

말 그대로 "균형잡힌 Tree"로,

위에서 본 Tree 구조의 최악의 경우처럼,

트리가 한쪽으로 쏠리지 않게 노드 삽입 및 삭제 시에 특정 규칙에 따라 트리가 재정렬되어

좌 / 우 SubTree의 밸런스를 유지하는 Tree이다.

항상 좌 / 우 SubTree 간에 밸런스를 유지하고 있기 때문에

탐색에 대한 시간 복잡도는 언제나 O(log N)이지만,

노드 삽입 및 삭제 시 발생하는 재정렬 작업 때문에

탐색을 제외한 작업에서는 일반 Tree보다 성능이 좋지 않다.

이러한 Balanced Tree의 예시에는 AVL-Tree, RedBlack-Tree, B-Tree 등이 있다.

왜 하필 (Balanced) Tree를?

Balanced Tree는 최악의 경우에도 탐색 시간이 O(log N)이므로,

탐색 기능 자체만 봤을 때에는 효율적인 자료구조임을 알 수 있다.

하지만 이전 글에서 Hash에 대해 공부하며,

Hash Table이라는 자료구조는 (평균적으로) 모든 자료구조 중 가장 빠른 탐색 시간인

O(1)을 가지는 것을 배웠다.

(Hash 관련 글 1편, 2편, 3편)

그렇다면 왜 Hash Table을 쓰지 않고 Balanced Tree를 쓸까?

DB 인덱스가 빠른 데이터 조회를 위해 사용하는 것이라면,

Hash Table을 사용하는 것이 더 효율적인 것 아닐까?

Hash Table의 치명적 단점

출처) https://helloinyong.tistory.com/296

Hash Table을 DB 인덱스로 사용할 수 없는 이유에 대해 알아보기 전에

간단하게 개념 먼저 복습하자.

Hash Table은 Hash Function이라는 특정 계산을 하는 함수에 입력 값(keys)이 들어오면

언제나 같은 결과 값(Hash 값)을 내뱉는다.

그리고 이 결과 값은 Hash Table(buckets)의 index 값으로 매핑되어 찾고자 하는 데이터를 얻을 수 있고,

이 과정은 미리 저장된 메모리 공간(Hash Table)에 한 번에 접근을 하기 때문에

O(1)이라는 어떠한 자료구조나 알고리즘보다 빠른 탐색 시간을 갖게 된다.

(물론 Hash 값이 충돌이 일어나는 등의 최악의 경우, O(N)이 될 수도 있다)

이러한 Hash Table의 동작 원리를 머리에 담고,

우리가 DB를 사용할 때 어떤 방식으로 데이터를 조회하는지 생각해보자.

Select CustomerName From Customer Where CustomerID = '2'

위 SQL 쿼리문처럼 조건에 등호(=)만 써서 데이터를 조회했던가?

아니다, "Where CustomerID >= '2'"처럼 부등호도 사용한다.

오히려 이처럼 특정 범위의 값을 조회하는 일이 더 많을 수도 있다.

다시 Hash Table로 돌아오면,

O(1)이라는 탐색 시간은 "단 하나의 데이터를 탐색하는 시간"이다.

그리고 Hash Table에 저장되는 값들은 정렬되어 있지 않기 때문에

특정 값보다 크거나 작은 값을 찾을 수 없다.

혹여 찾을 수 있다 하더라도 O(1) 보다 더 오랜 시간이 걸릴 것이다.

이러한 이유 때문에 DB 인덱스의 자료구조로 Hash Table은 매우 비효율적이어서 잘 사용하지 않고,

Balanced Tree를 사용한다.

그럼 다른 Balanced Tree나 자료구조는?

글 초반부에 Balanced Tree에 대해 설명하며 RedBlack-Tree와 B-Tree를 언급했었다.

두 트리 모두 Balanced Tree이기 때문에

최악의 경우에도 데이터 탐색 시간 O(log N)을 보장하는데,

왜 RedBlack-Tree는 DB 인덱스의 자료구조가 되지 못했을까?

해당 이유에 대해 알아보기 전에 두 트리가 어떤 것인지 간단하게 살펴보자.

RedBlack-Tree?

출처) https://helloinyong.tistory.com/296

RedBlack-Tree는 위 그림처럼 각 노드(node)가 하나의 데이터만 가진 상태로

좌 / 우 SubTree의 밸런스를 유지한다.

빨간색(Red)과 검은색(Black) 노드로 구분 지어

노드의 삽입 및 삭제 작업 시, 정해둔 규칙들에 맞게 노드들을 재 정렬하며

AVL-Tree보다는 약간 완화된 버전으로 생각하면 된다.

(더욱 자세한 설명은 위키백과의 글을 참고)

B-Tree?

출처) https://helloinyong.tistory.com/296

B-Tree는 위처럼 하나의 노드에 여러 데이터가 저장 가능한 트리이며,

Root - Branch - Leaf의 형태를 갖고 있다.

노드 내의 데이터들은 항상 정렬된 상태이며,

해당 데이터들 사이의 범위를 이용하여 자식 노드를 가질 수 있기 때문에

노드 내 데이터의 개수가 N개일 때, 자식 노드의 개수는 (N + 1) 개다.

DB 인덱스를 B-Tree로 구성할 경우,

가장 아래의 Leaf Node에 인덱스 Value에 대한 RowID를 저장한다.

(TMI)

인덱스를 구성하는 컬럼의 Cardinality가 높은 경우, 즉, 중복된 값의 Row가 적은 비율을 가지는 컬럼,

다시 말해, 컬럼의 분포도가 10~15% 이내인 경우 적합하다.

RedBlack-Tree의 치명적 단점

위 그림들만 봐도 알 수 있듯이,

RedBlack-Tree와 B-Tree의 가장 큰 차이는 '하나의 노드 내의 데이터 개수'이다.

RedBlack-Tree는 하나의 노드 내에 무조건 하나의 데이터만을,

B-Tree는 하나의 노드 내에 여러 데이터를 저장할 수 있다.

이러한 데이터 저장 방식의 차이는 어떤 차이를 일으킬까?

바로 "데이터 탐색 시의 속도 차이"다.

Tree 자료구조에서 데이터를 탐색할 때에는,

가장 위에 있는 root 노드부터 시작하여 찾는 데이터가 나올 때까지

자식 노드로 내려가며 탐색한다.

RedBlack-Tree의 구조를 보면 하나의 노드에 하나의 데이터만 있기 때문에

자식 노드로 넘어가는 횟수가 많을 것이고,

그러한 노드와 노드 사이는 "참조 포인터(reference pointer)"로 연결되어 있다.

하지만 B-Tree의 경우,

하나의 노드 내에 정렬된 데이터들이 마치 "배열"의 모습을 띄고 있는데

실제 메모리 상에 배열처럼 차례대로 저장이 되어있다.

컴퓨터 공학 관련 과목이나 공부를 해본 사람이라면,

포인터로 메모리에 접근 시 CPU 연산을 통해 주소를 알아내는 등의 부가적인 연산이 필요하기 때문에

실제 메모리 디스크에서 바로 다음 인덱스로 접근을 하는 배열 방식이

포인터 접근을 하는 것보다 훨~씬 빠르다는 것을 알 것이다.

물론, 이론적인 시간 복잡도는 두 트리 모두 O(log N)이지만

위와 같은 물리적인 메모리 처리에서 퍼포먼스 차이는 배열 구조의 접근 방식이 굉장히 빠를 수밖에 없다.

데이터 개수가 무의미할 정도로 적다면 상관없겠지만,

유의미할 정도로 많은 개수를 다룬다면 큰 차이가 있을 것이다.

(참고 - B-Tree 시간 복잡도 계산)

B-Tree에서 시간 복잡도를 계산할 때,

노드들 간 탐색 시간인 O(log N)과 하나의 노드 내 데이터를 탐색하는 시간인 O(log M)을

따로 계산해야 하는지 의문이 생길 수 있다.

하지만, 일반적으로 B-Tree는 하나의 노드에 저장될 노드 개수를 상수로 제한하기 때문에

시간 복잡도 계산에서 제외된다.

그럼 배열을 쓰면 되지 않나?

RedBlack-Tree를 사용하지 않는 이유가 포인터 접근 방식으로 인한 속도 이슈 때문이라면,

아예 배열을 DB 인덱스로 사용하면 되지 않을까?

응, 아니다.

배열의 치명적 단점

출처) https://helloinyong.tistory.com/296

배열에 대한 설명은 최근 올라온 유튜브 영상(링크)으로 대체한다.

노마드 코더로 유명한 니콜라스 님의 12분짜리 배열 설명 영상인데

말씀하시는 속도가 느려서 2배속으로 봐도 충분하다.

출처) https://www.geeksforgeeks.org/search-insert-and -delete-in-a-sorted-array

위 영상을 보면 알겠지만,

배열이라는 자료구조에서 빠른 것은 "탐색"뿐이다.

삽입 및 삭제 시에는 기존 데이터들을 이동하는 시간이 걸려서

평균적으로 O(N), 최악의 경우 O(N * log N)이 걸린다.

결국 답은 B-Tree

결국 DB 인덱스로 B-Tree가 적합한 이유는 아래 세 가지다.

실제로 가장 유명한 DBMS 중 하나인 Oracle도 B-Tree를 주로 이용한다.

1. 트리 내 모든 데이터가 항상 정렬된 상태로 유지되기 때문에,

등호(=) 연산뿐만 아니라 부등호(>, <) 연산 처리도 가능하다.

2. 포인터 접근 방식이 적어 매우 많은 데이터가 있어도 속도 이슈가 적다.

3. 데이터 탐색뿐 아니라, 삽입 및 수정 및 삭제에도 항상 O(log N)의 시간 복잡도를 가진다.

(TMI) 그 외 인덱스 자료구조

아래 내용들은 일전에 들은 DB 인덱스 교육 내용 중 일부이며, 그냥 넘어가도 무방하다.

Bitmap

말 그대로, 데이터 뭉치를 비트 열(Bit Array) 형태로 저장하여

이러한 Bitmap에 Bit 연산을 수행하고 DB 인덱스 Value에 대한 RowID를 저장한다.

일반적인 인덱스 자료구조인 B-Tree보다 적은 공간을 차지하며,

B-Tree와 같은 인덱스들은 컬럼의 Cardinality가 높은 경우, 즉, 인덱스하는 값이 반복되지 않는 경우 가장 효율적이라면,

Bitmap 인덱스의 경우, 컬럼의 Cardinality가 "매우" 낮은 경우에 적합하다.

(ex. 고객 DB에서 성별 항목은 보통 남녀 2개의 분명한 값만을 포함)

하지만 DML 작업 시, 성능 저하를 유발하기 때문에 주의가 필요하다.

(데이터 로딩 전 삭제나 작업 완료 후 재생성 동의 방법 등이 필요)

RBO에서는 불가하다.

Function-Based

함수(Function)나 수식(Expression)으로 계산된 결과에 대해 인덱스를 생성하며, 인덱스 형태로 존재하는,

미리 계산되어 있는 결과로 처리한다.

함수나 수식 사용이 반드시 필요하며, 성능 향상을 위해 인덱스가 필요한 경우 적합하다.

하지만 Aggregate Function(SUM, AVG 등)에 대해 적용이 불가하며, RBO에서도 사용이 불가하다.

이 글을 읽으며 B-Tree에 대해 궁금해졌다면,

아래 사이트를 통해 직접 B-Tree를 만들어 볼 수 있다.

(https://www.cs.usfca.edu/~galles/visualization/BTree.html)

그리고 B-Tree에 대해 공부하다 보면 필연적으로 B+-Tree에 대해서도 알게 되는데,

실제로 DB 인덱스로 B+-Tree를 많이 쓴다고도 한다.

역시 아래 사이트를 통해 직접 B+-Tree를 만들어 볼 수 있다.

(https://www.cs.usfca.edu/~galles/visualization/BPlusTree.html)

다음 글은 DB 인덱스 스캔 방식에 대해 알아본다.

끝!

[DB] DCL, DDL, DML이란?

대흉근 — Wed, 2 Jun 2021 15:11:09 +0900

가끔 DB 배포 프로세스를 진행하다 보면

이 배포가 DCL인지 DDL인지 DMl인지

알아야 할 때가 있다.

아직 완벽하게 숙지를 못해서

정확하게 알아둘 겸 글로 남겨둔다.

DCL(Data Control Language, 데이터 제어어)

Control이라는 단어 뜻에 맞게

데이터를 제어하는 언어다.

데이터의 보안 / 무결성 / 회복 / 병행 수행 제어 등을

정의하는데 사용한다.

종류는 아래 네 가지가 있다.

GRANT

특정 DB 사용자에게 특정 작업에 대한 수행 권한 부여

REVOKE

특정 DB 사용자에게 특정 작업데 대한 수행 권한 박탈 및 회수

COMMIT

트랜잭션 작업을 데이터에 적용

ROLLBACK

트랜잭션의 작업 취소 및 원래 데이터로 복구

DDL(Data Definition Language, 데이터 정의어)

SCHEMA, DOMAIN, TABLE, VIEW, INDEX를

생성 / 수정 / 삭제할 때 사용하는 언어이다.

즉, DB를 정의하는 언어이기 때문에

DBA(데이터베이스 관리자)나 DB 설계자가 사용한다.

종류는 아래 네 가지가 있다.

CREATE

데이터베이스, 테이블 등을 생성

ALTER

테이블 수정

DROP

데이터베이스, 테이블 등을 삭제

TRUNCATE

테이블 초기화

DML(Data Manipulation Language, 데이터 조작어)

DB에 데이터를 조회 / 삽입 / 수정 / 삭제 등의

역할을 하는 언어이며,

DB 사용자가 어플리케이션이나 쿼리를 통해

저장된 데이터를 실질적으로 처리하는데 사용된다.

DB 사용자와 DBMS(데이터베이스 관리 시스템) 간의

인터페이스를 제공하며,

흔히 DB를 다룰 때 많이 사용하게 될 언어다.

종류는 아래 네 가지가 있다.

SELECT

데이터 조회

INSERT

데이터 삽입

UPDATE

데이터 수정

DELETE

데이터 삭제

어플리케이션이나 시스템을 처음부터 개발하는 것이 아니면

보통 DML만 사용하게 될 가능성이 높다.

DML에 대해 우선적으로 잘 알아두자.

끝!

[DB] 인덱스란? - (1) 개념, 장단점, 쓰는 이유

대흉근 — Mon, 31 May 2021 23:18:29 +0900

Index(이하 인덱스)는 DB를 다루다 보면 필연적으로 듣는 단어이다.

본격적으로 글에 들어가기 전에 인덱스에 대해 간단하게 설명하자면,

DB 데이터 조회 성능 향상을 위해 사용한다.

대용량 데이터를 담고 있는 DB 테이블에서 우리에게 필요한 데이터를 빨리 찾으려면

이 '인덱스'라는 녀석의 도움이 필요하다.

인덱스가 아예 없거나 적절한 인덱스를 찾지 못하면,

어마무시한 데이터가 담겨있는 테이블 전체를 읽어야 하기 때문에 데이터 조회 시간이 오래 걸릴 것이다.

이 인덱스에 대해 앞으로의 글들을 통해 보다 자세히 알아보자.

본 글들은 아래 글들의 내용을 토대로 작성했다.

DB 성능과 관련된 사항들

인덱스에 대해 알아보기 전,

데이터베이스의 성능과 관련된 사항에는 크게 네 가지 정도가 존재하는데,

애플리케이션의 응답 시간 단축과 성능 향상 방법 중 하나인 DB 데이터 조회 속도를 빠르게 하려면,

아래 네 가지의 데이터베이스 Activity가 적게 발생하도록 쿼리를 작성해야 한다.

(1) 프로세서

컴파일(실행계획 생성),

연산(SORT, JOIN, DATA, CONVERSION),

LOCK 관리 등이 존재한다.

(2) LOCK

Row, Table, Library cache LOCK 등이 존재한다.

(3) Network I/O

Application Server와 DB Server들 간의 요청,

혹은 결과 데이터 전송을 뜻한다.

이러한 데이터 전송 간의 네트워크 시간이 꽤 오래 걸리기 때문에 해당 시간을 최소한으로 해야 하는데,

해결책은 원하는 데이터를 한방에 가져오는,

이른바 "한방 쿼리"를 짜는 것이다.

(4) 데이터 I/O

말 그대로 데이터를 입력되고(Input) 나가는 것(Out)인데,

DB 인덱스 개념이 여기에 속한다.

개념

인덱스란, DB 내 저장된 데이터의 "주소"를 갖고 있는 것이다.

출처)https://mangkyu.tistory.com/96

인덱스는 위 그림처럼 테이블 내의 1개의 컬럼, 혹은 여러 개의 컬럼을 Key로 삼고,

Key에 해당하는 OID(레코드의 물리적 주소 값)가 저장되어 있다.

테이블의 다른 세부 항목들은 갖고 있지 않기 때문에,

보통의 테이블을 저장하는 데 필요한 디스크 공간보다 작은 디스크 공간을 필요로 한다.

즉, 책으로 비교하자면 일종의 "색인" 페이지로,

SQL 명령문의 처리 속도를 향상하기 위해 생성하는 객체이다.

흔히들 책의 "목차"나 뒤에 있는 "찾아보기"를 예시로 많이 드는데,

나무위키의 목차에 대한 설명을 읽어보면 아래처럼 작성되어 있는 문장을 볼 수 있다.

"비슷한 개념인 색인(인덱스)과 가끔 혼동하는 사람이 있는데, 이 둘은 분명히 다른 개념이다.

목차는 책 앞에서 '이 책 내용은 뭐다' 하고 순서대로 보여주는 것이고,

색인은 책 뒤에서 '그 내용을 알고 싶으면 몇 페이지로 가라'라고 지름길을 안내해주는 것으로,

흔히 '찾아보기'라고 되어 있는 부분이 바로 색인이다."

그래서 "목차"보다는 "색인"이 더 맞는 비유다.

장점

인덱스를 사용하는 이유이자 장점은 크게 보자면 딱 하나뿐이다.

방금 인덱스의 개념을 "DB 데이터의 주소를 갖고 있는 것"이라고 했다.

그렇다면 장점은 당연하게도, 원하는 데이터를 빠르게 찾을 수 있다는 것이다.

그럼으로 인해 전반적인 시스템의 부하를 줄일 수 있기도 하지만, 데이터 조회가 빠르다는 것이 핵심이다.

'어? 이것밖에 장점이 없는데 왜 쓰지?' 생각이 든다.

그 이유는, 글 하단부의 '그럼에도 불구하고' 파트를 참고하자.

단점

하나였던 장점에 비해, 단점은 크게 세 가지다.

(1) 타 성능 악영향

인덱스는 데이터 조회(SELECT)를 제외한 모든 동작,

즉, INSERT / UPDATE / DELETE 성능에 영향을 미친다.

위 세 가지 동작은 데이터를 삽입하고 수정하고 삭제하는데,

그러한 행위들로 인해 인덱스를 걸어둔 컬럼의 데이터가 바뀌면 인덱스 테이블의 수정도 필요하기 때문에,

데이터의 삽입 / 수정 / 삭제 작업의 두 번 이루어지게 되는 것이다.

(2) 추가 저장 공간 필요

DB에 저장된 데이터의 주소를 인덱스의 Key 값으로 가지려면 별도의 공간에 저장하므로 추가 저장 공간이 필요하다.

때문에 인덱스를 사용하는 시스템을 설계할 때,

인덱스 영역을 전체 테이블 영역의 30 ~ 50%까지 잡아 놓을 만큼 저장 공간이 꽤나 많이 필요하다.

(3) 공수 필요

공수란, "장인 공"에 "셀 수"를 사용하는 단어로,

일정한 작업에 필요한 인원수를 노동 시간이나 노동 일로 나타내는 수치이다.

인덱스를 생성하고 주기적으로 관리할 공수, 즉, 인력과 시간이 들어간다.

그럼에도 불구하고

RDBMS(관계형 데이터베이스 관리 시스템)에서 인덱스는 필수다.

일반적인 OLTP(OnLine Transaction Processing, 온라인 트랜잭션 처리, 설명글 링크) 시스템에서

데이터 조회 업무가 90% 이상이기 때문이다.

그러한 조회 업무의 검색 속도 향상은 시스템 부하를 감소시켜, 같은 시간 내에 더 많은 업무 처리가 가능해진다.

그렇기 때문에 위의 단점에서 알 수 있듯,

(1) 규모가 작지 않은 테이블에서

(2) INSERT / UPDATE / DELETE가 자주 발생하지 않는 컬럼,

(3) 혹은 JOIN / WHERE / ORDER BY에 자주 사용되는 컬럼,

(4) 혹은 데이터의 중복도가 낮은 컬럼 등에

인덱스를 사용하면 좋다.

웹 애플리케이션의 백엔드 성능을 높이려고 종종 실행하는 SQL 튜닝이란,

SQL이 위에서 알아본 인덱스를 활용하도록 SQL을 수정하는 것이라고 할 수 있다.

그러니 인덱스를 잘 이해하고 있다면 더 좋은 SQL을 작성할 수 있을 것이고,

훨씬 더 성능 좋은 애플리케이션을 만들 수 있다.

다음으로는 인덱스의 구조에 대해 깊게 알아본다.

끝!

[Java] Java의 Garbage Collection - Generational GC, G1 GC

대흉근 — Mon, 10 May 2021 22:12:53 +0900

이 글을 작성하기 위해 지난 한 달 동안 Garbage Collection(이하 GC)에 대해 자세히 공부해보았다.

이번 글에서는 Java에서 사용하는 Generational GC에 대해 알아보며,

Naver D2 블로그의 Java Garbage Collection 글과 Java HotSpot VM G1GC 글을 토대로 작성했다.

계속해서 글을 읽기 전에 아래 네 글을 읽고 오는 것이 좋다.

복습

위의 네 개의 글을 읽기 귀찮을 수도 있으니 간단하게 GC에 대해 알아보자.

프로그램이 실행되다 보면, 더 이상 사용되지 않는 쓰레기 객체가 발생한다.

Java는 그러한 쓰레기 객체를 C 언어처럼 개발자가 직접 찾아 해제하지 않고 가비지 컬렉터(GC)가 찾아 지운다.

참고) 해당 객체를 NULL로 지정하거나, System.gc() 메서드를 호출하면 명시적으로 지울 수 있으나,

후자의 방법은 시스템의 성능에 매우 큰 악영향을 끼치므로 절대 사용하면 안 된다고 한다.

하지만 어떤 GC 알고리즘을 사용하더라도,

GC를 실행하기 위해 JVM이 애플리케이션 실행을 멈추는 'stop-the-world'는 항상 발생하게 된다.

그렇기 때문에 'GC 튜닝을 한다' 라고 하면, 대부분 이 'stop-the-world' 시간을 줄이는 것이다.

Weak Generational Hypothesis

Java의 GC는 'Weak Generational Hypothesis'라는 다음 두 가지 가설(가정 혹은 전제 조건) 하에 만들어졌다.

- 대부분의 객체는 금방 접근 불가능 상태(unreachable)가 된다.

- 오래된 객체에서 젊은 객체로의 참조는 아주 적게 존재한다.

이 가설의 장점을 최대한 살리기 위해,

Oracle에 의해 유지 보수및 배포가 이루어지고 있으며 가장 일반적으로 사용하는 JVM인 'HotSpot JVM'에서는

JVM의 Runtime Data Area에 있는 Heap Area를 Young 영역과 Old 영역, 크게 2개로 나누었다.

(JVM 구성요소에 관해서는 [Java] JVM이란? - (3) 구성 요소 글 참고)

(번외로, Weak과 반대 개념인 'Strong Generational Hypothesis'도 있을지 궁금하여 찾아보니

이곳의 15 페이지에서 해답을 찾을 수 있었다)

Young 영역 & Old 영역 (+ Permanent 영역)

출처) https://d2.naver.com/helloworld/1329

Young (Generation) 영역에는 새롭게 생성된 객체의 대부분이 위치하게 된다(Allocation).

위에서도 말했듯이 대부분의 객체가 금방 접근 불가능(쓰레기) 상태가 된다고 가정했기 때문에,

매우 많은 객체가 이 영역에 생성되었다가 사라진다.

Young 영역에서 객체가 사라질 때, 'Minor GC'가 발생했다고 한다.

Old (Generation) 영역에는 Young 영역에서 쓰레기 상태가 되지 않고 살아남은 객체가 복사된다(Promotion).

보통 Young 영역보가 크게 할당하며,

크기가 큰 만큼 Young 영역에서 발생하는 GC의 횟수보다 적게 발생한다.

Old 영역에서 객체가 사라질 때, 'Major GC(혹은 Full GC)'가 발생했다고 한다.

Permanent (Generation) 영역은 객체나 억류(intern)된 문자열 정보를 저장하는 곳이며,

Method Area 라고도 한다.

뭔가 Permanent라는 단어의 뜻을 생각해보면 Old 영역에서 살아남은 객체가 영원히 남아있는 곳 같은데,

절대 그렇지 않다.

Permanent 영역 역시 GC가 발생 가능하며 GC 발생 시, Major GC 횟수에 포함된다.

If.. 오래된 객체 -> 젊은 객체 참조가 존재한다면?

Weak Generational Hypothesis의 두 번째 가설에서

'오래된 객체에서 젊은 객체로의 참조는 아주 적게 존재한다' 라고 하였는데,

만약 참조하는 경우가 존재하는 경우엔 어떻게 처리될까?

출처) https://d2.naver.com/helloworld/1329

이러한 경우를 위해 Old 영역에는 위와 같은 512 Byte의 카드 테이블(card table)이 존재하는데,

Old 영역의 객체가 Young 영역의 객체를 참조할 때마다 이 카드 테이블에 표시가 된다.

따라서 Minor GC(Young 영역에서의 GC)를 실행할 때,

Old 영역에 있는 모든 객체의 참조를 확인하지 않고,

이 카드 테이블만 뒤져서 GC 대상인지 식별한다.

이러한 카드 테이블은 write barrier를 사용하여 관리한다.

(write barrier란 애플리케이션에서 참조를 대입하거나 rewrite 할 때 해당 참조를 별도로 기록하는 처리이며,

Minor GC를 빠르게 할 수 있도록 하는 장치)

그래서 write barrier 때문에 약간의 오버헤드는 발생하지만, 전반적인 GC 시간은 줄어들게 된다.

Minor GC와 Young 영역의 구성

객체가 가장 먼저 생성되고 대부분 소멸되는 Young 영역에 대해 자세히 알아보자.

Young 영역은 아래 3개의 영역으로 나누어진다.

(1) Eden 영역

(2) Survivor 영역

(3) Survivor 영역

'(2)와 (3)이 같은데 오타인가?' 라고 생각했다면, 아니다.

Survivor 영역은 2개로 이루어져 있다.

아래 그림을 보며 Young 영역에서 발생하는 Minor GC를 통해 각 영역의 처리 절차를 순서에 따라 알아보자.

출처) https://d2.naver.com/helloworld/1329

(a) 새로 생성된 대부분의 객체는 Eden 영역에 위치한다.

(b) Eden 영역에서 GC가 한 번 발생하고 살아남은 객체는 Survivor 영역 중 하나로 이동된다.

(c) 이후에 Eden 영역에서 또다시 GC가 발생할 때마다 이전의 GC에서 살아남은 객체가 이동된 Survivor 영역으로 객체가 계속 쌓인다.

(d) Eden 영역의 GC에서 살아남은 객체들이 계속 쌓이는 Survivor 영역이 가득 차게 되면 Minor GC를 실행하고,

그 중에서 살아남은 객체를 다른 Survivor 영역으로 이동시킨 후, 가득 찼던 Survivor 영역은 몽땅 비운다.

(e) (a)~(d) 과정을 반복하다가 계속해서 살아남아 있는 객체는 Old 영역으로 이동하게 된다.

위와 같은 절차를 통해 알 수 있는 것은,

Survivor 영역 중 하나는 '반드시 비어 있는 상태'로 남아 있어야 한다는 것이다.

만약 두 Survivor 영역에 모두 데이터가 존재하거나,

두 영역의 사용량이 모두 0이라면 시스템이 정상적인 상황이 아니라는 뜻이 된다.

이러한 내용은 이전에 알아보았던

[Garbage Collection] (4) GC 알고리즘 - Tracing Garbage Collection(추적 기반) : Copying Algorithm, Generational Algorithm

의 Copying Algorithm의 내용과 굉장히 유사하며,

위 글에서도 언급한 것처럼,

Generational GC의 알고리즘이 Copying Algorithm을 기반으로 했다는 것을 알 수 있다.

참고로, HotSpot VM에서는 보다 빠른 메모리 할당을 위해

'bump-the-pointer'라는 기술과 'TLABs(Thread-Local Allocation Buffers)라는 기술을 사용하는데,

이것까지 기술하면 글이 너무 길어질 것 같아 글 가장 상단부에 링크 걸어놓은 Naver D2 블로그의 글을 참고하면 된다.

Major GC의 방식

Old 영역은 데이터가 가득 차면 GC를 실행하는 단순한 방식이다.

GC 방식에 따라 처리 절차가 달라지는데 JDK 7을 기준으로 아래 5가지 방식이 존재하며,

각 GC 방식 이름 옆 괄호 안의 내용은 해당 GC 방식을 수동으로 활성화하는 옵션이다.

1. Serial GC (-XX:+UserSerialGC)

Minor GC는 앞서 'Minor GC와 Young 영역의 구성' 파트에서 설명했던 방식을 사용하고,

Major GC는 우리가 이전의 글에서 알아보았던 Mark-Sweep-Compact Algorithm을 사용한다.

위 링크 글을 참고하면 되지만 Mark-Sweep-Compact Algorithm에 대해 간단하게 설명하자면,

먼저 Old 영역에서 살아있는 객체를 식별(Mark)하고

Heap(힙) 영역의 앞 부분부터 확인하여 살아 있는 객체만 남긴다(Sweep).

그 후, 각 객체들이 연속되게 쌓이도록 힙의 가장 앞 부분부터 채워서

객체가 존재하는 부분과 객체가 없는 부분으로 나눈다(Compact).

이러한 Serial GC는 적은 메모리와 CPU 코어 개수가 적을 때 적합한 방식이라 애플리케이션의 성능이 많이 떨어지기 때문에,

최근의 운영 서버에서는 절대 사용하면 안 되는 방식이다.

2. Parallel GC (-XX:+UseParallelGC)

Throughput GC라고도 불리는 Parallel GC는 Serial GC와 기본적인 알고리즘은 같지만,

GC를 처리하는 쓰레드가 하나였던 Serial GC와는 다르게 Parallel GC는 GC를 처리하는 쓰레드가 여러 개이다.

그렇기 때문에 Serial GC보다 빠르게 객체 처리가 가능하고,

메모리가 충분하고 코어의 개수가 많을 때 유리하다.

아래 그림을 통해 Serial GC와 Parallel GC의 쓰레드를 한 눈에 비교 가능하다.

출처) https://d2.naver.com/helloworld/1329

3. Parallel Old GC (-XX:+UseParallelOldGC)

방금 전 알아본 Parallel GC와 비교하여 Old 영역의 GC 알고리즘만 다른데,

Mark-Sweep-Compact Algorithm이 아닌

Mark-Summary-Compact Algorithm을 사용한다.

Summary 단계는 Sweep 단계와 다르게 앞서 GC를 수행한 영역에 대해

별도로 살아 있는 객체를 식별하는 등의 약간 더 복잡한 단계를 거친다.

4. CMS(Concurrent Mark-Sweep) GC (-XX:+UseConcMarkSweepGC)

Low Latency GC라고도 불리는 CMS GC는 지금까지 알아본 GC 방식 중 가장 복잡한 방식인데,

아래 그림을 보며 Serial GC와 비교해보자.

출처) https://www.oracle.com/java/technologies/

Serial GC는 'stop-the-world' 때 Mark, Sweep, Compact 모든 단계를 수행하기 때문에

애플리케이션이 멈추는 시간이 굉장히 길다.

하지만 CMS GC는 최초 Initial Mark 단계에서

Class Loader에서 가장 가까운 객체 중 살아 있는 객체만 찾고 끝내기 때문에 'stop-the-world' 시간이 매우 짧다.

그 후, Concurrent Mark 단계에서는 Initial Mark 단계에서 살아있다고 확인된 객체들이 참조하는 객체들을 따라가며 확인하는데,

다른 쓰레드가 실행 중인 상태에서 동시에 진행된다는 특징이 있다.

그 다음, Remark 단계에서는 Concurrent Mark 단계에서 새로 추가되거나 참조가 끊긴 객체를 확인하며

'stop-the-world'가 짧게 발생하고,

마지막으로 Concurrent Sweep 단계에서는 쓰레기 객체를 정리하는 작업을 실행하는데,

Concurrent Mark 단계와 마찬가지로 다른 쓰레드가 실행되고 있는 상황에서 진행된다는 특징이 있다.

위와 같은 방식을 통해 'stop-the-world' 시간이 매우 짧음을 알 수 있고,

이러한 특성 때문에 Low Latency GC라고도 불리며,

모든 애플리케이션의 응답 속도가 매우 중요할 때 CMS GC를 사용한다.

하지만 'stop-the-world' 시간이 짧다는 장점과 함께 아래 두 가지의 단점도 존재한다.

(1) 다른 GC 방식보다 메모리와 CPU를 더 많이 사용한다.

(2) Compact 단계가 기본적으로 제공되지 않는다.

따라서 CMS GC를 사용할 때에는 신중하게 검토 후 사용해야 하며,

(2)의 단점 때문에 조각난 메모리가 많아 Compact 작업을 실행하면,

다른 GC 방식의 'stop-the-world' 시간보다 더 길어지기 때문에 Compact 작업이 얼마나 자주, 오랫동안 수행되는지 확인해야 한다.

5. G1(Garbage First) GC (-XX:+UserG1GC)

G1 GC는 Garbage First(1)라는 이름답게 쓰레기로 가득찬 Heap 영역을 집중적으로 수집하며,

Java 9부터 Default GC이다.

통계를 계산해가며 GC 작업량을 조절하고,

큰 메모리를 가진 Multi-Processor 시스템에서 사용하기 위해 개발된 GC이다.

'stop-the-world' 시간을 최소화하면서(Real-time, 즉 실시간 GC는 아니다),

따로 설정을 하지 않아도 Throughput(처리량)도 확보하는 것이 G1 GC의 목표이다.

'Java Heap의 50% 이상이 살아있는 객체인 경우',

'시간이 흐르며 Allocation 비율과 Promotion 비율이 크게 달라지는 경우',

'GC가 너무 오래 걸리는 경우(0.5~1초)' 등의 상황에서 G1 GC를 쓰면 도움이 된다고 한다.

이 방식을 이해하려면 지금까지 알아본 Young / Old 영역에 대해서는 잊어야 하며,

기본적으로 아래 네 가지 개념을 숙지해야 한다.

- 비어 있는 영역에만 새로운 객체가 할당된다.

- 쓰레기가 쌓여 꽉 찬 영역을 우선적으로 비운다.

- 꽉 찬 영역에서 살아있는 객체를 다른 영역으로 옮기고, 꽉 찬 영역은 비운다.

- 위와 같은 과정이 Compact(조각 모음)의 역할도 한다.

아래 그림을 통해 G1 GC의 작동 방식에 대해 자세히 알아보자.

출처) https://johngrib.github.io/wiki/java-g1gc/

위 그림은 아래 다섯 가지를 뜻한다.

- 빨간색 영역은 Young 영역의 Eden 영역처럼 쓰이고 있는 영역이다.

- 빨간색 S는 Young 영역의 Survivor 영역처럼 쓰이고 있는 영역이다.

- 빨간색 영역이 꽉 차면 살아있는 객체를 빨간색 S로 옮기고 빨간색 영역을 비운다.

- 파란색 영역은 Old 영역처럼 쓰이고 있는 영역이다.

- 파란색 H는 하나의 영역보다 크기가 커서 여러 영역을 차지하고 있는 커다란 객체(Humongous Object)이다.

위처럼 전체 Heap 영역을 바둑판 모양처럼 여러 영역(region)으로 나누어 관리하기 때문에,

그러한 영역들의 참조를 관리하기 위해 전체 Heap 영역의 5% 미만의 크기를

'Remember Set'이라는 것으로 만들어 사용한다.

일단 작동 방식을 러프하게 설명하자면,

한 영역에 객체를 할당하고 GC를 실행하다가,

해당 영역이 꽉 차면 다른 영역에 객체를 할당하고

GC를 실행한다.

즉, 지금까지 우리가 알아보았던

Young의 세 가지 영역(Eden 1개, Survivor 2개)에서 Old 영역으로 데이터가 이동하는 단계가 사라진 것이다.

좀 더 자세하게 작동 방식에 대해 알아보자.

아래 두 Phase를 번갈아 가며 수행하는데, 그 아래의 그림과 함께 살펴 보자.

- Young-only Phase : Old 객체를 새로운 공간으로 옮긴다.

- Space Reclamation Phase : 공간 회수

출처) https://johngrib.github.io/wiki/java-g1gc/

(1) Young-only Phase : Old 객체의 점유율이 threshold(임계) 값을 넘어서면 전환된다.

(2) Concurrent Start : 살아있는 객체들에 Mark(마킹) 작업을 한다.

(3) Remark : Mark(마킹)를 끝내고, 쓰레기 객체들을 해지한다.

(4) Cleanup : Space Reclamation Phase로 들어갈지 말지 판단한다.

(5) Space Reclamation Phase : Young, Old 객체 가리지 않고 살아있는 객체는 적절한 곳으로 대피시킨다(Evacuation).

작업 효율이 떨어지게 되면 이 단계는 끝나고, 다시 Young-only Phase로 전환된다.

(*) 만약 애플리케이션 메모리가 부족한 경우, 다른 GC들처럼 Full GC를 수행한다.

이러한 방식은 말도 많고 탈도 많은 CMS GC를 대체하기 위해 만들어졌으며,

그런 의도에 맞게 성능이 가장 큰 장점이기 때문에 지금까지 알아본 어떤 GC 방식보다도 빠르다.

이 글에서는 GC에 대한 개념적인 부분만 다루려고 했기 때문에,

G1 GC에 좀 더 깊게 알아보려면 글 가장 상단부에서 언급한 블로그의 글을 들어가보자.

추가적으로, GC 튜닝을 할 때에는 서비스마다 WAS에서 생성하는 객체의 크기와 생존 주기가 모두 다르고

장비의 종류도 다양하기 때문에,

WAS의 쓰레드 개수, 장비당 WAS 인스턴스 개수, GC 옵션 등은

지속적인 튜닝과 모니터링을 통해 본인의 서비스에 가장 적합한 값을 찾아야 한다고 한다.

누가 그런 소리를 하냐고?

2010년 개최된 JavaOne 컨퍼런스에 참여한 Oracle JVM을 만드는 천재 엔지니어들이..

끝!

[Algorithm][Garbage Collection] (4) GC 알고리즘 - Tracing Garbage Collection(추적 기반) : Copying Algorithm, Generational Algorithm

대흉근 — Sun, 2 May 2021 15:20:54 +0900

지난 3편에 이어,

Garbage Collection(이하 GC, 가비지 컬렉션)의 알고리즘 중

Tracing GC(추적 기반)에 대해 계속 알아본다.

다시 말하지만 Tracing GC에서는

아래 알고리즘들에 대해 작성할 예정이며,

지금까지 세 개의 알고리즘에 대해 알아보았다.

~~- Mark-Sweep Algorithm~~

- Mark-Sweep-Compact Algorithm

- Tri-color Marking Algorithm (Incremental GC)

- Copying Algorithm (Incremental GC)

- Generational Algorithm (Incremental GC)

이번 글에서는 앞서 살펴보았던

Mark-Sweep Algorithm의 문제인

Fragmentation(단편화) 이슈를 해결하기 위해 탄생한

Copying Algorithm에 대해 알아보고,

Copying Algorithm을 기반으로 발생되었으며

최근 많은 프로그래밍 언어에서 사용 중인

Generational Algorithm에 대해 알아본다.

Copying Algorithm

개념

Copying Algorithm 역시

단편화 문제를 해결하기 위해 제시된 방법이며,

이전에 살펴보았던 Mark-Sweep Algorithm처럼

Mark(마킹)를 하지 않고 아예 메모리를 옮겨버린다.

Cheney's Algorithm이 대표적인 Copying Algorithm인데,

Heap(힙) 영역을 Active(활동하는 공간)와 InActive(활동하지 않는 공간),

두 개의 같은 크기의 공간으로 나누어

Active 영역에만 객체를 할당하는 방식이다.

만약 Active 영역이 꽉 차게 되면,

Active 영역에서 GC를 수행하여 살아남은 객체를

InActive 영역으로 Copying(복사)하고,

Active와 InActive 영역을 서로 바꾼다.

출처) https://medium.com/@joongwon/jvm-garbage-collection-algorithms-3869b7b0aa6f

위의 그림으로 예를 들어 보자면,

두 개의 메모리를 A, B라고 했을 때

(1) 처음에는 모든 메모리를 A에 할당을 한다.

(2) 그러다가 A가 가득 차는 등으로 인해 GC가 실행되면

프로그램은 잠시 Suspend(일시중지) 상태가 되고,

A에서 살아남은 메모리를 모두 B로 복사한다.

이 과정이 끝나게 되면 B에는

A에서 접근 가능한 메모리들의 사본만이 있게 되고,

(3) A는 Garbage 객체들만 존재하므로 A 메모리를 비워버린다.

(4) 그다음 과정에서는 B에 메모리를 할당하다가

또다시 GC가 실행되면 A로 복사하고,

(1)부터 (4)까지의 과정을 반복하게 된다.

이처럼,

한 공간의 메모리를 조사하며

접근 가능한 메모리는 바로바로 다른 공간에 옮겨버리면

어디까지 조사했는지 알 수 있으므로

Incremental GC(점진적 GC)를 수행한다고 할 수 있다.

장점

Copying Algorithm의 가장 큰 장점은

메모리를 재배열할 수 있어서 단편화 문제가 해결된다는 것이다.

GC가 완료되면,

새로운 공간에 단편화 없이,

연속된 메모리 공간에 차곡차곡,

재배열이 되기에 캐시 효율이 높아진다.

이러한 장점 덕분에,

아래에서 알아볼 Generational(세대별) Algorithm이

Copying Algorithm을 기반으로 발전시킨 형태이며,

Copying Algorithm은 최근에도 비교적 많이 사용되는 방식이다.

또 다른 장점도 존재하는데,

처음부터 아예 메모리를 할당해두고 시작하기 때문에

Heap(힙) 영역의 메모리 할당을

Stack(스택)처럼 빠르게 할 수 있다는 것이다.

단점

하지만 처음부터 메모리를 잡아두고 시작하다 보니

메모리 공간을 많이 사용하게 되며,

실제로 사용하는 메모리 공간은

전체 Heap 영역의 절반 정도밖에

사용하지 못한다는 공간 활용의 비효율성이 존재한다.

뿐만 아니라 Copying(복사)이라는 작업의 오버헤드가 존재하며,

복사하는 과정에서 메모리의 주소가 바뀌므로

포인터를 이용한 접근을 포기하거나,

메모리의 주소가 바뀔 때마다

모든 메모리의 주소를 갱신해야 한다는 단점이 존재한다.

또한 프로그램의 Suspend(일시중지) 현상도 존재한다.

Generational Algorithm

개념

우리보다 월등히 똑똑한 개발자들이 객체의 라이프 사이클을 자세히 살펴보니,

한 가지 특이한 현상을 발견했다.

객체에 메모리를 할당 후,

해당 객체가 사용하지 않는 Garbage(쓰레기)가 될 때까지

걸리는 시간을 추적했을 때,

대부분의 객체는 잠깐 사용되고 금세 버려지며,

반대로 오래 살아남아 쓰이는 경우는

"그리 많지 않다"는 것이다.

이러한 현상을 토대로

아래 두 가지 가정(Weak Generational Hypothesis)을 전제 삼아

만들어진 방식이 바로 Generational Algorithm이다.

(1) 대부분의 할당된 객체는 오랫동안 참조되지 않는다.

(2) 오래된 객체에서 젊은 객체로의 참조는 거의 없다.

잠깐 사용되고 금세 버려지는 객체를

상대적으로 크기가 작은 "New(Young)" 영역에 할당하고,

New(Young) 영역에서 기준 시간 이상으로

오래 살아남은 객체가 있다면

"Old" 영역으로 이동시켜

말 그래도 "세대"를 구분하는 방법이다.

이 세대를 나누는 기준은 구현 방식마다 상당히 다른데,

Stack(스택) 영역을 New(Young) 영역으로 쓸 수도 있고,

Heap(힙) 영역에 임의로 할당해서 쓸 수도 있지만,

대부분의 경우 힙 영역을 사용하므로

이 글에서는 힙 영역을 기준으로 설명한다.

이 New(Young) 영역의 크기는 보통 해당 플랫폼이나

언어가 최소로 필요로 하는 메모리보다 조금 많게 잡는 편이며,

몇몇 구현의 경우에는 New(Young)와 Old 영역 2개가 아니라

임의의 개수만큼 나누는 경우도 있는데,

예를 들어, 맨 처음 할당된 Old를 0세대,

그다음을 1세대,... , 다음을 n세대처럼 사용한다.

출처) https://medium.com/@joongwon/jvm-garbage-collection-algorithms-3869b7b0aa6f

위의 그림을 보면,

객체는 Young(New) Generation에 할당되고

GC가 수행될 때마다 살아남은 객체에 Age를 기록한다.

Java 진영의 대표적인 JVM 구현인

아래 HotSpot JVM에서는

이 Age의 임계값의 기본값을 31로 세팅한다.

(객체 Header에 Age를 기록하는 부분이 6 Bits이고,

6 Bits로 표현할 수 있는 수치가 32이기 때문)

이 Age 역할은 해당 객체가 몇 번 살아남았는지 기록하는 것이며,

특정 임계값을 넘어서게 되면

Old Generation으로 Copy 하는 작업(Promotion)을 진행한다.

출처) https://medium.com/@joongwon/jvm-garbage-collection-algorithms-3869b7b0aa6f

HotSpot JVM에서는 구조가 좀 다른 것을 볼 수 있는데,

이와 관련해서는 따로 포스팅을 할 예정이다.

(글이 너무 길어져서;;)

장점

위에서 언급한 것처럼,

대부분의 객체는 Young(New) Generation에서 살다가 쓰레기가 되기 때문에

Young(New)에서 Old로의 Copying 작업을 최소화시킬 수 있고,

상대적으로 작은 영역만 추적하면

적은 시간과 비용으로 짧은 시간 안에

쓰레기 메모리를 확보할 수 있게 된다.

또한, Copying 작업이 이루어지며

Compaction 작업도 수행되기 때문에 단편화 문제도 해결될 수 있다.

그리고 Old 영역에서 쓰레기 메모리를 수집하는 Major-GC와

New 영역에서만 수집하는 Minor-GC로 나눠

GC를 수행할 수 있고,

위에서 알아본 Cheney's Algorithm을 접목하여

단편화를 줄일 수도 있는 등 여러 모로 이점이 많기에

Tracing GC(추적 기반 GC)를 사용하는

현재의 많은 언어들(Java, C#, Go 등)은 이 기법을 사용하고 있다.

긴 여정이었다..

하지만 Generational GC의 경우,

최근의 언어들이 많이 사용하는 GC이기 때문에

따로 포스팅을 작성하여 더 자세히 살펴볼 예정이다.

이번 글의 시리즈는 아래 글들을 참고하여 작성했다.

끝!

[Algorithm][LeetCode][Medium][Python] 55. Jump Game

대흉근 — Sat, 24 Apr 2021 21:02:23 +0900

문제는 여기서 볼 수 있다.

Dynamic Programming을 사용하도록 만든 문제인데,

Solution 작성을 정말 잘 해놨다.

이 글은 해당 Solution을 한글로 풀어 작성했으며,

Solution 페이지에는 Java 코드만 있기 때문에

참고하여 Python 코드를 작성했다.

문제

입력 값으로 음수가 아닌 정수로 구성된

nums 라는 배열이 들어온다.

문제에서 요구하는 것은,

배열의 가장 첫 번째 인덱스부터 시작하여

배열의 가장 끝 인덱스까지 도달할 수 있는지의

여부를 return 하면 된다.

얼마만큼의 인덱스를 이동하는 지에 대한 것은,

최대 현재 위치한 인덱스의 원소만큼

오른쪽으로 인덱스를 움직일 수 있다.

예를 들어, [2, 3, 1, 1, 4]라는 배열이 있을 때,

0번째 인덱스(2)에서 1번째 인덱스(3)으로 이동 후,

1번째 인덱스(3)에서 4번째 인덱스(4)로 이동하면

배열의 가장 끝 인덱스로 이동이 가능하다.

하지만 [3, 2, 1, 0, 4]의 경우,

0번째 인덱스(3)에서 1번째, 2번째, 3번째 등

어디로 이동하더라도

절대 배열의 마지막 인덱스에는 도달할 수 없다.

nums 배열의 길이는 최대 3 * 10^4이며

각 원소는 최대 10^5기 때문에

효율적인 알고리즘이 필요하다.

풀이 소개

아래에서 나올 풀이에서

"good index", "bad index"와 같은 단어가 자주 나올텐데,

"good index"는 배열의 마지막 인덱스에 도달할 수 있는 인덱스,

"bad index"는 배열의 마지막 인덱스에 도달할 수 없는 인덱스다.

즉, 배열의 첫번째 인덱스가 "good index"라면

결과적으로 True를 return 하면 될 것이다.

아래의 네 가지 풀이를 소개할 예정이며,

풀이 과정이 점점 진화되며 더 나은 퍼포먼스를 볼 수 있다.

(1) Backtracking - Using Recursion

말이 Backtracking이지, 거의 노가다 해결법이다.

배열의 첫번째 인덱스부터 시작하여

모든 경우의 수를 따져본다.

이해하기 어려운 코드는 아니기에 바로 아래의 코드를 소개한다.

실행해보면 테스트 케이스 중 하나에서 시간 초과가 발생하여

좋은 방법은 아니다.

class Solution:
    def canJumpFromPosition(self, position: int, nums: List[int]) -> bool:
        if position == len(nums) - 1:
            return True
        
        furthestJump = min(position + nums[position], len(nums) - 1)
        # Old Way
        #for nextPosition in range(position+1, furthestJump + 1):
        # New Way
        for nextPosition in range(furthestJump, position, -1):
            if self.canJumpFromPosition(nextPosition, nums):
                return True
        return False
        
    def canJump(self, nums: List[int]) -> bool:
        return self.canJumpFromPosition(0, nums)

입력 배열의 길이를 N이라 했을 때,

시간 복잡도는 O(2^N)이며,

증명 방법은 Solution 페이지의 Appendix A를 참고하면 된다.

공간 복잡도는

재귀 때문에 stack 메모리를 사용하게 되어 O(N)이다.

(2) Top-down Dynamic Programming - Using Memoization Table

보통 Top-down DP는

Backtracking 방법을 optimize한 방법이라 여겨진다.

Backtracking 방법의 코드를 잘 보면,

우리가 특정 인덱스를 good 혹은 bad index라고 결정 지었을 때

그 결과는 절대 바뀌지 않는다는 것을 알 수 있다.

만약 그러한 결과들을 어딘가에 저장해 둔다면,

재귀 혹은 반복문을 돌면서 다시 계산할 필요가 없이

저장해둔 곳에서 쇽 가져오기만 하면 된다.

그렇기 때문에 Top-down DP는

Memoization Table,

즉, 메모 테이블을 사용하는 방법으로 소개되기도 한다.

이와 같은 Memoization 방법을 적용하기 위해서

"memo"라는 배열을 하나 두고,

입력 배열의 각 인덱스가 good인지 bad인지

판단하여 저장한다.

이때 저장 방식은 아래의 세 가지 중 하나로 한다.

- GOOD

- BAD

- UNKNOWN

알고리즘은 아래와 같다.

(a) memo 배열을 모두 UNKNOWN으로 초기화 시킨다,

; 단 마지막 인덱스는 언제나 본인에게 도달 가능하기 때문에 GOOD으로 저장한다.

(b) Backtracking 방법의 첫 번째 단계를 수정한다

; 파라미터로 넘어온 position 인덱스에 해당하는 memo 배열의 값을 확인한다.

; 만약 GOOD이면 True를, 아니라면 False를 return 한다.

; 나머지 단계는 Backtracking 방법과 같다.

(c) 현재 인덱스의 good / bad 인덱스 여부를 결정했다면, memo 배열에 저장한다.

코드는 아래와 같으며,

이 방법 역시 긴 테스트 케이스에서 시간 초과가 발생한다.

class Solution:
    def canJumpFromPosition(self, position: int, nums: List[int], memo: List[str]) -> bool:
        if memo[position] != 'UNKNOWN':
            return True if memo[position] == 'GOOD' else False
        
        furthestJump = min(position + nums[position], len(nums) - 1)
        for nextPosition in range(position+1, furthestJump + 1):
            if self.canJumpFromPosition(nextPosition, nums, memo):
                memo[position] = 'GOOD'
                return True
        
        memo[position] = 'BAD'
        return False
        
    def canJump(self, nums: List[int]) -> bool:
        memo = ['UNKNOWN'] * len(nums)
        memo[-1] = 'GOOD'
        return self.canJumpFromPosition(0, nums, memo)

시간 복잡도는 O(N^2) 이다.

만약 nums 배열을 순회하며

i번째 인덱스의 nums[i]가 'GOOD'인 원소를 찾기 위해

오른쪽으로 이동한다고 하면,

nums[i]는 최대 N(nums 배열의 길이)이 될 수 있기 때문이다.

공간 복잡도는 O(2N) = O(N)이다.

재귀를 사용하며 N을 사용하고,

memo 배열을 사용하며 N을 사용하기 때문이다.

(3) Bottom-up Dynamic Programming - Remove Recursion

Top-down DP에서 Bottom-up DP로 변환하려면

재귀를 제거하면 된다.

재귀를 제거하게 되면,

method stack의 오버헤드도 사라지고

caching의 효과도 얻을 수 있어서

대체로 더 나은 퍼포먼스를 보여준다.

더 나아가, 다음에서 소개할 네 번째 방법을 적용하기 위해

혹은 다른 문제에서도 더 나은 방법을 적용하기 위해

이러한 Bottom-up 방식의 해결 방법이 필요하다.

그럼 어떻게 재귀를 제거할까?

보통 Top-down DP 단계를 거꾸로 해나가면

재귀를 제거할 수 있다.

이 문제의 경우에서는

배열의 첫번째 인덱스부터 시작하는 것이 아닌,

배열의 가장 끝 인덱스부터 시작하는 것이다.

아래 코드를 보면 좀 더 명확하게 이해가 가능하다.

class Solution:
    def canJump(self, nums: List[int]) -> bool:
        memo = ['UNKNOWN'] * len(nums)
        memo[-1] = 'GOOD'
        
        for position in range(len(nums) - 2, -1, -1):
            furthestJump = min(position + nums[position], len(nums) - 1)
            for nextPosition in range(position+1, furthestJump + 1):
                if memo[nextPosition] == 'GOOD':
                    memo[position] = 'GOOD'
                    break
        
        return memo[0] == 'GOOD'

하지만 아직까지도 타임 아웃이 발생한다.

여전히 (2)번 방법과 같은 이유로

시간 복잡도가 O(N^2)이기 때문이다.

공간 복잡도 역시,

(2)번 방법과 마찬가지의 이유로 O(N)이다.

(4) Greedy

대체 뭘 더 줄여야 할까?

Botttom-up DP 구현 코드를 다시 자세히 보자.

여전히 우리는 2중 for 문을 사용하고 있는 것을 볼 수 있는데,

안에 있는 for 문을 없앨 수 있다면

퍼포먼스가 굉장히 좋아질 것 같다.

안에 있는 for 문의 역할은

현재 위치한 index(position)의 다음 index(nextPosition)부터

조사를 시작하여 memo 배열의 nextPosition index 값이

'GOOD'인 것을 찾는다.

그럼 아예 'GOOD'인 index 값을

배열이 아닌, 단순 변수에 저장해두면

시간 뿐만 아니라 공간까지 줄일 수 있지 않을까?

그런 생각에서 탄생하는 코드가 바로 아래 코드이다.

class Solution:
    def canJump(self, nums: List[int]) -> bool:
        lastPos = len(nums) - 1
        for idx in range(len(nums)-1, -1, -1):
            if idx + nums[idx] >= lastPos:
                lastPos = idx
        return lastPos == 0

'GOOD'인 index를 저장할 lastPos라는 변수 선언 후,

입력 배열의 가장 끝 인덱스를 저장해둔다.

가장 끝 인덱스는 언제나 가장 끝 인덱스,

즉, 본인에게 도달할 수 있기 때문에

'GOOD' index기 때문이다.

그 후, 입력 배열의 가장 오른쪽부터 시작하여

현재 index(idx)부터 nums[idx]만큼 더한 값이

lastPos보다 크다면,

'GOOD' index인 lastPos에 충분히 도달할 수 있다는 뜻이므로

idx 역시 'GOOD' index가 되기 때문에

lastPos를 idx로 최신화 시켜준다.

이런 식으로 배열의 첫 번째 원소까지 진행하면

우리가 원하던,

입력 배열의 첫 번째 원소부터 시작하여

입력 배열의 가장 끝 원소까지 도달할 수 있는지에 대한

결과를 알 수 있다.

DP 문제들은 볼 때마다 뜬구름 잡는 소리 같기도 하지만,

이런 훌륭한 풀이가 있는 것을 보면

정말 감탄이 나온다.

끝!

[Algorithm][Garbage Collection] (3) GC 알고리즘 - Tracing Garbage Collection(추적 기반) : Mark-Sweep, Mark-Sweep-Compact, Tri-color Marking

대흉근 — Mon, 19 Apr 2021 15:52:03 +0900

지난 2편에 이어

Garbage Collection(이하 GC, 가비지 컬렉션)의 알고리즘 중

Tracing GC(추적 기반)에 대해 알아본다.

Tracing GC에서는

아래 알고리즘들에 대해 작성할 예정인데,

꽤나 많은 양이 예상되므로

두 편으로 글을 나눠 쓰려고 한다.

- Mark-Sweep Algorithm

- Mark-Sweep-Compact Algorithm

- Tri-color Marking Algorithm (Incremental GC)

- Copying Algorithm (Incremental GC)

- Generational Algorithm (Incremental GC)

이 글에서는 Reference Counting GC를 보완하며 만들어진

Tracing GC의 원조격 알고리즘이라 할 수 있는

Mark-Sweep에 대해 알아보고,

Mark-Sweep의 단점을 보완한

Mark-Sweep-Compact,

Incremental GC(점진적 GC)에 속하는

Tri-color Marking Algorithm에 대해 알아본다.

Tracing Garbage Collection

개념

가장 많이 사용되는 GC 기법으로,

대부분 경우 GC에 대해 누군가 물어본다면

이 방식일 가능성이 높다.

Tracing, 즉, "추적"이라는 단어의 뜻처럼

프로그램 실행 중 특정 타이밍에

현재 할당된 모든 메모리를 조사하여

그것이 현재 접근 가능한지 불가능한지 분류한 뒤,

접근이 불가능한 메모리를 "쓰레기"라고 간주하여 해제시키는 방식이다.

이 방식을 사용하면 2편에서 소개한

Reference Counting GC(참조 횟수 카운팅)의 단점인

오버헤드 이슈와 순환 참조 이슈를 어느 정도 해결 가능하다.

그럼 메모리 조사의 시작점이 있어야 할 텐데,

항상 접근 가능한 메모리를 root라고 한다.

이 root 메모리부터 검사를 시작해서

root 메모리가 참조하는 다른 메모리, 다른 메모리가 참조하는 또 다른 메모리 등

메모리가 참조하는 메모리를 확인하는 행위를 반복하여

접근 가능 or 불가능한 메모리를 분류한다.

이 root 메모리에 대해서는 Naver D2 블로그에서 작성한

Java Reference와 GC 글을 참고하면 좋다.

(root 메모리에 대해서 추후 글을 작성할 예정)

Mark-Sweep Algorithm

위에서 설명한 Tracing GC를 그대로 구현하는 방법 중

가장 단순한 방식으로,

Tracing GC의 원조격 되는 알고리즘이다.

알고리즘의 이름의 해석 그대로,

메모리 Mark(마킹) 후, Sweep(해제)하는 방식이다.

아래 그림과 함께 좀 더 자세히 풀어써보자면,

프로그램 실행 중 적당한 타이밍에 GC를 실행시켜

접근 가능한 메모리에는 Mark(마킹)를 하고

Mark(마킹)가 안 된 메모리는 전부 Sweep(해제) 한 후,

살아남은 객체의 Mark(마킹) 정보를 초기화한다.

(Marking 정보는 각 객체의 Header에 Flag나

별도의 BitmapTable 등을 사용하여 저장)

출처) https://medium.com/@joongwon/jvm-garbage-collection-algorithms-3869b7b0aa6f

이 방식대로 수행하면

접근이 가능한 혹은 불가능한 메모리를

완벽하게 분류해서 해제하는 것이 가능하다.

하지만 프로그램 실행 도중 메모리가 변경되면

마킹을 다시 해야 하기 때문에

프로그램을 통째로 정지('stop-the-world')시켜야 한다.

이 이유 때문에 Mark-Sweep 방식은

프로그램 실행 도중 잠깐 멈추는 시간이 생겨,

실시간으로 빠르게 동작해야 하는 프로그램에서는

뚝뚝 끊기는 큰 단점이 발생한다.

그래서 이 단점을 개선하기 위해

한 번에 처리하는 방식 대신,

조금씩 조금씩 수집을 하는 Incremental(점진적) GC 방식이나,

객체의 사용 시간을 계산하여 영역 별로 나누어 수집하는

Generational(세대별) GC 방식이 탄생하게 된다.

Mark-Sweep-Compact Algorithm

먼저 Incremental GC 방식을 알아보기 전에!

위의 Mark-Sweep 그림을 다시 보면,

Sweep 과정 후 메모리 상태가 중간중간 비워져 있는 이상한 상태를 볼 수 있다.

바로 GC가 수행되며 제거된 "쓰레기" 메모리들이 있던 곳이다.

이렇게 메모리가 조각난 상태를 Fragmentation(단편화)라고 하는데,

이 문제를 해결하기 위해 만들어진 알고리즘이다.

그럼 Fragmentation을 왜 해결해야 할까?

메모리의 빈 부분들을 합쳐보면

충분히 많은 빈 메모리가 있음에도 불구하고

새로운 객체를 할당할 수 없는 상황이 생기기 때문이다.

또한 새로운 객체를 할당하기 위해

메모리 상의 빈 공간을 뒤지는 과정 자체가 성능에 악영향을 미치기 때문에

결국 프로그램도 느려질 수 있다.

그래서 이름만 봐도 어느 정도 유추가 가능한

아래 그림처럼 Compact(압축) 단계가 하나 추가되었다.

출처) https://medium.com/@joongwon/jvm-garbage-collection-algorithms-3869b7b0aa6f

이 Compact 단계에서는

빈 공간들을 없애고, 사용되는 메모리들을 연속적으로 붙여준다.

하지만 이러한 Compact 단계 자체와

그 후에 메모리의 참조 관계를 다시 설정해주는 등의

부가적인 오버헤드가 또다시 발생한다.

Incremental GC

위와 같은 문제점을 해결하기 위해 나온 방식이

Incremental(점진적) GC다.

위의 방식들처럼 Mark(마킹)와 Sweep(해제)을

한 번에 하지 않고, 여러 번에 걸쳐서 수행하는 방식이다.

이 방법을 사용하면,

프로그램을 통째로 정지하는 것에 비해

마킹과 해제를 하는 한 cycle에 걸리는 시간은 더 오래 걸릴 수 있지만,

한번 GC를 수행할 때 프로그램이 정지하는 시간은 줄일 수 있다.

Mark-Sweep 방식에도

이러한 Incremental GC 방식을 어느 정도 적용이 가능하다.

Sweep 단계에서 접근이 불가능하다고 판단된 메모리는

절대 다시 접근 가능해질 수 없기 때문에,

해당 메모리의 해제는 언제 해도 상관없으므로

여러 번에 걸쳐서 수행해도 된다.

문제는 Mark 단계인데,

마킹을 점진적으로 하려면 Tri-color Marking(삼색 기법) 등의

방법을 추가로 사용해야 한다.

Tri-color Marking

Tri-color Marking(삼색 기법)은 말 그대로,

기존에는 접근 가능/불가능이라는 2가지의 색으로만 마킹을 했다면

아래 3가지의 색으로 마킹을 하는 것이다.

(1) 흰색 : 접근 가능한지 알 수 없는 메모리

(2) 회색 : 접근 가능하지만 해당 메모리에서 참조하는 메모리의 마킹을 하지 않은 경우

(3) 검은색 : 접근 가능하며 해당 메모리가 참조하는 메모리의 마킹도 끝난 경우

마킹하는 순서는 아래와 같다.

(a) root 메모리 조사

(b) 흰색인 메모리를 발견하면 회색으로 마킹

(d) 해당 메모리가 참조하는 모든 메모리를 회색으로 마킹

(e) (d) 작업이 끝나면 처음 회색이었던 메모리를 검은색으로 바꿈

위 작업들이 끝난 후,

만약 회색으로 마킹된 메모리가 존재하지 않으면

모두 흰색이나 검은색일 것이므로,

모든 메모리의 접근 가능 여부가 결정된다.

이런 방식을 이용하면 임의로 GC를 중단하여도

다음번에는 회색인 메모리부터 다시 조사하면 되므로

여러 번에 걸쳐 GC를 수행 가능하다.

하지만 아래의 예시처럼,

마킹을 하는 도중에 메모리 참조가 수정이 되면

잘못 마킹되는 일이 발생할 수 있다.

(가정) root가 A 메모리를,

A 메모리가 B 메모리를 참조하며,

A 메모리 외에는 B 메모리로 접근 가능한 메모리가 없고

흰색으로 마킹된 상태인 C 메모리가 존재한다고 하자.

(실행) GC를 수행하여 A, B 메모리가 검은색으로 마킹되고

GC가 정지했다고 가정하면,

이후 다시 실행될 GC에서 수행해야 할 해제 작업 전에

A 메모리가 B 메모리에 대한 참조를 제거하고

C 메모리를 참조하게 수정되었다고 하자.

(결과) 그러면 B 메모리는 이제 접근이 불가능하지만 검은색이고,

C 메모리는 접근 가능한데 흰색인 상태가 된다.

위와 같은 문제를 해결하기 위해

보통 read-barrier나 write-barrier를 사용하여

root 메모리에 읽거나 쓰는 것에 제약을 둔다.

대부분의 경우 write 행위보다 read 행위가

더 자주 일어나므로 write-barrier가 사용된다.

write-barrier에 대해 간단히 설명하자면,

애플리케이션에서 참조를 대입하거나 rewrite 할 때,

해당 참조를 별도로 기록하는 처리이다.

위의 예시를 다시 가져와보면,

A 메모리의 참조가 C 메모리가 되도록 write 된 것이므로

C 메모리의 마킹을 회색으로 바꾸면 된다.

그러면 B 메모리는 당장 해제되지는 않아도,

적어도 C 메모리가 해제되는 일은 없앨 수 있다.

다음 글에서는

Copying Algorithm과,

현재의 많은 프로그래밍 언어가 사용 중인

Generational GC에 대해 알아본다.

끝!

[Algorithm][LeetCode][Easy][Python] 53. Maximum Subarray

대흉근 — Sun, 18 Apr 2021 20:06:46 +0900

Easy 난이도라 만만하게 봤다가 혼났다.

딱 이런 부류의 문제를 위한 알고리즘이 있더라.

문제는 여기서 볼 수 있다.

문제

입력 값으로는 nums라는 배열이 들어오고,

배열 안에는 최소 하나의 정수가 존재한다.

배열 원소들 중 연속되는 subarray의 합이

최대가 되는 것을 찾아 return 해야 한다.

예를 들어,

입력값으로 [-2, 1, -3, 4, -1, 2, 1, -5, 4]가 들어오면

subarray 중 [4, -1, 2, 1]의 합이 6으로

합이 가장 크기 때문에 6을 return 하면 된다.

편의를 위해 배열의 길이는 N이라 가정한다.

해결 방법 - (1) Brute Force

누구나 쉽게 생각할 수 있는.

흔히 노가다라고 부르는 방법이다.

너무나 쉬운 방법이므로 따로 코드는 안 남긴다.

2중 for 문을 돌아야 하기 때문에

시간 복잡도는 O(N^2)다.

해결 방법 - (2) Dynamic Programming - Kadane's Algorithm

우선 Dynamic Programming(DP)와

DP 구현 방법 중 하나인 Kadane's Algorithm이

무엇인지 알아야 한다.

Dynamic Programming - Kadane's Algorithm (카데인 알고리즘)

위 블로그에서 그러한 설명을 아주 잘 해놨다.

Kadane's Algorithm

위 글을 참고하여

Kadane's Algorithm(카데인 알고리즘)이

무엇인지 알아보고,

어떻게 이 문제에 적용 가능한지 한 번에 알아보자.

카데인 알고리즘을 증명하기 위해

위에서 언급한 Brute Force 방법을

아래처럼 배열의 끝 부분부터 시작한다고 가정하자.

출처) https://sustainable-dev.tistory.com/23

A 배열의 5번째 인덱스에 위치한 2에 대해

subarray 합이 가장 큰 것을 알아보려면

위 그림 오른쪽처럼 찾아보면 된다.

그다음 순서인 4번째 인덱스에 위치한 -1에 대해

subarray 합이 가장 큰 것을 알아보려면

위 그림 왼쪽처럼 찾아보면 된다.

그런데 뭔가 중복되는 것을 볼 수 있다.

아래 그림을 보자.

출처) https://sustainable-dev.tistory.com/23

배열의 i번째 인덱스에 위치한 원소에 대해

subarray 합이 가장 큰 것을 알아보려면,

배열의 i-1번째 인덱스에 위치한 원소에 대해

구했던 subarray 합들을 이용하면 알 수 있다.

정확히는

max(A[i], LocalMaximum[i-1] + A [i])가

우리가 찾던 답이 될 것이다.

Python 코드

사실 이 문제는 LeetCode에서

Solution이 무료로 풀려있는 문제여서

해당 문제로 가면 볼 수 있다.

나처럼 그마저 귀찮은 사람을 위해

아래 코드를 남긴다.

class Solution:
    def maxSubArray(self, nums: List[int]) -> int:
        # Initialize our variables using the first element.
        current_subarray = max_subarray = nums[0]
        
        # Start with the 2nd element since we already used the first one.
        for num in nums[1:]:
            # If current_subarray is negative, throw it away. Otherwise, keep adding to it.
            current_subarray = max(num, current_subarray + num)
            max_subarray = max(max_subarray, current_subarray)
        
        return max_subarray

Brute Force와는 달리

배열을 딱 한 번만 순회하면 되므로

시간 복잡도는 O(N)이다.

해결 방법 - (3) Divide and Conquer

이 방법은 카데인 알고리즘보다

더 느리고 더 많은 공간을 차지한다.

하지만 한 문제를 여러 방법으로 풀어보는 것이

알고리즘 코딩 실력 향상에 중요하기 때문에

이 방법에 대해서도 알아본다.

Divide and Conquer

출처) https://leetcode.com/explore/learn/card/recursion-ii/470/divide-and-conquer/2897/

위 그림으로

Divide and Conquer(분할 정복)가 무엇인지

한눈에 파악 가능하다.

말 그대로,

어떠한 문제를 작은 문제들로 나누고

작은 문제마다 해결책을 찾아

각 작은 문제들의 결과를 합친다.

대표적인 알고리즘으로는

Merge Sort와 Quick Sort가 있다.

Python 코드

분할 정복 알고리즘을 이 문제에 적용하면

정답은 아래 세 가지 결괏값 중

가장 큰 것이 될 것이다.

** 배열의 가운데 원소 기준 **

(1) 왼편의 maximum subarray

(2) 오른편의 maximum subarray

(3) 왼편, 오른편을 합쳤을 때의 maximum subarray

(1)과 (2)는 배열의 가운데 원소를 포함하지 않고,

(3)은 배열의 가운데 원소를 무조건 포함해야 한다.

(1)과 (2)에서 maximum subarray를 찾을 때

위에서 알아본 카데인 알고리즘을 적용하면 되고,

(3)은 {(1) + (2) + 가운데 원소}로 구할 수 있다.

코드는 아래와 같다.

class Solution:
    def maxSubArray(self, nums: List[int]) -> int:
        def findBestSubarray(nums, left, right):
            # Base case - empty array.
            if left > right:
                return -math.inf

            mid = (left + right) // 2
            curr = best_left_sum = best_right_sum = 0

            # Iterate from the middle to the beginning.
            for i in range(mid - 1, left - 1, -1):
                curr += nums[i]
                best_left_sum = max(best_left_sum, curr)

            # Reset curr and iterate from the middle to the end.
            curr = 0
            for i in range(mid + 1, right + 1):
                curr += nums[i]
                best_right_sum = max(best_right_sum, curr)

            # The best_combined_sum uses the middle element and
            # the best possible sum from each half.
            best_combined_sum = nums[mid] + best_left_sum + best_right_sum

            # Find the best subarray possible from both halves.
            left_half = findBestSubarray(nums, left, mid - 1)
            right_half = findBestSubarray(nums, mid + 1, right)

            # The largest of the 3 is the answer for any given input array.
            return max(best_combined_sum, left_half, right_half)
        
        # Our helper function is designed to solve this problem for
        # any array - so just call it using the entire input!
        return findBestSubarray(nums, 0, len(nums) - 1)

시간 복잡도는

배열을 한 번 돌고,

반으로 나눈 배열들도 돌아야 하기 때문에

O(N * logN)이며,

공간 복잡도는

재귀 함수를 (log N) 번 돌아야 하기 때문에

스택에 그만큼 쌓여서

O(logN)이 된다.

끝!

[ETC][일상][배포] QA 테스트 및 운영 배포 실수에 대한 고찰

대흉근 — Fri, 16 Apr 2021 17:31:58 +0900

최근 바쁘다는 핑계로

운영 업무를 할 때 안이했던 것 같다.

고도화 프로젝트를 시작하며

운영에 배포하는 횟수가 잦게 되었는데,

크게 두 가지 실수를 저질렀다.

다시금 그러한 실수들을 반복하지 않기 위해

글을 작성한다.

첫 번째 실수

QA 환경에서 충분히 테스트하지 않았다.

요즘 협력사 개발 인력들이 갑자기 우르르 충원되어

내가 직접 개발하는 일은 줄어들었다.

협력사 분들에게 개발을 맡기는 대신,

나는 주로 앞 단에서 비즈니스를 처리하고 있다.

(개발을 많이 해보고 싶은데..)

다들 고수의 향기를 풍기고

실제로 고수 분들이기도 하셔서,

문의가 와서 수정 및 추가한 기능들을

QA 환경에서 충분히 테스트하지 않았다.

결국 그들도 사람이라

한 번에 100% 완벽하게 완성할 수 없기 때문에

감안하여 확인을 했었어야 했고,

나 또한 주 업무인 시스템 운영에서

주어진 역할을 다하지 않았다.

그래서 최근 운영 배포할 때마다 관련 담당자들이

'~가 이상해요', '~좀 봐주세요' 하면서

다시금 연락이 온다.

물론 운영 배포 후에 그런 연락이 올 수 있지만,

QA 환경에서 여러 번 테스트했더라면

충분히 거를 수 있는 것들이 대다수였다.

왜 그토록 많은 선배 개발자들이

테스트의 중요성에 대해 부르짖었는지

컴플레인을 받고 온 몸으로 느낄 수 있었다.

QA 엔지니어 짱짱맨.

두 번째 실수

운영 배포 후, 공지 및 안내를 충분히 하지 않았다.

현재 내가 운영 중인 시스템은

일반 사용자들이 아닌,

고객사의 직원들이 주로 사용한다.

따라서 웹 사이트에 공지를 날려주거나,

수정 및 추가 기능을 요청한 관련 담당자들에게

메일이라도 보내줬어야 한다.

그런데 다른 VoC 업무 등으로 바쁘다는 핑계로

운영 배포만 하고

추가 안내나 공지를 하지 않았다.

역시나 이러한 부분에서

왜 그토록 많은 채용 공고와 면접에서

협업의 중요성을 부르짖는지 알 수 있었다.

나 혼자 일하는 것이 아니다.

여러 사람이 얽혀 가며 일하기 때문에

항상 시야를 넓게 보고,

내가 혼자 하는 업무 같아도

연관된 사람들을 생각해보며 일해야 한다.

개발적인 부분보다는,

업무를 처리하는 부분에서

많은 것을 배웠다.

일반 사용자를 대상으로 한 사이트가 아니라

다행이라고 해야 할지..

물론 일반 사용자를 대상으로 하는 운영 업무였다면

이제 업무 시작한지 4개월 된 신입에게

운영 DB를 떡 주무르듯이 만지게 하고

모든 운영을 넘기진 않았을 테지만..!

끝!