나만의 무기 : 회고

나만의 무기 개요

• 5 주의 기간에 4~5 명의 팀원을 반 내에서 모집(!)하여 프로젝트를 진행한다.
• 프로젝트는 마지막 주 발표(시연)와 포스터를 통해 협력사, 정글 구성원과 결과를 공유한다.

 

진행한 프로젝트: 로드메이커

해당 프로젝트에 대한 내용은 Github 리포지터리에 있음(아직은 개선해야 하는 부분이 많습니다!). 블로그에는 그 내용보다는 그 과정에서 얻은 기술적, 비기술적 내용들이나 문제 해결에 대한 내용들을 포스트해 나갈 것 같다.

 

Hard Skills

• Java, Spring Boot, JPA, QueryDSL
• Github Actions
• AWS CodeDeploy, EC2, S3
• MySQL
• 여러 Conventions: Code convention, Commit Convention

 

Soft Skills

• 놀랍게도 팀원 간 마찰이 적어 나만무 프로젝트를 원만하게 끝낼 수 있었다(원만했음에도 협업은 언제나 스트레스다. 왜 회사들이 "같이 일하고 싶은 사람"을 뽑고 싶은지 알 수 있었다.).
• 다만 스택을 처음부터 단기간에 끝낼 수 없는 기술 스택을 선정함으로써 마무리 발표에서는 많은 것을 보여줄 수 없어 주목받기는 힘들었다(프로젝트 진행하며 모두 알고 있던 사실).

 

1. 발표

질문: GPT API의 멀티스레딩은 어떻게 구현하였는지?

사실 대답을 제대로 하지 못하였다: 스레드 풀을 이용하여 여러 번 단일 GPT에게 답변을 요청하였음.

1. 처음 유저가 질문을 입력하면 그 질문으로 대략적인 로드맵 형태로 답변하도록 프롬프팅하였다. 이 항목들 개별로 각각 설명을 더하기 위해 GPT에 다시 요청했어야 함.
2. 되돌아온 답변을 파싱하여 프런트에서 요청한 대로 전달해 주고(화면 표시), 그것과 별개로 파싱 된 답변들을 각각 GPT에 스레드풀을 이용해 답변을 15개 정도씩 요청하였다.
3. 대략 2번 GPT에게 요청하는 것보다 조금 더 긴 시간이 소요되었다(40 초 ~ 1분 20초).
4. 이렇게 한 구현은 현재로써는 제대로 보이지만, 사용자가 늘고 모든 답변을 제대로 생성해야 할 때에 프롬프팅과 기술적으로 추가적인 해결이 필요하다.
5. 그 중 하나가 Elastic Search를 통해 캐시 된 데이터를 가져옴으로써 답변 시간을 단축시키는 것이다.

이렇게 하면 답변 시간을 줄일 수 있고, endorse가 높은 데이터를 가져옴으로써 많은 사람들에게 추천을 받은 좋은 답변을 제공할 수 있다. 사용자가 늘고 좋은 데이터가 많아질수록 GPT 요금과 태생적으로 있을 수밖에 없는 응답시간에 대한 해결이 될 수 있을 것으로 예상하고 있다. 하지만 로드맵 자체에 대한 폴리싱이 더 필요하기 때문에 결국 구현해 보아야 어떤 문제가 있고 어떻게 해결할지 실질적으로 고민할 수 있을 것 같다.

 

2. 존댓말

일할 때는 존댓말로 서로 선을 지키는게 더 좋았던 것 같다. 일 안 할 땐 그냥 이름으로 불러도, 일 할 때에는 XX님, XX 씨,라는 호칭과 함께 존댓말로 업무 요청하는 게 더 편했다(정한 것도 아닌데 팀원 모두 서로).

 

3. 업무를 확보해나가는 방법

처음 하는 내가 업무를 확보해 나가기 위해서는

1. 쉬운 일을 맡아서 끝까지 해 낸다.
2. 그 일이 끝나면 그다음 일을 요청하며 나의 능력을 증명해 나간다.
3. 팀장 입장에서는 누구는 일을 먼저 빨리 끝내고, 누구는 느리게 끝나 일을 분배하는 데 애를 먹었음.
4. 그만큼 어느 순간에는 내 일을 내가 찾아서 하는 것도 필요함.

 

4. 협업

• 서로 같이 일을 맡아서 해 나가더라도 나중에 보면 서로 이해하는 게 다른 경우가 많았음.
• Github Project를 통한 업무 분담 경험은 좋은 경험이 되었다: 
  1. 업무를 분담할 때에는 한 줄로 쓸 수 있을 정도로 일을 잘게 쪼개서 진행해야 일의 진척 상황도 알기 쉽고
  2. 코드의 충돌이 일어나지 않도록 예방하거나 일어나더라도 영향이 제한적이라는 것을 알게되었다.
  3. 어디에서 어떻게 막혔는지 파악이 편하며, 잘못 되었을 때 수습이 편리해진다.
  4. 이렇게 해야하는 것은 업무 조정 뿐 아니라 Pull request도 마찬가지 이다.
• 왜 이렇게 구현해야하는지 모르고 해 달라는 대로 하는 경우 결국에는 일을 다시 처리해야 하는 경우가 발생하였다.
  1. 댓글: 페이지네이션 하면서 페이지 내에서 댓글의 일련번호를 달아달라는 요청을 받음. 프런트에서 해달라는 대로 하였으나, 이렇게 구현하면 대댓이나 댓글을 삭제하는 기능을 구현하기 위해 다시 수정이 필요함
  2. 페이지네이션: 처음 페이지네이션을 구현할 때 프런트엔드에서 요청한 대로 Previous page, Next page URL을 전달해 주는 API를 작성하였으나, 이는 NO Offset방식으로, 쿼리 속도를 높이기 위한 방법으로 사용되는 것이다. 하라는 대로 전달만 해주도록 작성하다보니, No Offset 방식이 아닌 전달 데이터만 Previous Page, Next Page를 보여주는 의미없는 방법으로 구현된 것이다.

 

5. 프로젝트 진척

• 처음 프로젝트를 시작했을 때에는 진척이 나가지 않아 고민이 많았다.
• 결국 처음 기획에서 동시편집 에디터에 대한 계획은 파기하는 것으로 방향을 정하였다: 필수적이지 않은 기능이기도 했고 가지고 있는 스택으로 소켓 통신을 활용하는 것의 난도가 높아 진척이 되지 않는 원인이 되었다.
• 필수적인 기능을 서비스 할 수 있도록 하는 것을 목표로 하여 나머지 기능들을 우선 구현하였다.

 

소감

• 프로젝트에 도움을 주신 멘토 향로님(https://jojoldu.tistory.com/)과 크래프톤 정글의 코치님들께서 도움이 되는 말씀과 조언을 열정적으로 해 주셔서 의미 있는 한 달을 보낼 수 있었다.
• 한 달의 짧은 기간에 선보여야하는 특성상 (개발을 처음 해 보는 사람들이) Java와 Spring 스택을 선택하는 팀은 별로 없었다(마찬가지로 프런트에서 Typescript를 선택하는 곳도 거의 없었다): 기본적인 기능의 구현에도 시간이 걸려 많은 것을 보여줄 수 없었을 테니까.
• 팀원 모두 (프로그래밍에 대한 경험은 있는 사람도 있었지만) Github를 이용하여 협업을 처음 해 보는 것이어서 이 경험에 대해 느낀 점이 많았다: 앞으로 프로젝트를 디벨롭 할 때에는 Branch Convention에 대한 정책도 설정할 예정이다.