Jungle Log 03

정글을 끝내며 얻었던 내용들: Soft & Hard

1. 알고리즘
   • Hard Skill
     • 파이썬 문법
     • 코딩 테스트에 대한 기본적인 베이스
   • Soft Skill & 느낀 점
     • 문제 풀이에 대한 감
     • 어떻게 알고리즘을 풀어나가야 하는가
     • 알고리즘 & 자료구조를 어떻게 공부해야하지?
2. RB Tree / Malloc / Web Server
   • Hard Skill
     • CS 기초: 웹서버, Malloc 기능
     • C
   • Soft Skill & 느낀 점
     • 문제 파고들기
     • 모르는 문제는 동료에게 물어보기
3. Pintos
   • Hard Skill
     • C
     • debugging
     • CS에 대한 심층적인 이해(부족하다)
   • Soft Skill & 느낀 점
     • 문제에 깊게 파고드는 법
     • 시간이 너무나도 부족하여 이론을 완벽하게 이해하고 코드 짜는 것이 불가능했다.
     • 초반에 빨리 이 점을 깨달았다면 코드를 좀 더 짜볼 수 있었을 텐데… 진짜 고생은 고생대로 하고 아. ㅁㅇ럼;ㅈㄷ로맫쟈ㅣ
4. 나만무
   • Hard Skill
     • Java, Spring Boot 의 시작
     • Github Actions
     • AWS
     • MySQL
   • Soft Skill & 느낀 점
     • 사람들과 협업하며 생겼던 문제들
       • 놀랍게도 팀원간 마찰이 많지 않아 나만무 프로젝트를 원만하게 끝낼 수 있었다.
       • 다만 스택을 처음부터 단기간에 끝낼 수 없는 기술 스택을 선정함으로써 마무리 발표에서는 많은 것을 보여줄 수 없어 주목받기는 힘들었다(프로젝트 진행하며 모두 알고있던 사실).
     • 발표 때 나왔던 질문: GPT API의 멀티스레딩은 어떻게 구현하였는지?
       • 스레드풀을 이용하여 여러 번 단일 GPT에게 답변을 요청하였음.
       • 처음 유저가 질문을 입력하면 그 질문으로 대략적인 로드맵 형태로 답변하도록 프롬프팅하였다. 이 항목들 개별로 각각 설명을 더하기 위해 GPT에 다시 요청했어야 함.
       • 되돌아온 답변을 파싱하여 프론트에서 요청한대로 전달해주고(화면 표시), 그것과 별개로 파싱된 답변들을 각각 GPT에 스레드풀을 이용해 답변을 15개 정도씩 요청하였다.
       • 대략 2번 GPT에게 요청하는 것보다 조금 더 긴 시간이 소요되었다(40 초 ~ 1분 20초).
       • 이렇게 한 구현은 현재로써는 제대로 보이지만, 사용자가 늘고 모든 답변을 제대로 생성해야할 때에 프롬프팅과 기술적으로 추가적인 해결이 필요하다.
       • 그 중 하나가 Elastic Search를 통해 캐시된 데이터를 가져옴으로써 답변 시간을 단축시키는 것이다.
       • 이렇게 하면 답변 시간을 줄일 수 있고
       • endorse가 높은 데이터를 가져옴으로써 많은 사람들에게 추천을 받은 좋은 답변을 제공할 수 있다.
       • 사용자가 늘고 좋은 데이터가 많아질수록 GPT 요금과 태생적으로 있을 수밖에 없는 응답시간에 대한 해결이 될 수 있을 것으로 예상하고 있다.
       • 하지만 로드맵 자체에 대한 폴리싱이 더 필요하기 때문에 결국 구현해 보아야 어떤 문제가 있고 어떻게 해결할 지 실질적으로 고민할 수 있을 것 같다.
     • 존댓말: 일할 때는 존댓말로 서로 선을 지키는게 더 편하네? 일 안 할땐 그냥 이름으로 불러도, 일 할 때에는 XX님, XX씨, 라는 호칭과 함께 존댓말로 업무 요청하는 게 더 편했다(정한 것도 아닌데 팀원 모두 서로).
     • 업무를 확보해나가는 방법: 처음하는 내가 업무를 확보해 나가기 위해서는
       • 쉬운 일을 맡아서 끝까지 해 낸다.
       • 그 일이 끝나면 그 다음 일을 요청하며 나의 능력을 증명해 나간다.
       • 팀장 입장에서는 누구는 일을 먼저 빨리 끝내고, 누구는 느리게 끝나 일을 분배하는 데 애를 먹었음: 쉬운일이 아니네…
       • 그만큼 어느 순간에는 내 일을 내가 찾아서 하는 것도 필요함
     • 협업
       • 서로 같이 일을 맡아서 해 나가더라도 나중에 보면 서로 이해하는 게 다른 경우가 많았음.
       • 의사 소통이 제대로 되지 않으면 일을 여러번 해야하는 번거로운 일이 발생함
       • 왜 이렇게 구현해야하는지 모르고 해달라는대로 하는 경우 결국에는 일을 다시 처리해야하는 경우가 발생했음
         • 댓글
           • 페이지네이션 하면서 페이지 내에서 댓글의 일련 번호를 달아달라는 요청을 받았었음.
           • 프론트에서 해달라는대로 하였으나, 이렇게 구현하면 대댓이나 댓글을 삭제하는 기능을 구현하기 위해 다시 대대적으로 수정이 필요함: 결국 일을 다시 해야…
         • 페이지네이션
           • 이 것도 처음 페이지네이션을 구현할 때 프론트엔드에서 요청한 대로 Previous page, Next page URL을 전달해주는 API를 작성하였으나,
           • 이 방법은 NO Offset방식으로, 쿼리 속도를 높이기 위한 방법으로 사용되는 것이다. 즉, 아무런 생각없이 하라는대로 한 것인데, 그렇다보니 No Offset 방식이 아닌 전달 데이터만 Previous Page, Next Page를 보여주는 가짜 No Offset방식으로 구현된 것이다: https://jojoldu.tistory.com/528
           • 왜 이렇게 해야하는지 제대로 파악하면 무늬만 구현하거나 잘못된 구현을 막고 두 번 일하는 것을 막을 수 있다.
     • 프로젝트 진척
       • 처음 프로젝트를 시작했을 때에는 진척이 나가지 않아 고민이 많았음.
       • 결국 처음 기획에서 동시편집 에디터에 대한 계획은 파기하는 것으로 방향을 정하였다.
       • 처음 기획상 기술적 챌린지를 위해 넣었던 기능이지만 핵심 기능이라고 보기도 힘들고 구현 자체가 많이 어려워 결국 시간 제약상 구현을 포기하였다:
       • 프로젝트를 진행할 때에는 모든 기능을 일정 완성도 이상으로 완성시키는 게 아니라 서비스가 가능한 정도로 일부 기능이라도 구현하여 보여주어야 한다.
         • 기능 1: 80 % 완성, 기능2: 60 % 완성, 기능 3: 30% 완성, … VS. 기능 1: 완료, 기능 2: 완료, 기능 3: 0 %, …
         • 바로 서비스 할 수 있는 정도의 완성도를 가진 기능 소수를 완료하여 보여주는 것이 중요하다.