Projects

우아한 테크코스 8기 과정 중 크루들의 블로그 활동과 미션 제출 기록 등 필요한 정보들을 모아볼 수 있는 서비스를 만들었던 과정을 기록했어요

who-tech

site: https://who-tech.vercel.app

fe: https://github.com/iftype/who-tech-frontend

be: https://github.com/iftype/who-tech-backend

어쩌다가 만들었는가?

안녕하세요 저는 우아한테크코스 프론트엔드 8기 과정 중인 콘티라고 합니다!

 

이번에 우아한테크코스 과정 중 클로드 코드를 활용하여 웹앱을 만들며 겪은 경험을 기록하고 공유하려고 글을 썼습니다.

 

바이브 코딩으로 만들었기 때문에 어떤 엔지니어링 기법을 사용해서 만들었다를 소개하기엔 제 실력이 너무나도 부족하다고 생각하여 사이드 프로젝트를 만든 경험 그 자체를 공유하려고 해요.

망해버린 프로젝트 경험

이번에 만든 who-tech는 우아한테크코스 과정을 진행한 크루들의 _블로그 글 현황_이나, _미션 제출 PR_을 편하게 확인할 수 있는 서비스에요.

 

저는 종종 AI를 사용해서 실제 사용할 프로젝트를 만들곤 하는데요, 저번에 만들어본 PR 제출 도우미 서비스 가 주목도 못 받고 역사 뒷편으로 사라졌기 때문에 크루원들이 진짜로 쓸만한 기능을 넣기로 계획했습니다.

처음에 기획한 프로젝트는 위 같은 내용이 아니라 크루원들을 편하게 팔로우 할 수 있는 사이트를 만드려고 했었어요. 우테코에서는 미션마다 페어프로그래밍을 하기 때문에 페어의 깃허브를 들어가야 할 상황이 많고, 그러면 제가 만든 프로젝트가 빛을 볼 것이라 생각했습니다.

멤버 수집

첫 계획

멤버 수집을 어떻게 해야할지 고민이 들었습니다. 트랙이 프론트,백,안드로이드로 나뉘어진 상황에 한명 한명 PR을 물어볼수도 없었고요. 하지만 멤버 수집은 무조건 자동화로 해야겠다! 생각했습니다. 인원이 너무 많고 하나하나 모으기엔 너무 귀찮을 것 같았거든요..

다행히도 우아한테크코스는 깃허브 조직으로 아주 관리가 잘됐기 때문에 미션 레포에는 접근하기 편했습니다. 미션 레포 PR에 접근해서 년도별로 기수를 나눠서 가져오면 되겠다고 계획을 잡았습니다.(2026년은 8기, 2025년은 7기..)

하지만 ..

// 8기의 경우
[1단계 - 콘솔 기반 로또 게임] 콘티 미션 제출합니다.

// n기의 경우
[콘티] 회원가입 미션 1, 2단계 제출합니다.

미션의 PR 제출 형식이 기수별로 달랐습니다. 처음엔 정규표현식을 적용해 간단히 가져오면 되겠구나 생각했지만 기준이 달라지니 어떤 기준으로 닉네임을 가져올 것인지 고민이 되더라구요.

 

하지만 다른 방법이 떠오르지 않아 처음 생각한 그대로 기수별로 정규표현식을 나눴습니다. octokit(깃허브 제공 API)으로 레포를 받아와서 레포마다 정규식을 달고 있었어요

엣지 케이스

아뿔싸! 8기의 모든 레포(당시 6개)를 작업하다 4기의 레포를 보게 되었습니다. 4기 프론트엔드의 PR 제출 형식이 아래와 같았습니다.

[콘티-철수] 계산기 미션 제출합니다.

콘티와 철수 두명 다 닉네임이기 때문에 정규식을 어떻게 걸어야 할지 감이 안왔습니다. 그래서 의심가는 닉네임은 제가 직접 수동으로하려고 고민하던 찰나, 기특한 방법이 떠올랐습니다.

특수문자나, 공백으로 모든 글자를 분해하고, 가장 많이 나온 단어의 빈도 수를 사용하자!

사실 크루 한명의 PR기록들은 가져올 수 있는 상태였기 때문에 페어가 어떻게 바뀌든 본인의 닉네임은 미션 제출 PR 제목안에 포함되어 있을 것이란 생각을 했습니다.

그렇게 단계, 제출과 같이 많이 나오는 단어들을 금지어로 설정하여 닉네임을 얻을 수 있었습니다.

PR 아카이빙 기능 추가

저도 멤버를 구하기 위해 PR에 접근하고, PR기록을 모으다 보니 한 가지 재밌는 아이디어가 떠올랐습니다.

우테코의 윗 기수 분들의 레포를 둘러보니 위처럼 미션 제출 기록을 아카이빙 하더라구요. PR기록도 있겠다, 사람들한테 이 형식으로 보여주면 좋겠다는 생각이 들었습니다.

그렇게 PR을 볼 수 있는 기능이 추가됐습니다.

블로그 글 수집

i love github

이 당시의 저는 처음 세웠던 계획이랑 전혀 다른 방향으로 가고 있었습니다. 팔로우 기능을 생각했지만 멤버 목록을 얻기 위해 PR의 정보를 수집했고, PR의 정보를 수집하다 보니 깃허브 api로 꽤 많은 정보를 얻을 수 있었습니다.

{
  "login": "iftype",
  "blog": "https://velog.io/@iftype",
   ...
  "created_at": "2022-06-17T02:13:45Z",
  "updated_at": "2026-04-11T16:15:33Z"
}

주소창에 https://api.github.com/user/107661542 를 검색하면 나오는 제 정보입니다

그런데 이 필드를 블로그 글도 수집할 수 있겠다고 생각해서 블로그를 직접 방문탐색하려 했습니다.

하지만 수집된 인원이 900명이 넘었기에 계속 돌리다 보면 제 오라클 프리티어 서버가 무리하진 않을까 고민하던 중 Codex에게 한 가지 아이디어를 받았습니다. (클로드 코드 토큰을 다 쓴 상황이었습니다)

github action cron

CODEX: cron 작업을 github action으로 해라,
블로그 직접 탐색하면 비용 크니까 RSS도 사용하고

// 서버 코드
setInterval(() => {
  syncAllRepos();
}, 60 * 60 * 1000); // 1시간마다

원래 제 스케줄링 작업은 서버에서 돌아가는걸 전제로 생각하고 있었습니다.

# .github/workflows/blog-check.yml
name: Blog Check

on:
  schedule:
    - cron: '0 * * * *'  # 매시간 0분
  workflow_dispatch:

jobs:
  blog-check:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger blog sync
        run: |
          curl -X POST "$BASE_URL/admin/blog/sync" \
            -H "Authorization: Bearer ${{ secrets.ADMIN_SECRET }}"

그런데 이 작업들이 깃허브 액션으로 된다니 상상조차 못하던 인사이트였습니다. 깃허브 액션의 공부 필요성을 몸으로 체득한 체, 블로그 글 수집 기능을 완성시켰습니다.

DB실수

정규화를 꼼꼼히

-- 처음에 잘못한 설계
CREATE TABLE Member (
  id INT PRIMARY KEY,
  githubId VARCHAR,
  cohort INT,          -- 단 하나의 기수
  role VARCHAR         -- 단 하나의 역할
);

저는 큰 실수를 저질렀습니다. 그것은 기수를 해당 멤버에 그대로 넣어버린 잘못인데요 크게 문제는 없었습니다.
제가 운영진(코치, 리뷰어)등을 추가하려고 계획하기 전까지는요..

운영진 추가

"4기 크루"이면서 "8기 코치"

운영진이 크루 출신일 경우, 위와 같은 문제가 생깁니다. 멤버 추가를 하면 블로그 글이 두 개씩 잡히고, 멤버 목록에도 두 명이 출력되죠 그렇게 테이블 구조를 다 뜯어고쳤습니다.

model Member {
  id            Int              @id
  githubId      String
  memberCohorts MemberCohort[]   // 1:N 관계
}

model Cohort {
  id            Int
  number        Int              // 1, 2, 3, ...
  memberCohorts MemberCohort[]
}

model Role {
  id            Int
  name          String           // "crew", "coach", "reviewer"
  memberCohorts MemberCohort[]
}

model MemberCohort {
  id       Int    @id
  memberId Int    @relation(Member)
  cohortId Int    @relation(Cohort)
  roleId   Int    @relation(Role)

  @@unique([memberId, cohortId, roleId])
}

DB의 기본인 정규화를 안 지켰을 때의 고통을 토큰으로 몸소 체감했습니다. (이 문제의 마이그레이션 때문에 주간 한도의 60%가 날아갔습니다)

{
  "githubId": "iftype",
  "nickname": "콘티",
  "cohorts": [
    { "number": 8, "roles": ["coach"] },
    { "number": 4, "roles": ["crew"] }
  ]
}

그렇게 수정한 결과 이쁜 응답을 받을 수 있었습니다.

디자인은 어떻게?

프론트엔드의 꽃은 디자인?

네 사실 제가 프론트엔드는 디자인 감각이 뛰어나야 됐다고 생각하던 사람 중 한명입니다. 이제는 디자인은 디자이너에게 맡겨야 한다는 주의로 바뀌었는데요, 그래서 생성형 AI인 PAPER를 이용하기로 했습니다.

어떤 디자인 툴도 상관없었지만 유튜브에 많이 바이럴 됐었고, MCP서버를 지원해 구축한 디자인 시스템을 클로드 코드로 받아올 수 있기 때문에 결정했습니다.

써본 결과 놀라웠습니다. 원하는 디자인 시스템과 총 7개의 페이지를 만들어내고도 주간 한도의 20%나 남았습니다.

PAPER 토큰 다 썼을 때 대처

하지만 MCP를 연결해 실제 페이지를 구현하다 PAPER의 주간 무료 한도를 전부 써버리고 말았고 더 이상 PAPER에 접근해 이미지를 참조하지 못하는 상황이었습니다.

번뜩이는 아이디어로 이미지를 전부 export 해서 png파일로 만든 뒤 작업하던 프론트엔드 폴더에 때려넣고 클로드 코드에게 이미지를 참조하라고 시켜 나머지를 완성시켰습니다.

클로드 경험

이번에 만든 프로젝트는 사실 클로드 코드에 익숙해지려는 이유도 있었습니다. 하지만 AI에 익숙치 않은터라 많은 실수를 했는데요 크게 세 가지의 실수가 있었습니다.

1. 로그는 날짜별로 저장하지마라

AI는 날짜별로 저장되어 있는 정보보다 기능별로 나뉜 md를 더 잘 찾아갔습니다. 로그를 남긴다면 기능별로 남기는 걸 추천드립니다.

2. 다음 작업자에 기록을 전달하자

// root/CLAUDE.md
## Handoff
- 작업 마무리 시 TODO.md에 `=== 다음 작업 ===` 섹션으로 다음 세션 인수인계 내용 기록
- Stop 훅이 git 상태와 함께 보존함 → 다음 SessionStart에서 자동 로딩

앞으로 해결할 일은 TODO.md 로 저장하여 다음 세션에 정보를 전달해야합니다.

저는 항상 토큰의 압박을 느꼈고, 다음 세션이나 다른 AI툴을 사용해야 됐으며, 그 과정에는 다음 세션에 해야할 일을 업데이트시켜 다음 작업자들의 이해를 도왔습니다.

3. 서브 에이전트를 활용하자

클로드 코드에게 서브 에이전트를 사용해달라해도되고, 이미 나온 오마이클로드코드 같은 오케스트레이션 스킬이면 더더욱 좋습니다.

서브(멀티X)에이전트를 사용해 작업하면 토큰이 확실이 줄었고, 읽기 쓰기를 저렴한 모델에 맡기고 어려운 작업은 오푸스나 소넷에게 맡기는 어드바이스 구조가 굉장히 도움됐습니다. 서브에이전트가 작업 종료시에만 보고하니 출력 토큰도 줄어들고 속도도 훨씬 빨랐습니다.

서버 로깅

서버 로깅의 경우, DB에 저장하지 않고 콘솔로 출력하였는데, 서버 로그도 DB로 관리해야한다는 걸 늦게나마 깨달았습니다. 하지만 이 구조도 지금 DB에 많은 영향을 주는 것 같아, 앞으로 더욱 가벼운 로그 관리 서비스로 업데이트할 예정입니다.

마무리

기획 단계에서의 개발

제가 AI를 사용해보니 이제는 기획 단계에서 실제로 프로토타입을 만들어보며 생각을 재정립하는 방식으로 바뀌었다고 생각이 듭니다. 왜냐하면 저는 정말 이 기능이 내가 원하던 기능인가? 를 시작 전에 정의할 순 없겠더라고요.

그래서 시대가 시대인만큼 원하는 구조를 미리 만들어보면 기획이 더 단단해지지 않을까 생각해봤습니다.

피드 모아보기

블로그 기능은 처음엔 생각치도 못했는데 만들며 여러 생각이 지나갔습니다. 우테코 사람들의 블로그는 많지만, 좋은 품질의 글도 조명받지 못하고 묻혀갑니다.

 

저는 더 좋은 품질의 글들이 각광받으면 좋겠어서 글을 모아볼 수 있는 서비스로 만들었습니다. AI시대인만큼, 자신의 생각을 글로 쓰는 능력이 더욱 중요해졌습니다.

 

그래서 저는 우테코 사람들이 글을 쓰고 그 글에 대한 반응을 얻어, 흥미를 잃지 않고 글을 썻으면 좋겠다는 마음이 있었습니다.

읽어주셔서 감사합니다.