![[후기] 일조량 시뮬레이션 개발 프로젝트 후기](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FdyO2zT%2FbtrpmgdAqet%2FfjVuDnlrSA80EJZcMb3d3k%2Fimg.png)
안녕하세요, 기계과 감성쟁이입니다.
약 5개월 간 진행했던 일조량 시뮬레이션 개발 프로젝트 후기를 남겨보겠습니다.
1. 프로젝트 요약
프로젝트명 : 디지털 트윈 기반의 국토 공간 정보를 활용한 일조량 예측 플랫폼
- 개발기간 : 2021년 7월 말 ~ 2021년 11월 말
- 개발인원 : 5명
- 맡은 직책 : 팀장
- 사용한 엔진 : 유니티(Unity)
- 국가 R&D 과제로 특허 출원 및 소프트웨어 등록.
- GitHub : https://github.com/foba1/ITRC-KMSIS
2. 프로젝트 후기
1. 관용과 엄격은 공존해야한다.
세상의 모든 협업이 그렇 듯이, 프로젝트를 진행하며 팀원들 간의 불화는 당연히 있었습니다. A는 회의 지각이 잦았고, 준비 또한 부족했습니다. 2~3차례 정도 반복되었는데, 저는 매번 가볍게 눈치만 주고 넘어갔죠. 하지만 B는 이에 점점 분노하고 있었고, 끝내 저에게 개인적으로 A를 내보내자고 했습니다. 그리고 얼마 후, 저는 A에게 개인적으로 연락해 '공적인 일'임을 강조하며 그를 다그쳤습니다. "경험 상 이런 경우 불만을 가지는 사람이 무조건 생긴다."라고 말한 뒤, "아직은 괜찮다. 개인적인 바램이다."라고 덧붙이며 그를 안심시켰죠. 이 전화 이후엔, B에게 전화를 걸어 그를 진정시켰습니다. 결과적으로 A의 업무태도가 정말 좋아지며 B의 불만 또한 사그라 들었습니다.
사람에 따라, 상황에 따라 리더쉽은 달라져야합니다. 부드러울지, 단단할지 말입니다. 제가 봤을 때 A는 조금만 다듬으면 충분히 열심히 할 수 있는 사람이었습니다. 다행히 제 예상은 빗나가지 않았고요. '부드러울 땐 부드럽게, 엄격할 땐 엄격하게'를 군대에서부터 생각했는데, 제 신념이 빛을 발했던 순간이 아닌가 싶습니다. 이때 쯤 보았던 넷플릭스 시리즈 '더 크라운'도 도움이 되었으니 한번 쯤 보는 것을 추천 드립니다.
2. 데이터 수집과 경우의 수 판단
자신이 원하는 것은 경우의 수로 판단할 수 있습니다. '만약에...?'라는 가정에서 최고의 상상이 나오는 법이니까요.
한번은 이런 일이 있었습니다. 프로젝트 기획안이 통과되고 본격적으로 시작하려는 찰나, 팀원 한 분이 저에게 전화가 왔습니다. 잠긴 목소리로 자신은 할 줄 아는게 없어서 도움이 될 지 모르겠다고 말을 하더군요. 평소에 적극적인 성격을 보인 분은 아니여서 자신감을 주면 충분히 함께 할 수 있다고 판단했습니다. 팀에 누구 하나 특출난 사람도 없고, 모르면 공부하기에도 충분한 시간이 있다고 설득하였고, 다행히 성공적이었습니다.
그 분이 다시 함께하기로 한 이유는 아마 심적 부담감의 하락일겁니다. 위와 같은 발언은 기대감을 낮춰줌으로써 능률에 대한 압박감을 줄여주니까요. 그리고 제가 그 분과 함께한 이유는 (냉정히 말해 능률이 부족함에도 불구하고) 팀의 분위기였습니다. 서로의 필요를 하나씩 교환한거죠. 저는 득이 되는 교환이라 생각해서 결정한 것이고요.
전화는 갑작스럽게 걸려왔고, 저는 급하게 판단해야 했습니다. 그럼에도 불구하고 성공적인 결과를 낳을 수 있었던 것은 평소에 자신과 팀원, 팀의 목표를 생각해왔기 때문이라 생각합니다. 여러 경우의 수의 유불리를 따질 때의 근거는 모두 데이터에서 나오니 말입니다. 팀을 이끌 때에 사람과 상황을 얼마나 잘 파악해야하는지 상기할 수 있었던 일이었네요.
3. 기획 깊은 나무 가뭄 안 탄다
광고대행사 스타트업에서 기획을 했다지만, 콘텐츠 기획과 프로그램 기획은 전혀 다른 분야였습니다. 프로그램 개발을 대체 어디서부터 시작해야하나 혼란스러웠죠. 이것저것 찾아보고 여기저기 물어봐서 기획명세서를 쓰기 시작했습니다. 이후엔 플로우차트를 만들고, 나름의 디자인 기획을 했습니다. 하지만 프로젝트를 진행하며 현실적 제약에 따라 여러 변경사항들이 생겼고, 중간중간 기획을 계속 수정해야했죠.
제약들을 미리 파악하고, 와이어 프레임과 같은 보다 구체적인 기획서를 함께 제작했다면 프로젝트 개발이 조금은 더 수월하지 않았을까 생각합니다.
4. 이해할 수 있는 팀장
블로그에 뜬금없이 유니티 포스팅을 올린 이유가 바로 이것이었습니다. 팀장은 의사를 결정하고, 팀원들을 이해해서 다같이 앞으로 이끌어가는 역할입니다. 그럴려면 팀원들의 업무를 이해해야 한다고 생각했고, 유니티를 공부했죠. 실제로 도움이 많이 되었습니다. 예전에 공부했던 파이썬과 웹도 마찬가지고요. 제가 직접 코딩을 하는 일은 거의 없었지만, 메커니즘과 개발환경을 아는 일은 소통에 지대한 영향을 미쳤습니다. 때때로 알고리즘을 생각할 때에 직접적인 도움이 되기도 했네요.
개발자에게 제플린을 소개해준 일도 비슷한 맥락이었습니다. 픽셀 단위로 디자인을 구현하는 일과, 픽셀 단위로 가이드 만드는 고충을 모두 아니까 제플린을 사용하자고 한 것이죠. 처음에는 무덤덤 하시더니, 개발 마무리 단계에선 정말 좋다고 목소리를 높이신게 아직도 생각나네요.
5. 국토 정보 얻기는 정말 힘들다
프로젝트 기획 단계에선 위 기사의 데이터를 사용하려고 했습니다. 그래서 국토지리정보원에 문의하고 요청하였으나, 기밀유지 계획 수준이 미달되어 실패하였습니다. 데이터를 외부에 제공한다고 했으나, 실질적으로 일반인이 사용하기는 불가능한 수준을 요구했습니다. 담당 교수님과 논의해보니, 실제로 기밀에 의해 연구개발을 할 수 없는 경우가 많다고 하더라구요. 특히 전쟁 중인 국가라서 국토 정보엔 민감하다고 덧붙이셨습니다. 원하던 데이터를 얻을 수 없어서 차선책을 택하긴 했는데 아쉬움이 많이 남습니다.
아무쪼록 5개월 간의 프로젝트가 끝이 났습니다. 학기와 겹쳐서 꽤 힘들었지만 뿌듯하네요.
다른 후기는 그때그때 생각나면 추가해볼게요.