29CM

29CM

개발팀 리뷰

위 내용은 29CM 전 • 현 재직자의 응답 결과입니다.

기술 스택

기술 스택 정보가 없어요.

재직자가 작성한 글

profile picture

서현직

29CM 그로스기획 리드

🔗 꼭 원온원이어야 하는 이유

얼마 전 INHR 컨퍼런스에서 작년에 출간한 <요즘팀장의 오답노트>에서 소개했던 원온원에 대한 발표를 했는데요. 도움이 되었다는 연락을 많이 받았습니다. 그래서 원온원 활용법에 대한 내용을 간략하게 요약해 보려고 해요. 많은 팀장들이 원온원의 중요성에 대해 의문을 가집니다. 왜 꼭 원온원이어야 하냐는 것이죠. 그래서 저는 원온원에 대한 말 할 때 항상 원온원이 중요한 이유로 이야기를 시작합니다. -- 모두가 알고 있듯 팀장에게 미팅은 매우 중요합니다. 팀장의 본질적인 역할이 ‘혼자’ 무언가를 하는 것보다 ‘여러 사람을 만나’ 문제를 찾고 해결해야 하는 경우가 많기 때문입니다. 팀의 우선순위를 합의하고, 협업 부서와의 갈등을 풀고, 팀원이 더 잘할 수 있는 방법을 찾는 일과 같은 것들이 대표적입니다. 그래서 하루 대부분의 시간을 미팅으로 보낼 때도 많아요. 좋은 미팅이 팀장의 업무 성과를 결정한다고 해도 과언이 아닙니다. 그럼 팀장에게 ‘좋은 미팅’이란 어떤 미팅일까요? 팀장의 역할과 미팅의 목적을 고려하면 아래와 같이 세 가지 기준을 생각해 볼 수 있습니다.      1️⃣ 더 나은 결론 2️⃣ 명확한 행동 3️⃣ 구성원들의 성장 이 세 가지 기준을 충족하기 위해 필요한 미팅의 조건도 있습니다. 미팅에서 더 나은 결론이 나오려면 상대방과 심도 있는 대화가 필요해요. 명확한 행동이 도출되기 위해서는 그만큼 구체적인 설명과 합의가 있어야 하고요. 미팅을 통해 구성원들의 성장까지 이끌어내기 위해서는 서로에 대한 명확한 이해도 필요합니다. 저는 원온원이 이 조건에 가장 부합하는 미팅의 형태라고 믿습니다. 1️⃣ 더 나은 결론 - 심도 있는 대화 2️⃣ 명확한 행동 - 구체적인 합의 3️⃣ 구성원들의 성장 - 서로에 대한 명확한 이해 팀장이 보여줄 수 있는 높은 수준의 관심은 팀원이 진심으로 이루고자 하는 목표를 이해하고, 이를 회사에서 달성할 수 있도록 도와주는 것입니다. 이를 위해 팀원의 목표는 무엇이고, 지금 무슨 일을 어려워하고, 이를 위해 어떤 도움과 지원이 필요한지 이해해야 하는데, 이런 대화를 하기에 원온원만큼 좋은 것이 없었습니다. 팀원의 성장과 성과는 팀원이 원하는 것과 회사가 원하는 것 사이의 교집합에서 가장 빠르게 일어납니다. 성과나 성장은 회사가 원하는 방향으로 일방적으로 일어나는 것이 아니기 때문입니다. 팀장의 역할은 그 교집합의 영역을 파악하고, 그 영역에서 팀원이 이루고자 하는 바를 빠르게 이룰 수 있도록 도와주면서 회사와 개인이 원하는 교집합의 영역을 키워나가는 것이라고 생각해요. 이를 위해 원온원은 두 가지 세션으로 나눠서 진행하는 것이 좋았습니다. 1시간 중 첫 40분은 <워크 세션>입니다. 워크 세션은 파악된 교집합의 영역에서 팀원이 성과를 낼 수 있도록 시의적절한 도움과 지원을 주는 것을 목표로 합니다. 그래서 팀원이 ‘더 좋은 성과를 내기 위해 충분한 지원을 받고 있다’고 생각하면 성공이에요. 두 번째 20분은 <커리어 세션>입니다. 커리어 세션은 회사와 개인의 교집합의 영역을 파악하기 위한 것이에요. 그래서 팀원이 ‘내가 바라는 목표와 되고 싶은 모습이 온전히 받아들여지고 있다’고 생각하면 성공입니다. 원온원이 중요한 이유와 구체적인 원온원의 운영 방식이 궁금하신 분들은 <요즘팀장의 오답노트>를 참고해 주세요. 원온원을 잘 운영하기 위한 템플릿도 필요하시다면 제가 작성한 퍼블리 아티클이 도움이 될 수도 있습니다. 간략한 원온원 운영 원칙 설명과 함께 노션으로 사용할 수 있는 템플릿도 다운로드 받을 수 있으니 참고 부탁 드립니다 :)  교보문고 링크 : https://product.kyobobook.co.kr/detail/S000202757281 퍼블리 링크 : https://publy.co/content/7471?s=qgev1x

profile picture

서현직

29CM 그로스기획 리드

넘어져도 괜찮다는 말

요즘 여섯 살 딸아이가 롤러스케이트를 배우고 있어요. 바퀴 달린 신발을 즐겁게 타는 언니들의 모습을 보고 배우고 싶었나 봅니다. 잔뜩 기대한 딸과 처음으로 롤러스케이트 장에 간 날, 바퀴 달린 신발을 신고 첫 발을 내딛은 딸은 한 걸음도 가지 못하고 넘어졌어요. 첫날 한 걸음도 제대로 걷지 못하는 딸아이가 넘어지는 것이 무서웠어요. 계속 넘어져서 금방 그만두겠다고 할까 봐 걱정이 되기도 했고요. 그래서 딸아이 뒤에 바짝 서서, 겨드랑이 밑에 손을 넣고 넘어질 것 같으면 바로 잡아주며 엉거주춤 뒤따라 걷고 있었습니다. 조금만 넘어지려고 해도 휙 잡아 버리는 제가 불편했는지, 아이가 멈춰 선 후 돌아서서 저에게 이런 말을 했습니다.   “아빠, 넘어져도 괜찮으니까 내가 혼자 한 번 해 볼게요” 그 말을 듣고 아차 싶었어요. 알겠다고 하고 저는 트랙 가장자리로 가서 딸아이가 타는 것을 지켜보았습니다. 아이가 롤러스케이트를 배울 때, 사실 제가 도와줄 수 있는 것은 별로 없더라고요. 트랙에 있는 안전 손잡이를 놓고 걸어 보는 것도, 넘어지는 것도, 그리고 다시 일어나 조금 더 걸어보는 것도 온전히 아이의 몫입니다. 그 시간 동안 제가 할 수 있는 것은 트랙 밖에서 큰 소리로 괜찮냐고 묻고, 또 응원해 주는 것뿐이었어요. 아이에게 롤러스케이트를 가르쳐 주면서 알게 되었습니다. 우리가 흔하게 듣고 또 남에게 해주는 “넘어져도 괜찮다”는 말은, 결국 스스로에게 가장 먼저 해야 하는 말이었어요. https://brunch.co.kr/@zseo/115

재직자가 좋아한 글

퀄리티 높은 REST API 작성하기 🎨  |  이전에 작성한 올바른 API 작성하기에 이어 높은 퀄리티의 API를 작성하는 방법에 관한 아티클을 번역을 통해 가져와 봤습니다 :-) 다음은 API의 품질과 성능을 향상시키는 매우 구체적인 조치와 관행입니다. 1) 복수 명사 사용하기 * 대부분 잘 확립되어 있는 부분이지만 규칙에 따라 잘 사용해야 합니다. * GET/book/{book_id} -> GET/books/{book_id} 2) REST API 경로 세그먼트에 따라 데이터베이스를 모델링하지 않기 * 개발자가 전체 관계형 데이터베이스 모델을 URL 구조로 구축하는 경우가 있습니다. GET /books/{book_id} 은 좋은 예시이고, /authors/{author_id}/books/{book_id} 은 좋지 않은 GET입니다. 책 ID는 전세계적으로 고유하기에 저자 ID가 책에 엑세스하기 위한 URL의 일부가 되면 안 되기 때문입니다. 만약 book_id 가 저자별로 공유한 경우 복합 URL이 적합할 수는 있죠. 3) 배열을 최상위 응답으로 반환하지 않기 * 앤드포인트의 최상위 응답은 배열이 아닌 객체여야 합니다. GET/books returns: {“data”:[{…book1…}], [{…book2…}]} 은 좋은 예시이고 GET /books returns:[{…book1…}] 은 좋지 않은 예시입니다. 배열을 반환하면 이전 버전과 호환되는 출력을 변경하기가 까다로워 권장되지 않습니다. 예를 들어 totalCount 와 같은 페이지 매김 필드를 추가하는 것이 좋습니다. 4) 데이터베이스에 숫자값을 저장하는 경우 객체 식별자는 문자열을 사용하기 * {“id”: “456”} 는 좋은 예시이고, {“id”: 456} 는 좋지 않은 예시입니다. 문자열 ID는 구현 변경에 유연하며, 향후 개발자가 다양한 방식으로 시스템을 조정하는 데에 편리합니다. 5) "NOT Found"를 사용하기 위해 404를 사용하지 않기 * 리소스를 찾을 수 없음을 나타나는 데에 사용해야 하는 HTTP 사양 주장은 중요하나, 개발자는 GET/PUT/DELETE 가 존재하지 않는 ID에 404를 반환하도록 하여 이를 문제 그대로 구현합니다. 그러나 존재하지 않는 ID에 대해 응답은 클라이언트에 2가지를 전달해야 합니다. 1) 서버가 요청을 이해했다. 2) 불행하게도 id를 찾을 수 없다. 404는 다양한 이유로 인해 발생할 수 있기 때문입니다. 6) 구조화된 오류 형식 사용하기 * 유저가 많고, 적절한 오류 형식이 없는 대규모 시스템 상에서는 자세한 오류 형식을 사용해야 합니다. 예를 들어 오류 메시지 - 오류 유형 - 원인과 같이 말이죠. 지금까지 퀄리티 높은 api를 작성하는 원칙에 대해 알아봤습니다. 해당 글에 대한 원본 글은 아래 링크에서 확인할 수 있습니다 ! https://medium.com/stackademic/creating-a-high-quality-rest-api-201819325356

좋아요 72 저장 161

thumbnail