이전 문서들에 이어서 추가적인 요구사항이 있어 이를 적어보고 활용도를 높일 방법과 기능적인 부분을 강화 해 보고자 합니다.
첫번째와 두번째 문서를 작성 했던 시점은 팀의 규모가 작았던 시절이었습니다.
1. 몇 가지 추가 건의사항이 있었습니다.
Architecture 문서의 용도의 확장을 요구했습니다.
기존 논의에서는 Architecture 또한 내부 의견을 나누기 위한 용도로 한글로만 작성을 원했었습니다.
다만, Architecture의 경우 해외 연구소에서 협업을 위하여 Architecture에 대한 내용도 영어로 작성하는게 좋을것 같다는 의견을 주셨습니다.
한글로 쓰면 번역기를 돌리면 번역기 성능에 따라서 의도가 많이 달라진다는 의견이었습니다.
개인적으로는 오히려 한글로 잘쓰면 오히려 번역기가 더 좋은 성능을 보이고 영어로 쓰게되면 완전히 정확한 표현을 쓰지 못해서 반대가 아닌가 생각이 들었습니다.
결론적으로 다 같이 의견을 나눴을때는 mermaid 같은 flow는 영어로 작성 (일반적으로도 그렇게 작성하게 되기에)
나머지 문장에 대해서는 한글로 작성하고 해외 연구소가 필요시 페이지를 번역해서 전달하는 것으로 합의 되었습니다.
2. 개인적인 요구사항도 있었습니다.
Doc as a code를 지향하기는 하나 많은 사람들이 사용하지 않으면 의미가 없다고 생각했습니다.
그래서 문서를 사용하는 사람들이 실제로 많이 사용하고 있는지 어떤 부분을 많이 사용하고 어떤 부분을 덜 사용하는지를 알고싶어졌습니다.
그래서 위와 같은 요구사항에 따라서 아래와 같은 기능들을 추가해보려고 했습니다.
1. 자동 번역 문서 작성 기능
https://github.com/teddylee777/langserve_ollama
영어 번역기가 이상하다면 단 하나의 번역기로 해결하자
라는게 저의 생각이었습니다.
Docusaurus는 언어별 페이지를 작성하면 언어별로 페이지를 다르게 볼 수 있는 기능을 제공하기에 LLM을 한번 써서 자동 번역으로 페이지를 만들면 좋을것 같았습니다.
1. 최근 한국 회사에서 한국어 + 영어가 잘 지원되는 LLM을 직접 만들기도 하며 성능도 괜찮다고 들은점.
2. 겸사겸사 LLM도 사용 해 보고 응용을 해보고 싶기도 했구요 ㅎㅎ
이 두 가지 의도가 겹쳐있었습니다.
이를 해보려면 아래와 같은 문제를 해결 할 수 있어야했습니다.
회사 환경은 외부 GPU를 사용 할 수 없는 상황이기에 이 기능에 대해서는 개인적으로 몇가지 실험이 필요했는데요.
10B쯤 되는 파라미터 모델을 사용할때 충분한 성능을 보여 줄 수 있는가에 대한 답이 필요했습니다.
아래 문제에 대한 해답이 필요했습니다.
1. 회사에 있는 Mac Studio의 GPU/NPU로도 충분한 성능을 뽑아 낼 수 있을지?
회사에서는 사용 가능한 GPU라고 한다면 제 자리에 보유중인 M1 Mac Studio 밖에 없는지라 이 정도의 하드웨어로도 충분한지가 궁금했습니다.
그리고 테스트 구동 같은 경우 코드는 집에서 짜서 가는 경우가 많았기에 집의 3070Ti로 테스트를 해보려고 했고, 최근에 잡다한 서버로 사용하기 위한 M1 Mac mini에서도 정상 동작하는지가 궁금했습니다.
결론부터 말하면 위의 오픈소스를 사용해 봤을때 아래와 같은 결과를 얻을 수 있었습니다.
GPU | 체감 성능 |
집 데스크탑 3070TI | GPT 4.0 정도의 속도로 문장이 출력 되고 결과물이 괜찮음. (사용가능) |
집 M1 Mac Mini | 10초에 한글자 정도나오는 저조한 성능을 보임 (사용불가) |
회사 M1 Mac Studio | GPT 4.0 정도의 속도로 문장이 출력 되고 결과물이 괜찮음 (사용가능) |
그래서 번역 파이프라인만 잘 짠다면 가능할 것 같았습니다.
2. docusurus 번역 파이프라인은 어떻게 짤 것인가?
현재의 docusaurus 배포 구조는 1시간마다 각 repo에 대해서 최신의 main 버전을 매번 동기화 해서 빌드하는 방식입니다.
기존 구조대로 매번 빌드를 하게 되면 번역 또한 매번 하게 될 것 같은데요.
LLM을 돌릴 수 있는 Mac Studio가 하나밖에 없어서 문서가 늘어나면 날수록 번역 페이지를 만드는데 linear하게 시간이 늘어날것 같은 생각이 들었습니다.
물론 전부다 번역시켜도 몇시간까지는 안걸릴거같아서 아직까지는 괜찮을것 같은 느낌이긴 합니다.
결정적으로 회사내 번역기나 chrome/edge 번역기도 훌륭해서 이 정도로 해결해야하는 기능이냐? 라고 하면 필요성에 대해서 의문이 조금 들긴했습니다.
일단은 전부다 번역 시키는 시간을 한번 측정해본 다음 이후의 고민 해봐도 될것 같습니다. (아직은 안해봄)
2. 유저 트래픽 추적 기능 추가
외부망과 단절되어도 작동할 것 같은 오픈소스들
sheshbabu/freshlytics: Open source privacy-friendly analytics (github.com)
CORS headers - Ackee Docs (electerious.com)
트래픽 확인 기능은 위와 같은 다양한 오픈소스/제품들이 있었는데요.
결과적으로 봤을때는 대부분 외부 API를 사용했기에 트래픽 기능은 넣을 수 없는것으로 확인했습니다.
그래서 이 기능을 추가하고싶으면 직접 오픈 소스를 구현해서 추가하거나 포기하거나
혹은 저희가 현재 사용하고 있는 datadog을 통해서 페이지에 대한 정보를 얻을 수 있을것 같습니다.
마지막 후보만이 비용은 좀 들지만 쉽게 해결할 수 있는 방법이라서 혹시나 사내 비용이 여유가 있다면 datadog의 tracker를 도입해보는 정도로 시도 해 볼 것 같습니다.
페이지의 사용률을 늘리기 위한 이런 저런 생각을 하다가 추가로 생각 해 낸 것은
저희가 지속적으로 관리해야하고 자주 보는 Confluence 페이지에 대해서 링크를 추가해두면 해당 페이지의 retention을 높일 수 있겠다 이런 생각이 들었습니다.
컨플루언스 검색으로는 어떤 키워드로 찾아야 할 지 몰라서 찾기가 쉽지 않기 때문이죠.
그래서 자주 사용할 만한 Confluence 문서 찾아서 해당 링크를 제공하는 페이지를 제공하는 기능을 최근에 추가했습니다.
본 포스트에 더 개선된 내용이나 이 외에도 추가되는 기능에 대해서는 다음 포스트를 통해서 제공할 수 있을것 같습니다.
'업무 개선 > 문서화' 카테고리의 다른 글
Docusaurus Sidebar 제목에 prefix Icon 추가하기 (0) | 2024.09.14 |
---|---|
ADR 도입기 - (2) Doc as a code의 Deploy, user guide와 SRS 관리 방법 검토 (0) | 2024.08.03 |
ADR 도입기 (1) - ADR 도입에 대한 팀원들의 의견과 피드백 (0) | 2024.06.17 |
우리 부서에 맞는 ADR (Architecture Decision Record) 템플릿 작성과 ADR 시스템 도입 (0) | 2024.05.26 |
개발 및 IT 관련 포스팅을 작성 하는 블로그입니다.
IT 기술 및 개인 개발에 대한 내용을 작성하는 블로그입니다. 많은 분들과 소통하며 의견을 나누고 싶습니다.