김신건의 로그

IaC 튜토리얼 (1)

koa (김신건) — Fri, 12 Jun 2026 00:00:00 GMT

IaC란?

[!NOTE] 한줄 정리 서버·네트워크·DB 같은 인프라를 사람이 손으로 클릭해 만드는 대신, 버전 관리되는 코드(설정 파일) 로 정의하고 자동으로 프로비저닝하는 방식

어떻게 만들지(절차)가 아니라 무엇을 원하는지(상태)를 적는 선언형 방식이 IaC의 주류다.

요약 정리

IaC는 인프라의 “원하는 상태(desired state)” 를 텍스트 파일로 기술하고, 도구가 그 정의대로 실제 클라우드/온프레미스 자원을 만들고 변경·삭제하도록 하는 운영 패러다임입니다.

콘솔에서 수동으로 만든 자원은 누가/언제/무엇을 바꿨는지 추적이 어렵고, 재현이 불가능합니다. IaC는 이 과정을 코드로 옮겨 Git으로 이력을 남기고, 코드 리뷰를 거치고, 동일한 정의로 몇 번이든 같은 환경을 재생산할 수 있습니다.

결과적으로 인프라가 소프트웨어 개발의 모범 사례(버전 관리·테스트·CI/CD· 리뷰)를 그대로 누리게 됩니다.

코드로 정의하면 따라오는 것들

Single Source of Truth : 실제 인프라의 구조는 코드 저장소가 말해줍니다.
리뷰 가능성: 인프라 변경이 PR로 들어와, 동료의 검토를 받습니다. (이제 AI의 작성과 리뷰도 받을 수 있습니다.)
자동화: apply 한번으로 수십 개의 자원을 일관되게 생성합니다.

IaC의 이점

이점	무엇을 해결하는가?	구체적인 효과
재현성 / 멱등성	환경 간 불일치, 재해 복구	동일 코드로 dev-alpha-production 등의 환경에 동일하게 생성 가능. 여러 번 apply해도 결과가 동일함
버전 관리	”누가 이걸 지웠는가?”	Git Diff로 변경 추적이 가능함
협업 / 리뷰	사일로화된 인프라 지식	인프라 변경이 코드 리뷰 대상이 되어 지식이 팀에 공유된다.
속도 / 자동화	느린 수동 프로피저닝	CI/CD 파이프라인에서 plan / apply를 자동 실행
일관성	휴먼 에러, Contribution Drift	클릭 실수 제거, 정책을 코드로 강제할 수 있음
문서화	오래된 위키	코드 자체가 항상 최신 인프라를 명세하는 명세서 역할을 함
비용 / 보안 가시성	유령 자원, 미흡한 점검	정적 분석 (tfsec, Checkov) 으로 배포 전에 위험, 낭비를 탐지할 수 있음

IaC에서 멱등성은 매우 중요합니다. 명령형 스크립트를 통해 인프라 생성시, 단순하게 두 번 실행하면 자원을 2개 만들어낼 수 있습니다. 선언형 IaC는 “이미 원하는 상태” 라면 아무 일도 하지 않습니다. 이 성질로 “안전하고 다시 돌릴 수 있는” 자동화를 가능하게 만들어줍니다.

명령형 vs 선언형 그리고 state에 대해

명령형(imperative)

“EC2 인스턴스를 생성하라 → 보안그룹을 붙여라 → 태그를 달아라”처럼 수행할 단계를 순서대로 기술합니다. (예: 셸 스크립트, AWS CLI 나열) 다시 실행하면 중복 생성·오류가 날 수 있어 멱등하지 않습니다.

선언형(declarative)

“t3.micro EC2가 1대, 이 보안그룹과 함께, 이 태그로 존재해야 한다”처럼 결과만 기술합니다. 도구가 현재와 비교해 필요한 동작을 스스로 도출합니다. (ex. Terraform, CloudFormation, Kubernetes manifest)

선언형 IaC 도구가 동작하는 방식

선언형 도구는 세 가지를 비교합니다.

코드에 적힌 목표 상태(desired)
도구가 기억하는 마지막 상태(state file)
클라우드의 실제 상태(real)

plan 단계에서 이 셋을 대조하여 “무엇을 만들고/바꾸고/지울지”를 실행 계획으로 보여줍니다. apply 단계에서 그 계획만큼만 실제 API를 호출합니다. 코드와 실제가 어긋나는 현상을 드리프트(drift)라 하며, 도구는 이를 감지해 다시 코드 기준으로 맞춰 줍니다. 이 “목표-현재 차이 계산” 모델이 IaC가 멱등하고 안전한 이유입니다.

CodeWithOutput 컴포넌트 데모

koa (김신건) — Tue, 26 May 2026 00:00:00 GMT

이 글은 <CodeWithOutput> 컴포넌트의 모든 표현 가능한 형태를 한 화면에서 확인하기 위한 데모입니다.  는 astro-auto-import 로 글로벌 등록되어 있어 글마다 import 문을 추가할 필요가 없습니다. 새 케이스가 추가될 때마다 이 페이지에 예시를 같이 추가하면 미리보기·실제 빌드·반응형 동작을 한 번에 점검할 수 있습니다.

1. 기본 — 코드 + 결과

가장 단순한 형태입니다. 코드 한 덩어리 + 결과 한 덩어리.

2. STDIN + STDOUT 한 쌍

input 을 함께 넘기면 결과 패널 위에 stdin 섹션이 추가됩니다.

3. 여러 테스트 케이스 (`cases`)

알고리즘 문제처럼 입력·출력 쌍이 여러 개 필요한 경우 cases 배열을 사용합니다. 모든 케이스가 한 번에 보이도록 세로로 쌓이고, 케이스 사이는 굵은 경계선으로 구분합니다. 라벨을 생략하면 예제 N 으로 자동 부여됩니다.

4. 사용자 지정 케이스 라벨

각 케이스에 label 을 명시하면 자동 번호 대신 사용자 라벨이 보입니다.

5. 다중 언어 코드 (`variants`)

같은 문제를 여러 언어로 풀이할 때 variants 로 코드 패널에 탭을 만들 수 있습니다. 오른쪽 패널의 결과는 모든 변형이 공유합니다.

6. 다중 언어 + 다중 케이스

variants 와 cases 는 함께 쓸 수 있습니다. 코드는 탭으로, 케이스는 세로 stack 으로.

7. 케이스마다 입력 유무가 섞여 있을 때

cases 안에서 어떤 케이스는 입력이 있고 어떤 케이스는 없는 경우. 각 케이스는 독립적으로 stdin 섹션을 표시/숨김.

8. 타이틀과 커스텀 라벨

title, outputLabel, 케이스별 inputLabel / outputLabel 까지 모두 지정한 풀 옵션 예시.

9. 좌우 비율 조절 (`codeWidth`)

codeWidth prop 으로 초기 좌측 코드 패널 너비를 조절할 수 있습니다 (사용자가 splitter 를 드래그하면 localStorage 에 저장됨).

10. 긴 코드 / 긴 출력 (스크롤 확인)

코드와 출력이 패널 높이를 넘으면 각 패널 내부에서 독립 스크롤됩니다.

11. 긴 한 줄 (가로 스크롤 확인)

긴 단일 라인은 패널 안에서 가로 스크롤이 동작해야 합니다.

12. 다양한 언어 하이라이팅

shiki 가 인식 가능한 언어라면 자동으로 색상이 적용됩니다.

<CodeWithOutput language=“rust” label=“Rust” outputLanguage=“text” code={fn main() {\n let v: Vec<i32> = (1..=5).collect();\n let sum: i32 = v.iter().sum();\n println!("sum = {}", sum);\n}} output={sum = 15} />

확인 포인트

좌우 splitter 드래그로 비율 조절이 동작하는가
더블클릭 시 50% 로 리셋되는가
화살표 키로 미세 조정되는가
모바일 폭 (640px 이하) 에서 splitter 가 사라지고 세로 stack 으로 전환되는가
다크/라이트 모드 전환 시 코드 색상이 따라가는가
다중 케이스에서 케이스 간 경계선이 명확한가
미리보기 (에디터) 와 실제 렌더링이 시각적으로 동일한가

[Leetcode] 192 Word Frequency

koa (김신건) — Mon, 25 May 2026 09:35:44 GMT

문제 요약 및 풀이

file.txt가 주어질 때, 각 단어의 빈도수를 계산하여 단어와 빈도수를 출력하는 한 줄짜리 [[Shell Script]]를 작성해야 한다.

이때 빈도수에 따라 내림차순으로 정렬해야 하고, 빈도수가 같은 경우는 주어지지 않는다고 가정한다.

스크립트로 작성하려면 어떻게 해야하나 고민하다가 sort + uniq -c 조합으로 단어의 빈도수를 계산 할 수 있다고 생각했고, 실행해보았다. 근데 빈도수의 오름차순으로 정렬이 되어서 sort -r 옵션을 추가해서 내림차순으로 정렬하도록 했다.

풀이 코드

[Leetcode] 195 Tenth Line

koa (김신건) — Mon, 25 May 2026 09:14:23 GMT

문제 요약 및 풀이

file.txt가 주어질 때, 정확하게 10번째 줄에 있는 텍스트를 출력하는 한 줄짜리 [[Shell Script]]를 작성해야 한다.

처음에는 head와 tail로 바로 간단하게 할 수 있을 것 같았다.

아래와 같이 10줄 미만의 입력이 주어지면 정확하게 10번째 라인이 아닌 마지막 라인을 출력하게 됨을 놓쳤다.

이를 수정하기 위해서 sed를 사용했고, 다음과 같은 풀이를 작성했다.

풀이 코드

sed -n '10p' file.txt

[Leetcode] 193 Valid Phone Numbers

koa (김신건) — Mon, 25 May 2026 08:14:00 GMT

문제 요약 및 풀이

file.txt가 주어질 때, (xxx) xxx-xxxx or xxx-xxx-xxxx 형태의 전화번호를 모두 출력하는 한 줄짜리 [[Shell Script]]를 작성해야 한다.

신경써야했던 부분은

괄호가 있는 경우와 없는 경우의 두 케이스를 구분해야 한다.
앞, 뒤에 의미없는 문자들이 들어오는 케이스가 있을 수 있다.
숫자가 아닌 문자들이 들어오는 케이스가 있을 수 있다.
각 숫자의 개수도 정확히 맞아야 한다.

풀이 코드

grep -E '(^[0-9]{3}-[0-9]{3}-[0-9]{4}$)|^(\([0-9]{3}\) [0-9]{3}-[0-9]{4}$)' file.txt

캐시 적용이 적절한 상황

koa (김신건) — Sun, 24 May 2026 09:26:00 GMT

다음과 같은 조건이라면 캐시를 적용해보자

원본 데이터 저장소에서 원하는 데이터를 찾기 위해 검색하는 시간이 오래 걸린다.
원본 데이터 저장소에서 매번 계산을 통해 데이터를 가져와야 한다.
캐시에서 데이터를 가져오는 것이 원본 데이터 저장소를 통해 요청하는 것보다 빨라야 한다.
캐시에 저장된(저장할) 데이터가 잘 변하지 않는 데이터다.
캐시에 저장된 데이터는 자주 검색되는 데이터다.

마크다운 문법 종합 테스트

koa (김신건) — Sat, 23 May 2026 00:00:00 GMT

이 글은 새 블로그에서 지원하는 마크다운 문법을 한눈에 확인하기 위한 페이지입니다.

1. 기본 텍스트 강조

굵게 · 기울임 · 굵게+기울임 · ~~취소선~~ · 인라인 코드 · 밑줄(HTML)

자동 링크: https://astro.build 일반 링크: Astro 공식 문서 위키 링크: [[Astro]] · 별칭 [[Astro|Astro JS]] · 깨진 링크 [[존재하지않는위키]]

2. 헤딩 계층

3단계 헤딩

4단계 헤딩

5단계 헤딩

6단계 헤딩

3. 인용과 콜아웃

평범한 블록 인용:

“단순함이 궁극의 정교함이다.” — 레오나르도 다 빈치

GitHub 스타일 콜아웃 (5종):

[!NOTE] 정보 — 가볍게 알아두면 좋은 부가 설명을 적습니다.

[!TIP] 팁 — 더 쉽게 일을 처리하기 위한 조언입니다.

[!IMPORTANT] 중요 — 목표 달성에 꼭 필요한 핵심 정보입니다.

[!WARNING] 경고 — 문제를 피하기 위해 즉시 주의해야 할 내용입니다.

[!CAUTION] 주의 — 특정 행동으로 인한 위험이나 부정적 결과를 알립니다.

4. 리스트

순서 없는 리스트:

첫 번째 항목
두 번째 항목
- 중첩 항목
- 다른 중첩
  - 더 깊은 중첩
세 번째 항목

순서 있는 리스트:

패키지 설치
설정 추가
빌드 확인

체크리스트 (GFM):

Astro 프로젝트 셋업
BrainDB 대체 remark 플러그인 작성
다크/라이트 모드 구현
1만 글 마이그레이션

5. 코드 블록

인라인 코드: const greeting = "안녕"

TypeScript:

interface User {
  id: string;
  name: string;
  email?: string;
}

export async function getUser(id: string): Promise<User | null> {
  const response = await fetch(`/api/users/${id}`);
  if (!response.ok) return null;
  return response.json() as Promise<User>;
}

Python:

from dataclasses import dataclass
from typing import Optional

@dataclass
class User:
    id: str
    name: str
    email: Optional[str] = None

async def get_user(id: str) -> Optional[User]:
    async with httpx.AsyncClient() as client:
        r = await client.get(f"/api/users/{id}")
        if r.status_code != 200:
            return None
        data = r.json()
        return User(**data)

Bash:

#!/usr/bin/env bash
set -euo pipefail

for file in src/content/posts/*.md; do
  echo "Processing $file"
  pnpm exec markdownlint "$file"
done

JSON + diff + plain text:

{
  "name": "shinkeonkim-log",
  "version": "0.1.0"
}

- 안녕하세요
+ 안녕하세요, 김신건입니다.

순수 텍스트 블록은 하이라이팅이 없습니다.
어떤 언어인지 명시하지 않으면 이렇게 보입니다.

6. 표

항목	설명	상태
다크/라이트 모드	localStorage + prefers-color-scheme	✅
위키링크	자체 remark 플러그인	✅
그래프 뷰	D3 force simulation	✅
통합 검색	Pagefind 빌드 후 인덱싱	✅
페이지네이션	Astro `paginate()`	✅

정렬 옵션:

왼쪽 정렬	가운데 정렬	오른쪽 정렬
left	center	right
짧은 텍스트	중간 길이 텍스트	더 긴 텍스트

7. 이미지

public/ 디렉토리에 둔 이미지 (절대 경로):

리모트 이미지:

8. 푸트노트

푸트노트도 지원합니다¹. 본문이 길어질 때 출처를 정리할 때 유용합니다².

9. 구분선과 줄바꿈

위는 구분선입니다. 줄바꿈 두 칸으로
강제 줄바꿈도 됩니다.

10. HTML 직접 삽입

마크다운 안에서 필요할 때 HTML 을 직접 쓸 수 있습니다:

접었다 펼치는 영역

이 안에 마크다운은 동작하지 않습니다 (raw HTML). 그래도 텍스트와 일반 HTML 은 잘 들어갑니다.

⌘ + K 같은 단축키 표기도 가능합니다.

11. 코드 + 실행 결과 패널 (`<CodeWithOutput>`)

좌측에 입력 코드, 우측에 그 결과를 나란히 보여주는 컴포넌트. 화면이 좁아지면 자동으로 위아래로 쌓입니다 (lg breakpoint 기준). 실제로 실행하는 게 아니라 글쓴이가 결과를 직접 적어 둡니다 — 그래서 셸, REPL, DB CLI, HTTP API 등 어떤 환경의 입출력이든 그대로 옮길 수 있습니다.

11.1 Bash

11.2 Redis CLI

11.3 PostgreSQL (psql)

11.4 HTTP — curl + JSON 응답

11.5 Python REPL

<CodeWithOutput language=“python” label=“python” outputLanguage=“text” outputLabel=”>>>” title=“dataclass 한 입” code={`from dataclasses import dataclass

@dataclass class Note: id: str body: str

n = Note(id=“2026-05-23”, body=“hello”) print(n) print(n.body.upper())} output={Note(id=‘2026-05-23’, body=‘hello’) HELLO`} />

11.6 멀티 언어 탭 — 같은 출력, 여러 구현

variants prop 에 언어별 구현을 나열하면 좌측에 탭으로 묶이고, 우측 결과는 공유됩니다. “같은 문제를 어떤 언어로도 풀 수 있다” 를 보여줄 때 유용합니다.

<CodeWithOutput outputLanguage=“text” outputLabel=“stdout” title=“피보나치 첫 10개” variants={[ { label: ‘python’, language: ‘python’, code: `def fib(n): a, b = 0, 1 out = [] for _ in range(n): out.append(a) a, b = b, a + b return out

print(fib(10)), }, { label: 'typescript', language: 'ts', code: function fib(n: number): number[] { const out: number[] = []; let [a, b] = [0, 1]; for (let i = 0; i < n; i++) { out.push(a); [a, b] = [b, a + b]; } return out; }

console.log(fib(10));, }, { label: 'rust', language: 'rust', code: fn fib(n: usize) -> Vec { let mut out = Vec::with_capacity(n); let (mut a, mut b) = (0u64, 1u64); for _ in 0..n { out.push(a); let next = a + b; a = b; b = next; } out }

fn main() { println!(”{:?}”, fib(10)); }, }, { label: 'go', language: 'go', code: package main

import “fmt”

func fib(n int) []int { out := make([]int, 0, n) a, b := 0, 1 for i := 0; i < n; i++ { out = append(out, a) a, b = b, a+b } return out }

func main() { fmt.Println(fib(10)) }, }, ]} output={[0, 1, 1, 2, 3, 5, 8, 13, 21, 34]`} />

11.7 너비 조절

codeWidth prop 으로 좌측 코드 패널 너비(%)를 정합니다. 사용자는 가운데 핸들을 드래그 (또는 화살표 키) 로 임의 조정할 수 있고, 너비가 100% 가 되면 자동으로 상하 배치로 전환됩니다. 조정값은 컴포넌트 단위로 localStorage 에 저장됩니다.

더블클릭 / Enter: 50% 로 리셋
화살표 키: 2% 씩 (Shift+화살표: 10%)
End 키: 100% (상하 배치)

<CodeWithOutput language=“bash” label=”$ bash” outputLanguage=“text” outputLabel=“stdout” title=“긴 코드 — 코드 영역 넓게 (codeWidth=75)” codeWidth={75} code={# 디스크 사용량 큰 디렉토리 상위 5개 du -h --max-depth=1 . 2>/dev/null \\ | sort -hr \\ | head -6 \\ | awk 'NR>1 {printf "%-8s %s\\n", $1, $2}'} output={189M ./dist 42M ./node_modules/.bin 12M ./node_modules/three 8.4M ./src 2.1M ./public 1.2M ./_posts} />

12. Mermaid 다이어그램

```mermaid 코드 블록은 자동으로 Mermaid 다이어그램으로 렌더링됩니다. CDN ESM 으로 lazy import 되므로 이 페이지에서만 ~수백KB 로드되고, 다른 글에는 부담이 없습니다. 다크/라이트 모드 토글 시 자동으로 다시 그려집니다.

12.1 Flowchart

flowchart LR
    A[글쓴이] -->|마크다운 작성| B(.md / .mdx)
    B --> C{remark 파이프라인}
    C -->|wikilink| D[[Wiki 페이지]]
    C -->|callout| E[Alert]
    C -->|mermaid| F[다이어그램]
    D & E & F --> G((정적 HTML))
    G -->|Pagefind 인덱싱| H[검색 가능]

12.2 Sequence — 빌드 파이프라인

sequenceDiagram
    participant Dev as 개발자
    participant CI as GitHub Actions
    participant Build as Astro Build
    participant PF as Pagefind
    participant Pages as GitHub Pages

    Dev->>CI: git push main
    CI->>Build: bun install + bun run build
    Build->>Build: remark plugins (wikilink/alert/mermaid)
    Build->>Build: Shiki + Content Layer
    Build-->>CI: dist/
    CI->>PF: index dist/**/*.html
    PF-->>CI: dist/pagefind/
    CI->>Pages: upload artifact
    Pages-->>Dev: https://shinkeonkim.com

12.3 State diagram — 사이드 드로어 상태

stateDiagram-v2
    [*] --> Closed
    Closed --> Opening: 햄버거 클릭
    Opening --> Open: transition 끝
    Open --> Closing: 백드롭/ESC/링크 클릭
    Closing --> Closed: transition 끝
    Open --> Closed: viewport >= md

12.4 ER diagram

erDiagram
    POST ||--o{ TAG_LINK : has
    TAG ||--o{ TAG_LINK : tagged
    POST {
        string slug PK
        string title
        date published_at
    }
    TAG {
        string name PK
    }
    TAG_LINK {
        string post_slug FK
        string tag_name FK
    }

18. 인터랙티브 애니메이션

본문 중간에 스튜디오 에서 만든 애니메이션을 삽입할 수 있습니다. 전체 카탈로그: /animations/ · 만들기 가이드: manual-docs/animation-studio-guide.md

18.1 HTTP 요청 / 응답

가장 기본적인 패턴 — Client 가 Server 에 요청, Server 가 응답.

{}

18.2 Redis 캐시 적중 (HIT)

캐시에 데이터가 있어 빠르게 응답하는 경우. DB 조회가 없어서 ~6ms.

{}

18.3 Redis 캐시 미스 (MISS)

캐시에 없어서 DB 까지 다녀와야 하고, 이후 캐시도 갱신해야 함. ~72ms.

{}

18.4 DB Primary-Replica 복제

쓰기는 Primary 에만, Read replica 들에는 WAL 스트림으로 비동기 복제.

{}

18.5 Load Balancer Round-Robin

요청들을 서버 풀에 순회하며 분산.

{}

18.6 TCP 3-way Handshake

SYN → SYN+ACK → ACK 로 연결 수립 (각 노드의 상태 전이 함께 표시).

{}

18.7 OAuth 2.0 Authorization Code Flow

User → App → Auth Server → token → API. 표준 OAuth 시퀀스.

{}

Astro 5의 기본 remark 설정은 remark-gfm 과 remark-smartypants 를 포함합니다. ↩
한국어 콘텐츠에서도 푸트노트 마커가 정상 동작합니다. ↩

1만 개의 글에서도 빠르게: 블로그 빌드 성능 최적화 회고

koa (김신건) — Sat, 23 May 2026 00:00:00 GMT

새 블로그를 막 띄운 다음, 곧바로 한 가지가 신경 쓰였다.

지금은 글이 몇 개뿐이지만, 1만 개로 늘어나면 빌드와 검색이 버틸까?

오래 운영할 블로그라면 답은 “버텨야 한다” 다. 마침 더미 글을 잔뜩 만들어 빌드를 돌려본 김에, 어떤 함정에 빠졌고 어떻게 빠져나왔는지 기록해 둔다.

어쩌다 1만 개를 측정하게 되었나

새 [[Astro]] 블로그에 다음 기능을 차례대로 붙였다.

마크다운 + 위키링크 + 백링크
D3 기반 [[D3|지식 그래프]]
다크/라이트 모드
[[Pagefind]] 통합 검색
paginate() 로 글/노트/위키 페이지네이션
react-force-graph-3d 로 3D 그래프 뷰

여기까지는 글이 두세 개뿐이라 모든 게 즉시 끝났다. 그래도 1만 개 시나리오에서 어떻게 되는지 보기 위해 10,000 개의 더미 마크다운을 생성하고 pnpm build 를 돌렸다.

[!WARNING] 빌드가 돌아오지 않았다. 몇 분이 지나도 끝날 기미가 안 보였다. 강제로 종료.

여기서 “그래도 1만 개면 좀 오래 걸리겠지” 하고 그냥 기다리는 건 위험하다. 정상적으로 끝날 수 없는 코드일 가능성이 더 크기 때문이다.

진단: 무엇이 폭주했는가

빌드 단계별 로그를 보니 각 글 페이지를 그릴 때마다 몇십 ms씩 추가로 시간이 늘어났다. 진짜 범인은 Backlinks.astro 였다.

---

const { slug, collection } = Astro.props;
const candidates = [slug, slug.toLowerCase()];

for (const col of ['posts', 'notes', 'wiki'] as const) {
  const entries = await getCollection(col);
  for (const entry of entries) {
    const body = entry.body ?? '';
    const re = /\[\[([^\]|#]+)(?:#[^\]|]+)?(?:\|[^\]]+)?\]\]/g;
    let m;
    while ((m = re.exec(body)) !== null) {
      const target = m[1].trim();
      if (candidates.includes(target) || candidates.includes(target.toLowerCase())) {
        matches.push({ ... });
      }
    }
  }
}
---

이 컴포넌트는 글 페이지 한 장을 그릴 때마다 모든 컬렉션의 모든 본문을 정규식으로 스캔한다.

한 페이지당 비용: O(N × 평균 본문 길이)
페이지 수: N
전체 비용: O(N²)

1만 글, 평균 본문 500자라면 어림 잡아 50억 회의 정규식 매칭. JS 정규식이 초당 1억 문자를 처리한다고 가정하면 50초가 아니라, 매 페이지가 그 비용을 통째로 다시 치르므로 누적되어 수십 분에서 시간 단위까지 늘어난다.

[!IMPORTANT] 빌드 타임에 O(N²) 가 들어와 있으면 N 이 두 자리 수일 때까지는 눈에 보이지 않는다. 100 → 1만으로 N 이 100배 커지면 작업은 1만 배가 된다. 처음부터 빌드 시점 비용은 페이지당이 아니라 프로젝트당 으로 가져가는 편이 안전하다.

설계: 콘텐츠 그래프를 한 번만 만든다

해결 방향은 단순했다.

전체 컬렉션을 딱 한 번 순회하면서 {nodes, links, backlinks, slugMap} 인덱스를 만든다.
그 인덱스를 모듈 레벨 Promise 에 캐시한다 — 모든 페이지 렌더가 같은 인덱스를 본다.
백링크는 Map 조회 한 번으로 끝낸다.

// src/lib/content-graph.ts (요약)
let cache: Promise<ContentGraph> | null = null;

export function getContentGraph(): Promise<ContentGraph> {
  if (!cache) cache = build();
  return cache;
}

async function build(): Promise<ContentGraph> {
  const [posts, notes, wiki] = await Promise.all([
    getCollection('posts', ({ data }) => !data.draft),
    getCollection('notes'),
    getCollection('wiki'),
  ]);

  const slugMap = new Map<string, ContentNode>();
  const backlinks = new Map<string, ContentNode[]>();

  for (const entry of [...posts, ...wiki, ...notes]) {
    /* 모든 별칭/제목/슬러그 → 노드 매핑 추가 */
  }

  for (const entry of [...posts, ...wiki, ...notes]) {
    /* body 한 번 스캔, 위키링크 → backlinks 에 누적 */
  }

  return { nodes, links, backlinks, slugMap };
}

그리고 백링크 컴포넌트는 이렇게 단순해진다.

---

const { slug, collection } = Astro.props;
const graph = await getContentGraph();
const matches = graph.backlinks.get(canonicalId(collection, slug)) ?? [];
---

복잡도가 O(N²) 에서 O(N) + O(1) 조회 × N 페이지 = O(N) 으로 떨어졌다.

[!TIP] Astro 의 페이지 컴포넌트는 모듈처럼 평가된다. Astro:content 의 getCollection 호출 결과도 동일 빌드 내에서는 캐시되지만, 거기서 파생된 계산은 따로 캐시되지 않는다. 위처럼 직접 만든 인덱스를 모듈 변수에 담아두면 자연스러운 메모이제이션이 된다.

그래프 페이지에도 같은 함정이 있다

src/pages/graph.astro 도 비슷한 스캔을 하지만 그쪽은 한 번만 렌더링되는 페이지라 O(N) 으로 끝났다. 다만 클라이언트에서 1만 노드를 D3 force simulation 으로 돌리면 브라우저가 사실상 멈춘다. 빌드는 살아도 사용자 경험이 죽는다.

MAX_GRAPH_NODES = 400 상한을 두고, 초과 시 연결도(degree) 상위 N 개만 그리며 안내한다.

const degree = new Map<string, number>();
for (const link of graph.links) {
  degree.set(link.source, (degree.get(link.source) ?? 0) + 1);
  degree.set(link.target, (degree.get(link.target) ?? 0) + 1);
}

const truncated = graph.nodes.length > MAX_GRAPH_NODES;
const sortedNodes = truncated
  ? [...graph.nodes]
      .sort((a, b) => (degree.get(b.id) ?? 0) - (degree.get(a.id) ?? 0))
      .slice(0, MAX_GRAPH_NODES)
  : graph.nodes;

연결이 많은 허브 노드부터 보여주는 편이 첫 인상에서 더 의미 있다. 작은 위성 노드들은 그래프에서 어차피 정보량이 적다.

측정: 10,531 페이지 / 34.57 초

수정 후 같은 시나리오로 다시 빌드.

지표	값
빌드된 페이지 수	10,531
전체 빌드 시간	34.57s
정적 페이지 생성 단계	14.31s
Pagefind 인덱싱	~10s
`dist/` 총 크기	189 MB
Pagefind 인덱스 크기	42 MB (페이지당 ~4.2 KB)
Pagefind 검색 (일반 쿼리)	< 100 ms
Pagefind 검색 (10K 매치 쿼리)	~1.2 s
그래프 페이지 SSR	< 50 ms (400 노드 상한)
페이지네이션 페이지 응답	< 10 ms

“무한정 → 35 초” 변화의 거의 전부가 백링크 인덱스를 모듈 캐시로 옮긴 것 에서 왔다.

[!NOTE] 검색 응답이 가끔 1 초가 넘는 케이스는 “성능” 처럼 더미 글 1만 개에 거의 모두 들어 있는 단어를 검색했을 때다. 1만 개 결과를 점수 매기느라 시간이 든다. 실제 운영에서는 한 쿼리가 1만 개 결과를 반환하는 일이 거의 없으므로 무시 가능한 코너 케이스.

같이 손본 자잘한 것들

Pagefind 메타데이터: 본문에만 인덱스가 잡히도록 data-pagefind-body 를 글/위키/노트 컨테이너에만 붙이고, 헤더·푸터·페이지네이션·홈·소개·그래프 페이지에는 data-pagefind-ignore="all" 을 달았다. 검색이 더 정확해지고 인덱스 크기도 줄었다.
Section 필터: data-pagefind-filter="section:posts/notes/wiki" 로 검색 UI에서 컬렉션별 필터를 쉽게 제공.
3D 그래프 lazy import: react-force-graph-3d 와 three 는 무겁다. 2D 가 기본이고, 3D 토글을 누른 순간에만 React.lazy() 로 코드를 가져온다.
GitHub 스타일 콜아웃: > [!NOTE] > [!TIP] > [!IMPORTANT] > [!WARNING] > [!CAUTION] 5종 — 지금 이 글에 시연되어 있다.
Shiki dual-theme: 같은 코드 블록이 github-light 와 github-dark 모두로 토큰화되고, CSS 변수로 테마를 갈아끼우니 다크 모드 토글이 코드 색까지 자연스럽게 따라온다.

얻은 교훈

1. 빌드 시점 비용은 프로젝트 단위 로 묶는다

페이지 컴포넌트 안에서 “전체 콘텐츠를 한 번 훑는” 코드가 보이면, 그건 거의 항상 잘못 둔 자리다. 그 페이지가 K 개 렌더되면 K 번 훑게 된다. 같은 일이라면 빌드당 한 번만 끝내고 결과를 공유해야 한다.

2. 모듈 레벨 `Promise` 는 단순하지만 강력하다

복잡한 빌드 캐시 인프라 없이도 됐다. ESM 모듈은 한 빌드 안에서 한 번만 평가되므로, 다음 한 줄이면 메모이제이션이 끝난다.

let cache: Promise<X> | null = null;
export function get() {
  if (!cache) cache = build();
  return cache;
}

추상화 단계가 적을수록 디버깅이 쉽다. [[BrainDB]] 같은 외부 도구를 쓸 수 없었던 게 오히려 단순한 해법으로 이끌었다.

3. 작은 N 으로 측정하면 함정을 못 본다

글 5 개일 때는 백링크 컴포넌트가 25 회 스캔을 했다. 눈에 띄지도 않는다. 안전하게 가려면 의도적으로 큰 N 을 만들어 한 번쯤 돌려봐야 한다. 더미 글 생성 스크립트는 30 줄 정도면 충분하다.

// scripts/generate-dummy-posts.mjs (요약)
for (let i = 0; i < COUNT; i++) {
  const rand = rng(i + 1);
  fs.writeFileSync(
    path.join(OUT_DIR, `stress-${String(i + 1).padStart(5, '0')}.md`),
    `---\ntitle: "${title}"\ndate: ${date}\n---\n\n${body}\n`,
  );
}

이 한 번의 부하 테스트가 운영 단계에서의 미래의 한 시간짜리 장애를 사전에 막아 준다.

4. 빌드를 살려도, 런타임이 살아야 한다

이번에는 그래프 페이지가 좋은 예시였다. 빌드 자체는 1만 노드를 무리 없이 직렬화하지만, 그 데이터를 받은 브라우저는 D3 force tick 첫 번째 프레임에서 죽는다. 빌드 결과를 소비하는 쪽 의 한계도 같이 봐야 한다.

5. 검색은 Pagefind 가 “그냥 동작” 한다

Pagefind 는 빌드된 HTML 을 후처리로 인덱싱한다. 1만 페이지에 대해서도 인덱스가 42 MB, 클라이언트는 청크 단위로만 받아오므로 초기 로드도 가볍다. 한국어 토크나이징도 별도 설정 없이 <html lang="ko"> 만으로 잘 동작했다.

[!CAUTION] Pagefind 인덱스는 빌드된 HTML 을 읽기 때문에 HTML 에 보이지 않는 내용은 검색되지 않는다. 백링크 같은 동적 영역이 SSR 단계에서 잘 렌더되어 있는지 확인하는 게 중요하다. 클라이언트 hydration 으로 채워지는 영역은 검색에 빠진다.

마무리

이번 라운드의 변화는 결국 한 가지 룰로 요약된다.

빌드 시점에 전체를 훑는 일은, 빌드당 한 번만 한다.

이 규칙 하나가 1만 페이지 빌드를 못 끝남 에서 35 초 안에 끝남 으로 바꿨다. 같은 규칙이 위키링크 인덱스(remark-wikilink.mjs)에도, 그래프 데이터(content-graph.ts)에도, 태그 인덱스에도 적용된다.

앞으로 콘텐츠가 늘어나면서 새로운 병목이 또 보이겠지만, 이번 회고로 일단 만 단위까지는 안심하고 글을 쌓을 수 있게 됐다. 늘 그렇듯 — 일단 기록을 하자.

2025년 회고록 - 개발자에서 학생으로 돌아가서, 2025년을 정리하며

koa (김신건) — Wed, 31 Dec 2025 04:30:00 GMT

개요

2025년… 굉장히 많은 일이 있었던 것 같습니다.

퇴사부터, 대학교 복학, 멋쟁이사자처럼과 SIPE 동아리 활동 그리고 여러 프로젝트와 자격증 취득까지 정말 다양한 활동을 했습니다.

이전에도 써왔던 회고글들처럼, 2025년 한 해 동안 있었던 일들을 회고하고자 합니다. 다만 여러 종류의 일들이 있었던지라, 카테고리별로 정리해보려 합니다.

1. 퇴사와 복학

올해 3월에 퇴사와, 대학교 복학을 같이 했습니다. 이전 글 에서 퇴사에 대한 이야기를 다루기도 했습니다.

퇴사를 하고 나서도 뭘 해야 할지 여러 고민을 했습니다. 어떤 도전들을 해야 할지, 어떤 공부들을 해야 할지에 대해서. 그래서 여러 도전적인 활동을 해보려고 했고, 더 다양한 분야의 공부도 해보려고 했습니다.

2. 동아리 활동

2.1. 멋쟁이사자처럼 국민대학교 운영진

멋쟁이사자처럼 국민대학교 동아리에서 백엔드 파트장을 맡아 1년간 활동했습니다. 그리고 올해를 마지막으로 더 이상 멋쟁이사자처럼 동아리에서 활동은 하지 않기로 했습니다.

생각해 보면, 멋쟁이사자처럼 국민대학교 동아리와의 인연이 제 커리어패스에 많은 영향을 주었던 것 같습니다.

2020년에 멋쟁이사자처럼 국민대학교 동아리에 아기사자로 참여하기 시작했습니다. 그리고 2021년, 2022년, 2024년, 2025년까지 운영진을 맡았습니다.

아기사자로 들어갔을 때는 처음으로 django 프레임워크를 접했고, 웹 개발에 대한 기초적인 지식을 쌓을 수 있었습니다. 그리고 운영진으로 활동하면서는 여러 사람들에게 저의 지식을 전파하는 경험을 했고, 누군가를 가르쳐야 한다는 생각에 더 많은 지식을 습득하려고 노력하는 과정도 있었습니다.

올해는 특히나 백엔드 파트장을 맡으면서, django와 drf에 대한 세션 커리큘럼을 구성하고, 직접 세션도 진행했습니다. 거기에 더해 마지막 활동이라고 생각했기 때문에, 프로젝트에 참여도 하고, 프로젝트를 심사하는 경험을 다 해보면서 마무리하고 싶었습니다.

그래서 대학생 참가자로, 4호선톤이라는 연합 해커톤 대회에도 참여를 했습니다. (비록 수상은 못했지만, 프로젝트 결과물은 괜찮게 나왔습니다.) 또, 교내 해커톤에서는 심사위원으로 프로젝트 심사도 하게 되었습니다.

2.2. SIPE 4기

SIPE는 제가 뭘 도전해야 할지 고민하던 시기에 알게 된 동아리입니다.

SIPE는 다른 개발자 동아리나 스터디 그룹과는 다르게, 개발자들이 모여 경험을 서로 공유하고 네트워킹을 하는 데에 중점을 둔 동아리입니다.

그래서 제가 고민하던 “새로운 도전과 다양한 경험”에 대해서, 간접적으로 다른 사람들의 경험으로 배울 수 있는 좋은 기회였습니다. 그리고 어쩌면 몇 개의 다리를 거쳐서 알아야 하는 사람들을 바로 알게 되는 좋은 기회이기도 했습니다.

거기에 더해, SIPE에서는 미션을 수행하는 활동이 있었는데, 그 중 “AI가 나를 소개해줘요” 미션과 “자라나는 새싹 키우기” 미션을 진행했습니다.

“AI가 나를 소개해줘요” 미션은 제가 AI 기술에 관심을 가지고 있었고, LLM이 마치 나처럼 나를 소개하는 경험을 해보고 싶어서 발제했습니다. 많은 사이퍼들이 관심을 가져주셨고 좋은 결과물을 낼 수 있었습니다. -> 관련 페이지

“자라나는 새싹 키우기” 미션은 개발자를 꿈꾸는 고등학생들에게 멘토링을 해주는 미션이었습니다. 이전부터 교육에 관심이 많았던 터라, 이 미션도 흥미롭게 참여했습니다. 좀더 다양한 기술을 알려주고 싶었지만, 고등학생들의 수준에 맞추다보니 기본적인 내용 위주로 알려줄 수 밖에 없었던 점이 아쉬웠습니다. 그리고 교육 분야나 기술 전파에 관심을 가지고 있는 상황이니 더욱더 교안이나 장표들을 미리 많이 준비해놓아야겠다는 생각이 들었습니다.

SIPE 5기에도 참여할까 고민하였지만, 2026년에는 졸업을 앞두고 캡스톤 프로젝트를 진행해야 하고 새로운 직장을 찾는 여정을 시작해야 해서 참여하지 않기로 했습니다. 6기에는 다시 참여할 수도 있을 것 같은데, 어떤 다양한 분들과 네트워킹을 할 수 있을지 기대가 벌써 되면서, 5기에 참여하지 못하는게 아쉽기도 합니다.

3. 대학교 3학년 생활

이번에 대학교 복학 후 공부를 하면서 세상이 많이 바뀌었다고 느꼈습니다. 19학번으로 입학핵서 학교를 다녔던 때는 AI 기술 자체가 발전되어있지 않았고 LLM도 없었으며 무조건 직접 공부하고 찾아보고 암기하는 방식이었습니다.

하지만 지금은 LLM이 있고, 다양한 AI 서비스와 도구가 있습니다. 그래서 공부하는 방식도 달라져야 한다고 생각했습니다. 제가 공부하는 방식에다가 AI 도구들을 적절히 활용하게 되었고, 이에 대한 공부 결과, 공부 방식에 대해서 정리해 보겠습니다.

3.1. 두근두근, 나의 학점은?

1학기와 2학기 모두 좋은 학점을 받았습니다.

3.2. 어떻게 공부하고 있는가? 그리고 왜 이렇게 공부해야 하는가?

우선 굿노트로 강의 내용들을 한 판에 정리했습니다. 저는 공부하는 내용이 제대로 구조화되어 있지 않으면 머릿속에 잘 들어오지 않습니다.

그래서 일부러 강의 내용을 정리할 때, 계층 구조를 나누거나 서열을 나누는 방식을 적용합니다. 그리고 연관된 개념과 상반된 개념이 한 번에 다 보이도록 합니다.

이 정리 방식은 시험을 보거나 복습을 할 때도 훨씬 도움이 됩니다. “그 개념이 어디에 있더라?” 혹은 “그건 무슨 개념이랑 연관이 있지?”라는 생각이 들면, 그 개념이 어디에 있었는지를 떠올리면서 쉽게 기억할 수 있기 때문입니다.

아래 이미지들은 제가 굿노트로 정리했던 내용들 중 일부입니다.

하나하나가 작은 그림 또는 픽셀처럼 보이지만, 각각 PPT 슬라이드 한 장이거나 강의 필기 내용을 정리한 것들입니다.

그러면 끝일까요? 아닙니다.

위의 방식은 한 번씩 개념을 정리한 것뿐이고 아직 제 머리에는 다 들어가 있지 않은 상태입니다.

여기에서 AI 도구 중 하나인 notebooklm을 활용합니다.

notebooklm은 구글에서 제공하는 LLM 기반의 도구입니다. 여기에 제가 정리해 놓은 시험 범위 .md 또는 .txt 파일을 업로드하고, 강의 교안도 같이 업로드합니다.

그러고 나서 notebooklm에서 제공하는 퀴즈 기능, 플래시카드 기능을 활용해서 무한 반복하며 복습 및 암기합니다. 만약 모르는 내용이 나오거나, 틀린 문제가 나오면, notebooklm에서 자연스럽게 해설 제공 기능을 이용하여 개념을 다시 이해할 수 있도록 했습니다.

이런 방식을 통해서, 머릿속에 구조화된 개념을 넣었고 그 개념을 복습하는 과정까지 거쳤습니다.

여기서 끝일까요? 만약 특정 강의나 특정 개념이 코드를 작성하는 것과 관련되어 있거나 설계를 해야 하는 것을 공부해야 한다면, notebooklm 만으로는 부족합니다.

그래서 저는 Claude Code, Cursor, Antigravity와 같이 IDE에서 코딩 에이전트가 동작하는 것을 프로젝트에 적용하는 것과는 또 다른 방식으로 활용해 봤습니다.

위의 이미지에서와 같이 특정 기술의 다양한 예제 혹은 어떤 프로그래밍 언어의 문법에 대한 실습 등을 프롬프트를 통해 구성하도록 했고, 결과물들을 확인하고 다르게 변주해보면서 이해하는 과정을 거쳤습니다.

4. 일정 관리

올해는 todomate라는 일정 관리 도구를 활용했습니다. 2026년까지는 그대로 쓰지 않을까 싶습니다만.. 그 이후에는 다른 도구를 쓸 수도 있겠다는 생각이 듭니다.

아무튼, 올해 2월에 친구의 추천으로 쓰기 시작했던 todomate 사용은 아주 성공적이었던 것 같습니다.

처음에는 단순히 루틴적으로 해야하는 일들만 관리하려고 사용했습니다. 예를 들어, BOJ 문제 풀이, 운동, 청소 등이요. 하지만 점점 사용하면서 그냥 무작정 떠오르는 일들도 적어두고, 장기적으로 해야하는 일들은 세세하게 쪼개서 적어두는 방식으로 활용하기에는 괜찮았습니다.

그래서 매일 아침마다 todomate를 켜서 오늘 할 일들을 확인하고, 자기 전에는 오늘 했던 일들을 다시 체크하는 방식으로 활용했습니다.

다만, 프로젝트 단위로 일을 관리해야 하거나, 팀 단위로 관리해야 하는 일이 있다면 매우 적합하지 않았습니다.

제가 해야 하는 개인 일정 관리에는 좋았지만 팀 단위의 일을 같은 곳에서 보고 싶어서 중복으로 관리하다 보니 오히려 번거로울 때도 있었습니다.
프로젝트 단위로 일을 관리하기에는 각 할 일마다의 순서나 의존성 관리를 할 수 없다 보니 계속해서 수작업으로 일의 순서를 조정해야 했습니다.

이 때문에 좀 더 좋은 일정 관리 도구를 찾으면 바로 다른 도구로 바꾸어 사용해 보면서 실험을 해보려고 합니다.

그래도 이 덕분에 올해는 일정 관리가 꽤 잘 된 한 해였던 것 같습니다. 예를 들어, 백준 스트릭 기록도 12월 31일 기준으로 729일째 이어지게 되었습니다.

5. 프로젝트

올해는 적당한 수의 프로젝트를 진행했던 것 같습니다. 다만 이 프로젝트들을 동시에 진행했던 적도 있어서 조금은 버거웠던 감도 있었습니다. 내년에는 동시에 최대 2개 정도로, 1개는 큰 볼륨의 프로젝트, 1개는 작은 볼륨의 프로젝트로 진행하는 게 좋을 것 같습니다.

5.1. 코드.kr

코드.kr 이라는 Obsidian 기반의 웹 블로그 프로젝트를 진행했습니다. 만드는 데에는 몇 시간 들지도 않았고, 점차 글들을 추가하면서 발전시켜 나가는 방식으로 진행하고 있습니다.

먼저 obsidian에서 글을 작성하고, 이 내용을 Github repo에 올립니다. 그리고 자동으로 Cloudflare Pages에서 이 Repo를 빌드하여 정적 웹사이트로 배포하는 방식입니다. 이때 Obsidian Quartz 테마를 사용했습니다.

이후에는 테마를 제 입맛에 맞게 수정하고, 디자인을 바꾸면서 더 꾸며나가려고 합니다. 그리고 글도 꾸준히 올리려고 합니다.

5.2. 깜빡이

깜빡이 프로젝트는 4호선톤에 참가하여 진행했던 프로젝트입니다. 좋은 팀원들을 만나서, 색다른 아이디어를 접할 수 있었던 경험이었습니다.

만 5~10세 아동의 집중력 향상을 목표로 하는 아동 교육 서비스이며, 게이미피케이션 요소를 도입하여 아이들이 즐겁게 게임을 하면서도 집중력을 기르고, 그 결과에 대한 리포트를 부모님께 제공하는 서비스입니다.

저는 인프라 및 백엔드 개발을 담당해서 진행했습니다.

처음에는 홈랩에 있는 K8s 클러스터를 통해 배포하였지만, 나중에는 AWS로 이전하여 배포했습니다. (개발 과정 중에 한번 홈랩 k8s 클러스터가 돌아가는 미니 PC가 전원이 꺼지는 등의 이슈가 있었고 해커톤 진행 중에 서비스가 다운되면 복구하기가 어렵기 때문에 이런 결정을 했습니다.)

인프라 구성은 이곳에서 다루고 있습니다.

그리고 백엔드는 django, drf, postgresql, redis, celery를 활용하여 개발했습니다. 제가 굉장히 애용하는 기술 스택이을 거의 그대로 활용했고 개발의 속도를 빠르게 낼 수 있었습니다.

이 프로젝트를 진행하면서 가장 신경 쓴 점은 PDF 리포트 생성 및 메일 발송 부분이었습니다.

PDF로 변환해야 하는 리포트 페이지는 프론트엔드에서 구현되어있고, 이 페이지는 사용자 로그인 후 접근해야 하는 페이지였습니다. 그래서 단순히 해당 페이지의 HTML을 가져오거나, URL에 접근하는 방식으로는 PDF를 생성할 수 없었습니다.

단순하게 제가 떠올린 해결책은 일회용 토큰이었습니다. 백엔드에서 PDF 생성 과정 중에 일회용 토큰을 발급하고 첨부하여 해당 페이지에 접근하게 했습니다. 프론트엔드 로직에서는 해당 토큰을 Header에 담아 백엔드 API에 요청을 보내면 이를 통해 User 인증을 처리했고, 인증이 완료된 상황에서 페이지를 렌더링 하여 PDF로 변환하는 방식을 적용했습니다. (약간 회사에서 경험했던 내용을 간단하게 해커톤 프로젝트에 적용해본 셈이었는데, 나름 잘 동작해서 다행이었습니다.)

이 과정에서 celery를 활용하여 비동기적으로 PDF 생성 작업을 처리했고, PDF를 첨부하여 메일을 발송했습니다.

이 프로젝트에 대한 자세한 내용은 이곳에서 확인할 수 있습니다.

5.3. Athena 프로젝트

Athena 프로젝트는 1학기에 수강한 웹서버컴퓨팅 과목의 AD 과제 겸 SIPE 미션에서 AI를 활용하는 프로젝트로 진행했습니다. 저 혼자 프로젝트 설계와 개발을 모두 진행했습니다.

이 프로젝트는 알고리즘 문제 풀이를 도와주는 AI 기반의 웹 서비스입니다. 백준 온라인 저지 문제를 기반으로 사용자가 코드를 제출하면, 먼저 코드를 실행하고 테스트케이스를 통과하는지 확인합니다. 만약 테스트케이스를 통과하지 못한다면 반례를 찾아냅니다. 반례가 없었다면 AI 모델을 활용하여 코드의 문제점을 분석하고 사용자에게 피드백을 제공합니다.

사용자는 계속해서 피드백을 적용하면서 코드를 개선할 수 있게 됩니다. 이 과정에서 반례 데이터나 피드백 데이터가 계속 수집되게 되고, 이를 통해 AI 모델이 점점 더 정확한 피드백을 제공할 수 있도록 합니다.

이 프로젝트에서는 docker-compose와 Docker를 기반으로 로컬에서 동작하는 환경까지만 구축했습니다. 이후에는 k8s 클러스터에서 동작하는 과정으로 확장할 수도 있지만, 마이크로서비스에 대해서 좀 더 경험을 쌓으면서 진행하는 게 좋을 것 같아서 일단은 여기서 마무리했습니다.

이 프로젝트는 아래와 같이 여러 개의 서비스들로 나누어 구성되어 있습니다.

웹앱은 django의 MTV 패턴을 그대로 사용하여 구성했습니다. 코드 실행은 Rust로 작성된 code-executor 서비스에서 처리했습니다. 그리고 이 서비스를 활용하여 코드 채점을 처리하는 code-judger 서비스를 구성했으며, 테스트케이스 생성을 위해 LLM 서비스와 채점 기능을 활용하는 code-testcase-generator 서비스를 구성했습니다. 그리고 이 모든 서비스들은 Docker container로 구성되었고, grpc를 통해 서로 통신하도록 설계했습니다.

완성도가 높지 않았다고 생각했고 실제로 서비스가 운영되기에는 어려운 점이 있었던 것 같습니다. 그래도 국민대학교 2025학년도 1학기 소프트웨어융합대학 크리에이터 경진대회에서 1등을 수상하는 성과를 거두기도 하면서 나름 의미 있는 프로젝트였던 것 같습니다. 그리고 혼자서 진행한 프로젝트였지만, 여러모로 배운 점도 많았기에 재미있게 진행했던 것 같습니다.

5.4. Palette

Palette 프로젝트는 사주 기반의 소개팅 서비스입니다. 아직 실제 사용자에게 배포가 되지는 않았습니다.

이 프로젝트에서는 실제 사용자들의 사주 데이터를 기반으로, 사주 궁합이 좋은 사람에 대해 매칭을 해주는 기능을 제공하고 있고, LLM을 활용하여 사주 궁합을 설명해 주는 기능도 제공합니다.

PASS 인증이나 토스 페이먼츠 등을 활용해서 인증 및 결제 기능까지 구현해 두었고, k8s 클러스터 배포 및 CI/CD 파이프라인도 구축했습니다. 이후에 실제 사용자가 사용하고 여러 피드백과 이슈를 처리하면서 내용을 정리하여 다시 글을 작성해 보겠습니다.

6. 자격증

올해도 마찬가지로 자격증 시험들을 치렀습니다.

정보처리기사, ADsP, 제한무선통신사, PCCP, 운전면허를 취득했습니다. 그리고 리눅스마스터 필기시험도 통과했지만, 실기 시험은 미루다가 결국 2026년으로 넘어가게 되었습니다.

정보처리기사 : 미루고 미루다가 무난하게 합격했습니다. 공부 기간이 그렇게 길지는 않았고 전공 개념을 복습하는 느낌으로 공부했습니다.
ADsP : 데이터 분석에 대한 기초적인 개념들을 공부했습니다. 실제 업무를 진행하는 과정에서 데이터 분석 업무를 진행하시는 분들과 협업하거나 소통할 때 도움이 되지 않을까 싶어서 취득했습니다. 이후에 인공지능 공부나 데이터 용어를 접하면서 도움이 되었습니다.
제한무선통신사 : 군대에서 무선 통신을 옆에서 지켜보면서 관심을 가지게 되어 취득하게 되었습니다. 단순히 기초 개념 강의를 듣고 간단한 문제 풀이로 취득할 수 있는 자격증이었습니다. 이후에 아마추어무선기사 자격증 쪽으로도 도전해 볼까 생각 중입니다. 취미로도 괜찮을 것 같고, 무선 통신에 대한 이해도를 높이는 데에도 도움이 될 것 같습니다.
PCCP : 국민대학교 내에서 해당 자격증의 점수가 필요한 경우가 있어서 취득하게 되었습니다. 코딩테스트는 평소에 미리 계속 연습해 오던 터라, Lv4로 무난하게 취득했습니다. 시간 관리를 신경 쓰면서 풀었으면 Lv5도 가능했을 것 같다는 생각이 듭니다.
운전면허: 너무 오랫동안 미루다가 취득하게 되었습니다. 1종 보통 면허를 취득했고, 클러치 조작이 처음에 너무 어려웠는데, 연습하다 보니 금방 적응했던 것 같습니다. 하지만 자동 차량을 운전할 것 같고.. 장롱면허가 될 것 같기도 합니다.

결론

올해는 많은 사건, 사고가 있었습니다. 그 속에서 다양한 경험을 했고, 많은 사람을 만났습니다. 그리고 개발자로서의 커리어를 쌓다가 학생으로 돌아가서 다시 공부에 전념하기도 했습니다.

내년에는 진짜 졸업을 앞두고 있습니다. 캡스톤 프로젝트를 진행해야 하고, 새로운 직장을 찾아야 합니다. 그래서 2026년에는 좀 더 집중해서 공부하고, 준비를 해야 할 것 같습니다.

Java / Spring 공부, Golang, Django와 Rails 근본 파헤치기, 캡스톤 프로젝트 등등. 할 게 많이 떠오릅니다. 어찌 되었든 2026년에도 열심히 달려보려고 합니다.

모두 좋은 한 해를 보내셨길 바라며, 그리고 2026년에도 좋은 일들만 가득하시길 바랍니다.

저의 넋두리같은 글을 읽어주셔서 감사합니다!

Atcoder Beginner Contest 399 후기

koa (김신건) — Sun, 30 Mar 2025 10:00:00 GMT

개요

대회 링크

어제 (03/29) 저녁 9시부터 10시 40분까지 진행된 [[Atcoder]] Beginner Contest 399 후기입니다.

총 7문제 중 4문제를 풀었습니다.

A번부터 D번까지 풀이하는데 19분을 소모했습니다. 이후 E번과 F번을 풀기 위해서 대회 종료시각까지 트라이를 했지만 풀이하지 못했습니다. rating이 떨어지나 걱정했지만, 다행히도 rating이 약간 올라서 안심했습니다.

공식 에디토리얼 (해설)

풀이

해설은 꼭 문제를 한번 읽고 확인해주세요.

A - Hamming Distance

문제 내용

두 문자열이 주어진다.

두 문자열의 해밍 거리 (서로 다른 문자의 개수)를 구하면 된다.

풀이

문자열을 순회하면서 서로 다른 문자의 개수를 구하면 됩니다.

B - Ranking with Ties

문제 내용

N 개의 score가 주어집니다.

각 score마다 RANK() 를 구하면 됩니다. (sql의 RANK()와 같이)

풀이

정렬을 사용하거나, map을 사용하거나 기타 등등 RANK()를 구현하기만 하면 됩니다.

C - Make it Forest

문제 내용

무향 그래프 F가 주어집니다.

간선을 지워 cycle이 없는 그래프가 만드려고 합니다. 이때, 지워야 하는 간선의 최소 개수를 구해야 합니다.

풀이

처음에 이렇게 풀어도 되는건가? 좀 헷갈렸다. 몇 가지 그래프를 그리다보니 확신을 하게 되었고, 아래와 같이 구성을 했다.

1 ~ N 까지 정점을 탐색하는데, 각 정점이 방문되지 않은 경우 DFS 탐색을 한다.
그리고, 만약 이전에 방문했음에도 다시 방문하게 되면 카운팅한다. 

단, 부모로 다시 탐색을 하러 돌아가는 경우는 배제해야 한다.

D - Bonfire

문제 내용

같은 숫자임에도 서로 인접하지 않은 두 숫자를 고른다.
두 숫자의 위치를 서로 바꾸어봤을 때, 각 숫자가 인접하게 된다면 카운팅한다.

풀이

솔직히 이 문제가 D번이 맞나? 싶었다. 생각보다 너무 쉽게 풀리는 문제였다.

그냥 각 숫자마다 위치 2개를 따로 hash 또는 배열에 저장해둔다.

그리고 앞에서부터 순회하면서 인접한 두 숫자에 대해서 저장해둔 위치로 조건을 판단해보면 된다.

E - Replace

문제 내용

문자열 S와 T가 주어진다.

문자열 S를 T로 바꾸길 원한다.

다만, 문자열 S에 존재하는 임의의 문자를 모두 하나의 문자로 바꾸는 연산만 가능한 상황이다.

이때, S를 T로 바꾸는 것이 가능한지, 가능하다면 최소 연산의 수가 어떻게 되는지 구해야 한다.

풀이

결국 풀이하지 못한 채로 대회가 종료되었다.

내 접근은 S->T로 가기 위한 과정을 유향 그래프화 시키는 것이었다. 만약 ab -> cb 라면 a -> c 라는 간선을 추가하는 것처럼 말이다.

이 과정에서 cycle이 없다면 간선의 수가 답이었고, cycle이 있다면 cycle로 변하는 과정에서 임의의 temp 문자로 변환되었다가 맨마지막에 변환되는 식이 되지 않을까 해서 간선의 수 + 1 을 더하는 방식이었다.

다만 이 과정을 구하는게 까다로웠고, 현재 temp 문자로 사용할 수 있는 문자가 있는지 등을 체크하기 위해 SCC와 위상정렬을 막 적용하다가 시간이 끝났다…

결론

7문제 중 4문제를 풀이하고 끝나서 굉장히 찝찝한 contest였다. 트리나 그래프 문제가 나오면 아직도 망설임이 좀 있는 것 같다. 관련 문제와 아이디어들을 좀 더 접할 필요가 있는 것 같다.

Atcoder Beginner Contest 398 후기

koa (김신건) — Sun, 23 Mar 2025 02:20:00 GMT

개요

대회 링크

어제 (03/22) 저녁 9시부터 10시 40분까지 진행된 [[Atcoder]] Beginner Contest 398 후기입니다.

총 7문제 중 6문제를 풀었습니다.

A번부터 D번까지 풀이하는데 20분을 소모했고, E번이 interactive 문제였고, 아이디어가 떠오르지 않아 F번 먼저 풀이하였고 이때 20분 정도 시간이 걸렸습니다. 그 이후, E번 풀이를 떠올리고 풀이하는데 25분 가량 걸렸습니다. 그리고도 시간이 남아서 G번을 확인하였습니다. 다만, 이때까지도 모든 문제를 풀이한 사람이 없던 상황이었고, G번의 난이도가 쉽지 않다는 것을 알게 되었습니다. 여러 접근을 했지만 풀이를 알아내지 못하고 대회가 종료되었습니다.

공식 에디토리얼 (해설)

풀이

해설은 꼭 문제를 한번 읽고 확인해주세요.

A - Doors in the Center

문제 내용

- 와 = 로 구성된 팰린드롬 문자열을 만드는 문제이다.

풀이

주어지는 N이 홀수인지, 짝수인지에 따라 문자열을 구성하면 된다.

B - Full House 3

문제 내용

7개의 숫자가 주어진다. 이 숫자를 조합하여 풀하우스를 만들 수 있는지 구하면 된다.

풀이

서로 다른 숫자 a, b에 대해, a의 개수는 3개 이상, b의 개수는 2개 이상인지 검사하면 된다.ㄴ

C - Uniqueness

문제 내용

1 ~ N 번 사람이 각자 숫자를 가지고 있다.

다른 사람들이 가지고 있지 않는 사람들 중에, 가지고 있는 숫자가 가장 큰 사람의 번호를 반환해야 한다.

풀이

솔직히 지문을 읽고, 뭔 이상한 소리인가 싶었고, 예제 또한 이상하게 주어져있어서 조금 당황했다. discussion에서 다른 사람들도 헷갈릴 여지가 있었던 것으로 보인다.

위에 문제 내용을 그대로 구현하면 된다.

D - Bonfire

문제 내용

모닥불에서 연기가 생성된다.
각 시간(틱)마다 바람이 분다. 이때 특정 (R, C)에 있는 사람에게 연기가 닿았는지 확인하여 모든 시간마다의 결과를 출력한다.

풀이

원래라면 모닥불로 하여금 생긴 연기를 계속 움직여가며 판단할 수 있다. 하지만 연기의 최대 개수가 200,000 개 이기 때문에 N^2이 되는 순간 해결할 수가 없다. 그래서 문제를 보자마자 바로 구현하기 시작한건 연기를 고정시키고 모닥불(0, 0)과 사람 (R, C)을 계속 이동시키자였다.

아래와 같이 구현했다. 다만 좌표를 저장할때 특정 int value로 담아두고 싶어서 좌표를 변환하여 했다. 지금 생각해보면 그냥 tuple로 저장해도 되었을 텐데라는 아쉬움이 남는다.

DIFF = 400000
K = 10000000

def to_axis(y, x):
  return y * K + x

def solve():
  n, r, c = mii()
  s = inp()

  maker = [DIFF, DIFF]
  dy = { 'N': 1, 'S': -1, 'W': 0, 'E': 0 }

  dx = { 'N': 0, 'S': 0, 'W': 1, 'E': -1 }
  r += DIFF
  c += DIFF

  smokes = {}

  ans = ""

  for i in range(n):
    direction = s[i]

    axis = to_axis(*maker)
    smokes[axis] = True
    maker[0] += dy[direction]
    maker[1] += dx[direction]

    r += dy[direction]
    c += dx[direction]

    if smokes.get(to_axis(r, c), False):
      ans += "1"
    else:
      ans += "0"

  print(ans)

E - Tree Game

문제 내용

트리가 주어진다. 이때 트리에 간선을 추가하는 액션을 각 턴마다 진행한다.
단, 간선을 추가함으로서 홀수개의 노드로 구성된 cycle이 생기면 안된다.
더이상 추가할 수 있는 간선이 없는 경우 패배한다.

상대와 게임을 진행함에 있어서, 선공/후공을 정하여 승리해야 한다.

풀이

처음에는 인터랙티브 문제이기도 하고 풀이가 잘 떠오르지 않았다. 그러던 중 예시를 여러 개 만들어보다가 떠오른 생각이 있었다.

처음에 주어지는 트리 상에서, 서로의 거리가 홀수로 떨어져 있는 경우면서 바로 이어지지 않은 경우가 결국 간선을 만들어낼 수 있는 경우 아닌가?

정점의 개수 N이 최대 100까지였기 때문에 구현을 빠르고 쉽게하기 위해, 플로이드-와샬로 미리 거리를 구했고, 서로의 거리가 홀수로 떨어져 있는 경우면서 바로 이어지지 않은 경우 == ar[x][y] % 2 == 1 && ar[x][y] > 1에 대한 간선을 미리 구해두었다.

그래서 이 간선들을 토대로 내 턴에는 아무거나 출력하고, 상대 턴에는 주어지는 간선을 제거하면서 처리해봤다.

ll ar[110][110];

void solve() {
  ll N;

  cin >> N;

  for(int i = 0; i <= N; i++) {
    for(int j = 0; j <= N; j++) {
      ar[i][j] = INF;
    }
    ar[i][i] = 0;
  }

  for(int i = 1; i < N; i++) {
    int a, b;
    cin >> a >> b;

    ar[a][b] = 1;
    ar[b][a] = 1;
  }

  for(int z = 1; z <= N; z++) {
    for(int x = 1; x <= N; x++) {
      for(int y = 1; y <= N; y++) {
        if(ar[x][y] > ar[x][z] + ar[z][y]) {
          ar[x][y] = ar[x][z] + ar[z][y];
        }
      }
    }
  }

  vector <pii> ans_list;
  for(int x = 1; x <= N; x++) {
    for(int y = x + 1; y <= N; y++) {
      if(ar[x][y] % 2 == 1 && ar[x][y] > 1) ans_list.push_back({ x, y });
    }
  }

  if(ans_list.size() % 2 == 0) {
    cout << "Second" << endl;
  } else {
    cout << "First" << endl;

    cout << ans_list[0].first << " " << ans_list[0].second << endl;
    ans_list.erase(ans_list.begin());
  }

  while(1) {
    int a, b;

    cin >> a >> b;

    if(a == -1 && b == -1) return;

    if (a > b) {
      swap(a, b);
    }

    for(int i = 0; i < ans_list.size(); i++) {
      pii current = ans_list[i];

      if(current.first == a && current.second == b) {
        ans_list.erase(ans_list.begin() + i);
        break;
      }
    }

    cout << ans_list[0].first << " " << ans_list[0].second << endl;
    ans_list.erase(ans_list.begin());
  }
}

F - ABCBA

문제 내용

문자열 S가 주어졌을 때, 문자열 S를 prefix로 하는 팰린드롬을 만들어야 한다.

풀이

보자마자 manacher 알고리즘이 떠올랐다. manacher 알고리즘은 특정 위치를 중심으로 팰린드롬의 길이를 구할 수 있는 알고리즘이다. 만약 이렇게 어떤 위치에서 구한 팰린드롬이 문자열 끝까지 도달할 수 있다면, 문제에서 원하는 문자열 S를 prefix로 하는 팰린드롬을 만들 수 있는 상황일 것이다. 따라서 앞에서부터 순차적으로 확인하다가 해당 경우인경우 바로 출력하게 했다.

단, 이때 홀수 길이의 팰린드롬과 짝수 길이의 팰린드롬인지에 따라 약간의 구현 처리가 필요하다.

아래 코드는 manacher 알고리즘의 일부 구현 내용을 생략하여 문제에 맞게 활용한 코드이다.

vector<int> manacher(string& s){
    int n = s.size(), R = -1, p = -1;
    vector<int> A(n);
    for(int i=0; i<n; i++){
        if(i <= R) A[i] = min(A[2*p-i], R-i);
        while(i-A[i]-1 >= 0 && i+A[i]+1 < n && s[i-A[i]-1] == s[i+A[i]+1]) A[i]++;
        if(i+A[i] > R) R = i+A[i], p = i;
    }
    return A;
}

string space(string& s){
    string t;
    for(char c: s) t+= c, t+= ' ';
    t.pop_back();
    return t;
}

void solve() {
  string s, o;

  cin >> s;
  o = s;

  int n = s.length();
  s = space(s);
  vector <int> ret_1 = manacher(s);

  int k = ret_1.size();
  int ans = ret_1.size() - 1;

  for(int i = 0; i < k; i++) {
    if (i + ret_1[i] == k - 1) {
      ans = i;
      break;
    }
  }

  if(ans % 2 == 0) {
    int org_idx = ans / 2;

    for(int i = 0; i <= org_idx; i++) {
      cout << o[i];
    }
    for(int i = org_idx - 1; i >= 0; i--) {
      cout << o[i];
    }
  } else {
    int org_idx = ans / 2;
    
    for(int i = 0; i <= org_idx; i++) {
      cout << o[i];
    }
    for(int i = org_idx; i >= 0; i--) {
      cout << o[i];
    }
  }
}

G - Not Only Tree Game

문제 내용

E번에서 주어지는 문제 조건과 유사하다.
단, 해당 문제에서는 트리가 아닌 그래프가 주어진다.
심지어 서로 연결되어 있지 않는 경우도 존재한다.

이때 2명의 플레이어가 게임을 진행한다고 했을 때 어떤 플레이어가 이기는지 출력해야 한다.

풀이

풀이가 전혀 떠오르지 않았다. 에디토리얼은 여기 있다.

결론

그래도 7문제중 6문제를 무난하게 풀이한 contest 였다. 오랫동안 굳었던 머리가 다시 풀리는 느낌이라 좋았던 대회지만, 대회 자체의 문제 난이도와 배치는 조금 이상했던 것 같다.

Atcoder Beginner Contest 396 후기

koa (김신건) — Sun, 09 Mar 2025 09:20:00 GMT

개요

대회 링크

어제 (03/08) 저녁 9시부터 10시 40분까지 진행된 [[Atcoder]] Beginner Contest 396 후기입니다.

총 7문제 중 5문제를 풀었습니다. A ~ D번까지 문제를 보자마자 바로 풀이하였고, 21분 소요했습니다. 여전히 구현이 느립니다. 더 땡겨야 합니다. E번 문제를 대강 풀이하고 제출했는데, 최적화된 해답을 출력하지 않았고, 이를 해결하는데 시간을 오래 사용했습니다. 마지막 제출을 대회 종료 5초전에 했고, 대회가 종료된 후 AC를 확인했습니다.

공식 에디토리얼 (해설)

풀이

해설은 꼭 문제를 한번 읽고 확인해주세요.

A - Triple Four

3번 연속된 숫자가 있는 경우, Yes 아니면 No를 출력한다.

문제에 주어지는대로 바로 구현하면 됩니다.

B - Card Pile

스택에 카드를 넣는 연산과 맨 위의 카드를 확인한 후, 빼는 연산 구현

문제에서 주어지는대로 스택을 사용하면 됩니다. 단, 100개의 0을 이미 넣어놓은채 시작하는 전제조건을 확인해야 합니다.

C - Buy Balls

검정색 공들과 흰색 공들이 숫자가 적혀진 채로 주어진다.

각 공을 고르고, 고른 공의 숫자들을 합쳤을 때 최대가 되도록 해야 한다. 단, 고른 검정색 공의 수가 흰색 공의 수보다 크거나 같아야 한다.

아래와 같이 그리디하게 최대한 검정, 흰색을 동시에 선택하다가, 흰색공을 선택하지 않아도 되는 경우에는 검정색만 고르도록 했다.

def solve():
  B = sorted(B, reverse=True)
  W = sorted(W, reverse=True)

  s = 0
  for i in range(min(n, m)):
    if B[i] + W[i] > 0 and W[i] > 0:
      s += B[i] + W[i]
    elif B[i] > 0:
      s += B[i]
  
  for i in range(min(n, m), n):
    if B[i] > 0:
      s += B[i]
  
  return s

D - Minimum XOR Path

그래프가 주어진다. 그래프의 간선에 가중치가 주어진다.

다만, 해당 가중치를 더하는 연산이 아닌, XOR 연산을 수행했을 때, 1 ~ N 까지 단순 경로로 도달했을 때 최소 값을 구하라

N이 크지 않게 주어졌다. DFS로 모든 단순 경로를 탐색하도록 했다. 아래에 일부 코드를 적어두었다.

n = m = 0
edges = []
mn = []
chk = []

def dfs(node, label):
  global n, m, edges, mn, chk

  if chk[node]:
    return
  
  chk[node] = True
  mn[node] = min(mn[node], label)

  for edge in edges[node]:
    dfs(edge[0], label ^ edge[1])
  
  chk[node] = False


def solve():
  global n, m, edges, mn, chk

  dfs(1, 0)
  print(mn[n])

E - Min of Restricted Sum

문제가 복잡하게 주어졌지만, 요약하자면 다음과 같다.

노드 번호1, 노드번호2, 두 노드 사이의 가중치가 나열된다.

각 노드마다의 값을 구해야 한다. 이때 각 노드 사이의 값 끼리 XOR연산을 했을 때 주어지는 가중치와 동일하도록 해야 한다.

문제를 보다보니, XOR 연산의 특성을 고민해보다 결국 시작 노드에서 아무 값으로 시작해도 그래프가 정상적으로 주어졌다면 어떻게든 값이 나온다는 사실을 알았다. 그래서 무작정 각 노드마다 탐색을 해서, 탐색이 되지 않은 경우 0으로 시작해서 그래프를 탐색하도록 했다.

하지만, 이는 틀린 답이었고, 이유를 찾지 못하다가 뒤늦게 문제 상 주어진 조건을 놓쳤음을 알게 되었다.

If there are multiple good sequences with the same minimum sum, printing any of them is accepted.

그럼 최소를 어떻게 찾아야할까를 계속 고민하다가, 각 그래프 탐색을 하면서 탐색이 된 노드들을 그룹지어놓고, 각 그룹마다 1, 2, 4, 8, 16, … 를 모든 노드값에 XOR 연산을 하면서 최소값이 된 경우 갱신을 하는식으로 구현을 추가했다.

해당 구현을 하다가 조금 구현 실수를 하면서 WA를 계속 맞았지만, 대회 종료 직전에 제출한 코드가 AC를 받으면서 종료되었다.

결론

이번에는 E번 문제를 좀 쉽게 접근하고나서, 더 생각이 떠오르지 않아 망설임이 많았습니다. XOR 연산에 대해서 좀더 잘 알게 된 competition이었던 것 같습니다.

Atcoder Beginner Contest 395 후기

koa (김신건) — Sun, 02 Mar 2025 02:50:00 GMT

개요

대회 링크

어제 (03/01) 저녁 9시부터 10시 40분까지 진행된 [[Atcoder]] Beginner Contest 395 후기입니다.

총 7문제 중 5문제를 풀었습니다. A ~ E번까지 문제를 보자마자 해답은 바로 떠올랐지만, 코드를 작성하는 시간이 오래 걸렸습니다. F번, G번 문제를 읽고나서 도저히 바로 해답이 안떠올라서 대회를 그대로 종료했습니다.

공식 에디토리얼 (해설)

풀이

해설은 꼭 문제를 한번 읽고 확인해주세요.

A - Strictly Increasing?

N 개의 숫자가 주어집니다.
N 개의 숫자들이 엄밀하게 증가하는 수열로 주어졌는지 판단하면 됩니다.

그냥 구현하면 됩니다.

B - Make Target

자연수 N이 주어집니다.

문제 규칙에 맞게 `#`과 `.`을 찍으면 됩니다.

수식으로 바로 해결해도 되고, N의 범위가 작기 때문에 반복문으로 돌려도 충분히 해결됩니다.

C - Shortest Duplicate Subarray

N 개의 숫자가 주어집니다.

주어지는 수열에서 `중복되는 숫자가 있는 부분 수열 중 최소 길이`를 구해야 합니다.

언뜻보면 브루트포싱으로 할 수 있겠다 싶지만, 숫자 범위가 그렇지 않습니다. 곧바로 각 숫자마다 분류하여 index를 저장했고, 각 index를 훑으면서 최소 격차를 가진 곳을 찾아 반환했습니다.

(처음에 문제를 잘못 읽어서 중복된 숫자가 없는 수열로 보았다가 시간 낭비를 했습니다.)

D - Pigeon Swap

해당 문제에서는 3가지의 연산이 있습니다.

1. 비둘기 한 마리가 이동한다.
2. 두 둥지에 있는 비둘기들이 서로 다 바꾼다.
3. A번 비둘기가 어디있는지 출력한다.

저는 이 문제를 보자마자, 그냥 어? 둥지 안에 있는 비둘기를 서로 바꾸는게 아니라 둥지에 가상의 라벨이 붙어있다고 생각하고, 그 라벨을 바꿔 붙였다고 생각하면 되는거 아닌가? 라고 생각을 했습니다.

그래서 비둘기마다 위치하는 둥지 위치, 각 둥지(번호를 매겨놓은)마다 붙어 있는 라벨, 각 라벨마다 붙어있는 둥지 원래 번호를 각각 저장했고 제 연산마다 적재적소로 활용해서 문제를 풀이했습니다.

어찌보면 포인터를 활용했다고 할 수 있겠네요.

아래는 코드의 일부 내용입니다

def solve():
  N, Q = mii()

  pigeon_place = [i for i in range(0, N)]
  place_label = [i for i in range(0, N)]
  place_label_rev = {}
  
  for i in place_label:
    place_label_rev[i] = i

  for _ in range(Q):
    commands = mii()

    if commands[0] == 1:
      a, b = commands[1:]
      a -= 1; b -= 1
      pigeon_place[a] = place_label_rev[b]

    elif commands[0] == 2:
      a, b = commands[1:]
      a -= 1; b -= 1

      A = place_label_rev[a]
      B = place_label_rev[b]

      place_label[A], place_label[B] = place_label[B], place_label[A]
      place_label_rev[a], place_label_rev[b] = B, A
    else:
      a = commands[1]
      a -= 1
      print(place_label[pigeon_place[a]] + 1)

E - Flip Edge

그래프가 주어집니다.
이때 1번 노드에서 N번 노드로 이동하면서 최단 거리를 알아내야 합니다.

단, 각 간선의 길이는 무조건 1입니다.
그리고 모든 간선의 방향을 뒤바꾸는 연산을 하면서 X 비용을 낼 수도 있습니다.

저는 문제를 보고, 이건 무조건 다익스트라 알고리즘으로 하면 되겠다 였고, 단 거리를 저장하는데 있어서 Distance[어느 방향으로 이 노드에 도달했는가? (0: 정방향, 1: 역방향)][노드 번호]와 같이 거리를 저장하기로 했고 각 노드에서 다시 방향을 유지하여 갈때는 원래 비용인 1을 사용하고, 방향을 바꿔서 갈때는 X + 1을 사용하여 가기로 설정했습니다.

아래는 코드의 일부 내용입니다.

struct Edge {
  ll node;
  ll cost;
  ll direction;
  Edge(ll node, ll cost, ll direction) : node(node), cost(cost), direction(direction) {}

  bool operator<(const Edge &to) const {
    return cost > to.cost;
  }
};

ll N, M, X;
vector<vector<vector<Edge> > > edges;
ll dist[2][220000];

ll dijkstra(ll s) {
  priority_queue<Edge> pq;

  pq.push(Edge(s, 0ll, 0));
  pq.push(Edge(s, X, 1));
  dist[0][s] = 0;
  dist[1][s] = X; // 모든 엣지를 역방향으로 바꾸면서 시작하는 경우

  while (!pq.empty()) {
    Edge cur = pq.top();
    pq.pop();
    
    if (cur.cost > dist[cur.direction][cur.node]) continue;
  
    // 만약 정방향으로 간다면
    for(auto nxt : edges[cur.direction][cur.node]) {
      if (dist[cur.direction][nxt.node] > cur.cost + nxt.cost) {
        dist[cur.direction][nxt.node] = cur.cost + nxt.cost;
        pq.push(Edge(nxt.node, dist[nxt.direction][nxt.node], cur.direction));
      }
    }

    // 만약 역방향으로 바꿔서 간다면
    for(auto nxt : edges[1 - cur.direction][cur.node]) {
      if (dist[1 - cur.direction][nxt.node] > cur.cost + X + nxt.cost) {
        dist[1 - cur.direction][nxt.node] = cur.cost + X + nxt.cost;
        pq.push(Edge(nxt.node, dist[1 - cur.direction][nxt.node], 1 - cur.direction));
      }
    }
  }

  return min(dist[0][N], dist[1][N]);
}

void solve() {
  for1(0, M) {
    ll a, b; cin >> a >> b;
    edges[0][a].push_back(Edge(b, 1, 0));
    edges[1][b].push_back(Edge(a, 1, 1));
  }

  cout << dijkstra(1);
}

F - Smooth Occlusion

풀이 X..

G - Minimum Steiner Tree 2

풀이 X..

결론

무난하게 5문제를 풀이하고나서, F, G번을 트라이할만한 시간이 남은 competition이었습니다. 다만, 오랜 기간동안을 손을 놓아서인지 구현 속도가 느리기도 했고 조금이라도 어려운 요소가 섞이니 접근이 잘 안되고 있습니다. 백준에서 골드/플레 문제 풀이를 해야할 것 같습니다..

새로운 시작을 준비하며, 그렙을 떠나 다시 학교로 돌아갑니다

koa (김신건) — Wed, 26 Feb 2025 04:25:00 GMT

새로운 시작을 준비하며, 그렙을 떠나 다시 학교로 돌아갑니다

안녕하세요, 백엔드개발자 김신건, Koa 입니다. 저는 2019년부터 함께한 그렙(Grepp)을 떠나, 다시 대학교로 돌아가기로 결심했습니다.

오랜 시간 인턴부터 정직원까지 쌓아온 경험과 애정이 깊은 회사지만, 지금은 제 자신을 더 깊이 탐구하기 위해 돌아가야 할 시점이라 느끼게 되었습니다. 이 결정은 분명 쉽지 않았습니다. 이 결정이 또 다른 성장의 기회가 될 거라 믿습니다.

그렙과의 지난 여정을 정리하면서, 저의 지난 발자취에 대해서도 공유해보고자 합니다.

C 언어 하나로 바뀐 꿈

저는 개발자를 꿈꾸던 사람이 아닙니다.

저는 어릴 적부터 기계공학자를 꿈꾸었고, 기계나 로봇을 설계하고, 설계한 것이 실제로 움직이는 걸 보면 가슴이 뛰는 아이였습니다. 하지만 “과연 내가 기계를 아주 잘 설계하고, 활용할 수 있는 사람인가?” 하는 근본적인 의문이 늘 따라다녔습니다. 그런 고민을 품고 지내던 중, 고등학교(한민고등학교) 방과 후 수업에서 C 프로그래밍을 처음 접했습니다.

처음에는 그저 호기심으로 시작했던 C 언어 공부였지만, 코드업(CodeUp) 사이트의 기초 100제를 풀어나가는 과정이 꽤 재미있었습니다. “나, 이거 꽤 잘하는 것 같은데?” 라는 작은 자신감이 쌓인 후, 300문제, 400문제를 연달아 풀었습니다. 그리고 곧장 정보선생님에게 찾아가 지금 당장 해야하는 공부에 댈해서 질문했습니다. 그렇게 알고리즘과 자료구조에도 본격적으로 입문했습니다. (그렇게 내신 성적은 점점 떨어졌지만요)

이때부터 여러 알고리즘 대회에 참가하기 시작했습니다. 다른 대회 참가자들에 비해 늦게 출발한 만큼 화려한 수상 성적을 거두진 못했습니다. 그래도 꾸준히 노력한 덕분에 가끔씩 장려상이나 동상을 받았고, 그 경험들이 저에겐 큰 동기부여가 되었습니다. 그리고 그 많은 대회 속에서 프로그래머스(Programmers) 사이트를 통해 대회가 진행되었는데, 이 플랫폼을 운영하는 기업이 바로 그렙이라는 사실을 훗날 알게 됩니다.

소프트웨어 특기자 전형으로 대학에 입학하다

고등학교 시절 학업 성적은 점점 떨어졌지만, 그동안 쌓아온 대회 수상 기록, 소논문 등으로 소프트웨어 특기자 전형에 도전했습니다. 6개의 대학에 지원했지만 그 중 5개는 고배를 마셨고, 마지막 한 곳에서 극적으로 합격 통지를 받았습니다. 그렇게 대학교에 입학해, 1학년 1학기를 보내며 여러 수업을 들었고, 방학 시즌에 현장실습을 하면 학점과 인턴 월급을 함께 받을 수 있다는 사실을 알게 되었습니다.

당시 여러 회사에 지원했지만, 최종적으로 그렙의 알고리즘 콘텐츠 제작 인턴으로 합격하여 방학을 그렙에서 보내게 되었습니다. 이 시기가 저와 그렙의 인연이 본격적으로 시작된 때입니다.

1학년 1학기 방학, 그렙에서 첫 인턴십

처음 회사로 출근하여, “내가 지금까지 공부해온 게 실제로 이렇게 쓰이는구나!”라는 사실이 무척 신기했습니다. 특히 제가 대회에서 사용했던 프로그래머스 서비스 내의 알고리즘 콘텐츠/문제들을 제작하는 과정에 기여할 수 있었다는 점이 큰 보람으로 다가왔습니다.

그래서 저는 최대한 열심히 업무를 수행했고, 저 스스로의 최대한의 역량을 발휘했습니다. 그리고 그렙에서 인연을 이어가며, 2학년 1학기 방학 때까지 알고리즘 콘텐츠 제작자로 계속 근무할 기회를 얻었습니다.

2학년 이후, 웹 개발로 시야를 넓히다

1학년에서 2학년 사이 기간 동안 스스로 한계를 느끼기도 했습니다. “내가 잘하는 건 알고리즘 문제 풀이뿐인가?”라는 생각이 들었습니다.

1학년의 저는 알고리즘만 아는 코더였던거죠. 그냥 문제 풀이만 할 줄 아는 사람이었습니다. 그것도 깊게 하지 못하는. 굉장히 스스로 부끄러웠고, 발전이 되고 있지 않았다는 것을 느꼈습니다. 마침 주변 지인들의 조언으로 웹 개발 동아리에 들어가게 됐고, 그곳에서 처음 웹 프레임워크와 프로젝트 구축 방법을 익혔습니다. 2학년 2학기가 끝나갈 즈음, “알고리즘 관련 말고, 웹 개발로 인턴을 할 수 있는 곳이 없을까?” 고민하던 차에, 그렙에서 개발 인턴으로 근무해볼 생각이 없는지 제안을 받았습니다. 덕분에 그렙과의 인연은 또 다른 국면에 접어들었습니다.

정직원으로 그렙에 합류, 그리고 군 복무

방학 인턴으로 웹 개발에 본격 뛰어들면서, 제가 실제로 사용하던 프로그래머스 서비스를 직접 개발하게 된다는 점이 참으로 매력적이었습니다. Ruby on Rails를 처음 접했고, Vue.js도 함께 다루면서 프론트엔드와 백엔드 양쪽을 모두 맛볼 수 있었습니다.

방학이 끝난 후 선택지가 생겼습니다. “계속 학교를 다닐까, 아니면 휴학 후 정직원으로 일하며 더 빠르게 성장할까?” 고민 끝에 저는 그렙에서 정직원으로 근무하기로 했습니다. 이후 2021년, 2022년에 걸쳐 채용사업부의 개발자로서 프로그래머스 채용 서비스와 비즈니스 서비스를 구축하고 개선하는 업무를 맡았습니다. 점차 백엔드 분야에 더 흥미를 느끼게 되어 서버 쪽을 심도 있게 파고들면서, 개발자로서의 시야를 넓혀갔습니다.

그러나 그 시기에 산업기능요원 제도가 바뀌면서, 저처럼 현역 판정인 사람은 산업체 복무가 불가능해졌습니다. 결국 군대를 더 이상 미룰 수 없다고 판단해 갑작스럽게 군대를 가게 되었습니다. 인생 계획이 어그러진 느낌이었지만, 한편으로는 “군대에서 조금이라도 휴식과 함께 생각을 정리할 수 있는 기회가 있겠지?”라는 희망도 있었습니다. (물론 자대 배치 이후의 현실은 그렇게 간단하지 않았지만요. 군 복무 이야기)

전역 후, 다시 그렙으로 복직 … 그리고 또 한 번의 고민

군 복무를 마치고 2024년 7월, 다시 그렙에 복직했습니다. 이번에는 교육솔루션팀에 합류해 교육 서비스를 개발하는 일을 맡았습니다. 8개월 정도 근무하면서, 안정적인 루틴과 급여 덕분에 편안함을 느꼈지만, 그 편안함 한편에서 “내가 진짜 하고 싶은 건 뭘까?”라는 고민이 점점 커졌습니다.

계속해서 새로운 기능을 만드는 데도 점차 흥미를 잃어가고, 동시에 사적인 프로젝트나 지식 탐구에도 예전 같은 열정을 쏟지 못하고 있다는 걸 깨달았습니다. 군대에 가기 전, “나는 성장하고 싶어!”라고 불타올랐던 그 마음이 어딘가 녹슬어버린 느낌이었습니다. 그러다 보니, "알고리즘만 아는 코더" 시절처럼 정체된 제가 부끄러웠습니다. “안정감만 쫓고 있으면, 결국 제자리걸음 아닌가?”라는 생각과 후회감이 들었고, 이번에는 스스로를 다시 새로운 환경에 던져 몰아붙여야겠다는 결심을 하게 되었습니다.

그래서 2025년 2월을 기점으로, 저는 그렙을 떠나 다시 대학으로 복학하기로 마음먹었습니다. 학교에서 좀 더 이론적인 공부를 보완하고, 새롭게 떠오르는 기술들에 집중해보고 싶습니다. 그 이후, 또 새로운 곳에 뛰어들어 가보고 싶습니다.

모든 선택에는 리스크가 따르지만, 지금이 아니면 안 될 것 같습니다. 물론 이 선택이 나중에 후회로 남을 수도 있습니다. 하지만 지금 이 시점에서 “기회비용을 감수하면서도 성장을 택하겠다”라는 다짐이, 오히려 저에겐 강력한 동력이 될 것 같다는 생각이 듭니다.

떠남은 끝이 아니라 또 다른 도약

저는 아직도, 계속해서 제 자신을 “부족한 개발자”라고 생각합니다.

특별히 잘하는 한 분야가 확고하게 잡혀 있는 것도 아니고, 일에 완전히 몰입하는 것도 잠시 주춤했던 때가 있었습니다. 그럼에도 "스스로를 몰아붙이고, 낯선 환경에서 새로운 경험에 뛰어드는 것" 만큼은 잘한다고 단언할 수 있습니다.

이번 결정이 누군가에게는 이해되지 않을 수도 있고, 저조차 훗날 후회할지 모릅니다. 하지만 그 후회조차도 분명 저를 더 나은 길로 이끄는 "새로운 동기부여"가 될 것이라 믿습니다.

그렙에서 함께했던 동료들, 그리고 프로그래머스를 통해 만났던 많은 분들께 감사 인사를 전합니다. "새로운 도전에 뛰어들려는 지금 이 순간"이 훗날 제가 더 큰 성장을 할 시작점이 되리라 믿습니다.

감사합니다.

Atcoder Beginner Contest 394 후기

koa (김신건) — Sun, 23 Feb 2025 05:00:00 GMT

개요

대회 링크

어제 (2/22) 저녁 9시부터 10시 40분까지 진행된 [[Atcoder]] Beginner Contest 394 후기입니다.

총 7문제 중 5문제를 풀었습니다. A ~ D까지 4문제는 대회 시작후 13분 안에 풀이했지만 E번 정확한 풀이를 생각해내는데 60분을 썼고, F번 문제를 읽고 끝났습니다.

공식 에디토리얼 (해설)

풀이

A - 22222

단순히 주어지는 숫자 문자열에서 2의 개수만큼 다시 2를 출력하는 문제입니다. 빠르게 구현하면 됩니다.

B - cat

주어지는 문자열을 문자열의 길이를 기준으로 정렬 후 차례대로 붙여 출력하는 문제입니다. 빠르게 구현하면 됩니다.

C - Debug

주어지는 문자열에서 WA 라는 문자열을 AC 라는 문자열로 계속해서 대체할 때, 최종 문자열을 구하는 문제입니다.

예를 들어, WWA 라는 문자열이 있으면 WWA → WAC → ACC 로 변합니다.

저는 단순히 처음에는 스택을 활용할까 생각했지만, 문자가 변하는 양상을 보니 W*X개+A*1개 의 형태를 갖춰야만 바뀐다는 걸 캐치하고, W의 개수를 세다가 A 문자가 등장하면 대체하는 식으로 코드를 구성했습니다.

D - Colorful Bracket Sequence

전형적인 안정적인 괄호 문자열 문제입니다. 다만, 괄호의 종류를 (), <>, [] 로 해두었습니다. 따라서, 관련 처리를 하면서 스택으로 해결하면 됩니다.

E - Palindromic Shortest Path

그래프가 주어집니다. 단, 정점이 아닌 “간선”마다 문자가 기록되어 있는 그래프입니다. 이때 모든 정점 사이의 페어마다, 간선의 문자열을 나열해서 팰린드롬이 되도록 하는 경로의 최소 길이를 구해야 합니다.

처음에 저는 BFS로 정점마다 출발하여 팰린드롬인지 파악하는 완전탐색으로도 1억 내외로 연산 수가 떨어지면 시간안에 들지 않을까라는 생각으로 트라이했습니다. 하지만 TLE가 나왔고, 다른 방법을 생각해야 했습니다.

이때 굳이 간선의 정보가 주어지고 있는데, 정점 기준으로 탐색할 필요가 있을까 생각이 들었습니다. 그래서 모든 간선은 일단 문자가 1개로 구성된 팰린드롬이고, 양 옆에 같은 문자를 이어 붙이면 팰린드롬이 되지 않을까 라는 생각으로 알고리즘을 구성했습니다.

먼저 정방향 간선 정보와 역방향 간선 정보를 저장한다.
모든 간선을 큐에 넣는다. (해당 간선은 길이가 1인 팰린드롬이기 때문에, { 시작점, 끝점, 길이=1 }) 와 같이 넣는다.
아래에서 설명 추가 과정 필요
큐의 맨 앞에 있는 간선에서 정방향 간선 정보와 역방향 간선 정보를 참조해, 앞 뒤로 같은 문자을 붙일 수 있느지, 붙일 수 있다면 그것이 현재 최소 길이인지 확인해서 갱신 후 큐에 다시 넣는다.
갱신된 모든 길이를 출력한다.

이 방법의 이점은 일단 간선의 정보만 다룬다는 것이고, 만들어진 문자열들이 팰린드롬인지를 체크할 필요가 없다는 것입니다.

그리고 이 방식은 홀수 길이인 경우만 알아낼 수 있는데 따라서 3번 과정에서 모든 i에 대해 i → i 로 가는 가상의 경로에 현재까지의 팰린드롬 길이가 0이다를 집어넣어놓으면 됩니다. { 출발점=i, 끝점=i, 길이=0} 과 같이 말입니다.

F - Alkane

그래프 정보가 주어집니다. 이때 아래 조건을 만족하는 부분 그래프의 최대 크기를 구합니다.

해당 그래프는 무향 그래프다.
모든 정점의 차수는 1 또는 4이다. (해당 정점에 이어지는 간선 수)

딱히 떠오르는 해답이 없었습니다…

G - Dense Buildings

문제조차 읽지 못했습니다.

결론

7문제 중 5문제를 풀이하면서 점차 예전의 실력을 되찾아가는 느낌이 들었습니다. 언젠가 모든 문제를 막힘없이 자연스럽게 다 푸는 실력까지 도달하고 싶습니다.

2022년 11월부터 시작된 1년 6개월 회고록

koa (김신건) — Tue, 28 May 2024 06:00:00 GMT

길면서 짧았던 군 생활을 마무리하며, 회고록을 작성한다.

서론

2022년 11월 28일, 논산 훈련소로 입대했습니다.

같이 오신 부모님과 되게 쿨한 작별 인사를 하고, 터벅 터벅 들어갔습니다. 이전에는 입소식도 했다고 하지만, 저는 코로나 막바지라 그런 행사 없이 바로 입소 관련 절차를 시작했습니다.

훈련소 내에서도 여러 일이 있었지만.. 시간이 바로 흘러 어느덧 수료식이었습니다. 수료식이 끝나고 부모님과 외출/면회를 하면서 저의 자대 배치 결과를 확인했습니다.

특전사령부.

????????? 저는 굉장히 당황스러웠고, 왜? 내가 어째서? 이게 맞아?

일단 특전사령부는 어디있지 하고 찾아보았고, 경기도 이천에 있다는 것을 확인했습니다. 와, 그래도 집 앞에 있는 부대로 가는구나 싶어서 신났습니다. (본가가 이천입니다)

그렇게 외출에서 복귀하고 자대 배치일을 기다려서, 그날이 왔습니다.

하지만 뭔가 이상했습니다. 이천으로 가는 길이라고 하기엔 너무 멀었고, 담당 간부님은 제가 전남 담양으로 간다고 말씀하셨습니다. 거기는 어디지..? 하고 물어보니 11공수특전여단이었고, 특전사령부의 예하 여단으로 가는 것이었습니다. 아.. 예하 부대는 표기가 안되는 거였구나 싶었고, 그렇게 전남 담양에서의 군 생활이 시작되었습니다.

자대 배치 후, 군 생활이 새로 시작되었다 할만큼 굉장히 많은 업무와 생활 룰(?)을 배웠고, 숙지했습니다.

그 이후, 여러 훈련도 하고, 업무/공부/운동을 반복하다 보니 1년 반이 흘렀습니다. (자세한 내용은 스킵. 알고 싶으면 술 사주면서…ㅎㅎ)

이제 한번 어떤 걸 공부했었는지 정리해보려 합니다. (군 관련 내용은 일부러 안 적었습니다.)

군대에서 공부하기

자격증을 땄다.

네트워크관리사 2급 자격증을 군생활 막바지에 땄습니다.

사실 필기 시험은 진작에 통과했었습니다. 나중에 따야지..따야지 하다가 막바지에 진짜 이제는 해야한다는 생각을 가지고 나중에서야 땄습니다..

그리고 전역 이틀 전에 SQLD 시험을 응시했고, 아마.. 합격이지 않을까 생각합니다.

백준 문제라도 풀자.

입대 전(2451문제) → 24.05.01(4034문제)로 약 1500문제 이상을 풀었습니다. 그리고 군생활 도중에 다이아5에서 다이아4로도 승급했습니다.

뭐.. 최대한 많은 문제와 할 수 있는 공부는 다 해보자라는 생각으로 계속 했던 것 같습니다. 그 덕분에 시간도 금방 간 것 같습니다.

강의를 듣자.

code.plus 사이트(스타트링크)에서 제공하는 알고리즘 고급으로 가는 연결고리 강의를 들었습니다.

인프런 - 외워서 끝내는 네트워크 핵심 이론 - 기초, 외워서 끝내는 네트워크 핵심 이론 - 응용 강의를 수강했습니다. 네트워크 관리사 자격증을 따면서 더 좋은 지식을 얻을 수 있을까 싶어 강의를 들었습니다. 상당히 좋은 강의였고 추천합니다.

인프런 - 외워서 끝내는 SSL과 최소한의 암호기술 강의를 수강했습니다. 위 네트워크 강의와 이어지는 부분이 많았고, 아직도 다시 찾아보면서 내용을 흡수하고 있습니다.

생활 코딩 - 정규표현식, Web2 : Oauth 2.0 강의를 수강했습니다. 이전부터 조금씩 내가 제대로 알고 있는 게 맞나 싶었던 부분을 긁어주었던 강의였습니다. 전역 후 다시 TIL 글로 정리해보려고 합니다.
인프런 - [그림으로 이해하는] 동기 비동기의 개념에 대한 가장 직관적인 이해라는 강의를 수강했습니다. 사실 거의 아는 내용이 나왔고, 조금 아쉬웠습니다. 차라리 이 강의를 몇 년 전에 비동기에 대한 이해가 없었을 때 봤다면 더 좋았겠다 싶습니다.
인프런 - SVG 마스터 강의를 수강했습니다. 뭔가 유익했지만 군대라는 현실에 실습을 거의 못해봤습니다. 조금 아쉽기에 이걸 활용한 사이드 프로젝트를 진행할 수 있을까 고민해봅니다.

앞으로는 뭘 하지?

남은 2024년 동안에는 아래 목표를 하나씩 차근차근 해보려 합니다.

일간 목표

아침 또는 저녁마다 운동을 한다. (안 되면 산책이라도)
매일 백준 문제 풀기 (적어도 1문제)

월간 목표

적어도 2권의 책을 읽는다. (종류 상관 X)
매주 일요일 혹은 매달 마지막에 무엇을 했는지 간단하게 정리하자.
TIL Repo에 꾸준히 기록물을 남긴다.

연간 목표

회사를 재밌게 다닌다.
연간 백준 500 AC를 도전한다.
자격증 / 운전 면허증 등의 자격증을 꾸준히 딴다.
Codeforces / Atcoder Contest에 주기적으로 참여한다. (Blue를 계속 유지할 수 있는 실력이 될 수 있도록)
Kaggle을 시작한다.
간단한 사이드 프로젝트를 적어도 2개 진행한다.
Spring과 K8s를 공부한다.
재미있는 자취 생활을 한다.

아무튼

드디어 끝났습니다.

제가 거창하게 나라를 지켰다고는 못하겠습니다.

저는 누군가가 계속 이어서 지켜오던 한 자리를 지켰고, 자리를 지키는 것 만큼은 최선을 다했다 생각합니다.

저는 앞으로 좀 더 다양한 경험을 사회에서 하면서 저의 길을 다시 걸어 가보겠습니다.

지금까지, 그리고 앞으로 나라와 각자의 자리를 지켜주시는 군인 여러분 감사합니다.

단결.

[BOJ] 16496 큰 수 만들기

koa (김신건) — Wed, 20 Sep 2023 14:03:00 GMT

문제 요약 및 풀이

16496번: 큰 수 만들기

야간 당직을 서면서 직접 숫자를 만들어 나열해가다가, 아이디어가 떠올랐다.

임의의 어떤 수 A와 B가 있을 때, 두 수를 합친 AB와 BA가 있다면, 그 두 수중 큰 숫자를 선택하는 상황이다.

그럼 점차 합쳐지는 과정에서도 똑같은 규칙이 적용되는 것이니, 정렬을 해당 기준으로 하고 나중에 합치면 되지 않을까?

풀이시에 주의하기…

ull 타입 사용하기, 오버플로우 주의
0000…000 은 0 이다. 문제조건을 잘 읽자.

풀이 코드

#include <bits/stdc++.h>

using namespace std;

#define for1(s, e) for(int i = s; i < e; i++)

typedef unsigned long long ull;

ull ar[1100];

ull zero(ull a) {
  ull ret = 1;
  if(a == 0) return 10;
  
  while(a > 0) {
    ret *= 10;
    a /= 10;
  }
  return ret;
}

bool compare(ull a, ull b) {
  ull x = a * zero(b) + b;
  ull x2 = b * zero(a) + a;
  
  if(x <= x2) return false;
  return true;
}

void solve() {
  int N;
  
  cin >> N;
  
  for1(0, N) {
    cin >> ar[i];    
  }
  
  sort(ar, ar+N, compare);
  
  if(ar[0] == 0) {
    cout << 0;
    return;
  }
  
  for1(0, N) {
    cout << ar[i];
  }
}

int main() {
  ios::sync_with_stdio(0);
  cin.tie(NULL);cout.tie(NULL);
  int tc = 1; // cin >> tc;
  while(tc--) solve();
}

[BOJ] 16940 BFS 스페셜 저지

koa (김신건) — Sun, 10 Sep 2023 04:00:00 GMT

문제 요약 및 풀이

16940번: BFS 스페셜 저지

트리가 주어지고, 노드들을 탐색한 순서가 주어진다. 이때, 탐색한 순서가 BFS 탐색으로 가능한 순서가 맞는지 검증하면 된다.

처음에는 정말 단순하게 접근했다.

그냥 BFS 탐색을 한번 돌면서, level graph를 만들고, level graph 상에서의 level이 비내림차순으로 배치되었는가만 봤다.

하지만, 역시나 바로 WA를 받았다. (생각을 좀 하고 풀라고…)

문제가 뭘까 생각중에 아래 예제를 질문 게시판에서 봤다.

이 경우에는 12354 또는 13245만 가능한데, 2 또는 3을 방문하는 순서에 따라 4 와 5의 방문순서가 결정되기 때문이다. 따라서, 12345와 같은 방문 순서가 불가능해진다.

그렇기 때문에 위에서 생각한 level graph로 판단하는 건 불가능하다.

그래서 결국 주어지는 순서대로 BFS 방문을 직접 해보는데, 다음노드로 넘어갈 때의 순서를 주어진 순서를 참고하여 탐색해보는 방법을 사용했다.

풀이 코드

#include <bits/stdc++.h>

#define for1(s,n) for(int i = s; i < n; i++)
#define for1j(s,n) for(int j = s; j < n; j++)

using namespace std;
typedef pair <int, int> pii;

int N;
vector<int> edges[110000];
int order[110000];
bool chk[110000];

int main() {
  ios::sync_with_stdio(0);
	cin.tie(0);
	cout.tie(0);
	
	cin >> N;
	for1(0, N - 1) {
		int a, b;
		cin >> a >> b;
		edges[a].push_back(b);
		edges[b].push_back(a);
	}
	
	for1(0, N) {
		int a;
		cin >> a;
		order[a] = i;
	}
	
	queue<int> Q;
	Q.push(1);
	int crt = 0;
	
	while(!Q.empty()) {
		int f = Q.front(); Q.pop();
		
		if(crt != order[f]) {
			cout << 0;
			return 0;
		}
		
		chk[f] = true;
		
		crt++;
		
		vector <pii> v;
		
		for(int nxt : edges[f]) {
			if(chk[nxt]) continue;
			
			v.push_back({ order[nxt], nxt });
		}
		
		sort(v.begin(), v.end());
		
		for(auto nxt : v) {
			Q.push(nxt.second);
		}
	}
	
	cout << 1;
}

[BOJ] 2618 경찰차

koa (김신건) — Sat, 27 May 2023 09:23:00 GMT

문제 요약 및 풀이

2618번: 경찰차

1. 두 경찰차가 모든 사건을 처리하러 이동해야 한다.
2. 모든 사건을 주어지는 순서대로 처리해야 한다.
3. 두 경찰차는 처음에 각각 (1, 1), (N, N)에 위치한다.

이때, 두 경찰차가 이동하는 최소 거리를 구해야 한다.

일단 먼저 모든 경우를 탐색한다고 생각해보고 접근해보자. 사건의 개수는 C개 (<= 1000)이다.

그럼 사건을 두 경찰차가 각각 배정받게 만들고, 이를 계산을 순서대로 해본다고 하자. 시간복잡도는 2^C 가 되며, 문제의 최대 범위로 입력이 들어올 경우 최대 2^1000 만큼 연산해야 한다.

무조건 시간초과가 뜰 것이다.

생각을 간단히 해보자.

만약에 첫번째 경찰차가 2번째 사건까지 처리하고, 두번째 경찰차가 4번째 사건까지 어찌저찌 처리했다 해보자.

그럼 다음으로 처리해야 하는 사건은 어떤 사건인가?

당연하게도 5번째 사건을 처리해야 한다.

왜? 바로 순서대로 사건을 처리해야 한다는 조건때문이다.

이 점을 이용해서 DP 식에 넣고 이용해보자.

i는 첫번째 경찰차의 마지막 위치라하고
j는 두번째 경찰차의 마지막 위치라 할 때
DP[i][j] = 두 경찰차가 이동한 최소 거리라 하자.

단, i와 j는 같을 수 없다. (i와 j가 같다는 것은 두 경찰차가 같은 사건을 처리했다는 의미이므로 배제해야 한다.)

DP[i][j] 를 이용해서 알아낼 수 있는 값은 어떤 것이 있을까?

첫번째 경찰차 또는 두번째 경찰차가 이동하는 경우일테니 아래와 같을 것이다.

// 첫번째 경찰차가 이동한 경우
int nxt = max(i, j) + 1;
DP[nxt][j]] = DP[i][j] + dis(points[i], points[nxt]);

// 두번쨰 경찰차가 이동한 경우
int nxt = max(i, j) + 1;
DP[i][nxt]] = DP[i][j] + dis(points[j], points[nxt]);

풀이 코드

#include <bits/stdc++.h>

#define for1(s,n) for(int i = s; i < n; i++)
#define for1j(s,n) for(int j = s; j < n; j++)
#define foreach(k) for(auto i : k)
#define foreachj(k) for(auto j : k)
#define pb(a) push_back(a)
#define sz(a) a.size()
#define INF 100000000

using namespace std;
typedef unsigned long long ull;
typedef long long ll;
typedef vector <int> iv1;
typedef vector <vector<int> > iv2;
typedef vector <ll> llv1;
typedef unsigned int uint;
typedef vector <ull> ullv1;
typedef vector <vector <ull> > ullv2;

struct Point {
	int y, x;
};

struct st {
	Point p;
	Point rev;
	int cost;
};

struct cmp{
    bool operator()(st a, st b){
        return a.cost > b.cost;
    }
};
 
int N;
int C;
Point points[1100];
int D[1100][1100];
Point back[1100][1100];

int dis(Point a, Point b) {
	return abs(a.x - b.x) + abs(a.y - b.y);
}

int main() {
  ios::sync_with_stdio(0);
	cin.tie(0);
	cout.tie(0);
	
	cin >> N >> C;
	
	for(int i = 0; i <= C + 1; i++)
		for(int j = 0; j <= C + 1; j++) D[i][j] = INF;
	
	points[0] = {1, 1};
	points[1] = {N, N};
	
	for(int i = 2; i <= C + 1; i++) cin >> points[i].y >> points[i].x;

	priority_queue <st, vector<st>, cmp> q;
	
	q.push({ {0, 1}, {0, 0}, 0});
	
	while(!q.empty()) {
		st here = q.top(); q.pop();
		
		int y = here.p.y;
		int x = here.p.x;
		if(D[y][x] <= here.cost) continue;
		
		D[y][x] = here.cost;
		back[y][x] = here.rev;
		
		int nxt = max(y, x) + 1;
		
		if(nxt > C + 1) continue;
		
		q.push({ {y, nxt}, here.p, here.cost + dis(points[x], points[nxt])});
		q.push({ {nxt, x}, here.p, here.cost + dis(points[y], points[nxt])});
	}
	
	stack <Point> stk;
	int ans = INF;
	Point s;
	
	
	for(int i = 0; i <= C + 1; i++) {
		if(D[i][C + 1] < ans) {
			ans = D[i][C + 1];
			s = {i, C + 1};
		}
		if(D[C+ 1][i] < ans) {
			ans = D[C + 1][i];
			s = {C + 1, i};
		}
	}
	
	cout << ans << "\n";
	
	while(s.x != 0 || s.y != 0) {
		stk.push(s);
		s = back[s.y][s.x];
	}
	
	while(!stk.empty()) {
		Point here = stk.top();
		stk.pop();
		
		if(stk.empty()) continue;
		
		Point there = stk.top();
		
		if(here.x != there.x) cout << 2;
		else cout << 1;
		cout << "\n";
	}
}

2년차 주니어 개발자 / 휴학생 / 예비 군인의 미리 쓰는 2022년 회고록

koa (김신건) — Sun, 30 Oct 2022 07:05:00 GMT

2년차 주니어 개발자, 휴학생, 예비 군인 등 많은 수식어가 생긴 올해의 회고록은 일찍 써보려 한다.

서론

이 회고록은 왜 일찍 쓰여지는 걸까?

작년 회고록 에서도 언급되었지만, 군대를 가야 합니다.

최대한 올해가 가기전에 입대를 하기 위해, 두 번이나 SW 개발병에 지원을 했었지만, 첫번째는 면접에서 탈락, 두번째는 서류에서 탈락했습니다.

아무래도 SW 개발병 점수에 포함되는 학력 점수가 영향을 많이 줬지 않았을까 생각하고 있습니다… (휴학을 너무 빨리 했습니다 ㅠ)

아무튼, SW 개발병으로 개발을 하면서 군대 생활을 하기엔 힘들겠다 판단했고, 기술행정병으로 지원했고 정보체계운용/정비 특기로 11월 28일에 입대합니다.

11월 언저리 넘어서야 올해 회고록 좀 써볼까 해왔었지만, 올해는 좀 서둘러봅니다.

올해는 큰 변화가 있었을까?

솔직히 큰 변화는 없던 한해 같습니다.

매일 아침 일어나 리모트 근무를 시작하고, 업무 시간이 끝나면 저녁을 먹고 독서 / 알고리즘 공부 / 유튜브 또는 넷플릭스 보기만 반복을 했던 것 같습니다.

어쩌면 2년동안 반복되는 생활에 큰 변화를 주면서, 언젠가는 해야 하는 의무를 다하기 위해 올해가 가기전에 입대를 하기로 한 것 같습니다.

올해는 뭘하며 지낸걸까?

회사 업무는 끝이 없었다.

JIRA 사이트에서 올해 내가 맡았던 이슈들 개수를 뽑았을 때 총 290개(2022.10.12 기준)가 나왔습니다…

처음에 뽑고나서 이렇게까지 많이 했었나? 라는 생각이 들었지만, 한번씩 제목들을 살펴봤더니 모두 기억에 남아있는 내용들이었습니다.

그 중에 기억에 남는 업무들을 간접적으로 나열해보고자 합니다.

1. 어쩌다보니 실험실이 된 프로젝트

다른 서비스에서 제공하는 API를 활용해야 하는 업무가 있었습니다. 근데 해당 서비스에서 제공하는 API는..

여러 복잡한 과정들을 거쳐서 값을 복호화 / 암호화해야 했습니다.
우리 부서만 사용하는게 아니었습니다.

그래서 결국 해당 API를 한번 걸러서 간편하게 사용할 수 있는 서버리스 프로젝트를 만들기로 했습니다.

그렇게 해당 프로젝트를 활용할 부서들에서 사람들이 모여서 개발을 시작했습니다.

해당 프로젝트를 진행하기 위해 여러 기술 / 인프라들이 합쳐지기 시작했는데,,,

Python, Flask, Docker(docker-compose), DynamoDB, AWS ECR, AWS Lambda, AWS API Gateway, Terraform 등

Python과 Flask

개발 자체는 Python과 Flask 프레임워크를 사용했습니다. (개발을 같이 하는 동료들의 주 언어가 대부분 Python 이었고, 간편하고 빠르게 개발할 수 있을 거라 생각했습니다.)

Terraform

그리고 해당 프로젝트의 인프라를 구성할 때, 가장 먼저 고려한 건 Terraform 이었습니다.

Terraform을 이용해 기본적인 VPC 부터 Lambda까지 모든 인프라를 구성하기로 했습니다. 사내에서 여러 프로젝트 인프라들이 Terraform으로 구성되고 있던 추세였고, 사용성이 나쁘지 않다고 생각되어서 도입을 하기로 했습니다.

Docker

AWS Lambda에 .zip 파일을 이용하여 배포하는 방식이 아니라,

Docker Container Image를 빌드하고, 해당 Image를 AWS ECR에 올린 후에, AWS Lambda에서 해당 이미지를 가져다가 구동하는 방식으로 배포하려 했기 때문에 Docker를 도입했습니다.

물론, 개발 과정 중 서버를 띄우는 등에서의 편리함이나 DynamoDB를 쉽게 로컬에서 테스트하기 위함도 있었습니다.

배포 과정 중에 API Gateway에 접근이 안되거나, 리소스 제한 정책, 보안 그룹 등의 설정들이 제대로 파악되지 않아 이슈가 있었습니다만..

어찌저찌 해결되어 결국 위 기술들이 모두 혼합되어 지금까지 잘 작동하고 있습니다. (자세히 이야기를 남기기엔 애매하네요.. 우리 회사에도 기술블로그 글을 쓴다면.. 할만한 이야기겠네요 ㅎㅎ)

그리고 추가적인 유지보수 작업들도 잘 이어지고 있는 상황입니다.

2. Jsonb 컬럼 치워!

DB 테이블 중, 한 테이블에 Jsonb 라는 타입의 컬럼들이 많이 있는 상황이었습니다.

말 그대로 컬럼에 Json 문자열이 들어가있기 때문에, 빠르게 안에 있는 정보를 파악하거나, DB Query로 통계를 뽑는 등의 작업이 쉽지 않았습니다. (Json 문자열 안에는 배열도 있었고, 2번, 3번이 중첩된 구조도 있었으며, FK 형식의 id값도 들어가있었습니다…)

Json 문자열 구조가 들어가있다보니, 임의적으로 데이터를 마이그레이션 하기도 쉽지 않았죠.

언젠가 뜯어고치고 만다! 라는 마음을 가지고 있었는데, 올해가 가기전에 편안하게 처리를 하게 되었습니다.

하는 방법은 의외로 간단했지만 험난했습니다.

새로운 테이블 / 모델 생성
기존의 Jsonb 컬럼에 있는 데이터를 옮기는 마이그레이션 잡 생성
기존 Jsonb 데이터로 사용하고 있던 “모든 부분”을 찾아내어 새로운 모델로 대체하기

1번은 그럭저럭 기존 Jsonb 내에있는 내용을 그대로 가져다 쓰는 거기에 큰 이슈는 없었습니다. 2번은 계속해서 써오고 있는 최적화 방법으로 쉽게 해결했습니다. 단순히 Insert 또는 Update하는 것을 쪼개서 실행하는 것이죠.. 마이그레이션하는 대상이 몇 십만개씩이었기 때문에, 한번에 Insert / Update를 하게되어 마이그레이션을 하다가 서버가 힘들어하는 상황을 막으려 했습니다.

# 임의적으로 모델이나 테이블명을 바꾸었습니다

module Migrations
  class MigrateHelloModelJob < ApplicationJob
    queue_as :default

      def perform
        max_id = HelloModel.maximum(:id)

        0.upto(max_id / 10_000 + 1).each do |i|
          ActiveRecord::Base.connection.execute <<-SQL.squish
            INSERT INTO future_hello_models (blah)
            SELECT blah FROM hello_models
            WHERE hello_models.id > #{i * 10_000} AND hello_models.id <= #{(i + 1) * 10_000}
          SQL
        end
      end
  end
end

3번은 코드 검색을 더불어서, 지금까지 해당 모델들이 쓰였던 부분들을 다 순회하면서 찾아내어 TODO 코멘트를 붙여놓은 뒤, 다 정리했습니다.

그리고나서 워낙에 큰 마이그레이션이다 보니, 사용자들이 해당 서비스를 비교적 사용하지 않는 새벽에 점검 화면을 띄우고 배포를 진행하였습니다.

해커톤, 공모전 그리고 토이 프로젝트들

올해도 마찬가지로 사이드 프로젝트들을 했고, Github 링크와 간단한 설명을 정리하여 남겨보겠습니다.

TTL

Velog / 티스토리 / 깃헙 블로그 등에 흩어져 있는 TIL을 모두 모아보는 서비스

해당 프로젝트를 하면서, 처음으로 celery를 도입하여 사용해보았습니다.

하지만 celery 큐를 통해 주기적으로 사용자의 TIL 글들을 동기화하는 job을 돌리는 과정에서,

서버 리소스의 최적화가 되지 않아 주기적으로 웹서버가 죽는 이슈가 있었습니다. 최대한 job을 나누고, 코드의 최적화를 시도했지만 계속해서 웹서버는 죽었고 결국 해당 기능을 잠시 죽이는 안타까운 백그라운드가 있었습니다

Github

Sellon

실시간 중고 상품 경매 서비스

실시간성을 위한 API들을 어떻게 만들지에 대한 고민을 많이 한 프로젝트였습니다.

자세한 내용은 Github README를 참고하면 될 것 같습니다.

Github

Peacepiece

일상생활 속 환경을 위한 활동을 기반으로 가상공간을 꾸밀 수 있는 웹플랫폼

기획자이면서, 디자이너이면서, 백엔드 개발자이면서, 프론트엔드 개발자였던 개인적으로 굉장히 힘들었던 프로젝트였습니다.

Github

Army Tiger

🪖 군대 일정을 Github 프로필에 남겨둘 수 있어요

군대를 가면서, 여러 지인이 군대 일정에 대해서 물어보았습니다. 그러면서.. 한번 마지막 사이드 프로젝트로는 요걸 만들어봐야겠다는 생각이 들어서 바로 만들었습니다.

만드는 김에 다른 사람들도 쉽게 사용하면 좋지 않을까 싶어서 사용법 등도 최대한 자세하게 작성했습니다.

Github

https://github.com/shinkeonkim/army-tiger

혼세혼세한 개발 공부

올해 계속 공부해온 것, 조금씩 찍먹을 해본 것, 공부해보려고 한 것들을 나열해보려고 합니다.

군대를 다녀와서 어떤 걸, 어디서부터 시작할지 결정할때, 참고할 수 있지 않을까 싶습니다.

[인프라]

docker
- 기존에 서버에서 바로 웹 서버를 띄웠던 것들을 모두 Dockerize하여 구성하였습니다.
- 간단한 웹 서버를 구성해야할 때, 필요한 요소들을 템플릿화 하는 작업을 진행했습니다.
- 이후에는, 기본적인 auth API 및 문서화 등을 할 수 있는 템플릿까지 만들면 좋을 것 같습니다.
docker-compose
- DB, Redis 등을 설치하여 구동하지 않고, docker container를 통해 구동하고, 이를 웹서버 등과 같이 사용하기 위해 docke-compose를 이용하였습니다.
- 캐싱같은 최적화를 좀더 찾아보면서 익힐 필요가 있을 것 같습니다.
- 최근에 docker-compose를 이용하여 개발을 할 때, alpha, beta, production 환경을 나누는 과정에서 좀더 간단하게 구성할 수 있는 방법을 찾고자 했지만 실패했습니다. 결국 파일을 모두 나누어 구성했습니다. 예를 들어, docker-compose.alpha.yml 라는 식으로..
- 로컬에서 docker-compose를 이용하여 개발한 후, 이미지를 ECR에 올려서 ECS로 배포하는 작업을 시도했습니다. 이후에는 Terraform을 이용해 미리 인프라를 구성하고, 이 인프라와 함께 이 방식을 이용해보면 좋을 것 같습니다.
k8s
- 회사 동료분이 쿠버네티스를 강력 추천하여, 공부를 해보고 있었습니다.
- 먼저, Django 웹 서버를 k8s에 얹어서 사용해보려 했지만.. 공부 기간이 너무 짧았습니다.
- 군대에 가서는 쿠버네티스를 공부하고 실제로 해볼 방법이 없을 것 같아, 잠시 보류하려 합니다.
Terraform
- AWS 인프라를 구성할 때, 최대한 Terraform을 이용하여 구성하고자 했습니다.
- 인프라를 이전에 어떻게 구성했는지, 어떤 구성요소가 필요한건지에 대한 파악을 하기 쉬웠습니다.
- 다만, 어떤 오류가 발생하였을 때, Terraform이 바로바로 오류를 뱉지 않고 오랜 시간동안 기다리는 경우가 있어서 불편했습니다.
- 좀더 편한 방법을 공부해보면 좋을 것 같습니다.

[웹 프레임워크]

Rails
- 회사에서 계속 Rails를 이용한 개발을 했습니다.
- 최근에는 Service, Form 구조를 활용한 모듈 분리를 가장 많이 시도했습니다.
- 군대를 다녀와서도.. Rails가 여전히 살아있다면(제발) 토이 프로젝트로 Rails 개발을 해볼까 합니다.
Django
- 사이드 프로젝트에서는 거의 Django를 활용했습니다.
- 웹 개발을 할 때, 가장 손에 익은 게 Python / Django 조합이었습니다.
- 하지만 대부분, drf를 계속해서 사용하는 반복적인 내용이었습니다.
- Django와 더불어 새로운 기술을 더 활용하는 프로젝트를 진행하면 좋을 것 같습니다.
Koa.js
- 큰 이유 없이 제 영어 이름이 Koa이기에, 한번 이름값(?)해보고자 시작해봤습니다.
- 기존 Rails와 Django와 달리, node.js 진영의 웹 프레임워크들이 ORM을 쉽게 사용하는 방법이나, DB 마이그레이션을 효율적으로 관리하는 방법을 못 찾아서 그만두었습니다. 개발자에게 편리한 것이 많은 프레임워크들을 사용하다보니, 실망감이 컸던 것 같습니다. 나중엔 더 편해져있겠죠?
Spring
- 이후에는 Spring도 사용하지 않을까하는 막연한 생각으로 공부를 해보려 했습니다.
- 인프런에서, 인프런 아이돌님의 강의를 쭉 듣고 있습니다. 생각보다 강의가 너무 많아서, 군대에서도 계속 들어보는 장기전이 될 것 같습니다.
- 처음에 강의를 들으면서 든 생각은, 이거 Django에서는 되게 쉽게 되는데.. 였지만, 일단 참고 들어보고 있습니다.

[언어]

ruby
- Rails를 하면서, 자연스레 루비 숙련도가 늘었습니다. PS를 할때도 ruby를 이따금씩 쓰기도 했습니다.
- single line if statement, ?/! method 등의 ruby에서 편한 문법을 좋아하게 되었습니다.
- 하지만, Rails가 없는 루비는 정말 불편했습니다. 이후에 어떻게 공부를 이어나가야 할지 감이 오지 않습니다.
python
- python은 웹 개발 뿐만이 아니라 여러 분야에 다 활용했습니다. 로컬에서의 파일 정리등에도 말이죠.
- 하지만, pythonic 하게 코드를 짤 줄 아니? 라고 물어보면 No라고 답할 것 같습니다. Production Python 코드에 대한 경험이 적기도 하고, Python Senior 개발자들의 코드를 훔쳐?보는 경험을 할 기회가 별로 없었습니다. 좀더 심오하게 파고들 필요가 있습니다.
rust
- 유데미 강의를 듣고 있었습니다. 군대를 가서도 해당 강의를 계속 듣지 않을까 싶습니다.
- C/C++ 개발자들이 Rust로 옮겨가고 있는 추세로 보였고, 왜 그런지를 알고싶었습니다.
- 웹 어셈블리를 이용한 웹 개발을 진행해보고 싶었습니다.
c/c++
- 알고리즘 문제 풀이에만 활용했습니다.
- c/c++로 production 코드를 개발하고 싶지는 않습니다. c/c++은 알고리즘 문제 풀이로만 활용하고 싶고, 이 생각은 변하지 않을 것 같습니다.

[PS / 알고리즘]

아직 PS(Problem Solving) / 알고리즘 공부를 놓지 못했습니다.
주로 BOJ와 Solved.ac를 이용해 문제를 풀었습니다.
Codeforces나 Atcoder는 자신감이 부족해서 문제 수 4,000 문제와 다이아 3 달성하기 전까지는 안할려 합니다.
기본 구현 문제
- 최근에 Production 코드에 집착을 하다보니, 기본 구현 문제를 빠르게 생각하고 짜지 못하는 것 같았습니다.
- 그래서 최대한 Bronze, Silver 문제들을 가볍고 빠르게 짜는 연습을 했습니다.
문자열
- 구현 문제들을 풀면서, 많은 기본 문제를 풀게 되었습니다.
- 하지만, 기본적인 KMP, Trie 등을 활용하는 문제를 최근에 안 풀어서, 숙련도가 낮아졌습니다. 예전부터 문자열 문제에는 손이 안가는 것 같습니다.
DFS / BFS
- solved.ac 에서 lang:ko tag:dfs - @$me 라는 식으로 검색하여, 한국어 DFS 문제 중 내가 안 푼 문제를 검색하여, 난이도 순으로 쭉 풀고 있었습니다.
- 채용 코테 또는 알고리즘 대회 등에서도 DFS/BFS는 무조건 한번은 나온다는 생각이 있기 때문에, 최대한 빠르고 정확하게 짜는 연습을 해보고 있습니다.
- 생각보다 DFS가 많은 알고리즘의 기초라는 사실을 종만북을 다시 읽다가 깨닫게 되어서, 깊게 파보고 있습니다.
트리
- 트리와 쿼리 시리즈를 계속 풀어보려고 트리 알고리즘들을 공부해보고 있었습니다.
- 하지만.. 트리랑은 제 머리가 맞지 않나 싶을 정도로 안 풀렸지만요.. 일단 LCA / Sparse Table 들을 활용하는 기본 트리 문제를 다 풀어서, 배수진을 칠까 합니다.
기하
- 기하는 알면 쉽지만, 모르면 못푸는 문제가 너무 많습니다. 이차원 벡터 등의 구현체들을 하나씩 만들어두면서 활용하고 있습니다.
- 최근에 볼롤껍질, 회전하는 캘리퍼스 문제를 다시 풀어봤습니다. 역시나 알고나면 너무 쉬운 문제였습니다.
정수론
- 대학에서도 수학 공부를 별로 안했는데, 알고리즘 문제 풀겠다고 수학 공부를 하고 있는 저를 보고 참 웃겼습니다.
- 정수론 책들을 사서까지 보고 있었는데, 군대가서 아마 요 책들을 읽지 않을까.. 싶네요.. 하하..
탐색
- 몇달전에야 삼진탐색을 제대로 알게 되었습니다. 하지만 카테고리를 보지않고 “이 문제 삼진 탐색이다!”하는 연습은 더 필요할 것 같습니다. 아직 이진탐색을 알아채는 것도 좀 늦는 것 같습니다 ㅠ
DP
- DP 문제들을 보고, 와 이거 DP다! 를 알아채는 시간은 줄었지만, 빠르고 간결하게 짜는 걸 더 연습해야 합니다.
- 그리고 한번 긁어서 되는 기본적인 DP 문제들보다, 이제 DP 최적화 기법들을 공부해봐야 할 것 같습니다. 아마 koosaga 님의 글을 참고해서 더 공부해야할 것 같습니다. 세상에, 너무 공부할게 많네요.

자격증을 땄다?

COS Pro 1급 Python과 정보처리산업기사를 땄습니다.

두 자격증을 따는 데, 긴 기간을 쓰지는 않았습니다.

Cos Pro는 시험 전날에 무슨 문제가 나왔었나 찾아보는 정도였고,

정보처리산업기사는 필기 한달, 실기 2주정도 자격증 책을 보고 공부(라고 하고 암기)했습니다.

기존에 알고리즘이나 CS를 계속 공부하고 있던지라 그렇게 어렵지는 않았습니다.

AWS 자격증도 따고 가고 싶었는데, 점점 미루고 미루다가 못 따고 가네요..

결론

올해는 일 / 사이드 프로젝트 / 알고리즘 공부 / 유튜브, 넷플릭스 / 잠 의 반복이었지 않나 싶습니다.

곧, 군대에 입대합니다. 내년에는 회고록을 쓸 수 있을지 잘 모르겠습니다.

군대에 있으면서 시간이 날 때마다 개발 공부를 하고는 싶습니다.. 하게 된다면 그 내용들을 정리하는 글을 써봐도 좋을 것 같습니다.

아무튼 다치지 않고 군대 잘 다녀오겠습니다.

충성.

[BOJ] 16942 문자열 접기

koa (김신건) — Thu, 05 May 2022 03:16:14 GMT

문제 요약 및 풀이

16942번: 문자열 접기

주어지는 문자열을 접어서, 같은 문자열로만 이루어지는 문자열을 만들어내면 된다.

문제에서 주어지는 예시를 쭉 보다보면, 한가지 사항을 발견할 수 있다.

만들어내는 문자열의 각 문자의 원래 문자열에서의 위치는 서로 홀수만큼 차이가 난다. (사이에 있는 숫자 갯수를 말하는 것이 아닌, 위치의 차이다.)

따라서, 최대한 같은 문자를, 위치가 홀수만큼 차이가 나는 문자들을 선택하면 된다.

물론 하나하나 따져가면 시간초과가 뜰테니.. DP로 풀어나갔다.

풀이 코드

#include <bits/stdc++.h>

#define for1(s,n) for(int i = s; i < n; i++)
#define for1j(s,n) for(int j = s; j < n; j++)

using namespace std;

string s; // 입력받을 문자열
int d[1100], ans; // d: DP 배열, d[i] = i번째 문자를 사용했을 때, 만들 수 있는 최대 문자열 길이

int main() {
  ios::sync_with_stdio(0);cin.tie(0);cout.tie(0);
  
  cin >> s;

  int n = s.length();

  for1(0, n) d[i] = 1; // 어찌되었든, 문자열을 접지 않으면, 모든 문자가 1로 가능하다.

  for1(1, n) {
    for1j(0, i) {
      if((i - j) % 2 && s[i] == s[j]) {
        // 홀수 간격이고, 문자가 같은 경우
        d[i] = max(d[i], d[j] + 1);
      }
    }
  }

  for1(0, n) {
    // DP 배열에서 최대값을 뽑아낸다.
    ans = max(d[i], ans);
  }

  cout << ans;
}

[BOJ] 19718 King's Inspection

koa (김신건) — Sat, 08 Jan 2022 09:33:10 GMT

문제 요약 및 풀이

19718번: King’s Inspection

문제 상황을 요약하면 다음과 같다.

자연수 a,b,c 가 주어진다.

주어진 자연수 a, b, c중 2개를 골라 1씩 더할 수 있다.

이때, 모든 숫자를 같게 만들기 위한 최소 덧셈 횟수는 몇번인가?

풀이 코드

문제를 보자마자, 바로 드는 생각은

그때 그때 가장 작은 숫자 2개를 골라 1씩 더해주면서 카운팅하면 되지 않을까? 였다.

그래서 바로 아래와 같은 풀이를 작성했다.

l = [int(input()) for i in range(3)]
cnt = 0
while not l[0] == l[1] == l[2]:
  l.sort()
  l[0] += 1
  l[1] += 1
  cnt += 1

print(cnt)

(브론즈 2티어 문제라서 그렇게 어려운 풀이를 유도하지는 않을 거라 생각했고, 범위도 신경쓰지 않는 풀이를 작성해버렸다.)

역시 위 풀이는 시간초과가 발생했고, 시간초과를 보고 나서 a, b, c의 최대 범위가 5억이라는 것을 확인했다.

그래서 이제 간단하게 또 생각을 틀었다.

가장 작은 2개가 서로 같지 않다면 그 두 개를 격차만큼 더해주고, 같다면 가장 큰 수와의 격차를 더해주면 되지 않을까?

그리고 아래와 같은 풀이를 작성했다.

l = [int(input()) for i in range(3)]
cnt = 0
while not l[0] == l[1] == l[2]:
  l.sort()
  if l[1] != l[0]:
    diff = l[1] - l[0]
  else:
    diff = l[2] - l[1]
  l[0] += diff
  l[1] += diff
  cnt += diff

print(cnt)

하지만… 여기서 끝나지 않았다..

바로 아래와 같은 케이스에서 너무나 늦게 답이 수렴되었기 때문이다.

1
499999999
500000000

다시 한번 생각을 틀었다.

무조건 작은 2개를 뽑는 게 아니라,

먼저 큰 두 숫자의 격차를 더해주고, 그 두 숫자가 같다면(격차가 0이라면) 작은 2개의 격차를 더하자.

l = [int(input()) for i in range(3)]
cnt = 0
while not l[0] == l[1] == l[2]:
  l.sort()
  diff = l[2] - l[1] if l[2] - l[1] else l[1] - l[0]
  l[0] += diff
  l[1] += diff
  cnt += diff

print(cnt)

단순하게 어떤 숫자를 선택해야 격차를 빨리 좁혀서 더해나갈 수 있을지 생각을 했고, 요렇게 AC를 받았다.

끝

[TIL] Window size에 따라 속도가 달라지는 CSS Animation 바로잡기

koa (김신건) — Sun, 19 Dec 2021 09:38:16 GMT

문제 상황

새벽에 어쩌다 떠오른 아이디어로 짧고 굵게 토이 프로젝트를 진행해보고 있다.

Github repo

Site page

바로 Can you catch “Circle” 이다. 뭐.. 줄이자면 CCC 일 것 같다. ㅋㅋㅋ

굉장히 단순한 웹 페이지 프로젝트이다.

단순히 화면에 있는 “Circle”을 잡으면 된다.

아직은 좌우로 움직이는 기믹밖에 없지만, 점차 추가해보려고 한다.

아무튼, 방금 언급한 “좌우로 움직히는 기믹”을 만들던 중, 아래와 같은 코드에서 한가지 생각지도 못했던 이슈가 발생했다.

.move-left-to-right {
  animation: just-left-to-right 20s linear infinite;
  -webkit-animation-name: just-left-to-right;
  -webkit-animation-duration: 20s;
  -webkit-animation-timing-function:linear;
  -webkit-animation-iteration-count: infinite;
}

@keyframes just-left-to-right {
  0% {
    transform: translateX(-45vw);
  }

  50% {
    transform: translateX(45vw);
  }

  100% {
    transform: translateX(-45vw);
  }
}

@-webkit-keyframes just-left-to-right {
  0% {
    -webkit-transform: translateX(-45vw);
  }

  50% {
    -webkit-transform: translateX(45vw);
  }

  100% {
    -webkit-transform: translateX(-45vw);
  }
}

바로 모바일과 PC에서의 화면 크기 차이 때문에 Circle이 다른 속도로 움직인다는 것이다.

왤까? 오랜만에 간단한 물리 식 $$ V(속력) = D(거리) / T(시간) $$ 을 떠올려보자.

여기서 거리는 $$ 90vw * 2 $$ 일 것 이다.(왕복 거리) 그리고 시간은 20초이다.

한가지 의문이 들 수 있다. 어? 수치가 정해져있는데, 속력이 고정되어있는 것 아닌가요?

아니다

vw 는 화면 크기에 따라 달라지는 가변단위 이기 때문이다.

따라서, 자연스럽게 화면 크기가 커지면 속력이 증가하고, 화면 크기가 작아지면 속력이 감소한다.

그래서 모바일에서 보면 굉장히 굉장히 느려지는 이슈가 발생한 것이었다.

그럼 어떻게 고쳤나?

여러 가지로 시도해봤지만 SCSS에서 가져온 window width를 시간 개념으로 다시 convert 하는 방법을 찾지 못했다.

그래서 해당 프로젝트는 Vue.js 프로젝트였기 때문에, js 단에서 속도를 정의하고 이걸 template에 주입하는 방식으로 해결했다.

솔직히 마음에 드는 방법은 아닌지라, 조금이라도 더 좋은 방벙을 발견하면 고칠 것 같다.

아래 코드가 해당 문제를 해결한 수정 내용이다. (해당 글과 상관없는 내용과 위에 첨부한 style 부분은 생략했다.)

<template>
  <!-- mdx-component: Circle -->
</template>

<script lang="ts">
import {
  computed,
  defineComponent, inject, onMounted, ref,
} from 'vue'
import Circle from '@/components/Circle.vue'

export default defineComponent({
    name: "JustMovingPage",
    setup() {
      const VELOCITY = 150;
      const windowWidth = ref(1);
      const compuetedAnimationDuration = computed(() => windowWidth.value / VELOCITY);

      onMounted(() => {
        windowWidth.value = window.innerWidth;
        window.onresize = () => {
          windowWidth.value = window.innerWidth;
        }
      })

      return {
        windowWidth,
        compuetedAnimationDuration,
      } 
    },
    components: {
      Circle
    }
})
</script>

참고한 글

Stackoverflow: Set reactive screen width with vuejs

[TIL] Django Alphanumeric Random String 생성하기

koa (김신건) — Tue, 14 Dec 2021 12:40:53 GMT

Django에서 랜덤 문자열 쉽게 만들어내기

웹 서비스를 구성하다보면, 종종 랜덤 문자열을 뽑아내야 하는 경우가 있다.

이번에는 사용자가 직접 가입하지 않고 초대를 받아 가입하는 서비스를 구성하던 중에, 임의적으로 유저의 username을 설정해야 했다. 이전에는 random module을 이용해 작성했지만, 이번에는 Django에서 지원하는 모듈로 작성하고자 찾아봤다.

get_random_string

바로, get_random_string이다.

아래와 같이 import 하면 된다.

from django.utils.crypto import get_random_string

사용방법

length를 무조건 넘겨주어야 한다.
```
get_random_string(length=10)
```
allowed_chars를 이용해서 랜덤으로 뽑아낼 문자의 후보를 한정할 수 있다.
```
get_random_string(length=10, allowed_chars="ABCD")
```
번외로 말하면 allowed_chars는 아래와 같이 하드코딩되어서 들어가고 있는 구조이다.
```
RANDOM_STRING_CHARS = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'

def get_random_string(length=NOT_PROVIDED, allowed_chars=RANDOM_STRING_CHARS):
```
따라서, 아래와 같이 allowed_chars를 한글로 대체하여 한글 랜덤 문자열을 자연스럽게 뽑아낼 수도 있다.
```
get_random_string(3, "가나다")
```

대학교 2학년 휴학생, 회사에서 2021년 회고록

koa (김신건) — Thu, 09 Dec 2021 00:00:00 GMT

한달, 아니 적어도 분기마다 회고록을 쓰려고 했지만.. 항상 키보드를 잡다가, 포기해왔다. 하지만 올해는 마무리 지어야하기에 끄적여본다.

🚀 왜 휴학하고 회사를 다니게 되었을까?

전 19학번으로 대학교에 입학했습니다.

그리고 우연히, 정말 우연한 기회로 그렙이라는 회사에서 1학년 여름방학 인턴을 하게 되었었습니다. 알고리즘 컨텐츠 제작자로 근무를 했고, 그렇게 1학년 겨울방학, 2학년 여름방학까지 알고리즘 컨텐츠 제작자로 근무했습니다.

그러던 중,

알고리즘 컨텐츠 제작자로 근무를 하는 건, 나에게 의미가 있을까?

지금 하고 있는 이 경험은 나에게 새로운 자극을 주는 경험일까?

라는 의문이 들었습니다.

그리고 2학년 겨울 방학에는 꼭 "개발자" 인턴을 경험해보자 생각을 했고, 바로 도전해봤습니다. 여러 곳에 서류를 넣었고 면접을 봤었지만, 결국 한번 더 가장 좋은 조건과 기회를 제공해주신 그렙에서 2020년 12월 부터 개발자로 근무를 하게 되었습니다.

근무를 시작하기 전, 2학기 기말고사를 마무리 짓고 부리나케 그렙에서 사용하는 Ruby on rails 기술스택을 익히기 시작했습니다.

Ruby on rails을 익히기 위해서, 책도 찾아보고, 여러 글도 찾아보았지만, 결국 가장 좋은 것은 공식 문서였습니다. 책과 공식문서를 읽어가면서 일주일동안 Ruby on rails 스택을 익혔습니다. 어쩌면 이전부터 계속 사용하던 주 스택이 Django였던 지라 익숙함을 느끼며 금방 습득했던 것 같습니다.

인턴으로 입사한 후, Ruby on rails를 활용하는 간단한 업무를 주셨고 빠르게 내부 레거시를 습득하면서도 Ruby on rails를 공부할 수 있는 기회를 얻을 수 있었습니다. (이후엔 여러 주니어 개발자분들이 비슷한 시기에 입사하셔서 같이 레일즈스터디를 이어갔고, 이게 큰 도움이 되었습니다.)

그렇게 계속 열심히 일을 하던 중에 1월 쯤, 경영진의 정규직 제안을 받게 되었습니다. 여기서 굉장히 고민을 많이 하게 되었습니다. 1년에서 2년 가량의 경력을 대학교 중간에 쌓을 수 있는 기회가 생각보다 크게 다가왔고, 그렇기엔 아직 졸업을 못한 저 자신이 너무 부담스럽기도 했습니다.

그래도.. 지금 당장 제가 재밌고, 할 수 있는 것을 하자는 생각으로 학교를 휴학하고(때려치우고 ?!) 2021년을 그렙에서 보내게 되었습니다. 🥰

🌱 1년동안 어떻게 성장했나?

🦁 아직 손에 쥐고 있었다. 동아리 활동

학교를 갑작스럽게 휴학하게 되면서, 원래 하고 있던 동아리 활동에 영향을 주게 되었습니다. 2021년에는 국민대학교 멋쟁이사자처럼 운영진 대표로서 역할을 다하기로 하였었지만, 학교를 다니지 않게 되면서 적지 않은 영향을 주게 되지만, 코로나의 영향으로 비대면 활동을 이어가게 되면서 회사와 동아리 활동을 이어갔습니다.

먼저, 국민대학교 멋쟁이사자처럼에서 주마다 HTML, CSS, Django 관련 세션을 이어갔고, 이를 준비하는 과정에서 다시 한번 Django에 대한 지식을 점검할 수 있었습니다. 그리고 다른 사람들에게 제 지식을 전파하는 경험을 하게 되었습니다.

🥊 재미있는 프로젝트를 많이 해보자.

전 친구들이 취미가 뭐라고 물어보면, 뭔지 알잖아? 개발 이라고 답해왔는데, 이번년도에도 시간이 날때마다 토이 프로젝트를 하려고 해왔습니다. 일단 정리 겸, 한번 나열해보겠습니다. 🧐 나열을 해보니, 생각보다 올해 일단 많은 프로젝트/아이디어를 내놓으려고 했던 것 같습니다.. 내년엔 조금 더 완성도 있는 프로젝트들을 내놓아보는 걸 목표로 해보고 싶습니다.

Django Coffee Model

github: django-coffee-model 오픈소스 프로젝트

timestamps를 조금더 쉽게 사용할 수 있게 만들어주는 단순한 django 라이브러리 입니다. pypi에 배포하였고, 이후 제가 만드는 프로젝트들에서도 사용하면서 유지보수를 했습니다. (물론 첫번째 오픈소스라서 나중에 다 갈아엎고 싶을 정도로 버전 관리를 엉망으로 한 것 같습니다.)

팩토리 유튜버의 영상 삭제를 막아보자!

github: prevent-factory-video-deletion 프로젝트

유튜버 팩토리 님의 영상을 보고 시작하게 된 프로젝트입니다.

영상의 주요 내용은, 해당 영상에 60분마다 댓글이 달리지 않으면 영상을 삭제하겠다는 내용입니다. 이걸 보고 전, 어? 깃헙 액션에 cron job 기능도 생겼는데, 이걸 한번 써서 크롤링해볼까? 라는 생각을 했고, 바로 코드로 옮겨봤습니다. 하지만.. 로컬에서 작동하던 코드가 깃헙 액션으로 옮겨지니 크롤링이 잘 되지 않는 모습을 보였습니다. ㅠㅠ. 유튜브 사이트 내부에서 크롤링을 막기 위해 무언가를 해둔 것 같았지만.. 해결하지 못하고 이 프로젝트는 멈추게 되었습니다.

Github action을 이용해 슬랙에 주기적으로 메세지를 보내보자!

github: kmu-likelion-slack-noti-action 프로젝트

이전 글에서 다루었던, 프로젝트입니다. 아래 글을 참고해주세요.

글 보러 가기

무야~호

github: mooyaho 프로젝트

2021년 초, 한동안 무야호 밈이 유행했었습니다. 한번 짤생성기를 경험삼아 Vue.js로 간단하게 만들어볼까 하고 시도한 프로젝트입니다. 그냥 살짝 맛만 보고.. 더이상 개발하지 않아서, 조금 아쉬운 프로젝트인 것 같습니다.

아직도 돌아가고 있는 허접한 사이트 보러가기 - https://mooyaho.me/

대학생 멋쟁이사자처럼 프로필을 이쁘게 보여주는 프로젝트

github: likelion-badge 프로젝트

해당 프로젝트는 Github README에서도 언급되어있듯이 mazassumnida 프로젝트를 보고 영감을 받아 진행해본 프로젝트입니다.

단순히, 멋쟁이사자처럼 기수와, 대학교 영어명을 param으로 넘기면 원하는 뱃지를 svg로 얻어내는 사이트를 만들고 배포했습니다.

해당 배지를 주로 Github Profile README나 노션 이력서 등에 첨부하는 것을 의도한 프로젝트입니다.

해커톤을 운영하면서, 정해진 기간에 개발된 프로젝트가 맞는지 알아야 했다!

github: github-repository-start-date-checker

하반기 중에, 멋쟁이사자처럼 대학교들이 모여 연합해커톤을 여는데, 어흥올림픽 이라는 해커톤 운영진으로 참가하게 되었습니다.

해커톤 운영 규칙중, XX월 OO일 이전부터 시작된 프로젝트는 인정하지 않습니다. 라는 식의 규칙이 있었고, 이를 검증할 방법이 필요했습니다.

다른 운영진분께서 크롤링을 이용한 코드를 작성해주셨고, Github API를 이용하는게 더 편하지않을까? 라는 생각이 들어서 이를 리팩토링하여 프로젝트를 간단하게 구성하고 실제로 활용했습니다.

바빠도 해커톤은 참가해야지

github: 대동먹지도 프로젝트

멋쟁이사자처럼 중앙 해커톤을 멋쟁이사자처럼 구성원분들과 같이 참가하게 되었고, 대동먹지도라는 프로젝트를 진행했습니다. 정말 사소한 먹거리들을 서로 공유하는 플랫폼을 만들어보자는 아이디어였고, 아쉽게도 수상하지는 못했습니다.

백엔드는 Django,(Django rest framework) 프론트엔드는 React,js로 구성했던 프로젝트입니다.

저는 백엔드, 프론트엔드 전반적인 구조를 구성하고, 각 환경을 배포하는 역할을 맡았습니다.

이 플젝을 하면서…

Django Rest Framework를 전보다 훨씬 빡세게 써볼 수 있었습니다.(문서화, Class based View 등등..)
React.js에서는 Redux를 통한 상태관리를 어떻게 더 잘할 수 있는지 알 수 있게 되었습니다.

⌨️ 코드 리뷰는 정말로 소중했다.

1년동안 그렙을 다니면서, 절 가장 성장시킨 존재는 코드 리뷰인 것 같습니다.

이전에는 코드 리뷰는 어떻게 하는거지? 왜 하는거지? 등등 머리속에 의문만이 가득한 존재였지만, 지금은 꼭 있어야 하는 존재로 저에게 남았습니다.

먼저, 코드 리뷰를 하면서 받았던 피드백들을 따로 모아두고, 기억하면서 비슷한 상황이 나왔을 때, ‘아, 이전엔 이렇게 했었지?’ 하는 도움말이 생겼습니다.

그리고 어떻게 효율적으로 짤 수 있을지, 어떻게 다른 사람이 봐도 이해가 되는 코드 구조를 구성할 수 있을지에 대한 고민을 하는 능력을 기를 수 있었습니다.

또한, 저의 코드 뿐만 아니라, 다른 사람이 구성한 코드를 볼 때도 새로운 지식들을 배울 수 있었고, 실제로 배운 것들을 써먹기도 하면서 좋은 코드들을 습득하는 기회를 가질 수 있었습니다.

(다음 회사, 다다음 회사를 가더라도, 전 꼭 코드 리뷰가 있고 자유로운 개발문화를 가진 회사를 가야겠다는 다짐도 하게 되었습니다.)

🗓 1일 1 OO

올해까지 해서, 현재 대력 2년간 1일 1커밋을 이어왔습니다. (아직 올해가 다 가지 않았지만..)

대략 2019년 12월 부터 시작한 1일 1커밋을 지금까지 이어온 것이 되게 뿌듯하네요.

주변에서, 이따금 계속 1일 1커밋 하기 힘들지 않냐라는 질문을 주시긴 합니다.

저도 처음 1일 1커밋을 시작했을 때는 너무나 힘들었던 것 같습니다.

"할 커밋이 없었으니까요."

아는 것도 얼마 없고, 프로젝트는 당연히 진행하고 있지 않았습니다.

그래서 무작정 알고리즈 문제를 풀고 이것부터 커밋하는 습관을 들이기 시작했습니다. 점차 커밋에 대한 부담감이 줄어들었고 여러 지식을 얻어가면서 프로젝트도 시작해갔습니다.

그렇다보니 요즘 평소 제 생활을 하다보면 어느새 하루에 1일 1커밋이 되어있는 것 같습니다. 평일 낮에는 일을 하고, 밤에는 프로젝트를 하고, 주말에는 프로젝트/공부를 하니까요.

그리고 1일 1커밋을 이은 1일 1문제를 시도하고자 하고 있습니다.

solved.ac에서는 백준 문제를 풀고 이를 스트릭으로 나타내주고 있습니다. 이를 이용해서 잔디를 또 채워보고 있습니다.

이전에 1일 1커밋을 했을 때처럼, 지금은 쉬운 문제들로만 시도해보고 있습니다. 처음부터 어려운 문제들로 채워나가기엔 저에게 너무나 큰 스트레스를 줄 것 같았습니다.

지금은 습관만 가지자는 마음으로 브론즈 문제들로 채워가고 있고, 점차 풀 문제가 사라지면 난이도를 하나씩 올려가면 문제들을 계속 풀어나가보려 합니다.

내년엔 무슨 성장을 할까?

Django/Rails/AWS를 좀 더 깊게 파보자.

내년엔 조금 더 깊게 Django/Rails/AWS를 파보려고 합니다.

Django/Rails에 대해서는 아직까지 계획이 크게 없지만 더 Production에 맞는 코드를 구성하는 방법에 대해서 파볼까 계획 중입니다.

AWS는 관련 자격증을 따면서 공부하려고 합니다. 하지만..

안타깝다.

안타깝게도 내년엔 성장을 할 수 있는 기간이 짧을 것 같습니다.

저는 현역 판정을 받은 21세 (2021 기준)이고, 군대를 더이상 미룰 수 없다는 판단을 했고, 하반기 혹은 내후년 상반기 중에는 군대를 가야할 것 같습니다.

자격증을 따자.

앞서 말한 군대를 위해, 여러 자격증을 딸 생각이다. 단순히 군대를 위한 자격증만은 아니고, 이후 내 커리어를 위해서도 필요하겠다 싶은 자격증들을 하나씩 모아두려고 한다.

Cos Pro
정보처리산업기사
AWS Certified Developer - Associate
SQLD
기타..?

조금 더 기록을 할 수 있는 방법이 없을까?

군대를 가더라도.. 아마 휴대폰은 쓸 수 있을 것 같고.. 미래의 저를 위해서 휴대폰에서도 쉽게 제가 현재 가지고 있는 지식을 계속 볼 수 있게 만들어보고 싶습니다.

아마 블로그에 글을 계속 쓰는 것으로 할 것 같지만.. 조금 더 부담감없는 방법이 없을까? 생각을 더 많이 해봐야 할 것 같습니다.

결론

올해 주니어 개발자로서 성장을 계속 해보자는 마음으로 살아온 것 같습니다.

내년에는 더 깊은 분야로 빠져드는 공부를 해보고 싶지만, 이제 새로운 도전을 해야 하는 시점에 왔기에 어떤 변곡점이 생길지 모르겠습니다.

지금처럼 행복하고 만족스러운 개발을 이어가는 개발자가 되고 싶습니다.

끝.

[TIL] 슬랙 웹훅과 깃헙 액션을 이용해 알림 봇 만들기

koa (김신건) — Thu, 18 Nov 2021 11:02:09 GMT

계기

국민대학교 멋쟁이사자처럼에서 슬랙을 사용하기로 했고, 내부 스터디인 줌터디도 슬랙에서 활동을 하게되었다. 이때, 특정 시간마다 회고글을 쓰라는 메세지가 주기적으로 오는 봇이 있으면 좋겠다고 생각이 들었다.

그래서 바로 워크플로빌더를 켰지만… 무료 플랜에서는 사용할 수 없었다…

그래서 직접 만들자! 결심했다.

일단 먼저 슬랙에 메세지를 보내기 위해, Slack Incoming Webhook을 설정했다.

큰 이슈는 없고, 딱 Webhook URL만 알아내면 된다. (간단해서.. 스킵..)

그리고 이제 주기적으로 메세지를 보내는 환경을 만들어야 한다.

cron job을 실행할 서버가 따로 있을까 고심하던 중, Github Action을 떠올렸고 구글링을 해서 간단한 파이썬 프로젝트를 구성했다.

.github/workflow/python-apps.yml

name: Noti Zoom Study

on:
  schedule:
    - cron: "0 11 ? * SUN"
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Set up Python 3.10
      uses: actions/setup-python@v2
      with:
        python-version: "3.10"
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
    - name: Noti
      run: python actions/zoom_study_notice.py
      env:
        ZOOM_STUDY_WEBHOOK_URL: ${{ secrets.ZOOM_STUDY_WEBHOOK_URL }}

actions/zoom_study_notice.py

import os, sys

sys.path.append(os.path.dirname(os.path.abspath(os.path.dirname(__file__))))

from dotenv import load_dotenv
from api.slack import post_text

load_dotenv(verbose=True)

ZOOM_STUDY_WEBHOOK_URL = os.environ.get("ZOOM_STUDY_WEBHOOK_URL")

ZOOM_STUDY_NOTICE = """<!channel> 이번주가 지났습니다.
1. 한 주동안 달성하고자 하는 목표를 적어주세요.
2. 지난 일주일동안의 목표 달성률과 그 이유를 적어주세요
[예시]
😀 이번주 목표
  - 도메인 주도 설계 책 4챕터까지 읽기
🤗 지난주 달성
  - 75/100, 3챕터까지 다 읽고자했지만, 못 읽었다.
😉 목표의 방향은 정해져있지않아요.
🙃 스스로 할 수 있는 목표치를 정해보아요.
😇 매주 목표를 정하고, 점검해보아요
🥰 목표가 많다면 여러개를 적어도 돼요
"""


if __name__ == "__main__":
    ret = post_text(ZOOM_STUDY_WEBHOOK_URL, ZOOM_STUDY_NOTICE)
    print(ret)

참고한 블로그

Github Repository

이번에 cron을 쉽게 만들려고 알아보던 중에, cronmaker라는 사이트를 처음 알게 되었다. cron 정규 표현식을 더 쉽게 만들어준다.

메세지가 잘 온다!

[BOJ] 15087 DRM Messages

koa (김신건) — Mon, 08 Nov 2021 06:42:51 GMT

문제 요약 및 풀이

15087번: DRM Messages

python에서 ord, chr을 잘 활용하자.
단계별로 최대한 함수를 나누어 구현해보면, 더 쉽게 문제가 해결된다.

풀이 코드

def get_sum(s):
    return sum([ord(i) - 65 for i in s])


def rotate_chr(s, n):
    return chr((ord(s) - 65 + n) % 26 + 65)


def divide(s):
    return s[: len(s) // 2], s[len(s) // 2 :]


def rotate(s, n):
    return "".join([rotate_chr(i, n) for i in s])


def merge(a, b):
    return "".join([rotate_chr(a[i], ord(b[i]) - 65) for i in range(len(a))])


s = input()
s1, s2 = divide(s)

print(merge(rotate(s1, get_sum(s1)), rotate(s2, get_sum(s2))))

[BOJ] 9881 Ski Course Design

koa (김신건) — Sat, 23 Oct 2021 08:05:14 GMT

문제 요약 및 풀이

9881번: Ski Course Design

문제를 간단?하게 요약/번역해보자.

땅의 높이를 나타내는 숫자 n개가 주어진다.
각 땅의 높이를 낮추거나 높일 수 있을 때, "가장 높은 땅의 높이"와 "가장 낮은 땅의 높이"의 격차를 17보다 작거나 같게 만들어야 한다.
이때, 총 비용을 구해야 한다. 단, 각 땅의 높이를 k만큼 낮출 때 비용은 k*k이다.

얼핏보면 심플해보이지만, 아래 테케와 같은 경우

작업 후, 전체 높이가 [4, 4, 20, 21, 21] 와 같이 될 때 최소다. 특정 최소 지점과 최대 지점만 잡고 계산하면 안 된다는 의미이다.

(제 풀이는 다른 분들의 풀이와 다른 것 같다; 문제 풀이 보기를 하니 제가 너무 꼬아서 풀었던 것 같다 ㅠ)

그래서 일단 정렬을 기본으로 하고,

두 왼쪽, 오른쪽 구간을 설정하고, 각각의 구간에 포함되어있는 숫자는 모두 같다고 가정했다.

왼쪽 구간은 무조건 증가시키는 구간, 오른쪽 구간은 무조건 감소시키는 구간으로 생각하였고, 아직 왼쪽 구간과 오른쪽 구간의 격차가 17 이상이라면 증가/감소 액션을 수행했다.

증가, 감소를 수행하는 기준은 (증가/감소시키므로서 될 코스트 - 현재까지의 코스트)를 구해서 더 코스트가 작은 액션을 수행하게 했습니다.

풀이 코드

n = int(input())
height = sorted([int(input()) for i in range(n)])
cost = [0]*n

l = 0 # 왼쪽 구간은 오른쪽 끝만 알고 있으면 된다.
r = n-1 # 오른쪽 구간은 왼쪽 끝만 알고 있으면 된다.

# 초기 왼쪽 구간을 설정한다.
for i in range(n):
  if height[i] == height[0]:
    l = i

# 초기 오른쪽 구간을 설정한다.
for i in range(n-1, -1, -1):
  if height[i] == height[-1]:
    r = i


while l < r and height[r] - height[l] > 17:
  l_cost = 0
  r_cost = 0

  # 왼쪽 구간을 증가시킴으로서 발생하는 비용 측정
  for i in range(l+1):
    l_cost += (cost[i]+ 1)**2 - cost[i]**2

  # 오른쪽 구간을 감소시킴으로서 발생하는 비용 측정  
  for i in range(n-1, r-1, -1):
    r_cost += (cost[i]+1)**2 - cost[i]**2

  if l_cost < r_cost:
    # 왼쪽 구간의 비용이 작은 경우 증가 액션 수행
    for i in range(l+1):
      cost[i] += 1
      height[i] += 1
  else:
    # 오른쪽 구간의 비용이 작은 경우 감소 액션 수행
    for i in range(n-1, r-1, -1):
      cost[i] += 1
      height[i] -= 1

  # 숫자를 증가시킴으로서, 구간이 확장되어야 하는지 검사
  for i in range(n):
    if height[i] == height[0]:
      l = i
  
  # 숫자를 감소시킴으로서, 구간이 확장되어야 하는지 검사
  for i in range(n-1, -1, -1):
    if height[i] == height[-1]:
      r = i

print(sum([i*i for i in cost]))

끝

[BOJ] 14427 수열과 쿼리 15(2)

koa (김신건) — Sun, 17 Oct 2021 02:42:08 GMT

문제 요약 및 풀이

14427번: 수열과 쿼리 15(2)

boj-14427 글에서 평방 분할을 이용한 풀이를 끄적였는데, solved.ac 난이도 기여를 하러 들어갔더니

대부분의 의견이 세그먼트 트리 기준으로 난이도 기여를 하지말아달라는 것이었다.

왤까 생각을 해보니.. 이 문제는 priority_queue로 간단하게 해결된다.

일단, 다른 수열과 쿼리 문제와 다르게 이 문제는 특정 구간을 구하는 쿼리가 아닌 전체 구간의 최소값을 구하는 것이다.

따라서 세그먼트 트리나 평방 분할같이 특정 구간의 대표값을 알아내는 쿼리 자료구조/알고리즘을 쓸 필요가 없었다.

그냥 값들을 모조리 priority_queue에 넣어두고, 현재 해당 인덱스에 들어가있는 값과 priority_queue의 top()의 값이 제대로 성립하는지 확인하면서 top()값들을 출력하면 되었다.

풀이 코드

#include <bits/stdc++.h>

#define for1(s,n) for(int i = s; i<n; i++)

using namespace std;
typedef long long ll;
typedef pair<ll, ll> pll;

priority_queue <pll, vector<pll>, greater<pll>> Q;
ll N, M;
ll ar[110000];
ll q, a, b;

int main() {
  ios::sync_with_stdio(0);cin.tie(0);cout.tie(0);
  cin >> N;
  for1(0, N) {
    cin >> ar[i];
    Q.push({ ar[i], i});
  }

  cin >> M;
  while(M--) {
    cin >> q;
    if(q == 1) {
      cin >> a >> b; a--;
      ar[a] = b;
      Q.push({b, a});
    } else {
      while(!Q.empty() && ar[Q.top().second] != Q.top().first) {
        Q.pop();
      }
      cout << Q.top().second + 1<< "\n";
    }
  }
}

[BOJ] 14427 수열과 쿼리 15

koa (김신건) — Sun, 17 Oct 2021 01:52:11 GMT

문제 요약 및 풀이

14427번: 수열과 쿼리 15

다른 풀이 보러가기(풀고 나서, 더 생각하니 이 풀이는 너무나 닭 잡는데 소칼을 쓴 격이 되었다. )

오랜만에 세그먼트 트리를 복습하고자 본 문제였지만, 결국 제일 좋아하는 알고리즘이 된(?!) sqrt decomposition을 이용해 풀게 되었다.

sqrt decomposition은 되게 어려워보이지만, 정말 간단한 아이디어로 어려운 상황을 해결할 수 있게 해준다.

먼저 문제를 요약해보자.

최대 길이가 10만인 수열 A가 주어지고 최대 10만인 M개의 쿼리에 대해서 수행해야 한다.
주어지는 쿼리는 아래 2개다.

1. i번쨰에 있는 숫자를 v로 변경해라.
2. 전체 수열의 최솟값의 인덱스를 출력하라.

한번 모든 쿼리를 나이브하게 처리한다고 생각해보자.

10만개의 숫자 중 최솟값을 최대 10만번 알아내야 하기 때문에, 10만 x 10만으로 100억이 된다. 무조건 시간초과가 뜬다. (질문 목록을 보니 예전에는 나이브하게 풀리는 허점이 있었던 것 같긴 하다. 테케 추가되었으니 안 될듯?)

그럼 여기에 sqrt decomposition 아이디어를 접목해보자.

평방 분할의 큰 아이디어는 여러 값들의 대표값을 sqrt(N)개 만큼 뽑아놓고 그값들을 갱신하고, 활용하자 라고 할 수 있다.

N개의 값이 있고, $$ \sqrt N $$ 개만큼을 묶어서, $$ \sqrt N $$ 개 만큼의 대표값을 만든다.

여기서 대표값은 $$ \sqrt N $$ 개 수의 최소값 및 최소값의 인덱스일 것이다.

한번 쿼리를 처리해보자.

1번 쿼리를 복잡하게 생각할 필요없이 그냥 $$ \sqrt N $$ 개의 숫자를 순회하면서 대표값을 갱신하면 된다. (단, 해당 대표값은 바꿔야 하는 i번째 숫자가 포함된 구간의 대표값을 말하는것이다.)

2번 쿼리는 정말 간단하게 모든 구간의 대표값을 순회하면서, 최소값과 최소값을 찾으면 된다.

두 쿼리의 시간 복잡도는 $$ \sqrt N $$ 일 것이고, $$ N * \sqrt N $$ 는 최대 대략 10만 x 300 정도이고, 3000만은 충분히 1초내에 연산된다.

풀이 코드

#include <bits/stdc++.h>

#define for1(s,n) for(int i = s; i<n; i++)
#define INF (ll)1e11

using namespace std;
typedef long long ll;

ll mo[110000];
ll mo_idx[110000];
ll ar[110000];
ll N, sq, Q, q, a, b;

int main() {
  ios::sync_with_stdio(0);cin.tie(0);cout.tie(0);
  
  cin >> N;
  
  fill(mo, mo+N, INF);
  fill(mo_idx, mo_idx+N, -1);
  for(sq = 0; sq*sq < N; sq++);

  for1(0, N) {
    cin >> ar[i];
    if(mo[i/sq] > ar[i]) {
      mo[i/sq] = ar[i];
      mo_idx[i/sq] = i;
    }
  }

  cin >> Q;
  while(Q--) {
    cin >> q;
    if (q == 1) {
      cin >> a >> b;
      a--;

      ar[a] = b;
      ll partition = a/sq;
      mo[partition] = INF;
      mo_idx[partition] = -1; 
      for1(partition * sq, min((partition + 1) * sq, N)) {
        if(mo[i/sq] > ar[i]) {
          mo[i/sq] = ar[i];
          mo_idx[i/sq] = i;
        }
      }
    } else {
      ll mn = INF;
      ll ret = -1;
      for1(0, sq) {
        if(mo[i] < mn && mo_idx[i] != -1) {
          mn = mo[i];
          ret = mo_idx[i];
        }  
      }
      cout << ret + 1 << "\n";
    }
  }
}

김신건의 로그

IaC 튜토리얼 (1)

IaC란?

요약 정리

코드로 정의하면 따라오는 것들

IaC의 이점

명령형 vs 선언형 그리고 state에 대해

명령형(imperative)

선언형(declarative)

선언형 IaC 도구가 동작하는 방식

CodeWithOutput 컴포넌트 데모

1. 기본 — 코드 + 결과

2. STDIN + STDOUT 한 쌍

3. 여러 테스트 케이스 (cases)

4. 사용자 지정 케이스 라벨

5. 다중 언어 코드 (variants)

6. 다중 언어 + 다중 케이스

7. 케이스마다 입력 유무가 섞여 있을 때

8. 타이틀과 커스텀 라벨

9. 좌우 비율 조절 (codeWidth)

10. 긴 코드 / 긴 출력 (스크롤 확인)

11. 긴 한 줄 (가로 스크롤 확인)

12. 다양한 언어 하이라이팅

확인 포인트

[Leetcode] 192 Word Frequency

문제 요약 및 풀이

풀이 코드

[Leetcode] 195 Tenth Line

문제 요약 및 풀이

풀이 코드

[Leetcode] 193 Valid Phone Numbers

문제 요약 및 풀이

풀이 코드

캐시 적용이 적절한 상황

마크다운 문법 종합 테스트

1. 기본 텍스트 강조

2. 헤딩 계층

3단계 헤딩

4단계 헤딩

5단계 헤딩

6단계 헤딩

3. 인용과 콜아웃

4. 리스트

5. 코드 블록

6. 표

7. 이미지

8. 푸트노트

9. 구분선과 줄바꿈

10. HTML 직접 삽입

11. 코드 + 실행 결과 패널 (<CodeWithOutput>)

11.1 Bash

11.2 Redis CLI

11.3 PostgreSQL (psql)

11.4 HTTP — curl + JSON 응답

11.5 Python REPL

11.6 멀티 언어 탭 — 같은 출력, 여러 구현

11.7 너비 조절

12. Mermaid 다이어그램

12.1 Flowchart

12.2 Sequence — 빌드 파이프라인

12.3 State diagram — 사이드 드로어 상태

12.4 ER diagram

18. 인터랙티브 애니메이션

18.1 HTTP 요청 / 응답

18.2 Redis 캐시 적중 (HIT)

18.3 Redis 캐시 미스 (MISS)

18.4 DB Primary-Replica 복제

18.5 Load Balancer Round-Robin

18.6 TCP 3-way Handshake

18.7 OAuth 2.0 Authorization Code Flow

Footnotes

1만 개의 글에서도 빠르게: 블로그 빌드 성능 최적화 회고

어쩌다 1만 개를 측정하게 되었나

진단: 무엇이 폭주했는가

설계: 콘텐츠 그래프를 한 번만 만든다

그래프 페이지에도 같은 함정이 있다

측정: 10,531 페이지 / 34.57 초

같이 손본 자잘한 것들

얻은 교훈

1. 빌드 시점 비용은 프로젝트 단위 로 묶는다

3. 여러 테스트 케이스 (`cases`)

5. 다중 언어 코드 (`variants`)

9. 좌우 비율 조절 (`codeWidth`)

11. 코드 + 실행 결과 패널 (`<CodeWithOutput>`)

2. 모듈 레벨 `Promise` 는 단순하지만 강력하다