hyejun CSlog

2025 전국 대학생 SW창업 아이디어톤 장려상

rngPwns — Wed, 25 Feb 2026 16:43:25 +0900

25.10.27~25.11. 29

졸업프로젝트 handDoc를 기반으로 예선·본선 총 2회의 창업 보고서를 작성했습니다.

서비스 구조, 기술 구현 내용, 시장 문제 정의를 체계적으로 정리하고, 결선 발표용 자료의 흐름을 구성했습니다.

2025 신촌 대학 연합 SW 창업 경진대회 은상

rngPwns — Wed, 25 Feb 2026 16:40:59 +0900

25.10.30~25.11. 29

졸업프로젝트 handDoc를 기반으로 창업 보고서를 작성했습니다. 서비스 구조와 기술 구현 내용, 시장 문제 정의 및 해결 전략을 정리했고, 결선 발표용 PPT 제작과 발표 스토리라인을 구성했습니다. 디자이너와 협업해 부스 운영용 배너·포스터를 제작하고, 결선 발표 질의응답 진행 및 부스 운영을 통해 심사위원과 관람객에게 서비스를 설명했습니다.

[handDoc] 25-2 Ewha Capstone Design 졸업프로젝트 대상

rngPwns — Wed, 25 Feb 2026 16:38:59 +0900

25.03.03~25.12.18

청각장애인 대상 수어·음성 변환 진료 웹 서비스 handDoc 개발 3명의 팀원 중 백엔드, AI 모델 서빙(FastAPI/Python), 클라우드 배포 및 운영을 담당했습니다. AWS 환경에서 FastAPI 기반 서 비스 배포와 인프라 구조 설계를 맡았으며, 프론트엔드 WebRTC 연동 및 일부 API 연결을 통해 서비스 흐름을 완성했습니다.

9th Open CloudPlatform (K-PaaS) 공모전 동상(OPA 의장상)

rngPwns — Wed, 25 Feb 2026 16:36:29 +0900

25.10.26 ~ 25.11.19

개방형 클라우드 플랫폼(K-PaaS) 활용 공모전에 참여하여 동상(오픈 클라우드 플랫폼 얼라이언스 의장상) 을 수상하였습니다.

졸업프로젝트 handDoc를 기반으로 한 보고서를 작성하고, 기존 AWS 인프라를 Kubernetes 환경으로 마이그레이션하는 역할을 전담했습니다.

Pod, Service, Ingress 구조를 구성하며 Ingress 설정 오류, WebSocket 연결 문제, CORS 이슈를 로그 기반으로 분석하여 해결했고, 클러스터 환경에서의 서비스 운영 경험을 쌓았습니다.

AWS Community Builders Day 2026 회고

rngPwns — Wed, 25 Feb 2026 16:17:06 +0900

좋은 기회로 AWS Community Builders Day 2026에 참여하게 되었다. 생각보다 많은 Hero분들이 있었고, 현업의 관점에서 AWS 의 최신 기술과 적용에 대해 알아볼 수 있었던 좋은 기회였다.

시간표에서 각 시간마다 3개의 강연이 열렸고, 셋 중 하나를 선택하여 강의실을 이동하며 강연을 듣는 형식이었다.
그 외에도 중간중간 네트워킹 시간이 있어 현업자들과 AWS 에 대한 인사이트를 공유할 수 있었다.

내가 선택한 강의에 대한 간단한 요약을 적어봤다.

OPENING

AWS community builder 가 되어라 - 히어로에 합류하면 좋은 점들. 그리고 간단한 오프닝이 진행되었다.

SECTION 1

Amazon Kiro(AI)를 활용해서 AWS 공부를 해 보자!

AI를 이용해 빠르게 학습하고 박학다식해져라
I자보다 T자형 개발자가 되어라.

넓게 알고 한두개를 깊게 알자

SDD(Spec Driven Development): 만들어진 스펙에 의거 개발 진행, 만들어진 뒤 수정시에도 스펙 지속적 참고
→ 요구사항 미리 정의, 개발중 재작업 방지. 코딩 전 명확한 체크 포인트 제공, 계획 단계 모호함 해결
kiro로 학습자료 만들어봐라~

SECTION 2

AWS Lambda

Lambda - 한 번에 다 start보다 2개씩 나눠서 start 하면 cold start 발생 적어서 더 효율적
Lambda Managed Instances : 내가 선택한 EC2 위에서 돌릴 수 있음
Lambda durable functions

중간에 끊기지 않고 input → output(save, pause 최대 1년)
병렬적으로 수행 가능. 다단계 워크플로우. 하나의 Lambda에서 다른 Lambda꺼 가져올 수 있음
Lambda가 30초마다 깼다 잤다 할 수 있어서 Lambda의 실제 운영시간은 매우 적음(몇초) → 비용도 매우 낮음

SECTION 3

오픈소스를 활용한 AWS 보안

반복되는 보안사고패턴: 퍼블릭 S3 버킷 노출, 0.0.0.0/0 무제한 보안그룹 개방, 암호화되지 않은 스토리지

감사를 대비하여 로그를 다 남겨놓기.

Prowler의 역할과 기능

핵심기능: 표준 컴플라이언스 진단 - 자동 점검 수행 , 수백개의 계정, 전체리전을 단일 실행으로 일괄 점검
주기적 자동 실행 및 스케줄링 실행지원

Cloud Custodian의 역할과 기능

핵심기능: 보안규칙을 코드로 정의, 이벤트 기반 자동 통제, 다양한 대응 조치
운영포인트: 서버리스운영, 최소권한원칙, 태그기반 예외처리

전체 논리 아키텍처
보안기준정의 → 주기적진단 → 반복 fail 식별 → 정책화(code) → 실시간 통제
중앙보안계정, 자동화운영계정의 역할을 분리 운영하자!

불필요한 자원 노출 막기
불가피하면 워크로드, 진단계정 두 개라도 분리하기

보통 eventbridge, lamda로 연결
SCP(헌법), IAM(신분증&열쇠) , Custodian(교통경찰) 으로 구성

SCP는 최소로. IAM도 최소권한부여(첨에 full admin 주면 서비스가 점점 늘어나서 막을 수 없어짐, 처음에 막아놓고 하나씩 허용하기)

즉,
Prowler: status, 현재 위치를 투명하게 보여줌
Custodian: control, 안전경로를 이탈 x
Governance

SECTION 4

AWS 이용한 사내 패키지 레지스토리 만들기
Code Artifact : 다양한 언어를 공유할 수 있는 AWS 패키지 서비스
사내 라이브러리 개발 및 배포 가능
문제가 있는 오픈소스 라이브러리는 패치하여 배포 가능
특정 파이썬 버전, 운체/CPU에 존재하지 않는 wheel은 채워서 배포 가능
모든 패키지 다운로드가 Code Artifact 거쳐서 가시성 확보
도커파일 등 인증을 위한 복잡한 설정 필요했음
→ 패키지 설치를 간단히 해 보자.

마지막에 클로징 세션에서 퀴즈 등 재밌는 행사가 진행됐지만, 시간 관계상 아쉽게도 참여하지 못했다.
중간에 무려 햄버거!! 도 주고, AWS 관련 다양한 굿즈와 스티커, 우산을 주셔서 참가비 10000원이 전혀 아깝지 않았다.

많은 인사이트를 얻은, 또 우리나라에 이렇게 인프라에 열정적인 사람들이 많다는 점을 한 번 더 일깨워 준 행사였다.
이 글을 보는 사람이 있다면, 본인이 인프라나 클라우드, AWS, 그리고 개발에 관심이 있다면 해당 행사에 참여해보는 것을 강력하게 추천한다 !!

[MoaMoa] MyPage · MoaLetter 프론트엔드 구현과 Vercel 배포 트러블슈팅

rngPwns — Sun, 25 Jan 2026 21:54:48 +0900

프로젝트 개요

MoaMoa는 8기 UMC Web 파트로 참여한 2개월간의 데모데이 프로젝트이다.
PM 1명, 디자이너 1명, FE 3명, BE 4명으로 총 9명이 참여해 기능 범위와 화면 수가 많은 편이었다.

프론트엔드는 React 기반 SPA로 구성되어 있으며, Vercel(PaaS) 환경에 배포해 실제 운영 환경에서도 서비스가 안정적으로 동작하도록 만드는 역할을 함께 담당했다.

서비스는 친구 생일에 돈과 편지를 함께 모아 선물을 전달하는 웹앱으로, 기획 단계에서 pain point 정의, 타겟 유저 설정, 간단한 시장 분석 및 유사 서비스 비교를 거쳐 기능이 구체화되었다.

프론트엔드는 아이폰 기준 웹앱 UI를 목표로 했고, 실제 사용 흐름이 중간에 끊기지 않도록 UI/UX 구현과 배포 안정화에 집중했다.

기준 디바이스: iPhone 13 / 14
레이아웃 규칙: max-width 393px, 세로 스크롤만 허용
기술 스택: React, TypeScript, Vite, Tailwind CSS
배포 환경: Vercel (pnpm)

맡은 역할

MyPage 전체 구현
MoaLetter 전체 구현
프론트엔드 Vercel 배포 및 배포 오류 해결
공용 컴포넌트 일부 구현 (Modal, Share Modal 등)
배포 환경에서 발생한 TypeScript / 환경변수 / 네트워크 이슈 정리 및 수정

다른 팀원들의 코드 구조는 최대한 유지하면서, 브랜치 단위로 문제를 재현 → 원인 분석 → 수정 가이드 정리 방식으로 작업했다.
단순 UI 구현을 넘어서, 운영 환경에서 프론트엔드가 하나의 서비스로 동작하도록 만드는 과정을 경험했다.

1. MoaLetter 구현 정리

핵심 목표

편지 작성 → 사진 선택 → 꾸미기 → 저장 → 롤링페이퍼 확인 전체 흐름이 중간에 끊기지 않도록 구성하는 것

구현한 주요 화면

편지 작성 페이지 (WriteLetter)
사진 앨범 선택 / 사진 그리드 선택
편지지 / 우표 / 스티커 선택 UI
롤링페이퍼 보기
편지 저장 완료 페이지

구현 포인트

1) 사진 선택 UX

앨범 리스트 → 3열 그리드
단일 사진 선택만 허용
선택 시 어두운 오버레이 + 체크 아이콘 표시
상단 확인 버튼으로 작성 페이지 복귀

const [selectedIndex, setSelectedIndex] = useState<number | null>(null);

복잡한 기능은 아니지만, 지금 내가 어떤 사진을 선택했는지가 즉시 보이도록 처리했다.

2) 기본 편지지 / 우표 미선택 시 화면 공백 문제

문제

아무 것도 선택하지 않으면 화면이 비어 보이는 문제 발생

원인

backgroundUrl prop이 타입에 정의돼 있지 않음
컴포넌트 내부 fallback 처리 부재

해결

props에 optional로 명시
내부에서 기본 이미지 강제 지정

backgroundUrl?: string | null;

→ 사용자가 선택하지 않아도 항상 기본 편지지가 렌더링되도록 수정

3) 공용 모달 / 공유 모달

하단 슬라이드 방식
바깥 영역 클릭 시 닫힘
링크 복사 + SNS 아이콘 UI 제공

공용 컴포넌트로 분리해 MyPage / MoaLetter 양쪽에서 재사용 가능하도록 구성했다.

2. MyPage 구현 정리

구현한 화면

마이페이지 메인
프로필 수정
키워드 편집
구매 내역
공지 / 고객센터 / 문의 작성
다른 유저 프로필 / 위시리스트
팔로우 / 언팔로우 모달

구현 포인트

1) 상태 기반 UI

공개 / 비공개
잠금 상태
토글 스위치 ON / OFF

단순히 디자인만 맞추는 것이 아니라, 상태 변경 시 UI가 즉시 반응하도록 구성했다.

2) 모달 / 라우팅 정리

마이페이지 내부에서 불필요한 페이지 이동 최소화
확인 / 취소 동작은 모달로 처리
실제 페이지 이동은 필요한 경우만 사용

→ 사용자 흐름을 끊지 않으면서 화면 전환 비용을 줄였다.

3. Vercel 배포 & 트러블슈팅

1) pnpm + package-lock 충돌

문제
pnpm 프로젝트에 package-lock.json이 남아 있어 Vercel 빌드 단계에서 lockfile 파싱 에러 발생.

조치

package-lock.json 제거
pnpm 기준으로 의존성 통일

→ 빌드 환경을 명확히 고정해 재현 불가능한 오류 제거.

2) TypeScript 에러로 인한 빌드 실패

문제
로컬에서는 경고 수준이던 TS6133, TS2322 등이 Vercel 빌드 단계에서는 전부 에러로 처리됨.

대응

설정으로 무시하지 않고 실제 원인 제거
공용 컴포넌트 타입을 기준으로 전파 수정

예:

Button의 PaddingSize, Variant, Width 타입 확장
BottomNavigation 필수 props → optional 처리

→ 빌드 타임 검증을 통과하는 코드 상태로 정리

3) dev에서는 정상, prod에서 로그인 404 / CORS

원인

개발 환경: Vite proxy(/api) 사용
배포 환경: proxy 없음 → /api/* 그대로 요청

해결

운영 환경 기준으로 네트워크 구조 재정리
API 호출을 절대 URL 기반으로 통일
환경변수로 dev / prod 분리

const baseURL = import.meta.env.DEV
  ? "/api"
  : import.meta.env.VITE_API_BASE_URL;

→ 개발/운영 환경 차이로 인한 네트워크 오류 제거

4) 로그인 직후 401 에러

원인

토큰은 localStorage에 저장됐지만
Axios 인스턴스 기본 헤더에 즉시 반영되지 않음

해결

localStorage.setItem('accessToken', at);
instance.defaults.headers.common.Authorization = `Bearer ${at}`;

→ 인증 상태 전파 지연 문제 해결

API 연동 과정에서 겪은 이슈

401: 인증 토큰 반영 타이밍 문제
502: 백엔드 서버 불안정
500: 이벤트 생성 API 실패로 전체 플로우 영향
404: 이벤트 미생성 상태에서 연쇄 호출

결과

대부분 API 연동 완료
이벤트 중심 API 일부는 백엔드 이슈로 미완
제한된 테스트 기간 내에서 프론트엔드 단에서 조치 가능한 부분은 모두 정리

정리하며

이 프로젝트를 통해 단순히 UI를 구현하는 역할에 그치지 않고,

모바일 웹 기준 레이아웃 설계
상태 중심 UI 구성
공용 컴포넌트 구조 정리
운영 환경(Vercel)에서 발생하는 실제 빌드·네트워크·환경 이슈 해결

까지 전반적인 프론트엔드 개발 과정을 경험했다.

특히 프론트엔드를 하나의 서비스 단위로 바라보고, 클라우드 환경에서 안정적으로 동작하도록 만드는 과정을 직접 겪은 점이 가장 큰 수확이었다.

2개월이라는 기간 동안 거의 매일 프로젝트에 몰입하며 기획·디자인·프론트·백엔드가 동시에 움직이는 협업 환경을 경험했고,
문제가 생겼을 때 각 파트가 어떻게 조율하고 해결해 나가는지를 실제로 체감할 수 있었다.

결과적으로, 모두가 끝까지 몰입해 고민하고 개선하면 서비스는 완성된다는 것,
그리고 그 과정 자체가 개발자로서 중요한 성장 경험이 된다는 점을 분명히 느낄 수 있었던 프로젝트였다 :)

[Argo CD 오픈소스 기여] CLI help에 뜨는 kubectl REST 플래그가 실제로는 동작하지 않는 문제 (#25875)

rngPwns — Sun, 25 Jan 2026 20:26:51 +0900

1. Argo CD를 첫 오픈소스 기여 프로젝트로 선택한 이유

클라우드 엔지니어를 목표로 준비하면서 토이 프로젝트나 개인 실습보다 실제 운영 환경에서 쓰이는 오픈소스에 직접 기여해보는 경험이 중요하다고 느꼈다. 그 기준에서 Argo CD는 꽤 매력적인 프로젝트였다.

Kubernetes 기반 GitOps 도구로 실무 사용 빈도가 높고
CLI / Server / Controller / UI 역할이 비교적 명확히 분리돼 있어 코드 흐름을 추적하기 쉬우며
이슈와 PR에 메인테이너 피드백이 꾸준히 달려 초보 기여자도 접근 가능한 편이다

그래서 Argo CD 이슈 중에서도 재현이 명확하고 영향 범위가 분명한 CLI 관련 이슈를 중심으로 살펴보게 됐다.

2. 선택한 이슈: CLI help에는 보이지만 실제로는 동작하지 않는 플래그

Issue: CLI shows kubectl REST flags (e.g. --disable-compression) that are not supported
Issue #25875

문제는 간단했다.

Argo CD CLI에서 -h 또는 --help를 보면 kubectl의 REST 관련 플래그들이 노출되지만, 실제로 해당 플래그를 사용하면 실행 단계에서 에러가 발생한다.

예를 들면,

argocd cluster -h

help 출력에는 다음과 같은 플래그가 보인다.

--disable-compression
--client-certificate
--client-key

하지만 실제로 실행하면,

argocd cluster --disable-compression list

결과는 unknown flag 에러다.

지원하지 않으면서 help에는 노출되는 플래그였고, CLI 사용자 입장에서는 꽤 혼란스러운 UX였다.

3. 원인 분석: 플래그 하나의 문제가 아니다.

처음에는 단순히 플래그 등록이 빠진 건가? 정도로 생각했다.

하지만 이슈 댓글과 코드를 같이 따라가다 보니,

이건 특정 플래그 하나의 문제가 아니라 CLI 초기화 구조에서 발생한 정합성 문제라는 걸 알게 됐다.

4. 구조 이해의 출발점: 다른 기여자의 분석

이 이슈에서 중요한 힌트를 준 건 기여자 kwentine의 코멘트였다.

요지는 다음과 같았다.

Argo CD CLI는 일부 커맨드에서 kubectl의 persistent flags를 초기화 과정에서 복사한다
하지만 모든 커맨드가 동일한 초기화 경로를 거치지는 않는다

다만 이 코멘트를 그대로 해답으로 쓰지는 않았다.

이 코멘트를 출발점으로 삼아,

실제 코드가 어디에 있는지
어떤 커맨드가 이 초기화 경로를 타는지
help 출력과 실행 경로가 어디서 갈라지는지

를 직접 코드로 확인했다.

5. 실제 문제 지점: InitCommand

문제의 코드는 다음 파일에 있었다.

cmd/argocd/commands/initialize/cmd.go

여기서는 kubectl의 persistent flags를 가져와
Argo CD 커맨드의 flags로 그대로 복사한다.

flags.VisitAll(func(flag *pflag.Flag) {
    if flag.Name == "server" {
        return
    }
    cmd.Flags().AddFlag(flag)
})

이 구조 때문에,

kubectl에는 있지만 Argo CD에서는 실제로 처리하지 않는 REST 플래그들이 help 출력에는 노출되는 상황이 발생했다.

6. 문제 정리

이 문제는 단순히 플래그 하나가 빠졌다가 아니라,

커맨드마다 초기화 경로가 다르고
help 단계에서는 kubectl 플래그를 일괄 노출하지만
실행 단계에서는 처리하지 못하는 플래그가 존재하는

CLI 초기화 흐름의 정합성 문제라고 판단했다.

7. 해결 전략: 범위를 의도적으로 제한하기

해결 방향에는 두 가지 선택지가 있었다.

모든 서브커맨드별로
이 플래그가 실제로 지원되는지를 판단하도록 구조를 리팩터링
InitCommand를 통해 복사되는 kubectl REST 플래그 중 명백히 지원되지 않는 것만 help에서 숨기기

1번이 더 이상적인 설계일 수는 있지만,

변경 범위가 커지고
CLI 전반에 영향을 주며
리뷰 부담이 커지고
첫 기여로는 리스크가 크다고 판단했다

그래서 이번 PR에서는 기존 구조는 유지한 채,

InitCommand 기반 커맨드에서
실제로 지원하지 않는 kubectl REST 플래그만 명시적으로 제외한다

라는 전략을 택했다.

8. PR 과정

https://github.com/argoproj/argo-cd/pull/25977

이 PR은 혼자 코드 고쳐서 끝나는 작업이 아니었다.
여러 기여자와 메인테이너가 각자 다른 관점에서 피드백을 주고, 그걸 반영하면서 점점 다듬어지는 과정이었다.

PR에서는 다음을 명확히 했다.

변경 범위를 InitCommand 기반 커맨드로 제한
unsupported kubectl REST 플래그만 명시적으로 필터링
UX 문제 해결이 목적임을 명확히 설명

리뷰 피드백 ①: Unit test 추가

Is it possible to add some unit tests?

단순한 필터링 로직이었지만, 회귀 방지 측면에서 테스트를 추가하는 게 맞다고 판단했다.

unsupported kubectl REST 플래그가 실제로 제거되는지 검증하는 테스트 추가

테스트 추가 이후, 리뷰어에게서 명확한 승인(LGTM)을 받을 수 있었다.

리뷰 피드백 ②: 테스트 누락 지적

certificate-authority 플래그 검증이 빠져 있다

단순 누락이었고, 모든 unsupported 플래그를 테스트에 포함하도록 수정했다.

9. 최종 수정 코드

10. 트러블슈팅 – 실제로 막혔던 지점들

가장 오래 걸린 건 CI였다. 문제는 로직이 아니라 생성 코드 검증 단계였다.

Argo CD는 CLI help 문서를 자동 생성된 결과물로 관리한다.
CI에서는 다음을 검사한다.

CLI 동작을 바꿨다면, 자동 생성되는 문서도 함께 업데이트됐는가?

처음에는 코드만 수정하고 docs/user-guide/commands/* 문서를 갱신하지 않아 CI가 실패했다.

이 경험을 통해,

오픈소스에서는 코드뿐 아니라 생성물까지 책임져야 한다는 걸 배웠다.

리뷰 피드백 ③: 구조적 질문 - 미해결

가장 인상 깊었던 질문은 이 부분이었다.

-tls-server-name 플래그는 argocd app에는 없고 argocd admin notifications에는 있다
- 그렇다면 플래그 관리를 초기화 경로 기준이 아니라
  서브커맨드별 실제 지원 여부 기준으로 해야 하는 것 아니냐?

여기서 핵심은 이 PR의 목적이었다.

이 PR은

unknown flag 에러를 없애는 것이 아니라
지원되지 않는 kubectl REST 플래그가 help에 노출되는 문제를 해결하는 것

서브커맨드별 실제 플래그 지원 여부를 추적하려면 플래그 정의 구조 전반을 재설계해야 하고,
이는 이번 PR의 범위를 명확히 초과한다고 판단했다.

그래서

InitCommand를 사용하는 커맨드 트리에 한정된 수정임을 설명했고
admin 계열은 의도적으로 범위 밖임을 명확히 했다.

11. 기여하면서 배운 점

DCO(Sign-off)
단순히 코드만 맞는 게 아니라, 기여자의 책임과 출처를 명확히 남기는 절차라는 걸 처음으로 체감했다.
리뷰는 개인이 아니라 팀의 작업
PR 하나가 여러 리뷰어를 거치며 점점 단단해지는 구조라는 점이 인상적이었다.
작은 PR이 왜 중요한지
변경 범위를 명확히 제한해야 리뷰도, 머지도 가능하다는 걸 배웠다.
오픈소스가 안정적으로 유지되는 이유
개인의 실력보다 프로세스가 실수를 걸러내도록 설계돼 있다는 걸 느꼈다.

12. 첫 후원도 진행

이번 기여는 단순한 CLI 버그 수정이었지만,

코드 구조를 이해하고
리뷰를 통해 설계 범위를 조율하고
테스트와 CI까지 책임지는

오픈소스 기여의 전체 흐름을 경험할 수 있었다.

이 과정에서 가장 많은 도움과 명확한 피드백을 준 nitishfy에게 GitHub Sponsors로 후원을 남겼다.

코드를 쓰는 사람뿐 아니라, 리뷰하고 방향을 잡아주는 사람들이 있어 이 생태계가 유지된다는 걸 실감한 경험이었다.

[코딩테스트 준비] 골드 1문제 (10942 펠린드롬?)

rngPwns — Sat, 10 Jan 2026 12:29:38 +0900

문제의 본질

수열 길이 N ≤ 2000
질문 개수 M ≤ 1,000,000

각 질문마다 직접 팰린드롬 검사하면 최악 O(N × M) → 절대 시간 안 됨

즉 모든 구간의 팰린드롬 여부를 미리 계산해야 한다.

핵심 아이디어: DP (Dynamic Programming)

정의

dp[i][j] = i번째 수부터 j번째 수까지가 팰린드롬이면 1, 아니면 0

점화식

1️⃣ 길이 1

dp[i][i] = 1

한 글자는 무조건 팰린드롬

2️⃣ 길이 2

dp[i][i+1] = (arr[i] == arr[i+1])

3️⃣ 길이 ≥ 3

dp[i][j] = (arr[i] == arr[j]) AND dp[i+1][j-1]

양 끝이 같고
안쪽이 팰린드롬이면
전체도 팰린드롬

DP 채우는 순서

구간 길이 기준으로 증가시키며 계산

길이 1 → 길이 2 → 길이 3 → ... → 길이 N

이유: dp[i][j]를 계산하려면 dp[i+1][j-1]가 이미 계산돼 있어야 함

시간 복잡도 분석

전처리

DP 상태 수: N² ≈ 4,000,000
시간: O(N²) → 가능

질의

각 질문: O(1)
총: O(M)

전체 시간 O(N² + M) - 이 문제의 유일한 정답 접근

[코딩테스트 준비] 골드 1문제 (2176 합리적인 이동경로)

rngPwns — Fri, 9 Jan 2026 12:16:21 +0900

그래프의 정점 1(S)에서 정점 2(T)로 이동한다.
이동할 때마다 항상 정점 2에 더 가까워지는 방향으로만 이동하는 경로를
“합리적인 이동경로”라고 정의한다.

그래프가 주어질 때, 가능한 합리적인 이동경로의 개수를 구하는 문제다.

핵심 관찰

“정점 2에 더 가까워진다”는 말은
정점 2까지의 최단거리 값이 매 이동마다 감소해야 한다는 의미다.

따라서 각 정점에서 정점 2까지의 최단거리를 먼저 알아야 한다.

전체 풀이 전략

1. 정점 2에서 다익스트라 수행

정점 2를 시작점으로 다익스트라를 실행한다.
dist[v] = 정점 v에서 정점 2까지의 최단거리

이 값이 이후 이동 가능 여부 판단 기준이 된다.

2. DFS + DP로 경로 개수 계산

dp[u] = 정점 u에서 정점 2까지 갈 수 있는 합리적인 경로의 수
종료 조건
- u == 2이면 1 반환
이동 조건
- u -> v로 이동 가능 ⇔ dist[v] < dist[u]

최단거리 값이 항상 감소하므로, 순환이 발생하지 않아 DP가 가능하다.

알고리즘 정당성

합리적인 이동경로는 최단경로일 필요는 없지만
항상 “정점 2 기준 거리 감소” 조건을 만족해야 한다
다익스트라로 거리 기준을 고정한 뒤
그 기준을 만족하는 방향으로만 DFS를 수행하면
모든 가능한 합리적인 경로를 중복 없이 셀 수 있다

[코딩테스트 준비] 골드 1문제 - 1949 우수 마을

rngPwns — Tue, 6 Jan 2026 19:59:44 +0900

1949 우수 마을

트리 DP를 이용한 최대 가중 독립집합 with 지배 조건

1. 문제 해석

문제는 트리 구조의 그래프에서 일부 정점을 선택하여 다음 조건을 만족하는 부분집합을 찾는 것이다.

선택된 마을의 주민 수 합을 최대화해야 한다.
인접한 두 마을은 동시에 선택할 수 없다.
→ 독립집합(Independent Set) 조건
선택되지 않은 모든 마을은 적어도 하나의 선택된 마을과 인접해야 한다.
→ 지배(Dominating) 조건

즉, 본 문제는
트리에서 지배 조건을 만족하는 최대 가중 독립집합을 구하는 문제로 해석할 수 있다.

2. 접근 방법 개요

트리는 사이클이 없으므로, 임의의 노드를 루트로 잡아 DFS를 수행하며
서브트리 단위로 최적해를 계산하는 트리 DP 방식이 적합하다.

각 노드에 대해 “선택하는 경우”와 “선택하지 않는 경우”를 분리하여 고려한다.

3. DP 상태 정의

루트를 기준으로 트리를 구성하고, 각 노드 u에 대해 다음과 같이 정의한다.

dp[u][1] : 마을 u를 우수 마을로 선택했을 때
u를 루트로 하는 서브트리에서 얻을 수 있는 최대 주민 수
dp[u][0] : 마을 u를 선택하지 않았을 때
u를 루트로 하는 서브트리에서 얻을 수 있는 최대 주민 수

4. 점화식

4.1 현재 마을을 선택한 경우 (dp[u][1])

인접한 마을은 선택할 수 없으므로, 모든 자식은 반드시 선택되지 않아야 한다.
자식이 선택되지 않은 경우라도, 현재 마을 u가 지배 조건을 만족시켜 준다.

따라서 다음과 같이 계산된다.

dp[u][1] = population[u] + Σ dp[v][0] (v는 u의 자식)

4.2 현재 마을을 선택하지 않은 경우 (dp[u][0])

이 경우가 문제의 핵심이다.

u가 선택되지 않았으므로,
u는 반드시 인접한 마을 중 하나에 의해 지배되어야 한다.
DFS 기준에서는 부모의 선택 여부를 알 수 없으므로,
자식 중 최소 하나는 반드시 선택되어야 한다.

자식 v에 대해 선택지는 두 가지다.

v를 선택 → dp[v][1]
v를 선택하지 않음 → dp[v][0]

기본적으로는 각 자식에 대해 max(dp[v][0], dp[v][1])를 선택하되,
모든 자식이 선택되지 않는 상황이 발생하면,
손해가 가장 적은 자식 하나를 강제로 선택해야 한다.

이를 위해 다음 절차를 사용한다.

각 자식에 대해 더 큰 값을 선택하며 합을 계산
선택된 자식이 하나도 없다면
dp[v][1] - dp[v][0] 값이 가장 작은 자식을 선택

5. 루트 처리 및 최종 결과

루트 노드는 부모가 없으므로,
루트가 선택되지 않았을 경우에도 자식 중 하나가 반드시 선택되어야 한다.

이는 dp[u][0] 계산 과정에서 이미 보장되므로,
최종 결과는 다음 중 최댓값이다.

정리

이 문제는 단순한 최대 독립집합 문제가 아니라,
선택되지 않은 정점도 반드시 커버해야 한다는 지배 조건이 추가된 문제이다.

트리 구조라는 점을 이용해
DFS 기반 트리 DP로 상태를 분리하고,
“최소 하나의 자식 선택” 조건을 정확히 처리하는 것이 핵심이다.