디스콰이엇 커피챗으로 채용까지 골인한 이야기 2

이 글은 고이의 COO @김명곤 님께서 작성하신
“디스콰이엇 커피챗으로 채용까지 골인한 이야기 1” 에 이은 연작으로 궁금하신 분은 전의 글을 읽어주세요!

1탄을 업로드한 시기가 8월이였는데 벌써 10월의 끝을 향해 달려가는 이 시점에서 2탄이 올라왔네요ㅎㅅㅎ
그 만큼 바쁜 시기를 보내고 있었다고 생각해주시면 감사하겠습니다

어떻게 명곤님과 커피챗을 하게 되었나?

개발자로 커리어를 만들어가고 있던 저는 항상 비즈니스에 임팩트를 만들어가는 사람이고 싶었습니다. 당시 채용시장의 불황과 저의 커리어에 대한 고민이 겹쳐져서 정말 힘든 시기를 보내고 있었어요.

그러다가 이런저런 커리어의 고민을 갖고 있던 지난 7월 명곤님이 디스콰이엇에 작성했던 개발자->PM으로 전환한 글을 읽고 이야기를 나누고 싶어 커피챗을 신청했습니다.

명곤님과 커피챗을 하며 얻은 인사이트

명곤님과 커피챗을 하며 크게 2가지의 인사이트를 얻을 수 있었습니다.

1. 그 간의 역량을 활용해 새로운 직무로서의 가능성을 보다

저는 당시 개발자로 살아가기 시작한 1년의 시간을 돌아보며 이 길이 맞는 길일까 고민했습니다. 구체적으로는 "빅테크에 합류하기 위한 개발자로서의 커리어패스"에 대한 회의감을 많이 갖고 있었습니다.

개발을 처음 시작했던 것도 비즈니스에 활용하기 위해서였지만, 점점 개발을 하다보니 "코더"의 정체성을 갖게 되었고 기술에 매몰되는 듯한 느낌을 받았죠. 물론 여전히 개발자에게 이런 코더로서의 역량이 중요하다고는 생각하지만, 그게 제일 중요한 것인지 혹은 저에게 맞는 옷인지에 대해서 회의감을 많이 느끼고 있었어요.

그래서 명곤님은 비슷한 고민을 했었고, 그 과정에서 본인의 장점을 활용해 프로덕트, 오퍼레이션 등 분야를 가리지 않고 임팩트를 내왔던 본인의 경험을 들려줬어요.

그 이야기를 듣는 것 자체로 저의 장점과 그 간의 경험(창업, 개발자)을 활용해 product/sales/operation에 국한되지 않고 다양한 범위에서 일을 해볼 수 있겠다는 용기를 갖게 되었습니다.

1. 결국 고객이해와 실행력이다.

명곤님은 정말 미친 듯한 실행력을 갖고, 고이에 합류하자마자 두 달만에 SEO 개선을 통한 유입을 10배 상승 시켰습니다. 뿐만 아니라 전사 관점에서 오퍼레이션 메인 업무인 고객 상담 지표 개선을 위해 뛰어들었어요.팀의 PMF를 찾는 과정에서 가장 중요한 것 고객이해와 실행력인 것 같다고 이야기했습니다.

이런 관점에서 저에게 있어서 창업을 한 경험, 개발을 한 경험이 본인처럼 전사적으로 중요한 것들을 판단하고 직접 실행해볼 수 있는 힘을 갖고 있다고 이야기해줬어요.

마찬가지로 저의 이야기를 쭉 들려드렸고, 명곤님은 "병택님은 그런 역량이 있지만 그걸 이력서와 포트폴리오에서 더 잘 풀어냈으면 좋겠다." 정말 많은 역량이 있을텐데 잘 정리되지 않은 것 같다는 평가를 내려주기도 했어요.

그래서 이를 기반으로 저의 이력서와 포트폴리오를 보면서 수정사항을 알려주고, 제 커리어 방향성에 대한 코멘트도 해주는 등 정말 열심히 저의 관점에서 이야기를 많이 해줬습니다.

커피챗이 끝난 2주 뒤 고이의 대표인 슬옹님과 만나다.

고이가 팁스 선정이 되고, 생존 런웨이가 길어지면서 명곤님이 대표인 슬옹님과 만나봐도 좋겠다는 제안을 줬어요.

슬옹님과의 만남에서도 고이는 장례라는 산업을 누구보다 빠르게 임팩트를 내며 바꿔나간다는 인상을 받았어요. 기존 장례산업의 비즈니스 문제가 무엇인지, 이를 해결하기 위해서는 어떤 것들이 필요한지, 우리 조직은 현재 어디에 와있는지 솔직하게 이야기해줬습니다.

무엇보다 진짜 이 사람은 장례에 미쳐있고, 뭐든 하겠다는 인상을 받았어요. 그러면서 동시에 도메인 한정적이고, 프로덕트나 스타트업의 관점에서 바라보지 않거나, 조직과 구성원들에 대한 관심이 없는 대표도 많이 봐왔는데 슬옹님은 그러지 않았죠.

그리고 인간적으로도 정말 함께 하고 싶어지는 매력이 있었습니다.

그렇게 고이에 합류하고 싶다는 마음이 점점 커지게 되었고, 결국 팀 인터뷰를 거치면서 이 구성원들과 함께라면 뭐든 해낼 수 있겠다는 확신을 갖게 되었어요.

비즈니스, 팀, 나의 역할의 관점에서 고이에 합류한 이유

슬옹님과의 커피챗 이후 정식 채용절차는 빠르게 진행되었어요. 이직에 대한 고민을 3개월 넘게 해왔던 저로서는 이렇게 빠르게 진행되는 것에 대한 고민도 있었어요.

그래서 저 스스로 고이에 합류해야하는 이유를 비즈니스와 팀, 그리고 저 개인의 역할 3가지 측면에서 정리했어요.

[비즈니스의 측면]

저는 그간 주거, 의료 등 고관여 상품에 관심이 있었던 것 같아요.

고관여 상품은 보통 의사결정에 많은 시간이 들고, 비용이 비싸며, 큰 자본을 가질 수록 시장파이를 많이 가져갑니다.

그런 비즈니스는 보통 데이터가 공유가 안되어 소비자들이 접근하기 어렵고 여기서 시장의 불균형, 불평등을 만들게 됩니다.

이런 시장을 바꾸는 것에 저는 유독 관심이 많았던 것 같아요.

왜냐하면 보수적인 시장인 만큼 실험이 성공하면 임팩트도 크고, 다양한 프로젝트를 진행해볼 수 있다는 점이 매력적이였던 것 같아요.

장례라는 산업도 저에겐 그런 관점에서 비슷했습니다.

무엇보다 최근 소중한 친구의 장례를 도우며 장례 자체가 소중하다는 감각도 느끼기도 했었구요.

[팀의 측면]

고이는 장례라는 무겁고 불합리한 시장에 참 많은 도전을 해왔었어요. 이런 도전을 하는 과정에서 가설을 세우고 검증하는 방식 그 자체에서 굉장히 속도감 있었고, 잘 하고 있다고 생각되었어요.

특히 그 간의 레슨런을 기반으로 성장을 막 하던 시기였어서 팀 전체 분위기가 좋았습니다. 각자가 “사려깊은 솔직함”으로 평가하고, 서로를 끊임없이 성장할 수 있게 독려하고, 그러면서 웃음을 잃지 않는 팀이였어요.

[개인의 역할 측면]

사실 이 부분이 제일 고민이였어요. 제안을 받은 Sales PM이라는 직무의 개념이 모호했어요. 특히 Sales를 안해본 것은 아니였지만, 메인인 롤로 가져가는 것에 대한 고민도 있었고 Sales에 PM이 어떤 기여를 하는 거지?라는 생각이 있었습니다.

그런데 슬옹님과 이야기하면서 합류 후 1개월, 3개월, 6개월의 목표와 과업을 이야기를 했었는데 그 부분이 많이 동의가 되었어요. 세일즈 영역에 직접 뛰어들어보고, 세일즈 영역에서 여러 데이터와 지표들을 분석해 프로덕트, 세일즈 관점에서 매니징을 하는 업무. 이런 업무라면 내가 어떤 역할을 해보고 성과도 만들어볼 수 있겠다 생각했어요.

저에게 합류 후 각 기간마다 주어졌던 미션은 아래와 같습니다.

1개월 - 상담을 메인으로 한 세일즈 업무를 맡아 고객의 니즈를 파악하고 해결한다.

3개월 - 오퍼레이션팀이 운영되는데 필요한 여러 프로덕트와 체계화를 위한 시스템을 구축한다.

6개월 - 팀을 안정적으로 운영하고 확장하며 오퍼레이션을 넘어 비즈니스 자체를 레버리지한다.

제가 조직에서 해줬으면 하는 것을 깊게 고민해보고, 먼저 제안해주는 사람들과 일을 함께 한다는 것 자체로 저에게는 매력적이였습니다.

합류 이후 3개월을 향해 달려가고 있다.

8월 7일에 합류하고 2달이 조금 넘는 시간동안 정말 미친듯이 달렸습니다.

밤,낮,새벽 가리지 않고 일을 했습니다.

세일즈, 오퍼레이션, 개발을 오가며 정말 많은 실험과 가설들을 검증했는데요.

입사 2달만에 제가 달성한 성과들은 아래와 같습니다.

9월 고객상담 지표 전환 달성률 1등,
어드민 개선을 통한 지표 관리 개선,
홀리스틱스를 활용한 데이터 시각화,
오퍼레이션 업무 체계화 등 정말 많은 것들을 했어요.

그 결과 지난 주 금요일부터 오퍼레이션 팀 리드로서 더 많은 책임과 권한을 갖고 일을 하게 되었습니다. 각각의 과정에서 얻었던 인사이트도 곧 정리해서 디스콰이엇에 올려보도록 하겠습니다.ㅎㅎ

고이는 커피챗에 적극 열려있습니다.

지금 이렇게 소중한 인연을 만들게 된 것은 디스콰이엇의 커피챗 덕분이라고 생각해요. 커피챗을 통해 나와 비슷한, 혹은 내가 가고 싶은 길을 먼저 걸었던 사람과 이야기나누는 것 만큼 큰 도움이 되는 것은 없는 것 같아요.

그렇기 때문에 저도, @김명곤 님도 디스콰이엇 커피챗을 적극 활용해 네트워킹하고 있습니다. 비슷한 고민이 있거나, 저희의 이야기가 궁금하다면 커피챗을 적극 신청해주세요!

서로 재밌게 이야기 나누고 도움이 되면 좋을 것 같고, 또 핏이 맞다면 고이로 합류할 수 있는 문도 활짝 열려있습니다ㅎㅎ

Notion API로 사내 백오피스 업무 프로세스 개선해보기

0.들어가며

안녕하세요. 저는 프론트엔드 개발자 현병택이라고 합니다 :)

제가 전 직장에서 Notion API를 활용해 백오피스 업무 프로세스를 개선하는 프로젝트를 진행했었는데요!

메이커분들이 관심을 가지실 수도 있을 것 같고, 제 스스로도 경험을 정리하는 차원에서 첫 메이커로그를 남기게 되었습니다ㅎㅎ

부족하지만 재밌게 읽어주세요!

1.프로젝트 목표

이번 노션 프로젝트의 핵심은 두 가지 목표가 있습니다

1) 기존 구글폼등으로 분산된 서비스 예약 및 채용 페이지 관리 및 DB관리를 노션페이지로 일원화하는 것

2) 별도의 어드민 페이지 없이 모든 예약페이지 관리부터 신청자 데이터도 노션으로 관리할 수 있도록 하는 것.

+) Notion API 자체가 어떻게 구성되고, 어디까지 가능한지, 한계점은 어디인지는 저의 블로그에 글을 남겨놨으니 여기서 확인을 해보시면 더 많은 내용을 검토하실 수 있을 것 같습니다 🙂

Notion API 어디까지 가능하니?

2.결과물 미리보기

2-1) 비효율적으로 진행되던 예약,신청페이지를 노션으로 일원화

[데모 영상]

file.notion.so

https://file.notion.so/f/s/25cfea5c-98b7-47c1-af7c-e3571ce67531/채용페이지.webm?id=30dfdb40-dfc2-470b-bc60-3105e3383705&table=block&spaceId=177b29e1-2726-40e0-9cec-f0097d016415&expirationTimestamp=1683619006060&signature=CKAxjObPt3VlUq_hEpxJn_Qgv3b5xCwOdUtAUUbwY9o&downloadName=채용페이지.webm

노션은 별도의 폼빌더가 없습니다.

프로덕트 헌트에서 좋은 평가를 받은 노션폼(https://notionforms.io/)라는 서비스가 흥행하고 있긴 합니다. 그러나 개인으로 사용하기엔 유료 서비스와 외국 사이트라는 것이 진입 허들을 만들고 있습니다. 또한 노션페이지에서 직접 수정할 수 있는 것이 아니라 notionForms에서 form에 대한 관리를 별도로 해줘야하기 때문에 번거로움이 있습니다.

그래서 저희 회사에서도 기존에는 위와 같이 별도의 노션 페이지를 공유해서 채용 소개 페이지가 따로 있고, 신청하기 버튼을 클릭시 구글폼의 신청링크로 신청을 하면 다시 그 신청자에 대한 관리를 노션에 별도로 기입해서 관리를 하던 상황이였습니다.

이를 해결하기 위해 노션의 페이지에 소개 문구를 작성하면, 웹에 반영되고 신청에 필요한 항목을 노션 데이터베이스의 속성으로 넣으면 해당 항목에 맞춰 반영되는 구조를 설계했습니다.

데모 영상을 보면 notion을 배포한 설문조사 페이지에서 설문을 입력하면 바로 notion DB에 반영되는 것을 알 수 있습니다.

2-2) 별도의 어드민 없이 노션으로 수정 및 데이터 관리 가능

[데모 영상]

file.notion.so

https://file.notion.so/f/s/c6cba47f-7c14-4aec-b53e-fddb8c6ca080/최종데모.mp4?id=c87d3c25-9adc-48e1-b8e1-d362aa5f6057&table=block&spaceId=177b29e1-2726-40e0-9cec-f0097d016415&expirationTimestamp=1683619072519&signature=VqOdLTKIwtm_wtHWPfw3BE88wlcr_bKFoegFP4_-aLQ&downloadName=최종데모.mp4

위의 영상에서 보듯이 타이틀이나 소개 문구, 이미지 등을 수정할 경우 바로 반영이 되며, 설문조사 항목을 추가하거나, 삭제하더라도 바로 반영이 됩니다.

이를 통해 노션데이터베이스, 페이지를 통해 비개발자도 충분히 Admin을 활용할 수 있게 서비스를 만들었습니다.

3. 설계

3-1) Notion API 쉽게 사용하기 위한 자체 API 구성

Notion API를 통해서 왠만한 백엔드 작업은 가능하지만 두 가지 문제가 있습니다

1. 노션에서 데이터를 넘겨줄 때 프론트엔드에서 조작하기 어려움
2. 속도가 느리다. 데이터 요청 시 평균 300ms~2000ms까지 걸립니다. 보통은 300ms 안쪽으로 데이터를 받아오지만, 10번에 1번 꼴로 데이터 2000ms까지 가는 경향

우선 1번의 문제먼저 보겠습니다.

아래의 데이터 구조는 Notion API에서 데이터를 넘겨주는 형태입니다.

  "object": "list","results": [{"object": "page","id": "59833787-2cf9-4fdf-8782-e53db20768a5","created_time": "2022-03-01T19:05:00.000Z","last_edited_time": "2022-07-06T20:25:00.000Z","created_by": {"object": "user","id": "ee5f0f84-409a-440f-983a-a5315961c6e4"},"last_edited_by": {"object": "user","id": "0c3e9826-b8f7-4f73-927d-2caaf86f1103"},"cover": {"type": "external","external": {"url": "<https://upload.wikimedia.org/wikipedia/commons/6/62/Tuscankale.jpg>"}},"icon": {"type": "emoji","emoji": "🥬"},"parent": {"type": "database_id","database_id": "d9824bdc-8445-4327-be8b-5b47500af6ce"},"archived": false,"properties": {"Store availability": {"id": "%3AUPp","type": "multi_select","multi_select": [{"id": "t|O@","name": "Gus's Community Market","color": "yellow"},{"id": "{Ml\\\\","name": "Rainbow Grocery","color": "gray"}]},"Food group": {"id": "A%40Hk","type": "select","select": {"id": "5e8e7e8f-432e-4d8a-8166-1821e10225fc","name": "🥬 Vegetable","color": "pink"}},"Price": {"id": "BJXS","type": "number","number": 2.5},"Responsible Person": {"id": "Iowm","type": "people","people": [{"object": "user","id": "cbfe3c6e-71cf-4cd3-b6e7-02f38f371bcc","name": "Cristina Cordova","avatar_url": "<https://lh6.googleusercontent.com/-rapvfCoTq5A/AAAAAAAAAAI/AAAAAAAAAAA/AKF05nDKmmUpkpFvWNBzvu9rnZEy7cbl8Q/photo.jpg>","type": "person","person": {"email": "cristina@makenotion.com"}}]},"Last ordered": {"id": "Jsfb","type": "date","date": {"start": "2022-02-22","end": null,"time_zone": null}},"Cost of next trip": {"id": "WOd%3B","type": "formula","formula": {"type": "number","number": 0}},"Recipes": {"id": "YfIu","type": "relation","relation": [{"id": "90eeeed8-2cdd-4af4-9cc1-3d24aff5f63c"},{"id": "a2da43ee-d43c-4285-8ae2-6d811f12629a"}],"has_more": false},"Description": {"id": "_Tc_","type": "rich_text","rich_text": [{"type": "text","text": {"content": "A dark ","link": null},"annotations": {"bold": false,"italic": false,"strikethrough": false,"underline": false,"code": false,"color": "default"},"plain_text": "A dark ","href": null},{"type": "text","text": {"content": "green","link": null},"annotations": {"bold": false,"italic": false,"strikethrough": false,"underline": false,"code": false,"color": "green"},"plain_text": "green","href": null},{"type": "text","text": {"content": " leafy vegetable","link": null},"annotations": {"bold": false,"italic": false,"strikethrough": false,"underline": false,"code": false,"color": "default"},"plain_text": " leafy vegetable","href": null}]},"In stock": {"id": "%60%5Bq%3F","type": "checkbox","checkbox": true},"Number of meals": {"id": "zag~","type": "rollup","rollup": {"type": "number","number": 2,"function": "count"}},"Photo": {"id": "%7DF_L","type": "url","url": "<https://i.insider.com/612fb23c9ef1e50018f93198?width=1136&format=jpeg>"},"Name": {"id": "title","type": "title","title": [{"type": "text","text": {"content": "Tuscan kale","link": null},"annotations": {"bold": false,"italic": false,"strikethrough": false,"underline": false,"code": false,"color": "default"},"plain_text": "Tuscan kale","href": null}]}},"url": "<https://www.notion.so/Tuscan-kale-598337872cf94fdf8782e53db20768a5>"}],"next_cursor": null,"has_more": false,"type": "page","page": {}
}

그래서 위의 데이터를 아래처럼 정제해주는 작업이 필요했습니다.

따라서 Notion API의 데이터를 정제해주는 BFF API 서버를 만들었습니다.

3-2) 스웨거 문서 제작

아래는 스웨거로 문서화를 해서 팀원들한테 공유한 결과입니다.

아래의 API를 활용하면 위와 같이 더러운 notion api 데이터 구조는 보지 않아도 됩니다..뿌듯! 다만, express를 활용해 BFF 서버를 구축해본 경험이고 문서화도 처음이라 아직 서툰 부분이 굉장히 많았습니다..

3-3) SDK key, DB id만 있으면 데이터 보내기 가능!

위의 구조를 통해서 notion sdk key와 db id만 있으면 설문을 만들 수 있는 구조를 만들었습니다.

프론트에서 query로 해당 값을 받아서 넘겨주는 형태로 설계를 우선 했습니다.

더 안전하고, 좋은 방식은 따로 DB를 만들어서 각 key와 id에 맞는 DB를 계속 누적하는 방식도 검토했으나, 시간이 너무 오래걸리고, 백엔드 작업을 최소화하는 것에 의미가 있었기 때문에 빠르게 데모를 만들기 위해 이렇게 진행이 되었습니다.

3-4) 속도개선 방향

속도 개선을 위한 SSR 도입, 캐싱전략 등을 포함할 수 있겠지만 아직 이 부분까지는 테스트를 해보지 못했으나, 충분히 속도는 개선할 여지가 많다고 생각합니다.

참고할 만한 자료로는 노션 API를 next.js 서버사이드 렌더링을 통해 블로그를 만든 morethanlog라는 프로젝트가 있습니다.

해당 프로젝트로 SSR을 도입하면 어느정도 속도 및 사용성이 개선될 수 있는 지점이 있는 것을 알 수 있었습니다.

morethan-log

welcome to morethan-log!

https://morethan-log.vercel.app/

4. 프론트 작업 트러블 슈팅(속성이름, 속성순서, 이미지업로드)

4-1) property에 따른 객체구조 만들어서 input value로 연결하기

노션은 객체의 key값으로 해당 프로퍼티의 이름을 받기 때문에 이 key값을 기반으로 다시 객체형태로 묶어줘야했습니다.

위와 같이 데이터를 정제해서 넘겨주면 프론트에서는 데이터베이스의 각 속성(property)에 따라서 객체구조를 다시 잡아서 type에 따른 input을 만들어줘야 합니다.

아래와 같이 input을 만들고 해당 input값의 입력값을 받는 객체에 model을 연결해주는 형태로 구조를 만들었습니다.

• 코드 구조

getPreview().then((res) => {
          this.databaseRetrieve = res.datathis.databaseRetrieve.properties.forEach((el) => {
            this.addInputValueObject(el)
          })
          this.finalProperties = res.data.databaseQuery[0].properties
        })

<input class="form_input_wrapper"
        v-if="item.type === 'title' || item.type === 'rich_text' || item.type === 'number'"
        v-model="item.answer"
      />

4-2) 노션의 속성은 순서를 보장하지 않는다.

위 과정에서 어려운 점이 있었는데 바로 노션의 속성은 순서를 보장하지 않는다는 것입니다.선택을 해야했는데, 결국 notion의 데이터베이스에 임의적으로 순서를 적어줘야만 했습니다.

그렇지 않으면 생성된 순서대로 데이터를 읽어와 사용자단에서는 원하는 순서를 보장할 수가 없었습니다.

그래서 -를 기준으로 이름을 다시 구성해서 보여준 형태로 코드를 짰습니다.

4-3) 이미지 업로드를 위한 S3 활용

S3에 이미지를 업로드하고 해당 링크를 notion에 전달해야만 했습니다. 그래서 이미지 업로드는 S3를 활용해 별도의 작업을 진행했습니다.

• 코드 구조

AWS.config.region = this.bucketRegionAWS.config.credentials = new AWS.CognitoIdentityCredentials({
        IdentityPoolId: this.IdentityPoolId
      })
      const s3 = new AWS.S3({
        apiVersion: '2006-03-01',
        params: {
          Bucket: this.albumBucketName
        }
      })
      await s3
        .upload(
          {
            ACL: 'public-read',
            Body: this.file,
            Key: this.file.name
          },
          (error) => {
            if (error) {
              this.errorHandler(error)
              // return alert('There was an error uploading your photo: ', error.message);
            }
          }
        )
        .promise()
        .then((data) => {
          console.log('File uploaded!!!')
          console.log(data)
          this.$parent.changeImageLink(data.Location, this.imageContent)
        })

5. 기대효과

5-1) 여러 서비스로 확장이 가능한 구조

해당 서비스를 통해서 사내에 있는 모든 예약 서비스를 위와 같은 구조로 변경이 가능합니다.

현재 교통, 통역, 유심, 투어버스 등의 신청을 받고 있는데, 이를 위와 같이 관리한다면 작업 효율이 굉장히 증가할 것으로 보입니다. 추후에는 왓츠앱으로 해외 환자들의 문의를 받고 있는데, notion과 왓츠앱을 연동해 문의 내역 등을 자동화하는 것도 가능하다고 생각합니다.

5-2) 누구나 예약페이지를 제작, 배포 가능

하이메디는 환자의 전 과정을 계속 담당하는 컨시어지 서비스가 메인이기 때문에 온라인 서비스를 도입할 때 별도의 관리자(Admin) 페이지가 필수적으로 필요합니다.

그런데 노션을 백엔드로 활용해 예약페이지를 만들어나간다면 사업담당자가 수정 및 문의를 통해 웹페이지의 유지보수가 가능한 구조가 될 수 있습니다.

이런 부분들을 추후 확장한다면 회사차원의 비용절감이 가능하지 않을까 생각했습니다.

6.느낀 점

6-1) 개발자가 된 이유를 다시 생각해보기

개발자가 되고나서 회사에 근무를 시작했지만, 온보딩과 그 간의 과정들이 사실 내가 개발자로 회사에 어떻게 기여하고 있는가에 대한 고민이 많이 들었습니다.

물론 시기적으로도 온보딩은 기술 학습에 포커스를 맞춰 진행되었는데 이는 비즈니스에 기여하기 위해 개발을 시작한 저에게 조금은 힘들기도 했어요

이번 프로젝트를 해보면서 실제 프로덕트로 비즈니스에 기여하면서 배우는 과정이 훨씬 즐겁고 재밌다는 것을 느꼈습니다.

이 작업을 통해 백엔드 작업도 해보고, 타 부서 직원들과 커뮤니케이션하면서 여러 방면으로 기여할 수 있음을 확인했을 때 그 기쁨이 가장 컸어요!

6-2) 시간을 효율적으로 쓰기

혼자서 업무를 잘 진행한다는 것이 참 어렵다는 생각을 하게 되었어요. 가설의 검증부터 프로덕트 설계 개발까지 진행하는 과정이 온전히 나의 몫이 된다는 것은 참 어렵다는 걸 느꼈어요

특정 이슈에 막혀 2일동안 진척시키지 못하고, 삽질을 할 때는 혼자서 잘 끝내고 싶다는 생각에 끙끙 앓으며 진행을 해봤지만 너무 더디게 진행된 적도 있었어요

그럴수록 여러 막힌 지점을 주변 개발자들과 이야기를 하다보니 확 뚤렸던 경험을 했습니다.그래서 결국 시간을 효율적으로 쓰기 위해서는 협업을 해야하는구나. 내가 혼자 책임지는 프로덕트라도, 그럴수록 더 많이 막힌 지점을 공유하고 인사이트를 얻는 것이 혼자 더 잘 일하기 위해 꼭 필요하다는 생각을 하게 되었습니다.