설 연휴가 지나갔다. 무려 9일이나 되는 길이였지만 체감상 0.9초 정도 되는것 같다. 잘 쉬었나 되돌아보다가 갑자기 이런 생각이 들었다.

무엇이 휴식인가? 혹은 뭘해야 또는 안해야 휴식인건가.

구글에 휴식 이미지 검색하면 자연에서 책을 읽거나 바다에서 누워있는 걸 볼 수 있다. 아무것도 안하고 가만히 있어야 휴식이라는 기사도 있고.

최근 슈카월드 영상과도 연관이 되는데, 설문조사에 따르면 한국인은 집에서 혼자 쉬는것을 가장 선호하는 반면 외국, 서양에서는 가족과 보내는 시간을 가장 선호한다고 한다.

내가 느꼈던 유럽, 서양인은 개인주의였고 한국인은 돈보단 사람, 지폐보단 정이였는데.

*뛰어난 개발자는 개인 프로젝트를 하며 휴식을 하려나? 라는 생각에서 출발한 질문인데 좀 멀리오긴 했네. *

"좀 쉬어. 고생했어" 라는 말을 듣고 "아 힘들었다. 어제 하던거 좀 하다 자야지" 하면서 코딩을 하진 않을것 같다. 아니 재밌긴 한데.. 뇌가 쉴시간도 줘야지

(스쳐 지나가는 "에어컨도 쉴시간 좀 줘야지" 하며 에어컨을 끄시던 어머니)

축구선수들도 비수기땐 축구게임 하던데 그치? 내가 이상한거 아니겠지.

연휴 끝, 할건 해야지

이제 할건 해야지!

인텔리제이로 사이드 프로젝트 개발을 이어오다보니 드는 생각이

유료버전에서는 DB 스키마도 다 확인할 수 있었는데, 무료버전은 그런게 없다.

그렇다고 큰맘먹고 지른다?? 무료버전이 있는데 산다는건 사치 같은 생각이 들었다.

(축구는 일주일에 한번하면서 축구화는 10만원 짜리 턱~턱 사면서, 코딩은 맨날 6시간 7시간 하면서 이게 돈이 아까워?? 축구화 사면 축구 실력이 느는것도 아닌데, 인텔리제이 유료는 효율성 차이가 말도 안되는데?)

이렇게 생각하면...흠.......환율..조금 잡히면 바로 사야겠다... 이럴거면 처음부터 샀지!

그 전까지는 도커 cli로 조회하는건 무리가 있어서 관련 툴을 설치해서 쓸 예정이다. 비버 아이콘 귀여운 DBeaver. 설치 하는 법은 인터넷에 넘치니까 사용해보고, 편한점, 불편한점 따로 서술하겠다.

오래 쉬었으니, 목표 설정 Reminder

내가 사이드 프로젝트 개발하는 것을 정주행 하는 사람은 없겠지만, 내가 지금 길을 잃을 판이니

설정해둔 목표와 기획을 상기시켜야 할 것 같다.

테스트 성공 했잖아 한잔해~

개발자로서 첫직장은 사회적인 엄마라고 본다. 적어도 나한텐. 학교에서 배우던 자바는 너무나 기초적인 것이고 회사에서 스프링부트를 배우면 어렵다. 선배를 보며, 선배의 기록을 보며 성장해 나간다. 그 첫직장의 문화는 자연스레 내 문화가 된다. 다른사람들은 모르겠지만, 그 문화가 이성적이고, 내 가치관에 맞는다면 자연스럽게 받아드렸던것 같다.

내 첫직장을 인턴으로 다닐때 아주 감사한 분들이 주위에 계셨는데, 그분들이 같은 회사에 개발자로서 전환하는것을 말렸었다.

안좋은 회사니까 다른데 가라는 뜻이 아니라. 사회에 나와서 엄마가 될 회사를 고를 기회가 있는데, 그 기회를 버리지 말라는 것을. 그 뜻을 4년이 지난 지금에야 이해했으니, 나도 배풀며 살아야겠지. 감사한 마음 가지고.

이야기가 멀리 돌아왔지만 나는 테스트 없는 개발팀에서 일했고, 지금 생각하면 아쉬운 점은 그뿐이다. 그래서 지금부터 테스트 하는 습관을 들일것이다.

과거의 나는 아주 안타깝게도 JUnit테스트 같은거 안했다.

물론 개발서버에서 동작 테스트, Use-case를 통해 통합테스트는 했다.

"Postman으로 쏴보고 에러 안나면 테스트 아닌가?" 이딴 마인드로 살아와서 단위테스트가 너무너무 불편했다.

JUnit5랑 Mockito를 사용한 후기를 말해주자면

기능 개발 -> controller / service / repository 싹다 구현 -> 산더미처럼 밀린 유닛테스트 숙제마냥 몰아서 작성 -> 테스트 구현 및 실행 -> 아 이거 방향이 이게 아니구나 -> 기능 수정 -> 단위 테스트 수정 -> 무한 반복

지쳐 쓰러져...

-> 테스트 코드부터 짬 -> 뿌듯

단위테스트 작성을 해보고 알게된 장점

개발자라면 당연히 기능 개발하고 뒤엎은 경험이 있을 것이다. 뒤엎는 상황까지는 아니더라도 영향도가 높은 수정?

그럴때 단위테스트가 빛을 발한다.

단위테스트로 정상 케이스 비정상 케이스 엣지 케이스등 정의 해서 통과 시켜놓고, 리팩토링 할때 다시 단위테스트 Run 누르면 끝!

전에 작성해둔 단위 테스트가 최소한의 안전장치로서 누락된 조건 확인이나 Null 미 체크 등을 방지시켜준다.

아직 배울게 많습니다

나도 이제 테스트에 통달했다고 할수 없다. 어디까지 테스트를 작성해야하는거지? 라는 고민이 많다.

고등학교 때 수학선생님이 해주신 말이 있다.

수학에 인생을 바쳐서 연구하면 그 끝은 철학과 비슷하다. 학문의 관점으로 봤을때 수학과 철학은 닮은 점이 아주 많다.

먼저 이과적, 개발자적으로 보면 비슷한건 맞아보인다. 둘다 자연이 아닌 사람이 만든 개념을 연구하는 것이니.

고등학교 때 수학을 좋아하고, 철학을 싫어했던 입장으로선 의아했다. 수학 공식의 원리를 이해했을때 그 짜릿함, 그리고 그 공식으로 문제를 성공적으로 풀때 그 짜릿함이 있다. 마치 검법의 묘리를 깨우치고 신검합일의 경지에 올라 적수가 없을때 느낌이랑 비슷할까?

하지만 대학을 가서 그 짜릿함은 온데간데 찾을 수가 없었다. 공식을 대입해서 푼다기 보다, 개념을 이해하고 연관되는 개념을 추론하는 형식에 가깝게 느껴졌다. 그 순간 그 선생님의 말이 생각났다. 이런 뜻이구나. (그래서 데카르트가 수학자 이자 철학자 였을까?)

다시 원점으로 오자면

이런 심오한 이야기로 블로그를 시작한 것은, Kafka를 공부하면서 점점 더 이해가 안되는것 같아서 그렇다. 아! 브로커 내부에선 이렇게 파티셔닝 하고 리벨런싱도 하는구나? 그럼 새로운 파티션 배정받으면서 메세지 유실이 어떻게 없는거지..? 잠깐 근데 파티셔닝 할때 Round Robin 방식으로 하는데, 컨슈머 하나가 파티션 하나를 읽으면 메세지 몇개 빠지는거 아니야? ?????

당연히 아니고, 내가 잘못 이해한거겠지만, 더 찾아봐야겠다..어렵다

저번 글에서 다시 시작합니다!

저번 글과 연관되서 시작하자면 본격적으로 기본 프로젝트 뼈대를 잡고, 주요 클래스는 선언한채로 kafka 설치에 전념했다.

먼저 내 컴퓨터 환경에서!

Kafka 2.13-3.9.0을 현제 윈도우 환경에 설치하고, Kafka-console-consumer.bat /Kafka-console-producer.bat 를 통해 테스트도 했다.

그리고 springboot에서 kafka 의존성 추가해주고.. producer는 kafka 연결된 로그는 보이는데... consumer 쪽은 죽어도 연결이 안된다.

혹시 구현되있는 서비스가 빈으로 등록이 안된건지.. @service에서 @component로도 바꿔보고 groupId도 삭제해보고..문제가 안보인다.

그렇다면.. 어짜피 kafka는 docker통해서 띄우려고 했으니까! 윈도우 환경에서는 그만 하고, docker 사용하자.

근데 여기서

Docker로 띄우면 되겠지 생각했지만 찾아보면 다들 docker compose를 사용한다. 왜?

"" 도커(Docker)는 소프트웨어 컨테이너 기술을 제공하는 플랫폼으로, 애플리케이션과 그 의존성들을 격리된 환경에서 실행할 수 있게 해준다. 이를 통해 애플리케이션을 효율적으로 개발, 배포, 및 실행 가능 도커는 다양한 운영 체제 및 클라우드 환경에서 동일한 방식으로 동작하므로 개발 환경과 프로덕션 환경 간의 일관성을 제공 ""

Docker Compose: Docker container를 여러개 관리할때 사용!

우린 kafka 하나만 쓸건데? 아니다. zookeeper도 같이 띄우기에 docker compose다.

결국 Docker 로 카프카 설치 성공!

이렇게 API로 테스트 진행하고,

받는 측에서도 로그 확인!

이 단순한 로그 보려고 온간 삽질을 했었는데, 너무너무 바보같은 실수라서 공유하기는 부끄럽다. 디버깅 팁을 주자면 Kafka Consumer가 로그가 안찍히고, .bat 파일에서 cli로 테스트 했을때는 잘된것이라면, Consume config 파일이 Bean 등록이 됐는지 확인해보자...

조그마한 사이드 프로젝트에서 유용하게 사용하여 공유할 수 있는게 있다면 공유 하겠다.

카프카에 대한 설명 정리 잘되어있는 곳!

분산형 스트리밍 플랫폼, 대규모 스트리밍 데이터를 주고받는데 특화되어있다.

너무 좋은 글과 작성자를 발견했다. 영어로 되어있는데 요즘은 번역도 잘 되니까 강추!

어렵지 않은 영어를 사용하셔서 읽을만 하다

https://www.linkedin.com/pulse/kafka-consumer-overview-sylvester-daniel/

https://www.linkedin.com/pulse/kafka-producer-overview-sylvester-daniel/

이분의 글도 너무 잘쓰시고 이해가 잘되어 공부하는데 많이 참고가 되었다! https://medium.com/@greg.shiny82/%EC%8B%A4%EB%AC%B4-%EA%B4%80%EC%A0%90%EC%97%90%EC%84%9C%EC%9D%98-apache-kafka-%ED%99%9C%EC%9A%A9-023d468f9182

오늘의 삽질

Eureka와 API Gateway를 이용해서 게이트웨이의 port를 통해 microservice까지 이어지게끔 테스트 하던 도중

yml로 라우팅을 시도하면 안되고, filterconfig 파일 생성 및 gatewayRoutes 함수로 자바단에서 라우팅하면 정상 작동하는 점을 발견,

왜안되지 삽질을 많이 했는데,

yml에서 spring 아래 indent로 cloud를 써야하는데,

예시 :
spring 
    application:
        name:
    cloud:

에러 예시:
spring 
    application:
        name:
        cloud:

이렇게 indent되어있는것을 확인 못하고 몇일을 삽질했다..

이제 kafka 를 구현할 차례!

Why Kafka? 필요한가요?

MSA 구성에는 마이크로 서비스가 각각 구성되어 빌드되고 배포되기 때문에, 실시간 처리가 가능하고, 스케일아웃에도 유연하게 대비되는 대규모 메시징 시스템이 필요.

우리는 유레카 서버를 이용해서 MSA를 구축했고, 유레카의 스케일아웃에도 대비해야하니 RabbitMQ보다 Kafka가 적합.

하지만 카프카를 구현하기 이전에 어디에 필요한지 알아야 하겠지?

When and Where?

이 대답을 하려면 내가 궁극적으로 어떤 시스템을 구현하고싶은지 정의해야한다.

나는 자동 매매 시스템, 모의 투자 시스템을 구현하고싶다.

원래 내가 구현하고싶은건 두가지였는데

1. 빗썸 api 활용하여 원클릭으로 내가 코인 투자.
2. 1번을 나 한정이 아닌 모두가 활용 할 수 있도록

예를 들어 crontab으로 1분마다 시세 조회 후 내가 설정한 가격 이하면 매수 급락 기준 설정, 바닥이 아니라 반등 기준 후 매수 설정 과 같은 로직?

시작된 고뇌...

음..아무리 사이드 프로젝트라고 하더라도 무작정 개발부터 하는게 맞나? 기획으로 먼저 정의되어야 하는것 아닐까..?

라는 생각이 자꾸 든다..

일단 실행에 옮기자! 화면 기획서든 문서든 하기 싫은거에 빠져서 포기하지 않도록. 구현해보고 아 이게 필요하겠다 라고 써둔 메모가 쌓여서 기획문서가 될 수 있잖아?

일단 코딩이 하고싶고 kafka가 찍어주는 로그를 얼른 보고싶으니까!

KafKa 시작!!은 아니고 Spring boot 복습

유저ms를 구현하던 중, Spring boot 디렉토리 구조라던지, DAO, DTO, VO, Entity, Repository 이런 엔티티에 대해서 확실하게 정리하고 넘어갈 필요가 있다고 생각이 들었다. 전에 회사에서는 VO를 DTO이자 Entity로 사용했기 때문에 좀 달라질 필요가 있다.

DTO Data Transfer Object

• 계층간 데이터 교환 위한 객체, 로직 미존재, getter setter만 존재.

VO Value Object

• Read only 속성을 가지며 값을 표현하기 위한 객체 (예시 private final int response_ok = 200)

DAO Data Access Object

• DB 데이터에 접근위한 객체

카프카를 통해 DTO, DAO, Entity, Repository 다 구현해야하고 직접 접해보니까 이해가 더 잘된다.

전 회사에서는 DAO와 VO만 존재했다. 사실 VO라고 써놓긴 했지만 Read only 속성도 없이 .setOOO()하면서 사용해서 다시 공부하면서 더 햇갈린것 같다. 그래서 이번엔 JPA를 사용하다보니 domain, repository, entity 등 잘 구분해서 쓸것이다!

하지만 각자 목적을 위해 비슷한 변수를 가지고 있는 OrderDto, OrderResponse, OrderRequest 등을 다루다 보면 이쪽에서 꺼내와서 저쪽에 넣고 setOrderId(order.getOrderID())를 평생 할 순 없다. 그래서 ModelMapper를 사용하더라! 주요 장점은 가독성 증가, 실수 방지! 완전 유용하자나.

ModelMapper는 의존성을 따로 추가해주어야 사용가능하다

dependencies{
  ...
  implementation 'org.modelmapper:modelmapper:3.1.0'
}

UserMapDto userMapDto = mapper.map(user, UserMapDto.class);

하지만 때에 따라서 좋게 좋게 넘어가면서 매핑이 필요할때도, 또는 이름과 타입이 동일해야만 매핑이 필요할때도 있겠다. 따라서 3가지 전략이 존재한다.

modelMapper.getConfiguration().setMatchingStrategy(MatchingStrategies.STANDARD) // STANDARD 전략 modelMapper.getConfiguration().setMatchingStrategy(MatchingStrategies.LOOSE) // LOOSE 전략 modelMapper.getConfiguration().setMatchingStrategy(MatchingStrategies.STRICT) // STRICT 전략

여기서 우리는 Strict를 사용한다. 타입과 필드명이 같으므로!

자세한건 여기서 찾아보면서 공부했다! https://devwithpug.github.io/java/java-modelmapper/

Dto, Repository, Entity

인터넷을 찾아보면 찾아볼수록 햇갈리기 시작하지만.. 정보를 정제하고 이해하면서 명확해지기 시작한다. 관심사의 분리가 필요하니 DTO와 Entity는 분리가 필요하니 DTO는 따로 구현을 할 것이다.

Entity와 Domain에 대해서 햇갈리기도 하고, 블로그 마다 해석이 다르다. 둘다 DB 테이블과 1대1 매칭되는 객체이지만 명명 방식이 다른것 같다. 나는 프로젝트 구조와 연관이 있다고 이해했다.

도메인형 구조를 띄고 있다면 Entity, 계층형 구조를 띄고 있다면 해당 객체들이 한 폴더안에 몰려 있으므로 도메인의 집합이 맞다고 생각해서 Domain.

나는 규모가 크지 않고, 특히나 MSA로 구현되어 멀티레포로 관리되기 때문에 도메인형 구조를 택할 이유가 없어 계층형 구조를 선택했고, 따라서 Domain으로 명명 및 구현할 것이다!

config
controller
service
dto
    ㄴ UserDto.java
repository
domain 
    ㄴ User.java
    ㄴ BlackList.java

이렇게!!

프로젝트의 구조와 네이밍 규칙은 내 가치관에 따라 정의를 하고 해석을 해 두었으니! 이제 정말 카프카를 구현해야겠지...

다음 장에서 계속...

개발하는 대로 글을 써서 늘리고 싶지만 그렇다고 스크롤 두번만에 끝나서 아쉬운 글을 쓰고싶지 않아서 진도가 좀 나가면 글을 쓰고 있다.

이 블로그의 주된 목적은..

내가 프로젝트를 하면서 개발 내용을 공유함과 동시에 내가 배우는 것도 있지만 이 글을 읽을 독자들에게 하여금 나같이 부족한 개발자도 맨땅에 삽질하면서 개발 할 수 있다는 것을 보여주며 자신감을 주고싶다.

그래서 이 블로그는 난 이만큼 알아!!라는 자랑보다는 난 이것도 몰라!!라는 한탄글도 많을것이고 모르는것, 이해 못한것, 그리고 찾아보지 않고 일단 해본것 모두 날것 그대로 글에 녹일 예정이다.

그럼 오늘도 시작해보자.

근데 나만 그런지 모르겠는데, 글로만 보면 난 잘 이해가 안된다. 어렸을때 부터 수학도 그랬는데 직접 풀어보고 다시 봐야 이해하는것 같다.

그래서 MSA를 이해하기 위해서 이렇게 프로젝트를 시작한다. 내 프로젝트에 들어갈 기술스텍을 완벽히 이해하지 못하더라도 일단 구현해보고 비효율적이거나 내가 원하는 목적에 부합하지 않으면 과감히 버린다. 내 사이드 프로젝트의 목적은 배움에 좀더 가까우니까!

목표

구현할 서비스로는

1. 사용 가능할 것
2. 충분한 수준의 보안을 갖출 것
3. 나에게 하드코딩 되지 않고 누구나 사용 가능할 것.
4. 내가 흥미를 잃지 않을 주제일것

기술 스택

kafka, JWT, Spring Security, ELK stack, PostgreSQL + JPA Spring Cloud

위의 기술 스택 선정의 가장 첫번째 요소는** 내가 사용해보지 않았다는 점**이다.

나는 백엔드 업무 당시 Vert.x 기반의 여러 Endpoint를 보유하고 있는 API 플랫폼을 운영개발했고, 특정 모듈의 오류가 잦아서, 그외 모듈까지 영향을 줄 수밖에 없는 긴급 작업들을 많이 했다.

중요도가 낮은 모듈의 오류로 인해 높은 중요도의 모듈까지 영향을 주는것을 보고 모듈이 독립적으로 동작, 배포 및 관리된다면 좋을 것 같다 라는 생각이 들었지만, MSA를 접하고 공부한 것은 퇴사 후였다.

프로젝트 개요

모의 투자 서비스. 이름은....코인 WWE? 가상자산 가상투자? 좀더 생각해봐야겠다. 1안 : 얼마에 사? 2안 : RE: 제로부터 시작하는 코인매수 3안 : 머리 어깨 무릎 매수!

12월 3일 23시에 일어났던 일과 평소에 즐겨하는 게임 FC ONLINE을 통해 영감을 받았는데,

모두들 코인 커래소, 주식 어플 또는 FC ONLINE 이적시장을 이용해봤다면 해본 생각이 있을 것이다.

"아..이가격에 샀으면 지금 얼마 벌었냐.." 또는 "아 이가격에 팔았으면 반절이라도 건지는건데..." 이걸 해볼거다.

기본적인 베이스는 거래소 API(빗썸+ 두나무)를 통해 코인 정보를 조회 및 노출, 그리고 특정 가격대에 매수를 걸거나 매도를 걸고 채결됐을때 실현손익 노출, 그리고 기회비용 노출?

예를 들어 1000원에 산 코인을 지금 2000원에 매도를 걸었다고 치자. 코인은 파죽지세로 올라가며, 2000원에 매도 채결이 되었고 현재 가격은 20,000원이다. 노출되는 정보는 실현손익 1000원(100%), 안팔았다면 수익(19,000원)(2000%)

뭐 이런식으로.. (아직 아이디어 부족해요...더 추가할거에요...)

1부 - 모의 투자 2부 - 실제 투자 3부 - AI 모델 삽입. <- 이건 추천 모델?

https://chobopark.tistory.com/480 요골 활용해서 추천하는 AI 모델 fine-tune 해서 써보자!! 재밌겠다. (확실히 AI가 들어가면 재밌어 보이네)

필요 기능

회원가입 및 로그인 예약 매수/매도 (가상) 가격 알림 서비스(근데 어디로? 카톡? 팝업?) 등등등.. 추가예정..

MSA할거라면서? 뭘 띄울건데?

_맞네..나 MSA 한다고 했지 _

독립적으로 띄워질 서비스 :

Eureka Server

• 각각의 서비스 application을 관리해줄 service discovery 기능.

Front:

• 사용자에게 보여질 화면을 담고있는 서비스

API Gateway:

• 로드벨런싱 및 라우팅을 도와줄 게이트웨이

Micro Services:

• 독립적으로 관리되고 배포될 핵심 비즈니스 로직을 담고있는 서비스들.
• 물론 DB도 따로! (내 수준의 프로젝트에선 상당히 비효율적이겠지만 msa 트랜젝션 롤백 전략 구현해보고싶다. )

우리는 여기서 Spring Cloud 의 서비스 디스커버리 기능을 제공하는 유레카와 그의 클라이언트 역할을 해줄 API Gateway를 사용할 것이다!

서비스 아키텍쳐!

첫발을 떼자!

Eureka 서버가 될 프로젝트에 필요한 dependencies 추가하고 micro service가 될 프로젝트 하나, API Gateway가 될 프로젝트 하나씩 해당 서버에 연동하여 위와같은 화면이 완성된다!

Spring Actuator 도 추가해서 status 클릭하면 해당 결과 확인 가능하다.

{
  "_links": {
    "self": {
      "href": "http://localhost:7000/actuator",
      "templated": false
    },
    "health": {
      "href": "http://localhost:7000/actuator/health",
      "templated": false
    },
    "health-path": {
      "href": "http://localhost:7000/actuator/health/{*path}",
      "templated": true
    }
  }
}

다음은....Postman을 이용한 테스트, 그리고 kafka 까지 설치해서 테스트 해봐야겠다!

사이드 프로젝트를 시작하면서 github 연동과 이 둘을 사용하기로 했다.

하지만 ultimate 구매를 안하고 IntelliJ CE를 사용하니 셋팅할 것이 한두가지가 아니다.

이 블로그와 위키독스에서 많은 도움을 받았다!

https://sundries-in-myidea.tistory.com/147 https://wikidocs.net/164891

셋팅 성공적! 완료!

이제 기획과 개발을 시작해볼까??

글 쓰기 위해 네이버도 가보고 tistory도 가보고 velog에 왔다.

하지만 velog 랜딩페이지에 뙇 하고 나오는 트랜딩 카테고리의 글들.. "이런 대단한 필력이나 실력을 가지고 있는 사람들이 하는것인가..?" 라는 주눅이 든다.

사실 회사에서도 신입으로써 처음 배울때 비슷한 생각이 들지만 사수, 선배 개발자, 팀장 모두 귀여운 새싹일 시절이 있을 것이다. 마음을 다잡고 시작해본다.

사이드 프로젝트의 시작.

사실 지금 데이터 사이언티스트로 이직하고 사이드 프로젝트로 Swift기반의 앱을 만들려고 했다. (이것 때문에 맥북 삼)

근데 아직 내가 심장 뛰는건 JAVA이고 스프링이고 서버 개발인가 보다. 첫직장에서 백엔드 개발자로 spring boot를 많이 접하고 덤덤해질때도 됐지만 그때도 지금도 아직 설렌다. 뭐랄까.. 놀이공원 들어가기 직전의 4살 아이와 같이 "재밌을꺼같애!!!"라는 느낌?

그래서

결국 사이드 프로젝트도 Spring boot 기반의 api 서버를 만들기로 했고, 요즘 공부하고 있는 MSA 기반으로 만들려고 한다.

기술 스택

추가하고 싶은 기술 스택은 정말정말 궁금하고 써보고 싶었던 kafka 와 ELK 스택. 그리고 JPA와 우아한 기술블로그에서 영감을 항상 얻는 객체지향적 마인드.

환경

개발 환경은 JAVA 11이상을 쓰려고 하고, IntelliJ CE 에 Spring Boot를 쓰려고 했는데 많은 블로그들이 말리는 소리가 들린다... Ultimate를 경험한 나는 하루에도 몇번씩 내적 비명을 지를 각오를 하고 시작하지만 Ultimate 가격을 보고나면 사그러들지 않을까?

API 플랫폼의 목적이나 무엇을 구현해보고 싶은지 결정 되면 또 쓰러 오겠습니다.

아무도 안 읽어 줄 블로그지만! 한번씩 응원해주시면 정말 큰 힘이 되겠네요.