Develop

서론 결국 좋은 품질의 애플리케이션을 개발하기 위해서는 CS지식을 활용하여 성능과 안정성을 최대로 이끌어내야한다. 이 때문에 나도 다시 CS지식을 학습하고 있는데 운영체제를 공부하다보니 이러한 이론들을 실제 개발에 어떻게 접목시켜야 좋을지 감이 오지 않았다. 스레드, 동기화, 스케줄링 부분을 학습하면서 이론들을 어떻게 실제 성능, 안전성, 자원 관리같은 운영품질 향상과 같은 실전에 연결 시킬 수 있는지 정리해보았다.스레드의 본질백엔드 개발 관점에서 스레드를 이해할 때의 핵심은 하나이다.같은 프로세스의 스레드들은 같은 주소 공간(메모리)를 공유한다. 즉, 코드/힙/전역 데이터같은 메모리를 함께 사용한다.대신 각 스레드들은 자신만의 스택을 가진다. 스택은 스택 포인터 레지스터로 관리되기 때문에 스레드별로 분..

서비스 계층의 책임이 오염되었다.사이드 프로젝트를 진행하던중 전체적인 MVP 기능을 완성하고 코드 리팩토링, 테스트를 진행하던 와중에 한가지 의문점이 생겼다.좋은 코드는 하나의 모듈은 하나의 책임만 져야한다. 응집도는 높을수록 결합도는 낮을수록 좋다. 그러나 내 프로젝트에서 기존의 인증 흐름에서 서비스 계층에서 서블릿api와 세션을 직접 다루고 있다는것을 깨달았다.서비스 계층은 본질적으로 비즈니스 규칙을 구현하는 곳인데, 서비스가 직접 `HttpSession`을 직접 읽고/쓰게되면 서비스가 "웹 요청/응답 컨텍스트"에 종속되게 된다. 그래서 결국 내가 작성한 코드는 "로그인은 웹 세션 기반으로만 가능"해진 확장이 불가능한 코드가 되어버렸다.기존의 코드서비스 계층에서 직접 서블릿 의존을 다루고 있는 모습을..

포스팅 한 이유개발을 하다보면 기본 폰트들(Consolas, Menlo, cascadia, sf mono 등...)을 사용하는 경우도 있지만 자신이 취향이 담긴 그리고 더 가독성이 좋은 폰트들을 설치하여 사용하기 마련이다. 그런데 이번에 새로운 폰트를 받아서 인텔리제이에서 적용하려 했더니 보여야할 폰트가 보이지 않는것이다. IDE를 껐다 켜보기도 하고, 재부팅도 해봤지만 vscode와 시스템 그리고 터미널에서도 새로 설치한 폰트가 인식되는데 유독 인텔리제이에서만 인식되지 않았다. 그래서 구글링을 해봤더니... 나와 똑같은 이슈를 겪는 사람들이 있었다. 그래서 이를 어떻게 해결했는지 알아보니 그 방법은 매우 간단했다. 우클릭을 해서 그냥 설치가 아닌 모든 사용자용으로 설치 버튼을 눌러서 설치를 하니 인텔리..

지난 글에서 테스트 코드의 기본적인 개념에 대해 알아보았다. 이번 포스팅에서는 그럼 왜 테스트 코드를 작성해야 하는지 어떻게 테스트 코드를 작성해야 좋은 테스트 코드인지를 알아보려고 한다.왜 백엔드 개발자는 테스트 코드를 작성해야 할까?회귀(regression)를 막는 가장 현실적인 방어선서비스가 커질수록 가장 자주 겪는 문제 중 하나가 있다.“이번에 새 기능 넣었는데, 예전에 잘 되던 기능이 갑자기 깨졌다.”이게 바로 회귀(regression) 버그이다.테스트 코드는 이런 회귀를 막는 가장 현실적인 방어선이다. 코드가 바뀔 때마다, 사람이 일일이 모든 주요 기능을 눌러볼 수는 없다. 자동화된 단위 테스트와 통합 테스트 스위트가 있어야, 코드 변경 → 테스트 실행 → 이상 있으면 바로 감지라는 루틴이 가..

테스트 코드를 세분화 하는 이유개발 공부를 하면서 생각보다 큰 어려움을 마주하는게 바로 테스트코드 작성이였다. TDD 설계가 뭔지, Mock은 또 언제 사용하는지, 통합테스트는 뭐고 단위 테스트는 뭐고... 실무에서 대규모 프로젝트를 진행해본적이 없고, 개인 프로젝트나 협업 프로젝트라 하더라도 학부생 수준에서 할 수 있는 규모의 프로젝트였으니 "일단 돌아만 가게 만들자! 버그는 나중에 생각해"라는 마인드로 항상 개발을 했었던것 같다. 그런데, 프로젝트의 구조가 커질수록 서비스의 로직이 복잡해질수록 어떻게 테스트 코드를 짜고 로직을 구현해야 좋은 코드일지, 여기서 생각지도 못한 버그가 터졌는데 이걸 어떻게 디버깅할지 테스트 코드 작성의 중요성을 절실히 느끼고 있다. 테스트 용어에 대해서는 여러말이 많지만..

서론스프링 부트 + 그레이들 프로젝트를 다루다 보면 자연스럽게 많이 사용하는 명령어가 있다.`./gradlew build`와 `./gradlew bootRun`두 명령이 비슷해 보이지만, 실제로는 목적과 동작이 꽤 다르다는 것을 정리하려 한다../gradlew build - 빌드 & 테스트 & 패키징`./gradlew build`는 말 그대로 프로젝트를 빌드하는 용도이다.이 명령을 실행하면 그레이들이 아래와 같은 작업을 수행한다.소스코드 컴파일테스트 코드 실행 (`test` task)결과물을 JAR/WAR로 패키징(`bootJar, jar` 등 생성)산출물을 `build/libs/xxx.jar` 같은 위치에 생성하게 된다.즉, 이 명령의 목적은 "애플리케이션을 실행하는 것"이 아니라, "배포 가능한 산출..

터미널 에뮬레이터의 경우 요즘엔 종류도 많고 OS에서 기본으로 제공하는 기본적인 터미널들도 커스터마이징이 가능해졌지만 기능에있어서 아쉬운점이 존재할 수도 있다. 맥에선 보통 iterm2를 사용했고, 현재 윈도우 + wsl2 환경에서는 윈도우 기본 터미널을 사용했었는데... 아무래도 다른 OS에서도 같은 터미널 에뮬레이터를 사용해서 단축키, 설정, 프로필등을 통일 시켜놓는게 편하지 않을까? Wezterm을 사용하기로 결정했다. 요즘 맥은 처박아놓고 거의 윈도우 랩탑만 사용하긴 하지만 다른 편의기능도 존재하고, 나중에 다시 맥을 사용할지도 모르니... Wezterm터미널 에뮬레이터의 종류중 하나이고, 자체적인 multiplexing 기능을 갖고 있다. 나야 뭐 보통 개발은 vscode나 이클립스, 인텔리제이..

왜 쿠키가 필요할까?HTTP는 기본적으로 무상태(stateless)프로토콜이라, 요청 하나하나가 서로 독립적이고 서버는 기본적으로 "이 요청이 누구의 것인지" 모른다. 하지만 우리가 실제 웹 서비스를 돌린다 했을때는 다음과 같은 기능들이 필요할 것이다.로그인 유지(세션 유지)장바구니 상태 유지사용자 설정(언어, 테마 등)분석/광고를 위한 사용자 식별 등이를 위해 서버와 브라우저는 쿠키(Cookie)라는 작은 데이터를 주고받으며, "이 사용자는 이 쿠키를 가진 사용자이다"라는 식으로 상태를 기억하게 된다.쿠키의 기본 동작 흐름서버 → 브라우저: Set-Cookie서버는 HTTP 응답 헤더에 `Set-Cookie`헤더를 넣어 쿠키를 설정할 수 있다.HTTP/1.1 200 OKSet-Cookie: sessio..

1. JWT를 실무에서 어렵게 만드는 것들JWT의 개념 자체는 단순하다.`header.payload.signature` 구조서버 비밀키/공개키로 서명서버가 토큰만 보고 사용자 식별그러나 실무에서 사용할 때 문제가 되는 포인트들이 여럿 존재한다. 설계와 개발 과정에서 신경 쓰고 개발한다면 JWT는 서버 부하를 줄이고, 대규모 서버 확장에 유리하지만 그렇지 않다면 허점이 노출되어 보안 위협을 겪을 가능성이 크다. JWT를 사용할 때 신경써야 할 부분은 다음과 같다.토큰을 언제까지 유효하게 둘것인가(만료 정책)토큰을 어떻게 무효화할 것인가(로그아웃, 탈취 시 대응)여러 기기, 브라우저, 마이크로 서비스에서 일관된 정책을 유지할 것인가.키 유출/탈취/XSS/재사용 공격 등 보안 이슈이를 해결하기 위해 등장한 개..

1. 서론백엔드 서버에서 많이 사용하는 세션 기반 인증과 JWT 기반 인증을 비교해보려 한다. 개인 프로젝트를 진행하면서 세션 방식과 JWT 방식을 모두 구현해보기는 했지만 어떠한 방식이 더 유리한지 구현에 용이한지 어떤 규모의 프로젝트에 적합한지는 고려해본적이 없어 이번 기회에 정리하려 한다.세션 인증서버가 "로그인한 사용자 상태"를 들고 있는 방식이다(stateful).구현이 쉽고, 전통적인 웹 서비스/어드민 페이지에 여전히 적합하다.JWT 인증서버가 사용자 정보를 서명된 토큰(JWT)에 담아서 클라이언트에게 맡기는 방식이다(stateless 지향).마이크로 서비스, 모바일/웹/외부API를 동시에 지웒나느 대규모 서비스에서 유리하지만 설계 난이도가 높다. 처음 만드는 서비스라면 세션으로 시작해도 충분..