TTS 기능 구현
프론트와 UX/UI 개선하기
발표 준비

스토리파이

TTS

Base64 인코딩

멘토링

면접 볼때 신경써야 될 것이 '왜'이다.
프로젝트를 처음 선택하는 사람이어서 쉬운 걸 선택했다는 걸로 들린다.
면접관 입장에서는 자바는 어려워서, 세팅이 편한 노드로 갔다로 들린다.

얘기를 할 때는 '나는 잘 하는 사람'이어야 한다.

이 프로젝트가 노드가 좋은 이유

• stable diffusion 같은 경우는 느리다 -> 그래서 노드가 좋다.
• 동기/비동기
• 동시성: 하나의 코어가 스위칭 하는 것.
• 병렬성: 완벽히 다른 코어가 각자 처리할 수 있다.
• 노드는 논 블록킹이다. (자바는 블록킹이다.)
• 그래스 싱글 스레드이지만 빠르다.

최종 발표(우리의 무기는)

• '내가 쓰려는 기술을 제대로 알고 썼다'는 것을 어필
• 리액트와 연관된 브라우저 작동 원리 이해하기
• 프로젝트에 대해서 셀프 질문을 많이 던져보기
• 코드 리뷰 기록을 남겨두기
• CDN 고려

UI

전반적으로 개선되었다.
ant 디자인 도입?
에러가 나면 신뢰가 떨어진다.
UI에서 버그가 나면 안 된다.
클릭했을 때 잘 되어야 한다.
로그아웃 후 얼럿 안 떠도 된다.(뎁스가 추가되면 불편해 진다.)
로그인 했을 때도 안 떠도 된다.(뎁스가 추가되면 불편해 진다.)
유저의 유스 케이스를 생각해 봐라.
책을 만들 때 스피너를 보이고, '완성 되었다고 링크 띄워주기' -> 소켓을 써야 함.
마우스 호버 이벤트
피드백 배너 스크롤 할 때 없애거나 고정되게
'스토리 만들기'는 버튼 (디자인 시스템 필요성)
푸터 만들기

UX

ux는 학습된 공감 능력이다.

리뷰

• 친구 기능 올라오면 PR 요청 달라
• PR 리뷰어 추가 후 슬랙에 태그 언급하기

소켓

나중에는 메시지 브로커를 쓸 수 있다.
책임을 분산하면 된다.
면접관이 스톰프 프로토콜을 써서 분산 시킬 예정입니다.
폴링 vs 롱폴링 vs 웹소켓 (왜 웹 소켓을 선택했는지 논리 만들기)

SSE(서버 사이드 이벤트)

GPT도 SSE를 쓰고 있다.(내부 동작 원리 파악해 보기)
웹 소켓이 되어 있다면 굳이 쓸 필요는 없다.

성능 테스트

• 글로벌의 특징: 인터넷이 낙후된 지역이 있을 수 있다.
• 서버에서 버티지 못한다. 이게 트래픽을 얼마나 받을 수 있는지.
• 제이미터(백엔드) + 모니터링툴
• 센츄리(프론트엔드)

커밋

• 커밋은 잘게 쪼개서 하는 게 낫다.
• 리뷰어가 보기 쉬워야 한다.

프로젝트

• (채팅 기능 추가 예정) 짧은 기간에 너무 기능만 구현하는 게 아닌지 약간 우려

면접 팁

면접관이 잘못된 걸 지적하면 잘못된 게 문제가 아니다.
이걸 어떻게 개선할지 대답하면 됨.

주요 내용

• 프로젝트 기술에 대해서 선택 이유를 논리적으로 준비하기
• (대표님은) '왜 썼는지 모르는 사람'은 무조건 떨어트린다.
• 친구 기능 왜 만들었는지 비지니스적으로 설명
• PO 직군에서 개발, 비지니스 경계 무관하게 나만의 논리 얘기할 수 있어야
• 우리 서비스가 장애가 나면 어떤 일이 일어날지 생각해 보기
• 요즘 시장에는 스페셜리스트보다 제너럴리스트가 환영 받는 분위기도 있다.
• 대표들 사이에서 사람을 줄였더니 생산성이 더 높아졌다는 말도 있음.
• 기업의 규모가 작아질수록 백엔드가 프론트, 프롬프트를 할 수 있는 게 메리트가 될 수 있다.

fly.io

디스크 공간 시 기존 앱 삭제

https://community.fly.io/t/flyctl-deploy-no-space-left-on-device/3411/2

flyctl apps list | grep builder

flyctl apps destroy {name}