기록창고

[코드트리] 시뮬레이션 약점 극복 학습 후기

zerossin — Mon, 15 Jun 2026 23:57:40 +0900

개요

최근 이것저것 일정이 겹치면서 정신없이 시간을 보냈다.

원래는 청약챌린지 첫 주가 끝나자마자 바로 다음 학습을 진행하려고 했는데, 생각보다 바쁜 일이 많아서 결국 조금 늦게 레슨을 시작하게 되었다.

그래도 첫 주 갭체크에서 현실을 확인한 이상 더 미루면 안 될 것 같았다.

3년 만에 돌아온, 코드트리 청약 통장 챌린지 | 코드트리

매주 학습 납입하고 7주 만기 채우면 코드트리 8월까지 무료. 매주 추첨권을 모아 맥북·에어팟·애플워치 응모까지. 신청 인원에 따라 조기마감될 수 있어요.

www.codetree.ai

이렇게 챕터를 알려준다.

그래서 이번 주에는 코드트리가 추천해 준 약점 유형 중 하나인 시뮬레이션에서 날짜와 시간 계산(Date & Time)레슨을 진행했다.

학습 구조

이번 레슨을 진행하면서 가장 먼저 느낀 점은 코드트리 커리큘럼의 구조였다.

문제만 던져주는 게 아니라 먼저 개념을 설명해 준 뒤

- 기본 문제(워밍업)
- 연습 문제(챌린지)
- 테스트 문제

순으로 난이도를 조금씩 높여간다.

또 특이한 점은, 문제를 풀기 전에 잠깐 개념을 먼저 설명해 준다는 것이었다.

이런 식이다.

이번 챕터에서는 시간 계산을 단순 시뮬레이션으로 하지 않고 특정 시점을 분 단위 숫자로 변환해서 차이를 계산하는 방식을 먼저 설명해 줬다.

02:05에서 04:01까지의 시간을 계산할 때, 125분과 241분으로 변환한 뒤 차이만 구하면 된다는 식이다.

사실 굉장히 당연한 이야기처럼 보였는데 막상 코딩테스트를 풀다 보면 문제에서 시키는 대로 구현부터 들어가는 경우가 많다. 그렇기에 "먼저 계산으로 단순화할 수 있는지 생각해 보라"는 메시지를 주는 느낌이다.

첫 번째 문제

이어서 문제풀이를 시작했다.

첫번째 문제는 2011년 11월 11일 A시 B분에서 시작하여 C시 D분까지 몇 분이 걸리는지 계산하는 문제였다.

a, b, c, d = map(int, input().split())

first = a*60+b
second = c*60+d

print(second - first)

개념 설명에서 배운 내용을 그대로 적용하면 되는 문제였다.
시와 분을 모두 분 단위로 변환한 뒤 차이를 계산하면 끝.

워밍업 문제답게 어렵지 않게 통과할 수 있었다.

두 번째 문제

다음은 2011년 m1월 d1일부터 m2월 d2일까지 며칠이 있는지 계산하는 문제였다.
추가로 시작일도 포함해서 계산해야 한다는 조건이 있었다.

m1, d1, m2, d2 = map(int, input().split())

num_of_days = [0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31]

m = 0

for i in range(m1, m2):
    m += num_of_days[i]

print(m+(d2 - d1)+1)

처음에는 날짜 계산이라고 해서 괜히 복잡하게 생각했는데 결국은 월 사이에 있는 날짜 수를 전부 더한 뒤 일(day)의 차이를 더해주면 되는 문제였다. 여기서 range를 이용해 월 사이의 날짜 수를 합산하는 방식으로 풀었다.

하지만 정답은 맞았지만 제출 후에는 "이게 가장 깔끔한 방법일까?"라는 생각도 조금 들었다. 내 답안을 평가해주는 기능이 있었으면 어땠을까 했다.

그래도 적어도 이전처럼 무작정 구현부터 들어가는 게 아니라 날짜를 숫자로 바라보려고 노력했다는 점은 긍정적이었다.

세번째 문제

첫번째 챌린지 문제이다.

2011년 11월 11일 11시 11분부터 특정 날짜와 시간까지 몇 분이 지났는지를 계산하는 문제였다.

a, b, c = map(int, input().split())

start = 11*24*60 + 11*60 + 11
end = a*24*60 + b*60 + c

result = end-start

if result < 0:
    result = -1

print(result)

이번에도 핵심은 같았다.
날짜와 시간을 전부 분으로 변환한 뒤 차이를 계산한다.

다만 처음에는 -1 처리 조건을 놓치고 계속 제출했다.

그러다 제출 결과 창에서 제공되는 테스트 케이스를 보다가 뒤늦게 발견했다.
문제를 대충 읽는 습관이 아직 남아 있다는 걸 다시 한 번 깨달은 순간이었다.

한편, 쓰면서 느낀 것인데, 제출 결과 창의 테스트 케이스를 바로 내 코드 창으로 가져올 수 있는 기능은 꽤 편리했다.

네번째 문제

두번째 챌린지 문제로, 난이도는 Hard로 적혀있었다.

특정 날짜가 월요일일 때, 다른 날짜는 무슨 요일인지 계산하는 문제였다.

m1, d1, m2, d2 = map(int, input().split())

yoil = ['Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun']

months_day = [0, 31, 28, 31, 30, 31, 30 ,31, 31, 30, 31, 30, 31]

m = 0
chai = 0
yoilindex = 0

if m1*30+d1 < m2*30+d2:
    for i in range(m1, m2):
        m += months_day[i]

    chai = m + (d2-d1)
    yoilindex = chai % 7
else:
    for i in range(m2, m1):
        m += months_day[i]
    
    chai = m + (d1-d2)
    yoilindex = -(chai % 7)

print(yoil[yoilindex])

이번 레슨에서 가장 오래 고민했던 문제다.
하지만 요일은 결국 7일마다 반복된다는 점에 주목했다.

그래서 두 날짜 사이가 며칠 차이인지 계산한 뒤,

'요일 인덱스 = 날짜 차이 % 7'

이라는 아이디어를 이용해 해결했다.

지금 다시 보면 코드가 깔끔한 편은 아니다.
앞 날짜와 뒷 날짜를 따로 처리하다 보니 분기문도 많고 중복 코드도 생겼다.

하지만 적어도 "요일은 7일 주기"라는 규칙을 먼저 발견하고 접근했다는 점에서 이전보다 사고 과정이 조금 발전한 것 같았다.

다섯 번째 문제

이번 레슨의 마지막 문제로, 테스트 문제다. 앞선 문제부터 지금까지까지 학습한 것들과 경험을 바탕으로 도전해 보는 문제인듯했다. 이렇게 보니 학습 구조가 잘 짜여졌다는 생각이 들었다.

문제는 특정 기간 동안 원하는 요일이 몇 번 등장하는지 구하는 것이였다.

m1, d1, m2, d2 = map(int, input().split())
A = input()

yoil = ['Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun']

months_day = [0, 31, 29, 31, 30, 31, 30 ,31, 31, 30, 31, 30, 31]

m = 0

for i in range(m1, m2):
    m += months_day[i]

chai = m + (d2-d1)
yoilsu = chai // 7
yoilsu_chuga = chai % 7
if yoilsu_chuga >= yoil.index(A):
    yoilsu += 1

print(yoilsu)

처음 문제를 봤을 때는 꽤 복잡해 보였다.
하지만 앞 문제에서 사용했던 요일의 주기성을 그대로 응용할 수 있었다.

요일은 7일마다 반복되기 때문에 먼저 몇 주가 지났는지를 계산하고, 남은 날짜에서 추가로 등장하는 횟수를 계산하는 방식으로 접근했다.

앞 문제들을 풀며 익힌 개념이 자연스럽게 이어지는 느낌이 들었다.

그래서 테스트 문제임에도 생각보다 수월하게 통과할 수 있었다.

느낀 점

이번 레슨은 솔직히 말해서 DP나 최단 경로처럼 어려운 알고리즘을 배우는 시간은 아니었다.
하지만 코딩테스트에서 자주 필요한 사고방식을 연습할 수 있었다.

특히 코드트리의 기본 문제 → 연습 문제 → 테스트 문제 구조가 꽤 마음에 들었다.

그저 문제를 많이 푸는 것이 아닌,
먼저 개념을 이해하고 그 개념을 여러 문제에 적용하면서,
마지막에는 응용 문제까지 연결해 보는 흐름이 자연스러웠다.

지난 갭체크 때의 나는 문제를 보자마자 구현부터 시작하는 경우가 많았다.

이번 레슨을 하면서는 "이걸 숫자로 바꾸면 더 쉬워지지 않을까?", "반복되는 규칙은 없을까?" 같은 생각을 조금씩 하게 되었다.

아직 갈 길은 멀지만, 적어도 이전보다는 문제를 바라보는 방식이 조금은 달라진 것 같다.

다음 주에도 코드트리가 추천해 준 약점 유형을 따라가면서 바닥난 코딩테스트 체력을 조금씩 끌어올려 볼 생각이다.

깃허브에 라이센스(License) 설정하기

zerossin — Wed, 2 Oct 2024 02:41:06 +0900

GitHub에 프로젝트를 올릴 때 라이센스(License)를 추가하는 것은 중요합니다. 라이센스는 다른 사람들에게 내 코드를 어떻게 사용할 수 있는지 규정해주기 때문입니다. 이번 글에서는 GitHub 저장소에 라이센스를 추가하는 방법을 간단하게 설명하겠습니다.

1. 라이센스란 무엇인가?

라이센스는 소프트웨어의 사용, 복사, 수정, 배포에 대한 권한과 제한을 명시한 법적 문서입니다. 적절한 라이센스를 설정함으로써 다른 개발자들이 코드를 어떻게 활용할 수 있는지 명확히 할 수 있습니다.

저작권 보호: 코드의 소유권을 명확히 하고 무단 사용을 방지합니다.
사용자 권한 부여: 다른 개발자들이 코드를 자유롭게 사용할 수 있도록 허용하거나 제한합니다.
기여 규칙 설정: 프로젝트에 기여하는 방법과 조건을 명시합니다.

2. 적합한 라이센스 선택하기

프로젝트의 목적과 사용 방식을 고려하여 적합한 라이센스를 선택합니다. 대표적인 오픈 소스 라이센스는 다음과 같습니다.

MIT License: 가장 간단하고 자유로운 라이센스. 상업적 사용, 수정, 배포가 가능하며 저작권 표시만 요구합니다.
Apache License 2.0: 특허 사용권을 명시적으로 포함하며, MIT보다 약간 더 복잡합니다.
GNU GPL v3: 강력한 카피레프트 라이센스로, 파생 작품도 동일한 라이센스를 사용해야 합니다.
BSD License: MIT와 유사하지만 약간의 차이가 있습니다.

참고: Choose a License 사이트를 방문하면 프로젝트에 적합한 라이센스를 선택하는 데 도움이 됩니다.

3. GitHub에서 라이센스 추가하기

GitHub에서는 저장소 생성 시 라이센스를 쉽게 추가할 수 있습니다. 이미 생성된 저장소에 라이센스를 추가하는 방법도 간단합니다.

3.1. 저장소 생성 시 라이센스 추가

GitHub에 로그인하고 새로운 저장소(new repository)를 생성합니다.
저장소 생성 페이지에서 "Initialize this repository with a README" 옵션을 선택합니다.
"Add a license" 드롭다운 메뉴에서 원하는 라이센스를 선택합니다.
"Create repository" 버튼을 클릭하여 저장소를 생성합니다.

라이센스를 선택할 수 있는 모습.

3.2. 기존 저장소에 라이센스 추가

GitHub에서 해당 저장소로 이동합니다.
"Add file" 버튼을 클릭하고 "Create new file"을 선택합니다.
파일 이름을 LICENSE로 입력합니다.
"Choose a license template" 버튼을 클릭하여 원하는 라이센스를 선택합니다.
필요에 따라 라이센스 내용을 수정한 후, "Commit new file" 버튼을 클릭하여 저장소에 추가합니다.

LICENSE 입력 시 자동으로 버튼이 생성되는 모습.

4. 확인하기

마지막으로 라이센스가 제대로 추가되었는지 확인합니다.

GitHub 저장소의 루트 디렉토리에 LICENSE 파일이 생성되었는지 확인합니다.
LICENSE 파일을 클릭하여 라이센스 내용이 올바르게 표시되는지 확인합니다.
프로젝트 페이지 상단에 라이센스 정보가 표시되는지 확인합니다.

MIT 라이센스가 적용된 모습.

리드미 파일 옆에 라이센스 메뉴가 생성된 모습.

5. 마무리

GitHub 레포지토리에 라이센스를 추가하는 것은 프로젝트의 법적 보호와 사용자 권한 명시를 위해 필수적입니다. 이번 글에서는 라이센스의 중요성부터 적합한 라이센스 선택, GitHub에 라이센스를 추가하는 방법까지 단계별로 살펴보았습니다. 라이센스는 오픈 소스 생태계를 건강하게 유지시키는 역할을 하므로 꼭 해보시길 바랍니다. 감사합니다!

Git 기록에서 특정 파일을 완벽히 삭제하는 방법: git filter-branch

zerossin — Wed, 2 Oct 2024 02:38:28 +0900

Git/Github(깃허브)를 사용하다 보면 민감한 정보나 대용량 파일을 실수로 커밋하는 경우가 있습니다. 단순히 파일을 삭제하는 것만으로는 충분하지 않은데, 그 이유는 해당 파일의 기록이 여전히 Git 히스토리에 남아 있기 때문입니다. 이를 위해 이 글에서는 git filter-branch를 사용하여 특정 파일의 모든 커밋 기록을 Git 저장소에서 완전히 제거하는 방법을 단계별로 설명해보려고 합니다.

⚠️ 주의: git filter-branch는 강력한 도구로, Git 기록을 영구적으로 변경합니다. 작업 전에 반드시 저장소를 백업하고 신중하게 진행하세요.

1. 왜 git filter-branch를 사용해야 할까?

git filter-branch는 Git 기록을 재작성하여 특정 파일이나 폴더를 완전히 제거하는 데 유용한 명령어입니다. 이 명령어를 사용하면 특정 파일과 관련된 모든 커밋을 수정하여 Git 기록에서 파일을 완전히 삭제할 수 있습니다.

기록 수정: 파일을 추가하거나 삭제한 모든 커밋을 수정하여 파일이 포함되지 않게 합니다.
완전한 삭제: 원격 저장소에도 수정된 기록을 반영하여 GitHub나 다른 플랫폼에서도 파일을 다시 확인할 수 없게 만듭니다.

참고: git filter-branch는 복잡하고 시간이 많이 소요될 수 있으며, 최신 프로젝트에서는 git filter-repo나 BFG Repo-Cleaner 같은 도구가 더 빠르고 효율적일 수 있습니다.

2. git filter-branch 사용하기

특정 파일을 Git 기록에서 완전히 제거하기 위해 git filter-branch 명령어를 사용합니다. 아래는 test.py 파일을 모든 브랜치에서 제거하는 예제입니다.

특정 파일 기록 삭제 명령어

git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch test.py' --prune-empty --tag-name-filter cat -- --all

--force: 기존의 필터링된 브랜치를 덮어씁니다.
--index-filter 'git rm --cached --ignore-unmatch test.py': 인덱스에서 파일을 삭제하고, 파일이 없을 경우에도 무시합니다.
--prune-empty: 파일 삭제 후 발생하는 빈 커밋을 자동으로 제거합니다.
--tag-name-filter cat: 태그를 수정하지 않습니다.
-- --all: 이 작업이 모든 브랜치에 적용되도록 합니다.

캐시된 파일도 함께 제거

필요 시 Git에서 캐시된 파일도 삭제합니다.

git rm --cached test.py

3. 강제 푸시로 원격 저장소에 반영하기

로컬에서 기록이 수정된 후, 원격 저장소에도 수정된 기록을 반영해야 합니다. 이를 위해 강제 푸시를 사용합니다.

git push --force --all

--force: 원격 저장소의 기존 기록을 덮어씁니다.
--all: 모든 브랜치에서 수정된 Git 기록을 원격 저장소에 강제로 푸시합니다.

⚠️ 주의: 강제 푸시는 원격 저장소의 기록을 변경하므로, 협업 중인 다른 사용자에게 영향을 줄 수 있습니다. 반드시 협업자들과 사전에 상의하세요.

4. 주의사항

혹시 모를 사항을 대비하는 작업입니다. (선택사항)

백업: Git 기록을 수정하는 작업은 되돌리기 어렵기 때문에 작업 전에 저장소를 백업하는 것이 중요합니다.
git clone --mirror https://your-repo-url.git
협업자 주의: 이 작업은 Git 기록을 수정하기 때문에, 협업자들은 로컬 저장소를 다시 동기화해야 합니다. 작업 후 협업자들에게 알려주세요.
git fetch --all git reset --hard origin/main
브라우저 캐시 확인: GitHub에서 파일이 여전히 보일 경우, 브라우저 캐시 문제일 수 있습니다. 브라우저 캐시를 지우거나 시크릿 모드에서 확인해 보세요.

5. 마무리

이렇게 git filter-branch 명령어를 살펴보았습니다. git filter-branch는 Git 기록에서 파일을 완전히 제거하는 데 유용하게 사용할 수 있지만, 아주 위험한 도구이기 때문에 혹시 모를 불상사를 막기 위해 작업 전에 반드시 백업을 하는게 좋습니다.

git filter-repo나 BFG Repo-Cleaner 같은 선택지도 있습니다. 다만 제가 사용했을 때 기록의 완전한 삭제가 안 이루어져 git filter-branch로 글을 작성하게 되었습니다. 감사합니다!

기록창고

[코드트리] 시뮬레이션 약점 극복 학습 후기

개요

학습 구조

첫 번째 문제

두 번째 문제

세번째 문제

네번째 문제

다섯 번째 문제

느낀 점

깃허브에 라이센스(License) 설정하기

목차

1. 라이센스란 무엇인가?

2. 적합한 라이센스 선택하기

3. GitHub에서 라이센스 추가하기

3.1. 저장소 생성 시 라이센스 추가

3.2. 기존 저장소에 라이센스 추가

4. 확인하기

5. 마무리

Git 기록에서 특정 파일을 완벽히 삭제하는 방법: git filter-branch

목차

1. 왜 git filter-branch를 사용해야 할까?

2. git filter-branch 사용하기

특정 파일 기록 삭제 명령어

캐시된 파일도 함께 제거

3. 강제 푸시로 원격 저장소에 반영하기

4. 주의사항

5. 마무리