💙 큐시즘이란?

💡한국대학생 IT 경영학회로, 매 기수 70-80명의 대학생들이 모여 각각 기획, 디자인, 개발(프론트/백엔드) 파트를 맡아 IT 프로덕트를 만드는 학회

기업과 연계하여 진행되는 기업 프로젝트, 자체적으로 서비스를 만드는 밋업 프로젝트 등 실무형 커리큘럼과 각종 네트워킹까지 다양한 활동을 할 수 있는 학회입니다.

이 중 이번에는 서울 우유와 함께한 기업 프로젝트에 대한 회고를 해보도록 하겠습니다.

---

🥛 프로젝트 소개 및 문제점 파악

현재 서울우유에서는 전자세금계산서의 진위 여부를 담당 직원이 수작업으로 검증하고 있으며, 이 과정에서 휴먼 에러 발생 가능성과 반복적인 업무로 인한 비효율성이 문제가 되고 있습니다.

이를 해결하기 위해 저희는 OCR 기술과 진위 여부 검증 API를 활용하여 전자세금계산서 검증을 자동화하고 업무 효율성을 높이며 휴먼 에러를 최소화하는 백오피스 서비스 프로젝트를 개발하였습니다.

⭐ 솔루션 바로보기

https://www.notion.so/yunbh0401/1b8f7fdfbdbb8077bc89fd28869457c7?pvs=4#1b8f7fdfbdbb8063a8defd6aed2e6602

⭐ 자세한 내용

노션
https://yunbh0401.notion.site/1b8f7fdfbdbb8077bc89fd28869457c7?pvs=4

깃허브
https://github.com/Seoul-Milk-Team5/SM-Frontend

---

💬 개발 과정

2025년 2월 18일부터 3월 12일까지 약 한 달간 빠르게 진행된 프로젝트였습니다. 기획, 디자인, 프론트엔드, 백엔드 개발이 동시에 이루어졌으며, 예상대로 최종 마무리는 프론트엔드 개발 단계에서 이루어졌습니다.

실제 개발 기간은 약 2주 정도였던 것 같습니다. 이번 프로젝트에서의 기술 스택 선정 과정과 협업 방식을 돌아보며, 다음 프로젝트에서는 어떤 점을 보완하면 좋을지 이야기해 보겠습니다.

🤔 기술 스택 고민과 결정

이번 프로젝트는 서울유우 직원들이 사용하는 어드민 페이지로, SEO 최적화가 필요하지 않으며, 약 4주 내에 빠르게 개발해야 하는 요구사항이 있었습니다.

✅ 필수 과제: 지능형 세금계산서 검증 시스템 구축

단순 반복적인 업무를 자동화하여 각 부서의 업무 소요 시간을 단축하고자 합니다.

전달받은 전자(세금)계산서 정보를 홈택스 자료와 비교하여 실제 발급된 계산서가 맞는지 검증하고, 자동으로 지급 결의서까지 작성되는 프로그램을 개발해주세요.

🔹 요구 사항

1. 세금계산서는 사진 촬영 후 첨부하거나 이미지 업로드 방식으로 등록할 수 있어야 한다.

2. 업로드된 이미지는 저장 후 조회할 수 있어야 한다.

3. 세금계산서 이미지에서 추출된 데이터를 국세청 홈택스 자료와 비교하여 진위 여부를 판단한다.

4. 검증된 계산서 데이터를 저장하여 자동으로 지급 결의서를 작성한다.

5. 검증된 자료는 DB에 저장되며, 사용자는 본인이 저장한 자료를 조회할 수 있어야 한다.

6. 관리자는 모든 사용자의 검증 결과를 조회할 수 있어야 하며, 조회 조건에는 계산서의 공급자, 공급받는 자, 기간 등이 포함되어야 한다.

필수 과제 내용을 바탕으로, 클라이언트 측에서는 복잡한 UI 구현이나 대규모 API 연결이 필요하지 않을 것으로 판단하였습니다. 이에 따라, TypeScript와 React를 기술 스택으로 선정하여 개발을 진행했습니다.

---

📌 TypeScript와 React

기술	선택 이유 및 근거
TypeScript	- 코드의 안정성을 높임 - 코드 유지보수 개선
React	- 컴포넌트 기반 구조로 UI를 효율적으로 재사용 및 유지보수 가능 - React의 기본 훅 (useState, useEffect, useContext)만 활용하여 상태 관리 - Redux, Zustand 등의 라이브러리를 도입하지 않아 번들 사이즈를 줄이고 성능 최적화 - SEO가 필요 없는 어드민 페이지이므로 CSR(클라이언트 사이드 렌더링) 방식으로 구현

또한, 번들 파일 크기를 줄이고 성능을 최적화하기 위해 불필요한 라이브러리 사용을 지양했습니다.

상태 관리는 React의 기본 훅을 활용하여 구현하였으며, 이는 프로젝트 규모와 요구 사항을 고려할 때 충분히 효율적인 방식이라 판단했습니다.

API 통신은 별도의 라이브러리를 사용하지 않고, 기본 fetch 함수를 활용하여 처리하였습니다.

🎯 내가 느낀점

React의 기본 훅을 최대한 활용하여 추가적인 라이브러리를 학습할 시간을 줄였습니다. 덕분에 시간 내에 필수 과제뿐만 아니라 선택 과제까지 구현할 수 있었고, 좋은 성과를 낼 수 있었습니다.

하지만 한 가지 아쉬운 점이 있었습니다. 기획 의도대로 개발을 진행하다 보니,

실제 대화 내용 예시

기획자: "페이지 이동 후에도 이 파일이 그대로 유지되면 좋겠습니다."
나: "그럼 useContext를 사용하여 상태를 유지해야겠네요."

이렇게 해서 최종적으로 프로젝트에서 useContext를 5개 정도 사용하였는데, 이로 인해 불필요한 렌더링이 발생하였습니다. 시간이 부족하여 최적화까지 신경 쓰지는 못했지만, 성능에 치명적인 영향을 주는 것은 아니었기에 그대로 진행하였습니다. 다만, 개인적으로는 다소 아쉬움이 남았습니다.

---

📌 Tailwind와 Shadcn UI

기술	선택 이유 및 근거
Tailwind	- 유틸리티 퍼스트 방식으로 빠르게 스타일 적용 가능 - 불필요한 CSS 중복 제거로 유지보수 편리 - 반응형 디자인 최적화로 추가적인 미디어 쿼리 작업 최소화
Shadcn	- Tailwind와 호환되는 UI 컴포넌트 제공 → 빠르고 일관된 디자인 적용 가능 - 기본 UI 컴포넌트 활용 → 버튼, 모달 등을 직접 개발할 필요 없이 즉시 사용 가능 - 손쉬운 커스터마이징으로 프로젝트 요구사항에 맞게 유연한 적용 가능

기획과 디자인이 완료되면 UI를 구현하고, 백엔드 개발자가 API를 완성하면 이를 연결해야 했다. 하지만 약 4주 동안 진행되는 프로젝트였기 때문에, 프론트엔드 개발자가 UI까지 직접 구현하면 개발 시간이 부족할 것이라 판단했습니다.

그래서 이번 프로젝트에서는 처음으로 Shadcn UI를 도입했습니다. Shadcn은 Tailwind 기반의 UI 라이브러리로, 디자인 시스템이 적용된 컴포넌트들을 제공하기 때문에 빠르게 UI를 구성할 수 있었습니다. 또한, 필요한 경우 손쉽게 커스터마이징할 수 있다는 점도 큰 장점이었습니다.

Tailwind CSS를 사용한 이유도 비슷했습니다. 스타일을 유틸리티 기반으로 적용할 수 있어 별도의 CSS 파일 없이 빠르게 UI를 구현할 수 있었고, 반응형 디자인도 미디어 쿼리를 직접 작성할 필요 없이 Tailwind의 클래스만으로 쉽게 적용할 수 있어 개발 속도를 높이는 데 도움이 됐습니다.
특히, Shadcn의 모든 스타일이 Tailwind로 구성돼 있어 프로젝트 전반에서 일관된 디자인을 유지할 수 있었습니다.

🎯 느낀 점

이번 프로젝트에서 Shadcn과 Tailwind를 활용한 선택은 매우 효과적이었습니다. 덕분에 UI 개발 속도를 크게 단축할 수 있었고, 그 시간을 기능 개발과 API 연동에 더 집중할 수 있었습니다.

다만, Shadcn을 처음 사용하다 보니 라이브러리 구조를 이해하고 적용하는 데 초반에 약간의 학습 시간이 필요했다. 또한, 기본적으로 제공되는 컴포넌트 스타일이 프로젝트의 디자인 시스템과 완전히 일치하지 않는 경우, 추가적인 커스터마이징이 필요했다. 하지만 Tailwind와 함께 사용하니 스타일을 조정하는 과정도 어렵지 않았습니다.

결과적으로, 빠르게 진행되는 프로젝트에서는 Shadcn과 Tailwind의 조합이 매우 유용했고, 앞으로도 비슷한 환경에서는 적극 활용할 계획입니다.

---

🔗 OCR 검증 프로세스 개선

문제 인식

세금계산서 OCR 데이터를 추출한 후, 홈택스를 통해 진위 여부를 검증하는 과정에서 몇 가지 문제가 발생했었습니다. 먼저, 백엔드에서 OCR 데이터를 추출한 후 프론트엔드로 전달되지 않아, 이후의 검증 절차를 진행할 수 없었습니다. 이는 백엔드에서 OCR 데이터를 응답 값에 포함하지 않는 구조였기 때문이었습니다.

또한, OCR을 통해 추출된 데이터의 각 속성이 명확히 문서화되지 않아, 어떤 항목이 어떤 의미를 가지는지 파악하기 어려웠습니다. 이로 인해 프론트엔드에서 데이터를 처리하는 과정에서도 혼선이 발생했습니다.

개선 방법

우선, 백엔드 개발자에게 OCR 데이터를 프론트엔드로 전달해 줄 것을 요청하여, 프론트엔드에서 검증 프로세스를 원활하게 진행할 수 있도록 했습니다. 이를 통해 검증 절차로 넘어가지 못하는 문제를 해결했습니다.

또한, OCR 응답 데이터의 각 속성들이 어떤 의미를 가지는지 백엔드 개발자와 협의하여 하나하나 명확하게 정의하고,이를 기반으로 프론트엔드에서 데이터를 처리하는 로직을 개선하여, 불필요한 혼선을 방지할 수 있었습니다.

마지막으로, 원래 백엔드에서 처리할 예정이었던 데이터 필터링 로직을 프론트엔드에서 대신 구현했습니다. OCR 데이터 중에서도 성공적으로 추출된 데이터만 검증 요청을 보낼 수 있도록 하여, 불필요한 요청을 줄이고 전체 검증 프로세스의 속도를 최적화했습니다. 이를 통해 검사 시간을 줄이는 동시에 시스템의 효율성을 높일 수 있었습니다.

🎯 느낀 점

메인 기능을 개발하면서, 하나의 문제를 해결하면 또 다른 문제가 발생하는 일이 반복되었습니다. 마치 개복치처럼 한 가지를 고치면 새로운 오류가 터지는 상황이 계속되었고, 그만큼 많은 시간을 투자해야 했습니다.

이번 경험을 통해, 다음번에는 테스트 코드를 먼저 작성하여 보다 안정적으로 동작하도록 개선해야겠다는 생각을 하였습니다. 또한, 예외 처리를 뒤늦게 추가하다 보니 일부 오류를 빠르게 대응하지 못한 점도 아쉬움으로 남았습니다. 만약 백엔드와 더 긴밀하게 협의하여 오류 코드에 대한 소통을 원활히 했다면, 보다 깊이 있는 예외 처리를 빠르게 적용할 수 있었을 것이라 생각합니다.

---

UT 진행

이번 UT(Usability Test) 세션에서는 다른 팀들이 우리 프로토타입을 테스트하고 피드백을 주는 시간이었습니다. 여러 팀의 다양한 시각과 관점에서 우리의 프로덕트를 점검할 수 있었던 기회였죠. 각 팀은 우리의 프로토타입을 실제 사용자처럼 다루며, 사용성에 대한 인사이트를 제공해주었습니다.

과정

UT 세션은 주로 두 가지 주요 단계로 진행되었습니다. 첫 번째는 다른 팀들이 우리 프로토타입을 실제로 사용해보며, 그 사용성에 대한 피드백을 제공하는 시간이었고, 두 번째는 각 팀의 피드백을 바탕으로 개선점을 도출해내는 시간이었습니다. 팀원들은 프로토타입을 테스트하며 어려운 부분이나 직관적이지 않은 점들에 대해 의견을 나누었고, 그 의견을 기획, 디자인, 개발팀과 공유하여 프로젝트의 완성도를 높일 수 있었습니다.

🎯 느낀점

다른 팀들의 피드백을 듣는 과정에서 내가 미처 생각하지 못한 부분들을 발견할 수 있었고, 사용자 관점에서의 중요한 인사이트를 얻을 수 있었습니다. 특히, 테스트를 통해 사용자가 실제로 느끼는 불편함을 직접 들을 수 있었기 때문에, 그 피드백을 바탕으로 우리 프로덕트를 더 직관적이고 사용하기 편리한 방향으로 개선할 수 있는 기회를 얻었습니다. 이 경험을 통해, 앞으로의 프로젝트에서는 피드백을 적극적으로 반영하고 더 나은 프로덕트를 만드는 데 중점을 두어야겠다는 생각을 하게 되었습니다.

🔗 UT 리뷰 링크

https://handy-hope-df5.notion.site/UT-1b0c15ac394e802b8f50df36cc86385f?pvs=4

---

✅ QA 진행

기획자, 디자이너, 백엔드, 프론트 개발자 모두가 모여 QA를 진행했습니다. 이 과정에서는 테스트 계획서를 먼저 작성하여, 각 기능별 테스트 항목과 예상 결과를 명확하게 정의한 후 진행하였습니다. 테스트 계획서에 맞춰 테스트를 진행하며 각 파트의 담당자들이 해당 영역에서 발생할 수 있는 문제를 미리 파악하고 해결 방안을 모색할 수 있었습니다.

특히, 테스트 계획서를 통해 기능 테스트뿐만 아니라 UI/UX 테스트, API 통합 테스트, 예외 처리 검증 등 모든 측면을 꼼꼼히 점검할 수 있었고, 이는 프로젝트의 전반적인 품질을 높이는 데 큰 도움이 되었습니다. 각 팀은 각자의 영역에서 발생할 수 있는 문제를 사전에 예측하고, 이를 미리 해결하려는 노력 덕분에 QA 과정이 원활하게 진행되었습니다.

🎯 느낀 점

QA 진행을 통해 협업의 중요성을 다시 한 번 느꼈습니다. 기획자, 디자이너, 백엔드, 프론트 개발자 모두가 함께 모여 테스트를 진행하면서, 각자의 관점에서 발생할 수 있는 문제를 공유하고 개선할 수 있었습니다. 특히 테스트 계획서를 작성한 덕분에 테스트가 체계적이고 효율적으로 진행되었으며, QA 후 발생한 버그들도 빠르게 수정할 수 있었습니다.

다만, QA 과정에서 더 개선할 점은 테스트 케이스를 작성할 때 좀 더 다양한 예외 상황을 고려하지 못한 부분이 있었습니다. 예를 들어, 극단적인 데이터나 예상치 못한 사용자의 행동에 대한 테스트가 부족해 일부 문제가 발견되었습니다. 다음에는 보다 더 꼼꼼하게 다양한 시나리오를 테스트할 수 있도록 준비하는 것이 중요하다는 교훈을 얻었습니다.

🎉 성과

• 업무 효율성 98% 증가

  기존 50개 문서 검증 시간: 250분 → 개선 후: 5분

  UT 결과: 반려 46건, 승인 1건, 검증 실패 3건으로 평균 업무 시간이 5분으로 감소하여 효율성 98% 향상

• 에러율 감소로 지급결의서 수정 프로세스 축소

  기존 에러율: 0.67% → 개선 후: 0%

  검증 정확도 테스트 6회 진행 결과, 입력값과 출력값이 모두 동일하게 측정되어 에러율 0% 달성

• 사내 업무 생산성 향상

  권한별로 효율적인 업무 관리 가능

  일반 사용자: 내 업무 관리, 관리자: 업무 관리 및 사용자 권한 관리

To. 돈까스클럽 🍽️

우리가 함께한 시간은 정말 소중하고, 그만큼 즐거운 시간이었어. 훌륭하고 재능 있는 너희들과 함께 코딩을 하며 배운 점들이 많았고, 무엇보다 함께 이룬 성과가 너무나 값지다고 느껴. 비록 이제는 각자의 길을 가게 되었지만, 내 마음속에서 '돈클'은 언제나 함께할 거야. 우리의 추억과 성과는 영원히 기억될 거고, 그 소중한 시간들을 잊지 않을 거야.