[필수] 2. 가장 열정을 가지고 임했던 프로젝트(목표/과제 등)를 소개해 주시고, 해당 프로젝트의 수행 과정 및 결과에 대해 기재해 주세요.지원 부문과 관련된, 어려웠거나 인상 깊었던 문제를 해결한 경험을 중심으로 작성해 주세요. (학교수업, 경진대회, 대외활동 등)맞닥뜨린 문제를 ‘구체적’으로 기술하고, 본인의 접근 방법과 해결 과정, 그리고 실제 결과를 ‘상세히’ 기술해 주세요. 문제를 잘 해결했다면 그 경험에서 아쉬웠던 점 혹은 더 나은 방법은 없었을지에 대한 고민 과정을 함께 작성해 주세요.해결하지 못한 경험이더라도 해결을 위해 얼마나 깊이 있게 고민을 했는지 그 과정에 대해 이야기 해 주세요. ※ 코드로 설명해 주셔도 좋습니다.

"AICanvas"라는 팀 프로젝트를 열정적으로 진행한 경험이 있습니다. "AICanvas"는 pix2pix라는 딥러닝 모델을 활용해 사용자가 주어진 주제에 맞게 그린 스케치를 그림으로 변환하여 즐거움을 전달하는 것을 목표로 한 서비스입니다.

[메시지 큐를 활용한 그리기 기능 사용성 개선] 배포 환경에서 딥러닝 모델을 GPU로 서빙할 수 없는 문제가 발생했습니다. 이로 인해 EC2 프리티어 인스턴스에서 그림 변환 요청당 3초가 소요됐습니다. 기존 로직은 HTTP 프로토콜을 이용하여 클라이언트, API 서버, 딥러닝 서버간 통신이 한번에 처리되었기 때문에 해당 문제로 인해 사용자의 요청이 유실될 수 있다고 생각했습니다. 이를 해결하기 위해 AMQP 프로토콜을 정의해서 RabbitMQ로 비동기 통신을 할 수 있도록 구현하였습니다. 그 결과 서버 간 결합을 느슨하게 분리하여 유저의 요청을 안전하게 처리하고, 느린 연산 시간을 개선하는 대신 API 응답에서 다른 콘텐츠를 제공하여 사용성을 개선할 수 있었습니다.

[메시지 브로커 선택 근거의 아쉬움] 메시지 브로커 선택이 아쉬웠습니다. 기존에 EC2를 사용했던 아키텍처의 호환성을 고려하지 못했으며, Java 코드로 AMQP 프로토콜을 정의했기 때문에 큐에 대한 유지보수 및 확장에 어려움이 따랐습니다. AWS SQS를 사용했을 경우 기존 아키텍처와 연동 및 유지보수, 확장성 측면에서 좋았다고 생각합니다.

"AICanvas"라는 팀 프로젝트에서 메시지 큐를 활용해 딥러닝 모델의 연산 지연 문제를 간접적으로 해결한 경험이 있습니다. "AICanvas"는 pix2pix라는 딥러닝 모델을 사용해 사용자가 그린 스케치를 자동으로 그림으로 변환해 주는 서비스입니다.

[메시지 큐를 활용한 그리기 기능 사용성 개선] 배포 환경에서 딥러닝 모델을 GPU로 서빙할 수 없는 문제로 인해, EC2 인스턴스에 배포한 서버를 기준으로 그리기 요청 처리에 평균 3초가 소요되었습니다. 기존 로직에서는 HTTP 프로토콜을 이용해 클라이언트, API 서버, 딥러닝 서버 간의 통신을 한 번에 처리했기 때문에 사용자의 요청이 유실될 가능성이 있었습니다.

우선 모델을 서빙하는 fastAPI 서버의 워커를 늘리는 방법을 고려했습니다. 그러나 이 방법은 지연 시간 자체를 해결해주지 못하고 기존 로직의 요청 유실 가능성을 해결하지 못한 방법이라고 판단했습니다. 이에 메시지 큐를 활용해 변환 요청을 안전하게 관리하여, fastAPI 서버로 들어오는 요청을 순차적으로 처리할 수 있는 방안을 고안하였습니다.

이를 바탕으로 RabbitMQ를 메시지 브로커로 하는 서버 간 비동기 통신을 구현하였습니다. 그 결과 서버 간 결합을 느슨하게 분리하여 유저의 요청을 안전하게 처리할 수 있게 되었습니다. 또한 API 응답에서 사용자의 흥미를 이끄는 콘텐츠를 제공해 사용성을 개선할 수 있었습니다.

[메시지 브로커 선택 근거의 아쉬움] 메시지 브로커에 대한 선택지를 충분히 고려하지 못하여 유지보수 및 확장성이 저하되어 아쉬웠습니다. 애플리케이션 코드에 AMQP 프로토콜을 정의했기 때문에 큐에 대한 유지보수 및 확장에 어려움이 따랐습니다. 또 EC2를 사용 중인 아키텍처와 호환성을 고려했을 때 AWS SQS를 사용했을 경우 기존 아키텍처와 연동에 용이하고, 유지보수성 및 확장성이 향상 됐을 것입니다.