무지개덕 [務知凱德] : 힘써서 알고 개선하여 덕을 쌓자

務(힘쓸무)知(알지)凱(개선할 개)德(덕 덕)

하라는 회의는 안하고 이런 거 찾아보는 우리 무지개떡 팀,,

가볍게 정한 의미이지만 우리 팀의 롱커톤 1주차가 어떻게 흘러갔는지 한 마디로 표현해주는 것 같습니다.

우리 팀의 최우선 가치를 뽑아보자면, 팀원 간의 존중을 기반으로 하는 투명한 공유와 선명한 솔직함입니다.

롱커톤 시작 전 0주차에 기획자님 두 분께서 강조하신 부분이기도 한데요, 우리는 뿌듯함과 어려움을 모두 공유함으로써 프로젝트에 대한 동기 부여와 심리적 안전감을 확보한다는 부분을 확실히 짚고 프로젝트에 임했던 것 같습니다. 덕분에 문제 정의와 솔루션, 기획에서의 접근 등이 자주 피벗되는 1주차를 무사히 잘 넘어갈 수 있었던 것 같아 기획자님들께 개인적으로 참 감사했습니다.

협업 방식

팀에서 보여지는 나의 역량과 이미지 때문에 개개인이 실천하기 다소 어려울 수 있는 투명한 공유와 선명한 솔직함을 자연스럽고 당연한 가치로 두기 위해서 우리 팀은 여러 방식을 도입하여 프로젝트를 진행하고 있습니다. 그중 하나는 하루 세 번 데일리 스크럼입니다. 매일 팀원의 컨디션과 파트 별로 어떤 일들이 진행되고 있는지, 어려움은 없는지를 짧은 시간 단위로 확인할 수 있어 매우 좋은 협업 방식이라고 생각합니다.

두번째는 문제 정의 및 프로젝트와 관련된 중요한 결정 단계에서 모두의 의견을 한 번씩 들어보는 일입니다. 이 방식을 도입하겠다고 누군가 분명히 말한 적은 없지만, 처음 문제 정의할 때 모두의 의견을 한 번씩 듣는 것이 습관화되어서 자연스럽게 이어진 협업 방식 같습니다. 이렇게 함으로써 모두의 머릿속에 그려진 이미지와 논리가 같은 방향을 향하고 있는지 확인하고 그렇지 않은 경우를 빠르게 발견하여 align 할 수 있어 큰 도움이 되었습니다.

이렇게 협업하기 좋은, 유용한 방법을 도입해도 의견 충돌은 있기 마련입니다. 이번 한 주 간, 우리 팀도 반대되는 의견, 살짝 어긋나는 의견 등 대화가 필요한 시점들이 있었습니다. 하지만 팀원들이 이 프로젝트에 대한 오너십을 가지고 자신의 주장에 타당한 이유를 대려고 하면서도 상대방의 의견에 경청하는 태도를 가졌기 때문에 정체되지 않고 조금씩 앞으로 나아갈 수 있었던 것 같습니다.

문제 정의

우리의 문제 정의는 조금 독특한 모양새로 진행이 되었습니다. 보통은 어떤 현상에서 사람들이 겪는 불편함을 문제로 삼고 이런 현상이 나타나게 하는 가장 핵심적인 원인을 분석하여 이에 대한 솔루션을 구상하는 플로우로 진행된다고 알고 있습니다. 저는 개발자라서 반박 시 여러분 생각이 맞습니다:(

우리는 사람의 감정을 다루는 문제인지라 솔루션의 형태는 얼추 예상이 가지만 펫로스 증후군이라는 현상에서 우리가 구상하는 솔루션으로 이어지는 논리 과정이 뚜렷하지 않아 자꾸만 원래 의논하던 부분으로 돌아가고 찜찜한 부분이 생기는 문제가 발생했습니다. 이때 운영진 및 현업자 멘토링을 진행하면서 문제 정의에서 주어와 서술어가 명확하지 않기 때문에 발생하는 문제라는 것을 알아내고 이틀 간의 회의를 거듭한 끝에 얼추 직관적인 문제를 정의내릴 수 있었습니다.

이렇게 피벗과 고민을 거듭하는 과정에서 저는 이 모든 것이 아무 의미 없이 시간을 버린 일이라고 생각하지 않습니다. 아주 작은 보폭이지만 한 걸음씩 앞으로 나아갔고, 가지 말아야 할 방향을 알 수 있었던 시간이었습니다.

개발자로서 문제 정의 과정을 거치면서...

개발자가 가장 여유로운 1주차에 우리 팀의 개발자들은 할 수 있는 일들을 미리 하면서 2주차를 준비했던 것 같습니다. MVP 기능이 확정되지 않아도 로그인, 회원가입 같은 기능 구현이나 개발 컨벤션 정하기, 깃 브랜치 파기, 리액트 개념 복습하기, 기술 검증하기 등을 하면서 이번 한 주를 보냈습니다.

2주차와 3주차 모두 PAY IT FORWARD 합시다!!!!

눈 떠보니 실전이다!

안녕하세요 파드 3기 웹 파트 황유민입니다. 저의 첫 메이커로그에서는 말이죠! 지난 5/24~5/25 에 진행된 숏커톤 프로그램에 대한 회고를 해보고자 합니다. 시-작

숏커톤을 준비하면서

악시오스랑 리코일 배운지 얼마 되지 않은 것 같은데 벌써 숏커톤이라니...!

놀란 마음을 진정시키고 저는 그래도 1인분은 해야 하지 않겠나 하는 걱정에 사로잡혀 세미나 자료 PPT와 웹 파트 GitHub에 올라온 코드들을 여러 번 정독 했던 것 같습니다.

하지만 백견이불여일행 이라고 하듯, 직접 코딩하면서 다양한 에러를 마주하고 디버깅 해보았더라면 더 잘 할 수 있었을 텐데 하는 아쉬움이 많이 남는 것 같습니다.

In the beninging...

처음 방문한 포항시 남구의 창바우 마을!

공기도 좋고, 날씨도 좋고, 바다도 너무나 예쁜 아기자기한 마을이었습니다. 그 자체로 힐링인 공간에서 다 함께 약간의 스트레스를 동반한 협업을 진행한다는 약간의 아이러니 이슈...

Team Pardyz

건물로 들어가자마자 확인할 수 있었던 팀원 명단. 기획자 2, 웹(프론트엔드) 3, 서버 2, 디자이너 1 로 구성된 팀으로 앞으로 18시간 동안 협업할 생각에 벌써부터 동지애가 생겼던 것 같습니다.

주제 공개

팀 배정과 저녁식사 이후 공개된 숏커톤의 주제는 바로 청춘 이었습니다!!

레이스 스타트!

가장 먼저 FigJam 으로 청춘 하면 생각나는 느낌이나 키워드를 마구마구 브레인스토밍 한 후, 비슷한 내용끼리 묶어서 해당하는 제목을 붙였습니다. 팀원 전체의 의견을 참고하기 위해 돌아가면서 자신이 생각하기에 가장 괜찮을 것 같은 주제 하나와 그 이유를 설명하였습니다. 바로 이렇게 말이죠!

그 중에서 저를 포함하여 대다수가 뽑고 기획자 역시 동의했던 실패/불안감 이 저희의 최종적인 주제로 뽑혔습니다. 이 주제에 대한 솔루션으로 제시된 아이디어는 사람들이 실패에 대한 두려움을 극복하고 다시 일어날 용기를 얻을 수 있도록 경험과 해결책을 공유하는 플랫폼, 실패 전시회 입니다.

이렇게 간단 명료하게 아이디어가 정해지면 좋았겠지만 사람들이 왜 서로의 성공 경험이 아닌 실패 경험을 보고 싶어 하겠는가 하는 질문에 막혀서 실패 전시회가 아닌 다른 아이디어를 생각하는 등 돌아 돌아 겨우 실패 전시회의 개발을 시작하게 되었습니다.

개발과 회고

• 여유로울 때 코드 컨벤션, 개발 리더, PR 방식 확실하게 정하기

얼떨결에 시작하게 된 개발이다 보니 숏커톤 전에 개발 리더를 정하고 PR 방식을 정해야겠다는 다짐이 무색하게 어영부영 깃허브와 각 사람의 브랜치를 판 것이 모든 문제의 시작이었다는 생각이 드는 것 같습니다. 지금 생각해보면 제가 실질적인 해커톤 경험이 없어 조금 의존적인 사고로 숏커톤에 참여했던 것 같습니다. 다들 잘하니까, 나보다는 잘하겠지 라는 안일한 생각이 소통의 부재로 이어졌고 그 결과가 나중에 가서 크게 돌아온 것 같아 저에 대한 아쉬움이 많이 남는 것 같습니다.

저는 GitHub에서 협업해본 것이 이번이 처음이었기 때문에 초반에는 하나하나 pull 받아도 되는지, pr 날릴지를 물어보고 결정했고 덕분에 충돌이 생기지 않아서 깃헙.. 꽤 쉽네? 라는 건방진 생각을 했던 것 같습니다. 하지만 점점 시간에 쫓기면서, 그리고 어느 시점에 merge가 안되었는데 모두가 되었다고 착각하는 바람에 제가 이전 버전을 pull 받고 새로 pr을 날리면서 모든 게 꼬였던 것 같습니다. 확인해보니 merge가 안된 상태였고 저는 새로 merge를 해버려서... 그때 해결했으면 그나마 나았을 텐데 충돌을 다 해결한 후에야 그 사실을 알게 되었고 저의 멘탈은 이미 조금씩 날아가고 있었던 것 같습니다. 깃헙.. 어려워 시간에 쫓긴다고 확실하게 말하지 않고 알잘딱깔쏀으로 해결하는 것은 문제 해결이나 시간 단축에 전혀 도움이 되지 않는다는 것을 뼈저리게 느꼈고 덕분에 많이 배웠습니다.

• 아이디어 정해지면 흩어지지 말기, 기능에 대한 모두의 생각이 같을 것이라는 편견 버리기

또한 아이디어가 정해지자마자 빠르게 일해야 한다는 의무감 때문에서 인지 모두가 신속하게 자리로 흩어졌었는데요. 대략적인 기능과 데이터에 대한 의논 없이 기획자가 작성하는 PRD가 완성되길 모두가 기다리기 보다는 짧은 시간이 주어졌으니 모든 것이 실시간으로 이루어졌다면 어땠을까, 상세한 싱크를 맞추고 시작했다면 좋았을 것 같다는 회고를 해봅니다. PRD가 완성되고 나서도 서버와 웹 개발자 모두 다같이 한 번 보고 확실하게 기능 정의하고 시작하면 좋을 것 같다고 생각하게 되었습니다.

• 리액트와 CSS 개념 확실히 공부하기

웹에서 만들어야 하는 페이지는 크게 3가지였습니다: 실패 전시회 메인 페이지, 실패 전시 view 페이지, 실패 전시 upload 페이지. 저는 이중에서 실패 전시 view 페이지를 맡아 개발을 시작하였습니다. 기본적인 UI 뼈대를 만드는 과정은 쉬웠습니다. styled component 를 사용해서 올바르게 배치만 하면 되었기 때문이었죠.

하지만 이 커텐을 올리는게 생각보다 쉽지 않았습니다. 저의 layout 스킬로는 말이죠 :( 공부가 더 필요한 시점이라고 느꼈던 것 같습니다.

view 페이지 외에도 부탁 받았던 기능은 recoil 을 사용해서 서버와 연결이 어려운 부분의 데이터를 보이게 라도 만들자는 것이었는데요, recoil 을 내가 짠 코드에서만 사용해본 저는 다른 사람이 짠 코드에 넣는 게 생각보다 쉬운 일이 아니었던 게 문제였죠... 시간은 정말 얼마 안 남았고 빠르게 코드를 이해하고 올바르게 넣어야 하는데 조급함 때문에 읽히던 코드도 이해가 안 되고 저의 부족함을 뼈저리게 느꼈던 1시간이었습니다.

• 타임 키퍼

타임 키핑이 잘 안 되었던 이유를 분석해보자면, 타임 키퍼 역할을 정하지 않고 각자의 역량에 맡겼던 것과 짧은 시간 동안 일을 순차적으로 진행하려 했던 것이 문제였습니다. API가 만들어지지 않아서, PRD가 작성되지 않아서. 먼저 말로 정리한 다음에 문서화 시켜도 되는 부분이었지만 짧은 시간이라는 조건 안에서 일해본 적 없던 파디들의 모임 파디즈에서는 그 부분을 고려하는 것이 어려웠습니다.

다음에 숏커톤을 한다면 저는 가장 먼저 전반적인 진행 과정을 정하고 시간을 할당하여 타임 매니징을 수행할 것 같습니다.

이렇게 저만의 회고를 진행해보았는데요, 다음 롱커톤 때는 오늘 회고한 부분들을 신경 써서 더 좋은 결과 만들어내길 기대해봅니다!

결론 (땅땅땅)

이렇게 부족한 점이 많았던 저도 팀의 일원으로 함께 해주신 파디즈에게 고맙고 미안한 마음을 거듭 전합니다.

1인분을 하려는 생각이 저를 0.75인분 (or less...) 밖에 하지 못하도록 했던 것 같습니다. 나만 도움이 필요한 게 아니라 저 사람도 나의 도움이 필요할 것이라는 자신감을 가지고, 그리고 그 자신감을 가질 수 있도록 롱커톤까지 열심히 공부해서 1인분 같은 3인분 3인분 같은 1인분을 감당하도록 노력하겠습니다!