AI 시대의 개인 이슈 트래커 - 나만의 Linear를 만들어봤다

1. 들어가며 — AI 에이전트 코딩 시대, 병목은 도구가 아니라 내 머리였다

AI 에이전트 코딩이 본격화되면서 개발자의 일하는 방식이 빠르게 바뀌고 있다.

불과 1-2년 전만 해도 코드를 한 줄 한 줄 직접 짜는 게 당연했다. 지금은 다르다. Claude, Cursor, Windsurf 같은 도구들이 반복적인 구현을 대신 처리해주면서, 동시에 굴릴 수 있는 프로젝트 수도 자연스럽게 늘어났다.

나도 그랬다. 이전에는 한두 개 프로젝트를 순서대로 진행했다면, 요즘은 3-4개를 병렬로 돌리는 게 일상이 됐다. 생산성이 올라간 건 분명한데, 이상하게 머릿속은 점점 더 복잡해졌다.

 

A 프로젝트를 하다가 B로 넘어가면, A에서 어디까지 했는지, 다음에 뭘 해야 했는지, 왜 그런 결정을 내렸는지가 흐릿해졌다. 코드는 그대로인데 나만 리셋된 느낌이랄까. 다시 맥락을 되찾는 데 생각보다 시간이 많이 들었다.

AI가 코딩을 빠르게 해줄수록, 내 머릿속 컨텍스트 관리가 더 중요해졌다. 도구는 충분히 좋아졌는데, 그걸 다루는 나의 워크플로우가 따라가질 못하고 있었다.

---

2. 하이니어란? — 개인 컨텍스트 스위칭 비용을 줄이기 위한 프로젝트

하이니어는 개인용 이슈 트래커다. Linear에서 영감을 받아 만들었고, 목표는 하나다. 컨텍스트 스위칭에 드는 리소스를 줄이는 것.

Linear나 Jira를 그냥 쓰면 되지 않냐고 할 수 있다. 나도 써봤다. Linear를 개인용으로 쓰기도 했고, Notion으로 태스크를 관리해보기도 했다. 그런데 기존 툴들은 팀 협업에 최적화되어 있다 보니, 개인이 쓰기엔 기능이 너무 많거나, 내가 원하는 방식으로 AI와 연동하기가 까다로웠다.

 

그래서 직접 만들기로 했다. 구조는 간단하다. 나는 칸반 보드를 통해 지금 무슨 작업을 하고 있는지, 해야 하는지, 이미 했는지를 한눈에 파악한다. AI는 MCP를 통해 칸반 컬럼을 직접 옮기고, 다음에 무슨 작업을 해야 할지 파악한다.

사람과 AI가 같은 보드를 공유하며 함께 프로젝트를 관리하는 구조다.

---

3. 칸반 보드 설계 — Linear를 참고한 뷰 구성 (칸반 / 드로우 / 풀페이지)

칸반 뷰

칸반 보드는 Linear UI를 많이 참고했다. Linear가 이미 이슈 트래커 UX를 잘 다듬어 놓았기 때문에, 개인 용도에 맞게 필요한 부분만 가져오는 방식으로 설계했다.

컬럼 구조는 Backlog → In Progress → Done → Closed 흐름을 따른다. 이슈 카드에는 제목, 상태, 연결된 브랜치 정보가 표시되고, 카드를 드래그해서 컬럼 간 이동이 가능하다.

 

 

드로워 뷰

이슈 카드를 클릭하면 오른쪽에서 드로워가 슬라이드로 열린다. 페이지를 이동하지 않고도 Status, Priority, Assignee, Label 같은 정보를 바로 확인하고 수정할 수 있다. 디스크립션 편집이나 최근 활동 확인도 여기서 된다. 더 깊게 들어가야 할 때는 상단의 "Open full page"로 풀페이지 뷰를 열면 된다.

 

 

 

풀페이지 뷰

이슈를 문서처럼 펼쳐서 보는 뷰다. 디스크립션이 길거나 세부 내용을 집중해서 확인할 때 사용한다. 에디터 형태라 바로 내용을 수정할 수도 있다.

 

 

 

드로우 뷰와 풀페이지 뷰로 나누어져있지 않아도 기본 기능엔 문제가 없긴하다. 그냥 만들어봤다. 이게 바이브 코딩의 묘미니까.

---

4. GitHub 연동 — 브랜치 생성과 PR까지 한 곳에서

이슈 트래커를 만들다 보니 자연스럽게 GitHub 연동이 필요해졌다.

이슈와 코드는 분리할 수 없다. 이슈가 생기면 브랜치가 생기고, 브랜치에서 작업이 끝나면 PR이 생긴다. 이 흐름이 하나의 맥락 안에 있어야 컨텍스트가 유지된다. 이슈 트래커와 GitHub를 왔다 갔다 하는 것 자체가 이미 작은 컨텍스트 스위칭이다.

 

GitHub App을 직접 만들어서 레포와 연결했다. 하이니어 안에서 이슈에서 바로 브랜치를 만들고, 작업이 끝나면 PR도 올릴 수 있다. 이슈를 열면 연결된 브랜치와 PR 상태가 바로 보여서, GitHub를 별도로 열지 않아도 현재 작업 상태를 파악할 수 있다.

 

5. MCP 연동 — AI가 칸반을 직접 움직인다

하이니어에서 가장 공을 들인 부분이다. 사실 이게 하이니어를 만든 핵심 이유이기도 하다.

MCP란?

MCP(Model Context Protocol)는 AI 모델이 외부 도구와 상호작용할 수 있도록 해주는 프로토콜이다. AI가 텍스트로 답하는 데 그치지 않고, 실제로 무언가를 조작할 수 있게 해주는 인터페이스라고 보면 된다. Claude Code가 stdio로 하이니어 MCP 서버에 연결되고, 거기서 Supabase DB와 GitHub API까지 직접 건드린다.

실제 사용 흐름

A 프로젝트 작업을 마치고 B로 넘어갈 때, Claude에게 이렇게 말하면 된다.

"A 프로젝트 로그인 기능 구현 완료했어. 다음 B 프로젝트에서 뭐 해야 해?"

 

그러면 Claude가 MCP를 통해 해당 이슈를 Done으로 옮기고, 연결된 GitHub 브랜치를 닫은 뒤, B 프로젝트 보드를 확인해서 다음 작업을 알려준다. 내가 보드를 직접 조작하지 않아도 된다.

컨텍스트 스위칭할 때 가장 귀찮은 순간이 "아 맞다 보드 업데이트해야지"다. 그 마찰을 없애고 싶었다.

구현된 툴들

MCP 서버에는 현재 이런 툴들이 구현되어 있다.

이슈 관련으로는 조회, 생성, 상태 변경, 댓글 추가, 그리고 여러 이슈를 한 번에 처리하는 배치 업데이트까지 된다. GitHub 연동으로는 브랜치 생성, 이슈 연결, PR 연결이 가능하다. 라벨이랑 멤버 관리도 MCP로 할 수 있다.

카테고리툴

이슈	조회, 생성, 상태 변경, 댓글, 배치 업데이트
GitHub	브랜치 생성, 이슈 연결, PR 연결
라벨	조회, 생성, 수정, 삭제
멤버	조회, 초대, 권한 변경, 제거

인증 구조

Claude Code 설정에 HINEAR_MCP_TOKEN 환경변수만 넣으면 된다. JWT로 검증해서 Supabase 세션을 만들고, 그 세션으로 모든 DB 작업이 이루어진다. 설정이 간단한 편이라 Claude Code에서 바로 연결해서 쓸 수 있다.

앞으로 붙이고 싶은 것들

지금은 명령을 받아서 처리하는 구조인데, 앞으로는 AI가 더 능동적으로 움직였으면 한다. 오래 In Progress에 머물러 있는 이슈를 감지해서 알려준다거나, 작업하면서 생긴 결정 사항을 디스크립션에 자동으로 기록해둔다거나. 일종의 AI가 써주는 작업 일지 같은 개념이다. 이 부분은 완성되면 후속 글로 따로 정리해볼 생각이다.

---

6. Pencil.dev 후기 — Stitch 대신 써본 디자인 툴, IDE 안에서 바로

하이니어 UI 작업을 하면서 처음으로 Pencil.dev를 써봤다.

구름(goorm) 밋업 세션에 갔다가 moai-adk 얘기를 듣던 중에 알게 됐다. 마침 UI 작업이 남아있어서 바로 써봤다.

 

이전엔 주로 Stitch를 쓰거나 직접 컴포넌트를 잡아가는 방식으로 작업했다. Stitch는 브라우저에서 별도 탭으로 열어두는 구조라, 코드를 짜다가 결과를 확인하려면 브라우저로 넘어가야 했다. 짧은 전환이지만 반복되다 보면 흐름이 끊겼다.

 

Pencil은 IDE 안에서 직접 볼 수 있다. 와이드 모니터에 IDE를 펼쳐두고 한 패널은 코드 에디터, 한 패널은 Pencil, 한 패널은 터미널로 구성해서 작업했다. 화면 전환 없이 코드 수정하고 결과를 바로 확인할 수 있으니 흐름이 끊기지 않았다.

 

아직 깊게 쓴 건 아니라 모든 기능을 평가하긴 어렵지만, 개발 경험만큼은 Stitch보다 좋았다.

---

7. 앞으로 — 디자인 시스템 구축과 하이니어 MCP 자동화

지금은 앞으로 만들 서비스들을 위한 디자인 시스템을 구현하는 중이다.

솔직히 하이니어보다 먼저 만들었어야 했다. 디자인 시스템이 없으니 UI 작업할 때 컴포넌트를 그때그때 만들어야 했고, 일관성을 유지하기가 쉽지 않았다. 순서가 뒤바뀐 셈이다.

 

그래도 일부러 하이니어를 먼저 만든 이유가 있다. 디자인 시스템 작업 자체도 하이니어 MCP로 관리하면서 진행해보고 싶었기 때문이다. 도구를 만들면서 그 도구로 다음 작업을 굴리는 구조. 맞는 순서인지는 모르겠지만, 해보고 싶었다.

 

MCP가 완성되고 나면 더 붙여보고 싶은 기능들도 있다. 오랫동안 In Progress에 머물러 있는 이슈를 감지해서 알려준다거나, 프로젝트 진행 상황을 요약해서 브리핑해준다거나. 결국 단순한 이슈 트래커를 넘어서, AI와 함께 프로젝트를 관리하는 워크스페이스가 됐으면 한다.

---

8. 마치며

만들고 나서 예상과 달랐던 게 있다.

GitHub 연동이나 다양한 뷰보다, 칸반 보드 자체를 꾸준히 업데이트하게 된다는 점이다. 이슈를 만들고, 브랜치를 연결하고, 작업이 끝나면 Done으로 옮기는 이 단순한 흐름이 생각보다 컨텍스트 유지에 도움이 됐다. 거창한 자동화가 없어도 그냥 보드가 정리되어 있다는 것만으로 다음 프로젝트로 넘어갈 때 훨씬 수월했다.

 

MCP까지 완성되면 어떻게 달라질지 궁금하다. 기대가 크다.