미니베리

1. 도입 배경프로젝트를 진행하면서 API가 점점 많아지다 보니 이런 문제가 생겼다.API 요청/응답 형식이 매번 헷갈림프론트와 협업할 때 명세 전달이 불편함테스트를 Postman으로 계속 날리는 게 번거로움그래서 Swagger(OpenAPI)를 도입했다.2. Swagger 적용 과정이번 프로젝트에서는 아래 라이브러리를 사용했다.implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:2.3.0'설치 후 서버를 실행하면http://localhost:8080/swagger-ui/index.html 로 접속 가능하다.여기까지는 정말 쉽다.문제는 여기서부터 시작이었다.3. 가장 큰 문제: 403 에러 (Undocumented)Swagger에서 API..

1. 문제 요약https://www.acmicpc.net/problem/2164 1부터 N까지 카드가 순서대로 쌓여있다.다음 과정을 반복한다:맨 위 카드 버리기그 다음 카드 맨 아래로 이동→ 마지막에 남는 카드 번호를 구하는 문제2. 예시로 이해하기N = 6일 때123456→ 1 버림: 23456→ 2 아래로: 34562→ 3 버림: 4562→ 4 아래로: 5624→ 5 버림: 624→ 6 아래로: 246→ 2 버림: 46→ 4 아래로: 64→ 6 버림: 4 → 정답: 43. 접근 방법이 문제는 가장 아래있는 수를 제어해야 하므로 큐 문제핵심 연산앞에서 제거 → popleft()뒤에 추가 → append()→ deque 사용 필수4. 내가 작성한 코드from collections import deque..

1. 들어가며프로젝트(BenePicker)를 진행하면서 점점 느낀 문제는 "협업이 정리가 안 된다"는 것이었다.어떤 기능이 어디까지 진행됐는지 한눈에 안 보이고PR이 어떤 작업인지 파악하기 어려웠으며이슈와 PR이 연결되지 않아 흐름이 끊겼다그래서 이를 해결하기 위해Issue 템플릿 + PR 템플릿 + Closes 키워드를 도입하게 되었다.2. 문제 상황기존에는 아래와 같은 문제가 있었다. 1) PR만 보고 작업 내용을 파악하기 어려움PR 제목만 보고는 무엇을 했는지 명확하지 않음구현 범위가 어디까지인지 알기 힘듦 2) 이슈와 PR이 연결되지 않음어떤 PR이 어떤 이슈를 해결하는지 알 수 없음이슈가 계속 남아 있어 관리가 어려움 3) 협업 기준이 없음각자 다른 방식으로 PR 작성리뷰 기준이 애매해짐3. 해..

1. 문제 요약https://www.acmicpc.net/problem/2493 각 탑은 왼쪽 방향으로 신호를 보낸다.이때 자신보다 높은 탑 중에서 가장 가까운 탑이 신호를 받는다.→ 각 탑마다 “왼쪽에서 가장 가까운 높은 탑의 위치”를 구하는 문제2. 처음 접근 (완전탐색)처음에는 단순하게 생각했다.“각 탑마다 왼쪽을 쭉 탐색하면서 처음 만나는 큰 탑 찾으면 되겠네?”그래서 구현한 코드는 다음과 같다.import sysinput = sys.stdin.readlinen = int(input())top = list(map(int, input().split()))answer = [0] * nfor where in range(n - 1, -1, -1): height = top[where] for ..

1. 문제 요약https://www.acmicpc.net/problem/20166N×M 격자에서 시작8방향 이동 가능 (대각선 포함)환형 구조 (wrap-around)→ 경계 넘어가면 반대편으로 이동같은 칸 재방문 가능문자열을 만들고, 주어진 K개의 문자열에 대해 경우의 수 계산1. 처음 접근 (DFS + 문자열마다 탐색)처음에는 이렇게 풀었다:for god_like in god_likes: for 모든 시작점: DFS로 문자열 생성2. 문제점문자열마다 DFS 수행 → 중복 탐색 발생같은 경로를 계속 다시 탐색K 최대 1000 → 시간초과3. 깨달음이 문제는 이렇게 풀면 안 된다:❌ "문자열이 주어졌으니까 → 찾아야지"대신 이렇게 바꿔야 한다:✅ "만들 수 있는 문자열을 전부 만들어놓고 → 조회하자" ..

1. 문제 요약온라인 스트리밍으로 진행된 개강총회에서출석 인정 조건은 다음과 같다. 1) 입장 확인 - 시작 시간 S 이전 또는 정확히 S 시각에 채팅한 사람 2) 퇴장 확인 - 종료 시간 E 이후부터 스트리밍 종료 Q까지 채팅한 사람즉,S 이전에 채팅 + E~Q 사이에 채팅둘 다 만족하는 사람 수를 구하는 문제2. 접근 아이디어이 문제는 딱 보면 복잡해 보이지만 핵심은 단순하다.→ 사람을 두 번 필터링하면 된다. 1) 입장 체크time → 이때 채팅한 사람들을 enter 집합에 저장 2) 퇴장 체크 E 이때 채팅한 사람 중에서 이미 enter에 있었던 사람만 카운트3. 핵심 포인트 1) 입력 끝 처리이 문제는 채팅 개수가 안 주어짐해결방법:fo..

1. 문제 요약https://www.acmicpc.net/problem/16165여러 개의 아이돌 그룹이 주어진다.각 그룹에는 여러 멤버가 존재한다.이후 두 가지 질의가 주어진다.2. 질의 유형 1) 0번: 그룹 이름 → 멤버 목록 출력 (사전순) 2) 1번: 멤버 이름 → 소속 그룹 출력2. 처음 접근 (리스트 기반)처음에는 단순하게 생각해서:groups: 그룹 이름 리스트members: 각 그룹의 멤버 리스트이렇게 저장했다. groups, members = [], [[] for _ in range(n)] 그리고 질의 처리 시:그룹 찾기 → groups 순회멤버 찾기 → members 전체 순회 + in 검사이후 오답처리되어 딕셔너리 형식으로도 처리해보았다.3. 문제점(오답 코드) 1) 리스트i..

1. 문제 요약https://www.acmicpc.net/problem/13414수강신청 시스템에서 학생들이 신청을 한다.총 L명의 신청 기록이 주어짐같은 학생이 여러 번 신청할 수 있음같은 학생이 여러 번 신청하면 마지막 신청만 유효문제를 처음 보고 든 생각이 문제는 수강신청 대기 명단처럼 보였다.학생들이 순서대로 신청을 하는데, 같은 학생이 여러 번 신청할 수 있고 마지막 신청만 유효하다는 점이 핵심이었다.즉, 단순히 입력을 그대로 저장하는 문제가 아니라중복된 학번을 처리해야 하고마지막 신청 기준으로 순서를 다시 판단해야 한다는 특징이 있었다.처음에는 큐처럼 순서를 관리하면 될 것 같아서 deque를 떠올렸다.2. 처음 시도: deque로 직접 중복 제거하기처음에는 신청 순서를 그대로 넣고,이미 들어..

1. 문제 요약문자열 S가 주어지고, 여러 개의 질의가 들어온다.각 질의는 다음과 같다:alpha[l][r] 👉 구간 [l, r]에서 문자 alpha가 몇 번 등장하는지 구하기2. 처음 접근 (딕셔너리 + 완전탐색)처음에는 문자별 인덱스를 저장하고, 매 쿼리마다 직접 확인했다.panels = dict()for i, c in enumerate(s): if c not in panels: panels[c] = [i] else: panels[c].append(i)for k in panels[alpha]: if l ❌ 문제점질의마다 리스트를 순회 → 최악 O(N)시간초과 발생3. 개선 시도 (누적합 / Prefix Sum)그래서 각 알파벳별 누적합 배열을 만들었다.pa..

1. 문제 요약https://www.acmicpc.net/problem/2559연속된 K일 동안의 온도 합 중에서 최댓값을 구하는 문제다.예를 들어,3 -2 -4 -9 0 3 7 13 8 -3 이 주어졌을 때,K = 2 → 최대 합 = 21K = 5 → 최대 합 = 312. 처음 접근 (시간초과 발생)처음에는 이렇게 풀었다. for i in range(n): for di in range(1, k): pannels[i] += pannels[i+di]3. 문제점매 시작점마다 K개를 다시 더함시간복잡도: O(N × K)최악의 경우:100,000 × 100,000 → 10^10 👉 시간초과 발생4. 핵심 아이디어: 슬라이딩 윈도우이 문제의 핵심은"연속된 구간의 합을 매번 다시 구할 필요가 없다"?..