Dezang Blog | DEZANG.net

해외주식 포트폴리오 공개 9월 2주차

September 12, 2021 · 4 min read

개요#

지금 현시점에 제가 가진 해외주식 포트폴리오와 어떤 생각으로 해외주식을 해왔으며, 앞으로의 계획은 무엇인지 공유합니다.

포트폴리오를 공개하는 이유와 주의사항#

제가 포트폴리오를 공개하는 이유는 아이러니하게도 그 동안 포트폴리오가 없었기 때문입니다. 블로그에 정기적으로 포트폴리오를 공개하자는 결심은 포트폴리오를 만들어서 관리하자. 라는 결심을 수행하기 위한 확장판인 셈이죠.

증권사 앱에서 종목 비중을 보여주긴 하지만 여러 증권사와 여러 계좌에 흩어져 있는 전체 자산을 관리하기에는 한계가 있습니다. 이런 부분을 자동화하려고 토이 프로젝트로 개발을 시도했었지만, 배보다 배꼽이 더 커지는 꼴이라 일단 수기로 구글 시트에 작성하기로 하였습니다.

저는 트레이더가 아닙니다. 종목을 기술적으로 분석하는 투자자도 아니죠. 경제 관련 뉴스 기사나 유튜브 영상을 통해 꾸준히 공부는 하고 있습니다만, 제가 관심있는 분야나 종목 안에서 검색하기 때문에 시야도 한정적입니다. 즉 제가 앞으로 이 공간에 적는 어떠한 투자관련 글은 종목추천이나 투자 권유가 아님을 명시합니다.

포트폴리오 공개#

경제적 자유.png

지금은 단순히 평가금액을 기반으로 한 비중 그래프지만 각 종목의 특성에 따라서도 분류할 예정입니다. 종목이 어떤 업종에 속해 있으며, 기업 라이프 사이클 중 어디에 위치하고 있는지 대략적으로는 알고 있지만 명확하지 않아서 이를 명확하게 파악하고 정리하는 작업을 우선적으로 해야합니다. 지속적으로 조금씩 업데이트할 생각입니다. 최종적으로는 이 영상 을 참고하여 전체 자산을 대시보드 형태로 보고자 합니다.

평가금액가치로 보았을 때 300달러 아래에 있는 종목들은 매수를 위한 부표로 사놓은 것들입니다. 사고 싶은데 너무 올랐다고 생각돼서 계속 매수 타이밍만 재던 놈들이죠. 그리고 그 매수 타이밍은 몇 주가 지나도 오지 않았습니다... 조정을 기다리던 어느 날 역시나 비싸다고 생각되었지만 그냥 시장가로 30-40만원 긁었습니다. 제가 산 가격대비해서 수익률이 크게 마이너스가 되었을 때 살 생각으로요. 그런데 그렇게 소량 산 종목들이 테슬라보다 수익률이 높네요. 참…

지금까지 투자 원칙?#

딱히 투자 원칙을 정한 적은 없습니다. 하지만 대략적으로 아래 항목들을 생각하면서 사거나 팔았던 것 같습니다.

혁신적이라고 생각하는 제품이나 기업 방향성이 공개되면 산다.
- 테슬라, 마이크로소프트, 퀄컴, 디즈니
내가 사용하면서 좋아하는 제품, 자주 소비하는 제품을 가진 기업을 산다.
- 코카콜라, 쿠팡, 데이터독, 유니티
펀더멘탈이 흔들리지 않은 기업이 최고가 대비 하락이 클 때 산다.
- 테슬라
더 좋은 투자할 곳이 생겼는데 현금이 없으면 판다.

내가 가지고 있는 생각#

저는 아래와 같은 생각을 가지고 있습니다. 생각은 매일매일 달라질 수 있지만, 지금까지 또 앞으로도 이런 생각에 기반하여 투자를 할 생각입니다.

마이크로소프트 홀로렌즈는 모바일의 다음 기기라고 생각될 정도로 혁신적이다. 하지만 최근 행보를 보면 일상에 적용되기에는 상당한 개선 및 시간이 필요해보인다.
내연기관차에서 전기차로 전환은 이미 시작되었고, 환경문제와 겹쳐 선택이 아닌 필수가 되었다. 테슬라는 전기차 섹터 내 퍼스트 무버로 OTA, FSD, 4680 배터리 등 으로 다른 기업들과 기술적 격차를 벌리고 있다.
세상에 돈이 너무 많이 풀린다. 화폐의 가치는 계속해서 떨어지고 있다. 현금을 그냥 두면 녹아 내린다. 녹지 않는 자산을 보유해야 한다.
노동의 가치는 로봇과 인공지능의 발전으로 계속해서 하락할 것이며 상대적으로 부동산과 기술의 가치(기술을 보유한 회사의 가치)는 계속해서 높아질 것이다.
가장 가치있는 투자는 나 자신에 투자하는 것이다. 나의 성장을 위해서라면 시간과 돈을 아끼지 말자.

앞으로의 계획#

최근에 읽은 Tesla: Sometimes A Great Company Isn't A Great Stock 이라는 글은 상당 부분 공감합니다. 위대한 회사라고해서 무조건 좋은 주식이라고 볼 수는 없습니다. 제가보기에도 다른 기업들의 현재 영업이익이나 미래가치에 비해서 고평가되어 있다고 생각합니다만, 그래도 테슬라 100주는 보유하려고 합니다. 그래야 후회하지 않을 것 같아요. 설사 다시 500달러, 혹은 더 깊은 나락으로 떨어지더라도 말이죠. 그렇게 떨어지면 더 사면 되구요!
저의 포트폴리오와 위 계획을 보시면 알겠지만, 저에게 해외주식은 "해외주식=테슬라" 라고해도 무방합니다. 하지만 앞으로 섹터별, 배당주기별로 다양하게 분산해서 투자할 생각이고 그러기에 더욱 명확한 매매원칙 수립할 필요를 느낍니다. 이 부분은 여러 책과 영상을 통해 계속 고민중이고, 정리가 되면 다시 적어보도록 하겠습니다.

마치며#

저의 해외 주식과 국내 비율은 6:4 정도 되는 것 같습니다. 또 더 큰 관점에서 암호화폐와 주식 비율은 대략 10:1 정도입니다. 네, 고위험자산인 암호화폐가 가장 큰 비중을 가지고 있어요... 사실 이런 부분이 해외 주식 내에서 배분을 크게 고려하지 않았던 이유이기도 합니다. 일단 현금, 달러, 채권, 주식, 부동산, 암호화폐와 같은 더 큰 자산 관점에서 안전자산과 위험자산의 비중을 조절하는 것이 급선무죠... 추후 국내 주식과 암호화폐 포트폴리오도 정리해서 공유할 수 있는 기회가 있었으면 좋겠습니다. 감사합니다.

Intellij 프로젝트 관리 단축키

September 5, 2021 · 3 min read

개요#

실무에서 인텔리제이를 사용하다보면 사용하는 프로젝트들이 적지 않습니다. 최근에 프로젝트를 열고 닫는데 사용하는 방법을 소개합니다.

정리되지 않은 작업 환경#

저는 단축키 사용을 좋아합니다. 주로 사용하는 도구가 있다면, 그리고 그 도구에서 자주 사용하능 기능이 있다면 단축키를 찾기 위해 시간을 투자합니다. 이렇게 투자한 시간은 이후 반복되는 작업에 소요되는 시간을 줄여줘서 긴 시간으로 봤을 때 효율적입니다.

MSA 로 구성된 서비스를 운영하다보면 여러 개의 프로젝트를 열어서 작업하게 되는데요. 어느새 인텔리제이 창만 5개가 넘어가버려서 효율이 떨어질 때가 있습니다. 작업이 끝나면 바로바로 창을 닫아 정리해야하면 좋을텐데 말이죠.

사실 인텔리제이 창뿐만 아니라 보겠다고 열어둔 수많은 크롬창과 터미널창에 작업 공간이 덮혀버리게 되면, 저는 궁극기인 재시작을 시전합니다. 하지만 인텔리제이 창이 많이 열려있을 때는 인텔리제이 모든 창을 닫고 다시 필요한 프로젝트를 열어서 작업을 계속해갔죠.

너무 친절한 인텔리제이#

인텔리제이에서 설정할 수 있는 부분인지는 확실하지 않지만, 창이 여러개 열린 상태로 앱을 재시작하면, 친절하게도 이전에 열려있던 모든 창을 다시 열어줍니다. 다시 깔끔하게 시작하겠다고 재시작했는데, 효과가 없는 셈이죠. 그래서 오랫동안 저는 인텔리제이 창을 하나씩 찾아가며 끄기를 시전했습니다. 최소화 해놓은 창들도 있고, 맥 데스크탑 화면 여기저기 흩어져 있어서 약간은 번거로운 작업이였지만, 내가 집중해야 할 창만 열어놓으면 업무 효율이 3~5% 정도는 향상되는 것 같은 느낌을 받았죠. (기분탓이겠지만) 그리고 이렇게 할 수 있는 단축키를 찾아보았지만, 일단 제 선에서는 못 찾았었습니다.

만능 단축키 CMD+SHIFT+A#

인텔리제이를 사용하면서 Cmd + Shift + A 를 모르는 사람이 있을까요? 만약에 지금까지 몰랐다면, 네, 제가 당신의 미래 시간 상당부분을 절약해드리게 됐습니다. Cmd + Shift + A 는 인텔리제이에서 액션 팝업창을 열어주는 단축키입니다. 어떤 액션이 수행되는게 아니라 수행할 액션을 검색할 수 있는 팝업창을 불러오는 단축키이죠.

자 그럼 제가 이번에 소개하려고 하는 프로젝트 관리에 대해서 말해보죠. 하나씩 창을 찾아서 닫는데 아니라 Close All Projects 라고 입력하면 모든 프로젝트가 닫히게 됩니다. 사실 이 기능은 화면 상단 File 메뉴에서도 있습니다. 어떻게 보면 저걸 입력하느니, 마우스에 손을 옮겨 File → Close All Projects 를 누르는게 더 빠를수도 있죠. 하지만, 전체를 입력하지 않아도 된다면 이야기가 달라집니다.

저 기능에 앞글자인 CAP 라고 입력하면 바로 해당 기능을 선택할 수 있죠. 만약 원하는 기능이 조금 아래 있다면 조금 더 명확하게 입력해주면 됩니다. CAPro 와 같은 형태로요.

Monosnap 2021-09-05 16-21-49.png

이런 앞글자 검색 방식은 인텔리제이 전반에서 동작합니다. 파일이나 클래스를 찾을 때도 동일하게 찾으면 되지요. (이런 검색 방식을 칭하는게 있는데 기억이 잘 안나네요)

보너스 최근 프로젝트 열기#

모두 닫았으면 원하는 프로젝트들을 열어야겠죠. 그리고 아마 대부분 열어야 하는 프로젝트들은 최근에 열었던 프로젝트일거예요. 최근 프로젝트 열기? Open Recent Project Action 팝업을 열어서 뭐라고 입력해야하는지 감이 오시나요? ORP 라고 입력하면 됩니다.!

마치며#

사실 적고 보면 간단한 기능인데, 저는 상당히 오랫동안 트랙패드로 손을 옮겨서 위에 소개한 기능들을 실행해왔습니다. 그 동안 그 번거로운 기분과 수없이 여러 번 낭비된 1~2초만 모아도 넷플릭스에서 영화 한편은 볼 수 있었을거예요! (사실 넷플릭스가 제일 낭비- _ㅠ)

많은 분들이 바로 깨달았겠지만, Cmd + Shift + A 은 비단 프로젝트 전체 닫고 최근 프로젝트 여는 곳에만 사용되는게 아닙니다. 말그대로 인텔리제이 내 모든 액션들을 검색하고 실행할 수 있죠. 무언가를 여러 번 클릭해서 실행하고 있나요? Cmd + Shift + A 를 눌러서 검색해보세요! 당신의 소중한 1초를 지켜줄거예요.

Spring Rest Docs & OAS - 시작하기

September 5, 2021 · 5 min read

개요#

지난 글 Spring Rest Docs & OAS 의 필요성 에서 이 둘의 조합이 왜 필요한지 알아보았습니다. 이제 간단한 샘플 코드를 통해 OAS 를 사용해서 API 문서를 만들어보겠습니다.

본문에 등장하는 코드는 깃허브에서 확인할 수 있습니다.

시작하기 전에#

이 튜토리얼은 restdocs-api-spec 라이브러리 사용에 중점을 두고 있습니다. 따라서 아래 나열된 방법들은 상세히 설명하지 않습니다.

Sprint Rest Docs 를 사용하는 방법
Spring Boot Start Web 으로 API 를 만드는 방법

restdocs-api-spec 프로젝트는 여러가지 구성 요소로 구성되어 있으며, mockmvc 를 사용한 테스트와 restassured 을 사용한 테스트 둘 다 지원합니다. 두 테스트의 큰 차이점은 MockMvc 는 @WebMvcTest 를 사용하고, Rest Assured 는 @SpringBootTest 를 사용한다는 점인데 자세한 내용은 MockMvc VS RestAssured 글을 참고되지만, 이 글이 작성된 시점은 2020년 8월로 1년이 지난 현재는 io.rest-assured:spring-mock-mvc module 이 존재하여 RestAssured 를 사용하더라도 전체 Bean 을 로드할 필요가 없어졌습니다.

테스트 가독성이나, 작성의 편리함을 보았을 때 RestAssured 를 사용하는게 좋아보이나, 이전에 사용 경험이 없어서, 이 글에서는 익숙한 MockMvc 를 사용하여 작성합니다. 추후 RestAssured 를 사용한 샘플도 작성해보겠습니다.

바로 RestAssured 로 시도해보고 싶은 분들은 아래 글들을 참고하면 좋을 것 같습니다.

간단한 샘플 API 구현#

먼저 사용자 정보를 조회하는 간단한 API 를 만들어보겠습니다. 그래들 설정을 해주고...

plugins {
    id 'org.springframework.boot' version '2.5.4'
    id 'io.spring.dependency-management' version '1.0.11.RELEASE'
    id 'java'
    id 'com.epages.restdocs-api-spec' version '0.11.5'  // (1)
}

group = 'net.dezang'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '11'

configurations {
    compileOnly {
        extendsFrom annotationProcessor
    }
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    compileOnly 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    testImplementation 'org.springframework.restdocs:spring-restdocs-mockmvc' // (2)
    testImplementation 'com.epages:restdocs-api-spec-mockmvc:0.11.5' // (2) For openapi spec
}

openapi3 { // (3)
    server = 'http://localhost:8080'
    title = 'USER-API'
    description = '사용자 리소스 API 입니다.'
    version = '0.1.0'
    format = 'yaml'
}

test {
    useJUnitPlatform()
}

(1) restdocs-api-spec 플러그인 추가
(2) spring-restdocs-mockmvc , restdocs-api-spec-mockmvc 의존성 추가
(3) openapi3 에 설정 정보 입력

유저 정보를 조회하는 간단한 API 를 만들어줍니다.

package net.dezang.restdocopenapi;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class RestdocOpenapiApplication {

    public static void main(String[] args) {
        SpringApplication.run(RestdocOpenapiApplication.class, args);
    }
}

package net.dezang.restdocopenapi;

import lombok.Builder;
import lombok.Getter;

@Getter
@Builder
class User {
    private Long id;
    private String username;
    private String password;
    private Integer age;
    private boolean enabled;
}

package net.dezang.restdocopenapi;

import lombok.AccessLevel;
import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.NoArgsConstructor;
import lombok.RequiredArgsConstructor;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.List;
import java.util.stream.Collectors;

@RestController
@RequestMapping("users")
@RequiredArgsConstructor
public class UserController {
    private final UserService userService;

    @GetMapping
    public ResponseEntity<List<UserDto.Response>> list() {
        List<UserDto.Response> responses = userService.list().stream()
            .map(UserDto.Response::of)
            .collect(Collectors.toList());
        return ResponseEntity.ok(responses);
    }

    @NoArgsConstructor(access = AccessLevel.PRIVATE)
    static class UserDto {
        @Data
        @AllArgsConstructor
        static class Response {
            private String username;
            private Integer age;

            public static Response of(User domain) {
                return new Response(domain.getUsername(), domain.getAge());
            }
        }
    }
}

package net.dezang.restdocopenapi;

import org.springframework.stereotype.Service;

import java.util.Collections;
import java.util.List;

@Service
class UserService {
    public List<User> list() {
        return Collections.singletonList(User.builder()
            .id(1L)
            .username("dezang")
            .password("!topSecret!")
            .age(20)
            .enabled(true)
            .build());
    }
}

우리는 컨트롤러 테스트와 이를 통해 나오는 API 문서에 관심이 있기에 레포지토리 레벨은 의도적으로 추가하지 않았습니다. 간단한 샘플이지만 도메인 객체와 응답 객체는 분리하였습니다.

OPENAPI SPEC 문서 생성#

package net.dezang.restdocopenapi;

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.restdocs.AutoConfigureRestDocs;
import org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest;
import org.springframework.boot.test.mock.mockito.MockBean;
import org.springframework.test.web.servlet.MockMvc;
import org.springframework.test.web.servlet.ResultActions;

import java.util.Collections;

import static com.epages.restdocs.apispec.MockMvcRestDocumentationWrapper.document; // (1)
import static org.mockito.BDDMockito.given;
import static org.springframework.restdocs.mockmvc.RestDocumentationRequestBuilders.get;
import static org.springframework.restdocs.payload.PayloadDocumentation.fieldWithPath;
import static org.springframework.restdocs.payload.PayloadDocumentation.responseFields;
import static org.springframework.test.web.servlet.result.MockMvcResultHandlers.print;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;

@AutoConfigureRestDocs
@WebMvcTest(UserController.class)
class UserApiDoc {
    @Autowired
    MockMvc mockMvc;
    @MockBean
    UserService userService;

    @Test
    void list() {
        //given
        given(userService.list())
            .willReturn(Collections.singletonList(
                User.builder()
                    .username("dezang")
                    .age(10)
                    .build()
            ));

        //when
        ResultActions resultActions = mockMvc.perform(get("/users"));

        //then
        resultActions
            .andExpect(status().isOk())
            .andDo(document("list-user",
                responseFields(
                    fieldWithPath("[].username").description("사용자 아이디"),
                    fieldWithPath("[].age").description("사용자 나이")
                )))
            .andDo(print());
    }
}

(1): MockMvcRestDocumentation 이 아닌 MockMvcRestDocumentationWrapper 내 document 메소드를 사용하여 테스트를 작성

코드 작성은 끝났습니다. 이제 openapi3 문서를 만들기 위해 플러그인이 제공하는 테스크를 실행합니다.

./gradlew openapi3

위 명령어를 실행하면, 테스트가 돌고 테스트 결과물이 build 경로에 생성됩니다.

build
├── api-spec
│   └── openapi3.yaml
...
├── generated-snippets
│   └── list-user
│       ├── curl-request.adoc
│       ├── http-request.adoc
│       ├── http-response.adoc
│       ├── httpie-request.adoc
│       ├── request-body.adoc
│       ├── resource.json
│       ├── response-body.adoc
│       └── response-fields.adoc
...

우리가 원하는 파일이 저기 보이네요. build/api-spec/openapi3.yaml 입니다. 아웃풋 경로는 처음 공유한 build.gradle 에 openapi3 에서 설정 가능합니다. 그럼 yaml 파일을 한번 살펴볼까요?

openapi: 3.0.1
info:
  title: USER-API
  description: 사용자 리소스 API 입니다.
  version: 0.1.0
servers:
- url: http://localhost:8080
tags: []
paths:
  /users:
    get:
      tags:
      - users
      operationId: list-user
      responses:
        "200":
          description: "200"
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/users450998075'
              examples:
                list-user:
                  value: "[{\"username\":\"dezang\",\"age\":10}]"
components:
  schemas:
    users450998075:
      type: array
      items:
        type: object
        properties:
          age:
            type: number
            description: 사용자 나이
          username:
            type: string
            description: 사용자 아이디

생각보다 별거 없어보이지만, 스펙 자체는 강력합니다. 이전 글 Spring Rest Docs & OAS 의 필요성 에 대한 확인할 수 있습니다.

스펙 문서 활용하기#

이제 유연한 결과물을 얻었으니, OAS 를 지원하는 도구나 서비스를 활용하면 됩니다. 일단 여기서는 도커를 활용하여 Swagger 를 사용해보겠습니다.

docker run --rm -p 80:8080 \
-v __YOUR_BUILD_PATH__/api-spec:/usr/share/nginx/html/docs/ \
-e URL=docs/openapi3.yaml \
swaggerapi/swagger-ui

드디어 API 문서를 볼 수 있게 되었습니다!

Swagger UI 2021-09-05 13-56-49.png

마치며#

이제 API 문서를 만들었으니 끝일까요? REST DOCS + OAS 를 시작하게 된 이유가 MSA 구조에서 분산되어있는 API 문서를 어떻게 하면 통합해서 볼 수 있을까? 였던 것을 기억하시나요? 각 서비스가 어떤 방법을 사용해서 OAS 라는 스펙을 지킨 문서를 생성했다면, 이 문서를 어떻게 서빙하는 것이 좋을까요? 다음 글에서는 역시 분산되어 있는 OAS 파일을 어떻게 자동으로 한 곳으로 모으고, 사용자들에게 보여줄 것인지 고민의 결과를 공유하겠습니다.

Spring Rest Docs & OAS 의 필요성

August 22, 2021 · 5 min read

개요#

테스트를 통해 API 문서가 코드와 일치됨을 보장해주는 SPRING REST DOCS 과 뛰어난 범용성을 자랑하는 OPEN API SPEC (OAS 3) 의 조합으로 개발된 API 활용도를 극대화 시키는 법을 소개합니다. 모든 API 문서를 한 곳으로 모을 수 있는 것은 보너스입니다.

SPRING REST DOCS 과 OAS 조합이 필요한 이유#

개발된 API 가 목적에 맞게 제대로 이용되려면 문서화는 필수적입니다. 저는 예전부터 테스트 코드를 통해 API 문서가 생성되는 SPRING REST DOCS 을 사용해왔습니다. API 문서를 위한 테스트를 만들어야 한다는 점은 분명히 번거로웠지만, API 문서가 코드와 일치되지 않아 발생할 수 많은 이슈들에 비하면 별거 아니라고 생각합니다. SPRINT REST DOCS 가 아니라면 지금까지도 못 들어보지 않았을까 싶은 AsciiDoc 이 불만이긴 했습니다만, 마크다운과 비슷한 사용법에 러닝커브가 거의 없다시피하여 잘 써왔습니다. 하지만 색다른 방법을 찾아봐야 하는 이유는 도구 자체가 아니라, 도구를 통해 만들어진 문서 접근에서 발생했습니다.

계속해서 늘어나는 API 서버와 분산되는 API 문서#

서비스가 확장함에 따라 API 엔드포인트가 늘어나는 것은 불가피했고, MSA 환경에서 개발되고 있는 제품인지라, API 추가는 API 서버의 추가로 이어졌습니다. 각 서버마다 REST DOCS 을 통해 만들어지는 API 문서는 각 서버의 특정 엔드포인트로 접근할 수 있었고, 우리 팀은 여기저기 흩어져있는 API 문서를 찾아다니며 개발을 해야하는불편함을 겪어야했습니다.

또한 자바가 아니라, 다른 언어로 개발된 API의 경우 REST DOCS 을 사용할 수 있는 방법이 없었고, 이런 이유로 REST DOCS 을 사용하지 않거나 사용하지 못하는 API 서버는 사내 Notion 에 API 문서를 작성해 공유하도록 하였으나, 역시나 크고 작은 수정 사항들이 빈번하게 동기화되지 않았고, 노션에 있는 API 문서는 신뢰를 잃어가고 있었습니다.

어떻게 하면 사내에 있는 모든 API 를 한 곳에서 볼 수 있을까?#

어떻게 하면 여기 저기 흩어져있는 API 를 한 곳에서 볼 수 있을까요? 그래서 사내에 있는 모든 기능과 리소스를 최대한 활용할 수 있는 환경을 만들 수 있을까요? 처음에는 각 서버에 있는 SPRING REST DOCS 으로 생성된 html 문서를 모아서 한 웹 서버에서 호스팅을 고려해보았습니다만, 그 각각의 문서 링크를 담고 있는 별도 페이지가 필요했고, 그 곳에는 Notion 링크도 들어가야 했습니다. 이렇게 하면 관리가 잘 될 수 있을까요? 모든 API 서버가 코드를 기반하여 같은 형태(인터페이스)로 API 스펙을 정의한 결과물을 만들어 낼 수는 없을까요?

이 시점에서 REST DOCS 을 잠깐 포기하고 다른 대안을 찾아보기 시작했습니다. API 블루프린트, 스웨거 과 같은 오프소스부터, 최근 자주 보이는 리드미닷컴, Stoplight 유료 솔루션도 검토해보았죠. 유료 솔루션을 알아보니 정의된 API 를 미려한 사이트로 호스팅해주는 역할을 주로하고 API Spec 자체는 개발자가 만들어서 넣어야했습니다. (어찌보면 당연한 이야기...) 그런데 문서를 읽다보니 OAS 3, Swagger Support 라는 문구가 여기저기서 보이더군요. Swagger는 사용해봤고, OAS 3 는 Open Api Specification v3 의 축약어였습니다. 여기에서 해결방법이 어렴풋 보이는 것 같았습니다.

그래, 관건은 API Specification.#

위에서 언급한 '모든 API 서버가 코드를 기반하여 같은 형태(인터페이스)로 API 스펙을 정의한 결과물을 만들어 낼 수는 없을까요?' 은 저만 고민했던 것은 아니였습니다. 이미 옛날부터 선배들이 고민해왔고, 그에 대한 정의도 만들어 놓았습니다.

OpenAPI v3.0 was released in July, 2017, by the OpenAPI Initiative, a consortium of member companies who want to standardize how REST APIs are described. There are various other approaches to API description
OpenAPI v3.0은 REST API 설명 방식을 표준화하려는 회원사 컨소시엄인 OpenAPI Initiative에서 2017년 7월에 출시했습니다. API 설명에 대한 다양한 접근 방식이 있습니다.
Stoplight - How to choose your api specification

여기서 소개하는 접근 방식은 OpenAPI, JSON Schema, API Blueprint, RAML 이며, 추천하는 녀석은 OpenAPI v3 입니다. 여기 저기서 봤던 OAS3 바로 그 녀석이죠. OAS3 에 대해서 자세히 알고 싶다면 여기 에서 확인할 수 있습니다.

이제 각 API 서버가 어떤 형식으로 표준화된 결과물을 생산해야하는지는 결정되었습니다. OAS 스펙에 맞는 형태로 yaml 또는 json 파일을 떨궈주면, 그 파일을 이쁘게 보여줄 도구와 서비스는 널려있습니다. 뿐만 아니라 OSA3 는 기계, 도구가 이해할 수 있도록 설계되었다고 하니, 일단 OAS 스펙 파일만 있으면 뭐든지 할 수 있을 것 같네요. 자 그럼 어떻게 이 파일을 API 서버로부터 얻을 수 있을까요? 사람이 하나하나 작성할 형태는 아닌데 말이죠.

스웨거를 다시 써야 할까?#

OAS 는 API 스펙을 나타내는 가장 대표적인 포맷이라 각종 언어에서 여러가지 프로젝트들이 지원합니다. 여기서는 대표적으로 Spring 쪽에 SpringDoc Project 와 Nodejs 쪽에는 Swagger-jsdoc 이라는 프로젝트가 있습니다. 특히나 스웨거는 OAS 적극 지원하고 있으며, 이전부터 자바/스프링 진영에서도 많이 쓰이는 프로젝트 입니다. 어찌보면 SPRINT REST DOC 보다 더 많이 쓰이는 녀석일지도 모르겠네요. 스프링에서 어노테이션 몇 개로 기본적인 문서를 뚝딱 만들어주는 도구니까요. 다만 예전에 스웨거를 써 본 입장에서 컨트롤러 코드에 API 설명를 위한 코드가 너무 덕지덕지 붙어있어서 가독성이 떨어지는 단점이 있었습니다. 제품 코드와 동기화도 보장하지 않구요.

Rest Docs 이 Open API Spec 을 떨궈줄 수만 있다면.#

REST DOCS 사용을 포기하고 여기까지 왔지만, 다시금 REST DOCS 이 그리워지는 순간입니다. REST DOCS 이 완성된 HTML 문서를 최종 결과물로 생성하는게 아니라, OPEN API Spec 으로 생성할 수만 있다면, 많은 것들이 해결될텐데 말이죠. 그런데! 그렇게 명확한 방향을 잡고 구글링을 하니, 저와 같은 고민 끝에 그 해답을 얻어 낸 분 이 있었습니다. 그리고 여기서 발견한 이 모든 것을 해결해주는 restdocs-api-spec 프로젝트! 기존 클래스들을 랩핑해서 만들어놔서 Import 만 바꿔줘도 기존 코드에 큰 변화없이 적용이 가능했습니다. 이제 이 라이브러리를 사용해서 REST DOCS 테스트 코드를 만들면, OPENAPI 3 스펙으로 파일이 뚝 떨어집니다. 유레카!

마치며#

분산된 API 문서들, 이 문서를 한 곳으로 모으고자 했던 갈망(?) 과 OAS 와restdocs-api-spec 이라는 라이브러리를 만나게 되기까지에 여정을 소개해드렸습니다. 다음 글에서는 본격적으로 restdoc-api-spec 을 사용해서 OAS 파일을 생성하고, 스웨거에서 파일을 보기 좋은 형태로 서빙하는 부분을 적어볼께요. 긴 글 읽어주셔서 감사합니다.

Go 시작하기 - 01

August 15, 2021 · 3 min read

들어가며#

새로운 것에 대한 배움은 삶을 풍요롭게 합니다. 익숙함에서 벗어나면 데이터를 처리하는 또 다른 시각을 포함하여 많은 것을 얻을 수 있다고 생각합니다. 주관적인 배우고 싶은 언어 랭킹 1위인 Golang 을 처음부터 차근차근 배워나가려고 합니다. 이 글은 누군가에게 Golang 에 대한 정보 전달을 목표로 하는 것이 아니라, 내가 언어를 배워나가는 과정을 담은 개발 학습 로깅입니다.

모든 과정에 대한 코드는 GitHub 에 공개되어있습니다.

간단하게 시작하기#

개발 환경 구성#

먼저 Go를 사용하려면 Go 를 설치해야합니다. 설치는 너무나 간단해서 여기에서는 따로 다루지 않겠습니다.

이제 어떤 에디터를 사용해서 코딩을 할지 결정해야하는데요. 저는 인텔리제이의 노예이기 때문에 인텔리제이를 사용하겠습니다. 기본적으로는 Go 를 지원하지 않는데, 플러그인만 설치하면 GoLand (JetBrain 의 Go 전용 IDE) 의 모든 기능을 사용할 수 있다고 하니 환호성을 지르며 어서 설치해줍니다.

Preferences 2021-08-15 17-13-09.png

설치가 되었으면, 빨리 프로젝트를 만들어보죠. 프로젝트를 만드는 순간부터 그 프로젝트의 역사는 시작됩니다. 그리고 그 역사는 commit 으로 기록되죠. 좌측에서 Go 를 선택하고 다음을 눌러 프로젝트 이름을 지정하고 Finish 를 누르면 프로젝트가 생성됩니다. Go 버전이 업데이트되면서 GOPATH 방식에 프로젝트는 잘 사용하지 않는 것으로 알고 있습니다.

New Project 2021-08-15 17-20-32.png

자 새로운 세상을 만날 준비가 되었다면 인사를 하며 시작해봅니다. main.go 파일을 만들고 main 함수를 생성한 뒤 아래와 같이 작성합니다.

package main

import "fmt"

func main() {
    fmt.Print("Hello")
}

Hello, Go World!
Process finished with the exit code 0

개인적으로는 인사만 한 다섯번째 하는 것 같네요 😐

외부 리소스 가져오기#

인사만 하고 끝내기는 아쉬우니 한 발자국만 더 가볼까요? 추후에 의미있는 앱을 만들려면 외부에서 데이터를 가지고 오는게 필수적입니다. 필요한 데이터가 있다면, 그 데이터를 제공해주는 서비스를 찾아보고 그 서비스가 API 를 지원하는지 확인해보세요. 대부분의 서비스들은 API 를 지원합니다.

API 문서 확인#

여기서는 요즘 핫한 암호화폐의 현재 시세를 가지고 와보죠. 저는 업비트 거래소를 사용하겠습니다. 업비트 API 문서 에서 현재가 정보를 제공하는 엔드포인트를 확인합니다. 코딩하기 전에 정말로 데이터가 내려오는지 확인해볼까요?

curl --request GET \
     --url https://api.upbit.com/v1/ticker\?markets\=KRW-BTC \
     --header 'Accept: application/json'
[{"market":"KRW-BTC","trade_date":"20210815","trade_time":"075919","trade_date_kst":"20210815","trade_time_kst":"165919","trade_timestamp":1629014359000,"opening_price":54817000.00000000,"high_price":55166000.0,"low_price":53420000.0,"trade_price":53614000.0,"prev_closing_price":54812000.00000000,"change":"FALL","change_price":1198000.00000000,"change_rate":0.0218565278,"signed_change_price":-1198000.00000000,"signed_change_rate":-0.0218565278,"trade_volume":0.022,"acc_trade_price":213592738229.775190000,"acc_trade_price_24h":559827073056.69978000,"acc_trade_volume":3918.44716516,"acc_trade_volume_24h":10269.53880782,"highest_52_week_price":81994000.00000000,"highest_52_week_date":"2021-04-14","lowest_52_week_price":11860000.00000000,"lowest_52_week_date":"2020-09-07","timestamp":1629014359797}]

잘 가지고 오네요. 개발하기에 앞서 이런 과정은 중요합니다. 내가 코딩을 잘못해서 데이터를 못 가지고 온 건지, 아니면 서비스 자체적으로 문제가 있어서 못가지고 온 것인지 확인이 필요하죠. 서비스는 문제가 없으니 이제 제가 코딩만 잘하면 데이터를 가지고 오겠네요. 🤩

사용할 패키지 찾고 문서 확인하기#

Go 에서는 HTTP 요청을 어떻게 해야 할까요? 고 패키지 를 모아놓은 사이트에 가서 http 를 검색해봅니다. JAVA로 치면 Maven Repository 같은 곳이겠네요. 예제가 친절하게 써있습니다. 이제 식상한 인사는 그만하고 암호화폐의 대장인 비트코인에 가격을 가지고 와볼께요.

package main

import (
    "io/ioutil"
    "net/http"
)

func main() {
    resp, err := http.Get("https://api.upbit.com/v1/ticker?markets=KRW-BTC")
    if err != nil {
        panic(err)
    }

    defer resp.Body.Close()

    data, err := ioutil.ReadAll(resp.Body)
    if err != nil {
        panic(err)
    }

    println(string(data))
}

[{"market":"KRW-BTC","trade_date":"20210815","trade_time":"084318","trade_date_kst":"20210815","trade_time_kst":"174318","trade_timestamp":1629016998000,"opening_price":54817000.00000000,"high_price":55166000.0,"low_price":53411000.0,"trade_price":53687000.0,"prev_closing_price":54812000.00000000,"change":"FALL","change_price":1125000.00000000,"change_rate":0.0205247026,"signed_change_price":-1125000.00000000,"signed_change_rate":-0.0205247026,"trade_volume":0.05957287,"acc_trade_price":239700491633.154070000,"acc_trade_price_24h":574757863109.85536000,"acc_trade_volume":4405.80968434,"acc_trade_volume_24h":10554.59700851,"highest_52_week_price":81994000.00000000,"highest_52_week_date":"2021-04-14","lowest_52_week_price":11860000.00000000,"lowest_52_week_date":"2020-09-07","timestamp":1629016998428}]

마치며#

간단한 몇 줄에 코드로 원하는 데이터를 가지고 왔습니다. 이제 데이터를 가지고 오는 법을 알았으니 원하는 데이터를 여기저기서 가지고 와서 요리조리 뚝딱뚝딱하면 원하는 기능을 하는 앱을 만들 수 있겠어요. 그런데... 저 JSON 문자열로 된 놈을 어떻게 해야 할까요? Go 에 저 데이터를 이쁘게 담아놓는 방법이 있을까요? 다음 번에는 이 방법에 대해 알아보겠습니다.

무제

August 14, 2021 · 4 min read

개요#

내 머리 속에 흐르는 생각을 적어본다.

생각의 흐름대로 적는다.#

글의 구성#

최근부터 일주일에 한 두 개씩이라도 글을 작성해서 올리고 있는데, 머리 속에 있는 정보를 글로 녹여내는데 어려움을 많이 느낀다. 그래서 작성하다가 마무리 짓지 못한 글이 계속해서 쌓이고 있다. 어떻게든 마무리 지어서 공개하긴 하지만, 스스로 글의 퀄리티가 만족스럽지 못하다. 글은 대부분 개발에 관련된 내용이라 작문 능력이 중요하지 않을 거라 생각했는데, 그래도 글은 글인듯 하다...

일단 괜찮은 글을 작성하기 위한 시작점으로 글의 구성을 잘 잡는 것부터 시작하려 한다. 그 방법을 이미 알고 있다면 이런 고민을 시작도 하지 않았겠지. 글의 작성도 애자일하게 작은 것을 시도하고, 회고하고 더 나은 방법을 시도하는 형식으로 진행해보려한다. 그 첫번째 시작으로 "개요" 세션과 "마치며" 세선의 추가다. 내가 적고자 하는 주제를 명확히 하는 것이 우선이라고 생각했기 때문에.

140자#

140자를 생각하면 떠오르는게 기업. 트위터, 나는 트위터를 많이 하지 않지만 앨론 머스크 덕분에 트위터로 공유된 정보를 다른 경로를 통해 많이 접한다. 트위터가 성공했던 이유 중에 하나는 이 "140자" 로 한정지은 트윗도 한몫했다고 생각한다. 글자 수에 한계 때문에 정보의 핵심만 담아야 하기 때문이다. (방금 안거지만 한중일을 제외한 다른 나라들의 트윗 글자수 제한은 280자 라고 한다.) 갑자기 왜 트위터가 튀어나왔냐고? 개요는 140자 이내로 적자! 라는 규칙을 만들면서 떠올랐다.

생각이 날라다닌다.#

내가 글을 적겠다고 컴퓨터 앞에 앉았을 때, 분명히 APY 와 ARP 의 다른 점 을 정리해야겠다고 생각했는데, 그걸 적다보니 앵커에 대한 이야기를 하고 있고, 앵커를 적다보니 디파이에 대한 내용을 적고 있고, 글의 내용이 너무 뒤죽박죽이라, 나는 왜 이럴까 생각하다가 어떻게 하면 글을 잘 쓰는지를 찾아보다가, 갑자기 어제 산 유데미 강의가 생각나서 그걸 조금 보다가, 아 글 쓰고 싶은데 어떻게하지 싶어서 선택한 방법이, 제목이 없는 생각 흐름 적기다. 어떻게 하면 이 날라다니는 생각을 하나의 주제에 묶어 놓을 수 있을까?

내가 무언가를 학습하는 방법#

유데미를 보면서 들었던 생각, 나는 어떻게 새로운 것을 배울까? 일단 모든 학습의 시작은 "어떤 문제" 로부터 시작된다. 그 문제를 해결하기 위해 "인터넷" 을 검색하다보면 해결 방법을 얻고 문제를 해결한다. 그리고 그 과정에서 애써 무시한 제대로 해결하기 위해 알아야 하는 지식이나, 더 우아하게 해결하는 방법에 대한 키워드를 얻을 수 있는데, 이 키워드를 조금만 공부해보면 여기서 알아야 할 것들이 무수히 많이 파생된다.

그렇게 학습해야 할 대상이 파악되면, 나는 구글에 꼭 alternative, compare, vs 와 같은 단어를 입력해서 내가 지금부터 학습할 녀석이 최적의 솔루션인가? 를 확인한다. '은총알은 없다' 라는 말처럼 모든 것을 해결하는 단 하나에 방법은 잘 존재하지 않지만 이 과정에서 내 성격에 더 잘 맞거나 현재 상황에 더 적합한 솔루션을 찾게 되는 것이다.

그렇게 대상에 대해 "이건 깊게 알아놓으면 내 인생이 편해진다.", "이걸 앞으로 많은 곳에서 사용될 놈이라 내 몸 값 올릴려면 배워야 한다." 이라는 확신이 서면, 가장 먼저 공식 문서를 확인한다. 모든 정답은 공식 문서에 있으니까. 그런데 그 공식 문서라는 녀석들이 양이 너무나도 방대해서, 꼭꼭 씹어서 이해하려면 한 세월이고, 전체적인 문서구성을 파악해서 나중에 필요할 때 '공식 문서에서 이거에 대한거 본 것 같은데?' 정도만 생각날 수 있도록 전체적으로 훑어본다. 여기서 큰 언덕이 "영어" 인데... 아예 못 읽는 것은 아니지만 읽는 속도가 매우 더디기 때문에 답답함이 몰려온다. 구글 번역기가 많은 부분 서포트해주긴 하지만, 그래도 불편함은 마찬가지.

이 시점에 필요한 게, 개발 서적이다. 나는 개발 서적을 꽤나 좋아하는데 일단 내가 뭘 모르는지 모르는 것을 깨닫게 해주고, 문제가 생길 때 언제든 물어볼 수 있는 동료 같은 존재가 되어 주기 때문이다. 개발 서적을 읽다보면...

잠깐 이거 생각의 흐름인데 이 생각을 너무 깊게 한듯... 조금 더 정리해서 별도 글로 작성해보기로. 아마 위와 비슷하게 작성한 글이 저 깊은 어딘가에 저장되어 있을 듯하다.

무노동월이천#

요즘 내가 밀고 있는 목표. 다른 말로는 "경제적 자유", 길게 말하면 "일을 하지 않고, 안정적으로 월 이천만원씩 들어오는 파이프라인 만들기" 인데 달성률은 5퍼센트도 안된다. 아니 아직 달성률을 체크할 단계도 아니지. 현재는 무조건 노동(개발)을 해서 수입을 만들고 있는 상황, 그나마 배당주나 디파이 생태계에 관심이 있어서 이런 부분으로 파이프가 생기고 있긴 한거 같은데 그 크기가 거의 빨대 수준... 어찌되었든 이렇게 목표를 세워놓으니 어떻게 하면 달성할 수 있을까 계속 고민하게 되고 이것저것 공부하고 시도하는 듯.

"무노동" 이라고 해서 일을 하지 않는 삶을 목표로 하는 것은 아니다. 다만 나의 노동으로 수입을 만드는게 아니라, 나의 노동을 "지속적인 수입을 만들어 줄 파이프 라인" 을 만드는데 쓰는 삶을 살고 싶다. 즉 빵을 생산하는 기계의 삶 보다는 빵을 만드는 기계를 설계하고 만들어 돌리는 삶을 살고 싶은 것이지, 일 안하면 무료해서 그 또한 그 나름대로의 고통인듯ㅎ

마치며#

그냥 내 머리 속에 흐르는 생각들을 두서없이 적어보았다. 누군가가 읽어주기 바라기 보다는 내 생각을 정리하는 차원에서... 그래도 정신없이 적고나니 생각이 좀 정리되... 었으면 좋겠지만, 크게 달라진 것은 없는 것 같다. 그래도 미래의 내가 읽으면 그 땐 그랬지하면서 웃을 수 있을테니... ← 이 문장을 적으면서 아주 예전에 작성했던 텀블러 블로그에 들어가봤는데, 그 때도 비슷한 글을 적었다. 생각이 가득해 라는 글인데, 무려 8년 전이다. 그 때나 지금이나 왜 항상 생각만 가득한건지... 8년 뒤에 황대장. 지금도 생각이 많니?

쿠버네티스에서 앱을 재시작 하는 방법

August 8, 2021 · 3 min read

개요#

쿠버네티스를 처음 접하고 사용해온지 2년이 넘어가는 것 같습니다. 처음에 쿠버네티스를 다루게 될 때 난감했던 부분 중에 하나가 애플리케이션을 어떻게 내렸다가 올리는지였죠. 그 방법이 시간이 지나면서 조금씩 나아졌다고 생각하는데, 그 방법들을 한번 쭉 소개해볼까 합니다. (본문에서 말하는 "서비스"는 쿠버네티스에 서비스가 아니라 "애플리케이션" or "서버"를 말합니다.)

파드 삭제#

kubectl delete pod <pod-name> 

가장 처음으로 사용했던 방법입니다. 쿠버네티스는 디플로이먼트에 선언한 상태로 현재 상태를 맞추기 위해 파드가 삭제되면 자동으로 새로 띄워줍니다. 즉 삭제만 하면 알아서 쿠버가 다시 띄워주기 때문에 재시작처럼 동작합니다. 아, 이 방법은 deployment 매니페스트로 생성된 파드만 해당됩니다. 이 방법을 쭉 써오다가 디플로이먼트 파드가 복수 개인 서비스를 재시작 할 경우에 파드를 하나씩 종료시켜야하는 문제점을 만나게 되었습니다. 물론 추후 라벨로 같은 라벨인 파드를 모두 삭제 할 수 있다는 것을 알게되었지만 그 때는 이미 더 좋은 방법을 알고 있어서... 서비스가 성장하면서 특정 서비스에 복수 개에 파드가 생성되는 경우가 많아지면서 이 방법은 더 이상 쓰지 않게 되었습니다.

디플로이먼트 삭제 후 재생성#

kubectl delete -f <deployment-manifest>
kubectl apply -f <deployment-manifest>

결론부터 말하면 비추천하는 방법입니다. 디플로이먼트를 삭제하면서 잃어버리는 정보들이 많거든요. (rollout history 같은 정보들) 어찌 됐든 해당 방법을 사용하면 복수 개에 파드를 가진 서비스도 모두 재시작할 수 있습니다. 디플로이먼트를 지우고 다시 만드는데 안될 수가 없죠. 파드를 삭제하는 방법에 비해 장점이 또 하나 있습니다. 바로 종료 후 시작하는 시점을 사용자가 컨트롤 할 수 있다는 것이죠. 즉 위에서 소개한 파드 삭제가 종료 후 바로 시작하는 "restart" 이였다면, 디플로이먼트 삭제 후 생성은 "stop", "start" 로 이벤트 시점이 나눠지게 됩니다. 운영하다보면 잠깐 내렸다가 일정 시간 후 띄워야 하는 경우가 생기기 마련이죠. 그럼 그 때 이렇게 해야하는데 왜 비추천이냐구요? 바로 다음에 소개 시켜드릴 방법이 더 좋기 때문입니다.

디플로이먼트의 Scale 을 변경#

kubectl scale deployment <deployment-name> --replicas 0
kubectl scale deployment <deployment-name> --replicas <n>

서비스 재시작을 위해서 상당히 오랫동안 써왔고 현재도 쓰고 있는 방법입니다. 다만 지금은 "stop", "start" 방식으로 종료 후 시작 시점을 제가 컨트롤 하고 싶을 때만 사용합니다. 즉시 재시작일 경우에는 마지막으로 소개할 방법을 사용하죠.

Rollout restart 명령어 사용#

kubectl rollout restart deployment <deployment-name>

저의 최종 종착점입니다. 사실 rollout 명령어를 쿠버네티스를 꽤 오랫동안 쓰고나서 알게 되서... 역시 지식이 부족하면 몸이 고생하는 법이죠. 저 명령어를 사용하면 파드를 재시작해줍니다. 다만 위에 방법처럼 단순히 파드를 삭제하고 시작해주는 것으로 끝나는게 아닙니다. 여기서 자세히 다루지는 않겠지만 서비스에 replica 수가 늘어나게 되면 배포 전략에 대해서 고민을 하게 되고 디플로이먼트에 설정하는 아래 설정을 하게 될텐데요.

spec:
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  type: RollingUpdate

이 전략에 맞춰서 재시작을 해줍니다. 간단하게 설명하면 이 방법 위에서 언급한 방법들은 순간적으로 모든 파드를 재시작하게 되지만, rollout restart 는 사용자가 설정한대로 순차적으로 파드를 재시작하게 되는 것이죠. 무중단 재시작을 위해서라면 필수적이라고 볼 수 있습니다.

마치며#

지금까지 서비스를 재시작하는 방법들을 알아보았습니다. 사실 rollout restart 을 초기부터 알았으면 좋았겠다 싶어서 다른 분들에게 소개하고자 쓴 글이지만, 제가 지금까지 사용했던 방법들을 되새겨보면서 각 방법들에 장단점도 정리하고 싶었습니다. 혹시 또 다른 방법이 있을까요? 여러분들은 어떤 방법을 사용하시나요? 현재 댓글 기능은 없지만... 어떤 방법으로든 의견주세요 😋

Java version 업그레이드 주기는?

August 8, 2021 · 3 min read

자바 8로 개발을 시작하고 지금까지 쭈욱 8로 개발을 하고 있습니다. 개인 토이 프로젝트는 예전부터 11로 작성해왔고 , 실무에서도 새롭게 시작하는 프로젝트들은 11을 사용하고 있지만, 자바 8로 이미 개발된 프로젝트들은 벌집을 건드리는 꼴이 될까봐 업그레이드 하지 못하고 있죠. 뭐 조만간은 반드시 해야 할 일이긴 합니다.

최근 프로젝트를 생성하다보면 14버전이나 그 상위 버전을 선택할 수 있게 되는 경우가 있습니다. 잠깐 이 버전들은 얼마나 지원되는 것일까요? 최신 버전이라고 마냥 올리는게 정답일까요? LTS 가 되는 11 다음 버전은 몇 일까요? 함께 알아봅시다.

Just before the release of JDK 9, Oracle made a number of announcements about how the development, distribution and updating of Java would work moving forward. Rather than the multi-year, feature-driven release cycle, there are now two releases of Java each year. The dates of these are fixed (March and September) and include only the features that are ready at that time. - What Does Long-Term Support Mean for OpenJDK?

This faster release cadence would rapidly make providing extended support impractical, so Oracle said they would designate specific releases of the Oracle JDK binary as having long-term support (LTS). JDK 8 was designated with LTS to get things started, with JDK 11 being the first LTS release under the new model. LTS releases would then occur every three years (so every sixth JDK release).

위 내용은 간단하게 정리하면 다음과 같습니다.

매년 두 번 릴리즈, 날짜는 3월이랑 9월
11 버전이 자바 8 이후로 첫번째 LTS
LTS 릴리즈는 3년마다 발생, 6개월 마다 업데이트 되는 버전이 6번 올라갈 때마다 임
따라서 다음 LTS 릴리즈는 17

조금 더 생각해보면...

LTS 가 아닌 버전은 고작 6개월 지원... 6개월 뒤에는 버그 나오면 알아서 해결해야 함 😳
2021년 9월에 다음 LTS 릴리즈인 17 이 나올 예정
한달 남았다? (좀 더 참고 있다가 17 쓸까...)
앞으로 대충 21년 더 자바를 쓴다 치면... 7 번에 LTS...
그럼, 11, 17, 23, 29, 35, 41, 47 가 LTS
21년 뒤면 아이폰 32 가 나올려나... 갤노트는 31
자바 17 이후 버전 쯤이면 Golang 쓰고 있지 않을까?

일단 다음 New Project 버튼 누를 때는 17 나오기 전엔 무조건 11 로 만들다가, 곧 17 이 나오면 17 로 만들어야겠네요. 그리고 8 → 11 → 17 보다는 8 → 17 로 한번에 마이그레이션 하는게 더 좋을 것 같습니다. 물론 무조건 버전을 올리기 보다는 각 버전에서 개선된 점은 무엇인지, 무슨 이유로 그렇게 개선하게 된 것인지를 아는 것이 더 중요하겠지요. 조만간 다음 버전에서 추가된 기능을 정리해봐야겠어요.

참고#

TIL-20210610

June 10, 2021 · 2 min read

RDS 인스턴스 사이즈 변경#

RDS Aurora Mysql 인스턴스 사이즈 변경시 변경 대상이 쓰기 데이터베이스라면, 읽기가 쓰기가 되는 FailOver Time 동안 쓰기가 일시적으로 중단되며 그 기간은 약 30초 정도 소요된다.

RDS 인코딩 변경#

파라미터 그룹 내 아래 설정값을 변경한다.

character_set_client: utf8mb4
character_set_connection: utf8mb4
character_set_database: utf8mb4
character_set_filesystem: utf8mb4
character_set_results: utf8mb4
character_set_server: utf8mb4
collation_connection: utf8mb4_general_ci
collation_server: utf8mb4_general_ci

확인하기

show variables like 'c%';

인코딩 직접 변경하기

alter database [DATABASE_NAME] character set = 'utf8' collate = 'utf8_general_ci';

RDS 느린 쿼리 로그 설정#

RDS 설정에서 느린 쿼리 로그 를 체크하였다고 느린 쿼리 로그가 CloudWatch Logs 에 쌓이지 않는다. 파라미터 그룹에서 slow_query_log 를 true(1) 로 변경해주어야 한다.
느린 쿼리에 판단 기준 역시 파라미터 그룹에서 지정할 수 있으며, long_query_time 를 수정하면 된다. 기본값은 10초.
log_queries_not_using_indexes 을 1 로 변경하면 인덱스를 타지 않는 모든 쿼리를 느린 쿼리로 기록한다.

참고#

AWS Docs - MySQL 데이터베이스 로그 파일

No appropriate protocol (protocol is disabled or cipher suites are inappropriate)#

Caused by: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
    at sun.security.ssl.HandshakeContext.<init>(HandshakeContext.java:171) ~[na:1.8.0_292]
    at sun.security.ssl.ClientHandshakeContext.<init>(ClientHandshakeContext.java:98) ~[na:1.8.0_292]
    at sun.security.ssl.TransportContext.kickstart(TransportContext.java:220) ~[na:1.8.0_292]
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:428) ~[na:1.8.0_292]
    at com.mysql.cj.protocol.ExportControlled.performTlsHandshake(ExportControlled.java:317) ~[mysql-connector-java-8.0.23.jar:8.0.23]
    at com.mysql.cj.protocol.StandardSocketFactory.performTlsHandshake(StandardSocketFactory.java:188) ~[mysql-connector-java-8.0.23.jar:8.0.23]
    at com.mysql.cj.protocol.a.NativeSocketConnection.performTlsHandshake(NativeSocketConnection.java:97) ~[mysql-connector-java-8.0.23.jar:8.0.23]
    at com.mysql.cj.protocol.a.NativeProtocol.negotiateSSLConnection(NativeProtocol.java:333) ~[mysql-connector-java-8.0.23.jar:8.0.23]
    ... 91 common frames omitted

참고#

도큐사우루스로 블로그 시작

December 17, 2020 · 2 min read

설치하기#

https://v2.docusaurus.io/docs/installation/

npx @docusaurus/init@latest init dezang.net classic

cd dezang.net
yarn start

빌드하기#

yarn build

This command generates static content into the build directory and can be served using any static contents hosting service.

배포하기#

도큐사우루스는 아래와 같이 배포를 가이드합니다.

GIT_USER=<Your GitHub username> USE_SSH=true yarn deploy

처음에는 자연스럽게 github page 를 사용하려고 했지만, 좀 더 성능이 좋은 (블로그에 무슨 성능 타령인지... 직업병이란...) 서비스가 없을까 찾아보던 중 비교 정리를 잘해놓은 nextJS 뭘로 배포할까? (Netlify, Vercel, Github page) 을 보고 결정했습니다. 해당 글에 달린 댓글이 결정에 중요한 요소가 되었는데요.

깃허브 Netlify에 비해 Vercel의 특장점은 유일하게 서울에 CDN이 있다는 것입니다. Vercel의 경우 국내에서 TTFB가 30~40ms 로 최상급서버의 성능을 느낄 수 있습니다!

실제로 vercel에 경우 Vercel Docs-Edge Network-Regions 페이지를 보면 Seoul, South Korea 가 당당히 자리잡고 있는 것을 확인하였습니다. 반면 Netlify 는 Netlify for Business 플랜에만 27 global edge locations 라고 명시해놓았을 뿐 프리 버전에 엣지가 어디에 몇 개인지는 비공개로 해놓았죠. 한글로 된 글이 대다수인 해당 블로그는 한국 엣지를 가지고 있는 것이 성능상 이점이 높을 것이라고 생각하여 이전에 써본 적은 없지만 vercel에 배포하기로 결정했습니다.

깃허브 로그인 후 몇 가지 설정만하면 바로 배포가 되었고, 커스텀 도메인도 아주 쉽고 빠르게 적용할 수 있었습니다. 무엇보다 Let's Encrypt 에서 SSL 인증서를 자동으로 발급받아서 적용해주는 것도 좋았네요.

Recent posts

개요#

포트폴리오를 공개하는 이유와 주의사항#

포트폴리오 공개#

지금까지 투자 원칙?#

내가 가지고 있는 생각#

앞으로의 계획#

마치며#

개요#

정리되지 않은 작업 환경#

너무 친절한 인텔리제이#

만능 단축키 CMD+SHIFT+A#

보너스 최근 프로젝트 열기#

마치며#

개요#

시작하기 전에#

간단한 샘플 API 구현#

OPENAPI SPEC 문서 생성#

스펙 문서 활용하기#

마치며#

개요#

SPRING REST DOCS 과 OAS 조합이 필요한 이유#

계속해서 늘어나는 API 서버와 분산되는 API 문서#

어떻게 하면 사내에 있는 모든 API 를 한 곳에서 볼 수 있을까?#

그래, 관건은 API Specification.#

스웨거를 다시 써야 할까?#

Rest Docs 이 Open API Spec 을 떨궈줄 수만 있다면.#

마치며#

들어가며#

간단하게 시작하기#

개발 환경 구성#

외부 리소스 가져오기#

API 문서 확인#

사용할 패키지 찾고 문서 확인하기#

마치며#

개요#

생각의 흐름대로 적는다.#

글의 구성#

140자#

생각이 날라다닌다.#

내가 무언가를 학습하는 방법#

무노동월이천#

마치며#

개요#

파드 삭제#

디플로이먼트 삭제 후 재생성#

디플로이먼트의 Scale 을 변경#

Rollout restart 명령어 사용#

마치며#

참고#

RDS 인스턴스 사이즈 변경#

RDS 인코딩 변경#

RDS 느린 쿼리 로그 설정#

참고#

No appropriate protocol (protocol is disabled or cipher suites are inappropriate)#

참고#

설치하기#

빌드하기#

배포하기#