요즘 스프링으로 개발을하고있는데, 학습한 내용은 많으나 정리할 시간이 없다는 핑계로 이제서야 짤막한 정리글을 스멀스멀 올리려하고있다. 본문에서는 기본적인 isolation 레벨이나 이외 DB 에 관련된 개념보다는 간략한 스프링에서 트랜잭션 처리를 다루고 있다. 스프링에서 트랜잭션 처리를 위해 선언적 트랜잭션을 사용한다. 선언적 트랜잭션 방법에는 설정 파일 또는 어노테이션 방식으로 간편하게 트랜잭션에 관한 행위를 정의할 수 있다. 본 문서에서는 @Transactional 어노테이션을 기준으로 다루겠다. 트랜잭션은 Spring AOP를 통해 구현되어있다. 정확하게 말하면, 어노테이션 기반 AOP 를 통해 구현되어있다. import org.springframework.transaction.annotation.Transactional; 따라서 아래와 같은 특징을 가지고 있다. 클래스, 메소드에 @Transactional 이 선언되면 해당 클래스에 트랜잭션이 적용된 프록시 객체 생성 프록시 객체는 @Transactional 이 포함된 메서드가 호출될 경우, 트랜잭션을 시작하고 Commit 또는 Rollback 을 수행 CheckedException 또는 예외가 없을 때는 Commit UncheckedException이 발생하면 Rollback 또한 주의점으로 @Transactional 은 우선 순위를 가지고 있다. 클래스 메서드에 선언된 트랜잭션의 우선 순위가 가장 높고, 인터페이스에 선언된 트랜잭션의 우선 순위가 가장낮다. (우선 순위는 아래와 같다.) 클래스 메소드 -> 클래스 -> 인터페이스 메소드 -> 인터페이스...

본 문서는 거창하지만 Typescript 를 통한 프로덕트 개발 A - Z 까지의 함축된 개발 과정을 담고 있다. 글을 작성하게 된 계기는 개발을 막 시작하는 이들이 전체 프로덕트 개발 프로세스를 모르기에 느끼는 고충을 같은 주니어 개발자인 본인이 그나마 일전 운좋게 프론트와 백엔드를 개발한 경험을 통해 조금의 가이드 라인을 제공해줄 수 있지 않을까 하는 작은 바램에서 시작되었다. 다소 많은 내용을 함축하여 담아야하는데, 큰 맥락에 대한 이해를 주 목적으로 두고 있기에 용어와 개념에 대한 좀 더 상세한 내용은 관련 레퍼런스를 참고하길 바란다. 덧붙여 본 문서가 타입스크립트에 맹신론으로 비춰질까 걱정이 앞 서지만 어디까지나 언어를 도구로써 이해해줄꺼라 믿는다. 결국 본인이 만들고자하는, 추구하는 소프트웨어 철학에 적합하는 도구를 고르는 것은 온전히 본인의 선택이다. 이를테면 현 시점에서 대용량 처리를 요구하는 소프트웨어에 싱글 쓰레드 기반인 자바스크립트를 택하진 않을 것이며, 간단한 기능을 요구하는 기능에 대해 다소 무거운 언어를 택하지 않을 것 이다. 타입스크립트가 뭐에요 ? 타입스크립트는 정적 타입(Static Typing) 언어이며, 동적 타입(Dynamic Typing) 언어인 자바스크립트의 상위 집합이다. 자바스크립트를 하나의 게임으로...

The XY Problem 이란 내가 X라는 문제를 풀려고 하고 있는 상황에서, Y가 해결책이 될 수 있을 것이라고 생각하기 때문에 실제 궁극적인 목표인 X에 대해서 묻는 대신 Y에 대한 질문을 하므로 발생하는 문제를 뜻한다. 이러한 문제는 주변에서 심심치않게 살펴볼 수 있는데, 이는 질문을 하는 당사자와 받는이로 하여금 많은 시간과 에너지 소모를 하게 만든다. 인류학자 레비 스트로스는 “과학자는 정답을 말하는 사람이 아니라, 올바른 질문을 하는 사람” 이라 주장하며 올바른 질문만이 올바른 정보를 얻을 수 있다 생각한다. 개인적으로 이러한 주장에 격하게 동감하며, 질문을 좀 더 잘하기 위해서는 XY Problem 상황 만큼은 피해야한다 생각한다. 그 상황이란 아래와 같이 연출된다. 유저는 X 를 하길 원한다. (User wants to do X) 유저는 X 를 어떻게 하는지는 모르지만, 만약 Y 를 해낼 수 있다면 X 의 해결책을 찾아낼 수 있을거라 생각한다. (User doesn’t know how to do X, but thinks they can fumble their way to a solution if they can just manage to do Y) 유저는...

본 책이 전달하는 메세지를 전부 다 이해하기엔 아직 이른 감이 있지만, 아주 조금 개발이란걸 하다보니 설득력이 느껴지는 부분이 꽤나 많았다. (최소 한번은 더 읽어 봐야겠다.) 이를테면, 객체들은 자율적인 존재, 메시지를 통한 객체들간의 협력 객체들을 자율적 존재인 공동체로 이러한 객체들은 타 객체들과 협력하는 사회적 존재이다. 책은 크게 역할, 책임, 협력 에 대해 얘기하고 있고 위에 언급한 협력을 포함한 역할과 책임 또한 어찌보면 우리 사회라는 Context 그 자체를 담고있는게 아닌가 싶다. 객체의 행동은 결국에 객체가 참여하고있는 협력을 뜻 하고. 협력이 바뀐다면 당연시 객체가 제공해야하는 행동 역시 바뀌어야한다. 역할은 다른 것으로 교체할 수 있는 책임의 집합이며, 책임이란 객체에 의해 정의되는 응집도 있는 행위의 집합이다. P75. 객체지향 시스템은 자율적인 객체들의 공동체다. 객체는 고립된 존재가 아니라 시스템의 기능이라는 더 큰 목표를 달성하기 위해 다른 객체와 협력하는 사회적인 존재다. 협력은 객체지향의 세계에서 기능을 구현할 수 있는 유일한 방법이다. 두 객체 사이의 협력은 하나의 객체가 다른 객체에게 도움을 요청할 때 시작된다. 메시지 전송(message sending)은 객체 사이의 협력을...

평생직장이란 개념에서 이직이란 존재하지 않는다. 그게 아니라면 우리는 앞으로 이직이라는 행위를 지속적으로 해야 한다. 다만 이직에 있어서 사회 통념상 받아들여지는 텀이 있다는 건 암묵적으로 모두가 동의하는 사실일 것이다. 그 시대에 따라 텀은 계속 바뀌지만 현재는 3 - 5년이 적정 텀이 아닌가 싶다. 이 또한 내가 속한 업계에서는 많이 변하고 있는 내용이긴 하다. 지인들은 내 이직 소식을 듣고 만류하기도하고 회유해보기도했다. 개인적으로 나는 텀은 중요하지 않다 생각된다. 결국 회사와 본인이 Fit 이 잘맞고, 지속적으로 동기 부여되며 같은 목표를 향해 달려갈 수 만 있다면 그 보다 더 긴텀도 순식간에 지나갈 것 이라 믿는다. 아래는 이번에 이직을 결정하며 어떤 팀에 갈것인가 메모장에 끄적인 내용이다. 회사 규모를 떠나 팀원을 리스펙할 수 있는 곳 Challenge 가 많고 그를 통해 본인 성정 가능한 곳 팀에 Goal 이 확실하고 그 Goal 이 사회에 긍정적인 영향을 미치는 곳 나와 Fit 이 잘 맞는 곳 병역특례 가능한 곳 이를 토대로 이력서를 정리해서 아래 회사들에 보냈고, 운 좋게도 인터뷰 과정에 응할...

배경 최근 새로운 도전이라는 명목하에 병역을 해결하기 위해 새로운 회사로 이직했다. 이직 결정에 있어서 비단 병역에 대한 문제만이 아닌 여러 사항들이 작용했는데 이와 관련해서 다음에 따로 글을 작성하겠다. 현 회사에서 레거시에 대한 내용을 많이 강조했고 그와 관련해서 어느 정도의 레거시는 예상했으나, 실제로 마주한 레거시의 정도는 정말 역대라 표현할 만큼 거대했다. 가장 먼저 CI/CD 가 제대로 구현되지 못했고, 개발자들은 Remote server 에 소스를 동기화 시키는 형태로 개발하고 있었다. 따라서 본인은 비효울적인 기술 스택들을 걷어내고, AWS ECS/ECR 를 통해 CI/CD 를 새로 적용했다. 본 글은 이를 구성하며 정리한 내용을 담고있다. 흐름 위 다이어그램은 실질적 배포 프로세스를 구성하기 앞 서, 이해를 돕기위해 흐름에 대해 따로 정의한 내용이다. 배포 순서는 아래와 같다. 게빌자는 본인의 로컬에서 작업한 내용을 Remote git server 로 Push 한다. AWS CodePipeline 은 해당 트리깅 이벤트에 따라 정의한 프로세스에 따라 작업을 수행한다. 트리깅 포인트 때문인지, Source 를 가지고 올 수 있는 항목이 제한적이다. (AWS CodeCommit, AWS ECR, AWS S3, Bitbucket, Github)...

본 문서는 gRPC 를 통해 Node 환경에서 마이크로 서비스를 개발하면서 느낀 고충에 대해 공유하고 있다. NestJS 라는 특정 프레임 워크를 사용했으며, 참조되는 코드의 모듈들 또한 해당 프레임 워크와 연관되어 있다. 본인은 gRPC 를 프로덕트에 적용해보며 실제로 높은 성능과 혁신적인 생산성을 경험할 수 있었다 이 문서를 보는 구독자 또한 이와 같은 경험을 가질 수 있었으면 하는 바람이다. gRPC 는 HTTP/2 레이어 위에서 Protocol Buffers 를 사용해 직렬화된 바이트 스트림으로 통신하므로 기존 REST API JSON 또는 XML 기반의 통신 보다 더 가볍고 통신 속도 또한 빠르다. 또한 인증, 양방향 스트리밍, timeout, cancellation, 블럭킹, 넌블럭킹등의 기능을 제공한다. 때문에 internal 통신이 빈번한 마이크로 서비스 구조에서 gRPC 를 적용했을 때, latency 감소 및 더 많은 트래픽을 처리하는 성능의 이점을 기대할 수 있다. gRPC 의 역사는 구글의 데이터 센터에서 실행되는 수 많은 마이크로서비스들이 10년 이상 사용한 단일 범용 RPC 인프라인 Stubby 에서 시작되었다. 구글은 오래전부터 마이크로서비스 아키텍처를 채택하여 연구해왔고, 내부 서비스들을 연결하기 위해 Stubby 를 만들었다....

IBM에서 기후변화와 COVID-19를 주제로 해커톤을 진행한다는 소식을 접했고, 평소 특히 COVID-19 에 대해 관심이 많았던 나는 주저 없이 참가 신청을 했다. 코로나 바이러스는 발병 이후 현재까지도 우리 사회를 위협하고 있다. 이러한 위협적인 바이러스로부터 우리 사회에 내가 기여할 수 있는 것은 무엇일까, 어떠한 메세지를 전달할 수 있을까 내심 고심이 많았지만 이러한 고심에 시간 또한 내게는 설렘으로 다가왔다. 이번 Call for code 2020은 에너지 해커톤 이후로 4년 만에 참가하는 해커톤이었다. 에너지 해커톤에서 너무 많은 에너지를 소비해서 다음 해커톤 참가를 꺼리게 된 것도 있었고, 일정이 바빠서 참가할 시간이 없었다. Schedule Getting started 시작에 앞서, 저번 해커톤은 친구와 함께 참가했다면 이번에는 혼자서 참가했기 때문에 조인할 팀을 찾아야 했다. 다행히도 빠르게 컨택된 팀에 조인할 수 있게 되었고 팀원들 또한 모두 좋은 사람들이라 생각되어 내심 만족했다. 우리 팀은 여러 아이디어들을 상의 끝에QR 코드 베이스 혼잡도 서비스를 구현하기로 결정했다. 이용자는 QR 코드를 통해 건물에 입장 또는 퇴장할 때, 태깅 이라는 절차를 수행하며 수행한 데이터는 서버가 수집을 하여...

도커에서 프로세스 스케줄링 하다가 이전에 정처기에서 학습했던 선점/비선점 스케줄링에 대한 이해도 떨어지는 것 같아 정리할 겸 글을 남긴다. 여기서 스케줄링이란 프로세스가 생성되어 실행될 떄 필요한 시스템의 여러자원을 해당 프로세스에게 할당하는 작업을 뜻 하며, 대기 시간은 최소화 하고 최대한 공평하게 처리하는 것을 목적으로한다. 메모리에 여러개의 프로세스를 올려놓고(=다중 프로그래밍), CPU의 가동시간을 적절히 나누어(=시분할) 각각의 프로세스에게 분배하여 실행되도록한다. 스케줄링에서는 아래와 같이 장기, 중기, 단기 단위가 있다. 장기 (Long-term scheduling) 어떤 프로세스가 시스템의 자원을 차지할 수 있도록 할 것인가를 결정하여 아래 준비(ready) 상태 큐로 보내는 작업을 의미한다. 상위 스케줄링이라고도 하며, 작업 스케줄러에 의해 수행된다. 수행 빈도 적고, 느리다. 중기 (middle-term scheduling) 어떤 프로세스들이 CPU를 할당 받을 것인지 결정하는 작업을 의미한다. CPU를 할당받으려는 프로세스가 많을 경우 프로세스를 일시 대기(waiting)시킨 후 활성화해서 일시적으로 부하를 조절한다. 스왑 인/아웃 결정 (메모리 부족 시 swap out, 남으면 swap in) 한다. 단기 (Short-term scheduling) 프로세스가 실행되기 위해 CPU를 할당받는 시기와 특정 프로세스를 지정하는 작업을 의미한다. 프로세서 스케줄링, 하위 스케줄링이라고도 한다....

TL; DR 여러분은 협업에 대해 어떻게 생각하는가? 🤔 모두 알다시피 협업은 절대 만만한 일이 아니다, 어쩌면 프로젝트를 진행하면서 맞닥뜨리는 가장 큰 난관이다. 그렇다해서 협업을 하지 않을 수 없다 현 시대에 소프트웨어는 너무 크고 복잡해졌기에 문제를 현명하게 해결할려면 혼자가 아닌 팀 단위로써 해결을 해야만한다. 본 문서에서는 노드 환경에서 프로젝트를 진행하며 협업에 대해 고민하고 시도(=삽질) 했던 내용들을 공유해보고자 한다. 다만, 본문에서 다루는 내용들이 꼭 노드 환경에 국한되어 있지 않다. 또한, 어떠한 방법론에 대해서도 강요하지 않을 것이며 언급되는 내용과 생각들은 굉장히 주관적인 부분이라는 것을 이해해 주고 읽어주길 바란다. 이 문서가 협업이라는 난관을 헤쳐나가고자 하는 이들에게 조금이라도 도움이 되길 바라며 글을 적는다. 본인은 협업을 다수와 함께 하는 테트리스 라 생각한다. 혼자 하기도 힘든데, 여러 블록들이 우리 의지와 다르게 쏟아진다면 분명 우리 모두 멘붕에 빠질 테고 야속하게 쏟아지는 블록들은 천장을 뚫을 듯 높게 쌓일 거다. 블록이라는 단위를 태스크로 본다면, 야속하게 쌓인 레거시들(블록들)은 다음 블록을 내려야 하는 개발자에게 큰 고충일 될 것이다. 그렇다면 우리는 어떻게 멘붕에...

우리는 작성한 API 에 병목 현상과 얼마 만큼의 트래픽을 수용할 수 있는지에 대한 여부를 확인하고자 스트레스 테스트를 작성한다. 통상 자바환경에 익숙하다면 스트레스 테스트를 생각하면 ngrinder (또는 grinder) 를 먼저 생각하게 되는데, 본인은 Node 환경에서 아주 가볍게 스트레스 테스트를 구성하고 싶었고 그 요구 사항에 맞는 툴을 리서치하다 third party 로 제공하는 Artillery 를 알게되었다. 본 문서에서는 Artillery 을 통해 스트레스 테스트를 진행하며 느낀 점과 그 방법에 대해 얘기해보고자한다. 문서 작성 시점 기준으로 Artillery 의 Github 스타는 3.6k 정도 되고, 아직 개선할 사항들이 많아 보이긴 하지만 사용에 있어 크게 불편한점은 찾지 못했다. 무료 버전과 유료 버전으로 나뉘는데 무료 버전을 사용해도 대세에는 크게 지장 없다. 그래도 회사에서 운영하는 프로젝트이다보니 업데이트는 꾸준히 존재한다. 아래는 본인이 정리한 Artillery 의 특징이다. HTTP, Websocket 프로토콜을 지원한다 Javascript 를 통해 필요에 따른 로직을 구성할 수 있다. 2번에 해당 하는 내용에 대해 아래와 같은 Trigging point 를 제공한다. beforeScenario: called before a virtual user executes a scenario afterScenario: called...

이번에 회사에서 진행하는 새로운 프로젝트를 TDD(Test Driven Development)로 진행하며 느낀 바와 경험들을 공유하고자 글을 작성한다. 예전부터 TDD 도입에 대한 갈망은 컸으나, 요구사항에 맞추어 구현체 내용을 구현하기 급급했다는 핑계로 항상 뒷전에 두었는데 지금이나마 TDD 방법론이 주는 행복과 역할을 느낄 수 있어 뜻 깊은 시간이었다. 본인의 경우 Typescript 환경에서 TDD 를 진행했으며, 혹시 같은 환경에서의 도입을 고민하는 이들에게 이 글이 조금의 도움이 되길 바란다. 다만, 알다시피 TDD 는 개발 방법론이기에 특정 언어에 국한되어 있지 않다. 본 문서에서 인용되는 코드들이나 라이브러리들도 각 언어마다 그 역할을 수행하는 녀석들이 있을 테니 그것은 각자 살펴보길 바란다. 들어가기 앞 서, 조금의 우려는 TDD 에 대한 무조건적인 찬양의 글이 아니며 어디까지나 TDD 를 통해 개발을 하며 느낀 주관적인 생각이니 이 점 유의해 주고 글을 읽어주면 좋겠다. 모든 개발 방법론에는 장단점이 존재하며 본 문서에서 다루는 TDD 또한 다르지 않다. Test case 를 작성하지 않았던 건 아니다. 난 요구 사항에 맞추어 기능을 개발하고 곧잘 기능에 대한 테스트 케이스도 작성하는 평범한...

쿠버네티스에서는 각 컨테이너의 상태를 주기적으로 확인하고 문제가 있는 컨테이너를 재시작하거나 pod를 서비스에서 제외시킬 수 있다. 이러한 기능을 health check 라고 하는데 AWS ALB 를 사용해보았다면 어떠한 기능인지 알 수 있다. health check 에는 두 가지 방법이 있다. Liveness probe 와 Readiness probe Liveness probe 는 컨테이너가 살아있는 여부를 체크하고 Readiness probe 는 컨테이너가 현재 서비스 가능 상태인지 여부를 체크한다. Liveness Probe 에서는 애플리케이션의 요구에 맞춰 컨테이너가 새로 시작되는 시점을 결정할 수 있다. Readiness Probe 에서는 애플리케이션이 많은 양의 데이터를 수행하다 락이 걸리거나 아직 어떠한 모듈이 bootstrapping 되지 않았을 때 (서비스 불가 상태) 애플리케이션의 상태를 쿠버네티스에 알린다. 다만, Readiness probe 는 Liveness probe 와는 달리 실패했다고 하더라도 컨테이너를 재시작하지 않는다. 재시작하지 않는 이유는 락이 걸렸거나 외부 주입된 모듈에 대해 이슈가 있으면 재시작한다해도 서비스가 불가한 상태이기 때문이다. 아래는 Liveness probe 와 Readiness probe 설정이다. # Liveness probe ports: - name: liveness-port containerPort: 8080 hostPort: 8080 livenessProbe: httpGet: path: /healthz port: liveness-port #...

이직을 했다. 암호화폐 거래소인 코인원에 19년 10월 이직을 했다. 퇴사를 결정하고 일주일 가량 가고 싶은 회사들을 리스트업 하고 컨택을 진행했다. 회사를 고를 때, 가장 많이 고려한 건 내가 해보지 않은 분야에 대한 도전이었다. 경험해보지 못한 분야에 대해 도전하여 내 자신에 대한 스펙트럼을 넓히고자 했다. 또한 내가 경험한 산업 군이 도전하고자 하는 분야에도 잘 녹일 수 있는 것들이 많지 않을까 내심 기대했다. 그렇게 이런저런 생각을 하다 결정을 내린 게 금융 쪽이 었다. 금융이라는 분야를 택한 이유는 꽤나 길어서 여기선 생략하겠다. 다만 내 최종 목적지에 꼭 필요한 피스였기 때문이었다는 정도만 얘기할 수 있을 것 같다. 그렇게 해당 분야에 회사들과 컨택하다 적극적으로 러브콜을 보내 준 코인원으로 가기로 결정했다. 코인원은 금융을 다룬다, 암호화폐도 다룬다. 근데 난 둘다 모른다. 다만 난 새로운 걸 배우는 걸 무척 좋아한다. 도전하지 않을 이유가 있겠는가. 스테이킹이라는걸 서비스 한다. 스테이킹 서비스는 블록체인 네트워크에 직접 참여하기가 어려운 개인 투자자를 대상으로 거래소가 이용자를 대신해 노드로 참여하면서 보상 수익을 나눠가질 수 있도록 한...

사이드 프로젝트(=갬성) 개발하다가 환기좀 시킬겸 프로그래머스 들어가서 문제 풀었다. 첫번째 문제는 보행자 천국 이다. 카카오 코드 페스티벌 예선 4번에 해당하는 내용이다. 카카오내비 개발자인 제이지는 시내 중심가의 경로 탐색 알고리즘 개발 업무를 담당하고 있다. 최근 들어 보행자가 자유롭고 편리하게 걸을 수 있도록 보행자 중심의 교통 체계가 도입되면서 도심의 일부 구역은 자동차 통행이 금지되고, 일부 교차로에서는 보행자 안전을 위해 좌회전이나 우회전이 금지되기도 했다. 복잡해진 도로 환경으로 인해 기존의 경로 탐색 알고리즘을 보완해야 할 필요가 생겼다. 도시 중심가의 지도는 m × n 크기의 격자 모양 배열 city_map 으로 주어진다. 자동차는 오른쪽 또는 아래 방향으로 한 칸씩 이동 가능하다 city_map[i][j]에는 도로의 상황을 나타내는 값이 저장되어 있다. 0인 경우에는 자동차가 자유롭게 지나갈 수 있다. 1인 경우에는 자동차 통행이 금지되어 지나갈 수 없다. 2인 경우는 보행자 안전을 위해 좌회전이나 우회전이 금지된다. (왼쪽에서 오던 차는 오른쪽으로만, 위에서 오던 차는 아래쪽으로만 진행 가능하다) 도시의 도로 상태가 입력으로 주어졌을 때, 왼쪽 위의 출발점에서 오른쪽 아래 도착점까지 자동차로 이동 가능한...