숏커톤! 그 15시간 동안 우리팀에 있었던 일들에 대하여

안녕하세요, 파드의 기획파트 팀원 김정훈입니다. 

저번주 금-토에 있던 파드 숏커톤 행사의 늦은 회고글을 올립니다!

https://github.com/1st-PARD-APP-PART/pixel_n_semicolon

<숏커톤 시작 전에 마음 속의 염려>

숏커톤 한 주 전의 기디개 연합 세미나 때를 회고해보면, 저는 좋은 중재자라 보긴 힘들었습니다. 글씨가 악필이었던 지라 보드를 사용해 소통할 때 글씨 해독(!)의 문제가 있었고, 골고루 발언권을 신경쓰는 모습을 보이지 못했습니다. 

무엇보다, 개발자 분들과 애기를 나눠보면 팀원마다 실력에 편차가 존재해서, 실력자가 비실력자에게 일을 수주하고, 비실력자는 실력자에게 의존하는 방식으로 개발이 많이 이뤄질 것이라 예상되는 상황이 불편했습니다. 

파드에서 지난 세미나 주차들을 통해 다루었던 것은, 그럼에도 불구하고 협업하기 위해선 소통의 범주를 넓히고, 긴밀하게 필요와 불편을 나눔으로써 각자가 할 수 있는 일의 역량을 최대한으로 끌어올리는 것이기 때문입니다. 

한편, 또 한가지 난관이었던 것은 나이 이슈였습니다. 나이가 있는 개발자 분들이 나이가 적은 개발자분들에게 함께 모여있을 때 ‘막내가 이런 것도 안 하고 뭐 하냐~’라는 투의 말을 할 때 어떻게 중재해야 할지 걱정이었습니다. 

마지막으로 염려되었던 것은, 디자이너 분과의 소통이었습니다. 개발에 관해선 어떤 절차로 개발이 이뤄지는지 대략 파악을 하고 있던 타라 걱정이 없었는데, 디자인은 센스에 관한 부분이 커서, 이전의 세미나 자료들을 개인적으로 회고해보았더라도 소통을 잘 할 수 있을까 걱정되었습니다. 

<숏커톤 기간 중 있었던 일! 저녁 8시부터 아침 10시까지> 

기획자가 느낀 “7시 - 10시” 15시간 동안의 일들

숏커톤이 시작하기 전날, 개발리드의 주도 하에 개발 언어인 플러터의 버전 싱크를 맞추는 작업을 완료하고, 숏커톤 시작 3시간 전엔 개발 팀원의 주도 하에 깃헙 페이지를 생성해두었습니다. 그리고 저는 시작 2시간 전, 팀원들끼리 원활하게 소통하기 위한 노션페이지를 미리 제작해두기 시작했습니다. 

숏커톤은 저녁 7시 시작했는데, 운영진은 10시까지 팀명과 서비스명, 서비스 한 줄 소개를 제출할 것을 요구했습니다. 숏커톤의 주제가 변화 였기에, 회의할 때 어떤 대상들에 우리가 관심이 있는지 맞추는 것에 먼저 초점을 두었습니다. 

그리고 개발에 드는 시간이 부족할 수 있으니, 10시가 아닌 8시 반까지는 아이디어 생성 작업을 마칠 것을 팀의 목표로 잡았습니다. 

8시가 넘어갈 무렵이 되어서야, 우리팀이 무엇을 하고 싶은지 정렬을 맞출 수 있었는데 그건 다름 아니고 life hack, 하나의 재밌는 장난을 칠 수 있게 해보자는 것에 의견이 맞아떨어졌습니다. 그래서, 어떤 장난을 치고 싶은지 정하는 것이 8시부터의 회의 주제가 되었는데 개발자 분들의 의견 제안이 촉매가 되었습니다. 

상대방의 핸드폰을 특정 시간 동안 잠궈버릴 수 있는 권한이 생기면 정말 재밌지 않을까? 하는 생각을 하게 되었고, 이 행동을 어떻게 변화라는 주제와 연결지을지 고민하기 시작했습니다. 그 때 리콜해온 것은 이전에 브레인 스토밍 도중 나왔던 것인, todolist 가 있었습니다. 초심을 잃기 쉬운 현대인들의 문화 속에서 초심을 잃지 않게 해주는 todolist 앱을 만들어보자는 애기가 나왔던 터라, 두 아이디어를 취합하는데 신경을 쓰기 시작했습니다. 

이때부턴 디자이너를 포함해 개발자들과 매니징을 담당하고 있는 저까지 모든 사람이 흥분한 상태로, 공격하는 유저가 어떤 흐름으로 앱을 사용하고, 방어하는 유저가 어떤 흐름으로 앱을 사용하는지 흐름을 설계하였습니다. 

9시 이후부턴 팀 이름과 서비스 이름을 정하고, 서비스 한줄 설명을 준비했습니다.  

그리고 이때부터 준비한 스토리 - 에픽 - 태스크 툴을 사용하여 스토리를 4개로 찢고, 그 작업들에 맞는 스프린트를 실행하기 위한 준비를 마쳤습니다. 

이 과정은 기획자인 저 혼자만이 한 것이 아니라, 모든 파트의 구성원들이 함께 협력하여 스토리들을 발행하고, 에픽들을 발행하였습니다. 10시 되고, 운영진분들과의 피드백 시간을 가졌을 때 들었던 조언은 구현해야 하는 기능들에 우선순위를 두어야 한다는 것이었습니다. 

그래서 10시 이후부턴 직무에 따라 나뉘어서 각자, 또 같이 협업하며 작업을 이어나갔습니다. 디자이너 분과 저는 스토리 3을 먼저 짜기 시작했고, 개발자분들은 개발리드의 주도 하에 스토리 3, 스토리 1, 2를 각각 나뉘어 분담하여 작업하기 시작했습니다. 

그래서 자정을 넘긴 12시 반 이후부터 4시까진 죽- 각 파트별로 구현하고 있는 기능이 잘 완성되어 가는지, 개발 속도와 디자인 속도가 잘 맞는지, 병목 상황이 무엇이고 어떤 곳에 주안점을 두어야 하는지 상의하며 하나하나씩 구현해나가기 시작했습니다. 

4시가 지난 이후엔 다시 목표를 세팅하였는데, 7시까진 4개의 스토리 모두가 각각의 개발 분담 사이드에서 완료될 것을 목표로 잡았습니다. 적어도 7시부터 8시 반까지는 통합하는 과정으로 사용되어야 할 것이라 예상했기 때문입니다. 

목표대로 7시까지 개발은 잘 완료되었고, 이후 통합 과정에 들어갈 수 있었습니다. 디자인의 경우는 디자이너 분의 놀라운 작업 속도 덕분에 스토리 3을 시작으로 해서 6시를 기점으로 이미 디자인 작업이 어느정도 완료된 상태였습니다. 

기획자인 저는 각 파트원, 또 개발 파트원들과의 의견 조율과 진행 상황을 계속해서 공유하는 한편으로 5시를 기점으로는 발표 준비에 들어가고 있었습니다. 지난 아이디어 내용들을 취합하고, 발표자료에 중요하게 언급되어야할 저희 팀과 제품의 특징에 대해 조사하고, 한곳에 정리하고 있었습니다. 

그리하여 8시 반 이후, 각 파트원들은 각자의 작업을 어느정도 마무리하고 9시부턴 휴식을 취하며 아직 개발이 미숙한 부분이나, 발표 자료 중 미숙한 부분에 힘을 쏟고, 40분 가량은 쉼을 가질 수 있었습니다. 

<잘한 것>

스토리를 작성한 것입니다. 

각 파트별로 소통할 때 스토리 몇이다, 라고 말하며 소통 과정에 드는 불필요한 노력들을 줄일 수 있었습니다. 작업 중인 페이지를 알아보기도 쉬웠고, 스프린트 진행 상황 중 현재 어떤 부분이 병목인지 파악하기도 용이했습니다. 

<반성>

기획자로서 좀 더 잘 할 수 있었던 부분은 디자이너를 돕는 것, 개발자를 돕는 것, 발표에 팀이 걸어온 길을 잘 녹여보이는 것 이 세가지였다 생각합니다. 

컨셉이 구체화된 저녁 10시를 기준으로 각 파트별로 필요한 예상 공수가 어느정도 보였기 때문에, 기획자는 의사결정의 역할, 그러니까 리드하는 것보다는 각 파트에 어떤 도움이 필요한지 파악하고 도움을 드리는 역할을 더 수행했어야 했는데, 그렇지 못했던 것 같습니다. 

실은 숏커톤 전에 앱파트, 디자인 파트 각각의 지난주차 세미나 자료들을 전부 한번씩은 회독해보고 들어가긴 했습니다만, 디자인의 경우는 피그마를 다루지 못해서, 개발의 경우는 어떠한 에러가 생겼을 때 그것을 직접적으로 해결해주지 못한 모습들이 반성이 됩니다. 

마지막으로 발표의 경우, 가장 미숙함이 드러났습니다. 어떤 포인트에 방점을 두어야 하는지 설계가 부족했고, 제가 보는 시선에 매몰된 나머지 청자에게 제 발표가 어떻게 들릴지 고려하지 못한, 배려가 부족한 발표였습니다. 

<성과 & 앞으로 어떻게 해야겠나?>

단적으로는, 디자인 공부를 평상시에 해두어야겠다 생각했습니다. 개발의 경우 평상시 미리 익혀두며 개발 사이클이 돌아가는 꼴에 대해 예상이 가능했지만, 디자인의 경우 센스에 대한 면면이 더 강조되는 탓에 디자이너분께 도움이 되지 못했다는 생각이 들었습니다. 

팀이 좋은 성적을 거두었지만, 솔직하게 그 공은 개발 리드 분과 파트 구성원 분들, 그리고 디자이너의 기획 전략과 컨셉 설정에 있었다고 생각하는데, 이런 면에서 아직 발전해야할 분야가 많은 것 같습니다. 

기획은 소프트 스킬이 중요하다는데, 제가 더 학습해야할 암묵지가 참 많은 것 같습니다ㅎㅎ

<개발파트에 대한 생각>

좋은 성적을 거두었던 이유는 개발 파트 구성원이 6명 중 4분이나 계셨던 것, 그리고 개발 파트 안에서도 실력의 편차가 존재했지만 그럼에도 모두가 할 수 있는 최선을 다하여서 많은 개발량을 온전히 소화해낼 수 있던 것이라 생각합니다. 

최선을 다해주신 주현 예진 뿐만 아니라, 어려운 기술적 난관을 잘 헤쳐주신 성찬, 성찬 팀원이 바쁜 와중 타 파트원들을 도우면서 개발 일정을 잘 조율해주신 성국 팀원께 감사드립니다. 

<디자인 파트에 대한 생각>

디자이너 눈에 완벽한 기획자는 없다, 라는 격언이 무엇보다 잘 공감되었던 숏커톤이라 생각하는데요, 디자이너도 좋은 기획자가 될 수 있다는 것을 두눈으로 잘 확인할 수 있었다 생각합니다. 프로젝트에 대해 잘 아는 사람이 pm이 되는 것이 맞다는 점을 상기해볼 때, 그러한 상황들엔 기획자로서 빈틈들을 잘 간파해 메꾸는 역할을 수행해야 한다는 점을 교훈으로 얻을 수 있었습니다. 기획자는 이를 테면 ux, tech, business 이렇게 세 가지 면 중 어떤 곳에 강점을 두느냐에 따라 진로 향방에 차별성을 둘 수 있을 것이라 보는데, 디자이너 분과 소통하며 그때 그때 팀에 더 필요한 역할을 수행해내는 좋은 기획자가 되고 싶습니다. 

픽셀과 세미콜론 수고하셨습니다,

롱커톤의 각 팀에서 최고의 모습을 발휘하시길 기원해요, 화이팅!

끝으로 저희 팀의 최종 결과물과 당시 사용했던 프로젝트 페이지들에 대한 결과물을 확인하실 수 있게 첨부해봅니다.

https://www.notion.so/kimboyworkman/2679db390d4e4f82b9afdb3fb404c0b1

3주차 파드 인공지능 스터디(PARDAI) 회고

안녕하세요, 파드의 기획파트(PM) 팀원 김정훈 학생입니다!

PARD 에선 다양한 스터디를 진행중인데, 저는 5주차 동안 개발, 기획, 디자인 파트에서 협업하는 6분의 학생들과 인공지능 스터디에 참여하고 있어요. (다음주차가 마지막입니다ㅠ 시간이 참 빠릅니다)

이번에는 지난주 수요일 진행되었던 파드 인공지능 스터디의 개인적인 회고를 진행하였습니다.

이번 3주차의 경우는 앱 파트장이신 진서 님, 기획 파트의 예은 님, 앱 파트의 재인 님께서 발표를 해주셨어요, ㅎㅎ

AI 이미지 인식 | 진서 님

(요약)

1. 딥러닝의 발전으로 AI 이미지 인식 기술의 수준이 정확도에서 사람을 앞섰다.
2. 그러나 실전에 활용되기에는 한계가 있었다.
3. 최근 AI 이미지 인식 기술은 이러한 한계를 극복하기 위한 방향으로 진행되고 있다.
4. 이 방향은 사실 최근 딥러닝 기술 동향과도 일치한다.
5. 인공지능 자체의 개발과 연구도 중요하지만, 각 산업 영역에 실전적으로 적용하기 위한 현실적 문제를 해결하는 것 역시 중요하다.

(생각)

(용어 주의)

명령의 목적을 명확히 주면, 사람보다 더 우수한 성능을 보이기 때문에 인공지능이 쓸 만하다. 하지만 그렇지 않은 경우, end to end 단에서 견고한 성능을 보여주기는 힘들다. 최근의 ai 인식 기술은 이러한 한계를 극복하기 위한 방향으로 진행되고 있다고 하는데, 결국은 어떤 수학 구조를 가져다 쓰느냐의 문제이고, 최근에 공부(귀동냥) 하여 알아낸 사실로는 알려진 symmetric group 들 간의 호환성을 고려하여 모델을 빌딩해야 한다는 점이 있었다. (실제로 트랜스 포머의 경우, inner product로서 dot product 를 사용하면 안 되는데 dot product 를 그대로 사용하고 있어서 미분기하 사이드에서 말이 안 되는 선택을 하고 있던 것임을 알 수 있었다. )

그러한 면에서 추가적으로, 4~5년 전부터 인공지능 필드는 이미 잘 하는 사람도 너무 많고 진입장벽이 낮은 필드란 생각을 갖고 있었는데 잘만 하면 생각보다 연구자들이 할 것이 아주 많이 남아 있다는 생각이 들었다.

또 한 가지 더 첨언하자면, 진서 님이 강조한 도메인 지식의 중요성은 역시나 예외 없이 맞말인 부분이었다. NLP에서 단어들의 공간을 vector space over R^n으로 치환하여 생각한다는 것은 사실 말이 안 되는 일이라는 센스에서 이해가 된다. 왜냐면 특정 단어 뒤에 반드시 다음 단어가 뒤따라 온다는 것과 단순히 rimannian space 에 대응 시킨다는 것은 큰 비약이고, 우리 뇌는 실제로 그러한 방식으로 말할 때 단어들을 꺼내오지 않기 때문이다.

그러니까,, 어떤 면에서 chatgpt가 지금의 성능을 내고 있는 것은 다시금 뒷목잡고 놀랄 만한 이슈임은 맞지만, 정리하면 적어도 다음의 두 가지 측면에서 큰 defeat이 있는 것이다.

1. 단어들 간의 관계, 단어들 간의 공간 사이의 엄격한 규칙을 찾아낼 수 있는 자가 있는가? (도메인 지식을 가진 학자들 중에)(그 전에 단어들 간의 거리 측정이 가능한 말이기는 한가에 대한 질문이 먼저지만.)
2. 뇌공학자 혹은 수리생물학자들 중 단어 뭉탱이와 단어 뭉탱이 사이의 연결을 어떻게 연결 짓는지 규명할 수 있는 사람이 있는가? (딥러닝은 회귀식들의 모음이지 않은가.)(물론 목적함수도 놓고, 제약조건도 놓고 하기 때문에 통계학 안에서의 수학들이 필요하긴 하지만 말이다)

AI 가 인간을 넘어서는 순간이 언제올까? | 재인 님

(요약)

ChatGPT를 활용하면 돈을 많이 벌 수 있다.

인공지능이 하는 일은 근사한 값을 찾아내는 것이다.

오리지널이 실종된다.

ChatGPT의 할루시네이션이 왜 나타나는지 정확히 알 방법이 없다 그래서 명확한 해결책도 없다

효과적인 자율 병사를 만들려면 보조 목표를 만들 수 있는 능력을 줘야 한다.

(생각)

CHATGPT 에 대한 말들은 작년 12월 초부터 봇물 터지듯 쏟아졌었는데, 올해 초반부까지도 그러한 정서에 편승했었다. 호기심에 물어본 엑셀 코드와 파이썬 코드들에 말이 되도록, 그리고 꽤 상세하고 길게 답안들을 생성해내는 것을 보고 놀랍기도 하고 지금까지 뭘 배웠나 하고 현타도 왔었다. 하지만, 근래 드는 생각은 생성 모델은 명확한 한계가 있다는 것이다. chatgpt가 하는 것은 여느 ml 모델들이 하듯(실체는 통계학) 패턴을 인식하는 것이지, 추론하는 것이 아니기 때문이다. 그리고 여기서의 추론은 인과성을 함의한다.

물론 causality learning을 포함해서 베이지안 학파로부터 출발해 2~3년 전부터 스타트업 업계나 데이터 분석 직무의 직장인들 사이에서 활발하게 인과 추론에 대한 스터디도 열리고 관심이 쏟아졌던 것은 맞다.

그럼 DL 방법들이 베이지안이 아니냐? 그건 아니다. 귀 동냥하였기로, 또 직접 보았기로는 DL은 베이즈 정리를 사용한다. 하지만 이번에도 역시, 진서 님의 요약에 대한 생각에서와 마찬가지로 비정형 데이터에 대한 도메인 지식이 제대로 반영되지 않았기 때문이라는 생각이 든다.

여기서 반기를 들만한 의견은, 알파폴드나 imagenet과 같은 예시다. 둘 모두 도메인 지식 출중한 학계에서의 성능보다 혁신에 가까운 성능을 가져다 준 사례들인데, 도메인 지식이 우선이라고? 하는 물음은 자연스럽다.

그런 면에서, 그만큼 도메인 지식 - 인공지능 지식 을 함께 깊이 있게 가져가는 연구자들이 해볼 일이 많겠다는 생각이 든다.

LCNC와 GPT기반 시리 만들기 | 예은 님

(요약)

생성형 AI가 로우코드/노코드 분야에 미칠 긍정적 영향

로우코드 도구에 대한 장벽 낮추기

새로운 유형의 개발 플랫폼의 도래

siri 에 open ai api key를 넣어보는 실습

(생각)

예은 님의 발표를 들으면서는, 노정석 대표님이 예전에 페이스북에 공유하셨던 자료가 떠올랐다. chatgpt 출시 후 2달 정도 흘렀을 때 나왔던 자료인데, 자료의 요지는 결국은 tesla와 같이 end to end로 서비스하는 역량이 없다면 결국은 API를 활용하는 회사들일 것이라는 것이었다. 당시 트위터엔 이미 생성형 ai 기반 스타트업의 실체를 까보면 api 임을 희롱하는 듯한 성격의 밈이 나돌고 있었는데, 과거를 포함해 현재까지 모두가 알고 있던 일이 아닌가 싶다.

그럼에도, 아이디어가 좋은 서비스들은 살아남을 것이라는 점이 자료의 두번째 요지였다. (그리고 그러한 서비스는 플랫폼 대기업에 귀속될 것이란 예측이 함께 있었다)

여기서 내가 생각해볼 수 있는 것은 크게 두 가지다.

하나는,

만약 내가 아이디어가 좋은 서비스를 기획 중이라면 ‘정말’ 아이디어가 좋은 것을 넘어 수많은 api 기반 프로덕트들이 제공하지 못할 새로운 가치를 제공할 수 있어야 한다는 사실이고

둘째는,

아이디어가 좋더라도 개발 과정이 애자일하고 현명해야 한다는 것이다. (모두가 각종 매체를 통해 구경했듯이 API 사용은 진입장벽이 낮은 일이니 경쟁자가 아주 많다)

정리하면, 실은 인공지능 스터디 조성을 꾀한 욕망은 앞서 꼬집은 ‘좋은 아이디어’ 몇 개를 미리 추려낸 뒤 PARD의 구성원들과 함께 개발가능한 일인지, 얼마나 좋은 아이디어인지 각을 미리 재보는 행위에 있었다.

잘 되고 있었는지는 모르겠지만, (세상에 공짜는 없다, 고민의 깊이가 필요한 시점ㅎ)

앞으로 다가오는 숏커톤과 롱커톤, 그리고 그 중간에 있을 아이디어 피칭 데이 전까지 성실히 고민해보아야 하겠다!

-읽어주셔서 감사드립니다-

PARD 기디개(기획, 디자인, 개발) 연합 세미나 회고

안녕하세요, 파드의 기획파트 팀원 김정훈 학생입니다!

파드에선 이번 주 토요일 무박2일 숏커톤을 진행하게 되는데요, 그렇기에 숏커톤을 시작하기 전 주차인 지난 주차 토요일엔 세 파트가 모두 모여 기디개 연합 세미나를 진행하였습니다.

연합 세미나는 3주 전부터 짜여진 조별로 함께했는데, 저희 조는 1조로 저를 포함해 @ 최성찬, 박예봄, 임예진, 천주현, 정성국 학생들 이렇게 총 6명으로 구성되었던 조입니다.

저희 조는 KPT 방법론을 사용해 우리동네 GS 어플을 사용하고 애자일 회고를 진행하였는데요, 그 과정 중에 있었던 일을 간략히 공유합니다.

• 진행방식

1.

우리동네 GS 앱의 장점(Keep)에 대해 작성: 5분

각자 작성한 Keep 공유

2.

우리동네 GS 앱의 문제점(Problem)에 대해 작성: 10분

각자 작성한 Problem 공유

3.

우리동네 GS 앱의 문제점을 해결하기 위한 Try 작성 : 10분

각자 작성한 Try를 제시하고 공유

4.

작성된 Try들을 ICE 방법론을 바탕으로 Impact 와 Effort를 기준으로 재배열하고,

추후 팀 및 프로젝트에 활용할 Try & Action 선정

5.

지금까지 진행한 KPT 방식에 대한 회고

이번 회고글 지면에선 저희 조가 KPT 이후에 회고한 점들을 중점으로 나누어 보겠습니다!

• 기디개 연합 세미나를 회고하며 언급 된 문제점

1.문제를 적을 때 디테일하게 적기 (해당 안건에 대한 질문을 매번 하게 되어 비효율 적임.)

2.기준의 부재 (ex. Impact와 Effot에 대해 기준삼을 수 있을 만한 구체적인 정의를 먼저 세워두지 않았기에 말의 3.공방이 나뉘었음. 이를 테면 Impact 는 유저의 수의 증감이라 했을 때, 헤비유저와 라이트 유저와의 구분을 미리 지어두어야만 함)

4.인터넷이 아닌 손으로 적고 이를 함께 보다보니 악필의 경우 읽고 소통하는 데에 어려움이 있어 시간이 부족했음.

타임어택이 있다보니 전반적으로 의사결정이 너무 빨리 정해짐.

5.이전에 서비스 도메인을 충분히 많이 사용해보지 않고 Problem 을 피드백 하였기 때문에, 문제점 팩트 체크 시 문제가 발견되었음. (ex. 과거엔 앱 리뷰등을 확인해 보면 확연한 문제점으로 꼬집어지던 이슈들이, 최근 버전에선 발견할 수 없는 경우들이 있었음.)

6.모두가 골고루 의견을 제시하지 못했음. 적게 발언한 사람을 중간중간 지목 후 발언권을 부여 하였음에도, 결과적으로 말을 많이 한 사람들과 말을 적게 한 사람들로 군집이 나뉘었음.

• 문제점에서 개선 가능한 포인트

1.말을 할 땐 순서 내지는 역할을 부여해 제시될 수 있었을 의견이 묻히는 일이 없도록 하자

2.problem state에 대한 기준을 먼저 명확히 하고, 문제 해결 단으로 넘어가는 것이 시간을 아끼는 길이다

3.글씨를 포함해 글을 쓸 땐 상대가 알아보기 쉽게(나의 암묵지, 상대의 암묵지를 함께 고려하는 배려하는 의사소통 / 들을 때는 청자에게 집중하기, 발언할 땐 청자를 배려하기)

• 숏커톤 때 우리 조가 함께 중점을 두고 가져가야할 방향은?

1.이름은 편하게 부르되 존대어를 사용하기

2.개발 실력에 편차가 존재하지만 모두의 역량이 낭비됨 없이 적절하게 섞일 수 있도록 협업, 또 그를 위한 빈번한 의사소통!

3.제한된 시간 자원 안에 목표까지 도달하기 위한 목표 관리와 리소스 관리

• 조 이름 정하기!

“픽셀과 세미콜론”

1.“픽셀“은 디자이너, 박예봄 학생을,

2. “세미콜론“은 앱 개발을 담당하고 있는, 임예진, 정성국, 천주현, 최성찬 학생을,

3.“과”는 기획 파트인 저, 김정훈 학생을 의미합니다,,ㅎㅎ

<<세줄 요약>>

1.현실적으론 실력의 편차가 존재한다. 그럼에도, 우린 함께 자라기를 추구한다.

2.작은 조직이지만 우리 팀은 각자가 지닌 역량을 숏커톤 기간 동안 모두 소비하고 나오길 원한다.

3.픽셀과 세미콜론 화이팅!!

그럼 이번 주 금, 토요일에 있을 숏커톤 이후의 소식으로 돌아오겠습니다-

@최성찬

@임예진

@천주현

@박예봄

@정성국

프로젝트, 관리하기 쉽지 않아요

안녕하세요! 파드에서는 숏커톤, 롱커톤을 앞두고 어느덧 파트별로의 연합 세미나가 코앞에 다가 왔어요. 그래서 지난 토요일에는 기획파트 마지막 세미나가 있었는데요. 오늘은 그 때 배운 내용에 대해 나눕니다.

프로젝트 매니징은 필연적으로 관리의 성격을 띄는 업이다. 무엇인가 관리해내려면, 일의 스코프와 스케쥴이 먼저 파악되어야 한다.

1. 스코프는 업무 범위를 설정하고, 제품 개발을 위해 필요한 각각의 기능을 찢어내는 작업이다.
2. 스케쥴은 투입 가능한 시간과 자원을 관리하는 것이다.

그런데 이때, 개발 범위가 유동적인가 비유동적인지? 내지는, 주어진 기간 내 변경될 가능성이 잦은지 적은지? 에 따라 워터폴 방식이 적합한 경우, 애자일 방식이 적합한 경우로 판별 가능하다.

IT 산업 분야에서 프로젝트를 관리하는 대표적인 방법 두 가지에 대해서 알아보자.

워터폴 방법

이 방법은 대기업에서 사용하기에 적합하다. WBS(work breakdown structure) 라 불리는 것이 워터폴 방법의 대표적인 사례다.

워터폴 방법을 사용해 제품을 개발하는 조직에 기획자로 일하고 있다면, 요구사항 정의하고, 그것을 문서화해 엔지니어들에게 넘기게 된다. 이때 염두할 것은, ‘워터폴 방식’ 이기 때문에 굉장히 디테일한 요구사항 정의서를 쓸 줄 알아야 하는 것이 기획자의 자질이자 책임이라 하겠다. 워터폴 방식을 사용할 때의 단점은, 개발 기간이 무한정 길어질 수 있다는 점이다.

NOTE:

admin 화면을 back office라고 한다

turn key로 맡긴다 = SI 업체에 외주를 맡길 때 처음부터 끝까지 맡긴다

애자일 방법론

스타트업에서 일하는 현직 근로자들에게 애자일이 뭔가요? 혹은 스크럼이 뭔가요? 라고 물으면 ‘밤 만이 새는 것’이라는 답변을 듣기 쉽다고 한다. 그러나 빨리빨리 끝내려고 하는 것, 혹은 밤 많이 새는 것이 애자일이 아니다..

애자일 방법의 핵심은 ‘니 일이 내 일이고, 내 일이 니 일이다’의 마인드가 갖추어져 있어야 스크럼이 가능하다는 것이다. (우습게도 그래서 야근이 많은 상황이 펼쳐진다.) IT 스타트업 조직에선 데일리 스크럼이라는 활동을 하는데 이것은 아침의 15분 동안, 서로가 하고 있는 일들을 확인하며 일의 싱크를 맞추는 활동이다. 이때 특징은 기획자가 주도하여 체크하는 것이 아니라 모두가 참여하여 진행상황을 공유하는 것, 30분을 넘기지 않는 것이다.

이는 비단 IT 개발 회사에만 국한된 내용이 아닐 것이다. 양자 컴퓨터를 개발하고 있는 회사라도, 혹은 정부 산하의 연구 조직이더라도 문화를 애자일하게 세팅하면 애자일 방법론이 가져다 줄 수 있는 효용들을 누릴 수 있을 것이다. 스크럼 매니저, 프로덕트 매니저라는 말도 있는데 IT 산업 뿐만 아니라 boring company, 뉴럴 링크, IBM 과 같은 조직의 JD 에도 심심찮게 구경할 수 있는 직무이다.

스크럼 외에도 몇 가지 알아두어야 할 용어들이 있는데 한번 정리해보자.

• 스프린트

스프린트는 보통 2주로 설정되는 것이 일반적이다. 한 스프린트 안에는 2~3일 단위의 태스크들이 할당된다. jira를 사용해본 경험이 있는 사람이라면 공감이 빠를 것이다. 프로덕트 하나를 만들기 전까지 스프린트를 얼마나 생성하면 좋을지, 각 스프린트 하나하나를 어떻게 밀도있게 보내도록 할지 고민하는 것이 관리자로서 PM이 해야할 일이다.

개발 이후엔 스프린트 회고를 한다. 목표대로 개발이 되었는지 안 되었는지 확인하는 것이 첫번째 목적이고, 두번째 목적은 커뮤니케이션이 잘 되었는지, 갈등은 없었는지, 팀으로서 좋았던 점이나 미진했던 점이 무엇인지, 앞으로는 스프린트 시 밀도있게 협업해야 할지, 느슨하게 협업해야 할지 개선사항을 도출해내고자 알고자 함이다. 회고하는 방식으로는, kpt 방식이 잘 알려져 있다.

• 프로덕트 백로그

프로덕트 백로그는, 어떤 것들을 개발해야 하는지 생각한 뒤, 그 생각들을 기능단위로 내려서 기능들을 정의한 뒤 리스트화 하여 전달하는 것을 의미한다. 크게 세 가지 갈래로 done/ todo/ block 으로 나눌 수 있고, 한 일, 할 일, 문제점을 ‘매일’ 공유함으로써 애자일하게 일할 수 있게 된다. 형식적으로는, 주로 칸반 보드를 이용해 작업의 work pipeline을 찢는 방식을 사용한다.

• 동기 커뮤니케이션과 비동기 커뮤니케이션

프로젝트 관리자가 사용할 수 있는 좋은 도구들이 시중에 많이 나와 있다. 그런데 중요한 것은, 여러 툴 들을 사용해보았다는 사실이 아니고 비동기 커뮤니케이션을 어떻게 효과적으로 구현해냈는지가 담겨 있는지 아닌지의 여부이다. 동기 커뮤니케이션은 협업자들이 동시간, 동일한 장소에서 함께 일하는 것을 의미하고, 비동기 커뮤니케이션은 다른 시간, 다른 장소일에서 함께 일하는 것을 의미한다. 그렇기 때문에 비동기 커뮤니케이션은 더 어렵다. 하지만 covid 19의 유행을 필두로 비동기 커뮤니케이션을 유연하게 돕는 각종 철학을 담은 툴들이 쏟아져 나왔는데 그 중 하나가 슬랙이라 할 수 있겠다.

슬랙에서 댓글 말고도, 모래시계 이모티콘, 체크 이모티콘, 눈 이모티콘 등을 사용할 수 있는데 해당 글에 내가 어떤 리액션을 하고 있는지 상대가 파악하기 쉽도록 돕는 것이다. 이 외에도 깃헙에 나의 status를 알리는 데 사용할 수 있는 여러 이모지도, 비동기 커뮤니케이션을 수월하게 하고자 하는 목적을 담고 있다.

사소하되, 중요한 것을 놓치지 않도록 시각화 해내어 ‘인지’를 돕는 것이다.

• Q.

앞서 살핀 프로덕트 백로그와 스프린트를 ‘나의 일’로 끌어들여와서 생각해보자. 내가 고려해야 할 일의 순서가 어떻게 되겠는가?

1. 백로그 작성하기
2. 필요할 일들의 총량을 파악하고 스프린트를 몇 개로 찢어낼지 정하기
3. 서비스가 나오기까지 스프린트 하나 당 (이걸 Iteration 부르기도 한다더라) 어떻게 계획을 수립할지 고민하기

이렇게 크게 3가지 면면이 있을 텐데, 매니저 입장에서 이를 잘 기록해두고 추적하는 것은 아주 의미있는 일일 것이다. 알려져 있기로는 x축에 투입된 조직의 Input, y축에 resource를 놓고 추적하는 Plot이 있다.

• “스프린트” 만드는 법

스프린트 보드의 대략적인 구성은 아래와 같다.

• 작업 중
• 작업 완료(검수 요청)
• 검수 중
• 수정 요청
• 검수 완료

그렇지만 익숙하지 않은 프로젝트를 처음 맡게 된 PM 이라면, 스프린트를 작성할 때 막막할 수 있다. 데이터의 흐름이나 UX 에 대한 전반적인 지식이 없다면 더욱 그럴 수 있다. 그럼에도, 스프린트를 작성할 수는 있다. 스토리 - 에픽 - 태스크 의 흐름을 타고 만들면 된다.

기획자들이 서비스 기획 초기에 많이들 작성하는 “유저 저니 맵” 을 떠올려보자. 유저 저니 맵을 어떻게 만들었던가? 에 대한 고민이 여기 녹아 있다.

그럼 스토리 - 에픽 - 태스크 가 각각 무엇을 의미하는지 살펴보자.

스토리:

스토리는 스프린트 보드를 만들 때 고려할 최상위 토글에 해당하며, 유저의 이야기를 말한다. 스토리에 해당하는 내용은 ‘사용자는 _해야 한다’ 이다. 예를 들어 당근 마켓의 경우, ‘사용자는 이웃과 물건을 거래할 수 있어야 한다’ 가 그들이 목표한 스토리 중 하나가 될 것이다.

에픽:

에픽은 feature, 즉 기능을 의미하며, 일의 중간 토글에 해당한다. 스토리 하나를 구현하기 위해선 기능들 몇 가지의 조합이 필요할 것인데 그때의 기능들을 에픽에 적으면 된다.

태스크:

테스크는 업무로서, 일의 하단 토글을 차지하고 있다. 기능은 사람이 업무를 함으로써 구현되지 않는가? 기능을 구현하기 위해 해야할 업무들을 쪼개어 놓으면 그것이 태스크다. 이 때 일반적으로는 한 태스크 당 3일 분량의 일이 할당되는 것이 권장된다.

자. 이렇게 정리된 태스크들을 칸반보드에 잘 뿌려서 관리하면 된다. 그런데 여기서 실력 있는 PM과 없는 PM의 차이가 드러난다. 스프린트에 필요한 일들을 무작정 뿌리는 것이 아니라 업무가 유기적으로 흐르게끔 유도해낸다.

상황에 따라 스프린트 하나에 여러개의 스토리를 담아내기도 하고, 칸반 보드가 단순한 개인 투두리스트로만 사용되는 것을 방지하기 위해 개인 또는 팀 단위의 다양한 필터를 걸어두기도 한다.

그리고 마이크로 매니징이 필요한 시기에는 체크리스트를 일의 사이즈 센스에서 좀 더 촘촘하게 내려앉혀 각자가 각자의 일을 스프린트 보드에 적고, 그 일들이 이루어지게 하는데 개연성을 수시로 부여한다.

추가적으로 날짜도 중요한 요소 중 하나인데, 작업 시간과 마감 시간을 관리하는 것은 리소스 관리 면에서 수치적인 증거가 반영된 회고를 가능하게 하기 때문이다.

칸반 보드의 맨 앞에 전체 일정에 대해 깔아두어 작업 자들이 플랫폼들을 이리저리 옮겨다니지 않게 배려하는 것도 하나의 센스다.

마지막으로 몇 가지의 팁을 더 적어보자면, 아래와 같다.

• 툴이 뭔지는 정말이지 중요하지 않다
• 기능의 사이즈에 따라, 스프린트 보드의 위계는 2 depth 가 되도록 하는 게 적당하다.
• x축에 시간, y축에 해야 하는 작업(누적총량 100)으로 놓고 선 위에 있는 부분과 아래 있는 부분을 추적하면 잘한 일들과 잘못한 일들을 파악할 수 있고 ⇒ 일/기간/사람을 더 늘일지 말지 애기할 수 있게 된다

PARD 인공지능 스터디 회고

안녕하세요! PARD 에 기획파트원(PM)으로 참여하고 있는 김정훈 입니다. 

PARD에선 ‘함께 자라기: 협업 역량 강화하기’, ’DART 기초부터 파헤치기’, ‘엉금엉금 블렌더’ 등 기획, 디자인, 개발 파트 구성원들이 어울려 스터디를 꾸준히 진행하고 있는데요.

데이터 과학에 관심이 많아 3월 초반을 시작으로 기획파트의 예은 님과 함께 인공지능 스터디 개설을 협의하고 구상하게 되었습니다. (예은 님은 생성 인공지능과 ESG와 같은 소셜 서비스에 예전부터 관심을 갖고 계셨어요^^) 

스터디를 개최한 목적은 크게 세 가지입니다. 

1. 인공지능, 공부할 분야가 정말 넓고 다양하다!
2. 트랜드가 너무 빨라 혼자 공부하려니 버겁다!
3. 시대가 시대인지라 PARD에서도 인공지능을 활용한 서비스가 나올 수 있는데, 어떤 서비스를 개발하게 될지 미리 애기 나눠보았으면 한다!

이후 스터디원들을 모집하고, 지난 수요일인 4월 26일 첫 스터디를 진행했습니다!

<<<<<<<<상세한 스터디 내용은 아래에서 확인하실 수 있습니다!>>>>>>>>

자기소개 시간 뒤에, 인공지능 스터디에 참여한 이유와 인공지능 공부 중 어떤 분야에 관심이 있는지 나누었습니다!

스터디원들의 답변은 다음과 같았어요 :)

-디자인, 기획, 개발 등 나와 다른 분야에서 일하는 사람들은 어떤 인공지능 공부를 하고 있는지, 인공지능 공부를 통해 어떤 효용을 기대하는지 궁금해요

-인공지능을 공부하는 각기 다른 전공사람들의 색다른 의견을 듣고 싶어요

-인공지능을 실질적으로 ‘내가’ 어떻게 활용할 수 있는지 궁금해요

-생성형 인공지능에 관심 있어요!

-web ai에 관심있어요!

그 후엔 본격적으로 아카이빙 해온 주제에 대해 각자가 짧은 시간 안에 소개하는 시간을 가졌는데요! 주제와 나눈 질문은 다음과 같습니다~

-성찬 주제: 트랜드는 기술을 따르는가, 자본을 따르는가?

기술이 먼저? 자본이 먼저? 누가 사회의 성장을 견인하는가?

-정훈 주제: 딥러닝? multitask learning?

multitask learning을 자율주행과 같은 상황 말고 언제 사용할 수 있을까?

-진서 님 주제: machine learning VS deep learning

딥러닝은 개발자도 설명하기 어려운 프로그래밍(블랙박스)을 할 수 있는데 정말 사람의 지능을 넘을 수 있을까? 머신러닝과 딥러닝의 차이점이 무엇일까? 딥러닝은 언제 공부하는 것이 좋을까?

-예은 님 주제: 머스크 VS 알트만

오픈AI의 목표인 ‘AI기술의 민주화’를 위해 세부정보를 공개하는 것이 옳은가 vs 경쟁 우위를 유지하는 것이 옳은가? 뉴럴링크의 BCI 기술이 어떤 효용을 가져다 줄 수 있을 것이라 생각하는지?

-현서 님 주제: AI리터러시와 spatial AI

AI리터러시와 전문 도메인 분야와 소비자들의 관심사가 맞물려 어떠한 B2C 서비스가 나올 수 있을까?

AI 전문 엔지니어가 아닌 입장에서는 AI 기술의 발전을 어떻게 바라볼 수 있을까?

ai가 추상적(의미 파악) 세계의 작업으로의 접근을 어떻게 하게될 수 있을까?

-재인 님 주제: AI시대를 대비하는 법

인공지능에 대체되기 쉬운 직업은? AI가 맥락을 기억하면서 다음 대화를 이어갈 수 있나? 인공지능을 어디에 어떻게 활용해야 할까?

미래에 얼마나 더 대단한 인공지능이 나올까?

1시간 20분이라는 런닝 타임이 야속하게 느껴질 정도로 많은 대화가 오고 갔는데요. 재밌는 질문과 주제들을 들고 와주신 스터디원 덕분이 아닌가 생각합니다^^ 질문 하나씩만 해도 보탤 말도 많고 생각해볼 것도 많은지라 시간 배분과 발표 배분을 다시 설정해서, 차주 미팅부터는 좀 더 유동적으로 토의가 이뤄질 수 있도록 미팅 진행방식이 조정되겠습니다.

<<<<<<<<읽어주셔서 감사합니다>>>>>>>>>

그럼 인공지능 스터디 모임은 다음주 스터디 회의록으로 찾아뵙겠습니다!ㅎㅎ

지난 한 주를 회고하며.

안녕하세요,

저는 파드에 pm으로 합류한 김정훈입니다. (ICT창업이란 전공과 수학통계학을 double로 전공하고 있는 학생이에요ㅎ) 

지난주 토요일 파드 1차 세미나를 갖고, 이후 예은 님과 인공지능 스터디 기획 아이디에이션도 하고, 현종 님의 스터디에 참여도 하며 알찬 시간을 가졌습니다!

이번에는 지난 며칠간의 주된 이슈에 대해 일상 속을 살아가며 정리해본 개인적인(그러나 너무나 보편적일) 생각들을 공유해볼 생각으로 글을 적어보았습니다. 

조금 색다른 글을 써볼까 하는데요. 순서는 다음과 같습니다. 

순서)

1위안을 주는 것

2주위를 둘러보면

3앞으로의 삶

4주변인으로서 앞으로의 삶

1위안을 주는 것

 제가 수학을 좋아하게 된 동기는 상당히 사적인 이유에서 출발했습니다. 기독교 대학인 한동대학에 와서 접한 공동체들은 저마다 강하고 약한 정도로 신앙의 색체를 띄고 있었습니다. 전 소위 모태신앙이란 이름으로 살아왔지만, 실은 어릴 때부터 강한 의문을 늘 품고 있었습니다. 과연 신은 존재하는가? 이런 질문 말고, 왜 기독교인들은 악을 행하는가? 와 같은 질문이었어요. 모순적인 사람들과, 모순적인 제 모습을 보며 인간성을 담보한 자로서 종교를 갖는다는 건 필연 거짓으로 향할 선언이 되는 것에 좌절했습니다. 그 후엔 자연스레 신의 존재 유무를 증명하려는 시도를 시작했어요. 천국은 과연 실재하는가? 와 같은 추상적인 질문에 제 자신을 가져다 놓을 때면, 늘 일종의 순환고리에 빠졌습니다. 

 반면 수학은 답이 있어서 좋았습니다. 일종의 위안이 되었달까요. 그런데 왠걸, 1년, 2년의 시간 뒤에 알게 되는 수학의 참모습은 ‘모른다’였습니다. 수학은 기본적으로 무엇을 대하기 시작할 때 난 이것에 대해 ‘모른다’는 스탠스를 취합니다. 무슨 말이냐면, 정답을 정해놓지 않고 출발한다는 것입니다. 우린 흔히 어떠한 현상을 해석할 때 내 안에서 떠오르는 생각 중 몇 개의 중, 가장 그럴 듯한 것을 정답으로 정해버립니다. 하지만 수학은, 가장 엄밀한 태도로 본인이 지닌 한계를 명시하고, 본인이 나아온 위치가 어떠한 가정에 기반한 것임을 정직하게 밝힙니다. 이것이 무슨 말이냐면, 수학은 본인의 한계를 거짓없이 표현한다는 점입니다. 

 이를 테면, 해석학의 초반에선 자연수와 정수, 유리수를 집합으로서 크기를 비교하는데, 일대일 대응이 된다면 같은 집합으로 보고, 그렇지 않다면 다른 집합으로 보는 태도를 취합니다. 하지만 실제로 규모 면에서 세 집합은 다른 크기를 가진 집합처럼 보입니다. 그럼에도, 수학은 위 세 집합을 같은 것으로 봐도 무방하다는 주장을 ‘공리’ 하에 이어갑니다. 그러면서, 공리의 한계와 취약성을 인정한 뒤, 공리를 선택하고, 자신만의 논리를 이어나갑니다. 이러한 수학의 특징은 일종의 위안감과 만족감을 줍니다. 인생에는 정해진 정답이 없다는 것을 명백한 센스로 시사하고 있기 때문입니다. 

2주위를 둘러보면

 격변하는 시대의 흐름 속에서 살고 있다고 생각하고, 많은 주변인들이 동감합니다. 무어의 법칙을 재정의하고 있는 기술을 모두가 체험하며 살고 있습니다. 이런 상황 속에서, 정말로 어떻게 살아야 하나 고민하는 사람들이 늘고 있습니다. 비단 IT업계 종사자가 아니라 해도 그럴 것입니다. 뉴스에 나온 지가 꽤 되었으니 말 다했죠. 그런 면에서, 전 앞으로, 또 지금 세상을 살아갈 제가 어떻게 지내야 잘 지내는 것인지 ‘정말로’ 고민이 됩니다. 

3앞으로의 삶

 한 가지 자명한 것은, 계속해서 뭔가 배워야 산다는 것입니다. 그런데 배움을 방해하는 요인이 있죠. 많은 방해 요인들 중 하나로 예를 들어 제가 오늘 해보고픈 말의 논리 전개를 진행해보겠습니다. 

학생들이 게임을 싫어하게 만드는 방법은 -> 게임을 숙제로 내면 된다

모든 숙제는 하기 싫다 -> 뒤집어 보면 하고 싶은 건 숙제가 아니다 

-> 어떤 종류든, 일을 숙제로 느끼지 않게 만들면 된다. 취미삼아 하듯 느껴야 한다. 

-> 그렇게 되려면 어떤 장벽을 실제로 허물어야 하나?

필연적으로 마주할 질문, ‘내가 진짜 원하는 것이 무엇인가?’

긴 텀의 인생이 있어서 정말 내가 ‘욕망’하는 것. 

이미지를 preprocessing하고, 웹 빌딩하는 일들이 내게 즐거움이나, 만드는 과정에서의 기쁨, 보람이랄 것들을 줘야 한다. 

-> 만약 그렇지 않다면?

내가 나 자신이 무엇을 원하고 있다고 말하고 있는지 못 듣고 있는 것. 

‘나다움’을 찾아야 함. 이것은 일종의 예술의 영역이라고 생각함.

‘줄세워서 우등’에 속해야 하는 것이 오늘의 날에 정말로 유의미한 일인가? nope! 

한편,

gpt-4 나오고 나서부터 인간과 기계의 협업이 점점 더 강조되고 있는데 무엇을 공부할지 선택하는 것은 정말로 중요한 문제가 되었음. 그 누구도 당신의 일에 대한 경쟁력을 보장해줄 수 없음. 현재 있다고 그래도, 5년 뒤, 10년 뒤? 아무도 못함.

한국은 관념이 너무나 단색인 사회. 많은 면에 있어 정답을 정해놓는 한국 문화. 생각에서 게으르기 때문. <- 정답을 정해놓고/정답이 있다고 생각하고 지도하는 여러 문화층위 속 사람들 

‘안전한’ 산업을 찾아 떠나야함. 안전함이 무엇인지는 여러 정의가 있을수 있음. 이때 한 가지 요인은 주된, ‘다양함’일 것임. 

정리해서, 학생의 때가 의미있으려면(포함해서 앞의로의 생이) 관념을 정하는 것이 아니라(정답이라 생각하는 실을 정해두고 달리는 것이 아니라) 스스로 생각의 방식을 다듬고, 정해나가는 것임.

제안) 

남이 의미있다고 그래서 하는 일 말고, 스스로 의미있다고들 생각하는 일을 찾아내시고 바로 시작해야만 한다! 사이드든 뭐든, 한국사회는 준비기간을 너무 길게 요구하는 문화가 깔려있으니, 그런 모습이 몸에 배지 않게 털어내야 함.

“만약 논문이라면 바로 써보면 되는 거고 창업이라면 실제로 바로 해봐야 하는 거고.”

4주변인으로서 앞으로의 삶

 이러한 생각들을 파드의 관점으로 당겨와보면, 파드의 팀원들이 해야할 것은 단순히 툴을 익히고 활용하는 것에 그쳐선 큰 의미가 없을 수 있습니다. 다음주도 달리기를 이어갈 제 자신이, 또 여름방학 때까지 함께 달릴 소중한 동료분들이 정말로 의미있는 결과물을 얻게 되는 시간의 흐름을 맞이하길 소망합니다. 

읽어주셔서 감사합니다, 즐거운 주말들 보내시길 !

PARD PM 파트에 합류하다!

안녕하세요! PARD(파드) 기획팀에 합류하게 된 김정훈입니다! 

지난주 토요일 처음 파드 공동 세미나가 있었는데요, 그에 대한 회고와 다짐을 나눕니다 :)

-파드에 조인하게 된 이유

 저는 지난해 겨울을 기점으로 project managing 직무에 관심을 갖게 되었습니다. 대학교 1학년 때는 기획에도 관심을 갖고 있었지만, 숫자를 제대로 이해하고 해석하는 데이터 리터러시 역량을 강화해야겠다는 생각에 통계를 비롯힌 공부에 비중을 두며 생활해왔습니다. 대학원을 마음에 품고 공부를 이어갔지만, 공부를 해볼수록 재미를 느끼는 것과는 별개로, ‘잘 할 수 있는 일’을 업으로 삼아야겠다는 생각이 커졌습니다. 

 저는 일이 work as life로 되려면 ‘누가 시키지 않아도 하고 있는 일’ 이 되어야 한다고 봅니다. 그러한 면에서 pm직무는 사람들과 대화하고, 그들이 필요한 것을 리서치하고, 기술이나 시장에 대해 분석하는 것은 누가 시키지 않아도 자처해오던 제게, 딱 맞는 일일 것이라 느꼈습니다!

 하지만 분야를 막론하고 현대사회에서 일이 일이 되게 하기 위해선 협업이 필요충분조건입니다. ‘협업을 잘하는 사람’ 인지 아닌지의 여부는 measure하기 어려운 문제인데, 제 자신이, 또 파드에서 마주하는 많은 분들이 협업을 잘하는 사람! 이라고 신빙성있는 근거를 제시할 수 있는 경험을 빌딩하는데 일조하는 구성원이 되었으면 합니다. 

-파드에서 하고 싶은 것, 개인적 측면

1) 스터디 조직.

2) 각 파트 팀원분들과 주기적인 소통. (웹 파트 개발자 2분, 앱 파트 개발자 2분, 디자이너 2분)

-파드에서 하고 싶은 것, 공동체의 측면

 좋은 manager는 맥락을 사전에 설명해주지 않아도 무엇이 필요한지 다 알고 있다고 생각해요. 잘하는데, 열심히까지 하는 사람인거죠. 프로덕트의 결과물은 성장시킨 사람들의 합이라는 말을 어딘가에서 본 적이 있는데요, 그러한 면에서 어떻게 해야 지금 나와 함께하는 저 사람이 지금보다 더 성장할 수 있게 만들 수 있나?가 제가 pm으로서 염두에 두고 있어야할 질문인 것 같습니다. 

 추가적으로 pm에게 가장 많이 요구될 스킬이 있다면 소프트 스킬일 듯 싶은데요, 이 부분을 위해 최근 사회사업 길라잡이 책인 ‘복지요결’을 읽기 시작했습니다. 타인과 소통할 때 어떠한 stance를 취해야할지 좋은 참고사항은 많더라구요. 추후 여건이 된다면 좋은 글귀들 모아 한번에 공유해보겠습니다.  

-목표 공유

기획파트 첫주차 세션에서 각자의 현재모습과 파드 활동 종료 이후의 기대하는 모습을 나열해보는 시간이 있었는데요, 제 목표는 아래와 같습니다 :)  

• before

기획자로서 개발자, 디자이너와 협업한 경험이 없음.

웹/앱 개발 domain의 pm이 구체적으로 어떤 role을 수행하는지 모르고 있음.

더해서, job market에서 어떤 factor들을 강조해야 경쟁력있는 applicants가 되는지 모르고 있음.

• after

구체적인 협업 경험에 대한 log와 기여도 정도를 popol에 제시할 수 있을 수준으로 build해놓음.

기획 직무와 관련하여 자문을 구할 선후배, 동료들이 있음.

현업에 투입되기 전에 무엇을 준비해야 하는지 ‘아는’ 상태.

-질문 공유

파드 첫주차 세미나가 끝나고 스스로 던져본 질문들을 공유합니다. 추후 과제로 하나하나 풀어나가고 싶습니다ㅎㅎ

• 기획 파트에 어떤 방식으로, 어떤 내용으로 massive한 기여를 할 수 있을 것인가?
• 기획자 pm 이나 tpm 직무의 사람들이 sql/r/python을 어떻게 실제로 사용하는지 공유한 문서가 있나?
• 웹/앱/디자인 개발 과정을 딥하게 학습한 결과가 내게 어떻게 유리하게 작용할 수 있나? 난 그걸 어떤 형태의 아웃풋으로 로그남기고 자랑할 수 있나? 실제로 협업 외에 어떤 유용한 이해도가 성장할 수 있나?
• 현업에선 sql을 많이 사용한다는데, 오늘의 내가 남긴 일의 흔적과 professional이 남긴 일의 흔적 둘의 간극은 정확히 어떤 요인들 가운데 있었고 그 gap은 수치적으로 얼마나 차이가 났나?
• TPM으로서의 직무에 멘토삼을 수 있는 사람이 누군인가?
• 기획자로서 pard에서, 현실적으로 어떠한 유의미한 결과들을 산출할 것인가?
• 숏커톤에 pm이 어떤 부분까지 관여하도록 환경을 setting해둘 것인가? 어떤 툴 사용? 어떤 로그를 실질적으로 남김? (이야기/ 숫자/ 관리)
• 롱커톤에 어떤 부분 툴을 사용하고, 실제로 팀의 실적을 어떻게 개선할 것인가? 어떻게 표현할 것인가?