23, 23주차

22~23주차

이번에도 두 주 간 프론트엔드와 백엔드 몇명이 모여 클론 프로젝트를 진행했다. 클론 프로젝트라고 해서 서비스 되고 있는 것을 완전히 따라하는 것은 아니지만 거의 비슷하게 구현하는 것을 목표로...

 

1. ChapGPT(짭GPT) ChatGPT

다른조는 유투브, 블라인드, 익스피디아 등 여러 사이트를 클론했고 우리는 ChatGPT를 클론하기로 했다.

이름하야 ChapGPT(짭GPT). ㅎㅎ

 

간단하게 생긴 투박한 공대감성 너낌의 ChatGPT도 알고보면 자잘한 기능이 많다. 지금와서 100% 똑같게 구현하려면 해야할 일이 한두가지가 아니지만 기획 당시에는 별거 없겠지 했던 것도 사실이다. (사실 쉬워보여서 제안했고, 다른 사이트보다는 거의 완성도있고 대부분의 기능을 구현한 것은 사실이지만, 쉬운것만은 아니었다.)

 

CRUD는 지난 프로젝트에서 구현했으니, 새로운 기술을 많이 써보고 싶었으나 우선 기한 내에 완성도 있는 마무리를 주안점으로 해서 스코프를 많이 줄였다. 

 

처음 기획은 단순한 CRUD + openAI API 연결 정도. 

그외의 기능은 시간이 되는대로 하나씩 더 해보는 것으로 하고 시작했다. 

 

팀원이 AWS EC2 배포를 도메인 구입하여 SSL 인증서 발급 후 HTTPS로 백엔드 서버를 배포하는 것을 완료했고, 나도 해보고 싶은 작업이어서 팀원으로부터 어떻게 하는지 흐름과 참고 글들을 받았다. 시간나는대로 해볼 예정. 

 

나는 openAI API를 연결하고(사실 파이썬으로 해봤기 때문이기도 하고, OpenAI 기술문서가 워낙 잘 되어 있어 쉽게 완성했다.

 

결과적으로 2주 약간 덜 되는 시간과 월/수/금 저녁 4시간과 토요일 8시간 남짓을 가지고 chatGPT와 거의 같은 기능을 완성도 있게 구현해서 만족스러웠다.

 

조금 시간이 더 있었다면 채팅 수정과 regenerating response 로 인한 채팅의 분기처리, 자동 제목 설정, stream 기능을 완성할 수 있었겠다. 

 

2. SSE(Server Sent Event)

또 API의 chat completion 옵션 중 stream을 이용해서 ChatGPT와 동일하게 답변이 한글자씩 완성되는 형태를 구현해보고 싶어서, SSE(Server-Sent Event)에 대해 공부했고 간단한 예제는 성공했으나, openAI API의 chat completion의 stream 옵션을 사용해서 구현하는 것은 해보지 못했다. (FE에서 바로 통신을 하면 가능할 것 같았고, BE와 협업으로 하려면 API 응답을 다 받고 나서, SSE로 다시 보내는 방식을 해야 하는데, 그것을 구현하기엔 FE의 여유가 없기도 했고)

 

그래도 SSE로 한글자씩 써내려가는 예제를 구현하면서 대강의 이해는 얻을 수 있었고, 그걸 이글로 정리했다. websocket이나 socket.io 라이브러리를 쓸 수도 있겠지만, 오버스펙일 수도 있겠다는 생각이 들었고, 어차피 이 프로젝트 아니더라도 쓰게 될 것 같았다.

 

3. Dockerization 계속

지난번 과제를 Docker로 배포했었는데, 이번에는 내가 배포를 담당하지 않았지만 테스트용 브랜치를 내 AWS EB에 배포하는 것을 awsebcli를 통해서 진행해 봤다. 지난번 압축파일을 업로드 하는 방식과 아주 사소한 차이가 있었고, 그걸 이글에 기록했다. 

 

그리고 집에서 사진이나 자료 저장용으로 사용중인 Synology Nas에서 webstation과 docker를 이용한 배포가 가능할 것 같아서 해봤고 가능하다는 것을 확인해서 이글에 기록했다. 

 

아마 다음엔 컨테이너 허브와 github action을 이용해 CI/CD 언저리를 해보지 않을까 싶다.

 

4. FE 맛보기

React를 사용하는 프론트엔드 코드를 받아서 실행시키고 백엔드 코드를 테스트 하면서 프론트엔드 코드 구조가 궁금했고 살펴봤다. 컴포넌트를 만들어서 연결하고, state나 ref, query 등을 이용하고 axios를 이용해 백엔드 서버와 통신하고, 각 컴포넌트가 반환하는 jsx를 렌더링하는 방식으로 대충 이해했다. 알듯말듯, chatGPT와 잠깐잠깐 이해해보려고 공부했다. 

 

모두 다 알고 싶다기 보다, 백엔드와 프론트엔드가 서로 API명세서만 접점을 갖고 개발하는 것이 과연 좋은 일인가 싶어 대화 할 때 적어도 용어에 대한 이해를 갖고 싶어서 살펴봤다. 

 

5. Github organization PR/merge rule

이번에 프로젝트는 github organization을 만들어 기능별로 branch만들어(아마도?) 개발을 완료하고 PR 하면, 나머지 팀원 중 1명 이상의 리뷰를 거치고 머지가 가능하도록 rule을 설정해서 진행했다. 메인 브랜치도 보호기능을 걸고.

 

바로바로 merge 할 수 없다는 단점은 있으나 머지하기 전에 코드를 리뷰하면서 다른 팀원의 PR과 상관없는 코드가 추가되는 것을 막기도 했고, branch에서 별도의 서버기능을 구현해서 테스트 해보기도 하는 등 github과 git사용에 대한 막연한 두려움이 사라진 것 같아서 뿌듯함을 느꼈다.

 

기술메니저를 통해 여러가지를 만들어 한번에 push하는 것이 아니라 작은 조각이라도 기능별로 자주 push하는게 좋다는 조언을 충실히 수행하다 보니, 뭔가 수정할게 보이더라도 개발하거나 처리해야 하는 기능을 완료하고 push한 다음 다른 작업을 하는 식으로 개발습관이 조금씩 바뀌는 것 같아서 좋았다. 이전에는 스크롤 내리다 뭔가 주석이 필요하다 싶으면 추가하고, 내려가다 오류가 보이면 수정하고 했었고, 그렇게 커밋하려고 하면 커밋 메시지가 비빔밥이 되어버리는 경험을 가끔 했기 때문.

 

6. 아쉬움

전반적으로 계속해서 나쁘지 않은 경험을 하고 있으나, 느슨한 느낌을 지울 수가 없다. 부트캠프 과정이라는 것 그리고 전직을 목표로하는 과정인 점을 감안 조금 더 공부하거나 많은 것을 해보기 위한 지원이 있으면 좋겠다는 생각을 하게된다. 이제 실전 프로젝트의 챌린지 팀에서 아마 그런 경험을 하지 않을까 하는 기대를 하게 된다.