지글지글

One More Second - 탄막 슈팅 게임 웹 서비스

kbk5675 — Sun, 15 Feb 2026 02:17:10 +0900

https://onemoresecond.site/

ONE MORE SECOND

onemoresecond.site

돌연변이 테스팅

이제부터100도씨 — Mon, 15 Sep 2025 20:13:44 +0900

돌연변이 테스팅

우선 돌연변이 테스팅은 명령문( <, <=, == 등) 에 대해 변경을 가하여 테스트하는 기법으로 보인다.

https://www.reddit.com/r/programming/comments/1fub9dw/what_is_mutation_testing_and_why_you_should_use/?tl=ko

최근 회사동료와 같이 프로젝트를 진행하며 작성한 테스트 코드에서 힌트를 얻었다.
enum상수의 추상 메소드를 테스트하는 것이었는데, 반환타입을 인터페이스의 구현체 중 아무거나로 변경하여 테스트를 수행해도 깨지지 않았다는 것이다.

아래는 sample code이다. 이렇게만 test case을 작성하진 않겠지만, 예시임을 이해하라.

class CarTest {

    @Test
    fun testCarName() {
        val kia = Car.KIA.make()
        val honda = Car.HONDA.make()

        kia.name shouldBeEqual Car.KIA.name
        honda.name shouldBeEqual  Car.HONDA.name
    }
}

enum class Car {
    KIA {
        override fun make() = Kia(this.name)
    },
    HONDA {
        override fun make() = Honda(this.name)
    },
    ;

    abstract fun make(): Cars
}

interface Cars {
    val name: String
    fun isDomestic(): Boolean
}

class Kia(override val name: String) : Cars {
    override fun isDomestic() = true
}

class Honda(override val name: String) : Cars {
    override fun isDomestic() = false
}

테스트에 대한 경험이 충분하다면 위 테스트 케이스가 잘못되었거나(부족) 하다는 것을 쉬이 알 수 있을 것이다.
나는 이 테스트 코드를 보고, 돌연변이 테스팅 기법이 떠올랐다.

만약 Car enum class의 HONDA 상수의 make() 반환 클래스를 Kia 로 변경하여도 위 테스트는 문제 없이 동작할 것 이다.

enum class Car {
    KIA {
        override fun make() = Kia(this.name)
    },
    HONDA {
        override fun make() = Kia(this.name)
    },
    ;

    abstract fun make(): Cars
}

name property로 this.name을 던지고 있기 때문에, 올바른 상수의 name이 전달된다. 뭐, 단순히 conflict resolve의 실수라고 해보면 테스트 코드가 이를 커버하지 못했다고 볼 수 있다.

돌연변이 테스팅이 필요한 기법이다, 아니다를 말하기에는 사용해본적이 없어서 아쉽지만 적어도 이러한 기법을 알았기 때문에 위 테스트 코드가 부족함을 아는데에 도움이 되었다고 본다.

[Line corp] Kotlin-jdsl commit 쪼개기-1

이제부터100도씨 — Sun, 31 Aug 2025 17:27:15 +0900

init 커밋이 무려 1만줄이 넘는 변경사항있다.
첫 커밋을 혼자 분석해보는 것도 재미있겠지만, 해보고 싶은 게 많은 나는 ai 의 도움을 받기로 했다.

gemini-cli도 고려해보았지만, 사용중이던 windsurf을 우선 사용해보기로 했다. agent 기능을 쓸 일은 없을 것 같긴하지만..

우선 전체적인 구조 파악을 위해 프로젝트 분석을 시켜두었다.

전체적인 내용을 확인해보고, 이제 각 모듈을 분석해 볼 차례이다.

효율적으로 분석하기 위해, claude 에게 순서를 추천 받았다.

이 순서대로 init commit을 쪼개보겠다

[Effective Software Testing] chapter_2

이제부터100도씨 — Sat, 30 Aug 2025 16:21:07 +0900

프로그램(기능)의 요구사항(기획서?)을 바탕으로 정의된 명세를 기반으로 테스트를 진행한다.
기능 구현 후, 요구사항에 맞게 잘 구현되었는지 확인하기 위해 먼저 시도해볼 수 있다.

1. 요구사항과 입출력에 대해 이해하기

프로그램(method)을 3단계로 분석한다.

메서드가 무엇을 수행하는가? (비즈니스 로직)
메서드가 무엇을 입력으로 받는가?
메서드가 무엇을 출력하는가?

2. 여러 입력값에 대해 프로그램이 수행하는 바를 탐색하기

이 메서드가 어떤 기능을 구현했는가를 탐색하는 단게이다. (비즈니스 로직 분석 단계)
내가 작성한 코드라면 skip 해도 되지만, 남이 작성한 코드를 테스트할 때 거치는 단계이다.

예상할 수 있는 입력값들을 통해 해당 메서드를 파악하면 된다.

처음 구매한 기기를 탐색해보는 과정으로 느껴진다

3. 테스트 가능한 입출력과 구획을 탐색하기

효율적인 입/출력 테스트를 위해 구획화 하는 단계이다.
간단한 예시로, 장바구니 기능을 구현하였다고 해보자. 최대 10개까지만 담을 수 있는 장바구니라면, 3개를 담아보는 입력과 4개를 담아보는 입력은 동등한 입력이므로 작성할 필요가 사라진다.

내가 전달하는 입력은 어떤 부류인가?
각 입력들의 조합에 대해 무엇이 가능한가?
어떠한 출력들이 가능한가?

4. 경계 분석하기

소프트웨어의 버그는 경계에서 흔하게 발생한다.
최대 10개 까지의 장바구니 였다면, 10이라는 값이 경계라고 볼 수 있다.

접점: on point 경계 위에 있는 점
거점: off point 다른 구획에 있으면서, 접점과 가장 가까운 점
접점은 10 이다. 거점은 11 이라고 보는데 1 ~ 10은 정상동작, 11부터는 비정상동작으로 보이므로 다른 구획(?)에 존재하면서 10과 가장 가까운 점이다.
내점: in point 항상 참인 점
외점 out point 항상 거짓인 점

5. 테스트 케이스 고안하기

각 입력을 조합하는 단계이다
위는 간단한 구현이므로 조합이 많지 않지만, 해당 메서드가 복잡하다면 예를 들어 가격은 30_000₩ 까지만, 각 품목은 5개까지만, 카테고리는 음식만 등의 요구사항 또는 파라미터가 생기게 되면 조합은 더욱 많아진다. 따라서 필요없는 조합은 제거한다.

예외 케이스 구획화 (가격이 0원, 품목의 갯수가 0개, 존재하지 않는 카테고리 등)
각 요구사항 구획화 ( 가격 유효성, 품목 유효성 등)
- 카테고리가 음식이 아닌 경우
- 가격이 30_000₩이 넘는 경우
- 품목의 갯수가 5개 넘는 경우
총 갯수가 10개 초과 일 때 여러 품목의 합이 10개 초과
총 갯수 10개 이하

6. 테스트 케이스 자동화하기

자동화 라고 해서 거창해보이지만, JUnit 과 같은 테스트 프레임워크로 테스트를 작성함을 말한다.
각 테스트 케이스에 맞는 입력을 만들어 테스트를 작성하면 된다.

7. 창의성과 경험을 발휘해서 테스트 스위트를 강화하기

우리가 작성했던 테스트 케이스에 빠진 부분이 있는지 검사하는 단계이다
위 장바구니 예제에서 빠진 부분을 찾으면 되는데, 아직 보이지는 않는다. 굳이 만들어보자면, 해외 상품을 장바구니에 담는 경우가 있을 것 같다.
해외($)라면, 매일 환율에 영향을 받으므로 오늘 환율에서는 통과가 되었지만 환율 변동으로 인해 30_000₩ 이라는 요구사항을 만족하지 못하는 테스트 케이스가 있을 것 같다.

스터디 4기 - In dark 웹 사이트 기반 게임 만들기 - 로그인 구현

kbk5675 — Wed, 27 Aug 2025 01:14:12 +0900

기획 단계에 이어 로그인 페이지 기획과 화면 구현을 진행하였습니다.

게임을 진행 및 저장을 위해서는 유저 정보가 가장 먼저 필요해서 첫번째 순서로 진행합니다.

1. 로그인 기획

첫 방문 진입 흐름

첫 화면 = 로그인 화면(전용 라우트 or 모달)
구글 소셜 로그인 및 개인 이메일 로그인
계정 연동 시 커뮤니티/채팅/진행도 동기화
cloude firebase 에 유저 정보 저장
테마 연출: 커서 위치를 중심으로 횃불 스포트라이트(radial-gradient) 효과로 어두운 배경을 밝히는 컨셉

2. 기획에 따른 구현

firebase 프로젝트 등록 진행

이후에 firebase에서 얻은 api key를 내 웹 프로젝트에 적용.

인증 메뉴에서 이메일 및 구글 인증 허용 설정

기획한 테마 및 UI 를 구현

이렇게 로그인 단계를 구현 완료했고, vercel을 통해 프론트 배포 진행도 완료했습니다.

문제점

은 firebase auth api-key가 vite의 .env.local로 관리되도록 했었는데, 이 부분 때문에 다른 컴퓨터에서 .env.local 파일이 없는 사용자는 페이지가 먹통이었던 문제가 있었습니다.

해결 방법

vercel의 환경 변수 설정 페이지가 있는데, 그 곳에서 .env 파일을 생성해 첨부해주면 firebase의 인증키 값을 넣을 수 있고 배포 시 환경 변수 설정이 되어 다른 사용자도 접근이 가능해집니다. firebase 인증 키는 다른 사용자가에게 보여져도 되는 키 값이라 이렇게 환경 변수 설정 쪽에 넣었으나, 관리자 키 값같은 다른 사람에게 비밀이 되어야할 키 값은 넣으면 안됩니다.

vercel 프로젝트의 환경변수 설정 세팅 페이지

로그인 시, 사용자의 로그인 정보는 cloude DB에 저장됩니다.

cloude firebase에 생성된 로그인 정보

이후 게임의 메인 페이지에 접속됩니다. 다음 시간에는 게임의 생명주기를 구현하고, 게임을 플레이할 수 있도록 구현 예정입니다~

스터디 4기 - In dark 웹 사이트 기반 게임 만들기 - 기획 단계

kbk5675 — Wed, 27 Aug 2025 01:01:37 +0900

웹 기반의 게임 프로젝트를 시작하려합니다.

평소에 만들고 싶던 '던전 탐험' 게임 + 커뮤니티의 웹사이트를 만들어보고 싶었는데 이 기회에 만들어 볼 겁니다.

게임 기획 & 아키텍처 설계 - GPT 이용

에셋 생성 - GPT 이용

코드 구현 및 생성 - Cursor, Codex

내가 만들고 싶던 게임의 모호한 계획과 방향성을 GPT 와 의논하면서 상세히 정리하는 것부터 시작.
여러 프롬프트를 거친 결과, 아래와 같은 기획이 나왔습니다.

게임 방향성과 목적 기획

1. 세계관 및 설정

주인공: 알 수 없는 이유로 미궁에서 깨어난 존재. 기억도 배경도 없음.
미궁: 끝을 알 수 없는 어둡고 불길한 공간.
- 빛이 거의 없고, 플레이어는 오직 횃불 하나에 의존.
- 어둠 속에서는 “볼 수 없다”라는 제약이 게임플레이의 본질이 됨.

2. 플레이 목적

단순히 탈출이나 보스 처치가 목표가 아님.
핵심은 “탐험 과정에서의 경험을 기록하고 공유하는 것”.
플레이어는 캡처 기능을 활용해:
- 특이현상 (이상한 벽, 빛의 틈새, 미지의 문양)
- 괴물 (공포스러운 존재, 스쳐 지나간 그림자)
- 보물 (의문스러운 아이템, 쓸모없는 잡동사니)
- 이벤트 (다른 모험가의 흔적, 기묘한 장치)
  등을 발견하고 기록 + 커뮤니티 업로드

3. 게임 목표

개인적으로는 미궁을 “계속 헤매는 경험”을 즐기는 것.
메타적으로는 커뮤니티 게시판을 채우는 것이 게임의 궁극적인 목표.
- 플레이어들이 남긴 게시글과 스크린샷이 쌓여서, 미궁의 집단적 기록이 형성됨.
- 어떤 현상은 여러 사람이 같은 걸 보고 토론할 수도 있고, 누군가가 처음 발견하는 레어한 현상도 있음.

4. 차별 포인트

보통의 던전 탐험은 전투 → 보상 구조인데, 여기서는 발견 → 기록 → 공유 구조.
이 게임은 커뮤니티가 곧 백과사전이 되고, 세계관 해석이 플레이어들 손에 달려 있음.
즉, “게임 + SNS + 집단적 탐험기록”이 결합된 형태.

그리고 게임 플레이 생명 주기에 대해서도 모호하게 생각되던 내용들도 GPT와 같이 정리해봤습니다.
아래는 그 결과입니다.

플레이어 행동 패턴 정리

1. 방 이동하려 할 때

입장: 새로운 방으로 들어감.
머무르기: 현재 방에 남아서 다른 행동(탐색, 휴식, 준비)을 할 수 있음.

2. 방에 입장했을 때

살펴보기: 방 안의 구조, 단서, 숨겨진 요소를 확인.
- (확률적으로 이벤트 발생: 특이현상, 숨겨진 길, 트랩 등)
줍기: 방 안의 아이템, 보물, 쓰레기(!)를 획득.
- (획득 → 인벤토리 저장 → 나중에 커뮤니티 캡처 공유 가능)

3. 몬스터를 만났을 때

공격: 기본 행동, 무기 또는 도구 사용.
방어: 피해를 줄이고 반격 기회 노림.
스킬: 캐릭터 고유 능력 활용 (쿨타임, 리소스 소비).

게임 UX 플로우 (간단 도식)

탐험 중
→ [이동 선택] → 입장 / 머무르기
새 방 입장 시
→ [행동 선택] → 살펴보기 / 줍기
→ (특정 확률로 이벤트 or 몬스터 조우)
몬스터 조우 시
→ [전투 행동] → 공격 / 방어 / 스킬
→ (결과에 따라 생존, 도주, 아이템 드랍)

UI 적용 아이디어

중앙 이미지 영역: 상황에 맞게 교체 (예: 빈 방, 아이템 있는 방, 몬스터 있는 방).
하단 버튼 UI는 상황에 따라 버튼 세트가 바뀌도록 설계.
- 이동 단계: [입장] [머무르기]
- 방 탐색 단계: [살펴보기] [줍기]
- 전투 단계: [공격] [방어] [스킬]

그리고 이런 플레이 생명주기를 만들면서 정리된 내용들을 통해 상세한 플레이어 상태머신 또한 구현할 수 있었습니다.

상태머신 개요

States

Idle 대기(방 선택 전)
Move.Select 이동 의사결정
Move.Entering 입장 처리 중
Room.Explore 방 내부 행동(살펴보기/줍기/머무르기)
Event.Resolve 특수 이벤트 처리(함정/NPC/기믹)
Combat.Decide 전투 선택(공격/방어/스킬/도주)
Combat.Resolve 데미지/드랍/사망 판정
Resting 휴식(자원 회복, 시간 경과)
Capture.Prompt 캡처/공유 팝업
GameOver 사망 또는 광원 소진 등으로 진행 불가

Resources(예시)

HP, MP, STA, Torch(횃불 게이지), Bag(인벤토리), Keys 등

주요 Guards(예시)

hasTorch(), hasSpaceInBag(), isDoorLocked(), isMonsterHere(), torchLow()

위와 같은 기획으로 명확한 프레임을 잡는데 큰 도움을 받을 수 있으며, 필요하면 유연하게 기획을 변경할 수도 있습니다.

지란스터디 4기 계획

lifehi — Sun, 3 Aug 2025 23:35:45 +0900

목표

유튜브 쇼츠 영상 누적 조회수 1000회 달성
AI 도구(Midjourney, HAILUO AI)를 활용
귀여운 동물(고양이 등)을 주제로 콘텐츠 실험

사용 도구

Midjourney: 고양이, 강아지, 토끼 등 귀여운 동물 이미지 생성
HAILUO AI: AI 영상 제작
CapCut: 영상 편집 및 자막 삽입
YouTube Shorts: 쇼츠 업로드 및 통계 분석

활동 일정

1주차

나비를 주제로 영상 제작 테스트 진행 (https://lifehi.tistory.com/5)
고양이를 주제로 Midjourney 이미지 -> HAILUO AI로 영상 제작

2주차

영상 1차 제작 (30~45초 분량)
쇼츠 업로드 및 해시태그 실험
성과 측정 (조회수, 좋아요, 댓글 등)

지란스터디 4기 계획

rlaehdehd7 — Sun, 3 Aug 2025 13:36:09 +0900

데이터베이스 실무 능력 기르기

목표

실전 데이터베이스 강의 수강
- 김영한의 실전 데이터베이스 - 기본편
프로그래머스 고득점 SQL Kit 문제 풀이
- 프로그래머스 SQL Kit

> 1~6주간(6주) 강의 수강 : 매주 섹션 2개씩 수강

> 7~8주간(2주) 문제 풀이 : 매일 풀이하는 문제 개수 다시 정하기

기대효과

> 더 나은 효율의 데이터베이스 설계와 쿼리에 대한 실력을 쌓을 수 있다

오픈소스에 내이름 박기

이제부터100도씨 — Wed, 16 Jul 2025 21:53:23 +0900

hypersistence-utils 오픈소스에 내 PR이 merge되었다.

hypersistenc-utils는 Vlad Mihalcea 가 관리하는 JPA(hibernate)을 사용하면서 겪는 불편함을 해소하기 위한 유틸리티 오픈소스이다. hibernate 6.x대와 7.x 대 모두 지원하고 있다. 그리고 hypersistence-optimizer도 운영중인데, hibernate을 사용할 때 여러 성능 이슈를 감지해주는 도구이다. 간단하게는 EAGER 로딩 전략을 감지해주기도 한다. Vlad Mihalcea는 자바 챔피언이자, hibernate 고수인데 이 분이 발간한 high-performance-java-persistence 라는 책이 있다. 구글에 서치 해보면 많은사람들이 이 책을 좋게 평가하고 있고, hibernate에 깊은 이해를 경험할 수 있다고 한다. 이번에 향로님이 인프런에 Vlad Mihalcea의 강의도 한국어 더빙판으로 제공하게 협업을 진행하셔서 최근 공부중인 테스트 코드와 TDD을 어느정도 마무리하면 high-performance-java-persistence책과 함께 수강해볼 예정이다. 기회가 된다면, 다음 스터디에서 진행해볼 듯 싶다.

오픈소스에 기여하게 된 이유

우선 내가 기여한 이슈를 간략히 설명하자면, @Tisd 은 @Id기반 컬럼에만 매핑되는 어노테이션이었다. (Tsid는 아래에서 설명하겠다) PrimaryKey외에 일반 컬럼에서도 @Tsid 을 적용하고 싶었고, 이에 대한 이슈가 이미 올라와있었다. 몇가지 확인을 한 뒤, ValueGenerationType 을 통해 구현하였다.

Tsid 란?

Time-Sorted Unique Identifiers 의 약자로 ULID와 Snowflake의 개념이 섞인 id생성 전략이다.
총 64비트를 사용하여 첫 42비트는 timestamp 값을, 하위 10비트는 node를 그리고 마지막 12비트는 counter값으로 사용하여 22비트의 random 비트를 사용하여 고유한 값을 제공한다. 물론 64비트를 사용하는 만큼 ULID보다는 충돌 가능성이 높다. 1ms 내에서 약 420만개(2^22)의 유일성을 보장한다. 자세한 설명과 사용법은 여기를 참고하거나, 구글 서치하면 많은 자료를 얻을 수 있다.

SnowFlake Id 나 Tsid 이 방식 모두 시간 역행에 대한 취약점?이 존재한다. 즉, 과거의 시간으로 id을 생성하게 되면 충돌이 발생하게 된다.
00-01-01 01 01 01
25-01-01T01:01:01.111111

오픈소스에 기여하며

지글지글 3기 공지사항

이제부터100도씨 — Wed, 16 Jul 2025 21:14:06 +0900

✏️ 지란 스터디 3기 공지사항

기간
2025년 6월 11일(수) ~ 7월 16일(수) (총 6주)

시간

수요일 18:00 ~ 21:00
스터디원*
[김동훈]([https://github.com/hunknownn], 임동윤, 오성찬, 김보근, 김동주

운영 방식

스터디는 매주 수요일에 진행됩니다.

주요 규칙

개인 프로젝트 기반 활동
6주 기간동안 2회 블로그 글 작성
양심에 맡겨 성실히 참여하기!

참고

글또