개발스토리지

[깃허브] Gist로 깃허브 꾸미기

believekim — Sat, 3 Jan 2026 19:45:19 +0900

깃허브를 꾸미다 보니 gist라는 기능을 알게 되어
적용방법을 정리해보았다

1. Github Gist란?

짧은 코드 조각, 메모, 또는 간단한 텍스트 파일을 공유하기 위한 서비스
별도의 저장소(Repository)를 만들지 않고도 파일 하나만 뚝딱 생성할 수 있는 것이 특징

2. Gist 생성

Gist에 접속
아래의 번호 순서대로 Gist 생성

게시글 경로 url을 복사

3. Github 환경변수 등록

GH_TOKEN 발급
프로필 클릭 -> settings

Developer settings 클릭

Personal access tokens -> Token(classic) 클릭 -> Generate new token을 클릭하여 발급

자신의 레포지토리로 돌아와 아래의 이미지대로 환경변수 값을 적용
GIST_ID_*는 위에서 복사해두었던 게시글url값 적용

4. Git Action 파일 생성

필자는 .github/workflows/gist.yml 로 생성

name: Update All Gists (Routine & Stats)

on:
  schedule:
    - cron: "0 0 * * *" # 매일 자정 자동 실행
  workflow_dispatch: # 수동 실행 버튼 활성화
  push:
    branches:
      - main
      - master

jobs:
  update-gists:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      # 1. Routine Gist 업데이트 (I'm a night  )
      - name: Update Routine Gist
        uses: maxam2017/productive-box@master
        env:
          GH_TOKEN: ${{ secrets.GH_TOKEN }}
          GIST_ID: ${{ secrets.GIST_ID_ROUTINE }}
          TIMEZONE: Asia/Seoul

      # 2. Statistics Gist 업데이트 (GitHub Stats Box)
      - name: Update Statistics Gist
        run: npx github-stats-box@1
        env:
          GH_TOKEN: ${{ secrets.GH_TOKEN }}
          GIST_ID: ${{ secrets.GIST_ID_STATISTICS }}
          ALL_COMMITS: true
          K_FORMAT: false

5. 결과 확인

Action으로 들어가 정상작동했는지 확인

메인페이지에서 Customize your pins 클릭
Show: 항목에서 Gists를 클릭하면 생성된 Gist가 노출(public으로 만들어야 노출됨)
원하는 Gist를 선택하면 적용완료!

https://github.com/pleasebelieveme

pleasebelieveme - Overview

pleasebelieveme has 69 repositories available. Follow their code on GitHub.

github.com

[깃허브] 깃허브 README 애니메이션 꾸미기 (pecman, snake)

believekim — Fri, 2 Jan 2026 15:37:51 +0900

취업을 준비하기에 앞서 깃허브의 README를 꾸며보았다
쓸데없이 애니메이션만 적용했는데 재밌다..

1. 들어가며

내 잔디 위에서 팩맨이 돌아다니고, 스네이크가 먹이를 먹는 재미있는 애니메이션을 GitHub 프로필에 적용하는 방법을 소개

참고 사이트
https://profile-readme-generator.com/

Profile Readme Generator

Beautify your github profile with this amazing tool, creating the readme your way in a simple and fast way! The best profile readme generator you will find!

profile-readme-generator.com

https://www.gitanimals.org/en_US?utm_medium=image&utm_source=pleasebelieveme&utm_content=line

GitAnimals

깃허브 활동으로 펫을 키우세요!

www.gitanimals.org

2. pecman 적용

./github/workflows/pecma.yml 파일 생성
매일 자정(UTC)에 실행되어 팩맨이 잔디를 먹는 .svg 파일을 생성

name: Generate pacman animation

on:
  schedule:
    - cron: "0 0 * * *"
  workflow_dispatch:

jobs:
  generate:
    permissions:
      contents: write
    runs-on: ubuntu-latest
    timeout-minutes: 5

    steps:
      - name: Generate pacman-contribution-graph.svg
        uses: abozanona/pacman-contribution-graph@main
        with:
          github_user_name: ${{ github.repository_owner }}
          theme: dark
          output: dist/pacman-contribution-graph.svg

      - name: Push pacman-contribution-graph.svg to the output branch
        uses: crazy-max/ghaction-github-pages@v3.1.0
        with:
          target_branch: output
          build_dir: dist
          keep_history: true
          commit_message: "update pacman ${{ github.run_id }}"
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

README.md 파일에 적용
pleasebelieveme에 본인의 아이디/레포지토리이름으로 변경

<h3>  Pacman eats my daily GitHub contributions</h3>

<img
  src="https://raw.githubusercontent.com/pleasebelieveme/pleasebelieveme/output/pacman-contribution-graph-dark.svg?v=1"
/>

3. snake 적용

./github/workflows/snake.yml 파일 생성
매일 자정(UTC)에 실행되어 뱀이 잔디를 먹는 .svg 파일을 생성

name: Generate snake animation

on:
  schedule:
    - cron: "0 0 * * *"
  workflow_dispatch:

jobs:
  generate:
    permissions:
      contents: write
    runs-on: ubuntu-latest
    steps:
      - name: generate snake.svg
        uses: Platane/snk/svg-only@v3
        with:
          github_user_name: ${{ github.repository_owner }}
          outputs: dist/snake.svg?palette=github-dark

      - name: push snake.svg to the output branch
        uses: crazy-max/ghaction-github-pages@v3.1.0
        with:
          target_branch: output
          build_dir: dist
          commit_message: "update snake ${{ github.run_id }}"
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

README.md 파일에 적용
pleasebelieveme에 본인의 아이디/레포지토리이름으로 변경

<h3>  Snake Contribution Animation</h3>
<img
  src="https://raw.githubusercontent.com/pleasebelieveme/pleasebelieveme/output/snake.svg?cache=1"
  alt="Snake animation"
/>

4. Git Animals

회원가입 후 commit포인트를 모아 캐릭터를 모으로 농장을 꾸민다
https://www.gitanimals.org/en_US?utm_medium=image&utm_source=pleasebelieveme&utm_content=line

GitAnimals

깃허브 활동으로 펫을 키우세요!

www.gitanimals.org

아래의 사이트에서 html코드를 복사해서 내 README.md 파일에 붙여넣기

https://github.com/git-goods/gitanimals

GitHub - git-goods/gitanimals: 깃허브 활동으로 펫을 키우세요 / Have pet in your github

깃허브 활동으로 펫을 키우세요 / Have pet in your github . Contribute to git-goods/gitanimals development by creating an account on GitHub.

github.com

5. 트러블슈팅

일반적으로 main 브랜치에 코드를 올리지만,

애니메이션 액션들은 생성된 .svg 이미지 파일들을 관리하기 쉽게 별도의

output 브랜치에 따로 저장하도록 설정되어 브랜치가 자동적으로 생성

GitHub Actions가 내 레포지토리에 파일을 생성하고 커밋(Push)하려면 쓰기 권한이 필요

해당 GitHub 레포지토리의 Settings 탭으로 들어갑니다.
왼쪽 사이드바에서 Actions > General을 클릭합니다.
페이지 하단부의 Workflow permissions 항목을 찾습니다.

Read and write permissions를 체크하고 Save 클릭

https://github.com/pleasebelieveme

pleasebelieveme - Overview

pleasebelieveme has 69 repositories available. Follow their code on GitHub.

github.com

역시 코딩보다 재밌다

[쉘스크립트] MSA 개발 환경에서 여러 서버 포트 종료 자동화스크립트 For MacOS

believekim — Sun, 16 Nov 2025 21:43:38 +0900

MSA로 개발을 하다가 인텔리제이가 멈춰 강제종료하였다.
다시 실행하려고 하니 총 12개의 서버의 포트가 충돌이 나서 쉘스크립트를 만들어 보았다.

1. kill_duplicate_servers.sh 작성

띄어쓰기는 _를 사용
servers=(<서버이름>:<포트번호>)의 내용을 자신의 상황에 맞게 수정

#!/bin/bash

# ===========================
# 서버 포트 점검 및 종료 스크립트 (Bash 3.x 호환)
# ===========================

# 서버명과 포트를 "서버명:포트" 형태로 배열에 저장
servers=(
  "AI_Server:20010"
  "Company_Server:20020"
  "Delivery_Server:20030"
  "Hub_Server:20040"
  "Hub_Route_Server:20050"
  "Order_Server:20060"
  "Product_Server:20070"
  "User_Server:20080"
  "Slack_Server:20090"
  "Eureka_Server:8761"
  "Config_Server:8888"
  "Gateway:8080"
)

echo "====== 서버 포트 점검 및 종료 ======"

for entry in "${servers[@]}"; do
  name=$(echo $entry | cut -d':' -f1)
  port=$(echo $entry | cut -d':' -f2)

  pid=$(lsof -ti tcp:$port)

  if [ -n "$pid" ]; then
    echo "$name (포트 $port) 실행중 PID=$pid -> 종료"
    kill -9 $pid
  else
    echo "$name (포트 $port) 실행중 아님"
  fi
done

echo "====== 완료 ======"

2. 실행방법

파일 생성
나는 vi를 사용했지만 nano, cat 등등 본인이 편한대로 생성하면 된다

vi kill_duplicate_servers.sh

실행 권한 부여

chmod +x kill_duplicate_servers.sh

실행

./kill_duplicate_servers.sh

3. 결과화면

[RestFul API] PUT vs PATCH vs POST, 언제 어떤 메서드를 써야 할까?

believekim — Mon, 10 Nov 2025 11:28:25 +0900

API 명세서를 작성하다가 PUT, PATCH, POST을 어떻게 사용해야 할지 혼란스러웠다.
멱등성이 있으면 PUT, 없으면 PATCH라는 원칙도 배우지만 그 기준만으로는 혼란을 해결하지 못했다.
그래서 설계원칙을 정리해보았다.

1. RESTful API 설계의 기본 원칙

REST 설계의 핵심은 리소스(Resource) 중심이기에
URL에는 명사(thing)만 들어가야 하고, 행동(action)은 HTTP 메서드로 표현
"무엇을 조작할 것인가"를 URL로
"어떻게 조작할 것인가"를 HTTP 메서드로 구분


구분	예시	설명
✅ 좋은 예	`GET /products/1`	상품 1번 조회
나쁜 예	`GET /getProductById/1`	행동이 URL에 들어감

2. PUT vs PATCH vs POST의 개념 비교


메서드	역할	멱등성	설명
`PUT`	리소스를 전체 교체 (replace)	✅ 있음	동일한 요청을 여러 번 보내도 결과가 같음
`PATCH`	리소스를 부분 수정 (partial update)	⚠️ 경우에 따라	일부 필드만 변경할 때 사용
`POST`	리소스를 생성(create) 또는 행동(action)	❌ 없음	비멱등, 같은 요청을 여러 번 보내면 결과가 달라짐

멱등성(Idempotency)이란?

같은 요청을 여러 번 보내도 결과가 변하지 않는 성질.

예시:

PUT /product/1 → { "name": "콜라", "price": 1000 }
- 여러 번 보내도 상품 정보가 동일하게 유지됨 → ✅ 멱등
PATCH /product/1 → { "price": 1000 }
- 여러 번 보내면 결과는 같지만, 로직에 따라 다를 수 있음 → ⚠️ 조건부 멱등
POST /product/1/increase
- 매번 수량이 1씩 증가 → ❌ 비멱등

3. 실무에서의 적용 기준

✅ `PUT` (전체 교체)

리소스를 통째로 덮어쓰는 경우 사용
누락된 필드는 삭제로 간주(null 값으로 설정)
멱등성 있음

PUT /products/1
Content-Type: application/json

{
  "name": "콜라",
  "category": "DRINK",
  "price": 1000,
  "quantity": 10
}

대부분의 도메인에서는 전체 교체가 어렵다.
예: id, createdAt, companyId 같은 필드는 바뀌면 안되기 때문에
실무에서는 PUT이 거의 사용되지 않음.

✅ PATCH (부분 수정)

일부 필드만 수정할 때 사용
null이 전달되지 않은 필드만 반영
부분 변경 시 주로 사용

PATCH /products/1
Content-Type: application/json

{
  "quantity": 20
}

여러 필드를 한 번에 바꾸더라도 전체 교체 의도가 아니라면 PATCH 사용
예시: 이름과 가격을 동시에 수정 → 여전히 부분 수정이므로 PATCH.

✅ POST (행동 또는 생성)

리소스를 생성하거나,
특정 행동(Action)을 수행할 때 사용 (즉, 단순 데이터 변경이 아닌 비즈니스 이벤트)

POST /products/1/increase
POST /users/{id}/follow
POST /auth/login

POST는 REST 관점에서는 행동을 표현할 때 유일하게 허용되는 메서드로
부분수정을 하더라고 URL에 행동이 들어가면 POST로 작성
참고: 로그인은 "유저 리소스 수정"이 아니라 "세션을 생성"하는 행동임으로 POST

참고

https://github.com/microsoft/api-guidelines/blob/vNext/azure/Guidelines.md

api-guidelines/azure/Guidelines.md at vNext · microsoft/api-guidelines

Microsoft REST API Guidelines. Contribute to microsoft/api-guidelines development by creating an account on GitHub.

github.com

[자바] 왜 if-else를 쓰지 말라고 할까? - 클린 코드와 테스트 관점에서

believekim — Sun, 9 Nov 2025 09:29:04 +0900

요구사항 중에 if-else문을 사용하지 말라는 문구를 보았다
단순히 “코드가 더러워진다” 정도로만 생각했는데
테스트 복잡도와 유지보수성 측면에서 중요한 이유가 있었다.

1. 문제 코드 — if-else가 많은 코드

아래는 로또문제를 예로 가지고 왔다.
번호 6개를 맞추면 1등, 5개를 맞추고 보너스 번호를 맞추면 2등이다.

public String getRank(int match, boolean bonus) {
    if (match == 6) {
        return "1등";
    } else if (match == 5) {
        if (bonus) {
            return "2등";
        } else {
            return "3등";
        }
    } else if (match == 4) {
        return "4등";
    } else if (match == 3) {
        return "5등";
    } else {
        return "꽝";
    }
}

필요한 테스트 케이스:

match=6 → "1등" ✅
match=5, bonus=true → "2등" ✅
match=5, bonus=false → "3등" ✅
match=4 → "4등" ✅
match=3 → "5등" ✅
match=2 → "꽝" ✅
match=1 → "꽝" ✅
match=0 → "꽝" ✅

총 8개 테스트!로 조합폭발(Combinatorial Explosion)

참고

테스트 케이스 수는 “if 조건 개수”에 따라 2ⁿ (지수적으로) 증가한다.

그래서 테스트 효율성 향상을 위해 MC/DC(테스트 갯수 n+1)를 사용한다.

2. Early Return으로 개선

테스트 케이스는 같지만 조건문 중첩이 사라졌고 가독성이 좋아졌으며 각 조건이 단일 책임을 가지도록 구현

public String getRank(int match, boolean bonus) {
    if (match == 6) {
        return "1등";
    }
    if (match == 5 && bonus) {
        return "2등";
    }
    if (match == 5) {
        return "3등";
    }
    if (match == 4) {
        return "4등";
    }
    if (match == 3) {
        return "5등";
    }
    return "꽝";
}

3. Map으로 개선

match와 bonus 조합을 Key, 등수를 Value로 맵핑

private static final Map<String, String> RANK_MAP = Map.ofEntries(
    Map.entry("6:false", "1등"),
    Map.entry("5:true", "2등"),
    Map.entry("5:false", "3등"),
    Map.entry("4:false", "4등"),
    Map.entry("3:false", "5등")
);

결과 찾기

public String getRank(int match, boolean bonus) {
    String key = match + ":" + bonus;
    return RANK_MAP.getOrDefault(key, "꽝");
}

4. Enum으로 개선

조건문이 사라지고 테스트 대상이 “로직”에서 데이터 구조로 변환

public enum Rank {
    FIRST(6, false, "1등"),
    SECOND(5, true, "2등"),
    THIRD(5, false, "3등"),
    FOURTH(4, false, "4등"),
    FIFTH(3, false, "5등"),
    FAIL(0, false, "꽝");

    private final int match;
    private final boolean bonus;
    private final String label;

    Rank(int match, boolean bonus, String label) {
        this.match = match;
        this.bonus = bonus;
        this.label = label;
    }

    public static String find(int match, boolean bonus) {
        return Arrays.stream(values())
                .filter(r -> r.match == match && (!r.bonus || bonus))
                .findFirst()
                .map(r -> r.label)
                .orElse("꽝");
    }
}

사용 예시

String rank = Rank.find(5, true); // "2등"

5. 비교

방식	장점	단점
if-else	단순, 직관적	조건 늘면 가독성 ↓, 테스트 폭발
Map	깔끔, 데이터 관리 쉬움	Key 구성 주의 필요
Enum + Stream	타입 안정성, 확장성 최고	약간 코드 길어짐

“조건문은 줄이는 게 목적이 아니라, 의도를 명확히 표현하는 것이 목적입니다.”

[IntelliJ] Spring Cloud 기반 MSA 프로젝트 여러 서버를 관리하는 gradle 초기설정

believekim — Wed, 5 Nov 2025 23:35:38 +0900

Spring Cloud를 사용해서 MSA 기반 서버를 구성하면서,
모놀리식과는 다른 Gradle 프로젝트 구조와 빌드 관리 방식에서 헷갈리는 부분이 많았다.
하나의 루트 폴더에서 여러 개의 서비스 모듈을 관리하는 방법과
그 과정에서 겪은 시행착오를 정리해본다.

1. MSA 프로젝트 구조 개요

MSA 프로젝트를 구성할 때, 각 서비스(eureka, gateway, user, order 등)는
각각 독립적으로 실행 가능한 Spring Boot 애플리케이션이 된다.
예시

Cupeed/
 ├── com.sparta.cupeed.config/
 ├── com.sparta.cupeed.eureka/
 ├── com.sparta.cupeed.gateway/
 ├── com.sparta.cupeed.user/
 ├── com.sparta.cupeed.order/
 ├── com.sparta.cupeed.product/
 ├── com.sparta.cupeed.company/
 ├── com.sparta.cupeed.hub/
 ├── com.sparta.cupeed.hubroute/
 ├── com.sparta.cupeed.delivery/
 ├── com.sparta.cupeed.ai/
 ├── com.sparta.cupeed.slack/
 └── settings.gradle   ← 모든 모듈을 관리하는 루트 설정

2. 루트 경로에 settings.gradle 설정

MSA의 각 서버를 연결하기 위해 루트 경로(Cupeed/)에 있는 settings.gradle 파일을 생성한다
우리의 서비스 명은 'Cupeed'이다
각 서버의 폴더명은 config가 아니라 'com.sparta.cupeed.config'이다

rootProject.name = 'Cupeed'

include 'config', 'eureka', 'gateway', 'user', 'order', 'product', 'company', 'hub', 'hubroute', 'delivery', 'ai', 'slack'

project(':config').projectDir = file('com.sparta.cupeed.config')
project(':eureka').projectDir = file('com.sparta.cupeed.eureka')
project(':gateway').projectDir = file('com.sparta.cupeed.gateway')
project(':user').projectDir = file('com.sparta.cupeed.user')
project(':order').projectDir = file('com.sparta.cupeed.order')
project(':product').projectDir = file('com.sparta.cupeed.product')
project(':company').projectDir = file('com.sparta.cupeed.company')
project(':hub').projectDir = file('com.sparta.cupeed.hub')
project(':hubroute').projectDir = file('com.sparta.cupeed.hubroute')
project(':delivery').projectDir = file('com.sparta.cupeed.delivery')
project(':ai').projectDir = file('com.sparta.cupeed.ai')
project(':slack').projectDir = file('com.sparta.cupeed.slack')

이렇게 설정하면, 루트 하나로 모든 하위 서비스의 Gradle 빌드를 관리할 수 있다.
각 서비스 내부에 존재하던 settings.gradle 파일은 삭제해야 충돌이 나지 않는다.

3. 확인

위와 같이 설정하면 IntelliJ에서 아래와 같이 관리가 가능하다

최상위 폴더에서 .gitignore을 추가해 프로젝트를 시작한다

[스프링] 왜 application.properties의 한글은 깨질까?

believekim — Tue, 4 Nov 2025 15:03:32 +0900

스프링으로 개발을 하다보면 application.properties란 파일을 만난다.
완성 후 깃허브에 코드를 올리고 나중에 확인해보면 주석이 모두 ??로 바뀌어 있다.

1. 인코딩

인코딩(Encoding)은 “문자”를 “숫자(바이트)”로 바꾸는 규칙이다.
https://start.spring.io/에서 프로젝트를 만든 후에 src/main/resources/application.properties를 IntelliJ로 열어보면 아래의 인토딩정보가 나온다. 기본값은 ISO-8859-1이다

UTF-8 = 국제 표준
ISO-8859-1 = 구시대 유럽 문자 인코딩

인코딩	특징
UTF-8	전 세계 문자 지원, ASCII 호환, 웹 표준
UTF-16	2~4바이트로 문자 표현, Windows 시스템 친화적
US-ASCII	영어만 표현 가능
ISO-8859-1 (Latin-1)	유럽 문자 지원, 한글·일본어 불가능

2. 왜 .properties는 ISO-8859-1을 기본으로 쓸까?

.properties 파일은 원래 Java 초창기 (JDK 1.0 시대) 부터 있던 포맷으로
그때는 국제화(i18n) 개념이 약해서, Java는 .properties를 ISO-8859-1로 강제 인코딩.
Spring Boot 2.4+ 이후에는 다음 설정을 추가하면 UTF-8을 강제할 수 있다.

spring.config.encoding=UTF-8

3. 왜 .yml은 UTF-8이 기본일까?

YAML은 JSON과 마찬가지로 UTF-8을 기본 인코딩으로 설계했어요.
.yaml과 .yml을 둘다 사용한다. 특히 윈도우에서는 3글자로 통합하기에 .yml을 사용한다.

https://yaml.org/spec/1.2.2/#12-yaml-history

YAML Ain’t Markup Language (YAML™) revision 1.2.2

yaml.org

4. IntelliJ에서 설정방법

Settings -> Editor -> File Encodings에서 인코딩을 설정할 수 있다.
Global Encoding → UTF-8
Project Encoding → UTF-8

5. 왜 UTF-8이 표준인가?

모든 문자(한글, 이모지, 아랍어 등) 표현 가능
다른 인코딩과의 충돌 최소화
JSON, YAML, HTML, Markdown 등 대부분 UTF-8 기반
Spring Boot도 점점 UTF-8로 통일되는 방향

[CS] Inside-Out vs Outside-In TDD의 두 가지 접근법

believekim — Mon, 3 Nov 2025 03:48:35 +0900

TDD개발방법론을 공부하다보니
두가지의 접근법을 알게되어 정리해보았다.
결론부터 말하면 무엇이 더 좋은 것은 없고 상황에 따라 모두 정답이다.

1. 들어가며

“TDD는 테스트 먼저 짜는 거” 정도로만 알고 있었다.

테스트를 먼저 짜는게 익숙하지 않았기에

코드를 구현하기 시작하면 User객체를 만들고 나서

테스트를 작성하여 확인하며 진행했었다.

package com.example.tdd.domain;

public class User {
    private final String username;
    private int age;

    public User(String username, int age) {
        if (username == null || username.isBlank()) {
            throw new IllegalArgumentException("username은 비어있을 수 없습니다.");
        }
        if (age < 0) {
            throw new IllegalArgumentException("age는 음수일 수 없습니다.");
        }
        this.username = username;
        this.age = age;
    }

    public String getUsername() {
        return username;
    }

    public int getAge() {
        return age;
    }

    public void increaseAge() {
        this.age++;
    }

    public void updateAge(int age) {
        if (age < 0) throw new IllegalArgumentException("age는 음수일 수 없습니다.");
        this.age = age;
    }
}

테스트 코드

package com.example.tdd.domain;

import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

import static org.assertj.core.api.Assertions.assertThat;
import static org.assertj.core.api.Assertions.assertThatThrownBy;

class UserTest {

    @Test
    @DisplayName("생성자: 정상 입력 시 User 객체 생성")
    void createUser_success() {
        User user = new User("alice", 25);

        assertThat(user.getUsername()).isEqualTo("alice");
        assertThat(user.getAge()).isEqualTo(25);
    }

    @Test
    @DisplayName("생성자: username이 비어있으면 예외 발생")
    void createUser_invalidUsername() {
        assertThatThrownBy(() -> new User("", 25))
            .isInstanceOf(IllegalArgumentException.class)
            .hasMessageContaining("username");
    }

    @Test
    @DisplayName("생성자: age가 음수이면 예외 발생")
    void createUser_invalidAge() {
        assertThatThrownBy(() -> new User("alice", -1))
            .isInstanceOf(IllegalArgumentException.class)
            .hasMessageContaining("age");
    }

    @Test
    @DisplayName("나이 증가")
    void increaseAge() {
        User user = new User("bob", 30);
        user.increaseAge();
        assertThat(user.getAge()).isEqualTo(31);
    }

    @Test
    @DisplayName("나이 업데이트")
    void updateAge() {
        User user = new User("carol", 20);
        user.updateAge(35);
        assertThat(user.getAge()).isEqualTo(35);
    }
}

아직 테스트부터 짜는것조차 익숙하지 않다.

하지만 어디서부터 테스트를 시작하느냐에 따라 전혀 다른 개발 방식이 된다.

2. Inside-Out 방식이란? (Bottom-Up TDD)

가장 작은 단위(클래스, 메서드)부터 테스트를 작성하는 전통적인 TDD 스타일
빠른 피드백, 내부 설계에 집중 가능
하지만 전체 흐름(사용자 시나리오)은 나중에 확인된다.

@Test
void increaseAge_whenCalled_incrementsAge() {
    User user = new User("alice", 25);
    user.increaseAge();
    assertThat(user.getAge()).isEqualTo(26);
}

@Test
void updateAge_whenValidAge_updatesAge() {
    User user = new User("bob", 30);
    user.updateAge(35);
    assertThat(user.getAge()).isEqualTo(35);
}

장점

디버깅, 리팩토링 쉬움
도메인 로직 테스트에 적합

단점

사용자 요구 반영이 늦음
상위 레이어 변경 시 영향도가 큼

3. Outside-In 방식 (Top-Down TDD / London School)

사용자 또는 외부 시스템 관점에서 테스트를 먼저 작성
전체 시나리오 테스트 후, 필요한 내부 컴포넌트를 Mock으로 대체하며 구현
사용자 시나리오 → 서비스 → 도메인 → 레포지토리 순으로 테스트와 구현을 점진적으로 확장하는 방식

"이 기능이 최종적으로 이렇게 동작해야 한다"를 먼저 정의하고

그 기능을 만들기 위해 필요한 내부 클래스나 메서드는 Mock을 사용해서 흉내만 내는 것

// 사용자를 등록하면, UserRepository에 저장되고 기본 나이가 0이어야 한다
@Test
void registerUser_whenValidInput_createsUserWithDefaultAge() {
    UserRepository userRepository = mock(UserRepository.class); // 실제 DB 없이 흉내
    UserService userService = new UserService(userRepository);

    User user = userService.registerUser("carol");

    assertThat(user.getUsername()).isEqualTo("carol");
    assertThat(user.getAge()).isEqualTo(0); // 기본 나이
    verify(userRepository).save(user); // 실제 DB 호출 확인
}

테스트를 작성한 후, 테스트가 통과하도록 실제 UserService와 User 클래스를 구현

class User {
    private String username;
    private int age;

    public User(String username) {
        this.username = username;
        this.age = 0; // 기본 나이
    }

    public String getUsername() { return username; }
    public int getAge() { return age; }
}

class UserService {
    private final UserRepository userRepository;

    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    public User registerUser(String username) {
        User user = new User(username);
        userRepository.save(user);
        return user;
    }
}

장점

사용자 시나리오 중심 → 비즈니스 가치에 집중
Hexagonal Architecture와 자연스럽게 연계 가능
Mock 활용으로 빠른 피드백 유지

단점

Mock 과다 사용 시 테스트 깨짐 가능
인터페이스 설계 부담이 있음

3. 정리

Inside-Out은 “엔진부터 조립해서 자동차 완성”
Outside-In은 “운전자가 원하는 경험부터 설계하고 엔진을 맞춰감”

구분	Inside-Out (Bottom-Up)	Outside-In (Top-Down)
시작점	도메인, 내부 로직	사용자 시나리오, API
테스트 순서	Domain → Service → Controller	Controller → Service → Domain
중심 사고	내부 설계, 객체 책임	사용자 가치, 시나리오
도구 활용	단위 테스트 중심	Mock, 인수 테스트 중심
장점	빠른 피드백, 리팩토링 용이	비즈니스 요구에 초점, UI 연동 쉬움
단점	외부 흐름 반영 늦음	내부 설계 복잡도 높을 수 있음

Inside-Out과 Outside-In은 TDD에서만 쓰이는 용어가 아니었다.
https://brunch.co.kr/@mime3/2

Inside-out, Outside-in

대기업 n년차라면 스스로에게 물어야 하는 것 | 링크드인에서 흥미로운 글을 읽었다. 범선과 크루즈에 비유한 대기업 직원과 스타트업 창업자 얘기다. 범선은 바람이 적당히 불고 큰 돛대를 달

brunch.co.kr

Inside-Out: 내부 관점에서 시작
- 소프트웨어: 도메인/클래스 중심 → 외부 시나리오 연결
- 마케팅: 자사 제품·강점 중심 → 고객에게 제공
- 전략/인사: 조직 역량 중심 → 외부 시장이나 직원 요구 대응
Outside-In: 외부 관점에서 시작
- 소프트웨어: 사용자 시나리오/인수 테스트 중심 → 내부 구현 연결
- 마케팅: 고객 요구·니즈 중심 → 내부 역량 조정
- 전략/인사: 시장/직원 요구 중심 → 조직 역량 최적화

[CS] 패키지 구조 선택하기(Package by Layer vs Package by Feature vs Hexagonal Architecture)

believekim — Fri, 31 Oct 2025 23:09:52 +0900

프로젝트를 진행하다보면 가장 먼저 떠오르는 고민이
"패키지 구조를 어떻게 가져갈 것인가?"이다.
그래서 여러가지 패키지구조를 비교해보았다.

0. 참고자료

기본적으로 아래의 사이트를 참고하여 작성하였다.

https://medium.com/sahibinden-technology/package-by-layer-vs-package-by-feature-7e89cde2ae3a

Package by Layer vs Package by Feature

Which one should we use? And why?

medium.com

1. Layered Architecture

소프트웨어를 역할(role) 기반으로 나눈 전통적인 구조
“서비스는 비즈니스 로직만 담당해야 하고, 데이터 접근은 리포지토리가 담당해야 해” 라는 설계 원칙

Presentation (Controller)
↓
Business (Service)
↓
Persistence (Repository)

특징

UI → 비즈니스 → 데이터 순으로 흐름이 고정
각 계층은 아래 계층에 의존 (단방향)
기술 스택과 계층이 1:1 대응

⚠️ 한계

계층 간 강한 결합 (Controller → Service → Repository로 의존 연결)
기능 단위로 이동하려면 여러 계층을 건너야 함
기능 추가 시 여러 패키지를 수정해야 함

2. Package by Layer

Layered Architecture를 그대로 코드 패키지 구조로 옮긴 형태

├── com.app
    └── controller
        ├── CompanyController
        ├── ProductController
        └── UserController
    └── model
        ├── Company   
        ├── Product
        └── User
    └── repository
        ├── CompanyRepository   
        ├── ProductRepository
        └── UserRepository
    └── service
        ├── CompanyService
        ├── ProductService
        └── UserService
    └── util

특징

한눈에 “역할별 클래스”를 찾기 쉬움
Layered Architecture와 거의 동일한 개념

⚠️ 한계

낮은 응집도: 같은 기능에 속한 코드가 여러 패키지로 흩어짐
높은 결합도: Repository 변경 시 Controller까지 영향
확장성 부족: 기능이 늘수록 Controller/Service 패키지가 거대해짐

3. Package by Feature

Layered 철학에서 벗어나 “도메인 단위로 구조를 짜자!”는 대안적 구조
각 기능(feature) 안에 controller, service, repository 배치

├── com.app
    └── company
        ├── Company
        ├── CompanyController
        ├── CompanyRepository        
        └── CompanyService
    └── product
        ├── Product   
        ├── ProductController
        ├── ProductRepository
        └── ProductService
    └── util
    └── user
        ├── User   
        ├── UserController
        ├── UserRepository
        └── UserService

특징

같은 기능에 필요한 코드가 모두 한곳에 모임(높은 응집도, 낮은 결합도)
기능 단위로 이동, 테스트, 배포가 쉬움
캡슐화 강화 (패키지 내부에서 private 접근 가능)
마이크로서비스로 전환 용이

⚠️ 단점

처음 구조 설계 시 통일성이 필요
공통 로직(util 등) 관리 어려움

4. Hexagonal Architecture

Ports and Adapters 패턴이라고도 불림
비즈니스 로직(Core) 을 외부 의존성(Web, DB, Message Broker 등) 으로부터 완전히 분리하는 아키텍처
1. Core (Domain + Application): 순수한 비즈니스 로직
2. Ports: Core가 외부와 소통하기 위한 인터페이스 (InputPort, OutputPort)
3. Adapters: 실제 구현체 (Controller, Repository 등)

├── com.app
    ├── company
    │   ├── application              # 유스케이스(서비스 계층)
    │   │   ├── CompanyService.java  # 핵심 비즈니스 로직
    │   │   └── CompanyUseCase.java  # Port(인터페이스)
    │   │
    │   ├── domain                   # 도메인 엔티티 + 도메인 로직
    │   │   └── Company.java
    │   │
    │   ├── infrastructure           # 외부 시스템과 연결되는 Adapter
    │   │   ├── persistence
    │   │   │   ├── JpaCompanyRepository.java  # Output Adapter (DB 구현체)
    │   │   │   └── CompanyEntity.java
    │   │   └── web
    │   │       └── CompanyController.java     # Input Adapter (API 진입점)
    │   │
    │   └── ports                    # 외부 의존성에 대한 Port 정의
    │       ├── in
    │       │   └── CompanyUseCase.java        # Input Port (Controller → Core)
    │       └── out
    │           └── CompanyRepositoryPort.java # Output Port (Core → Infra)
    │
    ├── product
    │   ├── application
    │   │   └── ProductService.java
    │   ├── domain
    │   │   └── Product.java
    │   ├── infrastructure
    │   │   ├── persistence
    │   │   │   └── JpaProductRepository.java
    │   │   └── web
    │   │       └── ProductController.java
    │   └── ports
    │       ├── in
    │       │   └── ProductUseCase.java
    │       └── out
    │           └── ProductRepositoryPort.java
    │
    └── util

특징

핵심 도메인(domain)은 외부 환경(DB, Web 등)과 완전히 분리됨
“의존성 역전(Inversion of Dependency)”을 통해 내부가 외부를 제어
외부 교체(DB → NoSQL 등) 시 도메인 영향 없음
단위 테스트 용이 (mock port 활용 가능)
DDD(Domain-Driven Design)와 자연스럽게 맞물림

⚠️ 단점

설계 복잡도 높음
작은 프로젝트엔 오버엔지니어링이 될 수 있음

5. 정리

[1] Layered Architecture (철학)
         ↓
[2] Package by Layer (구현 구조)
         ↓
[3] Package by Feature (도메인 중심 재구성)
         ↓
[4] Hexagonal Architecture (의존성 역전, 포트/어댑터 분리)

구분	Layered Architecture	Package by Layer	Package by Feature	Hexagonal Architecture
구조 기준	계층(역할 중심)	계층(패키지 중심)	기능(도메인 중심)	포트/어댑터(도메인 중심)
응집도	낮음	낮음	높음	매우 높음
결합도	높음	높음	낮음	매우 낮음
유지보수성	보통	낮음	높음	매우 높음
테스트 용이성	낮음	낮음	높음	매우 높음
마이크로서비스 전환	어려움	어려움	쉬움	매우 쉬움
설계 난이도	쉬움	쉬움	중간	어려움
적용 시점	초기, 간단한 서비스	학습, 소규모 프로젝트	중규모 이상 프로젝트	대규모, DDD 기반 시스템

소프트웨어 아키텍쳐 연대기라는 글을 보았다.
세상엔 아키텍쳐가 너무 많다.

https://herbertograca.com/2017/07/03/the-software-architecture-chronicles/

[IntelliJ] TODO, FIXME와 커스텀 주석 활용법

believekim — Thu, 30 Oct 2025 15:47:23 +0900

코드를 작성하다가 주석이 많아지다보니 코드를 설명한 주석과
구현하거나 고쳐야할 주석을 구분하기가 어려워져 작성하게 되었다.

1. 주석 예시

IntelliJ 공식 문서는 기본기능과 커스텀 주석을 만드는 방법만 나와있다.

https://www.jetbrains.com/help/idea/using-todo.html

TODO comments | IntelliJ IDEA

www.jetbrains.com

기본 기능은 TODO와 FIXME가 있고 View -> Tool Windows -> TODO를 클릭하면 확인할 수 있다

하지만 주로 쓰이는 주석은 다음과 같다고 GPT에 검색했다.

태그	의미	예시
NOTE	참고용 메모	// NOTE: DB 커넥션은 풀링 중
REVIEW	리뷰 필요	// REVIEW: 이 로직 복잡도 높음
OPTIMIZE	성능 개선	// OPTIMIZE: 반복문 줄이기
HACK	임시 해결책	// HACK: 예외 회피용 코드, 임시 하드코드
BUG	버그 표시	// BUG: 간헐적 실패 발생
DEPRECATED	사용 중단 예정	// DEPRECATED: 다음 버전에서 제거

2. 커스텀 주석 설정 방법

Settings -> Editor -> TODO로 들어간후 +버튼을 사용해 추가한다.

기능 확인

3. 커스텀 주석 그룹화

TODO설정창 아래 Filters에서 +버튼을 클릭한다.
Name을 지정하고 커스텀주석 항목을 선택하여 적용한다.

Filter TODO Items(깔대기모양)을 클릭하면 그룹화된 내용만 따로 볼 수 있다.

4. 플러그인

NextTask TODO Manager는 JetBrains IDE에 필요한 유일한 작업 관리 플러그인입니다.
아직은 나에게 과분한거 같아 설치하지는 않았다.

https://plugins.jetbrains.com/plugin/26765-nexttask-todo-task-manager

NextTask TODO Task Manager - IntelliJ IDEs Plugin | Marketplace

NextTask TODO Task Manager Plugin Source Code NextTask TODO Manager is the only task management plugin for JetBrains IDEs you will need. Allows you to track, organize...

plugins.jetbrains.com

개발스토리지

[깃허브] Gist로 깃허브 꾸미기

1. Github Gist란?

2. Gist 생성

3. Github 환경변수 등록

4. Git Action 파일 생성

5. 결과 확인

[깃허브] 깃허브 README 애니메이션 꾸미기 (pecman, snake)

1. 들어가며

2. pecman 적용

3. snake 적용

4. Git Animals

5. 트러블슈팅

역시 코딩보다 재밌다

[쉘스크립트] MSA 개발 환경에서 여러 서버 포트 종료 자동화스크립트 For MacOS

1. kill_duplicate_servers.sh 작성

2. 실행방법

3. 결과화면

[RestFul API] PUT vs PATCH vs POST, 언제 어떤 메서드를 써야 할까?

1. RESTful API 설계의 기본 원칙

2. PUT vs PATCH vs POST의 개념 비교

멱등성(Idempotency)이란?

3. 실무에서의 적용 기준

✅ PUT (전체 교체)

✅ PATCH (부분 수정)

✅ POST (행동 또는 생성)

[자바] 왜 if-else를 쓰지 말라고 할까? - 클린 코드와 테스트 관점에서

1. 문제 코드 — if-else가 많은 코드

2. Early Return으로 개선

3. Map으로 개선

4. Enum으로 개선

5. 비교

[IntelliJ] Spring Cloud 기반 MSA 프로젝트 여러 서버를 관리하는 gradle 초기설정

1. MSA 프로젝트 구조 개요

2. 루트 경로에 settings.gradle 설정

3. 확인

[스프링] 왜 application.properties의 한글은 깨질까?

1. 인코딩

2. 왜 .properties는 ISO-8859-1을 기본으로 쓸까?

3. 왜 .yml은 UTF-8이 기본일까?

4. IntelliJ에서 설정방법

5. 왜 UTF-8이 표준인가?

[CS] Inside-Out vs Outside-In TDD의 두 가지 접근법

1. 들어가며

2. Inside-Out 방식이란? (Bottom-Up TDD)

장점

단점

3. Outside-In 방식 (Top-Down TDD / London School)

장점

단점

3. 정리

[CS] 패키지 구조 선택하기(Package by Layer vs Package by Feature vs Hexagonal Architecture)

0. 참고자료

1. Layered Architecture

특징

⚠️ 한계

2. Package by Layer

특징

⚠️ 한계

3. Package by Feature

특징

⚠️ 단점

4. Hexagonal Architecture

특징

⚠️ 단점

5. 정리

[IntelliJ] TODO, FIXME와 커스텀 주석 활용법

1. 주석 예시

2. 커스텀 주석 설정 방법

3. 커스텀 주석 그룹화

4. 플러그인

✅ `PUT` (전체 교체)