RAG / 데베 / 파인튜닝 : 굳? 이 써야 되는지 / 써도 딱히 도움이 될거 같진 않다

데이터 청크를 나누어야할 것 같은데, 현재 프로그램 구조 상 Claude가 스스로 긁어오는 부분이 있으므로 토큰 제한 컨트롤하는게 쉽지 않아보임 -> 프로그램 구조를 좀 변경해서, 일단 (전처리 과정으로) Github API 활용해서 Claude에 넣을 데이터 양 확보하고, 토큰 수 계산해주는 함수 등 사용해서 데이터 청크 나눠서 돌리는 쪽으로 가는게 좋아보임 대신 프로그램 구조가 변경되니 할일 많아질 것

3번 기능 이후, 사용자가 자신의 레포지토리들(을 분석한 포트폴리오)을 전부 넣어서 포트폴리오 한 장 정도로 만들어 줄 수 있으면 더 쓸모 있을것. 지금의 프로그램은 오히려 채용 담당자가 보고서 이 사람이 어떤것을 했는지 파악하기에 더 좋을 것 같다는 생각

녹음본 정리:

1-1. 이력서 및 포트폴리오 작성 개발자로서 포트폴리오 작성이 목표임 이력서 작성 시 저장소에 기여한 내용을 반영하고, 프로젝트별 기여도를 파악할 수 있어야 함 분석 모델을 활용하여 개발자로서의 기여도를 파악할 수 있도록 함 변경된 코드를 포함하여 포트폴리오를 한번에 전체적으로 분석할 수 있도록 함 요즘은 노션과 같은 자기계발 플랫폼을 사용하여 포트폴리오를 작성하는 추세임 1-2. 프로젝트별 기여도 분석 프로젝트별 기여도를 분석하여 이력서에 반영하는 방안을 논의 중임 토큰 제한을 두어 각 팀원의 기여도를 유관하게 반영할 수 있는 방안을 고려 중임 토큰 제한을 설정할 경우, 커밋 양이 많아지면 문제가 발생할 수 있음 이력서 작성 시 요즘의 트렌드에 맞춰, 저장소에 기여한 내용을 포함하여 포트폴리오를 작성하려는 의견이 있음 프로젝트별 기여도를 계산하여 전체 이력서에 반영하는 방안을 고려 중임 1-3. 코드 분석 및 포트폴리오 생성 코드의 변경 사항을 분석하여 이력서에 반영하는 방안을 논의 중임 프로젝트별 기여도를 계산하여, 전체 이력서에 반영하는 방안을 고려 중임 변경된 코드를 포함하여 포트폴리오를 한번에 전체적으로 분석할 수 있도록 함 요즘은 노션과 같은 자기계발 플랫폼을 사용하여 포트폴리오를 작성하는 추세임 요약본을 저장했다가, 요즘까지 작성된 코드를 통합하여 프롬프트로 제공하는 방안을 고려 중임 2. 프로젝트 제한 2-1. 코드 분석과 코밋 사용자의 코드 분석을 위해 코밋된 것 중 변경된 파일들을 분석함 분석 시 파일별로 코밋 여부를 확인하여 전체적으로 분석하기 어려움 코밋이 한번만 되고 전체가 올라온 경우, 청크를 나눠서 진행하는 것이 현실적임 파일을 나누어 분석하는 방안을 고려 중임 프로젝트 진행 시, 언어 모델이 답을 내놓을 수 있음 2-2. 레그와 데벨의 활용 레그나 데벨을 활용하여 분석할 수 있음 분석에 필요한 데이터를 임시로 저장해 두고, 사용자 기어 분석을 통해 결과를 제공함 사용자 기어 분석 결과를 데이터 저장 임시 툴로 활용할 수 있음 데이터 저장을 통해 분석의 신뢰성을 높일 수 있음 사용자 기어 분석을 위한 레그나 데벨을 적용하는 방안을 고려 중임 2-3. 코드 분석의 어려움과 해결책 코드 분석 시, 전체 코드를 분석하여 어떤 코드인지 확인하는 것이 어려움 과거 회사에서 인터넷 필요에 의해 4중 거리를 작성한 적이 있음 코드 리뷰를 통해 원래 의도했던 코드였음을 확인한 사례가 있음 코드 분석을 잘하기 위해서는 사용자 기어 분석이 필요함 코드 분석을 위한 주석과 레그 기록을 통해 원래 의도를 파악하는 것이 중요함 3. 프로젝트 분석 3-1. 프로젝트 규모와 중요성 프로젝트의 규모는 졸작 수준으로 적절한 편임 개발 규모를 중시하며, 비용보다 정확도가 더 중요함 프로젝트의 성공을 위해 기능과 작동 사항의 수정이 필수적임 3번 기능 수정이 핵심이며, 1번과 2번은 기능 수정 필요성이 낮음 기능 수정과 더불어 프로젝트의 전체적인 분석이 필요함 3-2. 분석 도구 활용 링크를 통해 코드와 분석 결과를 본인에게 전달할 수 있음 프롬프트를 통해 분석 결과를 확인할 수 있음 3번 기능 수정을 통해 1번과 2번을 핵심으로 뽑아낼 수 있음 분석 시, 오류가 발생하지 않도록 주의해야 함 지속적인 오류 분석을 통해 개선할 수 있음 3-3. 기능 분석의 한계 기능 분석 시, 모든 커밋을 분석하는 것이 아닌, 문제 발생 여부를 판단해야 함 분석 시, 시간적 제한이 있을 수 있으므로 효율적인 분석이 필요함 사용자의 기여한 커밋을 분석하여 전체 분석을 단순화할 수 있음 분석 범위를 특정 기간에 한정하여 효율적으로 진행할 수 있음 포트폴리오 분석 시, 문서화 작업과 코드 리뷰를 함께 고려해야 함 4. 프로젝트 제안서 4-1. 포트폴리오 중요성 개발자들에게 포트폴리오 제안서에 도움이 되는 결과물을 제시해야 함 이동훈 교수님은 실용성, 즉 제안서의 활용도를 중시하심 개발자들에게 도움이 되는 결과물을 만드는 데 도움이 되는지 검토가 필요함 제안서에 다양한 기능을 포함시켜서 향후 업데이트 가능성을 남겨둠 이동훈 교수님의 반응을 보고 최종 포트폴리오를 제안서에 포함시킴 4-2. 최종 결과물 평가 방법 최종 결과물 평가에 설문조사가 가장 정확하지만, 현실적으로는 힘드니 대체 방안 고려가 필요함 최종 결과물의 유용성을 홍보하는 방법도 있지만, 사용자들에게 직접 평가받을 수 있는 홍보 방법도 있음 서버를 사용하지 않는 것이 좋을지, 아니면 클로드 API를 사용하는 것이 좋을지 고민이 필요함 서버 사용 시 비용 발생과 우회 가능성에 대해 고려해야 함 문제점은 깃허브 API 사용, 방역적 문제, 논의에 대한 문제가 가장 큼 4-3. 지도점검표 제안 이동훈 교수님의 지도점검표 업로드 지도 내용과 확인 사인을 포함한 타이핑을 편하게 하여 효율적으로 사용하기 위함 지도 내용은 사인만 받으면 되므로, 타이핑 후 다음에 확인하는 방법 제안 사인은 한글로 그려 이메일로 받으면 됨