Developing

Questack 개발 일지 - 2026-05-30

montmer27 — Sat, 30 May 2026 22:31:11 +0900

오늘은 Questack의 수집 파이프라인을 live API 없이 검증 가능한 구조로 만드는 데 집중했다. 어제까지는 GitHub/RSS 수집, 랭킹, 브리핑 생성 기능이 동작하는 상태였다면, 오늘은 외부 서비스 상태와 무관하게 “수집기가 같은 입력에 대해 같은 결과를 내는지”를 테스트로 고정했다.

구현한 기능

첫 번째 작업은 GitHub 수집기 fixture replay 테스트였다. GitHub Search API 응답 예시를 src/test/resources/fixtures/github/search-repositories.json에 저장하고, 테스트에서 이 JSON을 GithubRepositorySearchResponse로 역직렬화하도록 했다. 실제 GitHub API를 호출하지 않고도 GithubCollector가 repository item을 CollectedItem으로 잘 정규화하는지 확인할 수 있게 된 것이다.

이 테스트에서는 다음 흐름을 검증했다.

GitHub fixture JSON을 client DTO로 읽기
GithubSearchClient mock이 fixture item을 반환
GithubCollector가 Source를 생성
repository title, summary, canonical URL, author, publishedAt을 CollectedItem에 저장
같은 fixture를 다시 replay하면 canonical URL 기준으로 duplicate skip

두 번째 작업은 RSS/Atom 수집기 fixture replay 테스트였다. RSS XML fixture와 Atom XML fixture를 각각 추가하고, MockRestServiceServer가 실제 feed URL 대신 fixture XML을 반환하도록 했다. 이 덕분에 live RSS feed에 접근하지 않고도 RssCollector의 fetch, parse, normalize, persist 흐름을 통합 테스트할 수 있게 됐다.

RSS replay 테스트에서는 다음을 검증했다.

RSS item과 Atom entry parsing
feed별 Source 생성
RssTextNormalizer를 통한 HTML 제거와 텍스트 정규화
link 없는 item skip
canonical URL duplicate skip
CollectedItemType.BLOG_POST 저장

오늘 작업으로 milestone의 앞쪽 두 이슈가 해결됐다.

#9 Add fixture replay tests for GitHub collection
#8 Add fixture replay tests for RSS collection

이제 Questack은 GitHub/RSS 수집 파이프라인을 live API 없이 재현 가능한 fixture로 검증할 수 있다. MVP Done Criteria 중 “A replay harness can test collection/ranking without live API calls”에 한 걸음 크게 가까워졌다.

트러블슈팅

첫 번째 문제는 GitHub replay 테스트를 추가한 뒤 기존 RankingServiceTest가 실패한 것이다. 에러는 DataIntegrityViolationException이었고, 원인은 sources.name unique 제약 충돌이었다.

여러 @SpringBootTest가 같은 H2 application context를 재사용할 수 있는데, 기존 ranking 테스트는 테스트 시작 전에 DB를 정리하지 않았다. 하네스 테스트가 늘어나면서 이전 테스트 데이터가 남아 Source("Test GitHub", ...) 저장 시점에 충돌이 발생했다.

해결은 명확했다. repository를 직접 사용하는 Spring Boot 테스트에서 @BeforeEach cleanup을 추가했다. FK 순서를 고려해 RankingScoreRepository, CollectedItemRepository, SourceRepository 순서로 정리했다. 이 내용은 TR-006으로 기록했다.

두 번째 문제는 RSS replay 테스트에서 MockRestServiceServer expectation을 중간에 다시 추가하다가 IllegalStateException이 난 것이다. 같은 테스트 안에서 첫 번째 replay 요청을 실행한 뒤, 검증/초기화 없이 두 번째 replay expectation을 추가한 것이 원인이었다.

해결은 첫 번째 rssCollector.collect() 직후 server.verify()와 server.reset()을 호출한 뒤 두 번째 expectation을 등록하는 방식이었다. 이 내용은 TR-007로 기록했다.

기술적 의사결정

오늘 추가된 결정은 두 가지다.

TD-017: GitHub 수집기는 fixture replay 테스트로 검증하기로 했다. live GitHub API 호출은 rate limit, 네트워크, 응답 데이터 변화에 영향을 받기 때문에 기본 테스트로 적합하지 않다. 대신 JSON fixture를 client DTO로 역직렬화하고, mock client가 반환하게 해서 수집기의 정규화 계약을 고정했다.

TD-018: RSS 수집기도 fixture replay 테스트로 검증하기로 했다. RSS feed는 외부 사이트 상태와 feed 내용 변화에 영향을 받기 쉽기 때문에, XML fixture를 통해 RSS/Atom parsing부터 persistence까지 검증하도록 했다. HTTP mock은 별도 라이브러리를 추가하지 않고 Spring test의 MockRestServiceServer를 사용했다.

두 결정 모두 기존 방향과 충돌하지 않는다. TD-012의 project harness 강화, TD-013의 RSS 통합, TD-015의 milestone/issue 기반 개발 플로우와 잘 이어진다.

Questack 개발 일지 - 2026-05-29

montmer27 — Fri, 29 May 2026 17:40:27 +0900

오늘은 Questack의 MVP 파이프라인을 “수집은 된다” 수준에서 한 단계 더 끌어올려, 실제 학습 자료로 읽을 수 있는 브리핑 품질과 개발 흐름 관리 방식을 정리했다. 큰 흐름은 RSS 수집기 완성, 브리핑 출력 개선, GitHub milestone 기반 작업 관리, 그리고 주제별 브리핑 생성 로직 개선이었다.

구현한 기능

첫 번째로 RSS/Atom 기술 블로그 수집기를 기존 CollectedItem 파이프라인에 통합했다. Spring Blog, NAVER D2, Kakao Tech feed를 설정하고, 각 feed item을 CollectedItem으로 정규화해 저장하도록 했다. 이로써 Questack은 GitHub repository뿐 아니라 기술 블로그 글도 같은 랭킹/브리핑 흐름에 태울 수 있게 됐다.

두 번째로 데일리 브리핑의 점수 표시 방식을 개선했다. 기존에는 백엔드 적합도, 학습 가치, 구현 가치가 Why it matters 문장 안에 섞여 있었는데, 항목 간 비교가 어려웠다. 이를 Markdown 표로 분리해서 Top 3 소재의 점수를 빠르게 비교할 수 있게 했다.

세 번째로 GitHub milestone과 issue를 개발 플로우에 통합했다. 남은 MVP 작업을 MVP Completion: Replay Harness to Mini Quest milestone으로 묶고, replay harness, ranking 품질 고정, RSS source 확장, mini project quest, reliability/cost guardrail, portfolio demo 작업을 issue로 나눴다. 이후 작업은 roadmap은 방향, milestone은 범위, issue는 작업 계약, PR은 검증 단위로 운영하기로 했다.

마지막으로 가장 중요한 개선은 데일리 브리핑 본문 생성 방식이다. 기존 2026-05-29.md를 보니 세 항목이 링크와 제목만 다르고 사실상 같은 템플릿 문장으로 작성되어 있었다. 이를 고쳐서 Summary 섹션을 추가하고, title, summary, ranking reasons를 기반으로 DB migration, Spring Boot 운영 모니터링, Spring AI, cache, messaging, auth 같은 주제별 프로필을 선택하도록 바꿨다. 이제 Why it matters, Backend interview angle, 30-minute study path, Mini project idea가 소재별로 다르게 생성된다.

트러블슈팅

RSS 수집 중 NAVER D2 feed의 description이 너무 길어 H2 컬럼 제한을 넘는 문제가 있었다. collected_items.summary는 2000자 제한인데 RSS description에는 HTML 본문 일부가 길게 들어올 수 있었다. 이 문제는 TR-005로 기록했고, RssTextNormalizer를 통해 HTML 태그 제거와 컬럼 길이 제한을 적용해 해결했다.

브리핑 개선 중에는 DailyBriefingService에 주제별 프로필 record를 추가하면서 중괄호 위치가 잘못 들어가 컴파일이 실패했다. ./gradlew test 실행 중 unnamed classes are a preview feature 오류가 나왔고, 원인은 writeMarkdown 메서드가 클래스 밖으로 밀려난 것이었다. 파일 하단 구조를 정리한 뒤 다시 테스트를 실행해 통과시켰다. 이건 재발 가능한 환경 이슈라기보다는 단순 편집 실수라 별도 TR로 남기지는 않았다.

기술적 의사결정

오늘 추가되거나 확인한 핵심 기술 결정은 세 가지다.

TD-013: RSS/Atom 기술 블로그 수집기를 CollectedItem 파이프라인에 통합했다. 별도 모델을 만들지 않고 GitHub와 같은 랭킹/브리핑 흐름을 재사용하기로 했다.

TD-015: 남은 MVP 작업은 GitHub milestone과 issue로 추적하기로 했다. 문서 기반 roadmap만으로는 PR 범위와 완료 상태가 흐려질 수 있어, milestone과 issue를 실제 개발 플로우에 연결했다.

TD-016: 데일리 브리핑은 고정 템플릿 반복이 아니라 주제별 학습 내용을 다르게 생성하기로 했다. LLM은 아직 MVP 필수 범위가 아니므로, 현재는 deterministic keyword/profile 기반으로 소재별 질문과 학습 경로를 다르게 만든다. 나중에 LLM을 붙이더라도 Top 3 같은 작은 대상에만 적용할 수 있도록 지금 구조를 1차 필터로 활용할 수 있다.

스파르타 내일배움캠프 Java Spring 백엔드 2기 수료 후기

montmer27 — Tue, 26 May 2026 14:31:45 +0900

(향후 3년간 유지 - 2029.05.25까지)

나는 내일배움캠프 자바 스프링 백엔드 2기 수료생이다.

작년 11월 중순부터 5월 19일까지, 약 5개월 좀 넘는 기간 해당 과정을 들었다.

우선, 미래 백엔드 취업을 위해 해당 과정을 고민 중이라면, 단연코 추천하고 싶다.

다음 세 가지 강력한 이유가 있다.

1. 프로젝트 중심 캠프

개발자는 프로젝트로 말해야 한다는 건 누구나 아는 사실이다. 어떤 캠프는 대학교 기말 과제처럼 하나의 프로젝트를 장기간 준비시킨다는데, 여기선 다양한 프로젝트를 아주 많이 경험할 수 있다. 짧게는 1주, 길게는 3주간 개인 프로젝트, 그룹 프로젝트가 교차되며 한 달에 최소 2개의 프로젝트를 경험하게 된다.

실제로 포트폴리오에 기재하게 될 프로젝트는 파이널 포함 1-2개 정도이겠지만, 중요한 건 프로젝트를 많이 경험하면서 쌓이는 경험치다.

개발자는 끊임없이 문제를 발견하고 개선해야 한다. 프로젝트가 많은 캠프는 프로젝트를 거듭하면서 아쉬웠던 부분을 여러 번 확인하게 되고, 이를 개선하면서 점점 데이터가 쌓인다. 그리고 이 모든 개선점이 파이널 프로젝트에서 빛을 발한다. (물론 파이널에도 개선할 점은 나올 것이다)

중요한 점은 피드백이다. 현업/전직 개발자 튜터님들이 실무 수준의 피드백을 주신다. 칭찬 일색/비판 일색이 아닌, 프로젝트의 장단점을 객관적으로 분석해서 피드백을 주시기 때문에, 실무 수준의 시각을 파악하기 더없이 좋은 기회이다.

2. 탄탄한 기본기 + AI 활용한 심화 과정

Java는 백엔드 진영에서 가장 많이 사용하는 언어이고, Spring은 Java 기반 대표적인 백엔드 프레임워크다.

본 트랙은 Java와 Spring의 중요한 개념 설명들을 과정 초반에 강의와 프로젝트에 집중적으로 할애한다. 뿐만 아니라 배치고사를 통해 수강생들의 수준을 파악한 뒤, 수준에 맞는 맞춤형 수업도 운영한다. 여기서 Java와 Spring에 대한 개념적 이해를 확실하게 다질 수 있다. 이러한 이유로, 기업에서 신입 지원자를 평가할 때 가장 중요한 요소인 기본기에서 흔들릴 일이 없다.

AI도 아주 주요하게 다룬다. 트랙 중간에(대충 3개월차쯤이었던 걸로 기억한다) AI 집중 세션이 있으며, 여기서 내가 알던 AI 활용법은 AI를 개발자로서 다루는 방법과 다르다는 걸 알게 된다. Java와 Spring 환경에 어떻게 AI 모델을 연결시키는지 자세히 배우게 된다. 단순히 '이렇게 하면 된다'를 보여주고 끝나는 것이 아니라, 채용 시장에서 AI 활용 개발자를 어떻게 원하고 있는지, 현재 프로젝트와 어떻게 연결시켜야 좋을지 스스로 고민하고 생각해보게 한다. 이는 다른 부트캠프에서 경험해볼 수 없는 부분이라고 확신한다.

3. 최소한의 비용으로 최대의 효과

이 과정의 장점은 100% 온라인이라는 것이다. 왕복 교통비, 식비를 아낄 수 있음은 물론, 시간이 매우 절약된다. 그런데 거기서 한 걸음 더 나가서, 하루 12시간을 공부한다(2시간 식사시간 제외). 그럼 12시간 공부, 7시간 수면, 5시간 자유시간으로 활용할 수 있다.

이렇게 공부를 하게 되면 수료 시 순수 학습시간에 1200시간이 찍혀 있는 광경을 볼 수 있게 된다.

무언가를 1200시간 공부했다는 건, 어느 누구도 감히 무시하지 못하는 수준이다. 하루 12시간씩 100일이다. 숙식을 집에서 해결하니 비용은 최소화되고, 깨어 있는 시간 대부분은 학습에 투자하니 최대의 효과를 얻게 된다.

마치며

모든 부트캠프가 마찬가지듯, 부트캠프는 취업의 발판이지 취업 그 자체는 아니다. 그 누구도 당신의 취업을 대신해줄 수 없고, 어떤 부트캠프를 나오든 기업에서 먼저 당신을 찾지 않는다. 당신이 먼저 문을 두드려야 한다.

하지만 당신이 문을 두들길 때, 문을 열어서 면접이라도 보자고 연락할 회사의 수를 최대화하고 싶다면, 이 부트캠프가 정답이다.

100개의 지원서를 넣어서, 1곳에서 연락이 오는 부트캠프를 가겠는가, 10곳에서 연락이 오는 부트캠프에 가겠는가?

나는 그래서 내일배움캠프를 선택했고, 그 결과에 만족 중이다.

현재 다음 기수 모집 중인 것 같은데, 아래 링크에서 지원 가능하다.

단기심화 자바 부트캠프 I 스파르타클럽 내일배움캠프

취업생 수 1위! 약 3개월 만에 완성하는 단기심화 JAVA 부트캠프!

nbcamp.framer.website

하네스 엔지니어링

montmer27 — Tue, 26 May 2026 13:01:18 +0900

본 포스팅은 아래 영상을 보고 작성되었습니다.

https://www.youtube.com/watch?v=6MYZ7fMhKPY&pp=ygUZ7ZWY64Sk7IqkIOyXlOyngOuLiOyWtOungQ%3D%3D

개념

충분히 강력한 에이전트를 어떻게 제어할지 다루는 기술

단순히 에이전트로 코딩하는 것이 아니라, 모델 동작 환경을 최적화하여 에이전트의 능력을 최대화하는 기법.

가까운 미래에는, 에이전트가 스스로 하네스를 생성하게 될 것.

하네스 엔지니어링이라는 명칭만 새로웠을 뿐, 하네스 자체는 AI 모델에 적용되어 있었다. (예: 클로드 코드)

프롬프트 엔지니어링: "잘 해줘" vs 하네스 엔지니어링: 잘 할 수밖에 없는 구조를 만들어주는 것

핵심

1. 도구는 많을수록 좋다? 오히려 어떤 도구를 사용할지 고민하는 시간만 길어진다. 선택지가 많을수록 결정은 어려워진다.

2. 검증 자동화: 코드 작성 이후 테스트뿐만 아니라, 다른 에이전트로 교차 검증을 하도록 세팅한다. 하네스가 많을수록 인간의 개입 여지는 줄어든다.

3. 에이전트가 작동할 프로젝트가 지저분하면, 에이전트가 작성하는 코드도 지저분해진다. 프로젝트 전체가 하나의 프롬프트이기 때문이다.

4. 인간의 역할과 에이전트의 역할은 구분된다. 여전히 구조적 판단은 인간의 몫이다. 무엇을 만들고, 어떤 예외까지 고려할 것인지는 인간이 결정해야 한다.

생각은 아웃소싱할 수 있지만, 이해는 아웃소싱할 수 없다.

-안드레 카파시-

느낀 점

현재 앱을 2개 정도 개발 중인데, 단순히 에이전트에게 주의사항만 알려주는 것이 하네스가 아니라는 것을 깨달았다. 여러 에이전트를 병렬적으로 배치해서 코드의 품질을 교차검증하도록 하는 방법이 있다는 것을 처음 알았다.
단순히 하네스를 쓸 줄 안다는 것에 한 걸음 더 나아가서, 하네스 엔지니어링을 통해 인간의 고유한 영역인 구조적 판단력과 설계 능력을 어떻게 극대화했는지를 보여주어야 한다. 그것이 내 포트폴리오에서 드러나야 할 역량.

5/25 채용공고 분석 및 서류 전략 모색

montmer27 — Mon, 25 May 2026 20:09:41 +0900

브이에이트코프 | 백엔드 개발자
링크: https://www.wanted.co.kr/wd/357104

선호 인재상:

NestJS 또는 Spring Boot로 서비스를 직접 개발·운영할 수 있는 백엔드 개발자.
AWS, Terraform, CI/CD까지 다루며 인프라와 배포 자동화에 익숙한 사람.
DB 성능, 운영 지표, 장애 대응까지 보는 운영형 개발자.

이력서 + 포트폴리오 전략:
Spring Boot 또는 NestJS 프로젝트를 하나 골라 API 설계 → DB 설계 → 배포 → 모니터링 흐름으로 보여주는 게 좋습니다. Terraform, GitHub Actions, Docker, AWS 배포 경험이 있다면 별도 섹션으로 빼서 강조하세요. 포트폴리오에는 쿼리 튜닝, 장애 대응, 배포 자동화처럼 운영에서 문제를 줄인 경험을 수치와 함께 넣는 게 강합니다.

제네시스네스트 | Java 백엔드 개발자
링크: https://www.wanted.co.kr/wd/314893

선호 인재상:

Java, Linux, Spring 기반 서버 개발 기본기가 탄탄한 사람.
전산학 기초와 백엔드 구조 이해를 갖춘 개발자.
빠르게 성장하는 개발자 중심 조직에서 높은 기준의 동료와 일할 수 있는 사람.

이력서 + 포트폴리오 전략:
Java/Spring 기본기를 정면으로 보여주세요. REST API, 인증/인가, 예외 처리, 테스트 코드, Linux 배포 경험을 기본기 패키지처럼 묶으면 잘 맞습니다. 포트폴리오는 화려한 기능보다 코드 품질, 계층 분리, 트랜잭션 처리, 테스트 가능성을 보여주는 쪽이 유리합니다.

김캐디 | 백엔드 개발자 Backend Engineer
링크: https://www.wanted.co.kr/wd/347508

선호 인재상:

기능 구현에 머물지 않고 기획, 설계, 배포까지 제품 전 과정에 참여하는 사람.
Java/Kotlin, Spring Boot, AWS, Docker 기반으로 서비스를 운영할 수 있는 사람.
비즈니스 요구에 맞춰 아키텍처를 선택하고 팀과 적극적으로 협업하는 개발자.

이력서 + 포트폴리오 전략:
서비스 성장에 기여한 경험을 가장 앞에 두는 게 좋습니다. 단순 CRUD보다 사용자의 문제를 발견하고 기능이나 구조를 개선한 사례를 강조하세요. 포트폴리오에는 Spring Boot 기반 서비스에 Docker 배포, AWS 운영, 모니터링 또는 성능 개선 내용을 붙이면 공고와 밀착됩니다.

여기어때컴퍼니 | Server Engineer 예약/결제플랫폼개발
링크: https://www.wanted.co.kr/wd/356204

선호 인재상:

Java/Spring 기반 REST API와 MSA 운영 경험이 있는 서버 개발자.
예약·결제처럼 안정성과 정확성이 중요한 도메인을 책임질 수 있는 사람.
대용량 트래픽, SQL 튜닝, PG/간편결제 연동에 관심이 있는 문제 해결형 개발자.

이력서 + 포트폴리오 전략:
결제, 주문, 예약, 재고처럼 상태 전이가 중요한 도메인 프로젝트를 전면에 세우세요. 트랜잭션, 동시성 제어, 실패 처리, 재시도, 멱등성 같은 키워드가 매우 잘 맞습니다. 포트폴리오에는 결제 흐름 설계, 장애 상황에서 데이터 정합성 보장, SQL 튜닝을 시나리오 중심으로 설명하면 좋습니다.

커넥트웨이브 | Consumer Commerce Backend Engineer
링크: https://www.wanted.co.kr/wd/273728

선호 인재상:

Java/Kotlin/Spring/JPA 기반 백엔드와 배치 프로세스 개발 경험이 있는 사람.
상품 데이터, 가격 비교, 카테고리 매핑처럼 대용량 데이터 처리에 관심 있는 개발자.
PR, 코드 리뷰, 자기주도 학습에 익숙하고 MSA/비동기 처리로 확장 가능한 사람.

이력서 + 포트폴리오 전략:
커머스나 데이터 처리 프로젝트가 있으면 가장 잘 맞습니다. 배치, 검색, Redis/MongoDB/Elasticsearch, Kafka/RabbitMQ 같은 경험은 우대사항과 바로 연결되니 별도 태그로 드러내세요. 포트폴리오에는 상품 수집·분류·검색 API, 가격 비교 데이터 모델링, 비동기 작업 처리 구조 같은 예제가 강합니다.

시큐레터 | JAVA 개발자
링크: https://www.wanted.co.kr/wd/322017

선호 인재상:

Java/Kotlin 기반 Spring Boot REST API를 만들 수 있는 사람.
React/Next.js, Node/Express까지 함께 다룰 수 있는 풀스택 성향의 개발자.
보안 솔루션 도메인에서 설계부터 배포, 운영 이슈 해결까지 책임지는 사람.

이력서 + 포트폴리오 전략:
백엔드만이 아니라 프론트와 연결된 완성형 서비스를 보여주는 게 좋습니다. 보안 도메인과 맞추려면 인증/인가, 파일 업로드 검증, 입력값 검증, 취약점 대응, 로그 추적 경험을 강조하세요. 포트폴리오에는 직접 설계·구현·배포·운영한 서비스라는 흐름이 보이게 구성하면 공고와 잘 맞습니다.

아타드(ATAD) | 백엔드 개발자
링크: https://www.wanted.co.kr/wd/346637

선호 인재상:

Java, Python, Node.js 중 하나 이상으로 백엔드 시스템을 설계·개발할 수 있는 사람.
DB 설계, SQL, RESTful API 구현 기본기가 있는 개발자.
클라우드, 대규모 트래픽, Agile/Scrum, 오픈소스 경험에 열려 있는 사람.

이력서 + 포트폴리오 전략:
범용 백엔드 역량을 깔끔하게 보여주는 전략이 좋습니다. Java/Spring 중심이라면 Python이나 Node.js 경험은 보조 역량으로 짧게 넣고, 핵심은 API 설계, DB 최적화, 클라우드 배포로 잡으세요. 포트폴리오는 확장 가능한 API 서버, DB 인덱싱/쿼리 개선, 클라우드 배포 조합이면 충분히 설득력 있습니다.

Questack 개발기 DAY 1

montmer27 — Sun, 24 May 2026 00:33:09 +0900

프로젝트 설명

매일 GitHub/RSS*/기술 블로그에서 Java/Spring/Backend/AI 관련 이슈를 수집하고, 필터링/랭킹/요약한 뒤, 학습용 미니 프로젝트 과제를 생성하는 서비스

*RSS
웹사이트에 신규로 등록되는 최신 콘텐츠에 대한 요약된 정보를 빠르게 제공하기 위한 포맷입니다.
블로그, 뉴스, 칼럼 등 업데이트가 잦은 콘텐츠들을 사용자가 편하게 볼 수 있도록 만들어진 규약이라고도 할 수 있습니다.

개발 계획

개발 기간: 26.05.23 - 26.06.06 (2주)
워크플로우 문서

작업 내용

프로젝트 이름 확정: Questack
의미 확정: Quest + Stack
하루 이슈 개수 확정: 3개
미니 프로젝트 난이도 확정: 신입 백엔드 면접 대비용
로컬 DB 확정: H2 우선
수집 후보 정리: 추천 소스 + 국내 기술 블로그 30개
MVP 우선순위 정리
2주 개발 로드맵 작성
의사결정/트러블슈팅/일일 브리핑 템플릿 작성
Local 개발용 Github API Token 발급, 준비 완료
- 최신 기술을 확인하기 위해 Codex가 자동으로 공개 저장소를 검색하는데, 비인증 요청은 rate limit이 낮은 한계를 극복하기 위해
- 나중에 미니 프로젝트 repo 생성, README 업데이트, Github에 push 여부 확인, 커밋 목록 조회 같은 기능을 붙이기 위해

Questack 2주 개발 워크플로우

montmer27 — Sun, 24 May 2026 00:05:13 +0900

1-2일차: 기획/스캐폴딩

프로젝트 이름, 핵심 기능 범위 확정
Spring Boot 기본 구조 생성
docs/technical-decisions, docs/troubleshooting, docs/daily-briefings 생성
데이터 모델 설계: Source, CollectedItem, RankingScore, Briefing, MiniProject

3-4일차: 수집기

GitHub Search API 연동
RSS 수집기 연동
수집 결과를 DB에 저장
중복 제거: URL, repo id, normalized title 기준

5-6일차: 필터링/랭킹

백엔드 취업 적합도 점수화
Java/Spring/AI/DB/Infra 키워드 가중치
프론트엔드/로봇/배터리/반도체 제외 필터
테스트 데이터 fixture 기반 검증

7일차: 일일 브리핑 생성

상위 N개 이슈 Markdown 생성
“왜 중요한가 / 오늘 공부할 것 / 구현 과제 / 블로그 초안” 포맷
docs/daily-briefings/YYYY-MM-DD.md로 저장

8-9일차: 미니 프로젝트 생성기

이슈 하나를 선택하면 Spring Boot 미니 프로젝트 과제 생성
AI가 전체를 다 구현하지 않고 TODO-STUDENT 영역을 남기는 구조
예: Redis cache, JWT auth, Kafka consumer, Spring AI RAG

10일차: 게이미피케이션

streak, XP, completed quest
GitHub push 체크리스트
“오늘의 퀘스트 완료” 상태 저장

11-12일차: 자동화/하네스

매일 실행 스케줄러
API 호출 캐시
fixture replay 테스트
LLM 호출 전 1차 필터링으로 비용 절감
실패 시 troubleshooting 문서 자동 생성 초안

13일차: 문서/자소서 재료 정리

README 작성
아키텍처 다이어그램
기술 의사결정 문서 정리
트러블슈팅 2-3개 작성

14일차: 데모/회고

샘플 일일 브리핑 생성
샘플 미니 프로젝트 생성
GitHub push
자소서 문장/면접 답변 정리

[운동 관리 앱 만들기] Levio - DAY 5: 트러블슈팅

montmer27 — Sat, 23 May 2026 01:57:38 +0900

TR-001 / 2026-05-23: Mobile Codex workflow failed during dependency installation

증상: GitHub Mobile에서 issue comment로 /codex 명령을 실행했지만 Mobile Codex PR workflow가 Install dependencies 단계에서 실패. 실패한 run은 26296953177이고, 단계는 npm ci.

원인: package-lock.json에 optional peer dependency lock entries가 일부 빠져 있어 GitHub Actions runner의 npm 10 계열 npm ci가 lockfile을 불완전하다고 판단. 로그에는 Missing: picomatch@4.0.4 from lock file, Missing: yaml@2.9.0 from lock file이 표시됨. npx npm@10 install --package-lock-only 실행 결과 node_modules/@netlify/build/node_modules/picomatch와 node_modules/tailwindcss/node_modules/yaml 항목이 추가되며 원인과 일치함.

조사 과정: gh run list로 실패한 workflow run을 찾고 gh run view --log-failed로 실패 로그를 확인. 로컬 현재 npm 11에서는 npm ci --dry-run이 통과했지만, runner와 가까운 npm 10으로 npx npm@10 ci --dry-run을 실행해 lockfile 수정 후 통과 여부를 확인.

해결: npx npm@10 install --package-lock-only로 package-lock.json을 재생성하여 누락된 optional peer lock entries를 추가. 이후 npx npm@10 ci --dry-run이 통과함.

재발 방지: GitHub Actions에서 사용하는 Node/npm 계열과 맞는 npm으로 lockfile을 갱신한다. CI dependency 단계는 npm install로 완화하지 않고 npm ci를 유지하여 lockfile 불일치를 조기에 감지한다.

관련 항목: TD-010, TD-011

TR-002 / 2026-05-23: Mobile Codex workflow failed while reading Codex server info

증상: GitHub Mobile에서 /codex 명령을 다시 실행했지만 Mobile Codex PR workflow가 Run Codex 단계에서 실패. 최신 실패 run은 26298819897. 로그의 핵심 에러는 Error: Failed to read server info from /home/runner/.codex/26298819897.json.

원인: openai/codex-action@v1이 Codex Responses API proxy의 server info JSON 파일을 읽으려 했지만, 해당 파일이 생성되지 않음. 로그의 with: 출력에 openai-api-key 입력이 보이지 않고, openai/codex-action은 OpenAI API key를 GitHub Actions secret으로 제공해야 하므로 OPENAI_API_KEY secret이 없거나 비어 있을 가능성이 가장 높음. 이 경우 action이 더 명확한 missing API key 오류 대신 server info JSON 누락 오류로 실패할 수 있음.

조사 과정: gh run list --workflow "Mobile Codex PR"로 최근 실패 run을 확인하고, gh run view 26298819897 --log-failed로 실패 단계와 로그를 확인. Install dependencies 단계는 지나갔고, 실패가 Run Codex 내부의 read-server-info 명령에서 발생함을 확인. 이전 run 26298363344도 같은 Failed to read server info 패턴으로 실패했음.

해결: 아직 미적용. GitHub repository settings에서 Actions secret OPENAI_API_KEY가 존재하고 값이 비어 있지 않은지 확인해야 함. secret을 추가/수정한 뒤 같은 이슈에 새 /codex ... 댓글을 작성해 workflow를 재실행한다.

재발 방지: workflow 시작부에 OPENAI_API_KEY secret 존재 여부를 명시적으로 검사하는 preflight step을 추가하면, Codex action 내부 ENOENT 오류 대신 사람이 이해하기 쉬운 실패 메시지를 남길 수 있음.

관련 항목: TD-001, TD-010, TR-001

TR-003 / 2026-05-23: Mobile Codex workflow failed while creating a pull request

증상: Mobile Codex PR workflow가 코드 수정, 테스트, 빌드, 브랜치 push까지 완료했지만 Open pull request 단계에서 실패. 실패 메시지는 pull request create failed: GraphQL: GitHub Actions is not permitted to create or approve pull requests (createPullRequest).

원인: Workflow file에는 pull-requests: write 권한이 있었지만, GitHub repository-level Actions 설정의 can_approve_pull_request_reviews 값이 false였음. 이 값이 false이면 GitHub UI의 "Allow GitHub Actions to create and approve pull requests"가 꺼진 상태이며, GITHUB_TOKEN의 GraphQL createPullRequest 호출이 차단됨.

조사 과정: gh api repos/ginsengcandy/workout-tracker/actions/permissions/workflow로 repo Actions workflow permissions를 확인. 응답은 {"default_workflow_permissions":"write","can_approve_pull_request_reviews":false}였고, 실패 로그의 GraphQL 권한 오류와 일치함. 최신 실패 run 26299615315 로그에서 이미 push된 브랜치가 codex/mobile-allow-the-save-of-temporary-workout-data-and-mak-06f5091임을 확인.

해결: GitHub API로 repository workflow permission을 default_workflow_permissions=write, can_approve_pull_request_reviews=true로 변경. 이미 push된 모바일 Codex 작업 브랜치로 PR https://github.com/ginsengcandy/workout-tracker/pull/4를 수동 생성.

재발 방지: 모바일 Codex 파이프라인을 운영하려면 repo Settings > Actions > General > Workflow permissions에서 Read and write permissions와 Allow GitHub Actions to create and approve pull requests를 모두 켜야 함. 신규 repo로 이전하거나 repo 설정을 재구성할 때 체크리스트에 포함한다.

관련 항목: TD-001, TD-012, TR-001, TR-002

[운동 관리 앱 만들기] Levio - DAY 5: Mobile Codex 파이프라인 구축

montmer27 — Sat, 23 May 2026 01:53:53 +0900

기술적 의사결정

2026-05-22: GitHub Mobile 기반 Codex PR 파이프라인 채택

결정 내용: GitHub issue comment의 /codex <task> 명령을 GitHub Actions 트리거로 사용하고, openai/codex-action@v1이 브랜치 작업 후 테스트와 빌드를 통과하면 PR을 생성하도록 구성.

이유 / 배경: 사용자는 스마트폰에서 작업 지시를 내리고 GitHub Mobile에서 PR을 검토 및 merge하려는 흐름을 원함. GitHub Mobile은 PR 검토 경험이 안정적이고, GitHub Actions와 repository secret, PR API가 한 플랫폼 안에서 연결되어 자동화 구성이 단순함.

대안으로 고려했던 것: GitLab MR 중심 운영 (모바일 검토 경험이 약함), Slack/Telegram/webhook 봇 별도 구축 (추가 서버와 인증 관리 필요), main 직접 자동 merge (검토 단계가 사라져 위험함)

영향받는 문서 / 파일: .github/workflows/mobile-codex-pr.yml, docs/mobile-codex-pipeline.md, README.md, src/App.test.js

2026-05-22: GitHub를 기본 remote로 두고 GitLab을 보조 remote로 유지

결정 내용: origin fetch URL은 GitHub repo git@github.com:ginsengcandy/workout-tracker.git로 설정하고, origin push URL은 GitHub와 GitLab을 모두 등록. 기존 GitLab repo는 별도 gitlab remote로 보존.

이유 / 배경: GitHub Mobile, GitHub Actions, Netlify GitHub App을 중심으로 PR 검토와 배포를 단순화하면서도, GitLab 사용 경험과 백업 용도를 유지하고 싶었음. 한 번의 git push origin <branch>로 GitHub와 GitLab 모두에 브랜치가 반영되도록 구성하면 전환기 동안 두 호스팅을 병행할 수 있음.

대안으로 고려했던 것: GitLab만 canonical로 유지 (GitHub Mobile PR 흐름과 충돌), GitHub로 완전 이전 후 GitLab 삭제 (복구/백업 여지 감소), GitLab push mirror 설정 (UI 설정과 권한 관리가 추가로 필요)

영향받는 문서 / 파일: .git/config remote 설정, GitHub repo ginsengcandy/workout-tracker, GitLab repo kimsparadise0202/workout-tracker

2026-05-22: GitLab 최신 main을 기준으로 GitHub main 초기화

결정 내용: GitLab main이 로컬 main보다 앞서 있었으므로, 로컬 main을 gitlab/main으로 fast-forward한 뒤 GitHub main에 push.

이유 / 배경: GitLab main에는 feat/heatmap merge commit이 이미 존재했고, 로컬 main에는 GitLab에 없는 커밋이 없었음. 덮어쓰기 대신 fast-forward로 최신 canonical 상태를 GitHub에 복제하는 것이 안전했음.

대안으로 고려했던 것: GitHub 초기 main을 로컬 이전 상태로 유지 (GitLab 최신 merge 누락), GitLab main force push (원격 히스토리 손상 위험), 별도 merge commit 생성 (불필요한 히스토리 추가)

영향받는 문서 / 파일: 브랜치 main, remote tracking branch gitlab/main, GitHub main

2026-05-22: Netlify 배포 기준을 GitHub repo로 전환하기로 결정

결정 내용: Netlify site의 linked repository를 GitLab에서 GitHub ginsengcandy/workout-tracker로 바꾸는 방향으로 결정. production deploy는 GitHub main merge를 기준으로 실행되도록 운영.

이유 / 배경: 사용자는 GitHub Mobile에서 PR을 merge한 직후 결과가 Netlify에 반영되기를 원함. GitHub를 PR 검토와 merge의 중심으로 삼는다면 Netlify도 같은 GitHub repo를 바라봐야 merge 후 배포 경로가 직관적임.

대안으로 고려했던 것: Netlify는 GitLab을 계속 바라보고 GitHub merge 후 GitLab 동기화를 기다림 (동기화 실패 시 배포 누락 가능), GitHub와 GitLab 양쪽 deploy hook 유지 (운영 복잡도 증가)

영향받는 문서 / 파일: Netlify site settings, GitHub App repository access, docs/mobile-codex-pipeline.md

2026-05-22: main 자동 merge는 제외하고 PR 생성까지만 자동화

결정 내용: 모바일 Codex 파이프라인은 브랜치 생성, 코드 변경, 테스트, 빌드, push, PR 생성까지만 수행하고 main merge는 사용자가 GitHub Mobile에서 직접 수행.

이유 / 배경: 자동 코드 변경은 테스트를 통과해도 제품 의도나 UI 품질까지 완전히 보장하지 못함. 사용자가 모바일에서 최종 검토와 merge를 수행하면 속도와 통제 사이의 균형을 맞출 수 있음.

대안으로 고려했던 것: CI 통과 시 자동 merge (오작동 시 main 오염 가능), manual workflow_dispatch만 사용 (모바일 issue comment UX보다 번거로움)

영향받는 문서 / 파일: .github/workflows/mobile-codex-pr.yml, docs/mobile-codex-pipeline.md

2026-05-22: 기존 CRA 기본 테스트를 현재 앱 smoke test로 교체

결정 내용: learn react 링크를 찾던 기본 CRA 테스트를 현재 운동 기록 앱의 첫 화면 요소를 확인하는 smoke test로 변경.

이유 / 배경: 모바일 Codex PR 파이프라인은 PR 생성 전 npm test -- --watchAll=false를 실행함. 기존 테스트는 현재 앱 UI와 무관하여 항상 실패했기 때문에, 자동 PR 생성 경로를 막는 잘못된 게이트였음.

대안으로 고려했던 것: 테스트 단계 제거 (회귀 검증 약화), 실패하는 기본 테스트 방치 (자동 PR 생성 불가), 더 넓은 UI 테스트 작성 (이번 변경 범위를 넘어섬)

영향받는 문서 / 파일: src/App.test.js, .github/workflows/mobile-codex-pr.yml

2026-05-23: GitHub CLI를 PR 생성 도구로 채택

결정 내용: Homebrew로 GitHub CLI gh를 설치하고, 브라우저 device login으로 ginsengcandy 계정 인증 후 gh pr create로 PR을 생성.

이유 / 배경: GitHub CLI가 없으면 PR 생성에 Chrome UI 조작이나 수동 링크 클릭이 필요함. CLI를 설치하면 이후 PR 생성, PR 조회, Actions 확인 같은 반복 작업을 터미널에서 안정적으로 처리할 수 있음.

대안으로 고려했던 것: GitHub 웹 compare URL 수동 사용 (사용자 조작 필요), Chrome 자동화 (브라우저 권한과 세션 의존), GitHub API 직접 호출 (토큰 관리 필요)

영향받는 문서 / 파일: 로컬 Homebrew 설치 상태, GitHub CLI auth state, GitHub PR #1

2026-05-23: 모바일 Codex 파이프라인 변경분을 feature branch PR로 검토

결정 내용: 모바일 Codex workflow 변경분을 feat/heatmap 브랜치에 chore: add mobile Codex PR pipeline 커밋으로 저장하고, GitHub PR #1을 main <- feat/heatmap으로 생성.

이유 / 배경: 이미 feat/heatmap이 현재 작업 브랜치였고 GitHub/GitLab 양쪽에 push된 상태였음. main에 직접 반영하지 않고 PR로 검토하면 새 자동화 설정과 테스트 변경을 GitHub Mobile에서 확인한 뒤 merge할 수 있음.

대안으로 고려했던 것: main에 직접 push (검토 생략), 별도 브랜치로 cherry-pick (추가 브랜치 관리 필요), GitLab MR 생성 (GitHub Mobile 검토 목적과 맞지 않음)

영향받는 문서 / 파일: .github/workflows/mobile-codex-pr.yml, docs/mobile-codex-pipeline.md, README.md, src/App.test.js, GitHub PR https://github.com/ginsengcandy/workout-tracker/pull/1

2026-05-23: 기술적 결정 로그를 append-only 로컬 메모리로 운영

결정 내용: 모든 중요한 기술적 결정은 .local-notes/technical-decisions-2026-05-23.md에 append-only 방식으로 기록하고, 기존 기록은 변경하지 않음. 미래 Codex 세션이 이 규칙을 잊지 않도록 루트 AGENTS.md에 decision log 운영 지침을 추가.

이유 / 배경: 사용자는 기술적 의사결정을 나중에 다시 확인할 수 있는 지속적인 기록으로 남기고 싶어 함. 매번 명시적으로 요청하지 않아도 Codex가 결정사항을 기록하도록 하려면, git에서 제외된 실제 로그와 git으로 공유되는 작업 지침을 분리하는 방식이 가장 안정적임.

대안으로 고려했던 것: .local-notes에만 규칙을 기록 (미래 세션에서 발견하지 못할 수 있음), git으로 관리되는 docs/decisions.md에 기록 (사용자가 요청한 비관리 로컬 기록 방식과 다름), 기존 로그를 수정하며 정리 (append-only 요구와 충돌)

영향받는 문서 / 파일: AGENTS.md, .gitignore, .local-notes/technical-decisions-2026-05-23.md

(아래부터 고유 식별자로 관리하기 시작함)

TD-IDX-001 / 2026-05-23: 기존 기술적 결정 항목 식별자 매핑

결정 내용: 기존 append-only 기록은 원문을 수정하지 않고, 아래 인덱스로 안정 식별자를 부여함.

이유 / 배경: 사용자는 앞으로 기술적 결정과 트러블슈팅 문서를 상호 참조할 수 있도록 항목별 고유 식별자를 원함. 동시에 이전에 정한 append-only 원칙을 지키기 위해 기존 제목을 직접 고치지 않고 별도 매핑 항목으로 식별자를 부여함.

대안으로 고려했던 것: 기존 heading을 직접 수정 (append-only 원칙 약화), 앞으로의 항목에만 식별자 부여 (기존 결정과 상호 참조가 어려움)

영향받는 문서 / 파일: .local-notes/technical-decisions-2026-05-23.md, .local-notes/troubleshooting-log.md, AGENTS.md

관련 항목: TD-009

식별자 매핑:

TD-001: 2026-05-22 / GitHub Mobile 기반 Codex PR 파이프라인 채택
TD-002: 2026-05-22 / GitHub를 기본 remote로 두고 GitLab을 보조 remote로 유지
TD-003: 2026-05-22 / GitLab 최신 main을 기준으로 GitHub main 초기화
TD-004: 2026-05-22 / Netlify 배포 기준을 GitHub repo로 전환하기로 결정
TD-005: 2026-05-22 / main 자동 merge는 제외하고 PR 생성까지만 자동화
TD-006: 2026-05-22 / 기존 CRA 기본 테스트를 현재 앱 smoke test로 교체
TD-007: 2026-05-23 / GitHub CLI를 PR 생성 도구로 채택
TD-008: 2026-05-23 / 모바일 Codex 파이프라인 변경분을 feature branch PR로 검토
TD-009: 2026-05-23 / 기술적 결정 로그를 append-only 로컬 메모리로 운영

TD-010 / 2026-05-23: 트러블슈팅 로그를 기술적 결정 로그와 분리

결정 내용: 기술적 의사결정은 .local-notes/technical-decisions-2026-05-23.md에 TD-###로 기록하고, 장애 조사와 해결 과정은 .local-notes/troubleshooting-log.md에 TR-###로 별도 기록. 두 문서는 관련 항목을 서로 참조함.

이유 / 배경: 의사결정 기록과 장애 해결 기록은 서로 연결되지만 목적이 다름. 의사결정 문서는 선택과 이유를 남기고, 트러블슈팅 문서는 증상, 조사, 원인, 해결, 재발 방지를 남겨야 나중에 빠르게 재사용할 수 있음.

대안으로 고려했던 것: 기술적 결정 로그 하나에 모두 기록 (문서가 비대해지고 장애 조사 흐름이 묻힘), Git tracked docs에 기록 (사용자가 요청한 로컬 비관리 메모리 방식과 다름), 트러블슈팅은 기록하지 않음 (같은 실패를 반복 조사할 위험)

영향받는 문서 / 파일: AGENTS.md, .local-notes/technical-decisions-2026-05-23.md, .local-notes/troubleshooting-log.md

관련 항목: TR-001, TD-IDX-001

TD-011 / 2026-05-23: CI 의존성 설치는 npm ci를 유지하고 lockfile을 npm 10 기준으로 보정

결정 내용: 모바일 Codex workflow의 dependency install 단계는 npm install로 완화하지 않고 npm ci를 유지. 대신 GitHub Actions Node 22 runner와 가까운 npm 10 계열로 package-lock.json을 재생성하여 누락된 optional peer lock entries를 보정.

이유 / 배경: npm ci는 lockfile 불일치를 조기에 잡아주는 CI용 설치 방식이므로 자동 PR 파이프라인의 재현성을 높임. 실패 원인이 workflow 자체가 아니라 lockfile의 npm 10 관점 누락 항목이었으므로, 설치 명령을 느슨하게 바꾸는 것보다 lockfile을 정확히 만드는 것이 더 안전함.

대안으로 고려했던 것: workflow에서 npm install 사용 (CI 재현성 약화), Node/npm 버전을 로컬 npm 11에 맞춤 (GitHub Actions 표준 LTS 환경에서 멀어짐), dependency install 검증 제거 (자동 PR 품질 게이트 약화)

영향받는 문서 / 파일: package-lock.json, .github/workflows/mobile-codex-pr.yml, .local-notes/troubleshooting-log.md

관련 항목: TR-001, TD-001

TD-012 / 2026-05-23: GitHub Actions의 PR 생성 repo 권한을 활성화

결정 내용: GitHub repository Actions workflow permission에서 default_workflow_permissions=write와 can_approve_pull_request_reviews=true를 활성화하여 GITHUB_TOKEN이 pull request를 생성할 수 있게 함.

이유 / 배경: 모바일 Codex 파이프라인은 gh pr create로 자동 PR을 생성해야 함. Workflow-level pull-requests: write만으로는 충분하지 않고, repository-level 설정에서 Actions의 PR 생성/승인 권한이 꺼져 있으면 GitHub GraphQL API가 createPullRequest를 거부함.

대안으로 고려했던 것: Codex 작업 브랜치는 자동 push하고 PR은 사용자가 수동 생성 (모바일 자동화 완성도 저하), 별도 PAT secret으로 PR 생성 (토큰 관리 부담 증가), workflow에서 PR 생성 단계를 제거 (파이프라인 목표와 충돌)

영향받는 문서 / 파일: GitHub repo Actions settings, .github/workflows/mobile-codex-pr.yml, GitHub PR https://github.com/ginsengcandy/workout-tracker/pull/4

관련 항목: TR-003, TD-001

현재 상황 정리

montmer27 — Fri, 22 May 2026 18:58:59 +0900

1. 이력서 미완성

개선 필요

- 자기소개 보강 필요

- 스킬 노출 방식 변경 필요

- 트러블슈팅에서 표를 줄글로 바꾸기 (진행 중, 근데 눈길이 안 감)

- 팀 프로젝트에서 내 포지션, 담당 업무 없음

- 목표, 주요 기능, 참여 기간 등이 구체적일수록 좋다.

- 프로젝트의 기술 스펙 정의를 구체적으로 작성하는 것이 좋다.

어느정도 완성된 부분

- 성능 개선 과정 (less wordy하게 바꾸는 작업 중인데 보기 안좋고 눈에 확 안 들어옴)

2. 오늘 얻은 꿀팁

- 면접관 입장에서 질문하기 좋은 자기소개서가 좋다. 최근 관심 있거나 좋아하는 기술, 언어, 서비스 등을 적어놓으면 나에 대한 정보 + 질문거리를 주는 셈이라 좋다.

- 프로젝트 설명 시, 담당한 기능, 구현 방식, 기술 선택 근거 등을 써주면 질문하기 좋다.

- 자소서를 서문으로 첨부한 개발 포트폴리오를 만들어라 -> 신입 때는 포폴의 위력이 강하다. 신입이면 이력서가 곧 포폴.

- FlowCV로 3개월에 한 번 이력서 갱신하는 게 좋다.

3. 현재 내 문제

- 처음부터 완벽한 이력서를 만드려다 보니 속도가 너무 느리다.

- 우선은 원티드/스파르타 커리어에서 정해진 양식에 따라 내용을 채워넣고, 추후 디자인을 적용하자.

4. 하루 회고

하루 회고는 매우 중요하다. 한 게 없다고 생각할 때 더더욱 해야 하는 게 하루 회고다.

기억하자. '일단 하는 게 안 하는 것보다 훨씬 나으며, 지금 하는 것이 나중에 하는 것보다 훨씬 낫다.' 그리고 이거 쓰고 나면 운동하러 갈 거다.

아쉬웠던 부분

- 원래는 AI 부분을 공부하며 포트폴리오에 메인으로 넣을 부분을 뽑아보려고 했다. 백엔드 엔지니어가 AI 경험이 없는 건 말이 안 되는 시대이기 때문이다. 그런데 intelliJ 열고 프로젝트 잠깐 보다가 다시 이력서 디자인 수정으로 빠져버린 게 아쉽다.

- 디자인 감각: 어떤게 좋은 디자인인지 모르겠다. 어떻게 해도 마음에 안 드는데, 남이 한 걸 그대로 따라해도 마음에 안 든다. 내가 하면 구려지는 것 같다. 다른 사람은 글씨가 많아도 괜찮아 보이고, 나는 글씨를 줄여도 눈길이 안 간다. 뭘 어디서부터 손 대야 할지 감이 안 온다.

좋았던 부분

- 3개월에 한 번씩 이력서를 갱신하는 것이 좋다는 것을 알았다.

- OpenCV로 이력서를 관리하는 것이 좋다는 것을 알았다.

- 하루 회고를 해서 다행이라는 점? 내일도 할 것이다.

- 젭에 들어가니 현희님, 민우님, 은식님이 계셨다. 6조는 어제 강남에서 모였다고 하는데, 우리 조도 얼른 모여야 할 것 같다. 누가 단톡방 파주면 참 좋을텐데..민우님 어떻게 안될까요?

- 신입 이력서는 포트폴리오에 공을 많이 들여야 한다는 것과(경력 적을 칸이 없으므로), 지원자의 정보(자기소개)가 중요한 역할을 한다는 것을 조사를 통해 알게 되었다. 나를 어떤 사람으로 포지셔닝할지, 어떤 소재와 스토리로 나를 드러낼지 앞으로 계속 고민해 볼 예정이다.

- 은식님 말로는 개인 프로젝트가 하나 정도는 있는 게 좋다고 한다. 원래 백엔드 개발자 취준을 해보셨다고 해서 더 신뢰가 간다. 나도 백엔드로 개인 프로젝트를 시작하면서 포트폴리오를 어떻게 채울지 고민해봐야겠다.

- 팀 노션 내 예상 질문 사항에 알림 서버 구현 관련 업데이트를 해 두었다. 적을 수 있는 건 왠만큼 다 적은 것 같다. 나도 아리까리했던 부분들이라 정리했던 건데, 팀원들에게도 도움이 됐으면 좋겠다.

그래서 내일도 이렇게 사나?

점수를 매기자면 3/10점. 체력이나 컨디션은 좋았지만 생산성 측면에서 감점이 됐다.

ChatGPT 30만원을 결제해서 나만의 앱을 만들기 시작한 것도 아니고, 이력서는 아직 첩첩산중이고, 그룹 프로젝트에 대한 이해도도 완벽하지 않아서 썩 반복하고 싶은 하루는 아니었다.

내일은 반드시 오늘보다 생산적인 하루를 보낼 수 있도록 해야겠다.

지금부터의 일정

- 운동: 땀흘리며 1시간 이상 운동하는 것이 목표다. 파이널 프로젝트 핑계로 3주 넘게 운동을 쉬었다. 운동하는 동안에는 내가 만든 앱을 사용해 봐야겠다. 쉬는 시간은 필요 이상 가지지 않는다.

- 콘티 짜기: 내일 아침까지 사모님께 보내기 위한 콘티를 짜야 한다. 기존에 했던 곡들을 중심으로 짜서 보내드려야겠다.

- 트롬본 연습: 입술도 좀 풀어줘야 한다.

내일 일정

- 수영 가기: 격한 유산소를 통해 몸의 기강을 잡을 것이다.

- 이력서 트러블슈팅 & 성능 개선 가독성 향상: 특히 트러블슈팅의 경우 내용을 다시 작성해야 한다.

- chatGPT 30만원 구독 및 앱 만들기: 개발자 할거면 언젠간 살 것이고, 어차피 살 것이라면 일찍 사는 게 낫다.

- 고기파티: 4시까지 교회에 도착해야 한다.

Developing

Questack 개발 일지 - 2026-05-30

구현한 기능

트러블슈팅

기술적 의사결정

관련 커밋 / PR

Questack 개발 일지 - 2026-05-29

구현한 기능

트러블슈팅

기술적 의사결정

관련 커밋 / PR

스파르타 내일배움캠프 Java Spring 백엔드 2기 수료 후기

하네스 엔지니어링

5/25 채용공고 분석 및 서류 전략 모색

Questack 개발기 DAY 1

Questack 2주 개발 워크플로우

[운동 관리 앱 만들기] Levio - DAY 5: 트러블슈팅

TR-001 / 2026-05-23: Mobile Codex workflow failed during dependency installation

TR-002 / 2026-05-23: Mobile Codex workflow failed while reading Codex server info

TR-003 / 2026-05-23: Mobile Codex workflow failed while creating a pull request

[운동 관리 앱 만들기] Levio - DAY 5: Mobile Codex 파이프라인 구축

기술적 의사결정

2026-05-22: GitHub Mobile 기반 Codex PR 파이프라인 채택

2026-05-22: GitHub를 기본 remote로 두고 GitLab을 보조 remote로 유지

2026-05-22: GitLab 최신 main을 기준으로 GitHub main 초기화

2026-05-22: Netlify 배포 기준을 GitHub repo로 전환하기로 결정

2026-05-22: main 자동 merge는 제외하고 PR 생성까지만 자동화

2026-05-22: 기존 CRA 기본 테스트를 현재 앱 smoke test로 교체

2026-05-23: GitHub CLI를 PR 생성 도구로 채택

2026-05-23: 모바일 Codex 파이프라인 변경분을 feature branch PR로 검토

2026-05-23: 기술적 결정 로그를 append-only 로컬 메모리로 운영

TD-IDX-001 / 2026-05-23: 기존 기술적 결정 항목 식별자 매핑

TD-010 / 2026-05-23: 트러블슈팅 로그를 기술적 결정 로그와 분리

TD-011 / 2026-05-23: CI 의존성 설치는 npm ci를 유지하고 lockfile을 npm 10 기준으로 보정

TD-012 / 2026-05-23: GitHub Actions의 PR 생성 repo 권한을 활성화

현재 상황 정리