프로덕트 엔지니어로서 성장
이직을 준비하면서 우연히 어떤 회사의 CTO님과 커피챗을 할 기회가 생겼고, 그 분에게 위 질문을 받았다. 하지만 프로덕트 엔지니어로서 성장하고 있다고, AI 도구를 잘 활용하고 있다고 말할 수 없었다.
이전 회사에서는 간단한 코드 뭉치 작성이나 문제 해결의 갈피를 잡기 위해 ChatGPT를 사용했었고, 퇴사 후에는 아쉬웠던 구현 과제에 Claude 및 Cursor를 조금 사용해 봤을 뿐이었다.
그분이 보기에 나는 프로덕트 엔지니어로서 적극적으로 성장하고 있지 않은 것으로 보였던 것 같다. 나에게 AI 도구를 이용해서 클론 코딩을 해 보는 것이 어떻냐고 제안을 하셨다. 곰곰이 생각해 보니, 프로덕트 엔지니어를 지향한다면 적어도 제품을 0부터 1까지 만들어 본 경험이 있어야 신뢰를 줄 수 있다는 생각이 들었다.
커피챗을 마무리한 뒤, 집으로 돌아가는 버스 안에서 프로덕트 엔지니어로서 성장하는 모습을 보여줄 수 있을 만한 게 뭐가 있을까 고민했다. 처음부터 너무 큰 문제를 해결하려면 부담감이 크니, AI 도구와 차근차근 친해지기 위해 작은 문제부터 해결해 보기로 마음먹었다.
불편했던 경험
이직을 하면서 종종 알고리즘 테스트나 구현 과제를 수행한 적이 있다. 첫 경험은 토스의 구현 과제였다. 4시간 이내에 요구사항에 맞춰 웹 앱을 구현하는 과제였다. 하지만 제대로 시간을 관리하지 못해서 구현율이 50% 채 되지 않았다. 결과는 당연히 탈락이었다.
시간 관리를 제대로 하기 위해 타이머 앱을 알아보았다. 꽤 괜찮아 보이는 포모도로 앱을 내려받아 사용해 봤지만 나의 문제를 해결해 주지 못했다. 나는 특정 시간에 알림이 울리길 원했는데, 대부분의 포모도로 앱은 일정 단위 시간마다 알림을 울리는 방식이었다. 나에게 아무런 도움이 되지 않아 그 앱을 삭제했던 기억이 불현듯 떠올랐다.
이 소소한 문제를 해결할 수 있는 알리미 앱을 만들기로 했다.
소소한 제품을 만들어보자
우선 내가 원하는 알리미 앱을 머릿속으로 그려보았다. 특정 시간에 알림이 울리는 앱. 핸드폰을 꺼내 떠오르는 생각들을 메모장에 정리했다. 정리한 요구사항은 다음과 같다.
목적
- 프로덕트 엔지니어로서 성장하기
- 문제를 정의하고 해결 방법을 설계하고 실천하기
- 제품의 제로 투 원 경험을 해보기
- AI 도구를 활용하여 생산성을 높이기
문제 정의
- 대부분의 포모도로 앱들은 일정 시간마다 알림을 울리는 기능만 제공한다.
- 하지만 내가 원하는 기능은 특정 시간마다 알림을 울리게 하는 기능이다.
목표
- 특정 시간에 알림을 울리는 알리미 앱 만들기
기능 요구사항
- 지정된 시간에 알림이 울려야 함.
- 웹 워커를 사용하거나 Web API 중 notification api가 있으려나?
- 알림은 청각적, 시각적 요소 두 가지로 표현
- 네트워크는 필요 없음
- 알림 조건을 편하게 설정할 수 있어야 함 (and 및 or 논리 활용 가능)
- 범위 조건(몇 시 몇 분부터 몇 시 몇 분까지)
- 단위 조건(매 시간마다, 10분마다)
- 특정 값 조건(14시, 35분)
- 단순함을 위해 활용 가능한 값은 시, 분으로 한정
- 조건 규칙 집합은 로컬 기기에 저장
- 조건 규칙 집합을 관리할 수 있어야 함(CRUD)
- 조건 규칙 집합은 각각 활성화 여부가 존재하며, 활성화를 끄면 해당 규칙 집합은 무시되어 알림이 울리지 않음.
- 데스크탑 앱으로 사용할 수 있으면 좋음. (Electron)
기술 스택
- React
- TypeScript
- Electron (선택 항목)Cursor를 활용하기
정리해놓은 기획을 Cursor에게 주고 앱을 만들어 달라고 했다. Cursor가 알아서 필요한 부분들(기술 스택, 부가 기능 등)을 되물어보았고, 나는 대답을 해 주었다.
기본적인 레이아웃과 간단한 Information Architecture 를 지정해주니, 디자인은 꽤 잘 구현해주었다. 또한 푸터, 알림 조건 미리보기 기능, 알림 조건 생성/수정일과 같이 내가 놓친 기능들을 챙겨주었던 부분은 꽤나 놀랐다. 직접 구현했다면 꽤나 시간이 걸렸을, 웹 워커를 활용한 기능도 빠르게 구현해주었다.
다만 명확하게 지시하지 않은 부분은 임의로 구현하기도 하니, AI 도구에게 많은 맥락을 제공해야 한다. 특히 처음에 만들어진 알림 조건 설정 기능의 UI/UX 및 데이터 구조 부분이 미흡했다. 이 기능을 개선해나가는 과정에서 시간이 조금 걸렸다.
또한 에러가 났을 때, 에러 메시지를 그대로 복붙하고 문제를 해결해달라고 요청하면 AI 도구가 당장 그 문제를 회피하는 방식을 취하는 경우가 있었다. 표면에 드러난 문제에 대한 근본적인 원인, 그것을 해결할 수 있는 근본적인 방법들에 대해 개발자도 같이 고민해야 한다.
로컬에서 빌드 결과물을 테스트한 뒤, 깃헙 워크플로우로 배포된 앱을 내려받아 직접 실행해보았다. CI/CD 설정과 Electron 포팅 과정에서 시간을 좀 잡아먹기는 했지만, 앱이 잘 작동하니 굉장히 뿌듯했다.
최소한의 실행 가능한 앱을 만들고 나니 저수준의 코드가 눈에 띄었다. 0-1을 완료한 후에는 코드를 정리하는 데 힘을 쏟았다. 저수준으로 구현된 비즈니스 로직들이 이곳저곳에 산재해있고 이것들을 전파하느라 props drilling이 심했다. 나는 이 문제들을 해결하기 위해 Context API와 Reducer를 조합한 패턴으로 변경하도록 지시했다. 화면 구성요소를 의미론적 단위로 나누어 별도의 컴포넌트로 분리했다. 공용 컴포넌트를 만들어 추상화하고, 재사용성을 높였다.
바이브 코딩에 대한 생각
프로덕트 엔지니어로서 성장하기 위해 문제를 정의하고 문제 활용에 AI 도구를 활용했다. 거의 하루 만에 앱을 만들고 빌드 및 배포 프로세스까지 설정했다. 단순한 제품이라도 만드는 과정은 결코 단순하지 않았다.
AI 도구에게 더 많은 맥락과 더 명확한 지시를 내릴수록 업무를 잘 수행하는 것을 알게 느꼈다. 요구사항뿐 아니라 기술 스택부터 코드 컨벤션, 데이터 구조, 클린 코드, 구현 패턴 같은 부분도 개발자가 명확하게 지시를 하는 것이 좋다. (혹은 구현 단계에 들어가기 전, plan 모드를 이용해 자문을 구하는 것도 좋은 방법이다.)
AI 도구가 수행 중인 일을 리뷰하여 올바른 방향으로 나아가고 있는지 검토하는 것도 중요하며, 잘못된 방향으로 가려고 한다면 지시를 잘못 내리지 않았는지 회고해야 한다.
아직까지 Cursor는 제품을 만들기 위한 슈퍼 앱은 아니라는 생각이 들었다. 특히, 아이콘을 만드는 능력은 젬병이었다.
그릇에 토마토 베이스 수프와 노란 면, 토마토가 얹혀진 아이콘을 만들어 달라고 하니, 위와 같은 아이콘을 만들어주었다… 😮💨 Cursor는 아이콘을 만드는 도구가 아님을 알게 되었다.
결국 나는 precraft라는 별도의 아이콘 생성 도구를 사용했다. 이번 경험에서는 피그마를 사용할 일이 없었지만, 만약 디자인 영역에서도 도움을 받아야 했다면 또 다른 도구를 사용해야 했을 수도 있다. 결국, 도구들은 각각 강점이 있는 것이다.
바이브 코딩은 과연 은탄환일까? 결국 그것은 도구를 활용하는 사용자의 능력에 달린 게 아닐까? 그 능력은 과거의 업무 방식과 다를 게 없다고 생각한다. 문제를 정의하고 목표를 설정하고 요구사항을 정리하고 필요한 기술을 선정하고 구조를 설계하고 업무를 지시하고 리뷰를 하고 개선을 하고.. 그저 사람에게 시키던 일을 도구에게 시킬 뿐이다.
새로운 물결에도 불구하고 변치 않는 경쟁력, 그것은 이런 능력이 아닐까, 라는 생각을 한다.
마지막으로, 해당 앱은 https://github.com/Einere/tomato-mien 에서 확인할 수 있다.