정글 최종 발표 일기

다들 안녕하신가요? 5주동안 달려온 나만의 무기를 크래프톤 사옥에 가서 발표를 끝마친 날입니다. 사실 이글은 한참뒤에 쓰는 일기지만 뜻 깊었던 경험을 잊지 않기위해 작성해봅니다.
2024.7.20

 

나의 자랑스러운 팀원들

 

발표 전까지

떨리는 마음으로 눈을 뜨고 비장한 마음으로 이른 아침에 무수히 많은 발표들을 했던 407호로 향했다. 발표현장을 상상하며 혼자 허공에 발표를 했다. 그전까지는 많이 떨렸었는데 연습을 반복하며 작은 자신감을 쌓아왔기 때문에 마음이 차분해지고 조금 덜 떨수 있지 않았나 싶다.

 

버스를 타고 다같이 이동하고 발표현장에 도착해서 노트북 연결 테스트, 시연을 위한 팀원들의 조용한 공간을 빠르게 찾고 정신 없었다. 특히 소리가 잘들리는지 프로젝터 해상도에 알맞는 우리 웹사이트의 화면 확대율은 몇인지 계속 줄 서가며 체크했었다. 

다음 발표에는 현장에 도착해서 장비 연결후 체크할 사항들을 체크리스트를 만들어야겠다고 느꼈다. 우리 차례가 왔을때 한번에 다 체크하고 와야되는데 꼭 자리에 돌아오니 빼먹은게 생각나더라.

 

다른 팀의 시연전에는 demo 신에게 기도했었다. 잘되라고. 잘되더라 멋지다

 

끝날때 까지 끝난게 아니야!

발표 현장

 

우리 미코의 차례가 왔고 나는 사람들과 눈을 맞춰가며 발표를 했다. 자신있고 밝게.

 

하지만, 시연중 에러가 발생해 결국 영상으로 시연을 대체하게되었다. 최악이었고 너무 속상했다.

시연중 청우형이 다가와 우리가 사용하는 api 측 에러가 발생했다고 전달 받았고, 그때 내가 할 수 있는 최선은 영상을 바로 트는 것이라 생각했다. 우리가 한것을 보여주는 것에는 부족함이 없으니...

사실, 바로 복구시켜서 시연이 가능하게 되었는데, 청우형이 영상 재생 중반이더라도 끊고 나에게 알려줘서 시연을 할껄 이라고 후회도 많이 된다고 했다.

 

그럼에도 그 순간에 내가 할 수 있는 최선은 최대한 밝고, 자신있는 표정으로 발표를 이어나가야 한다고 생각했다. 

최악의 순간에도 그래도 우리는 영상을 준비했고 보여주고 싶은 것은 다보여줬다 그리고 아직 포스트 세션이 남았다!!! 라는 긍정적인 마인드로 잘 발표해서 난 좋았다.

 

근데, 마치고 자리로 오니 팀원들의 상태가 너무 안좋았다. 물론 우리의 부족함과 안일함에서 온 결과라고 생각하지만, 아직 속상해 해야 할때가 아니라고 생각했다. 자신이 없어 보이는 팀에 누가 찾아와 질문을 하겠는가...

 

그래서 팀원들에게 cheer up 토크를 했다. "우리가 보여줄 수 있는건 다보여주었고 우리가 만든 결과도 나는 너무 만족해서 좋다.(진짜로 좋았다) 그리고 아직 시연을 보여줄수있는 포스트세션이란 기회가 남아있다. 우리가 자신있고 밝은 모습으로 있으면 사람들은 찾아오고 알아줄사람은 알아주니 끝까지 힘내자" 라고 했었던거 같다.

충분히 예상할 만했는데 해당 에러를 예측 못한 팀장이 미안해 ㅠㅠ

 

웃는 얼굴에 복이온다

발표모습

포스트 세션을 진행하면서 다행히 사람들이 많이 찾아와 주셨다. 내 stt 에 대해 관심이 있으신 분들이 오래 있어주셨다. 내가 일하고 싶은 곳에서 일하시는 분들이 오셔서 되게 오래 질문하고 마지막 까지 이야기를 하고 가셨다. 정말 기뻤고 내가 하고 싶은 일을 진짜 저곳에서 하고 있구나라고 얼핏 예상하게 된거 같기도하고? 무튼, 나도 저 사이에 껴서 다시 이야기를 나누고 뭔갈 만들고싶다고 느꼈다. 뽑아줘요!

 

끝나고 든 생각

제일 먼저 든 생각은 시연을 실패하게 한 에러의 원인이 무엇이었을까? 그리고 어떻게 예방할 수 있었을까? 였다.

그래서 짐싸기 전에 팀원들과 에러로그를 보았고 나는 버스를 타고 돌아가면서 이 고민을 계속했다.

별개로, 진짜 열심히했고 점점 발전해서 처음 생각과 거의 똑같이 구현이 된 우리 프로젝트가 너무 만족스러웠다. 이렇게 내 상상을 이루어준 팀원들에게 진심으로 고마웠다. 고생했어 다들.

 

후회를 후회로 남지않고 나의 성장의 경험으로 바꾸자

 

내가 이제 할일은 위와 같다고 생각했다. 어떤 경험이던 내가 가꾸기 나름이다. 그리고 나는 다음에는 이런 실수를 하지 않는 사람으로 또 성장 하고 싶었다. 그래서 팀원들에게 오늘 하루는 쉬고 회식하고, 내일 다같이 모여서 에러를 재현하고, 이런 에러가 발생해도 시연이 되도록 코드를 추가하자고 했다.

 

시연연습을 할때 내용을 연습하는 것에 너무 치중했던 것 같다. 시연에 영향을 줄 수 있는 다른 요인에 대해 꼼꼼하게 고민을 못한점과 시연의 시작을 위한 단계를 좀더 많이 돌려보고, 체계화 했으면 시연을 성공적으로 할 수 있지 않았을까? 

 

 

실패 원인

에러 원인과 그 해결 방법에 대해 따로 글을 작성할 예정이지만 이 글에도 일부 작성하겠습니다.

 

음성파일을 외부기업 stt api 에 전송하고 1초 주기로 처리가 완료되었는지 상태를 확인하고, 처리가 되었다면 결과를 받는 요청을 하는 형식으로 구현이 되어있는데, 해당기업 서비스 상태에 따라 간혹 429에러 (너무 잦은 요청)이 뜨는 것이었다. 실제로 재현해보려고 많이 시도했다. 평소에는 폴링주기를 0.01초로 바꿔도 해당에러가 안뜬다. (해당 기업 공식 문서에는 주기를 5초로 권장하고있음) 그런데 간혹 발생하는 점에서 우리는 앞과 같이 생각하게 되었다.

 

해결방법

해당 에러 발생시 해결방법은 잠시 모든 요청을 지연시키는 것이었다. 테스트를 해보았을때 5초 혹은 그 이상 요청을 잠시 중단하고 다시 보내면 정상작동하는 것을 확인했다.

 

해야할것은 3개 였다.

1. stt 요청을 보내는 서버에서 429 처리

2. 사용자에게 지연 알림 보내기

 

나는 해당 요청을 파이선 worker를 이용해 동시에 5개 처리되게 하고 있었는데,

마지막 429에러가 발생한 시간을 변수에 저장하고 지연시간(초기값 5초) 변수를 지정했다.

모든 worker는 요청을 전송하기 전에 `현재시간` - `마지막 429 에러시간` <= `지연시간` 조건을 체크하고 `참`이면 잠시 sleep 하도록 했다. 429 에러가 발생한 요청은 큐에 넣고 지연시간뒤에 다시 요청을 보내도록 했다.

 

429에러가 뜬다면 파이선 서버는 메인서버로 429상태를 보내고 메인서버는 클라이언트에게 socket.emit 으로 stt 서비스 지연중이라는 alert를 보낸다.

 

위와 같은 방법으로 문제를 해결했고, 이제 다른 세계선의 우리는 멋지게 발표를 했을 것이다. 🥲

 

마치며,

여러모로 정말 배운것이 많은 하루였고, 어려운 순간이 와도 긍정적인 마인드로 원인을 찾고 해결할 방법을 찾는 것이 나에게 위안이 된다는 것을 느꼈다. 다음엔 더 멋진 발표를 하는 나로 성장할 수 있는 경험에 감사하고 우리 팀원들과 정글 동기들 그리고 나! 진짜 고생했어!!!