약 두 달간의 IP 주소 관리 플랫폼 개발 프로젝트 회고

기존 IP 주소 관리 플랫폼이 기술적으로 노후화되어, 새로 대체할 수 있는 IP 주소 통합 관리 플랫폼을 개발하는 프로젝트를 약 두 달간 진행했다. 프로젝트 기간과 내가 맡은 역할을 간단하게 정리하면 다음과 같다.

• 프로젝트 기간 : 2026.01.05 ~ 03.16
• 참여 인원 : 4명 (프론트 2명, 백엔드 2명)
• 담당 역할 : 프론트 개발
  • 대시보드 페이지 (Warnings, 공인 IP 가용 현황, 즐겨찾기)​
  • 감사 로그 페이지 (액션별 세부 내역 출력)​
  • IP 주소/서브넷 개별 로깅 기능​
  • 관리 페이지 (엔티티 관리/사용자 권한 관리)​
  • 서브넷페이지 (서브넷 생성/삭제, 슈퍼넷 생성, 머지/분할 시 속성 일괄 또는 개별 설정 기능, 전체 레이아웃 개선)​
  • IP 주소 및 서브넷 대역 일괄 예약, 엑셀 추출 기능​ (Import/Export)
  • 그 외 사용자 경험을 향상시킬 수 있는 기능 (텍스트 복사, IP 상세 조회 탭, 브라우저 이동버튼과 내부 네비게이션 히스토리 동기화, 자동스크롤 등)

1. 사용자 친화적인 기능 구현에 대한 고민

프로젝트를 하면서 가장 어려웠던 부분은, 네트워크 운영 경험이 없는 내가 실제 운영자의 관점에서 이 도구를 얼마나 편하고 직관적으로 사용할 수 있게 만들지 고민하는 일이었다. 단순히 기능이 동작하는 화면을 만드는 것과, 운영자가 매일 반복적으로 사용하는 도구를 사용자 친화적으로 설계하는 것은 전혀 다른 문제였다. 그 간극을 메우는 과정에서 책임님의 피드백이 큰 도움이 되었지만, 운영자의 실제 사용 맥락을 충분히 알지 못하다 보니 사용자 경험을 주도적으로 설계하기보다 요구된 기능을 구현해 나가는 SI성 프로젝트처럼 느껴졌다.

네트워크 운영 관리자가 가장 많이 보는 서브넷 관리 페이지는 단순히 데이터를 보여주는 화면이 아니라, 운영자가 서브넷 구조를 빠르게 파악하고 필요한 작업을 바로 수행해야 하는 핵심 화면이었기 때문에, 기능 구현 자체보다도 "얼마나 직관적으로 이해되는가"가 더 중요했다. 기존에 사내에서 사용하던 네트워크 운영 도구의 UI는 세로 형태로 계층 구조를 나열하는 방식이었는데, 내가 보기에는 처음 진입했을 때 구조를 한눈에 파악하기 어렵고, 서브넷의 부모-자식 관계를 빠르게 인지하기가 쉽지 않았다. 그래서 이번 프로젝트에서 사용자가 "지금 어느 대역을 보고 있고, 하위에 어떤 서브넷들이 있는지"를 더 자연스럽게 읽을 수 있는 구조로 개선하고 싶었다.

그 과정에서 가장 많이 고민한 부분은 하위 서브넷이 펼쳐지고 접히는 방식과 서브넷 계층 구조 표현이었다. 화면 전환이 갑작스럽거나 움직임의 방향이 어색하면 사용자가 오히려 더 헷갈릴 수 있어서, 사용자가 "아, 이 서브넷 아래에 하위 항목이 생겨나는구나" 혹은 "지금 보고 있던 하위 구조가 다시 부모 안으로 정리되는구나"라고 직관적으로 느낄 수 있는 흐름이 무엇인지 많이 고민했다. 하위 서브넷이 펼쳐질 때, 현재 보고 있던 서브넷이 자연스럽게 접히고 하위 서브넷이 오른쪽으로 펼쳐지는데 이때의 흐름이 어색하지 않도록 프롬프트를 여러 번 작성하고 수정했다. 또한 하위 서브넷이 존재하는 서브넷과 리프 서브넷의 카드 디자인을 구분했고, 서브넷을 클릭할 때마다 브레드크럼으로 경로를 표시해 현재 계층 구조를 보다 명확하게 파악할 수 있도록 했다.

운영 도구 개발은 일반 서비스 개발과 비교했을 때 차이점이 많다고 생각한다. 일반 서비스의 사용자는 첫인상, 디자인 완성도, 탐색의 재미, 감성적인 만족감 같은 여러 요소를 종합적으로 보고 이 서비스를 계속 사용할지 판단한다. 반면 운영 도구의 사용자는 이 서비스를 쓸지 말지 선택하는 사람이 아니라, 업무를 위해 반드시 써야 하는 사람에 가깝다. 그래서 운영 도구에서는 시각적인 인상보다도 얼마나 빠르게 원하는 작업에 도달할 수 있는지, 반복적인 작업을 얼마나 덜 피로하게 만들 수 있는지, 버튼을 눌렀을 때 일어나는 동작들이 한 번에 이해가 되며 직관적인지가 훨씬 더 중요하다고 느꼈다. 즉, 일반 서비스의 UX/UI가 선택받기 위한 경험에 가깝다면, 운영 도구의 UX/UI는 효율적으로 일하기 위한 경험에 더 가깝다고 느꼈다.

2. 토큰 사용량 걱정없이 무제한 사용했던 Cursor 개발 경험

이번 프로젝트에서는 커서를 토큰 사용에 대한 부담 없이 자유롭게 활용해볼 수 있었고, 그 과정에서 AI를 어떻게 업무에 어떻게 더 효율적으로 녹여낼 수 있을지에 대해 고민하게 되었다.

아래 이미지들은 최종 발표 때 발표한 커서 사용 경험에 대한 내용이다. 이번 프로젝트에서는 먼저 Figma로 화면의 초안을 구체화한 뒤, 그 구조와 요구사항을 .cursor/rules 형태의 문서로 정리하고, 이를 바탕으로 Cursor에게 구현을 맡기는 방식으로 작업했다. 설계 문서화 -> 문서 기반 구현 -> 검증 및 세부 개선의 사이클을 반복했는데, 모든 작업을 '문서'를 기반으로 했다는 점이 특징이다.

팀 프로젝트에서는 구현만큼 중요한 것이 팀원 간 맥락 공유인데, 문서를 기반으로 작업하니 협업이 훨씬 수월해졌다. 구두로만 설명할 때보다 화면 구조, 요구사항, 수정 의도를 문서로 남겨두어 팀원들이 빠르게 이해할 수 있었고, 이후 기능을 수정하거나 확장할 때도 맥락을 다시 맞추는 비용이 줄어들었다. 문서가 하나의 공통 기준점 역할을 해줘서 커뮤니케이션이 훨씬 안정적이라고 느껴졌다.

특히 커밋 메시지 작성, PR 생성, 빌드 테스트를 자동화했던 부분이 AI를 가장 잘 활용했다고 느낀 부분이었다. 반복적이지만 꼭 필요한 작업을 일관된 형식으로 처리할 수 있어 편리했고, 개발 내용을 빼먹지 않고 정리하는 것이 수월했다.

커서 활용으로 단순히 개발 속도만 빨라진 것은 아니다. 자주 쓰는 기능은 .cursor/rules로 표준화해 여러 곳에 재사용했고, UX/UI에서 고민이 생길 때는 Plan 모드를 통해 여러 아이디어를 빠르게 생성하여 비교했다. 덕분에 구현 자체에 쓰는 시간을 줄이고 기능의 완성도나 사용자 경험을 다듬는 데 더 많은 시간을 투자할 수 있었다.

그리고 커서는 디버깅을 굉장히 잘한다. 문제가 생기면 개발자 도구를 열어 상황을 파악하고, 그 상황만 커서에게 던져주면 가능한 원인과 개선 방안을 빠르게 파악 후 문제를 해결해 주었다. 한 가지 사례를 들면, 하위 서브넷이 있는 2계층 (디렉터리) 서브넷을 즐겨찾기 리다이렉션 하는 경우, 루트 서브넷으로 리다이렉션 되는 버그가 있었다. 문제는 한 번 봤던 캐시가 있으면 제대로 동작하는데, 새로고침하고 다시 보면 제대로 동작하지 않는다는 것이었다. 커서에게 상황을 자세히 알려줬더니 400만 토큰을 써서 해결이 되었는데, 문제 원인은 다음 이미지에 설명되어 있다. 이 글을 보고는 Opus 없었으면 절대 해결 못했겠다는 생각만 들었다.

3. 토큰 사용량을 줄이기 위한 노력

토큰을 무분별하게 사용하지 않기 위해 리팩토링에 신경 썼다. 한 파일 안에 코드가 너무 길어지면 프롬프트에 담아야 할 문맥이 커지고 그만큼 한 번에 사용하는 토큰량도 많아지기 때문에, 컴포넌트와 로직을 역할별로 분리하고, 반복적으로 사용하는 패턴이나 유틸성 코드는 따로 분리해 관리했다.

또한 Cursor 토큰 사용량을 매번 http://cursor.com/dashboard에 들어가서 보지 않아도 되도록, IDE 안에서 바로 상태를 파악할 수 있는 UsageWatcher라는 툴을 만들었다. Cursor 사용량 API를 바탕으로 현재 사용량과 비용을 statusline에 표시해 주는 간단한 확장 프로그램으로, 토큰 사용 흐름을 실시간으로 체크하며 작업할 수 있어 토큰 사용에 대한 경각심을 가질 수 있었다.

4. 느낀점

이번 프로젝트에서 가장 크게 남은 것은 실제 사용자의 관점에서 문제를 바라보며 사용자 경험을 향상시키기 위해 고민해본 경험이다. 또한 AI를 개발 과정에 적극적으로 활용해보면서, AI를 잘 활용하려면 결국 맥락이 잘 담긴 문서를 작성하는 일이 중요하다는 점을 배웠다. 완성도 높은 운영 도구를 만들기 위해 사용자의 실제 맥락을 더 깊이 이해하려 노력하고, 이를 뒷받침할 운영과 개발 역량을 꾸준히 쌓아나갈 것이다.