programmers-csharp-kit

Imported from ruddyscent/programmers-csharp-kit (AGENTS.md). Install upstream with npx skills add ruddyscent/programmers-csharp-kit. Copyright stays with the author.

AGENTS.md

이 파일은 이 저장소에서 프로그래머스 코딩테스트 고득점 Kit 학습자료를 만들거나 수정할 때 따르는 작업 지침입니다.

저장소 목적

이 저장소는 프로그래머스 스쿨의 코딩테스트 고득점 Kit를 C# 중심으로 학습하기 위한 풀이 노트 저장소입니다.

문제 원문을 복제해 모아 두는 저장소가 아니라, 각 문제를 이해하기 위한 핵심 아이디어, C# 풀이, 복잡도 분석, 주의점을 정리하는 학습 자료 저장소입니다.

학습자료 생성 기준

새 학습자료를 만들 때는 다음 원본 프롬프트의 의도를 따른다.

문제를 C#으로 풀려고해. 이 문제를 풀기 위한 학습자료를 생성해줘. 가능하다면 풀이 방법은 이해하기 쉬운 방법과 코드가 짧은 두 가지를 알려줘. 풀이는 프로그래머스의 코딩테스트 연습에서 실행할 수 있어야 해. LINQ를 적극적으로 사용해도 괜찮아. 풀이에는 공간, 시간 복잡도 분석도 넣어주고. 곳곳에 이모지도 넣어줘. 결과는 마크다운 파일로 내려받고 싶어.

이를 실제 작성 규칙으로 풀면 다음과 같다.

1. 문제는 C#으로 풀이한다.
2. 코드는 프로그래머스 코딩테스트 연습 환경에서 실행 가능한 형태로 작성한다.
3. 가능하면 두 가지 풀이를 제시한다.
4. 첫 번째 풀이는 이해하기 쉬운 버전으로 작성한다.
5. 두 번째 풀이는 코드가 짧고 간결한 버전으로 작성한다.
6. LINQ를 적극적으로 사용해도 된다. 단, LINQ가 오히려 코드가 길어지거나 메모리를 불필요하게 더 쓰면 반복문, 배열, 튜플, 기본 자료구조를 우선한다.
7. 각 풀이마다 시간 복잡도와 공간 복잡도를 분석한다.
8. 설명 중간중간 적절한 이모지를 사용한다.
9. 결과물은 Markdown 문서로 작성한다.

권장 파일 이름

프로그래머스 Kit 문제의 C# 학습자료는 다음 형식을 사용한다.

문제명_CSharp_학습자료.md

예시:

더_맵게_CSharp_학습자료.md
완주하지_못한_선수_CSharp_학습자료.md

공백은 _로 바꾸고, 문제명의 공식 표기를 최대한 유지한다.

권장 문서 구조

학습자료는 기존 문서의 톤과 흐름을 따른다. 보통 다음 구조를 사용한다.

# 문제명 — C# 학습자료

## 1. 문제 핵심

## 예제 이해하기

## 주의할 점

# 풀이 1. 이해하기 쉬운 방법

## 아이디어

## C# 코드

## 코드 해설

## 시간 복잡도

## 공간 복잡도

# 풀이 2. 짧은 코드 버전

## 아이디어

## C# 코드

## 시간 복잡도

## 공간 복잡도

## 정리

문제에 따라 섹션 이름은 자연스럽게 조정해도 된다. 단, 풀이 아이디어, C# 코드, 시간 복잡도, 공간 복잡도는 빠뜨리지 않는다.

풀이 2가 실제로 코드 길이가 짧은 풀이가 아니라 시간 복잡도나 표현 방식이 다른 풀이일 때는 제목을 억지로 “짧은 코드 버전”이라고 쓰지 않는다.

예시:

# 풀이 2. 빠른 버전 — Dictionary로 이름 개수 세기
# 풀이 2. 표현식 버전 — LINQ로 이웃 비교

추천 풀이 섹션에서는 학습용 추천과 코딩 테스트 제출용 추천을 구분한다. 코드 길이를 우선하는 경우, 메모리를 덜 쓰는 경우, 시간 복잡도를 더 중시하는 경우를 필요하면 짧게 나눠 설명한다.

C# 코드 작성 규칙

프로그래머스 제출 형식을 우선한다.

using System;
using System.Collections.Generic;
using System.Linq;

public class Solution
{
    public int solution(...)
    {
        ...
    }
}

문제의 반환 타입과 메서드 시그니처는 프로그래머스 문제에 맞춘다.

필요한 using만 포함한다. LINQ 사용은 허용되며, 짧은 버전에서는 적극적으로 활용해도 된다. 다만 이해하기 쉬운 버전에서는 초보자가 따라갈 수 있도록 명시적인 반복문과 자료구조를 우선 고려한다.

코딩 테스트 제출용 코드는 너무 길어지지 않게 작성한다.

다음 기준을 우선한다.

1. 사용하지 않는 using System; 같은 네임스페이스는 넣지 않는다.
2. 단일 문장 if, for, foreach, while은 기존 문서 흐름을 해치지 않는 선에서 중괄호를 생략해도 된다.
3. int left = 0, right = n - 1, answer = 0;처럼 서로 밀접한 변수는 한 줄에 묶어도 된다.
4. 단순 데이터 묶음에는 별도 클래스보다 이름 있는 튜플을 우선 고려한다.
5. int[,] 입력을 정렬해야 할 때는 int[][]보다 (start, end) 같은 튜플 배열이 더 간결하면 튜플 배열을 사용한다.
6. 큐나 스택에 여러 값을 함께 넣어야 하면 Queue<int[]>보다 Queue<(int r, int c)>, Queue<(int r, int c, int d)>처럼 튜플을 우선 고려한다.
7. HashSet, Dictionary, PriorityQueue, SortedDictionary 등 문제에 맞는 표준 자료구조를 사용해 불필요한 직접 구현을 피한다.
8. GetValueOrDefault, AddRange, RemoveRange, Array.ConvertAll처럼 코드 길이를 줄이면서 의미가 분명한 표준 메서드는 활용해도 된다.
9. 입력 배열에 직접 누적하거나 방문 표시를 해도 되는 문제라면, 별도 배열을 만들지 않는 풀이를 짧은 버전으로 제시할 수 있다. 단, 원본 입력을 변경한다는 점이 풀이 이해에 중요하면 설명에 적는다.
10. 짧게 만들기 위해 성능이 나빠지는 방식은 피한다. 예를 들어 매 반복마다 정렬하는 LINQ 풀이처럼 시간 초과 위험이 큰 코드는 “짧아 보여도 위험한 풀이”로만 언급한다.

코드 길이를 줄인 뒤에는 코드 해설도 반드시 같은 변수명과 자료구조에 맞춘다. 예전 설명의 int[], rowCount, Job 클래스 같은 표현이 튜플 기반 코드와 섞여 남지 않도록 확인한다.

설명 톤

독자가 C#과 알고리즘을 배우는 중이라고 가정한다.

문장은 짧고 명확하게 쓴다. 어려운 개념은 예시와 함께 설명한다. 코드가 왜 그렇게 움직이는지 단계별로 보여준다.

번역투 문장과 지나친 수동형은 지양한다. 사람이 직접 쓴 학습 노트처럼 자연스럽고 구체적으로 설명한다.

AI가 대량 생성한 글처럼 보이지 않도록 한다. 과한 일반론, 반복적인 문장 패턴, 빈말에 가까운 표현은 줄이고 문제 풀이에 실제로 도움이 되는 내용을 쓴다.

이모지는 학습 흐름을 가볍게 만드는 정도로 사용한다. 제목, 핵심 포인트, 주의점, 성공/실패 지점에 적당히 넣되, 코드 블록 안에는 넣지 않는다.

복잡도 분석

각 풀이마다 시간 복잡도와 공간 복잡도를 별도로 적는다.

가능하면 변수의 의미를 함께 설명한다.

예시:

N은 입력 배열의 길이입니다.

시간 복잡도: O(N log N)
정렬에 O(N log N)이 걸리고, 이후 한 번 순회하므로 전체 시간 복잡도는 O(N log N)입니다.

공간 복잡도: O(N)
정렬 결과를 새 배열로 만들거나 Dictionary에 값을 저장하므로 O(N)의 추가 공간을 사용합니다.

저작권 및 인용 주의

프로그래머스 문제 원문, 제한사항, 입출력 예, 테스트케이스 등 공식 콘텐츠의 저작권은 프로그래머스 및 각 원저작자에게 있다.

학습자료를 작성할 때 공식 문제 원문을 길게 복제하지 않는다. 문제 핵심은 직접 요약한다. 공식 링크는 꼭 필요할 때만 짧게 안내하고, 모든 문서에 반복적으로 문제 링크를 넣을 필요는 없다.

README와 LICENSE의 저작권 안내를 유지한다. 이 저장소의 라이선스는 작성자가 만든 풀이, 해설, 코드, 학습 정리에만 적용되며 프로그래머스 공식 콘텐츠에는 적용되지 않는다.

인덱스 관리

새 문제 자료를 추가하면 해당 유형 디렉터리의 index.md와 루트 README.md의 학습자료 목록도 함께 갱신한다.

현재 주요 디렉터리는 다음과 같다.

그래프/
깊이_너비_우선_탐색/
동적계획법/
스택_큐/
완전탐색/
이분탐색/
정렬/
탐욕법/
해시/
힙/

디렉터리명에는 Windows 호환성을 해칠 수 있는 : 같은 문자를 쓰지 않는다.

커밋 메시지 작성 규칙

커밋 메시지를 요청받으면 변경 내용을 짧게 요약하는 영어 메시지를 기본으로 작성한다.

형식은 다음을 우선한다.

type: concise summary

- Detail 1
- Detail 2
- Detail 3

type은 변경 성격에 맞게 고른다.

docs: 문서, 학습자료, README, AGENTS.md 변경
fix: 잘못된 코드, 설명, 복잡도, 오타 수정
refactor: 동작은 유지하면서 코드 구조나 풀이 표현 정리
chore: 저장소 관리성 변경

제목은 50자 안팎으로 간결하게 쓴다. 본문 bullet은 2~4개 정도로 유지하고, 변경 이유와 범위를 설명한다.

학습자료 수정 커밋에서는 다음 관점을 반영한다.

1. 코드 길이를 줄였는지
2. 풀이 제목이나 추천 문구를 정리했는지
3. 코드 해설을 실제 코드와 맞췄는지
4. 저작권 안내나 공식 링크 방침을 조정했는지

단일 파일의 작은 변경이면 한 줄 커밋 메시지만 제안해도 된다.