[목표]
멘토님께 이메일 보내기(월, 목)
프로젝트 흐름/진행도 구성(파이프 라인)
1차 MVP 발표
어제 했던 내용들 회고 작성(트러블슈팅)
씻고, 식사를 하고 부랴부랴 월요일날 제출해야됐었던 진행장표를 작성했다.


각 팀당 MVP 1차 발표가 있었다.
다음과 같은 기능이 구현완료되었다.
FFmpeg: 디바이스에서 처리와 서버 처리중 디바이스에서 처리하도록 구현
촬영과 동시에 재생가능, 각 ios, and 에서 호환되도록 인코딩 가능
웹소켓으로 채팅 시스템 추가중
중고거래는 넣는것인가? 지금보면 동영상 공유와 편집에 대해 더 많은 시간을 투자한 것같다.
→ 어느정도 동영상 쪽으로 갈 것같다.
동기화 이슈가 있을 수도 있는데? 어떤식으로 해결할 것인가? 다른 사람과의 배치가 다를 수도 있다. 상태가 변경됐는데, 다른 사람의 화면에서 반영이 안될 수도 있다. 즉, 동시성 문제를 잘 고려야할 것 같다.
서비스적으로 어떤 고민을 했는지에 대해 고찰을 한 경험을 한다면, 더욱 의미있는 높은 점수를 받을 수 있을 것이다.
자율모드, 트랙모드 구현완료
현재 속도, 시간, 페이스, 칼로리등 표시 완료
트랙 저장 및 페이스별로 조절 가능
봇 시뮬레이션 개선중
AWS에서 가르쳐준 내용을 기반으로 구성하였다. 자동으로 배포를 위한 CI/CD도 구성중이다.
시연을 했다.
결과 반영이 된다. 방금 달린 트랙도 저장된다. 봇의 페이스를 설정하여 같이 뛸 수도 있다.
기술적 챌린지 회고를 했다.
해당 내용은 PPT 작성하느라 못함. 명석이형 내용 참고
로그인 기능.
구간암호화는 제공하되 사용자 단말기의 탈취는 생각하지 않는다.
체점을 두 곳에서 하는 것은 굉장히 좋은 것 같다. 간단한 채점은 클라이언트에서도 하고, 무거운 채점은 서버에서 하기 때문에 좋은 것 같다.
선생님 입자에서 최대 몇명까지 될까? 창이 여러개 띄울 수 있는가에 대해서 고민을 해보는 것도 좋은 것 같다.
[명석이형]
완성도 측면에서 봤을때는 지라를 클론코딩하였기 때문에 하나의 이슈가 생성된 뒤에 프로젝트를 생성하고 사용자가 코드를 수정하고 이 코드의 퀄리티가 검사되고 커밋 및 풀리퀘스트가 어떻게 진행되는지까지 확인할 수 있는것이 좋을것같다.
관리자 측면과 사용자 측면에서 어떻게 사용되는지를 시연하는게 좋다.
전체적인 완성도를 단단하게 만들기보다는 부가적인 서비스의 빠른 시연을 보여주는것이 좋을것같다.
실제 이슈가 어떻게 트랙킹 되는지에 대한 관점이 더 좋다.
ses, legis는 쓰면 좋지만 우선순위를 낮추는게 좋을것같다.
이슈 트래킹의 하나의 생명주기가 돌아가는것을 보여주는것이 좋을것같다.
실제 배포환경에서 어떻게 처리할 것인지에 대해(2D 렌더링 같은 경우) 고민을 해봐야되겠다.
여러 기능들을 추가한 것이 좋다.
그러나 어떤식으로 서비스를 깍고, 퀄리티를 올릴지 고민을 해보면 좋을 것 같습니다.
우선순위를 정하고, 중요한 기능을 우선 개발해야될 것 같다.
다음주 수요일까지 MVP 개발이다. 일주일 밖에 안남았다. 완성도가 떨어져도 하고자 하는 기능을 넣어야될 것 같다.
우리가 앞으로 중요도에 대해서 이야기 해봤다. 우리가 우선적으로 처리해야되는 일들과 각자 할일을 배정했다. 특히, 깃허브 API 연동이랑 코드 품질 검사 부분 2명의 인원을 나누었다. 그리고 우리의 이슈트래킹 시스템을 개발자들이 이슈, 버그만을 추적하기 위한 서비스로 방향성을 명확히 하였다.
코치님의 말씀대로 CRUD는 거의 잘 하는 것 같으니 빨리 마무리 짓고 추가 핵심 기능과 AI를 도입할 부분을 생각해보아야겠다. 또한 이슈를 해결하는 스토리 라인을 위주로 발표하는 것이 좋겠다고 하여서 진혁이 형이 시나리오를 짜보기로 했다.
오늘 일정들과 피드백들을 러프하게 정리했다.
안녕하세요, 김도균 멘토님. 크래프톤 정글 8기 김태용입니다.
다음주 월요일과 목요일 미팅 요청을 드리고자 연락드렸습니다. 만약에 편하신 시간대가 있다면 그 시간에 맞춰서 준비해두도록 하겠습니다.
이하 생략
메일은 보냈다.
Amzon Q 를 익스텐션에 설치하였다. 이걸 통해서 EC2 DNS 설정을 할 예정이다. 또한 컴퓨터 자체에 AWS CLI을 설치하여 IAM 권한을 통해 Amzon Q가 내 AWS 콘솔을 인식을 할 수 있게끔 구축했다.
그래도 내가 수동으로 하는 것보다 수월하길 바란다…
식사를 하러 밖에 진샤이라는 중국집에 갔다왔다.


어제부터 연기되었던 dev 충돌 Merge를 확인하고 있다. 결국 어제부터 붙들었던 머지는 해결 완료 했다. dev로 로컬에서 확인했고, main으로 올려서 서버에서 정상적으로 적용되는 것을 확인할 수 있었다.
어제 미리 DNS는 사두었다.
그러나 연결을 하지 못했다.
나의 목적은 원래의 탄력적 IP를 제거하고, 다음과 같이 구축했다.
http://codeplanner-alb-629240198.ap-northeast-2.elb.amazonaws.com/
이 링크로는 접속이 된다!
이제 탄력적 주소를 쓰지 않기 때문에 ip 하드 코딩한 nginx와 관련 env 파일을 모두 수정해보겠다…
긴장되는 순간이다.
결론적으로 안된다. 리다이렉션이 이상한데로만 된다…
CloudFront에서 해당 문제가 있었다. 내가 잘 몰라서 초래한 결과였다. 커서가 알려준 다음과 같은 해결책으로 해결했다.
Origin Path
/codeplanner-alb-629240198.ap-northeast-2.elb.amazonaws.com
→ 이 부분이 잘못되었습니다!
Origin Path는 ALB 내부의 특정 디렉터리로 접근할 때만 사용합니다.
ALB(혹은 EC2, nginx)에서 /codeplanner-alb-629240198.ap-northeast-2.elb.amazonaws.com라는 경로는 일반적으로 존재하지 않습니다.
이 값이 있으면, CloudFront가 ALB에 요청을 보낼 때
예: /api/hello → /codeplanner-alb-629240198.ap-northeast-2.elb.amazonaws.com/api/hello
이렇게 요청하게 되어 404가 발생할 수 있습니다.
원래의 내용에 편집해서 사용해봤는데, 배포가 안되서 삭제한 다음 새로 추가해서 넣었다.
URL 배포가 자꾸 다른 URL로 들어가지는 문제가 계속 생겨서 CloudFront를 삭제하고 다시 작성해보았다. 그래도 잘 안되서 내일 해보기로 했다. DNS 연결이 이렇게 잘 안되다니...