SK 네트웍스 family AI 캠프 22주차 회고( 2025-07-21 ~ 2025-07-25 )

PMI

Plus : 좋았던 점

새로운 기술 습득: PostgreSQL, OpenSearch, MinIO

 제가 담당한 문서 검색 에이전트를 구현하기에 앞서, 문서 검색에 사용될 데이터베이스 구축을 먼저 진행하게 되었습니다. 지난주에 구상했던 하이브리드 DB를 구현하기 위해 정형 DB는 PostgreSQL, 비정형 DB는 AWS S3, 벡터 DB는 OpenSearch를 사용하기로 하였습니다. 세가지 서비스 모두 처음 다뤄보기 때문에 2일 간은 공부하는 시간을 가졌고, 어느 정도 사용법을 익힌 뒤에는 Docker-Compose를 사용하여 초반 세팅을 해주었습니다.

지난 주 구상한 하이브리드 데이터베이스

 초반 세팅은 각 docker-compose.yml 파일 작성, 서비스에 사용되는 환경변수 설정, PostgreSQL과 OpenSearch 대쉬보드 설정을 해주었습니다. 그리고 S3는 MinIO를 사용하도록 설정하였는데 이는 MinIO가 AWS S3를 완벽히 호환할 수 있다는 점과 초반 개발 단계이기 때문에 비용이 들지 않는 서비스를 사용하기 위함이었습니다.
 docker-compoes 파일을 작성은 4차 프로젝트를 진행할 때 해보았지만 이번 시간을 통해 더 깊게 이해하게 되었습니다. 특히 환경변수를 설정하는 방법에 대해 확실히 이해할 수 있었는데, docker-compose 파일에 값을 넣지 않고 같은 경로에 .env 파일을 만들어 해당 값을 불러오도록 하게 설정하는 방법을 배웠습니다. 
 그리고 PostgreSQL과 OpenSearch, MinIO는 각각 대쉬보드를 지원해주고 있는데 이를 통해 적재한 데이터를 CRUD 처리할 수 있습니다. PostgreSQL은 pgAdmin을 사용했고, OpenSearch는 OpenSearch Dashboards를, MinIO는 MinIO Console을 사용하였습니다.

각 데이터베이스 툴의 대쉬보드

 

Docker를 활용한 개발 환경

 데이터베이스 구축을 docker-compose 로 하게 되면서 개발이 완료되었을 때 배포를 어떻게 하면 좋을지 생각하게 되었습니다. AWS의 EC2로 배포하는 것을 생각해보면 하나의 인스턴스를 생성하고 내부에 docker로 컨테이너를 실행하여 배포하게 되는데, 세개의 데이터베이스 툴을 docker-compose로 묶어둔 상황에서 이를 모두 떼어내고 각각 EC2를 생성하게 하는건 너무 오랜 시간이 소모됩니다. 그렇다고 하나의 EC2에 모든 툴을 묶어 배포하는 것은 서비스의 비중이 한 곳에 치우치게 되므로 설계상 좋지 않습니다. 그래서 찾은 방식이 AWS의 ECR을 활용하는 것입니다. ECR은 AWS의 Docker Hub라고 생각하시면 됩니다. Docker 이미지를 빌드하여 Docker Hub에 올리듯, 이미지를 빌드하여 ECR에 올리게 되면 이를 통하여 ECS를 생성할 수 있게 됩니다. ECS는 docker-compose를 기반으로 배포를 쉽게 할 수 있다는 특성이 있기 때문에 현재 상태에서 가장 적합한 배포 방식이라고 판단하였습니다.

 

중간 발표

 이번 주 8월 22일은 프로젝트 중간 발표가 있었습니다. 발표는 제가 맡아서 ' 제약사원의 AI 파트너 NaruTalk '라는 주제로 발표를 하였습니다. 프로젝트의 선정 배경을 말할 때 우리가 주제 선정을 위해 얼마나 노력했는지, 자체 테스트 및 검증을 위해 도메인 지식을 활용하기로 하였고, 제약영업에서의 AI 서비스 도입이 왜 필요한지, 어떤 Pain Point들이 존재하는지를 설명하였습니다.
이 초반 스토리텔링 부분에서 실제 제약 영업 분야에 10년 이상 종사하신 팀원 김도윤님이 제공해주신 많은 정보들과 멘토님이 조언이 정말 많은 도움이 되었습니다.

발표를 잘 마친 후 엔코아와 SK에서 현업으로 계신 심사위원님의 피드백을 받았습니다. 해당 내용은 아래와 같습니다.

• 데이터베이스의 설계가 서비스에 비해 복잡한 것 같아서 PostgreSQL의 pgVector 기능을 사용해보는 것도 좋을 것 같다.
• 다른 한 분은 회사 내부 서비스이기 때문에 OpenAI API를 사용하는 것보다 sLLM을 사용하는 게 어필 포인트가 될 수 있다.
• 사용자의 질문을 라우팅할 때 폴백처리를 하는 것도 좋지만 사용자가 선택하게 하는 선택지를 넣는 것도 좋을 것 같다.
• 문서 초안 작성 기능 같은 경우에도 폴백 되어도 내용이 추가되는 것이 없으니 사용자가 새로 내용을 입력하게 할 필요가 있다.
• 규정 위반 검토 기능은 영업 사원이 한 번 더 체크하도록 하고, 규정의 출처도 남기는 것이 좋다.

위 내용에서 주목한 점은 pgVector라는 플러그인이 있다는 것과 사용자가 기능 처리 과정에 개입할 수 있는 휴먼 인 더 루프(Human-in-the-Loop, HITL)에 대한 피드백이었습니다. 에이전트는 상황을 파악하고 스스로 일을 처리한다는 특성이 있지만 중간 중간 높은 도메인 지식을 가진 사용자에게 확인을 받으며 진행한다면 그 결과물 또한 더 정확하게 나올 거라는 생각이 들었습니다.

 

Minus : 아쉬웠던 점

  심사위원님의 피드백 중에서도 sLLM을 도입하는게 어떻겠냐는 말씀이 있었고 기획 단계에서도 같은 내용으로 고민을 했었는데, sLLM 이외에도 구현할 기능이 많았고, 프로젝트 주제가 sLLM이 아니었기 때문에 제외를 하게 되었습니다. 하지만 회사 내부 자료를 다뤄야하는 프로젝트인 만큼 sLLM을 사용하는 것이 포인트가 되었을 것이라는 생각이 오래 맴돌았습니다. 추후에 프로젝트가 마무리 되고 고도화 하는 과정에 도입해보면 좋을 것 같다는 생각을 하며 아쉬움을 남겼습니다.

 

Impressive : 인상적이었던 점

 프로젝트를 진행하면서 처음 사용해보는 기술들이 많아 조금 겁이 나기도 하고 막막하기도 했는데 일정에 쫓기며(?) 닥치는대로 배우고 써보고 하니 이제는 사용하지 않은 기술에 대한 두려움이 많이 사라진 것 같습니다. 무엇이든 시작이 가장 어려웠던 것 같습니다.