LGAimers 5기 - 온라인 해커톤(Phase II) - 2, 문제 발생 및 느낀점

온라인 해커톤이 끝이나면 상위 100여명은

PPT를 제출해서 코드 검증도 거쳐야 하고 코드를 설명해야 한다.

정확히 기억은 안 나지만 상위 100여명은 각 팀별로 PPT를 제출할 수 있는 3~4일의 시간이 주어진다.

그렇게 우리 팀은 오프라인으로 모였다.

총 다섯 명으로 구성된 팀이지만 한 분은 지방에 살고 있어서 해당 팀원을 제외하고 오프라인으로 진행했다.

하지만 오프라인 진출을 위해 PPT를 제작하고 코드 검증을 위해 정리를 하면서 문제가 있다는 것을 알았다.

---

문제1

처음에는 문제 없이 각자 맡은 부분을 잘 진행했다.

문제가 있다는 걸 인지했을 때는 두 시간 정도 진행하고 '한 번 전체적으로 실행을 해볼까?'하고 실행했을 때 였다.

예측을 진행했을 때 결과가 항상 같아야 한다.

하지만 결과가 달랐다...

정확히는 제출했을 때의 결과와 달랐다.

나를 포함한 한 분은 결과가 똑같이 나왔지만 제출했을 때의 결과와는 달랐다.

처음에는 이 상황을 이해하지 못 했었다.

엘리스에서 제공하는 클라우드 환경에서 진행하는 데 결과가 다른 이유는 random_state를 설정하지 않았을 때 발생하지만

무작위성이 있을 수 있는 부분에 random_state를 설정했기 때문에 결과가 같아야 한다.

대체 무슨 상황이지....

---

원인 및 해결1

우리 팀은 각자 모델을 계속 돌리면서 최적의 하이퍼파라미터를 찾았고 그것을 기반으로 최종 제출했다.

따라서 다섯 명 중 가장 좋은 점수를 보여준 팀원의 결과를 제출했다.

하지만 그 팀원은 엘리스에서 제공하는 환경에서 작업을 진행한 것이 아닌...

개인 로컬 환경에서 진행했다.

파이썬, 라이브러리... 버전이 달랐다. 그래서 같은 결과가 나오지 않았던 것이다.

다행히 버전을 맞추고 같은 결과가 나오는 것을 확인하고 잘 넘어갔다...

---

문제2

 

엘리스에 제공하는 환경에는 code.ipynb, data폴더에 train, test csv 파일이 있다.

모든 코드는 code.ipynb 파일에서 작성하고 해당 파일을 제출하는 것이다.

하지만 코드를 최종적으로 제출한 팀원은 대회 규칙을 제대로 확인하지 않았고

개인 로컬 환경에서 코드를 작성하고 결과를 제출한 것이다. 당연히 code.ipynb 파일은 비어있는 파일이었다.

솔직히 이때 화가 좀 많이 났었다...

허허허 우리 금쪽이...

---

해결

엘리스에 문의를 할 수 밖에 없었다. 하지만 주말이라 답장이 바로 오지 않아서 마음 고생 많이 했다.

월요일 아침

정말 다행히 발표자료를 제출할 때 코드도 같이 첨부하면 된다고 답장이 왔다.

월요일 아침부터 좋은 소식을 듣고 신나게 운동하러 갔다.

---

이렇게 우리 팀은 9월 한 달을 성능을 끌어 올리기 위한 회의를 거의 매일 진행했다.

---

 

다행히 우리 팀은 위에서 말했듯 문제가 터졌을 때 한 사람을 탓하지 않았고 모두에게 상황을 공유하고 해결하기 위해 노력했다.

 

버전이 달라서 예측 값이 달랐을 때

버전이 달라 결과다 다르게 나올 때 바로 requirments.txt를 뽑아서 모두에게 공유했다.

같은 결과가 나온 분이 있다는 것을 알고 버전 문제라는 것에 확신이 생겼었다. 이렇게 문제를 해결할 수 있었다.

 

코드 제출에 문제가 있었을 때

사실 이 때는 할 수 있는 것이 없었다. 운영진에게 문의를 하고 기다리는 방법밖에 없었다.

모두가 누구를 비난하거나 기분 상한 것을 티내지 않고 차분히 답장을 기다렸다.

이렇게 문제르 겪고 해결하고 나니깐 팀원들끼리 더 친해질 수 있었다.

그리고 8월 한 달 진행했던 온라인 해커톤 보다 오프라인 해커톤을 준비했던 기간에 더 의미있게 보냈던 것 같다.

본선 진출에 성공했다고 만족한 것이 아닌 뭐라도 하나 더 찾아내고 0.01 점이라도 더 좋은 성적을 내기 위해 모두가 열심히 참여했다.

---

느낀점

버전 관리와 팀워크의 중요성을 크게 느꼈다. 팀 프로젝트는 모두가 같은 환경에서 작업한다고 생각하기 쉽지만, 현실은 그렇지 않았다. 특히, 파이썬이나 라이브러리 버전의 차이로 인해 예측 결과가 달라질 수 있다는 점을 직접 경험했다. 버전 관리를 소홀히 하면, 아무리 잘 짜인 코드라도 다른 환경에서 다른 결과를 초래할 수 있다는 사실을 깨달았다. 문제를 발견한 후 빠르게 requirements.txt를 생성하고 팀원들과 공유하여 같은 환경에서 작업할 수 있도록 한 점은 해결의 중요한 부분이었다.

하지만 그보다 더 중요한 것은 팀워크의 본질이었다. 팀원이 규칙을 놓쳤거나 코드 제출 과정에서 문제가 생겼을 때, 누구 한 사람만을 탓하는 것은 올바른 해결책이 아니며, 모두가 같은 책임을 나누고, 함께 해결해야 한다는 것을 이번 경험을 통해 깊이 느꼈다. 팀 프로젝트에서는 개개인의 책임보다는 전체 팀의 책임이 중요하다는 사실을 다시 한 번 배웠다.

우리 팀은 초반에 각자 맡은 역할에 충실하며 개인 플레이로 프로젝트를 진행했다. 각자가 맡은 부분에만 집중하고, 다른 팀원이 어떻게 분석하고 결과를 도출하는지에는 관심을 가지지 않았다. 이로 인해 첫 단추를 잘못 끼운 것처럼 중요한 초기 조정이 부족했다. 첫 단추를 잘못 맞췄을 때 마지막 단추를 끼우기 전까지는 잘못된 것을 모른다. 팀원들과 회의를 통해 생각과 코드를 공유하고 함께 해결하려는 노력 덕분에 가운데 단추들은 맞춰졌다. 하지만 마지막에 다다랐을 때 최종적으로 모든 것이 완벽하게 맞물리지 않았다. 그럼에도 모두가 함께 문제를 해결하기 위해 노력하면서 문제를 해결할 수 있었다.

앞으로의 팀 프로젝트에서는 초기 단계부터 팀원들이 서로의 진행 상황과 분석 방법에 관심을 가지고, 공유와 소통을 더욱 강조하는 것이 필요하다는 것을 배웠다. 문제 해결뿐만 아니라 처음부터 끝까지 모든 과정에서 팀이 하나가 되어야만 프로젝트가 성공적으로 끝날 수 있다는 교훈을 얻었다.