개발하는 일상

한 줄 요약 select 태그를 커스텀하게 만들고 싶다면 div 태그에 tabIndex="0" 속성을 주고, blur 이벤트리스너를 활용해보자 여러 옵션 중 하나를 선택할 수 있게 해주는 HTML 태그가 있다. select 태그인데, 내부 운영용 툴을 만들다가 이 태그를 쓰게 되었다. select 태그를 쓰게 되면 디폴트로 아래 그림1와 같은 디자인이 따라온다. 이 디자인은 css로 바꿀 수 없다는 것이 문제였다. 아무리 내부용 툴이지만 이렇게 만들고 싶진 않아서, div 태그로 직접 select 태그를 구현하기로 했다. 적절한 style과 클릭 이벤트리스너를 달아서 아래 그림2와 같은 태그를 만들었다. div 태그로 select 태그를 흉내내면서 생긴 하나의 문제가 있었다. select 태그는 선택지를..

최근 채널톡을 컨트롤하는 모듈을 만들다가 아주 기발하다고 생각한 아이디어가 있어서 리뷰를 요청했다. 아이디어는 아래 내용과 같다. 채널톡의 문의버튼을 Vue 컴포넌트처럼 사용할 수 있게 만들었다. 원래 채널톡 버튼은 iframe을 삽입하도록 동작한다. 1의 컴포넌트를 상태 관리 라이브러리(Pinia)의 getter에 선언했다. 더 자세한 맥락은 다른 글 "SPA에서 채널톡 사용하기" 에서 작성할 예정. 이 방식이 재밌다고 느껴서 들뜬 마음으로 리뷰를 기다렸다. 그리고 우리팀 인턴이 그날 밤 이런 리뷰를 달아주셨다. 조금 설명을 덧붙이자면 컴포넌트처럼 보이게 하지 않고, 조금 귀찮더라도 채널톡이 제공하는 method를 lifecycle hook에서 직접 호출하는 방식이 어떻겠냐는 의견이었다. 왜 그렇게 생..

같은 주제로 작성한 1부글에는 명확한 문제 인식과 태도에 관련된 이야기가 있습니다. 스타트업 3년차 개발자가 생각한 팀을 신나게하는 리더(PM)의 특징 - 1부 "회사가 재밌어. 월요일이 좋아." 다들 한번쯤은 이런 회사를 꿈꿨으리라 생각한다. 하지만 현실은 그렇지 않은 경우가 더 많은 것 같다. 심지어는 재밌게 일한다는 것은 환상이라며 단정짓는 사 bingbingba.tistory.com 프로덕트에 참여하는 "느낌"을 준다 해결 방법을 기획하는 것이 PM의 일이다. 그렇지만 PM 혼자서 다 기획해버리면 팀을 신나게 할 수 없다. 무슨말일까? 자신이 공을 들여 고민한 문제일수록 해결했을 때의 기쁨도 커진다. 그래서 메이커를 신나게 하려면 문제를 주고 시간을 줘야한다. 던져진 문제를 고민하면서 본인의 문제..

"회사가 재밌어. 월요일이 좋아." 다들 한번쯤은 이런 회사를 꿈꿨으리라 생각한다. 하지만 현실은 그렇지 않은 경우가 더 많은 것 같다. 심지어는 재밌게 일한다는 것은 환상이라며 단정짓는 사람도 있는 것 같다. 신나게 일한다는 건 정말 환상인걸까? 나도 회사 가기가 너무 싫었던 적이 있다. 하지만 분명 밤늦게 일하다 퇴근하면서도 뿌듯하다고 얘기했던 일도 있었다. 지금 회사에서 3년간 다니며 언제 신났는지, 언제 그렇지 않았는지 떠올려보았다. 이 글은 리더에 관한 글인 만큼, 내가 팀원이었을 때 좋았던 리더의 모습을 떠올렸다. 내가 리더일때 겪은 경험 또한 떠올려 작성하였다. 문제를 매우 명확히 이해하고 있다 내가 PM일 때 새로운 상품 구성을 팔기 위해 상세페이지를 만들어야 할 일이 있었다. 디자이너 한..

요약 나는 개발자가 서비스를 잘 이해해야 하고 서비스 개선에 개발자로서 참여할 수 있어야 하고 서비스를 토대로 코드를 설계해야 한다고 생각한다. 이것이 내가 생각하고 해석한 도메인 드리븐 디자인의 개념이다. 서비스 로직대로 코드를 짜고 있긴 했었다 내가 처음 회사에서 서비스를 구현할 당시, 코드에는 아주 느슨한 규칙만 있었던 걸로 기억한다. 으레 초기 스타트업이 그렇듯 빠르게 개발하는 게 우선이었고, 내가 이해한 만큼의 서비스를 ㄱ내가 빠르게 구현할 수 있는 방식으로 코딩하였다. 먼저 누군가 개발해놓은 상태관리 store가 있으면 그냥 import해서 사용하였다. 만약 기존 코드로 해결할 수 없다면 해당 store에 기능을 추가하거나 나만의 store를 만들어냈다. 서비스 로직대로 코드를 짜긴 했으나, ..

요약 장점 코드의 연결이 느슨해진다 유지보수가 쉬워진다 단점 트랜잭션처리에 약하다 코드를 보고 서비스 로직을 파악하는 게 쉽지 않다 어떤 문제가 있었나? 모듈형 구조만으로는 코드의 연결을 충분히 감당할 수 없었다. 우리 서버는 NestJS 기반의 모듈형 구조였다. 유저, 구매, 메세징 등 역할마다 모듈을 만들었다. 알아보기 쉽고 유지보수를 편하게 하기 위해서 모듈은 최대한 서로 연결되지 않도록 하고 싶었다. 하지만 당연하게도 서비스 로직은 그렇지 않은 경우도 많다. "구매를 완료하면 유저 정보가 업데이트되고 알림메세지를 보낸다." 앞서 말한 3가지 모듈이 전부 쓰여야 하는 "구매완료"라는 서비스 로직이다. 처음에는 모듈 멤버 중 다른 모듈에서 꼭 쓰여야 하는 멤버만 export 해서 사용하는 식으로 버텼..