[스나이퍼팩토리] 한컴AI 2기 - 성과발표회 회고록

문서를 이해하는 시스템을 만들며

이번 성과발표회는 단순히 결과물을 보여주는 자리가 아니라, 그동안 내가 어떤 문제를 고민했고, 어떤 방식으로 해결해 왔는지를 스스로 정리하는 과정이었다. 프로젝트를 시작할 때와 지금을 비교해 보면, 생각보다 많이 달라져 있었다.

---

(1) 이번 프로젝트/성과발표회를 통해 배우고 느낀 점

가장 크게 깨달은 점

가장 크게 느낀 점은 기술을 구현하는 것과, 기술을 설명하는 것은 완전히 다른 능력이라는 것이다. 기능 자체는 어느 정도 구현되어 있었지만, 발표를 준비하면서

• 왜 이 구조를 선택했는지
• 기존 방식과 무엇이 다른지
• 이게 실제로 어떤 가치를 주는지

를 설명하려다 보니, 내가 만든 시스템을 내 언어로 다시 이해해야만 했다.

---

발표 준비·협업 과정에서 느낀 변화

초반에는 일단 되는 걸 만들자에 가까웠다면, 발표를 준비하면서부터는 이게 왜 필요한가, 왜 이렇게 설계했는가를 항상 같이 생각하게 됐다. 특히

• 이 슬라이드는 왜 필요한지
• 이 설명은 너무 기술적인지
• 이 부분은 시연으로 보여주는 게 맞는지

를 계속 고민해가며, 기술 중심 사고에서 사용자·청중 중심 사고로 전환되는 경험을 했다.

---

이번 과정을 통해 이전의 나와 달라진 점

이전의 나는

“이 정도면 설명 없이도 알겠지”

라고 생각하는 편이었다면, 지금은

“설명할 수 없다면, 아직 정리가 안 된 상태다”

라고 생각하게 됐다.

---

(2) 내가 맡은 역할과 성과

맡은 역할

• 백엔드 (Fast API 및 MySQL) 전반 설계 및 구현
• 인프라와 문서 처리 파이프라인(RAG) 통합
• 비동기 처리 구조(Celery 기반)
• 발표 및 시연

---

구현한 기능 및 기여

• 서비스 기획
• 서비스를 위한 각종 API
• 임베딩 → 검색 → 리랭커 → LLM 응답으로 이어지는 RAG 파이프라인 통합
• API 서버와 Worker를 분리한 Docker 기반 비동기 구조
• ACL 기반 문서 접근 제어 흐름 설계

---

해결한 문제 또는 책임졌던 과제

가장 신경 썼던 부분은

• 문서 승인 → 처리 → 완료로 이어지는 상태 관리
• 시연 중 실패 가능성을 고려한 영상/흐름 설계

였다. 발표 당일 안정적으로 돌아가야 한다는 관점에서, 기술뿐 아니라 운영 시나리오까지 함께 책임졌던 경험이었다.

---

(3) 아쉬운 점 및 개선하고 싶은 부분

기술적으로 아쉬웠던 점

• 관리자 자동 업로드 파이프라인이 워커로 완전히 분리되지 못한 점
• 표 데이터를 HTML로 리턴하는 OWPML 기능을 백엔드에 온전히 통합하지 못한 점.

핵심 기능은 구현했지만, 사용자 경험 측면에서 한 단계 더 다듬지 못한 부분이 아쉬움으로 남았다.

---

발표에서 충분히 전달하지 못한 부분

기술적으로 준비했던 내용이 많았던 만큼,

• 모델 비교 및 선정 이유
• 트러블 슈팅
• 성능평가

등은 시간 관계상 생략해야 했다. 발표 분량 컨트롤은 괜찮았지만, 시연을 잘 못한 부분이 큰 아쉬움이었다.

---

(4) 정규 교육 과정 중 나에게 도움이 되었던 파트

정규 교육 과정 중 가장 실질적으로 도움이 되었던 파트는 AI 교육 과정이었다.

특히 임베딩과 벡터 검색을 단순히 “모델을 호출해 결과를 받는 과정”이 아니라, 데이터를 어떤 단위로 표현하고, 그 표현을 어떤 기준으로 검색하고 해석할 것인가의 문제로 다룬 점이 인상 깊었다. 이 관점 덕분에 Vector DB를 단순한 저장소로 사용하는 대신,

• 하나의 벡터가 무엇을 대표하는지
• 검색 결과가 왜 이 순서로 나오는지를
  설계 단계에서부터 설명 가능하도록 구조를 잡고자 했다.

이번 프로젝트에서는 문서 전체나 임의 길이의 텍스트 조각이 아니라, 장·조·항·호 단위의 의미 블록을 하나의 벡터 단위로 정의했고, 이를 통해 벡터 간 거리가 단순 문장 유사도가 아니라 같은 규정 맥락 안에서의 의미적 근접성을 반영하도록 설계했다.

또한 검색 과정 역시 단일 점수에 의존하지 않고, ACL 및 메타데이터 기반 구조 필터링으로 검색 대상 문서를 먼저 제한한 뒤,
벡터 검색으로 후보를 수집하고 구조 정보와 함께 리랭킹하는 단계적 흐름으로 구성했다.

이렇게 함으로써 “왜 어떤 문서는 검색되지 않는지”, “왜 이 조항이 다른 결과보다 위에 노출되는지”를 검색 파이프라인 전체 관점에서 설명할 수 있게 되었다.

 

반면, 이번 프로젝트에서 일부 요구되었던 클라우드 인프라 관련 작업은 프로젝트의 핵심 목표와는 다소 거리가 있었고,
사실상 해야 해서 한 작업에 가까웠다. 그 과정에서 시간과 에너지가 분산되면서 문서 처리 엔진이나 검색 품질처럼 내가 더 집중하고 싶었던 영역의 완성도를 충분히 끌어올리지 못한 점은 아쉬움으로 남는다.

이번 경험을 통해 모든 기술을 억지로 끼워 넣기보다는, 프로젝트의 성격에 맞는 기술을 선택하고 집중하는 것이 결과물의 완성도에 훨씬 중요하다는 점을 분명히 느끼게 되었다.

 

---

(5) 향후 목표 및 포트폴리오 개선 방향

강화하고 싶은 기술

• 문서 기반 RAG 고도화
• 멀티모달(표·이미지) 활용

---

포트폴리오 개선 방향

• 이번 프로젝트를 단순 결과물이 아니라 설계 의도가 드러나는 포트폴리오로 정리
• 코드뿐 아니라 왜 이렇게 만들었는지를 설명할 수 있는 문서 보강

---

취업 준비에서의 다음 단계

• “이 기술을 쓸 줄 안다”가 아니라 “이 상황에서 이 구조를 선택했다”를 말할 수 있는 개발자가 되는 것
• 면접에서 이 프로젝트 하나로도 충분히 대화가 이어질 수 있도록 준비하는 것이 목표다.

---

(6) 팀원들과의 협업에서 느낀 점

이번 팀 프로젝트는 항상 이상적인 협업만 있었던 경험은 아니었다. 모든 팀원이 처음부터 끝까지 같은 온도로 몰입했다고 말하기는 어렵고, 중간중간 역할 분담이나 책임감의 차이로 부담이 한쪽으로 쏠리는 순간도 있었다.

그럼에도 불구하고 이 경험이 의미 있었던 이유는, 그 상황 속에서 “어디까지 내가 책임져야 하는지”를 스스로 정리하게 되었기 때문이다.

누군가 대신 해주길 기다리기보다는,

• 이건 지금 내가 정리하지 않으면 안 되는 부분인지
• 이건 굳이 끌고 갈 필요가 없는 영역인지

를 구분하면서 기술적인 판단뿐 아니라 협업에 대한 기준도 함께 세울 수 있었다.

또한 팀 내에서 의견이 다를 때 조용히 넘기기보다는 최소한의 근거를 가지고 설명하려 노력했던 경험은, 이후 어떤 협업 환경에서도 도움이 될 것이라 생각한다.

이번 프로젝트를 통해 “모든 팀원이 항상 같은 방향을 보지는 않는다”는 현실을 인정하게 되었고, 그 안에서 내가 통제할 수 있는 부분에 집중하는 태도가 결과적으로 나 자신을 지키는 방법이라는 것도 배우게 되었다.

---

이번 성과발표회는 “잘 끝냈다”기보다는 다음 단계로 가기 위한 기준을 하나 세웠다는 느낌에 가깝다.

이 경험을 발판 삼아, 앞으로는 더 명확한 문제의식과 설명 가능한 설계를 하는 개발자가 되고 싶다.