군만두의 IT 개발 일지

[스터디14] 06. 소프트웨어 프로세스 모델 이해하기

mandus — Wed, 24 Jun 2026 22:12:40 +0900

8장. 소프트웨어 프로세스 모델 이해하기

8-1 소프트웨어 프로세스 모델이란?

소프트웨어 프로세스 모델(software process model)은 소프트웨어 개발의 전체 흐름과 생애 주기를 체계화한 모형이다. 적절한 모델을 적용하면 기존에 겪었던 문제를 반복하지 않고 프로젝트를 효율적이고 안정적으로 수행할 수 있다.

소프트웨어 프로세스 모델의 필요성

체계적인 개발 절차: 개발 과정의 각 단계를 명확히 정의해 일관된 방식으로 업무를 수행하고, 개발자와 이해관계자 간 의사소통을 원활하게 한다.
효율적인 자원 관리: 시간과 비용을 효과적으로 분배 및 관리하고, 단계별 산출물을 문서화해 유지 보수를 원활하게 한다.
높은 수준의 위험 관리: 개발 초기부터 잠재적 위험 요인을 식별하고 대응하도록 유도하며, 특히 반복적이고 점진적인 모델이 위험 관리에 강점을 보인다.

소프트웨어 프로세스 모델의 역사

1960년대 ~ 1990년대 중반: 소프트웨어를 한 번에 완벽하게 개발하는 데 중점을 둔다.
1990년대 중반 이후: 객체 지향 프로그래밍의 부상과 함께 변화와 외부 상호 작용을 중시하는 방식이 주목받는다.
2000년대 이후: 소프트웨어 규모가 커지면서, 폭포수 모델과 반복적 모델이 Unified Process(UP)로 통합되는 흐름으로 발전한다.

1960~2000년대	2000년대~현재
폭포수 모델, V-모델, 증분형 모델, 진화형 모델, 애자일	폭포수 모델 + 반복적 모델 → Unified Process(UP)로 통합

반드시 한 가지 모델만 적용해야 한다는 규칙은 없으며 소프트웨어의 형태, 규모, 기능에 따라 적절한 모델을 선택하는 것이 중요하다.

8-2 단계별 진행과 문서화에 중점을 둔 폭포수 모델

선형적이고 순차적인 접근 방식인 폭포수 모델

폭포수 모델(waterfall model)은 요구 사항 분석, 설계, 개발, 테스트, 유지 보수가 순차적으로 흐르는 선형적 접근 방식이다. 각 단계에서 이전 단계로 되돌아가기 어렵지만, 단계별 산출물이 명확해 일정 관리와 진행 파악이 쉽다.

단계	산출물	작성 내용
요구 사항 분석	요구 사항 정의서	시스템의 기능적, 비기능적 요구 사항을 기술함
프로그램 설계	설계 사양서	시스템 아키텍처와 데이터베이스 설계 문서를 만듦
개발	소스 코드(모듈별 코드)	실제 프로그램을 구현하며, 프로그래밍 언어로 코드 파일을 작성함
테스트	테스트 결과서	요구 사항 충족 여부 확인을 위해 입력, 예상 결과, 실제 결과 등을 기록함

적용 분야: 요구 사항이 명확한 프로젝트에서 여전히 자주 사용한다.
단점: 요구 사항 변경에 대한 유연성이 부족하고, 오류와 버그가 주로 테스트 단계에서 발견된다.
보완 방법: 초기 요구 사항 분석 단계에서 고객과 긴밀하게 소통하고, 테스트 프로세스를 강화한다.

테스트 프로세스를 강화한 V-모델

V-모델은 폭포수 모델을 확장해 테스트 프로세스를 강화한 모델이다. 개발 단계와 테스트 단계를 일대일로 대응시켜 V자 형태로 진행하며, 오류를 조기에 발견할수록 일정과 비용을 효과적으로 단축할 수 있다.

Verification(검증): 개발 단계까지 각 산출물이 요구 사항을 충족하는지 검증한다.
Validation(확인): 완성된 프로그램이 실제 요구 사항에 맞게 동작하며 문제가 없는지 확인한다.

검증 세부 단계	설명
요구 사항 분석	사용자의 니즈를 분석해 요구 사항을 도출하고, 기능적, 비기능적으로 구분해 체계적으로 정리함
시스템 설계	요구 사항 문서를 검토해 필요한 기술을 파악하고, 구현 가능성을 판단함
아키텍처 설계	고수준 설계. 모듈 간 인터페이스, 관계, 의존성을 기술하고, DB 테이블과 아키텍처 다이어그램, 통합 테스트 계획을 작성함
단위 설계	저수준 설계. 모듈의 기능 로직을 의사 코드 수준으로 기술하고, 단위 테스트 계획을 수립함

확인 세부 단계	설명
단위 테스트	화이트박스 테스트로 로직을 검증함. 개별 함수, 메서드의 정확성과 효율성을 개발자가 직접 점검함
통합 테스트	블랙박스 테스트로 동작의 결괏값을 검증함. 모듈을 통합해 컴포넌트 간 인터페이스, 상호 작용 오류를 검증함
시스템 테스트	실제 시스템을 요구 사항과 비교해 검증함. 실사용 환경과 유사한 조건에서 성능 등 시스템 레벨의 오류를 발견함
인수 테스트	요구 사항 충족과 신뢰성 확보 여부를 평가함. 실제 배포, 사용 준비 완료 여부를 최종 확인함

8-3 지속적 향상에 중점을 둔 반복적 모델

반복적 모델(iterative model)은 사용자의 요구 사항이나 제품의 일부를 단계에 따라 개발하고 반복해 개선하는 접근 방식이다. 크게 증분형 모델과 진화형 모델로 구분한다.

전체를 모듈로 분해하고 점진적으로 개발하는 증분형 모델

증분형 모델(incremental model)은 전체 시스템을 여러 모듈로 분해하고, 각 모듈을 점진적으로 개발하는 방식이다.

개발 방식: 분해한 모듈을 하나의 서브 시스템으로 먼저 구현해 릴리스한 후, 다음 서브 시스템을 순차로 개발한다.
특징: 핵심 모듈을 우선 개발해 기능을 점차 확장해 나간다.
적용 원리: 하나의 증분 사이클이 폭포수 모델의 흐름을 따르므로, 폭포수 모델을 여러 번 적용한 결과를 순차로 조합해 최종 시스템을 완성한다.
장점: 프로젝트 관리자(PM)가 적절하게 관리하면, 각 서브 시스템을 독립적으로 병행해서 개발할 수 있다.

프로토타입을 기반으로 발전시키는 진화형 모델

진화형 모델(evolutionary model)은 MVP(Minimum Viable Product)를 핵심 프로토타입으로 먼저 개발한 후, 운영 중 발생하는 요구 사항과 피드백을 반영해 시스템을 지속적으로 발전시키는 방식이다.

적용 분야: 초기 요구 사항이 명확하지 않은 프로젝트에 적합하다.
주의점: 무분별하고 빈번한 릴리스는 버전 관리의 부담을 키우므로, 진화 과정의 전반적인 개요를 사전에 정리해 두어야 한다.

구분	증분형 모델	진화형 모델
개념	하나의 증분은 폭포수 모델을 적용해 개발하며, 개발된 증분들을 결합해 최종 시스템을 완성함	MVP를 초기 프로토타입으로 개발한 후, 운영을 시작하고 기능을 점차 발전시켜 최종 시스템을 완성함
특징	초기 요구 사항이 명확한 경우에 적합하며, 각 증분을 병렬로 개발할 수 있음	초기 요구 사항이 불명확한 경우에 적합함
장점	신규 도입 시 발생하는 충격을 완화하고, 후반 통합 시 발생하는 부담을 줄일 수 있음	완성도를 점차 향상시킬 수 있고, 초기의 불완전한 요구 사항에 유연하게 대응할 수 있음
단점	여러 증분을 관리하는 부담이 있고, 요구 사항 변경에 효과적으로 대응하기 어려움	빈번한 릴리스 시 버전 관리 부담이 커지고, 비용과 일정이 증가할 수 있음

항목	폭포수 모델	반복적 모델
개발 방식	순차적, 단계별로 진행	반복적, 점진적으로 개선
변경 대응	유연성이 낮고 변화하기 어려움	유연성이 높고 변경 사항을 쉽게 반영
문서 중요도	각 단계별 산출물이 중요	비교적 덜 중요하며 프로토타입에 중점
고객 참여 시기	초기 요구 사항 전달 단계에서만 참여	지속적인 참여와 피드백 수행
요구 사항 명확성	초기 요구 사항이 명확해야 함	초기 요구 사항이 불완전해도 적용 가능
프로젝트 규모	주로 소규모	소규모에서 대규모까지 적용 가능

8-4 위험 최소화에 중점을 둔 나선형 모델

나선형 모델(spiral model)은 위험 분석 단계를 별도로 두어 위험 최소화를 중요한 요소로 고려하면서, 점차 완벽한 시스템을 구축해 나가는 방식이다. 다음 4단계를 반복하며 시스템을 완성한다.

목표 설정: 고객의 요구 사항을 분석하고 타당성을 검토한 후, 해당 사이클의 목표를 새롭게 수립한다.
위험 분석: 고객의 요구 사항을 기반으로 예상되는 위험 요소를 식별하고, 이를 초기에 최소화하는 해결 방안을 마련한다.
구현 및 테스트: 적합한 개발 모델을 선택해 진행하며, 단위 테스트 후 통합 테스트와 시스템 테스트를 순차로 진행한다.
고객 평가 및 다음 계획 수립: 고객 평가를 바탕으로 반복 여부를 결정하고, 인수 테스트로 시스템의 적합성을 최종 검토한다.

8-5 신속한 개발 경험에 중점을 둔 애자일

애자일(Agile)은 짧은 작업 주기와 반복적인 릴리스 사이클로, 고객의 요구 변화나 시스템 장애에 유연하고 신속하게 대응하는 개발 방법론이다.

애자일 소프트웨어 개발 선언문
공정과 도구보다 개인의 상호 작용을,
포괄적인 문서보다 동작하는 소프트웨어를,
계약 협상보다 고객과의 협력을,
계획에 따르기보다 변화에 대응하기를
가치 있게 여긴다.

구성 요소	설명
제품 백로그(product backlog)	제품에 필요한 항목을 모두 나열한 목록. 한 번에 정해지는 것이 아니라 지속적으로 진화하는 산출물임
스프린트 백로그(sprint backlog)	제품 백로그 중에서 이번 스프린트 주기 동안 개발할 항목을 뜻함
스프린트(sprint)	반복적인 짧은 개발 주기. 보통 2~4주로 설정하며, 정해진 기간 동안 계획한 작업을 완료하는 것을 목표로 함
일일 스크럼(daily scrum)	매일 짧게 진행하는 회의로, 진행 상황, 어려움, 다음 단계 계획을 공유함
제품 개선 반영 부분	스프린트 종료 시 결과물을 평가하고 배포 여부를 결정하며, 개선 사항을 반영하는 과정을 포함함

애자일의 핵심 가치

협력: 통찰력과 아이디어를 공유해 시너지를 창출하고, 문제 발생 시 신속하게 해결하며 추가 문제점을 미리 발견하는 데 도움을 준다.
피드백: 개발자가 자신이 만든 기능을 스스로 확인하는 내부 피드백과 고객, 사용자가 제품을 사용한 뒤 제공하는 외부 피드백으로 나뉜다.

애자일 스프린트 5단계

분석: 사용자의 요구 사항을 분석하고, 스프린트 백로그에 포함할 항목을 선정한다.
설계: 선정한 스프린트 백로그의 설계와 디자인을 추가하거나 수정한다.
개발: 프로그램 기능을 개발하고, 단위 테스트와 통합 테스트 코드를 작성하고 수행한다.
테스트: 테스트에서 발견한 오류를 수정하고, 이 스프린트에서 개발한 코드 품질을 검증한다.
검토: 내부 피드백과 외부 피드백을 반영해 개선 사항을 정리하고, 이를 다음 스프린트에 적용한다.

애자일의 장점과 한계

애자일은 '먼저 만들어 보고 빠르게 수정한다'는 원칙에 따라 계획에 소요되는 시간을 최소화하고, 버그와 피드백을 신속하게 반영해 시장 출시 시간(Time to Market)을 단축한다. 다만 다음과 같은 한계도 있다.

다른 방법론에 비해 유지 보수 작업의 부담이 높아질 수 있다.
요구 사항의 방향성이 크게 변경되면 전체 모델이 무너질 위험이 있다.
민첩하고 빠른 대응을 요구하다 보니 협업이 많아져, 개발자에게 심리적 부담과 스트레스로 다가올 수 있다.
지속적인 변화에 적응하기 위해 새로운 기술을 끊임없이 학습해야 하는 부담이 존재할 수 있다.

애자일을 적용한 다양한 개발 방식

스크럼(scrum): 애자일 중 가장 대표적인 방식이다. 백로그와 스프린트를 핵심 구성 요소로 사용하며, 각 스프린트 종료 시점마다 목표에 맞는 기능이나 개선 사항을 반영한다.
익스트림 프로그래밍(Extreme Programming, XP): 요구 사항을 한 번에 수집하지 않고 반복 주기를 극히 짧게 운영하는 방식이다. 빠른 프로토타입 제작과 지속적인 수정, 변경, 배포가 특징이다.
칸반(Kanban): 엄밀히는 '시각적 작업 관리 도구'이지만 애자일의 한 형태로 본다. 작업을 카드 형태로 시각화해 진행 상황을 실시간으로 파악할 수 있으며, 지라(JIRA)와 같은 도구에서도 칸반 보드를 제공한다.

8-6 객체 지향 프로그램 표준, Unified Process

통합 프로세스(Unified Process, UP)는 UML과 함께 OMG(Object Management Group)에서 공개한 통합 개발 프로세스로, 객체 지향 프로그래밍의 실제 표준으로 간주된다. 통합 프로세스보다 줄임말인 UP를 자주 사용한다.

UP의 특징

개발 방식: 반복적이며 점진적이고 진화적인 개발 방법론이며, 개발 사이클은 보통 3주 단위로 반복한다.
위험 관리: 프로젝트 수행 과정에서 발생할 수 있는 위험 요소, 특히 아키텍처와 고객 요구 사항 측면의 위험을 우선적으로 식별하고 해결한다.
아키텍처 확정: 주로 상세화(elaboration) 단계에서 위험을 해결하며, 이 단계가 끝나면 시스템의 아키텍처가 확정된다.

여러 개발 방법론을 적용한 UP

UP는 폭포수 모델, 반복적 모델 등 기존의 개발 방법론을 조합하여 통합적으로 적용하는 프로세스다.

적용 모델	UP에서의 역할
폭포수 모델	개념화 단계에서 목표·범위를 정의하고 초기 요구 사항을 수집함(폭포수의 요구 사항 정의 단계와 유사)
나선형 모델	상세화 단계에서 아키텍처와 고객 요구 사항 관점의 위험을 조기에 발견하고 수정함
프로토타입 모델	상세화가 완료되면 주요 기능을 정의하고, 프로토타입을 개발해 기능 검증을 담당함
반복적 모델(증분형, 진화형)	반복적이고 점진적인 개발로 시스템을 구축함

UP의 4단계

개념화(inception) 단계: 프로젝트의 초기 평가를 진행하고 시스템의 구성 환경을 파악한다.
상세화(elaboration) 단계: 시스템의 구조를 정의하고 고객의 요구 사항을 분석해 유스 케이스를 도출한다. 주요 위험 요소를 집중적으로 분석하고 이해관계자와 협업해 해결하는, UP에서 가장 핵심적인 단계다.
구축(construction) 단계: 시스템을 배포할 수 있는 품질 수준에 도달할 때까지 개발과 테스트를 반복해서 수행한다.
전이(transition) 단계: 구축한 시스템을 실제 운영 환경에 배포하고, 마지막으로 사용자 교육과 인수인계를 진행한다.

이 글은 『 Do it! 클린 프로그래밍 』 책의 8장을 학습한 내용을 정리한 것입니다.

[코딩테스트] 약점 0개를 향한 7주, 코드트리 챌린지 완주 후기

mandus — Mon, 22 Jun 2026 14:35:57 +0900

1. 청약 통장 7주차 : 7주 만기 회고 & 스스로에게 보내는 축하

1-1. 7회차 미션

미션: 7주 만기 회고 & 스스로에게 보내는 축하
두 달 동안 한 주도 빠짐없이 달려온 스스로를 돌아보고, 그동안의 성장과 성과를 마음껏 자랑하는 회차다.
회차별 글, Trail 학습 이력 등 7주의 궤적을 한눈에 정리하는 데 의미가 있는 것 같다.

▲ 7회차 납입 가이드

1-2. 7주를 완주한 나에게

첫 글을 보면 갭체크 결과에 빨갛고 노란 약점들을 보며 놀랐던 게 엊그제 같은데, 한 회차도 거르지 않고 만기에 도착했다.
매주 미션을 제출하려고 키보드 앞에 앉으려고 했던 습관이 나를 여기까지 데려왔다는 게 가장 실감 난다.

▲ 코드트리 청약 통장 납입 현황

2. 가장 뿌듯했던 순간 : 우수 후기 선정과 그리디 완주

6회차에 쓴 글이 우수 학습 후기로 선정됐다. 솔직히 회차 미션을 채우려고 쓴 글이었는데, 누군가 읽고 의미 있다고 봐줬다는 게 생각보다 크게 뿌듯했다.
이 우수 후기라는 결과 하나가 마지막 주차까지 끌고 가는 동기가 됐다.

▲ 우수 학습 후기로 선정된 6회차 후기

실력 면에서 가장 달라진 건 그리디(Greedy)다. 5회차 갭체크에서 "부족"으로 내려갔던 영역인데, 이번에 Lesson 1. Greedy Algorithm을 끝까지 풀어 진도율 100%를 채웠다.
씨앗 아이콘이 새싹으로 바뀐 걸 보니 미루기만 하던 영역을 끝냈다는 게 눈으로 확인돼서 좋았다.

▲ Greedy Algorithm 진도율 100%

그리디에서 가장 헤맨 건 "사각형 채우기 3"이었다. 처음엔 눈앞에서 가장 큰 것부터 채우면 될 줄 알고 제출했다가 틀렸다.
다시 보니 그리디는 "지금의 최선"이 "전체의 최선"이 되는 근거가 있어야 성립한다는 걸, 한 번 틀리고 나서야 체감했다. 같은 날 접근을 바꿔 통과시켰을 때가 7주 중 가장 기억에 남는다.
제출 기록을 보면 "동전 더하기" 같은 기본 문제부터 "소괄호 매칭 수 최대화하기" 같은 Hard 난이도까지 통과시킨 흔적이 남아 있다. 틀렸다가 다시 맞힌 기록도 지우지 않았는데, 오히려 학습 과정처럼 느껴지는 것 같다.

▲ Easy 문제부터 Hard 문제까지 내 제출 기록

3. 시작할 때와 비교해 달라진 점

청약 통장 챌린지처럼 매주 반복적으로 해야 하는 과제는 잊어버리기도 쉽고 막연하게 느껴졌는데, 그것을 끝까지 성공해냈다!
만기를 기념해 갭체크를 다시 응시했다. 첫 갭체크에서 빨간색이던 영역이 어떻게 바뀌었는지, 7주 간의 변화를 객관적인 그래프로 확인하고 싶었다.
세 번의 갭체크를 한 표로 정리하니 약점이 한 칸씩 위로 올라가는 흐름이 한눈에 보였다.

영역	1차 (5/8)	2차 (6/7)	최종 (6/22)
단순 반복문	불안	안정	안정
Shortest Path	부족	해결	안정
Greedy	불안	부족	안정
DP I / Parametric Search	-	불안	안정
MST / String / Advanced DP	-	-	해결

빨간색과 노란색이 한 칸씩 위로 올라가더니, 최종 갭체크에서는 약점 박스가 0개가 됐다.
첫 글에서 세운 "부족한 지식 영역 0개" 목표를 실제로 달성한 순간이라, 표를 보고 한참을 들여다봤다.

▲ 1차(5/8), 2차(6/7) 갭체크 결과

▲ 최종(6/22) 갭체크 결과

4. 그만두고 싶던 고비와 비결

혼자 공부하는 건 쉽지 않았다. 솔직히 귀찮아서 "이번 주는 그냥 넘길까" 하고 미루고 싶은 마음이 매주 있었다.
그 고비를 넘긴 첫 번째 비결은 경품 추첨권이라는 보상이었다. 매주 납입할수록 추첨권이 쌓이니, 미루다가도 결국 다시 문제를 풀게 됐다.

▲ 청약 통장 혜택

두 번째 비결은 함께 달리는 사람들이었다. 내가 추천인으로 등록한 사람, 그리고 나를 추천인으로 등록해 준 사람이 매주 꾸준히 인증하는 걸 보면서 동기부여를 받았다.
혼자였다면 또 미뤘을 텐데, 옆에서 누가 달리고 있다는 사실만으로도 멈추기 어려웠다.

▲ 함께 달린 추천인들

사실 내가 추천인으로 등록한 지인이 나에게 "같이 하자"고 권한 게 시작이었다. 그렇다 보니 빠지면 안 된다는 책임감이 묘하게 생겼다. 덕분에 둘 다 끝까지 완주할 수 있었다. 혼자 하는 공부보다는 같이 하는 공부가 오히려 끝까지 하기 좋은 것 같다.

▲ 코드트리 1회차에 대한 대화

5. 앞으로의 계획과 AI 시대의 알고리즘

6회 납입을 채우면 8월 31일까지 코드트리를 무료로 이용할 수 있다. 청약 통장 챌린지가 끝나도 그 기간 동안 손을 놓지 않을 생각이다.
최종 갭체크에서 추천 범위(T6)까지는 안정권에 들었지만, 나머지 트레일이 아직 파란색(미추천 범위)으로 남아 있다. 무료 이용 기간 동안 T6 이후의 심화 트레일과 아직 다 못 푼 챕터를 채워볼 계획이다.
특히 Parametric Search와 MST는 갭체크에서 "해결"로 확인됐지만 아직 익숙하다고 말하긴 이르다. 다익스트라를 발판 삼아 그래프 심화를 더 단단히 다지려 한다.
요즘은 AI가 코드를 거의 다 써 준다. 하지만 그 코드가 맞는지, 어디서 느려지는지 검토하는 건 결국 사람이다. 알고리즘을 모르면 AI의 답을 검증할 수 없다. 특히 백엔드는 같은 기능도 쿼리 한 줄, 자료구조 하나로 응답 속도가 갈린다. AI가 짠 코드가 O(N²)인지 O(N log N)인지 판단하려면 결국 내가 알아야 한다.

6. 마무리

7주 전의 나는 실력을 "평균 정도"라고 막연히 생각했지만, 지금은 내 강점과 약점을 표로 설명할 수 있는 사람이 되었다.
어려워하던 다익스트라를 잡았고, 미루기만 하던 그리디까지 끝냈다. 그리고 첫 글에서 빨갛던 약점들이 최종 갭체크에선 모두 사라졌다. 약점을 하나씩 초록색으로 칠해온 7주였다고 생각한다.
혼자였다면 중간에 멈췄을 수도 있는데, 청약 통장 덕분에 약점을 직시하고 끝까지 넘을 수 있었다. 두 달간 운영해 주신 운영진분들께 감사드린다.
완주했다고 끝이 아니라, 계속 새로운 출발점에 서야 한다. 이 습관 그대로 다음 목표를 향해 계속 달릴 생각이다.

코드트리 갭체크 응시하러 가기

코드트리 바로가기

[코드트리] 동적계획법(DP) 쉽게 이해하기 (점화식부터 구현까지 총정리)

mandus — Mon, 15 Jun 2026 09:29:06 +0900

1. 청약 통장 6회차 : 나만의 알고리즘 개념서 만들기

1-1. 6회차 미션

미션: 나만의 방식으로 알고리즘 개념 설명하기
가장 자신 있거나 좋아하는 유형을 하나 골라, 다른 사람에게 설명하는 나만의 개념서를 작성한다.
쉬운 설명 + 코드트리 문제 풀이 과정 + 자주 하는 실수/꿀팁을 함께 담는다.

▲ 코드트리 - 6회차 납입 가이드

1-2. 주제 선정 이유

DP는 여러 문제에서 자주 만나본 유형이고, 점화식을 세워 푸는 과정 자체가 재밌어서 골랐다.
다만 최근 갭체크에서는 DP가 불안정한 지식으로 분류되어, 좋아하는 것과 별개로 손에 완전히 익지는 않은 상태였다.
이번 개념서를 쓰며 점화식 감각을 확실히 다지기로 했다.

2. 동적계획법(DP)이란

2-1. 개념 정의

동적계획법(Dynamic Programming) : 큰 문제를 같은 모양의 더 작은 문제로 쪼개 먼저 풀고, 그 결과를 모아 큰 문제를 해결하는 기법
점화식(recurrence) : 작은 문제의 답으로 큰 문제의 답을 표현한 식
초기조건(base case) : 더 쪼갤 수 없는 가장 작은 문제의 정답

▲ 코드트리 - 동적계획법

2-2. 점화식

코드트리에서는 1부터 N까지의 곱을 예시로 든다. F(N)을 1부터 N까지의 곱이라 정의하면 식은 다음과 같다.

- F(N) = F(N-1) × N (N > 1) : 점화식
- F(1) = 1 : 초기조건

큰 문제 F(5)는 F(4)를, F(4)는 F(3)을... 이런 식으로 한 칸씩 작은 문제로 내려가다 초기조건 F(1)=1에서 멈춘다.
거꾸로 F(1)부터 답을 모아 올라오면 F(5) = 1×2×3×4×5 = 120이 된다.

▲ 점화식 개념도

3. Bottom-up vs Top-down

같은 점화식이라도 코드로 옮기는 방법은 크게 두 가지로 나뉜다. 방향만 반대일 뿐 동일하다.

3-1. Bottom-up : 반복문으로 표 채우기

초기조건 F[1]을 먼저 채워두고, 작은 인덱스부터 큰 인덱스로 표를 채워 나가는 방식이다.
F[i]를 구할 때 F[i-1]이 이미 채워져 있다.

F = [0] * (n + 1)            # 결과를 저장할 표
F[1] = 1                     # 초기조건 먼저 채우기
for i in range(2, n + 1):    # 작은 값부터 차례대로
    F[i] = F[i - 1] * i      # 점화식을 그대로 옮김
print(F[n])                  # 큰 문제의 답

▲ Bottom-up 표 채우기

3-2. Top-down : 재귀와 메모이제이션

큰 문제를 함수로 호출하면, 함수가 알아서 작은 문제를 다시 호출하며 내려가는 방식이다.
종료조건 자리에 초기조건을 넣고, 나머지는 점화식을 그대로 적으면 된다.

def f(n):
    if n == 1:          # 종료조건 = 초기조건
        return 1
    return f(n - 1) * n  # 점화식

그런데 재귀를 그대로 쓰면 함정이 있다. 피보나치처럼 같은 작은 문제가 여러 번 호출되면 계산이 기하급수적으로 늘어난다.
이때 한 번 구한 답을 배열에 저장(메모이제이션)해 두면, 같은 호출은 즉시 재사용해 중복을 없앤다.

▲ 재귀 호출 트리와 메모이제이션

3-3. 두 방식 비교

구분	Bottom-up (반복문)	Top-down (재귀 + 메모)
방향	작은 문제 → 큰 문제	큰 문제 → 작은 문제
구현	for / while 반복문	재귀 호출
장점	스택 오버플로 걱정이 없고 빠르다	점화식과 코드가 1:1로 닮아 직관적이다
주의	채우는 순서를 직접 설계해야 한다	메모이제이션이 없으면 시간 초과가 난다

4. 코드트리 문제에 적용하기 : 사각형 채우기 3

▲ 코드트리 - 사각형 채우기 3

4-1. 문제 이해

문제 : 2×N 사각형을 1×2, 2×1, 1×1 타일로 빈틈없이 채우는 방법의 수를 구한다.
예제 : N=1 → 2가지, N=2 → 7가지, N=3 → 22가지.
작은 N의 답으로 큰 N의 답을 만드는 전형적인 DP 문제다.

4-2. 점화식 세우기

dp[n]을 "2×n 사각형을 채우는 방법의 수"로 정의하면, 점화식은 다음과 같다.

- dp[n] = 3 × dp[n-1] + dp[n-2] - dp[n-3] (n ≥ 3) : 점화식
- dp[0] = 1, dp[1] = 2, dp[2] = 7 : 초기조건

제대로 세웠는지 작은 N으로 검증한다. dp[3] = 3×7 + 2 - 1 = 22로 예제와 일치한다.
한 칸 더 확인하면 dp[4] = 3×22 + 7 - 2 = 71이다.
정확한 유도는 각 열에서 다음 열로 '튀어나온 칸'의 상태까지 추적해야 하지만, 이렇게 작은 N으로 식이 맞는지 검증하는 게 가장 빠르다.

4-3. 의사코드

1. dp[0]=1, dp[1]=2, dp[2]=7로 초기화한다.
2. i를 3부터 N까지 키우며 dp[i] = 3×dp[i-1] + dp[i-2] - dp[i-3]을 채운다.
3. dp[N]을 출력한다.

4-4. 구현 코드 (Java)

import java.util.Scanner;
 
public class Main {
    public static void main(String[] args) {
        Scanner sc = new Scanner(System.in);
        int n = sc.nextInt();
 
        long MOD = 1_000_000_007; 
        
        // dp[i] = 2×i 사각형을 채우는 방법의 수
        long[] dp = new long[Math.max(n + 1, 3)];
        dp[0] = 1;   // 빈 사각형: 1가지
        dp[1] = 2;
        dp[2] = 7;
 
        for (int i = 3; i <= n; i++) {
            dp[i] = (3 * dp[i - 1] + dp[i - 2] - dp[i - 3]) % MOD;

            if (dp[i] < 0) {
                dp[i] += MOD;
            }
        }
 
        System.out.println(dp[n]);
    }
}

이 문제는 Bottom-up으로 풀었다.
N이 커지면 경우의 수가 빠르게 늘어나므로, 자바에서는 결과 자료형을 long으로 두는 게 안전하다. (파이썬은 큰 수를 자동 처리한다.)
뺄셈 때문에 음수가 나올 수 있으니 dp[i] = ((식) % MOD + MOD) % MOD 형태로 보정한다.

코드트리 트레일 둘러보러 가기

5. 자주 하는 실수

초기조건을 빠뜨린다. 점화식만 적고 base case를 안 넣으면 재귀가 끝나지 않거나 표가 비어버린다. 점화식보다 초기조건을 먼저 적는 습관이 안전하다.
점화식의 방향을 헷갈린다. F[i]가 F[i-1]에 의존하면, 반복문은 반드시 작은 i부터 채워야 한다. 순서가 꼬이면 아직 비어 있는 칸을 참조하게 된다.
재귀에 메모이제이션을 안 붙인다. 점화식이 맞아도 중복 호출 때문에 시간 초과가 난다. 재귀 DP에는 메모 배열이 필수다.
배열 인덱스 범위를 놓친다. 크기를 n+1로 잡고 1번 인덱스부터 쓰면 off-by-one 실수를 줄일 수 있다.

나만의 DP 풀이 순서
- 1단계: 상태(무엇을 dp[i]로 둘지)를 한 문장으로 정의한다.
- 2단계: dp[i]를 더 작은 항으로 표현하는 점화식을 세운다.
- 3단계: 초기조건을 정한다.
- 4단계: 반복문 또는 재귀+메모 중 편한 쪽으로 옮긴다.

6. 마무리

예전에는 DP를 보면 점화식을 어떻게 세울지 막막했는데, 상태 정의 → 점화식 → 초기조건이라는 순서를 정해두니 편했다.
특히 Bottom-up과 Top-down이 결국 같은 점화식의 방향만 다른 것이라는 점을 그림으로 그려보고 나서 머릿속에서 두 방식이 정리되었다.
갭체크에서 불안정하게 떴던 DP를 직접 설명해보니, 남에게 설명할 수 있을 때 비로소 내 것이 된다는 걸 다시 느꼈다.

[코테 중간 점검] 코드트리 갭체크로 한 달 만에 약점 유형 극복 후기

mandus — Sun, 7 Jun 2026 22:51:22 +0900

1. 청약 통장 5회차 : 한 달 간의 변화 & 중간 회고

1-1. 5회차 미션

미션: 중간 점검! 갭체크 응시하고 4주 간의 성장 돌아보기
첫 갭체크 후 세웠던 목표를 향해 꾸준히 나아가고 있는지, 방향이 맞는지를 스스로 점검하는 회차다.
진단 그래프의 색이 실제로 어떻게 바뀌었는지 객관적으로 확인하는 데 의미가 있다.

1-2. 첫 갭체크 결과 (5/8)

불안정한 지식 : 단순 반복문, Greedy
부족한 지식 : Shortest Path (다익스트라)
출력과 조건문은 안정적이었지만, 단순 반복문과 BFS는 시간 안에 풀지 못했고 다익스트라는 아예 건너뛴 상태였다.

참고로 갭체크는 아래 이미지 또는 본문 하단 링크를 통해 누구나 무료로 응시할 수 있다.

2. 지난 한 달 동안 한 일들

2-1. 1~2주차 : 단순 반복문과 중첩 루프

코드트리에서 진단 직후 추천받은 챕터부터 복습하며 기초를 다시 잡았다.
특히 중첩 반복문, 반복 종료 조건, 제어 변수 변경 세 가지를 의식하며 문제를 풀었다.
반복 단위를 손으로 표에 그려보는 습관을 들이니 인덱스 실수가 눈에 띄게 줄었다.

2-2. 3~4주차 : Greedy와 BFS / 그래프 탐색

Greedy는 "왜 이 선택이 최적인가"를 설명할 수 있을 때만 통과한다는 걸 알았지만, 감각을 잡는 것은 어려웠다.
BFS는 큐, 방문 체크, 레벨 단위 탐색이라는 세 가지 뼈대를 먼저 외운 뒤 문제에 적용했다.
그래프 탐색 자체에 익숙해지다 보니, 부족 영역이던 다익스트라까지 손이 닿게 된 것은 예상 밖의 수확이었다.

3. 두 번째 갭체크 결과

지난 갭체크에서 나온 결과를 가지고 학습 목표를 설정해 현재 상태가 어떻게 변화했는지 점검했다.

3-1. 두 번째 갭체크 (6/7)

불안정한 지식 : DP I, Shorten Time Technique, Parametric Search
부족한 지식 : Greedy
해결한 문제 레벨이 전반적으로 올라가면서, 기존 약점은 사라지고 더 고난도 개념이 새 약점으로 등장했다.

3-2. 갭체크 결과 비교

영역	첫 갭체크 (5/8)	두 번째 갭체크 (6/7)
출력 / 조건문	안정	안정 유지
단순 반복문	불안정	안정
BFS / 완전탐색 / 백트래킹	미해결	안정
Shortest Path (다익스트라)	부족	해결
Greedy	불안정	부족
DP I / Shorten Time / Parametric Search	미확인	불안정

가장 의외였던 건 가장 걱정했던 다익스트라가 오히려 약점에서 빠졌다는 점이다. 그래프 탐색을 다지는 과정에서 자연스럽게 따라온 것 같다. 반대로 Greedy는 "불안정"에서 "부족"으로 내려갔다. 손이 잘 안 가던 영역이라, 솔직히 변명의 여지가 없었다.

4. 남은 4주 학습 목표

1순위 : Greedy
2순위 : DP I, Shorten Time Technique, Parametric Search
3순위 : 종합 문제 풀이 + 시간 제한 안에서 푸는 연습

한 달 회고 한 줄
- 무서워하던 다익스트라는 잡았고, 만만하게 본 그리디에 발목 잡혔다.
- 약점이 바뀐다는 건 실력이 한 칸 올라갔다는 뜻이라 믿는다.
- 다음 회차엔 그리디까지 초록색으로 칠하고 돌아오겠다.

5. 마무리

다익스트라는 어렵게 느꼈지만 막상 해보니 풀렸고, Greedy가 오히려 힘들었다.
혼자였다면 그리디를 또 미뤘을 텐데, 청약 통장 덕분에 약점을 직시할 수 있었다.
그리디를 제대로 끝내고 코딩테스트 고난도 문제를 시간 안에 풀 수 있는 수준으로 가는 것이 목표다.

코드트리 갭체크 응시하러 가기

추천받았던 챕터 복습하러 가기

[코드트리 후기] 북마크로 만든 나만의 복습 루틴

mandus — Thu, 28 May 2026 22:21:01 +0900

1. 청약 통장 4회차 : 북마크로 만드는 나만의 오답노트

코드트리에 다시 보고 싶은 문제를 모아두는 북마크 기능이 있다는 걸 이번 미션을 통해 알게 됐다.
그동안은 "다음에 또 풀어야지" 하고 머리로만 기억하다 흐지부지됐는데, 폴더로 묶어두니 복습할 내용이 눈에 보이는 목록으로 정리됐다.

2. 나만의 북마크 폴더 기준

폴더를 막 만들면 결국 어지러워질 게 뻔해서, "북마크한 이유"를 기준으로 폴더를 나눴다.
단순히 유형별(그리디, 그래프)로만 묶지 않고, 갭체크 진단 등급을 그대로 가져와서 "얼마나 급한가"를 폴더 이름에 녹였다.

나만의 폴더 네이밍 규칙
- [1순위] 부족 - 다익스트라: 갭체크 빨간색 영역, 기초 원리부터 다시
- [2순위] 불안정 - 그리디: 감은 있는데 손이 헷갈리는 영역
- [복습완료] 한 번 더: 풀긴 했지만 시간이 오래 걸려 확인이 필요한 문제

폴더 이름에 우선순위 숫자를 붙였다. 목록을 열었을 때 폴더 중에서 무엇부터 손대야 할지 바로 알 수 있다.
"완료" 폴더를 따로 두었다. 다시 풀어서 막힘없이 통과한 문제는 완료 폴더로 옮겼다. 약점 폴더가 비어가는 게 눈에 보여서 동기부여가 되었다.

3. 북마크한 문제 다시 풀어보기

이번에 북마크한 대표적인 문제는 체크에서 진단받은 약점 두 가지였다.

구분	최대 수 만들기	간선 없애기
유형	그리디 (Greedy)	다익스트라 (Dijkstra)
난이도	70XP	90XP
평균 풀이 시간	16분	180분
정답률	63%	71%
갭체크 약점 등급	불안정	부족

3-1. 최대 수 만들기 (그리디)

여러 개의 수를 적당한 순서로 이어 붙여 만들 수 있는 가장 큰 수를 구하는 문제다. 예제는 43, 37, 4를 4 → 43 → 37 순으로 붙여 44337을 만든다.
처음 풀 때 나는 별 생각 없이 숫자를 내림차순으로 정렬했다. 그러면 43, 37, 4가 되어 43374가 나온다. 그런데 정답인 44337보다 작다.
"큰 수가 앞"이 아니라 "붙였을 때 더 큰 쪽이 앞"이라는 점이었다.

정렬 기준
- 두 수 a, b를 비교할 때 단순 크기가 아니라 이어 붙인 문자열로 비교한다.
- (a + b) 와 (b + a) 를 만들어서, 더 큰 쪽이 만들어지는 순서를 앞에 둔다.
- 예: 9 와 30 → "930" vs "309" → 930이 크므로 9가 앞이다.

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.Arrays;

public class Main {
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        
        int N = Integer.parseInt(br.readLine());
        String[] nums = new String[N];
        
        for (int i = 0; i < N; i++) {
            nums[i] = br.readLine();
        }
        
        Arrays.sort(nums, (a, b) -> (b + a).compareTo(a + b));
        
        if (nums[0].equals("0")) {
            System.out.println("0");
            return;
        }
        
        StringBuilder sb = new StringBuilder();
        for (String num : nums) {
            sb.append(num);
        }
        
        System.out.println(sb.toString());
    }
}

3-2. 간선 없애기 (다익스트라)

N개의 정점과 M개의 양방향 간선이 있는 그래프에서, 간선 하나를 제거했을 때 1번에서 N번까지의 최단거리가 바뀌는 경우의 수를 구하는 문제다.
평균 풀이 시간이 180분이라는 통계가 말해주듯, 갭체크에서 "부족" 판정을 받은 내게는 가장 무거운 문제였다.
다익스트라 자체가 아니라 "문제를 어떻게 분해할지"가 어려웠다.
- 먼저 원래 그래프에서 1번 → N번 최단거리를 한 번 구해 기준값으로 저장한다.
- 간선을 하나씩 제거한 그래프에서 다시 최단거리를 구한 뒤, 기준값과 다르면 카운트한다.

원래 1 → 5 최단거리는 1-3-5 경로의 2+1 = 3이다. 7번 간선(3-5)을 지우면 1-4-5의 1+3 = 4로 바뀐다. 최단거리가 3에서 4로 달라지므로 이 경우만 카운트되어 답은 1이 된다.

- 다익스트라는 문제에 따라 반복해서 호출할 수 있다.
- 어떤 간선이 최단경로에 영향을 주는지 그 간선을 빼고 다시 최단거리를 재보는 것으로 알 수 있다.

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
import java.util.PriorityQueue;
import java.util.StringTokenizer;

public class Main {
    
    static class Edge {
        int to, weight, id;
        public Edge(int to, int weight, int id) {
            this.to = to;
            this.weight = weight;
            this.id = id;
        }
    }

    static class Node implements Comparable<Node> {
        int v;
        long dist;
        public Node(int v, long dist) {
            this.v = v;
            this.dist = dist;
        }
        @Override
        public int compareTo(Node o) {
            return Long.compare(this.dist, o.dist);
        }
    }

    static int N, M;
    static List<Edge>[] graph;
    static int[] parentVertex;
    static int[] parentEdgeId;
    static final long INF = Long.MAX_VALUE;

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());

        N = Integer.parseInt(st.nextToken());
        M = Integer.parseInt(st.nextToken());

        graph = new ArrayList[N + 1];
        for (int i = 1; i <= N; i++) {
            graph[i] = new ArrayList<>();
        }

        for (int i = 0; i < M; i++) {
            st = new StringTokenizer(br.readLine());
            int u = Integer.parseInt(st.nextToken());
            int v = Integer.parseInt(st.nextToken());
            int w = Integer.parseInt(st.nextToken());
            graph[u].add(new Edge(v, w, i));
            graph[v].add(new Edge(u, w, i));
        }

        parentVertex = new int[N + 1];
        parentEdgeId = new int[N + 1];
        Arrays.fill(parentVertex, -1);
        Arrays.fill(parentEdgeId, -1);

        long originalDist = dijkstra(-1, true);

        if (originalDist == INF) {
            System.out.println(0);
            return;
        }

        List<Integer> pathEdges = new ArrayList<>();
        int curr = N;
        while (curr != 1) {
            pathEdges.add(parentEdgeId[curr]);
            curr = parentVertex[curr];
        }

        int ans = 0;
        for (int skipEdgeId : pathEdges) {
            long newDist = dijkstra(skipEdgeId, false);
            if (newDist > originalDist) {
                ans++;
            }
        }

        System.out.println(ans);
    }

    static long dijkstra(int skipEdgeId, boolean savePath) {
        long[] dist = new long[N + 1];
        Arrays.fill(dist, INF);
        PriorityQueue<Node> pq = new PriorityQueue<>();

        dist[1] = 0;
        pq.offer(new Node(1, 0));

        while (!pq.isEmpty()) {
            Node current = pq.poll();
            int u = current.v;

            if (current.dist > dist[u]) continue;

            for (Edge edge : graph[u]) {
                if (edge.id == skipEdgeId) continue;

                int v = edge.to;
                long nextDist = current.dist + edge.weight;

                if (nextDist < dist[v]) {
                    dist[v] = nextDist;
                    if (savePath) {
                        parentVertex[v] = u;
                        parentEdgeId[v] = edge.id;
                    }
                    pq.offer(new Node(v, nextDist));
                }
            }
        }

        return dist[N];
    }
}

4. 나만의 복습 루틴

코드트리 커리큘럼을 그날 분량만큼 진행한다.
풀다가 막혔거나 시간이 오래 걸린 문제는 약점 폴더에 북마크한다.
전날 북마크한 문제 중 1순위 폴더부터 한 문제를 다시 푼다.
주말에는 복습완료 폴더로 옮기지 못한 문제만 모아 한 번 더 돌린다.

5. 마무리

전에는 문제를 "푼다"는 행위 자체에만 집중했는데, 북마크 기능을 쓰고 나서는 "틀린 문제를 어떻게 다시 만나느냐"가 더 중요하다는 걸 체감했다.
다음 회차에도 약점 폴더를 계속 비워가면서, 8주 뒤 갭체크 재응시 때 그래프가 어떻게 달라지는지 직접 확인해 볼 생각이다.

코드트리 북마크(나의 리스트) 보러 가기

코드트리 갭체크 응시하러 가기

[코딩테스트 독학] 알림톡과 깃허브 잔디로 만드는 1일 1코테 루틴 (feat. 코드트리)

mandus — Sun, 24 May 2026 19:27:21 +0900

1. 청약 통장 3회차 : 꾸준함을 만드는 나만의 루틴 설계

1회차에서는 갭체크로 "Shortest Path는 부족한 지식, 단순 반복문과 Greedy는 불안정한 지식"이라는 진단을 받았다.
약점을 알았으니 8주 학습 계획을 세웠고, 첫 일주일은 의욕적으로 문제를 풀려고 했다.
그런데 막상 어렵게 느껴지는 건 알고리즘이 아니라 "매일 꾸준히 책상 앞에 앉는 일"이었다.

3회차 미션
다양한 동기부여 방식으로 꾸준히 학습한 경험 공유
: 알림톡, 깃허브 연동, 본인만의 동기 유지 방식 중 하나 이상을 적용하고 공유하기

이번 회차 미션을 보고 가장 먼저 든 생각은 "이건 내가 가장 약한 부분이다"라는 것이었다.
지금까지 해왔던 코딩테스트 공부 패턴이 늘 비슷했기 때문이다.

2. 그동안 실패했던 이유

오랫동안 유지하는 것이 가장 어려운 것 같다.

1주차: 매일 2~3문제씩 풀이함.
2주차: 하루 빠지면 죄책감이 듦. 다음 날에 보상하려 5문제 풀고 지침.
3주차: 결국 멈춤.
한 달 뒤: 다시 시작하지만 이전에 풀었던 유형이 가물가물함.

3. 이번 회차에 적용한 동기 유지 방식

3-1. 코드트리 학습 리마인더 알림톡 설정

▲ 알림톡 설정

설정 경로: 계정 설정 > 알림
매일 정해진 시간에 카카오톡으로 "오늘의 학습 시간" 알림이 도착한다.
알림 자체보다도, 알림을 본 순간 "아 맞다, 오늘 아직 안 풀었지"라는 생각이 강하게 든다.
알림을 무시하고 넘어가도 "내가 의도적으로 무시했다"는 사실에 죄책감이 든다.

3-2. 깃허브 연동

▲ 깃허브 연동

설정 경로: 코드트리 깃허브 연동
코드트리에서 푼 문제가 자동으로 개인 깃허브 레포지토리에 커밋된다.
가장 큰 효과는 두 가지다.
1. 잔디가 매일 채워지는 걸 보면 기록이 끊기는 게 싫어서 자발적으로 한 문제라도 풀게 된다.
2. 개발자 취준생 입장에서 깃허브 프로필이 자연스럽게 학습 기록 포트폴리오 역할을 한다.
백준의 BaekjoonHub와 비교하면 별도 확장 프로그램 설치 없이 계정 연동 한 번으로 자동화된다는 점에서 편리하다.

3-3. 나만의 동기 유지 방법

블로그 회고 글: 주 1회 청약 통장 챌린지 회고 글을 작성한다. 외부에 공개된다는 사실이 "적어도 일주일에 한 번은 정리할 내용이 있어야 한다"는 마음으로 활동을 강제할 수 있다.
스터디 진행도 공유: 같이 공부하는 친구에게 주 1회 문제 풀이를 공유한다.

4. 결과

알림톡 적용 전: 일주일에 학습 누락 평균 4~5일
알림톡 + 잔디 적용 후: 일주일에 학습 누락 1~2일

▲ Github 잔디

5. 앞으로의 다짐

청약 통장 챌린 8주 완주 후 갭체크 재응시를 통해 "부족한 지식" 영역 0개 만들기
깃허브 잔디 연속 30일 이상 유지하기
단순 반복문, Greedy 영역을 "안정적인 지식"으로 끌어올리기

6. 마무리

코드트리의 알림톡과 깃허브 연동은 설치도, 설정도 부담이 없이 할 수 있었다.
의지력이 떨어지는 날에도 "알림이 오니까, 잔디가 비니까" 라는 마음으로 한 문제는 풀게 된다. 이 한 문제가 쌓여서 8주를 만들 수 있을 것 같다.
다음 회차에서는 실제 문제 풀이 과정에서의 학습 회고를 정리해보려고 한다.

코드트리 바로가기

알림톡 설정하러 가기

깃허브 연동하러 가기

[코드트리] Greedy(탐욕 알고리즘) 약점 극복 학습 후기

mandus — Mon, 18 May 2026 20:24:36 +0900

1. 청약 통장 2회차 : 차근차근 약점 집중 돌파

2회차 미션의 핵심은 내 약점 유형을 직접 골라 레슨 1개 이상을 완료하는 것이다.
1회차에서 갭체크 진단을 통해 Greedy(탐욕 알고리즘)가 "불안정한 지식" 영역으로 분류되었기 때문에, 이번 회차에서는 Greedy 챕터를 집중 학습하기로 결정했다.
진단 결과를 바탕으로 추천된 챕터는 여기에서 확인할 수 있다.

2. 코드트리 커리큘럼 구조 확인

2-1. 레슨 단위 학습 구조: 기본 - 연습 - 테스트

코드트리의 가장 큰 특징은 기본 - 연습 - 테스트의 3단계 구조로 문제를 학습할 수 있다는 점이다.
기본 문제: 하나의 개념과 하나의 문제가 1:1로 짝을 이루도록 구성되어 있다. 개념 설명을 읽은 직후 바로 문제에 적용할 수 있어서, 이론과 실습 사이의 간격이 거의 없다.
연습 문제 / 테스트 문제: 해당 레슨에서 학습한 모든 개념이 함께 제공되며, 여러 개념을 복합적으로 적용하는 연습을 한다.

2-2. 타 서비스와의 비교

항목	코드트리	백준 / 프로그래머스
학습 구조	개념 - 기본 - 연습 - 테스트 단계별 제공	문제만 제공, 개념 설명 없음
약점 진단	갭체크로 유형별 약점 진단 가능	별도 진단 기능 없음
해설 제공	개념 설명 - 모범 코드 - 토론 제공	커뮤니티 풀이에 의존
학습 방향 제시	진단 결과 기반 추천 챕터 안내	스스로 문제 선택

백준이나 프로그래머스에서는 "어떤 문제를 풀어야 할지"를 스스로 결정해야 했다. 반면 코드트리는 갭체크 진단 결과를 기반으로 추천 챕터를 제시해 주기 때문에 방향을 잃지 않고 학습을 이어갈 수 있다. (백준은 현재 서비스 종료함)

3. Greedy 레슨 학습 후기

3-1. Greedy 알고리즘

Greedy(탐욕 알고리즘): 현재 상황에서 가장 최선인 선택을 반복하여 전체 최적해를 구하는 방식이다.
코드트리 레슨에서는 Greedy를 처음 소개할 때 동전 거슬러주기 문제를 예시로 사용한다. 1, 4, 5원짜리 동전으로 8원을 거슬러줄 때, 단순히 큰 동전부터 사용하면 5 + 1 + 1 + 1로 4개가 되지만, 실제 최솟값은 4 + 4로 2개다.
이 예시를 통해 Greedy가 항상 최적해를 보장하지는 않는다는 점을 먼저 인식하게 된다. Greedy가 유효한 경우는 "현재의 최선이 전체의 최선임을 증명할 수 있을 때"다.

3-2. 레슨에서 배운 문제 패턴

회의실 준비 문제: Greedy 레슨에서 가장 인상 깊었던 문제다. 끝 시간 기준 오름차순 정렬이라는 하나의 선택 기준만으로 최적해가 도출된다는 사실이 처음에는 직관적으로 와닿지 않았다.
- 코드트리는 정답 접근법을 바로 알려주지 않고, 시작 시간 기준 정렬 / 구간 길이 기준 정렬 / 끝 시간 기준 정렬 순으로 각각의 반례를 하나씩 보여줬다.
- 이 방식 덕분에 "왜 끝 시간 기준으로 정렬해야 하는가"에 대한 근거가 명확하게 잡혔다.
연속 부분 합의 최댓값: 합이 음수가 되는 순간 구간을 끊고 다음 원소부터 다시 시작하는 패턴이다. O(N) 시간 복잡도로 해결 가능하다는 점이 인상적이었다.
레슨을 통해 어떤 정렬 기준이 유효한지 반례로 직접 검증하는 사고방식을 갖게 되었다.

4. 직접 푼 문제: 자연수 M/2개의 쌍

4-1. 문제 설명

M개의 자연수를 두 개씩 짝지어 M/2개의 쌍을 만들 때, 두 수의 합이 가장 큰 쌍의 합 C의 최솟값을 구하는 문제다.
난이도 80XP / 평균 풀이 시간 65분 / 정답률 41%로, Greedy 레슨 안에서도 난도가 있는 문제에 속한다.

4-2. 아이디어: Greedy + 투 포인터

C(최댓값)를 최소화하려면, 가장 큰 수와 가장 작은 수를 짝짓는 것이 직관적으로 떠오른다. 이것이 이 문제의 Greedy 핵심 아이디어다.
오름차순 정렬 후 왼쪽 포인터(작은 값)와 오른쪽 포인터(큰 값)를 좁혀가며 짝을 만든다. 이 과정에서 매칭 가능한 수(matchCount)만큼 count를 차감하고, count가 0이 되는 순간 해당 포인터를 이동한다.
같은 값이 여러 개 있는 경우를 처리하기 위해 (count, value) 쌍으로 입력을 관리하는 것이 이 문제의 포인트다. 값을 그대로 배열에 풀어 넣으면 count가 매우 클 경우 시간 초과가 발생한다.

4-3. 풀이 코드

import java.io.*;
import java.util.*;

public class Main {
    static class NumberInfo implements Comparable<NumberInfo> {
        long count;
        long value;

        public NumberInfo(long count, long value) {
            this.count = count;
            this.value = value;
        }

        @Override
        public int compareTo(NumberInfo o) {
            return Long.compare(this.value, o.value);
        }
    }

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int n = Integer.parseInt(br.readLine().trim());

        NumberInfo[] numbers = new NumberInfo[n];
        for (int i = 0; i < n; i++) {
            StringTokenizer st = new StringTokenizer(br.readLine());
            long count = Long.parseLong(st.nextToken());
            long value = Long.parseLong(st.nextToken());
            numbers[i] = new NumberInfo(count, value);
        }

        // value 기준 오름차순 정렬
        Arrays.sort(numbers);

        int left = 0;
        int right = n - 1;
        long maxC = 0;

        while (left <= right) {
            // 왼쪽 포인터와 오른쪽 포인터가 만난 경우: 같은 값끼리 짝
            if (left == right) {
                if (numbers[left].count > 0) {
                    maxC = Math.max(maxC, numbers[left].value * 2);
                }
                break;
            }

            long matchCount = Math.min(numbers[left].count, numbers[right].count);
            long currentSum = numbers[left].value + numbers[right].value;

            // 현재 쌍의 합으로 최댓값 갱신
            maxC = Math.max(maxC, currentSum);

            // 매칭된 만큼 개수 차감
            numbers[left].count -= matchCount;
            numbers[right].count -= matchCount;

            // 개수가 0이 된 포인터 이동
            if (numbers[left].count == 0) left++;
            if (numbers[right].count == 0) right--;
        }

        System.out.println(maxC);
    }
}

4-4. 풀이 과정에서 헤맸던 부분

처음에는 입력값이 (개수, 값) 형태로 주어진다는 점을 간과하고 값을 배열에 직접 풀어 넣는 방식으로 접근했다. count가 10억 단위일 수 있기 때문에 이 방식은 메모리 초과로 이어졌다.
left == right인 경우: 같은 값끼리 서로 짝을 지어야 하는 상황이다. 이 케이스를 별도로 처리하지 않으면 오답이 발생한다.

import java.io.*;
import java.util.*;

public class Main {
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int n = Integer.parseInt(br.readLine().trim());

        List<Long> list = new ArrayList<>();

        for (int i = 0; i < n; i++) {
            StringTokenizer st = new StringTokenizer(br.readLine());
            long count = Long.parseLong(st.nextToken());
            long value = Long.parseLong(st.nextToken());

            // count만큼 value를 직접 추가
            for (long j = 0; j < count; j++) {
                list.add(value);
            }
        }

        Collections.sort(list);

        int left = 0;
        int right = list.size() - 1;
        long maxC = 0;

        while (left < right) {
            long currentSum = list.get(left) + list.get(right);
            maxC = Math.max(maxC, currentSum);
            left++;
            right--;
        }

        System.out.println(maxC);
    }
}

import java.io.*;
import java.util.*;

public class Main {
    static class NumberInfo implements Comparable<NumberInfo> {
        long count;
        long value;

        public NumberInfo(long count, long value) {
            this.count = count;
            this.value = value;
        }

        @Override
        public int compareTo(NumberInfo o) {
            return Long.compare(this.value, o.value);
        }
    }

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int n = Integer.parseInt(br.readLine().trim());

        NumberInfo[] numbers = new NumberInfo[n];
        for (int i = 0; i < n; i++) {
            StringTokenizer st = new StringTokenizer(br.readLine());
            long count = Long.parseLong(st.nextToken());
            long value = Long.parseLong(st.nextToken());
            numbers[i] = new NumberInfo(count, value);
        }

        Arrays.sort(numbers);

        int left = 0;
        int right = n - 1;
        long maxC = 0;

        while (left <= right) {

            long matchCount = Math.min(numbers[left].count, numbers[right].count);

            long currentSum = numbers[left].value + numbers[right].value;
            maxC = Math.max(maxC, currentSum);

            numbers[left].count -= matchCount;

            numbers[right].count -= matchCount;

            if (numbers[left].count == 0) left++;

            if (numbers[right].count == 0) right--;
        }

        System.out.println(maxC);
    }
}

5. 마무리

Greedy는 "가장 좋아 보이는 것을 고르면 되지 않나?"라는 생각에서 출발하지만, 반례를 만나는 순간 무너지는 알고리즘이다. 그 경계를 직접 확인하고 이해하는 과정이 이번 회차 학습의 핵심이었다.
코드트리의 개념 설명은 단순히 정답 접근법을 알려주는 것이 아니라, 틀린 접근 - 반례 - 올바른 접근 순으로 구성되어 있어 이해의 깊이가 달랐다. 이 방식 덕분에 문제를 틀리더라도 "왜 틀렸는지"를 스스로 납득할 수 있었다.
다음 회차에서는 갭체크에서 "부족한 지식"으로 분류된 Shortest Path(다익스트라) 챕터로 넘어갈 예정이다.

코드 트레일로 이동하기

갭체크 추천 챕터 확인하기

[구글 클라우드 스터디잼] Prompt Design in Vertex AI

mandus — Sat, 16 May 2026 12:14:45 +0900

구글 클라우드 스터디잼에 참가하여 'Prompt Design in Vertex AI'의 챌린지 랩을 진행한 내용을 정리했습니다. 챌린지 랩은 단계별 가이드 없이 학습한 내용만으로 시나리오를 직접 해결해야 하는 형태로, 이번에는 'Cymbal Direct'를 위한 생성형 AI 마케팅 도구를 Vertex AI Studio와 Workbench에서 구축하는 실습이었습니다.

1. Gen AI 시대의 MLOps

1.1 예측 AI vs 생성형 AI

구분	예측 AI (Predictive AI)	생성형 AI (Generative AI)
목적	분류, 회귀, 객체 탐지, 예측	새로운 콘텐츠 생성 (텍스트, 이미지, 코드)
학습 방식	모델을 처음부터(from scratch) 학습	사전학습 모델 발견 후 커스터마이징
데이터	대량의 라벨링 데이터	큐레이션된 데이터셋
평가 지표	정확도, 정밀도	유창성, 사실성, 브랜드 평판

예측 AI는 기존 데이터로 분류·회귀 같은 특정 문제를 푸는 데 초점이 있고, 생성형 AI는 패턴 학습을 통해 새로운 콘텐츠를 만들어내는 것이 핵심입니다. 두 영역이 MLOps의 기본 원칙은 공유하지만, 생성형 AI는 추가 적응(adaptation)이 필요합니다.

1.2 Gen AI MLOps의 새로운 단계

사전학습 모델 탐색: Model Garden에서 Google/오픈소스/서드파티 모델 선택
직접 예측 단축 경로: 프롬프트만으로 즉시 추론 실행 (전용 ML 파이프라인 불필요)
커스터마이징과 튜닝: Supervised Tuning, RLHF, 어댑터 레이어
- 어댑터 레이어는 수십 MB 크기로, 파운데이션 모델 옆에 결합되어 추론에 사용된다.
큐레이션된 데이터 통합: 임베딩, Vector Search, Grounding
새로운 평가/모니터링: Safety Score, Recitation Check

이번 챌린지 랩은 Model Garden에서 Gemini를 골라 Vertex AI Studio에서 프롬프트를 설계하고, Workbench(Jupyter)에서 Python 코드로 호출하는 흐름을 따름.

1.3 콘솔에서 주의할 점

실습을 시작하면서 한 가지 문제가 있었습니다. 기존 문서에서 "Vertex AI"로 표기되던 메뉴가 실제 콘솔에서는 Agent Platform으로 바뀌어 있습니다. 처음에 메뉴 위치를 찾지 못해 헷갈렸습니다.

▲ Google Skills 공지

▲ Agent Platform 콘솔 화면

2. 챌린지 랩 시나리오

Cymbal Direct라는 가상의 아웃도어 용품 온라인 리테일러가 신제품 라인 마케팅 캠페인을 준비 중이라는 설정입니다. 생성형 AI를 활용해 두 가지 도구를 만드는 것이 목표입니다.

도구	목적
이미지 분석 기반 제품 설명 생성기	제품 사진에서 자연의 감성을 담은 짧은 묘사 텍스트 생성
태그라인 생성기	제품 속성, 타겟 청중, 감정적 공감에 따른 광고 카피 생성

전체 챌린지는 총 4개의 Task로 구성됩니다. Task 1, 2는 Vertex AI Studio에서 프롬프트를 설계하는 단계이고, Task 3, 4는 그 프롬프트를 Python 코드로 내보내 Workbench에서 수정 및 실행하는 단계입니다.

3. Task 1. Gemini 이미지 분석 도구 만들기

3.1 목표

Vertex AI Studio에서 지정된 Gemini 모델로 Cloud Storage에 있는 Cymbal Direct 제품 이미지를 분석하여 다양한 스타일의 설명 텍스트를 생성하는 프롬프트 템플릿을 만듭니다.

3.2 진행 순서

Vertex AI Studio에서 새 프롬프트 생성, 모델은 챌린지에서 지정한 Gemini 모델 선택
이미지 입력으로 Cloud Storage 경로의 제품 이미지 첨부
아래 세 가지 스타일이 모두 나오도록 프롬프트 실험
- 이미지에서 영감을 받은 짧은 설명
- 광고에 어울리는 캐치프레이즈
- 자연 친화적 캠페인을 위한 시적 묘사
출력이 만족스러울 때까지 프롬프트와 파라미터(Temperature, Top-P 등) 조정
프롬프트 이름을 Cymbal Product Analysis로 지정
Save 클릭 후 지정된 리전 선택

▲ 이미지 입력 + 생성된 텍스트 결과

4. Task 2. Gemini 태그라인 생성기 만들기

4.1 목표

제품 속성, 타겟 청중, 감정 공감 코드를 파라미터로 받아 커스터마이징 가능한 태그라인을 생성하는 프롬프트 템플릿을 구축합니다.

4.2 System instructions 설정

프롬프트의 System instructions 칸에 다음 지시문을 입력합니다.

Cymbal Direct is partnering with an outdoor gear retailer.
They're launching a new line of products designed to encourage young people
to explore the outdoors.
Help them create catchy taglines for this product line.

4.3 Few-shot examples 작성

모델 출력 스타일을 잡기 위해 2개의 예시를 추가해야 합니다. 한 개는 챌린지에서 제공된 예시를 그대로 쓰고, 다른 한 개는 같은 형식으로 직접 작성했습니다.

Input	Output
Write a tagline for a durable backpack designed for hikers that makes them feel prepared. Consider styles like minimalist.	Built for the Journey: Your Adventure Essentials.
Write a tagline for a lightweight tent designed for young adventurers that makes them feel connected to nature. Consider styles like poetic.	Sleep Under Stars, Wake With the Wild.

Few-shot prompting이란? 모델에게 원하는 입출력 쌍을 몇 개 보여주는 것만으로 출력 스타일을 학습시키는 기법. 파인튜닝 없이도 도메인 특화 출력을 유도할 수 있음. 이번 Task에서는 2개의 예시로 출력 형식(짧은 문장, 콜론으로 두 절 구분, 영어 대문자 시작)까지 모델이 흉내내도록 유도함.

4.4 커스터마이징 파라미터

제품 속성: durable, lightweight, waterproof 등
타겟 청중: young adventurers, families 등
감정적 공감: empowered, connected, free 등
스타일: minimalist, poetic, bold 등

▲ 태그라인 생성 결과

4.5 저장

프롬프트 이름을 Cymbal Tagline Generator Template로 지정하고 지정된 리전에 저장합니다. Autosave로 이미 저장돼 있다면 이름만 정확한지 확인하면 됩니다.

5. Task 3. 이미지 분석 코드 실험

5.1 목표

Vertex AI Studio에서 만든 프롬프트를 Python 코드로 내보내, Workbench(Jupyter Notebook)에서 직접 호출하고 수정합니다.

5.2 진행 순서

콘솔에서 Agent Platform → Notebooks → Workbench로 이동
지정된 Workbench 인스턴스에서 Open JupyterLab 클릭
image-analysis.ipynb 열고 커널을 Python 3로 설정
전체 셀 실행하여 환경 정상 동작 확인
Vertex AI Studio → Cymbal Product Analysis 프롬프트 → 우측 Code 버튼 → 언어 Python → 두 번째 코드 셀을 노트북의 지정 셀에 복사
API 키 기반 인증 블록을 PROJECT_ID, LOCATION 기반 코드로 교체

API 키 방식을 PROJECT_ID/LOCATION 방식으로 바꾸는 이유? API 키는 노출 시 누구나 호출 가능하므로 운영 환경에서 위험함. Workbench는 이미 서비스 계정으로 인증된 환경이므로, 프로젝트와 리전만 명시하면 IAM 권한에 따라 안전하게 API를 호출할 수 있음. 보안의 기본 원칙인 최소 권한(Principle of Least Privilege)을 따른 것임.

▲ JupyterLab에서 image-analysis.ipynb 열기

▲ 코드 셀 복사

5.3 프롬프트 수정 두 가지

코드가 정상 동작하는 것을 확인한 후, 두 가지 요구사항에 맞춰 프롬프트를 수정합니다.

수정 항목	요구사항	방법
출력 길이	10단어 미만	프롬프트 본문을 더 구체적으로 (예: "in fewer than 10 words")
창의성	가장 창의적이고 예상치 못한 묘사 유도	Temperature 값을 높임 (힌트: 파라미터 조정 필요)

"창의적이고 예상치 못한" 묘사를 원한다면 Temperature를 높이고(예: 0.9 이상), 필요시 Top-P도 함께 조정합니다. 프롬프트 수정 후 셀을 다시 실행하여 결과가 짧고 더 창의적으로 변했는지 확인하고, 마지막에 노트북 파일을 반드시 저장해야 진행도 체크가 통과됩니다.

▲ 수정 후 결과

6. Task 4. 태그라인 생성 코드 실험

6.1 목표

Task 2에서 만든 태그라인 프롬프트를 Python 코드로 내보내, 마지막 입력에 특정 키워드를 강제하는 방식으로 수정합니다.

6.2 진행 순서

Workbench에서 tagline-generator.ipynb 열기 (커널 Python 3)
Vertex AI Studio의 Cymbal Tagline Generator Template 프롬프트 → Code → Python → 두 번째 코드 셀을 노트북에 복사
인증 블록을 PROJECT_ID, LOCATION 방식으로 교체
코드 실행하여 정상 출력 확인
마지막 input을 수정하여 태그라인에 nature 키워드가 포함되도록 명시적 지시 추가
저장 후 재실행하여 결과 검증

6.3 키워드 강제 패턴

마지막 입력 텍스트를 아래처럼 수정합니다. 단순히 "include nature"라고 적기보다 "the tagline must explicitly include the word 'nature'"처럼 명령의 강도를 높이면 결과가 더 안정적입니다.

# 마지막 입력 예시
"""Write a tagline for a lightweight rain jacket designed for young adventurers
that makes them feel connected to the outdoors.
The tagline must explicitly include the word 'nature'.
Consider styles like poetic."""

▲ tagline-generator.ipynb 코드 셀

▲ nature 키워드가 포함된 결과

7. 정리

7.1 챌린지 랩에서의 Gen AI 개발 흐름

Vertex AI Studio에서 프롬프트 프로토타이핑
출력 스타일을 잡기 위한 Few-shot 예시 설계
창의성/길이/포맷 제어를 위한 샘플링 파라미터 조정
최종 프롬프트를 Python 코드로 내보내 애플리케이션에 통합
Workbench에서 인증/배포 환경에 맞춰 코드 수정

실제 운영 단계에서는 여기에 평가(Evaluation Service), 모니터링(Safety Score), Vector Search 기반 Grounding, Vertex Extensions를 통한 외부 도구 연결이 추가된다고 합니다. 추가로 아래와 같이 정리할 수 있습니다.

프롬프트는 새로운 인터페이스: API 호출처럼 정형화된 호출이 아니라 자연어로 모델의 동작을 정의함.
Few-shot 예시의 위력: 파인튜닝 없이도 출력 스타일을 정밀하게 제어할 수 있음.
파라미터 조정의 중요성: Temperature 하나로 같은 프롬프트의 출력 다양성이 완전히 달라짐.
Studio → Workbench로의 연결: 프로토타이핑된 프롬프트가 그대로 운영 코드로 이어짐.

전통적인 LLM 통합	이번 실습 방식
API 키를 코드에 직접 하드코딩하 호출	IAM 기반 인증으로 안전하게 호출
프롬프트를 코드 안에서 직접 수정	Studio에서 시각적으로 설계 후 코드로 내보내기
출력 형식을 후처리로 강제	Few-shot 예시로 모델 출력 자체를 제어
파라미터 튜닝을 별도 코드 변경으로 처리	Studio UI에서 즉시 실험·조정

이 글은 '2026 구글 클라우드 스터디잼'에서 학습한 내용을 바탕으로 작성되었습니다.

[코드트리 후기] 코딩테스트 준비, 갭체크부터 청약 통장 1회차 시작하기

mandus — Mon, 11 May 2026 17:09:15 +0900

1. 청약 통장 1회차 : 내 약점 파악과 목표 설정

1-1. 갭체크란

갭체크(Gap Check): 적응형 진단 테스트로, 응시자의 풀이 결과에 따라 다음 문제의 난이도가 동적으로 조정되는 방식
출력, 조건문 같은 기초부터 Shortest Path 같은 고급 알고리즘까지 폭넓은 범위를 짧은 시간 안에 검증한다.
각 문제마다 평균 풀이 시간과 평균 시도 횟수가 비교 지표로 제공되어, 단순히 풀었는지가 아니라 얼마나 효율적으로 풀었는지까지 평가된다.

1-2. 응시 전 vs 응시 후

처음에는 "기초 문제부터 차근차근 나오겠지" 싶었는데, 막상 응시해 보니 출력 → 조건문 → 단순 반복문 → BFS → Greedy → Shortest Path 순으로 난이도가 빠르게 올라갔다.
BFS와 Shortest Path 문제는 평소에 자주 다루지 않던 유형이라 문제 이해 자체에 시간이 걸렸다.

2. 갭체크 결과

불안정한 지식 (단순 반복문, Greedy)
- 기본 for/while 루프는 사용할 수 있지만, 중첩 반복문이나 반복 종료 조건 설정, 제어 변수 변경 등을 효과적으로 다루지 못한다.
- 다양한 반복문 구조와 중첩 루프 활용, 반복 조건과 제어 변수에 대한 심도 있는 이해가 필요하다.
부족한 지식 (Shortest Path)
- 다익스트라 알고리즘의 기본 원리조차 확실히 이해하지 못한 상태로, 단순한 그래프에서도 최단 경로 탐색을 올바르게 구현하기 어렵다.
- 이 상태에서는 LCA, MST 같은 고급 알고리즘 학습에도 어려움이 따르므로, 다익스트라와 우선순위 큐 기반 최단 경로부터 익혀야 한다.

3. 학습 목표 설정

3-1. 우선순위 정리

학습 우선순위
- 1순위: Shortest Path (다익스트라)
- 2순위: 단순 반복문 응용, Greedy 패턴
- 3순위: BFS/DFS

3-2. 주차별 학습 계획

1~2주차: 단순 반복문 응용과 중첩 루프 패턴 집중
3~4주차: Greedy 패턴 안정화, BFS 기초
5~6주차: 다익스트라 알고리즘과 우선순위 큐 학습
7~8주차: 종합 문제 풀이 + 시간 제한 안에서 푸는 연습

3-3. 8주 후 목표

갭체크 재응시를 통해 "부족한 지식" 영역을 0개로 만들기
단순 반복문, Greedy 영역을 "안정적인 지식"으로 끌어올리기
코딩테스트에서 고난도 문제를 시간 안에 안정적으로 풀 수 있는 수준 도달하기

4. 마무리

갭체크를 응시하기 전까지는 내 코딩테스트 실력이 "중간쯤"이라고 생각하고 있었다. 객관적인 진단을 받아보니 강점과 약점이 명확히 분리되는 그래프 형태로 나타나서 충격받았다.
"불안정한 지식"과 "부족한 지식"을 구분해서 보여주는 방식이 인상 깊었다. 단순히 못 한다/잘 한다가 아니라, 어디서부터 손대야 할지 알 수 있었다.
8주 동안 청약 통장을 통해 약점을 보완하는 학습을 하기 위해 노력할 예정이다.

코드트리 갭체크 응시하러 가기

[스터디14] 01. 클린 코드의 원칙

mandus — Sat, 9 May 2026 04:32:13 +0900

1장. 클린 코드의 원칙

클린 코드란 동료들이 쉽게 이해하고, 수정과 확장이 용이한 '좋은' 코드를 의미한다.

1-1 클린 코드를 지켜야 하는 이유

개발자는 일정 압박, 잦은 변경 요청, 개발자 간의 다양한 코딩 스타일 때문에 일관된 코드 스타일을 유지하기 어렵다. 그럼에도 클린 코드를 지키는 이유는 다음과 같다.

다른 개발자나 미래의 자신이 코드를 이해하고 수정하는 데 드는 시간과 비용을 크게 줄인다.
유지 보수 비용 절감 및 개발 생산성 향상에 직접적으로 기여한다.
장기적으로 프로젝트의 성공을 보장하는 필수 요소이다.

1-2 의미 있는 이름 짓기

네이밍 규칙 4가지

표기 방식의 일관성을 유지하기 위해 미리 정한 네이밍 규칙이 있다.

규칙	방식	예시 (user name)
카멜 케이스	뒤에 오는 단어의 첫 글자를 대문자로 표기	userName
파스칼 케이스	두 단어의 첫 글자를 모두 대문자로 표기	UserName
케밥 케이스	단어마다 하이픈(-)으로 연결	user-name
스네이크 케이스	단어마다 언더바(_)로 연결	user_name

자바에서의 네이밍 규칙

변수: 소문자로 구성하거나 카멜 케이스 적용
함수: 카멜 케이스 적용
클래스: 파스칼 케이스 적용
상수: 대문자로 구성

케밥 케이스는 yml 형태의 파일명에, 스네이크 케이스는 데이터베이스의 컬럼명(열 이름)에 주로 사용된다.

가독성 고려하기

가독성 좋은 코드란 한마디로 잘 읽히고 작성한 의도를 예측할 수 있는 코드다. 변수, 함수, 클래스 이름은 작성한 코드의 기능과 의도가 잘 드러나도록 지어야 한다.

기능에 맞는 이름 짓기

클래스: 객체로 사용하므로, 명사 또는 명사구로 이름 짓기
함수: 동작을 수행하므로, 동사 또는 동사구로 이름 짓기
구성 요소의 위치와 맥락에 맞게 이름을 지어야 한다. (예: User 클래스 내부 멤버 변수에 user를 붙이는 것은 부적절하다)
매직 넘버는 의미를 알 수 있도록 상수로 선언하면 가독성과 유지 보수성이 모두 향상된다.

1-3 주석 제대로 사용하기

가독성이 뛰어나고 작성 의도가 분명하게 파악되는 코드보다 더 좋은 주석은 없다. 주석은 오직 보조 수단이며, 제대로 사용할 경우에만 유효하다.

좋은 주석 vs 나쁜 주석

좋은 주석	나쁜 주석
작성 의도를 설명하는 주석	데드 코드(미사용 코드)
정보나 의미를 알려주는 주석	이력 관리용 주석 (Git이 대체함)
강조나 경고 주석	코드 작성 시점을 기념하는 주석
TODO 주석	거짓 정보가 담긴 주석
소유권, 저작권을 나타내는 주석

데드 코드와 이력 관리용 주석

'언젠가는 쓰지 않을까?' 하는 마음에 코드를 주석 처리해 남겨두는 경우가 많지만, 데드 코드는 코드 복잡도를 높이기만 할 뿐이다. 깃허브 같은 형상 관리 도구로 언제든 이전 버전을 복원할 수 있으므로 과감히 삭제하는 편이 좋다.

거짓 정보가 담긴 주석

반드시 제거해야 하는 주석은 잘못된 정보가 담긴 주석이다. 코드가 업데이트되는 것처럼 주석도 꾸준히 갱신해야 한다.

1-4 복잡한 조건식은 함수로 변경하기

복잡한 조건식을 그대로 두면 가독성이 떨어지고 의도를 파악하기 어렵다. 조건식을 별도 함수로 추출하면 함수 이름만으로 조건의 의미를 직관적으로 이해할 수 있다. 매직 넘버나 의미가 모호한 값은 상수로 선언하여 활용하면 다음과 같은 이점이 있다.

매개변수의 의미를 파악하기 쉽다.
조건문의 의도를 직관적으로 파악할 수 있다.
변수명을 통해 값의 의미를 유추할 수 있다.

// 상수 선언으로 의도를 명확하게 표현
static final int MOVE_DOWN = 1;
static final int STONE_EXIST = 1;
static final int MOVE_RIGHT = 0;

// 함수명, 매개변수, 조건식이 모두 명확해짐
static void moveUser(User user, int direction) {
    if (direction == MOVE_RIGHT) {
        // ...
    }
    if (map[next_y][next_x] == STONE_EXIST) {
        // ...
    }
}

1-5 함수는 하나의 기능만 수행하기

원칙 1: 간결하고 명확한 함수 설계하기

작은 함수 만들기: 의도적으로 여러 기능을 한 함수에 담지 않고, 중첩된 조건문이나 반복문은 가능한 한 사용하지 않는다. 로직 대신 함수를 호출해 처리하는 방식이 가독성 면에서 바람직하다.
기능이 드러나는 이름 짓기: 다른 개발자가 함수 이름을 보고 어떤 기능을 수행하는지 쉽게 짐작할 수 있어야 한다. 다소 길더라도 명확하다면 좋은 이름이다.
매개변수 최소화하기: 매개변수가 많아질수록 함수를 이해하기 어려워진다. 일반적으로 3개 이상 늘어나지 않도록 주의하고, 클래스의 멤버 변수로 대체할 수 있는지 고민해 본다.

원칙 2: 추상화 레벨을 고려한 내려 읽기 형태 만들기

추상화 레벨이란 함수가 수행하는 기능이 얼마나 구체적인지 혹은 추상적인지를 가리키는 개념이다. 함수 안에서 호출되는 함수들이 동일한 추상화 수준을 유지하도록 설계하면, 위에서 아래로 책을 읽듯 이해하기 쉬운 형태가 된다.

// 같은 추상화 레벨의 함수들을 호출
public static void createShoppingMall() {
    createUserMgmtModule();      // 고객 관리
    createProductMgmtModule();   // 상품 관리
    createDeliveryMgmtModule();  // 배송 관리
}

private static void createUserMgmtModule() {
    CreateRegisterUserFunction();  // 회원 가입
    CreateModifyUserFunction();    // 정보 수정
    CreateDeleteUserFunction();    // 탈퇴
}

원칙 3: 함수 이름과 다른 기능 수행하지 않기

함수명을 짓고 나면, 그 이름에서 예측되는 기능을 정확히 수행하고 있는지 반드시 확인해야 한다. 예를 들어 isAnswerCorrect 함수가 정답 여부 확인 외에 점수 증가 로직까지 포함하면, 함수명만으로는 추가 동작을 예측할 수 없어 협업 시 혼란을 준다.

원칙 4: 조회와 명령 분리하기

변숫값을 업데이트하는 명령 함수 내부에 조회 로직을 함께 구현하면 함수의 기능이 모호해진다. 조회와 명령을 각각 다른 함수로 분리해 역할을 명확히 구분하는 것이 좋다.

// 조회 함수와 명령 함수 분리
if (studentNameExists(students, updateStudent.getName())) {
    updateScore(students, updateStudent);
}

// 조회: 학생 존재 여부 확인
private static boolean studentNameExists(ArrayList<Student> students, String name) {
    for (int i = 0; i < students.size(); i++) {
        if (students.get(i).getName().equals(name))
            return true;
    }
    return false;
}

// 명령: 점수 업데이트
private static void updateScore(ArrayList<Student> students, Student updateStudent) {
    // 업데이트 로직
}

1-6 생성자 가독성 높이기

생성자에 매개변수가 많을수록 클라이언트 코드에서 각 매개변수가 무엇을 의미하는지 파악하기 어렵다. 이때 빌더 패턴(Builder Pattern)을 적용하면 가독성을 크게 높일 수 있다.

빌더 패턴 적용

원본 클래스 내부에 정적 클래스인 Builder를 선언한다.
Builder 클래스는 원본 클래스의 멤버 변수를 모두 가지고 있다.
각 변숫값을 저장하는 함수를 체이닝 가능하도록 구현한다. (return this)
build() 함수에서 현재 변숫값을 이용해 원본 객체를 생성하고 반환한다.

// 빌더 패턴을 사용해 원하는 속성만 자유롭게 선택해 객체 생성
Person builderPerson = new Person.Builder("쫑이")
    .age(20)
    .gender("M")
    .height(180)
    .build();

Person builderPerson2 = new Person.Builder("하루")
    .age(5)
    .build();

단, 빌더 패턴이 항상 정답은 아니다. 클래스가 단순하거나 생성자를 자주 사용하지 않는 경우, 빌더 패턴을 적용하면 오히려 코드가 더 복잡해질 수 있다.

1-7 오류 코드보다 예외 사용하기

함수의 실패 케이스를 처리할 때 오류 코드로 처리하는 방식보다 예외(Exception)를 활용하는 방식이 더 클린 코드에 가깝다.

오류 코드 vs 예외 처리

오류 코드 방식	예외 처리 방식
함수 내부 분기문으로 오류 처리	try~catch 문으로 예외 처리
'함수는 하나의 기능만 수행하자' 원칙 위반	오류 처리와 핵심 로직이 분리됨
추상화 레벨이 어긋남	추상화 레벨이 대등함
조건문 분기가 많아져 흐름 파악이 어려움	흐름이 명확해 이해하기 쉬움

예외 처리의 장점

실패 케이스 발생 시 예외를 생성해 상위 함수로 전달하거나, try~catch 문으로 처리하는 방식이 깔끔하다.
throws Exception을 사용하면 호출한 함수에서 발생한 예외를 그대로 자신을 호출한 함수로 넘겨줄 수 있다.
오류 처리 역시 하나의 기능이므로, 핵심 로직과 분리해야 함수의 단일 책임 원칙이 지켜진다.

// try~catch 문으로 예외 처리
public class Main {
    private static final Logger Logger = 
        java.util.logging.Logger.getLogger(Main.class.getName());

    public static void main(String[] args) {
        VPC vpc = new VPC();
        // ...
        try {
            vpc.deleteVPCResourceUsingException();
            vpc = null;
        } catch (Exception e) {
            Logger.log(Level.WARNING, e.getMessage());
        }
    }
}

이 글은 『Do it! 클린 프로그래밍』 책의 내용을 바탕으로 작성되었습니다.