[프로젝트 회고록] Co Labor를 마치며,,,

1. 프로젝트 소개

 

1-1. Co-Labor : 외국인 근로자 서포트 플랫폼

• 외국인 근로자들이 한국에서 안정적으로 정착하고 적응할 수 있도록 돕는 플랫폼
• 일자리, 정보 부족, 법률 등 외국인 근로자들이 겪을 수 있는 다양한 문제 해결에 도움을 줌
• 프로젝트 인원 : 4명 ( 백엔드 3명, 프론트 1명)
• 개발기간: 2024.07.01 ~ 2024.07.22 / 2024.07.30 ~ 2024.08.02 / 2024.10.03 ~ 2024.10.18

 

 

이 프로젝트는 사회적 약자 지원에 대한 주제에서 외국인 근로자도 사회적 약자에 포함되지 않을까? 에서 시작된 프로젝트이다. 

우리나라의 저출산은 점차 심해지며, 일손은 부족해지고 이에 따라 외국인 채용을 늘리는 추세이다. 대한민국이 아시아 최초의 다문화 국가가 된 그 흐름과는 다르게 이에 대한 서비스, 특히 IT 서비스는 상당히 부족했고 우리는 이 부분에 집중했다.

 

Co-Labor 프로젝트는 노동자(labor)와 함께(co)한다는 의미에서 지어졌다.

 

주제를 정한뒤 우리는 노동자와 함께 어우러지는 사회를 만들기 위해 어떤 기능이 필요할지 생각해 보았다.

외국인 노동자가 가장 필요로 하는 기능은 뭘까? 우리 프로젝트의 궁극적인 목표는 뭘까?

 

아무래도 한국에서의 적응과 좋은 환경에서의 노동일 것이다. 이에 우리는 외국인 노동자가 한국에서 취업을 준비하고, 취업 이후에도 적응을 잘 마치기 위해 다음과 같은 기능들을 마련했다.

 

1. 기업 정보와 채용공고
2. 법률 챗봇
   한국에서 발생할 수 있는 취업 시장과 근무 중 발생할 수 있는 법적 문제들을 법률 챗봇을 통해 조언을 구할 수 있다.
3. 지원센터&병원 지도
   근무 중 발생할 수 있는 문제들을 해결할 때 도움이 될 수 있는 외국인 노동자 지원센터의 위치와 근처 가까운 병원의 위치를 확인할 수 있다.

Pelicans

 

1-2. Co-Labor 기능 소개 및 시연영상

 

 

1-3. 시스템 아키텍처

2. 프로젝트 진행 과정

 

2-1. 프로젝트 협업

 

프로젝트는 같은 대학교 동아리 소속의 동기들과 진행했다. 아무래도 동기이고, 학교에서 매일 만날 수 있다 보니 소통이나 회의가 굉장히 편했다.

이번 프로젝트를 진행한 팀 이름은 펠리컨이다. 

펠리컨은 왼쪽 사진처럼 일단 입에 넣어본다. 우리도 마찬가지로 일단 시도해 보고 입이 찢어져도 포기하지 않는다. 결국에는 얼마나 많은 시간을 쓰던 노력을 하던 삼키고 소화시키기에 

굉장히 잘 어울리는 팀명이라 할 수 있겠다.

 

 

Co-labor프로젝트를 진행하면서 여러 공모전에 참가하면서 진행되었는데, 여러 개 공모전을 함께 관리하기 위해서 노션에서 각 프로젝트별 페이지를 따로 만들어 프로젝트 단위로 관리하고, 칸반보드를 통해 협업을 진행했다.

 

 

 

우리는 모두 학교에서 진행하는 프로젝트는 여러 번 했었지만, 제대로 구색을 갖추고 컨벤션과 Git 등 협업 규칙들을 체계적으로 기획한 뒤 진행하는 프로젝트는 처음이었다.

언제까지 주먹구구식 개발을 할 수는 없기에 이번 프로젝트의 목표 중 하나를 좋은 협업과 Git 사용으로 정했다.

 

협업은 git, 노션, 피그마를 통해 진행되었다. 

우선 피그마를 통해 전체적인 틀을 잡고, 필요한 기능들을 노션 칸반보드에 할당한 뒤 github 이슈를 생성한다. 생성된 이슈 번호에 맞게 브랜치를 파서 작업하는 것이 기본 규칙이다.

• 사실 이 방식도 굉장히 아쉬운 게 일단 기능들을 명확하게 명세한 뒤 노션에 큰 흐름을 적어두고 개발하는 편이 더 좋았을 것 같다. 이렇게 하다 보니 API 명세 작성도 굉장히 어렵고 어떤 스택을 사용할지 배포는 어떻게 할지에 따라 개발 방식 또한 달라질 수 있는데 이 부분을 고려하기도 힘들었다.

 

git의 사용은 GitFlow방식을 채택하여 main은 배포용 브랜치로 두고 develop 브랜치에 검증이 완전히 끝난 기능들만 push 한다. 각 기능들은 task로 적절히 나누어 이슈에 배치하고 이슈 번호대로 브랜치를 파서 개발한 뒤 테스트가 완전히 끝나면 develop 브랜치에 병합하는 방식이다.

• 굉장히 좋은 방식이고 유용했지만 자동화된 테스트가 없었다는 점이 아쉬웠다. 개발 규모가 점점 커지면 브랜치를 파서 기능을 새롭게 개발한 뒤 통합 테스팅을 하는 과정이 굉장히 힘들었다. 다음에는 꼭 테스트 자동화...

 

 

2-2. Challenges

나는 이번 프로젝트에서 크게 백엔드, 배포, AI 검색, 챗봇 RAG 기법 적용 정도를 맡았다.

그 외에도 프론트도 살짝 도와주고 데이터베이스도 도와주고 했지만 대부분의 시간은 챗봇에 사용했던 것 같다.

 

백엔드

백엔드 부분에서 어려웠던 부분은 구현이 아닌 설계였다.

API 명세 없이 개발에 먼저 들어가다 보니 어디로 요청했을 때 어떤 응답을 줘야 하지? 혹은 어떤 종류의 응답들이 필요할까.. 이 부분은 응답에서 순환 참조가 나타나는데 이를 애플리케이션에서 처리해야 하나 클라이언트에서 처리해야하나 등의 고민들이었다.

 

처음 프로젝트를 시작했을 때는 기초 지식도 많이 부족하고 협업을 통한 개발이 어떻게 이루어지는지, 어떤 부분에서 기획이 중요하다는 건지 전혀 알지 못해서 API도 내 마음대로 짜고 데이터베이스 설계부터 서비스 계층에서 하는 일까지 모두 내 마음대로 구성하고 구현했다.

이 부분이 나중에 굉장히 발목을 잡았는데, 데이터베이스를 한 번 잘못 설계하니 거의 모든 계층을 뜯어고치면서 데이터베이스를 다시 짜야했다. 또 어느 기능에서 어떤 방식으로 데이터를 제공할지 기획이 되지 않아서 불필요한 스키마나 API가 생기는 문제점도 존재했다.

 

이런 문제들을 해결하는 과정에서 기획, 설계의 중요성뿐 아니라 어떤 방향으로 기획을 해야 하고 어째서 이 부분은 이렇게 설계했고까지의 비교적 깊은 부분 까지도 설계하는 것이 좋다는 점을 느꼈다.

 

배포

백엔드 개발을 어느 정도 마친 뒤 우선 배포에 들어갔다. 배포에서는 컴퓨터의 흐름, 네트워크의 흐름을 정확하게 알지 못한다는 점에서 어려움을 겪었다.

클라이언트가 어떤 과정으로 웹 브라우저를 통해 https 요청을 보내고, 어떻게 DNS 서버를 거쳐 백엔드까지 도달하는지 정확한 이해가 없으니 오류가 생겨도 원인을 파악할 수 없었다.

 

우선 시간이 많이 없어서 여기저기 글도 많이 찾아보면서 일단 문제 해결에 집중했다. 특히 https에서는 cloudfront 문제인지 nginx 문제인지 백엔드 CORS 설정이 문제인지 모든 경우의 수를 따져가며 원인 파악보다는 단순 문제 해결에 집중했고 찜찜함만 남은 채로 배포를 마무리했다.

마침 운이 좋게도 3학년 1, 2학기때 컴퓨터 네트워크, 서버 프로그래밍 수업을 들으면서 다른 공모전에 참가하며 새롭게 배포를 마쳤고 컴퓨터의 흐름에 큰 깨달음이 있었다. 

이해와 함께 문제를 만나면 그 문제의 원인을 분석할 수 있고 어느 부분에서 문제가 생겼는지 알게 되니 문제 해결은 굉장히 쉬웠다. 또, EC2와 RDS의 인바운드 규칙을 편집하는 과정에서 네트워크의 흐름에 대해 깊은 이해가 가능했다.

 

AI 검색과 챗봇

다음은 AI 검색인데... AI에 대해 공부가 전혀 되지 않은 채 머리를 박으며 구현에 들어갔고 결국에는 실패로 돌아간 기능이다. 어찌어찌 gpt와 github의 다른 코드들을 계속 보면서 kobert로 구현은 잘했는데 성능은 정말 최악이었다. 

사용한 방식은 semantic seach이다. 자세한 방식은 다음과 같다.

1. gpt api를 통해 query expansion
2. kobert로 데이터베이스에서 유사한 내용을 검색

데이터베이스를 키워드마다 순회하므로 시간적인 성능도 굉장히 안 좋았고 데이터베이스에 내용이 추가되면 새롭게 임베딩을 생성해야 해서 실제로도 사용하지 못할 만큼의 response time이 나타났다.

또한 gpt가 생성해 내는 추가 쿼리들은 기존의 context를 전혀 유지하지 못했고 gpt 보다는 다른 방식으로 도메인 특성을 유지하면서 쿼리를 확장시키는 방향이 맞았다.

또 데이터베이스의 검색 대상 내용들은 키워드보다는 문장 중심이었기에 kobert와는 적합하지 않았다.

 

당시에는 이런 배경지식들이 전혀 없었기에 AI 검색은 포기하고 대신 챗봇을 고도화시키는 방향으로 접근했다.

챗봇은 기존에는 그냥 gpt API + 프롬프트 엔지니어링을 통해 대답만 생성해 내는 것에 국한되었다.

나는 조금 더 도움이 되게끔, 특히 나와 비슷한 상황에 처한 사람들의 사례를 찾아보면 어떨까? 에서 시작하여 RAG 기법을 적용하였다.

사실 내가 사용한 건 RAG와는 조금 다른데, 답변의 내용을 가지고 generation을 하지는 않고 답변에 포함시키는 방향으로 구현했다.

 

왜냐하면 Retreival의 결과가 판례다 보니 굉장히 길었고 generation 과정에서 실제 판례가 왜곡된다면 이는 큰 문제로 이어질 가능성이 높았기 때문이다.

 

이렇게 파이프라인을 잘 짜놓고 elasticsearch로 구현을 했는데 완전 처음 사용하는 기술이고 도커에 대한 지식도 없어서 구현하는데도 꽤나 힘들었다.

특히 EC2 서버에서 elasticsearch를 사용할 때 프리티어 요금제의 성능상 제약 때문에 고생을 많이 했었다.

 

사전 지식이 없는 상태로 나름의 정보 검색 기술들과 인공지능 기술들을 사용해 보았고 그 뒤 학교 수업에서 인공지능, 정보검색을 수강했는데 시기적으로도 굉장히 운이 좋았던 게 내가 사용한 기술들이 어떤 원리로 돌아가고 어떤 구조로 이루어져 있는지 더욱 깊게 이해할 수 있었다.

---

3. 결과 및 성과

 

- 2024 새싹 해커톤 본선 진출

- AI메이커톤 경진대회 최우수상

- 2024 공개 SW 개발자대회 본선 진출 및 우수작 선정

 

- 2024년 스마트 & 디지털 페스티벌 VIP초청

---

4. 후기 및 배운 점

프로젝트를 진행하면서 겪은 어려움들과 이들을 해결하는 과정에서 배운 점이 굉장히 많았다.

협업

백과 프론트에서 어떤 기획들이 중요한지 어떻게 협업을 해야 할지 깨닫게 되었다. API 명세에서도 많이 느꼈지만 배포 부분에서도 많이 느끼게 되었는데, 특히 https 배포를 할 때 프론트의 설정이 어떻게 되었는지를 잘 이해해야 Nginx, EC2 인스턴스의 인바운드 규칙을 잘 설정할 수 있었다. 이 과정에서 기획이 왜 중요한지 협업을 어떻게 해야 하는지 등의 내용들 뿐 아니라 네트워크의 흐름을 이해한 것이 가장 큰 성과였다.

클라이언트가 어떤 과정으로 SSL을 받아서 어느 어느 서버를 거쳐 백엔드 서버까지 도달하는지 잘 알아야 그 과정을 매끄럽게 코드로 풀어낼 수 있고 여기까지 숙달이 되어서야 보안을 신경 쓸 수 있는 것이다.

 

백엔드간의 협업도 상당히 느낀 게 많았는데 사소하게는 변수명, 네이밍 규칙, 메서드 규칙 정도가 있겠고 상세하게는 어떤 기능을 누가 담당하고, 이 기능과 연계된 부분은 어떻게 처리하고 이런 협업도 굉장히 중요했다. 예를 들어 로그인이 구현되지 않은 상황에서 기업과 관련된 CRUD를 작성하다 보면 로그인이 추가된 이후 매끄럽게 기업 CRUD를 수정할 수 없었다.

사실 협업보다는 OCP 원칙을 지키지 않아서 일어난 일 같기도 하지만 협업과 기획이 잘 되어서 인터페이스만 잘 설정했어도 훨씬 수월한 개발이 가능했을 것이다.

이런 부분에서 인터페이스와 관련된 공부가 많이 부족하다고 느꼈다.

 

데이터베이스 디자인

다른 부분도 다 그렇지만, 특히 데이터베이스에 관해서는 스키마 삭제/수정이 굉장히 굉장히 번거로웠다. 무결성 원칙들에 관한 내용도 그냥 CASCADE로 설정했다가 꽤나 고생했었고 참조 관계도 막 설정했다가 불필요한 decomposition이 존재하거나 순환 참조 문제도 많이 생겼었다. 특히 테스트 데이터를 대량 삽입하고 나서는 스키마에 비효율성을 발견해도 더 이상 수정할 수 없었다. 

정규화, 트랜잭션 이런 부분은 오히려 공부하고 적용하면 돼서 그렇게 문제는 아니었지만 무결성 제약을 어느 테이블에 어떻게 적용해야 할지, 참조 관계는 어떻게 설정해야 효율적 일지는 굉장히 많은 공부가 필요해 보인다.

 

애플리케이션 딴에서 처리하는 것과 클라이언트에서 처리하는 것 혹은 DBMS에서 처리하는 것, 세 방향이 있어서 이 부분들을 어떻게 설정하는지에 따라 성능이 많이 갈릴텐데 시간이 부족해서 거의 다 어플리케이션 딴에서 처리한 것 같아 아쉬운 부분이 있었다.

 

챗봇 개발 및 AI 트렌드

이번 챗봇 개발 및 elasticsearch 적용 등 새로운 기술들을 많이 사용했는데 이 부분은 크게 어려운 점이 없었다.

챗봇이야 그냥 API를 쓰면 되는 거고 elasticsearch도 환경 설정만 까다롭지 결국에는 다 API여서 쉽게 적용했다.

새로운 기술에 대해서는 사용보다는 언제 어떤 기술을 적용해야 하고, 그 기술을 사용했을 때 문제점이 무엇인지, 원리가 뭔지를 고민하는 부분이 더 어려웠다. 

특히 elasticsearch를 사용했을 때 해당 기술에서 제공하는 유사도 검색이 문장을 벡터화시키는 건지 뭐를 벡터화시키는건지 잘 모르겠어서 성능이 좋지 않았을 때 어느 부분이 문제인지 판단하는 것이 불가능했다. 또 RAG를 적용했을 때 보안과 관련된 트렌디한 이슈가 존재했는데 전혀 모르고 있었다가 심사에서 지적을 받기도 했었다.

 

이런 부분에서 느낀 게 내가 어떤 기술을 적용해야겠다고 느꼈으면 다음과 같은 사항들은 반드시 숙지하고 적용하는 편이 좋다.

1. 왜 이 기술을 이 task에 적용하려 하는지. 적용해서 도달하려는 목표점이 무엇인지.
2. 이 기술을 적용했을 때 task가 어떻게 풀리는지.
3. 어떤 원리로 어떻게 기술이 동작하는지. - elasticsearch 라면 벡터화 방식 정도가 되겠다.
4. 이 기술을 적용했을 때 성능적으로 혹은 비기능적으로 더 안 좋아질 부분이 있을지.

 

분명히 급하게 새로운 기술들을 적용하다 보니 마음에 들지 않고 아쉬운 부분도 많지만 자신감을 많이 얻을 수 있었다.

다시 한번 말하지만 진짜 중요한 건 기술의 사용법이 아니라 원리와 이해였다.

 

오픈소스로서의 가치

마지막에 참여한 공모전은 공개 SW 개발자 대회인데, 오픈소스로서의 가치 또한 평가하는 공모전이었다.

이에 우리는 다른 개발자들이 우리 프로젝트를 어떻게 보다 쉽게 사용하고 이해할 수 있을까를 많이 고민했고, 결론적으로는 도커를 통한 quick start와 문서들을 작성했다.

문서화는 굉장히 잘해두어서 뿌듯하지만 그럼에도 elasticsearch와 배포 쪽은 어떻게 명시를 해줘야 할지 모호한 부분이 있었고 그런 부분들이 아쉬웠다.

 

마무리

이번 프로젝트는 얻은 게 굉장히 많았다. 내 나름의 개발자로서의 가치관을 정립하게 되었고 앞으로 채워나가야 할 점도 많이 깨달았다. 무엇보다도 내 스스로 증명을 완료했다는 느낌을 받았다. 열정이 있는 분야에 대해 어느 정도 깊이 있게 공부하고 구현하고 노력도 많이 쏟고 하는 과정이 스스로 뿌듯했고 앞으로도 할 수 있다는 자신감 또한 얻게 되었다.

 

조금 더 기술적으로 들어가자면, AI에 대해 관심도가 많이 깊어져서 지금은 관련 논문도 몇 편 읽었고 아키텍처를 하나 만들어서 논문도 작성 중이다. 백엔드에 대한, 네트워크 흐름에 대한 이해도도 굉장히 깊어졌고 문제 해결 능력을 기를 수 있는 소중한 시간이었다.

 

Pelicans