Azure AI Developer 해커톤 (수상내역) / 회고록

https://devpost.com/software/azurefarming?ref_content=my-projects-tab&ref_feature=my_projects

AzureFarming

Microsoft 주관 Azure AI Developer Hackathon 2025에서 수상

'디자인' 부문은 소프트웨어와 서비스 설계를 평가

 

해커톤 수상 내역

저는 2월 말 졸업하며 해당 Microsoft Azure AI Developer 해커톤을 진행하게 되었습니다.

해당 대회는 Microsoft Azure 클라우드와 Azure AI 활용을 주제로 하고, Github Copilot의 활용을 권장합니다.

 

저는 해외 거주 팀원들을 포함해 팀으로 협업해서 결과물을 제출했습니다. 

아이디어는 '렌탈형 스마트팜 (성장 단계별 아바타 + 게임같은 인터페이스로 관리)'이었습니다.

 

업자용 스마트팜 공장은 너무 비싸고, 취미용으로도 개인이 비싼 가정용 기기를 사서 관리해야하기도 합니다.

이 기획은 두 지점을 절충해서 생각한 방법이며 '실제 작물의 생산'에 집중하기보단 '정서적 충족감'에 초점을 맞췄습니다. 따라서 이후 해당 프로젝트를 확장하게 된다면, 게임적인 경험과 이벤트 그리고 아바타의 커스터마이징이나 스토리텔링같은 것을 추가할 생각입니다. 

 

소통은 Discord 팀 서버를 만들어서 온라인 협업으로 진행 했습니다.

그리고 전반적인 소프트웨어/서비스 설계를 평가하는 디자인 부문에서 상을 받았습니다.

---

맡은 역할

 

🌿 기획 - 전반적인 서비스와 기술 구조  

작년에 매주 진행한 대학생 주말농장 프로그램을 통해, 농사와 식물을 통한 힐링에 큰 관심을 갖게 되었습니다.
그 영향으로 중소형 농업 장비에도 직접 투자할 만큼 장비 활용에도 흥미가 많았고, 이러한 경험이 계기가 되어 "이색 스마트팜"이라는 주제를 잡게 되었습니다. 당시 제 아이디어를 팀에 공유했을 때, 반응이 예상보다 훨씬 좋아서 자연스럽게 이 주제로 방향이 정해졌습니다.

 

✍️ 기술문서 작성

이번 프로젝트에서 전체 기획은 초반부터 제가 중심이 되어 정리한 만큼,
이후 기능 구현과 시스템 구조 설계까지도 자연스럽게 연결해서 조율하게 되었습니다.

 

팀원들도 제 기획 의도를 존중해 주었고, 각자 맡은 영역에서 의견을 주거나 설계를 신뢰하며 따랐습니다.
그 과정에서 기획의 방향성과 기술 구조 사이의 맥락이 어긋나지 않도록 조율하는 역할은
자연스럽게 제가 맡게 되었고, 핵심 기능 구조나 흐름에 대해서는 제가 먼저 설계안과 흐름도를 작성하여 공유했습니다.

 

따라서 기술적인 구조 제안이나 문서 작성은 대부분 직접 진행했으며,
해당 내용을 바탕으로 팀원들과 논의를 이어가고 필요한 수정을 함께 반영해 나갔습니다.

현재 해커톤 제출페이지 하단에 첨부된 영문 기술 문서들과 해당 페이지의 프로젝트 설명란도 모두 제가 직접 작성했습니다.

 

특히, 시차로 인해 소통에 지연이 생기기 쉬운 상황에서도
명확한 문서화와 구조 정리는 협업의 안정성을 높이는 데 큰 역할을 했다고 생각합니다.

---

 

👨‍💼 PM (팀 리더)

• 팀원 모집, 일정 관리, 역할 분담 및 업무 진행 총괄
• 디자인·IoT 작업 등 팀원들과 직접 협업하며 피드백 주도

🌐 IoT 및 인프라 구축

• Azure의 IoT 리소스 구성 및 Terraform 자동화 배포
• Micropython 기반 객체 설계, Wokwi 가상 게이트웨이 사용한 시뮬레이션 테스트
• ESP32 실제 장비로 MQTT 메시지 송수신 테스트
• Azure Function App (Node.js) 기반의 서버리스 메시지 처리 구현

📝 기획 및 기술 설계

• 직접 기획한 아이디어 기반으로 프로젝트 시작 (지난 1년간 대학생 주말농장 매주 경험)
• API 문서, 사용자 시나리오, Azure 메시징 구조 및 통합 설계 정리
• 최종 프로젝트 문서 및 참고자료는 전부 직접 작성

🎨 프론트엔드 & UX

• 초기 기능별 Wireframe 스케치 및 화면 흐름 구조 설계
• 디자이너 영입 후 문서화된 인수인계 자료 작성
• 프론트엔드는 당장 진로는 아니지만, 기존 창업·수업 프로젝트에서 주로 담당해 경험 다수

---

팀 구성 및 역할

이번 프로젝트는 다양한 국적과 배경을 가진 멤버들로 구성된 팀이었고, 제가 리더로서 팀원 모집, 일정 조율, 역할 분담을 직접 맡았습니다.
해커톤 참가자 명단을 기반으로 DM과 이메일을 보내며 팀원을 찾아나갔고, 해외의 디스코드 개발자 커뮤니티에서도 적극적으로 인재를 탐색하며 팀을 구성했습니다. 

 

저 이외의 팀 구성은 다음과 같습니다. 

• IoT 및 회로 담당 (인도 / 전자공학 전공)
  예전에 한국어를 가르치며 친해졌던 친구로, 가장 먼저 합류했습니다.
  ESP32 기반 장치와 센서 코딩, 회로 구성, Micropython 환경에서의 테스트 등에 참여했습니다.

• 초기 백엔드 (러시아 출신 / 스페인 거주 벡엔드&DevOps 시니어)
  초기에 C4 다이어그램과 유저 시나리오 설계 등 실무 중심의 접근을 공유해 주셨습니다.
  설계 관점에서 많은 인사이트를 주셨지만, 본업 일정으로 인해 Azure 대회 기간의 구현일정에는 참여하지 못했습니다.
  
  
• UI 디자이너 (한국인 / 그래픽 디자인 경력)
  학교 지인을 통해 소개받아 합류했습니다. 그래픽 디자인 경험은 풍부했지만
  사용자 경험 설계나 개발 협업은 처음이어서, 기능 구조와 화면 흐름 문서를 따로 정리해 인수인계를 진행했습니다. 
  
  
• 최종 백엔드 (LA 거주 / 시니어 풀스택 엔지니어)
  Microsoft Azure 해커톤 수상 경험이 있는 실력자였습니다.
  농사나 원예에 관심이 많아 주제에 공감하며 팀에 합류하셨고,
  제가 Azure에서 GUI로 리소스를 설정하며 어려움을 겪던 중, Terraform 도입을 제안해주셔서
  이후 리소스 배포와 테스트가 훨씬 수월해졌습니다.

 

팀워크만큼이나 기획 전달과 일정 조율의 중요성,
그리고 다양한 배경을 가진 멤버들과 함께할 때의 소통 전략을 배운 뜻깊은 경험이었습니다.

---

어려웠던 점 (IoT-클라우드 연계)

 

아래는 외국 블로그의 내용을 번역한 것입니다.

AWS IoT vs Azure IoT: 핵심 비교

출처 : Infiniticube 블로그: AWS IoT vs Azure IoT

 

아래 접은글에 해당 블로그를 번역한 내용을 넣어두었습니다.

디지털 시대의 핵심 기술, 사물인터넷(IoT)

 

디지털 시대는 사물인터넷(IoT)을 핵심 기술로 부각시켰으며, 이는 비즈니스 운영 방식, 고객과의 상호작용, 데이터 관리 방식을 혁신적으로 변화시키고 있습니다. 전 세계 수십억 개의 기기가 연결되어 있는 상황에서 올바른 IoT 플랫폼을 선택하는 일은 매우 중요합니다. 이 블로그에서는 Azure IoT와 AWS IoT를 비교하며, 각 플랫폼의 기능과 특징, 차이점을 분석하여 비즈니스에 가장 적합한 선택을 할 수 있도록 돕습니다.

이 비교를 통해 비즈니스 운영을 최적화하고, 고객 경험을 개선하며, 혁신을 촉진할 수 있는 통찰을 제공합니다. 디지털 전환을 성공적으로 이끌기 위해서는 확장성, 효율성, 보안성, 운영 속도 측면에서 최적의 플랫폼 선택이 필수입니다.

---

💡 알고 계셨나요?

• Azure IoT Hub는 원격 지역에서도 적은 데이터 전송량으로 클라우드와 기기간 통신을 가능하게 하여, 연결 환경이 제한적인 기기에도 매우 효율적입니다.
• AWS IoT는 수십억 개의 기기와 수조 개의 메시지를 처리할 수 있으며, 이를 안전하고 신뢰성 있게 다른 기기나 AWS 서비스로 라우팅할 수 있습니다.

---

📖 IoT 플랫폼이란 무엇인가요?

• 비전문가용 설명
  마치 마법의 공책처럼, 내가 쓴 내용이 친구의 공책에 자동으로 복사된다면 어떨까요? IoT 플랫폼은 바로 이런 개념입니다. 스마트워치, 보안카메라, 자동화 기계 같은 기기들이 인터넷을 통해 데이터를 주고받고, 결정하고, 학습하게 하는 기술입니다.
• 경영진 및 IT 전문가용 설명
  IoT 플랫폼은 디지털 전환을 위한 핵심 인프라이며, 기기 연결, 데이터 수집 및 분석, 자동화된 작업 실행까지 지원합니다. 이를 통해 실시간 통찰력 확보, 운영 최적화, 새로운 비즈니스 모델 개발이 가능해집니다. 플랫폼 선택은 **배포 속도, 확장성, 투자 수익률(ROI)**에 직접적인 영향을 줍니다.

---

🧩 IoT 플랫폼의 주요 기능

• 쉬운 통합성: 다양한 기기를 하나의 시스템에서 쉽게 연결·관리할 수 있습니다. (예: 만능 리모컨)
• 데이터 분석: 수집된 데이터를 분석하여 의미 있는 인사이트를 제공합니다. (예: 운동 권장하는 피트니스 트래커)
• 보안성: 데이터와 기기를 외부 위협으로부터 보호합니다.
• 확장성: 기기가 늘어나도 성능 저하 없이 안정적으로 관리할 수 있습니다.

---

🔧 IoT 플랫폼의 핵심 구성 요소 및 작동 과정

📥 데이터 수집

• 센서 및 기기: 온도계, 가속도계 등 다양한 센서가 데이터를 수집합니다.
• 연결성: Wi-Fi, 블루투스, 셀룰러, LoRaWAN 등 다양한 방식으로 데이터를 전송합니다.

🧠 데이터 처리

• 클라우드 or 엣지 컴퓨팅: 데이터를 클라우드에서 강력하게 처리하거나, 지연을 줄이기 위해 엣지(기기 근처)에서 처리합니다.
• 분석: 수집된 데이터는 알고리즘을 통해 패턴을 파악하거나 예측 분석에 사용됩니다.

👁 사용자 인터페이스

• 대시보드와 앱: 분석된 데이터를 시각화하여 사용자에게 보여줍니다.
• 알림 및 조치: 이상 현상에 대한 알림을 제공하고 조치를 유도합니다.

🔄 통합 및 자동화

• API 통합: 외부 시스템과의 연결을 통해 자동화된 워크플로우를 구축합니다.
• 보안: 인증, 암호화, 업데이트 등을 통해 시스템 전반의 보안을 유지합니다.

---

⚔️ AWS IoT vs Azure IoT: 주요 비교 항목

항목	AWS IoT	Azure IoT
플랫폼 서비스	IoT Core, Analytics, Device Management 등 다양한 서비스 제공. AWS 서비스와 뛰어난 통합성.	IoT Hub, Edge, Central 제공. Azure 클라우드와 밀접한 통합
보안	암호화, 인증 등 다계층 보안. ISO, HIPAA 등 국제 표준 준수	고급 보안 프로토콜, 글로벌 데이터 보호 기준 충족
확장성 및 안정성	수십억 기기와 수조 메시지 처리 가능. 글로벌 인프라로 안정적 운영	대규모 IoT 배포 지원. 고가용성 및 지역 분산 인프라 제공
데이터 분석	실시간 분석 및 머신러닝 연동	Stream Analytics 및 Azure ML 통합 분석 가능
개발자 도구	다양한 SDK와 툴, 풍부한 문서 및 커뮤니티 지원	빠른 시작을 위한 샘플 및 광범위한 도구 제공
비용	유연한 가격 정책. 스타트업부터 대기업까지 확장 가능	투명한 가격 체계. 장기적으로 비용 효율적
사용 편의성	직관적인 UI, 빠른 배포	클라우드 및 엣지 모두 지원하는 간편한 인터페이스
규제 준수	국제 규제 준수, 정기적 업데이트 제공	다양한 산업 규제에 부합. 풍부한 문서 제공
맞춤화 가능성	다양한 언어와 툴로 맞춤형 개발 가능	고도의 유연성과 다중 언어 지원
파트너 생태계	방대한 파트너 및 통합 서비스 제공	업계 리더와의 전략적 제휴. 앱 마켓 통합

 

---

🏗️ IoT 아키텍처 비교

🟦 Azure IoT 아키텍처 요약

• 기기: SDK, RTOS, Sphere 등으로 스마트 기능 부여
• 프로비저닝: IoT Hub가 기기 등록 및 역할 분배
• 데이터 처리 경로:
  • Hot Path: 즉각적인 처리 (Stream Analytics)
  • Warm Path: 중요 데이터 분석 (Data Explorer)
  • Cold Path: 장기 저장 및 머신러닝 활용 (Data Bricks 등)
• 비즈니스 통합: Power BI, Maps, Web/Mobile 앱, Logic App 등으로 활용

🟨 AWS IoT 아키텍처 요약

• 기기 + SDK: 다양한 언어용 SDK로 연결 및 통신
• 인증 및 권한: 인증서 기반 보안 및 MQTT 권한 제어
• 게이트웨이 + 레지스트리: 장치 상태 및 메타데이터 관리
• IoT Core: 중심 통신 처리 시스템
• Rules Engine: 조건 기반 메시지 전달/처리
• Shadow: 기기의 가상 상태 저장 및 제어
• AWS 연계 서비스: Lambda, S3, Kinesis 등과 통합 가능

---

🧭 어떤 플랫폼이 더 적합한가?

 

상황	AWS IoT	Azure IoT
다른 AWS 서비스와 통합	✅
글로벌 인프라 우선	✅
고급 분석 도구 필요	✅
하이브리드(온프레미스+클라우드) 필요		✅
엣지 컴퓨팅 활용		✅
Microsoft 제품군과 통합 필요		✅

 

 

🔧 AWS 경험자에게 낯설었던 Azure의 구조

처음엔 AWS IoT 경험이 있었기 때문에, Azure도 금방 익숙해질 거라 생각했습니다.
하지만 프로젝트 초기에 Azure 리소스를 구성하면서 곧바로 벽에 부딪혔습니다.

 

AWS는 IoT Core에 Rule Engine만 연결하면,
간단한 SQL 조건문으로 Lambda, S3, DynamoDB에 바로 이벤트 메시지를 전달할 수 있었습니다.

하지만 Azure는 모든 메시지의 흐름을 명시적으로 설계해야 하며,
IoT Hub → Function App → Cosmos DB로 이어지는 구조조차 제대로 작동하게 하려면
수많은 의존 리소스를 정확한 순서로 생성해야 했습니다.

 

게다가 Azure는 비슷한 이름의 서비스가 너무 많았습니다.
예: IoT Central, IoT Hub, Event Hub, Service Bus, Event Grid…
각각 목적이 다르지만, 이름만 보고는 구분이 쉽지 않았고
비슷한 주제를 찾아도, 공식 가이드 문서를 참고해도, 튜토리얼마다 사용하는 서비스 조합이 달라 혼란만 더 커졌습니다.

 

🧨 문제의 핵심: 의존성과 자료 부족

• Azure는 IoT 메시지를 자동으로 처리해주지 않습니다.
  반드시 라우팅 규칙을 설정하고, 내부 엔드포인트(예: Function App)와 연결되어 있어야 메시지가 전달됩니다.
• 포탈에서 리소스를 수동으로 만들다 보면 연결이 빠진 채로 리소스만 덩그러니 존재하거나,
  반대로 순서가 잘못되어 리소스 생성 자체가 실패하기도 했습니다.
• GPT에게 물어봐도, "먼저 생성해야 하는 리소스"를 미리 만들지 않으면 코드 실행이 실패했고,
  Azure Student 계정이라 제한된 리소스가 많아 튜토리얼 그대로 따라갈 수도 없었습니다.
• 심지어 IoT Hub 자체 로그는 메시지 라우팅이 실패하면 보이지 않아서,
  AWS의 Topic 디버깅과 달리 무응답 상태에서 디버깅조차 못 하는 상황이 생겼습니다.

 

🔍 해결 방법: 문제를 쪼개고, 작게 테스트하기

정말 안 될 땐 아주 기초적인 기능 하나만 쪼개서 테스트하는 게 가장 효과적이었습니다.

1. MQTT 연결부터 확인 → 제대로 연결되지 않아 메시지가 유실되고 있었음
2. 디바이스 MQTT 메시지 publish 수신 여부 확인
   • Azure IoT Explorer를 활용해 메시지 수신 여부를 점검.
   • (Mac 환경에서는 Windows 전용 툴을 대신해 npm + electron으로 로컬 앱을 빌드해 사용)
3. Function App이 IoT Hub에서 메시지를 수신하는지 확인
4. Cosmos DB에 메시지가 제대로 저장되는지 확인

하나하나 순서대로 테스트하면서
어디서 문제가 생기는지 하드웨어 → 네트워크 → 클라우드까지 추적했습니다.

이 과정을 통해, Azure에서는 라우팅이 기본값이 아니라 직접 설계 대상이라는 사실을 명확히 인지했고,
메시지 전달은 엔드포인트와의 라우팅 설정 없이는 불가능하다는 걸 배웠습니다.

 

 

"메시지 라우팅" 관점에서의 AWS IoT vs Azure IoT 차이점

비교 항목	AWS IoT Core	Azure IoT Hub
라우팅 구성 방식	Rules Engine 기반 (SQL-like 필터링 + 동작 지정)	메시지 라우팅 기능 내장 (조건 기반 대상 설정)
설정 방식	SELECT * FROM 'topic' WHERE ... 형식의 SQL 필터를 사용하여 조건 설정 + 작업(Action) 지정	JSON 기반 조건(예: 메시지 속성, 라우팅 태그) 설정 후 대상 엔드포인트 지정
가능한 대상	Lambda, S3, DynamoDB, SNS, SQS, Kinesis 등 AWS 서비스 연동	Event Hub, Blob Storage, Service Bus, Azure Functions, Logic Apps 등 연동
트리거 동작 구조	Rule → Action 중심 (많이 쓰면 Rule 수가 늘어남)	Hub 내부에서 Condition → Endpoint 구조로 통합 설정 가능
시각화/관리 도구	콘솔 기반 Rule 리스트 제공 (단일 Rule 단위 관리)	Portal에서 시각화된 라우팅 테이블 지원 (전체 흐름 파악 용이)
개발자 유연성	자유도 높음 (SQL 기반 필터링과 동적 트리거 설계)	구조적이지만 사용자 친화적이고 운영 중심에 가까움

 

✅ 해결의 전환점: Terraform 도입

 

Azure IoT 아키텍처를 수동으로 설계하고 배포하는 과정에서 저는 꽤 오랜 시간을 소비했습니다. 리소스 간 의존성, 라우팅 구조, 이름만 비슷한 다양한 서비스들(IoT Hub, Event Grid, Service Bus 등)로 인해 설계와 테스트 모두가 반복적으로 막히고 있었습니다.

하지만 팀 내 시니어 풀스택 개발자의 추천으로 Terraform을 도입해보며 상황이 완전히 달라졌습니다.

 

💡 Terraform 도입 전에는...

• Azure Portal에서 하나씩 리소스를 생성하고, 연결 구조를 매번 수동으로 확인
• 연결 오류나 의존성 누락으로 인해 리소스를 반복 삭제/재생성
• 메시지 흐름이 작동하지 않아도 어디서 막혔는지 파악이 어려움
• Mac 환경에서 IoT Explorer가 지원되지 않아 디버깅 환경도 제한됨

하루종일 포털을 딸깍거리며 삽질을 반복했는데, 문제가 해결되기는커녕 리소스 충돌과 혼란만 더 늘어났습니다.

⚙️ Terraform이 가져다준 변화

Terraform은 Azure 인프라의 배포를 코드 기반으로 자동화해주었습니다.

• 리소스 설계를 코드로 명확히 정의할 수 있어 구조적 오류가 줄어들었고,
• GPT에게 “Terraform 기반 Azure IoT 인프라를 설계해줘”라고 요청하자,
  의존성까지 고려된 실제 동작 가능한 코드를 제공받을 수 있었습니다.
• 수정을 반복할 때도 매번 포털을 다시 만질 필요 없이 terraform apply 한 번이면 깔끔하게 재배포 완료.

📌 예를 들어, 수신된 IoT 메시지를 Azure Function에 라우팅하고, 이를 Cosmos DB에 저장하는 흐름도
Terraform을 통해 모든 리소스를 명확히 선언하고 배치해 실수 없이 구현할 수 있었습니다.

 

이전에 힘겹게 트러블슈팅하고 구글링하고 반복하던 때에 비하면.. 눈물나게 편했습니다.

사람이 기술을 잘 배워야만 힘든 일이 덜어지는 구나 싶었어요. 

열심히 새로운 기술을 배우고 써먹어야겠다고 결심했습니다.

 

🛠️ 팁: GPT를 제대로 활용하려면

단순히 “Azure에서 IoT 연결하려면?”보다
“Terraform으로 MQTT D2C 메시지를 IoT Hub → Function App → Cosmos DB로 연결하고, REST API로 조회 가능하게 해줘”처럼 구체적인 프레임워크와 설계 틀을 정해주니, 훨씬 정확하고 신뢰도 높은 응답을 받을 수 있었습니다.

 

📡 최종 인프라 구조 (자동화된 배포 기준)

📶 Device-to-Cloud (D2C) 흐름

ESP32 → Azure IoT Hub → Azure Function App → Azure Cosmos DB

• IoT Hub: MQTT 프로토콜로 ESP32 센서 데이터 수신
• Function App: 메시지 파싱/정제 후 Cosmos DB 저장
• Cosmos DB: MongoDB API 기반 NoSQL 저장소

🔁 Cloud-to-Device (C2D) 흐름

Frontend → FunctionApp → Azure IoT Hub → ESP32

 

사용자가 프론트엔드에서 명령을 호출하면 Function App → IoT Hub를 통해 ESP32로 전달.

 

💡 AWS에서는 Lambda와 Rule Engine으로 처리하듯,
Azure에서는 Function App과 메시지 라우팅을 통해 유사한 이벤트 기반 처리 흐름을 구현할 수 있음.

 

참고) 현재는 Actuator 제어용 IoT API는 미구현 상태이며, Azure IoT Explorer의 C2D 테스트 콘솔을 통해 기본 동작만 확인 가능

추후에는 Node-RED와 Azure 제공 템플릿을 활용하여 게이트웨이 기반으로 제어 흐름을 구성할 예정.

 

📘 배포 스크립트 레포

👉 🔗 AzureFarming2025/azure-iot-deployment (GitHub)

Function App과 인프라(Terraform)는 해당 레포 내부에 별도 디렉토리로 분리해 관리하고 있습니다.

 

---

🔍 회고

이번 경험은 단순한 배포 자동화를 넘어,
Azure의 구조적 설계 철학과 서버리스 아키텍처의 실무적 감각을 익히는 데 큰 도움이 되었습니다.

Terraform을 통해 코드로 클라우드를 다루는 감각도 처음 체득했고,
앞으로 더 복잡한 멀티 리소스 환경에서도 자신 있게 설계할 수 있는 기반을 만들 수 있었습니다.

 

AWS IoT에서는 Lambda를 통해 특정 조건에 따라 트리거를 설정하듯,
Azure에서는 Function App을 사용하면 유사하게 IoT Hub의 메시지 이벤트를 쉽게 처리할 수 있습니다.

하지만 처음에는 이 구조를 제대로 몰라 다른 대안을 찾느라 꽤 시간을 소모하기도 했습니다. Azure 환경에서는 처음 설계 시 익숙하지 않은 개념들이 많았지만, 이번 프로젝트를 계기로 Azure에서의 IoT와 서버리스 아키텍처의 흐름을 좀 더 이해할 수 있었습니다.

 

다만, 아직 경험해보지 못한 Azure 기반의 다른 서비스들을 대상으로 솔루션을 설계하기엔 배울 것이 한참 많다고 느껴집니다.

시간이 된다면 앞으로도 종종 관련 해커톤 프로젝트를 꾸준히 진행하면서, 더 연습할만한 기회를 갖고 싶네요.

 

👣 팀 리더로서 느낀 어려움과 배움

 

계획과 조율 속에서 성장한 실전 경험

저는 평소 일을 할 때 계획을 세심하게 점검하고, 변수를 줄이기 위한 리스크 대비에 많은 에너지를 씁니다. 흐름이 어긋나는 상황이 오면 자연스레 제 책임부터 되돌아보는 편이며, 항상 플랜 B를 마련해두고자 합니다.

 

이번 프로젝트는 IoT, 프론트엔드, 클라우드 인프라 등 서로 다른 기술 영역을 하나로 아우르는 구조였습니다. 팀원 수가 많지 않았기에 저는 다양한 역할을 넘나들어야 했고, 기술적인 구현 못지않게 각 파트를 유기적으로 연결하고 전체 구조를 조율하는 데 많은 시간을 쏟았습니다.

 

또한, 팀원마다 일하는 스타일과 속도가 달랐기 때문에, 일괄적인 스케줄링보다는 각자의 리듬을 존중하는 협업 방식을 설계하는 데 집중했습니다. 분산된 일정을 조율하고, 각 파트에서 나온 내용을 하나의 흐름으로 엮어내는 과정은 쉽지 않았지만, 그만큼 큰 배움이 있었습니다.

Trello 보드에 전체 업무 흐름 및 진행 상황을 정리 Discord 공지 채널에도 동일한 내용으로 주기적으로 업데이트

각 팀원과는 1:1로 일정과 역할을 조율하며 , 참여 가능 기간과 목표를 사전에 논의해 모두가 합의한 계획을 도출함

 

깊이 있는 소통의 필요성과 실제 접근 방식

팀원 대부분은 조용하고 신중한 성향이었고, 큰 회의보다는 1:1 커뮤니케이션이 효과적이었습니다. 디자이너와 브랜딩 방향을 논의할 때도, 직접 이야기를 나누며 의견을 수렴하고 조율하는 데 많은 시간을 들였습니다. 전체적으로 빠르게 결정해야 할 일도 많았지만, 가능한 한 구성원의 의견을 존중하고 반영하려고 노력했습니다. 다양한 국적과 배경을 가진 사람들과 온라인으로 협업하는 일은 익숙했지만, 이번에는 더 깊이 있는 인간적인 연결을 고민하게 됐습니다. 특히 기술적 실행뿐 아니라 팀의 감정선과 몰입도까지도 리더의 역할이라는 걸 체감하게 된 순간들이 많았습니다.

 

기억에 남는 경험 – 소통의 본질을 되묻다

작년에는 디스코드 팀 서버를 기반으로 게임 개발 프로젝트를 진행한 적이 있습니다. 언어 장벽으로 인해 팀 내 의사소통이 어려워졌을 때, 직접 GPT API와 Python을 활용해 실시간 번역 봇을 만들어 적용한 적이 있습니다. 단순한 기술이었지만 그 효과는 놀라웠습니다.

그 이후 팀원들 사이에 대화가 활발해졌고, 프로젝트는 단지 업무를 넘어서 인간적인 교감이 깃든 작업이 되었습니다.

특히 제 동생이자 스토리 작가였던 Kate는 모든 팀원의 작은 기여까지 진심으로 인정해주는 태도를 보여주었고, 그 문화가 팀의 지속성과 몰입에 핵심적인 영향을 주었다고 느꼈습니다.

 

그 모습을 보며 '사람을 자발적으로 움직이게 하는 힘'은 단순한 업무 지시가 아니라,
상대의 가치를 알아봐주는 태도에서 시작된다는 걸 배웠습니다.

 

이 경험은 지금도 종종 스스로를 돌아보게 하는 기준점이 됩니다. 

 

작년 가을에 진행했던 게임 프로젝트 / 디스코드 번역 봇 사용 (Gpt API + python 구현 + GCP 배포)

 

번역 봇을 만들게 된 배경 및 후일담 (접은 글)

예전에 진행했던 한 게임 프로젝트에서는, 제 친동생 Kate가 스토리 작가로 참여하고, 캐릭터 작화는 한국인 지인들이 맡게 되었습니다. 당시 팀에는 해외 배경 작화가들도 있었는데, 한국 팀원들이 언어 장벽으로 인해 소통에 어려움을 느끼는 모습이 자주 보였습니다.

 

또, 기존 번역기나 AI를 사용해도 말의 톤이나 뉘앙스가 일정하지 않았고,
매번 다른 앱으로부터 번역한 뒤 디스코드 앱으로 복사해 붙이는 일이 반복되다 보니 심리적 피로도 높았던 것 같습니다.

 

그래서 큰 기대 없이 직접 GPT API를 활용한 실시간 Discord 번역 봇을 만들어 도입했는데, 예상보다 훨씬 좋은 반응을 얻었습니다. 모든 팀원들이 엄지를 치켜세우며 좋아했고, 그때부터 서로의 말문이 트이기 시작했죠.
자연스럽게 일상 이야기도 오가며 분위기가 훨씬 부드러워졌습니다.

 

비록 이후 여러 사정으로 프로젝트는 잠정 중단되었지만,
지금도 남은 팀원들이 꾸준히 먼저 연락해오며 자발적으로 재개 일정을 논의를 진행할 만큼 팀워크는 여전히 살아 있습니다. 
저에게는 정말 인상 깊고 감동적인 협업 경험이었습니다.

 

물론 팀원들이 제 꼼꼼한 일정 관리나 리스크 대응을 보며 "Excellent Organizer"라고 평가해준 점도 고마운 일이었지만,

 

제가 보기엔 그들이 끝까지 함께하고 싶어했던 진짜 이유는,
스토리 작가인 Kate가 중심이 되어 만든 ‘서로의 가치를 진심으로 인정해주는 따뜻한 분위기’ 덕분이었다고 생각합니다.

 

당시 게임프로젝트 팀원들의 나에 대한 평가

 

팀 관리에 대한 고민과 전환점

이번 프로젝트는 기획은 대부분 완성된 상태에서 추가모집한 팀원들이 합류하는 구조였기에, 자율성과 소속감을 자연스럽게 이끌어내는 게 다소 까다로웠습니다. 그러던 중, 향후 확장 가능성을 염두에 두고 준비 중이던 3D IoT 시제품 제작 방향과 관련 자료를 팀에 공유했을 때, 예상보다 긍정적인 관심과 활기찬 반응이 돌아왔습니다.

 

그때, 한 사람이 전하는 메시지 하나가 팀 전체의 분위기와 에너지에 얼마나 큰 영향을 줄 수 있는지를 실감했습니다. 다만 여러 업무를 동시에 조율하던 당시에는 제 자신도 꽤 벅찬 상황이었기에, 프로젝트에서 다른 불안 요소가 생길 때마다 종종 이런 생각들이 떠오르곤 했습니다.

 

이 고민이 깊어지면서, 저는 오랜 지인이자 평소에 신뢰하던 전 팀원에게 조언을 구했습니다.
그 친구는 조용히 이렇게 말했습니다.

올바른 대화는 항상 부드럽게만 흘러가진 않아.
팀은 책임을 나누는 사람들이고, 그 무게를 서로 인식할 수 있도록 말해줘야 해.

 

그 말을 들은 순간, 저는 그동안의 제 태도를 다시 돌아보게 됐습니다. 프로젝트가 흔들릴 때마다 스스로 더 많은 일을 감당하며 해결하려 했지만, 오히려 그것이 팀원 각자가 자신의 가치나 책임을 체감할 기회를 줄였을지도 모른다는 생각이 들었습니다.

 

이번 프로젝트를 통해 저는 리더십은 모든 걸 떠안는 것이 아니라, 책임을 함께 나누고 그 의미를 구성원들과 공유하는 과정임을 실감하게 됐습니다. 시간은 많지 않았지만, 대회 후반부, 미리 합의한 목표에 비해 진행이 부족해질수록 저는 팀원 한 명 한 명과 더 자주 이야기하려 했습니다. 그들의 입장이나 이 대회에 참여하게 된 계기, 어떤 부분에 의미를 두고 있는지를 듣고, 그에 맞춰 서로의 목표를 다시 강조하고 응원하며, 마지막까지 책임감 있게 함께 나아갈 수 있도록 도왔습니다.

 

결과적으로 대부분의 팀원들이 자신이 맡은 범위를 끝까지 마무리해줬고,
그 과정에서 저는 혼자 끌고 가는 것이 아니라, 같이 가는 팀워크의 중요성을 배웠습니다.

 

앞으로의 다짐

 

이번 프로젝트를 통해 느낀 가장 큰 배움은,
작은 역할이라도 팀 전체의 흐름에 영향을 줄 수 있다는 점이었습니다.
그리고 그 흐름은 결국 서로가 조금씩 책임을 나누며 지탱해나가는 것이라는 걸 알게 됐습니다.

 

그래서 앞으로는 제 일에만 집중하는 것을 넘어서,
다른 팀원들이 자연스럽게 몰입할 수 있는 분위기를 만드는 데에도 기여하고 싶습니다.
말보다 행동으로 신뢰를 주는 사람이 되고 싶고,
필요할 땐 적절히 흐름을 정리해줄 수 있는 동료가 되고 싶습니다.

 

예전에는 ‘부드러운 이해’만이 좋은 소통이라 여겼지만,
이번 경험을 통해 때로는 기준을 분명히 하고, 서로의 책임을 인식시키는 말도 필요하다는 것을 배웠습니다.

물론 그 중심엔 항상 존중과 배려가 있어야 한다고 생각합니다.

 

앞으로도 저는 기술적인 역량은 물론,
사람들과 함께 일하는 방법에 대해서도 계속 배우고 성장하고 싶습니다.

그리고 저와 함께하는 팀이 조금 더 안정감 있게 움직일 수 있도록,
주위 환경을 챙기고, 신뢰를 줄 수 있는 동료가 되는 것이 저의 목표입니다.