
| 시간 | 학습내용 | 소요시간 | 메모 |
|---|---|---|---|
| 아침 | |||
| 점심 전 | |||
| Arvo | |||
| Evening |
바이브 코딩을 통해 빠른 시도와 레슨런이 가능해진만큼 기획의 본질에 더 집중해야한다는 메세지를 던지는 글이였다. 지난 주 노코드 웹개발 세미나를 들은 후 읽으니 더욱 와닿았던 글.
작가의 개발일지 중 인상적이였던 부분은 기술의 한계를 우회하는 판단과 서비스의 타겟군을 생각하는 과정이였다.
카카오톡 알림 대신 이메일 알림으로 우회한 선택을 보고 타협과 합리적인 판단은 한끗차이라는 생각을 하게 되었다. 타협이 되지 않으려면 어떻게 해야할까.
항상 강조되는 목적 중심 사고가 여기서도 재조명 된다. 여러가지 고려 사항 속에서 길을 잃지 않으려면 목적이 무엇인지 되묻고 목적에 필요한 게 무엇인지 생각해야한다.
또한 나의 판단이 꼼수가 되지 않으려면 탄탄한 하드스킬 역량이 받쳐줘야된다고 생각한다. 그렇지 않으면 챌린지를 회피하면서 그것이 합리적인 판단이라 믿는 오류를 범할 수 있기 때문이다.
그 다음 인상적이였던 부분은 기능 자체보다 이 기능이 누구를 타겟팅해야하는지를 고민하는 과정이였다. 개발자와 PM의 관점 차이가 발생하는 포인트이지 않을까.
타겟이 있어야 서비스의 목적과 가치가 생긴다는 걸 직접 개발해보면서 체감했다고 하는데, 바이브코딩으로 빠르게 웹을 개발할 수 있는 환경의 장점과도 이어지는 대목이라고 생각한다. 실패 비용이 0인 만큼, 에너지를 쏟아야하는 것은 '누가 왜 써야 하는가'라는 고민이라는 말도 중요한 논점이라고 생각한다.
바이브 코딩의 등장으로 코딩이라는 전문적인 영역의 허들이 드라마틱하게 낮아졌다. 그러다보니 '바이브코딩 = 코딩 역량 대체'라는 인식이 생겼다. 하지만 PM이 코딩이 필요한 일을 해내는 것이 정말 의미 있는 일일까? '누구나 코딩이 필요한 일을 할 수 있다'라는 사실은 매우 매력적이지만 작가의 말 처럼 실패 비용이 0이라고해서 사용자가 부담해야하는 불편에 대한 비용도 0은 아니라는 사실을 유념해야 한다.
세미나에서 만난 개발자 분들에게 우려 섞인 질문을 한 적이 있다.
"비개발자들이 노코드 개발로 만든 아웃풋을 업무에 적극적으로 활용하는 것이 개발자 입장에서 어떻게 받아드려나요?"
결론만 말하자면 답변은 '나쁘게 생각하지 않는다'였다. 다만 조직 차원에서 이런 기술을 업무 파이프라인에 적용하는 방식이 더 중요하다고 말했고 현업에서도 이미 많이들 활용하고 있으니 내가 우려하는 부분에 대해 너무 걱정하지 않아도 된다고 하셨다.
답변을 듣고 나니 그동안 나는 '조직 속의 나'를 그리지 못하고 있다는 사실을 알게되었다.
내가 AI를 기깔나게 활용할 줄 알아도 조직의 문화와 목표에 적합하지 않을 수 도 있다는 사실을 생각해볼 수 있었다.
결론적으로, 바이브 코딩으로 개발을 하던 뭘 하던 PM은 기획의 본질을 생각해야하고 협업을 위한 원활한 소통을 중시해야한다는 PM의 황금율로 아티클 스터디를 정리할 수 있을 거 같다.
e.g. "검색 결과 개편"❌ → 어떻게 개편할 건지 실행 가능한 수준으로 기술📖 [3-3] 가상으로 내가 만드는 서비스의 회원 가입 or 회원 탈퇴 정책서를 작성 해 보세요.
📖 [3-4] 회원가입 시에 발생할 수 있는 서비스 에러 케이스를 작성해보세요.
📖[3-5] 앞서 작성한 서비스의 회원 가입 or 회원 탈퇴 정책서를 가지고 해당 기획안을 작성해 보세요.
새삼스럽게 밝히는 것 : 경험 단위 분석 내꺼지롱