해커톤 준비하기 / 평가요소

필요한 역량?
1. 순발력
2. 기획
3. 성과
4. 발표

자료 이미지 캡쳐

경험을 위한 팁

• 새로운 기술을 하나 써보자 ! : 프로젝트에서 새로 써 볼 기술을 하나 정해보기
  • 처음 해보는 뭔가를 해볼 수 있는 기회
• 멘토링을 적극적으로 활용 : 이부분을 꼭 기록해두자 그리고 꼭 디벨롭
• 바퀴를 새로 만들지 말자
• 완벽에 추구하지 말자

• 주로 아이디어, 기술, 완성도를 봄
• 기술 후원이 걸린 경우, 기업에서 필요로 할만한 것을 만드는게 좋음.
• 해커톤은 아이디어 싸움이다!
  • 기술 경진 대회가 아님
  • 사업성이 있어야 하는 거는 아니지만 최소한 설득은 필요
  • 뻔하다면 완성도에서 승부 볼것!
• 기획과 발표에 힘을 쓰자
  • 검색을 통해 다양한 수상작 발표자료를 참고해보자
  • 발표만 기깔나서는 안됨
• 배포하면 가산점 있음
  • 실재로 해볼 수 있다면 당연히 평가가 좋음
  • 공개 채널에 테스트 링크를 올려서 반응을 보는 것도 좋음
  • 배포가 안되면 로컬에서 시연은 가능해야 함

해커톤 발표 자료는 짧은 시간에 프로젝트의 핵심 내용을 효과적으로 전달해야 하기 때문에, 구조적으로 잘 짜여진 발표 자료가 중요합니다. 발표 자료에 포함해야 할 주요 내용은 다음과 같습니다:

1. 문제 정의 (Problem Statement)

• 해결하고자 하는 문제를 명확하게 설명합니다.
• 이 문제의 중요성이나 현재의 문제점에 대해 이야기합니다.
• 문제를 해결함으로써 얻게 될 이점도 간단히 언급합니다.

2. 솔루션 소개 (Solution)

• 개발한 솔루션의 개요를 설명합니다.
• 어떤 방식으로 문제를 해결했는지, 어떤 접근 방식을 사용했는지 설명합니다.
• 솔루션의 차별화된 점이나 주요 특징을 강조합니다.

3. 기술 스택 (Tech Stack)

• 프로젝트에서 사용된 주요 기술이나 도구들을 간단히 소개합니다.
• 언어, 프레임워크, 라이브러리 등 기술적 배경을 짧게 설명하고, 그 기술을 선택한 이유를 언급할 수 있습니다.

4. 구현 과정 (Development Process)

• 프로젝트의 개발 과정을 간략히 설명합니다.
• 팀 내 역할 분담이나 개발 단계, 어떤 어려움을 겪었는지, 어떻게 해결했는지를 짧게 설명합니다.

5. 데모 (Demo)

• 솔루션이 실제로 어떻게 작동하는지 보여줍니다.
• 시연할 수 있는 경우, 실제 제품이나 프로토타입을 통해 데모를 진행합니다.
• 데모가 어려운 경우, 스크린샷이나 GIF, 동영상 등을 통해 동작 과정을 시각적으로 보여줍니다.

6. 성과 및 효과 (Results and Impact)

• 솔루션이 실제로 어떤 성과를 내는지, 혹은 예상되는 결과를 설명합니다.
• 사용자나 비즈니스에 미칠 긍정적인 영향이나 개선 효과를 구체적으로 설명합니다.

7. 향후 계획 (Future Plans)

• 프로젝트를 향후 어떻게 발전시킬 것인지에 대해 간단히 언급합니다.
• 추가로 구현할 기능이나 개선할 점에 대해 설명하고, 프로젝트의 확장 가능성에 대해 이야기할 수 있습니다.

8. Q&A

• 마지막으로 청중의 질문에 답변할 시간을 마련합니다.
• 가능한 질문들을 미리 예상하고 준비해 두는 것이 좋습니다.

발표 자료의 구성 팁:

• 간결함: 슬라이드마다 너무 많은 텍스트를 넣기보다, 핵심 내용 위주로 간결하게 정리합니다.
• 시각적 자료 활용: 도표, 이미지, 동영상 등 시각적인 자료를 적극 활용하여 청중의 이해를 돕습니다.
• 스토리텔링: 프로젝트가 시작된 배경, 문제 해결 과정, 결과를 이야기 형식으로 풀어가는 것이 좋습니다.
• 시간 관리: 발표 시간에 맞추어 각 섹션에 얼마나 시간을 할애할지 미리 연습합니다.

이 구조를 기반으로 하면, 해커톤 발표에서 핵심 내용을 효율적으로 전달할 수 있을 것입니다.

문제점 발생 및 해결 과정은 해커톤 발표에서 매우 중요한 부분 중 하나일 수 있습니다. 특히 심사위원들이 프로젝트의 완성도뿐만 아니라 팀이 직면한 도전 과제를 어떻게 해결했는지, 그리고 개발 과정에서의 창의적 문제 해결 능력을 평가할 가능성이 높기 때문입니다. 이 과정을 포함하면 다음과 같은 장점이 있습니다:

문제점 발생 및 해결 과정을 포함해야 하는 이유:

1. 문제 해결 능력 강조:

   • 개발 과정에서 겪었던 문제점(예: 기술적 장애, 시간 부족, 협업 문제 등)을 설명하면, 팀의 문제 해결 능력을 강조할 수 있습니다.
   • 심사위원들에게 팀이 단순히 프로젝트를 구현한 것이 아니라, 실질적인 문제를 해결해 나가며 프로젝트를 완성했다는 점을 어필할 수 있습니다.

2. 기술적 이해도 및 깊이:

   • 기술적으로 어려운 문제를 어떻게 해결했는지를 설명하면, 팀의 기술적 이해도가 높다는 인상을 줄 수 있습니다.
   • 특히 창의적인 해결 방안이나 독특한 접근 방식을 사용한 경우, 그 부분을 강조하면 높은 평가를 받을 수 있습니다.

3. 실제 경험 공유:

   • 문제를 해결하는 과정에서 배운 점을 공유하면, 프로젝트가 단순한 결과물이 아니라, 실질적인 경험을 바탕으로 만들어졌다는 점을 전달할 수 있습니다.
   • 이는 다른 참가자나 청중에게도 좋은 인사이트를 제공할 수 있습니다.

4. 진정성 있는 발표:

   • 단순히 성공 사례만 이야기하는 것보다, 어떤 어려움이 있었고 이를 어떻게 극복했는지에 대한 이야기는 발표에 진정성을 더해줍니다. 이는 청중의 공감을 얻을 수 있습니다.

문제점 발생 및 해결 과정 포함 시 구성 방법:

1. 문제점 간단히 설명:
   • 어떤 문제에 직면했는지 간결하게 설명합니다. 예를 들어, 시간 제약, 기술적 장벽, 기능 구현 중 발생한 오류 등.
2. 해결 방안:
   • 문제를 어떻게 해결했는지 구체적으로 설명합니다. 이를 해결하기 위해 팀이 협력하거나, 새로운 기술을 배웠거나, 우선순위를 조정했는지 등의 내용을 포함합니다.
3. 결과:
   • 문제 해결 이후 프로젝트가 어떻게 진전되었는지 설명합니다. 문제 해결로 인해 얻은 교훈이나 성과도 함께 이야기할 수 있습니다.

예시:

• 문제: "백엔드 서버에서 데이터를 실시간으로 처리할 때 병목 현상이 발생했습니다."
• 해결 방법: "이를 해결하기 위해 캐시 시스템을 도입했고, 데이터 흐름을 최적화하기 위해 비동기 처리 방식을 적용했습니다."
• 결과: "이 덕분에 응답 속도가 50% 개선되었고, 실시간 데이터 처리에 문제가 없어졌습니다."

결론적으로, 문제점 발생 및 해결 과정을 발표에 포함하면 발표 자료가 더 풍부해지고, 심사위원과 청중에게 깊은 인상을 남길 수 있습니다.