일7 실전! 리팩토링 배경 회사 내부 일정, 개발팀 일정 꼬여서 예상치 못한 공백이 생겼다. 소규모 인력으로 운영하느라 매번 밀려있던 버그를 처리하기로 했다. 우리 서비스를 이용하는 크리에이터는 영상을 업로드 하고 유저가 동작을 따라할 구간을 설정해야 한다. 바로 이 구간 설정 기능을 손봐야 했다. 목표 바뀐 정책을 반영하고, 자잘한 버그를 수정하자 ! (사실 정책은 작업 도중에 확정되긴 했다) 올해 초 이벤트 진행 중에 발생한 버그였다. 유저가 구간 간격을 너무 밭게 설정하면, 순차적으로 이루어져야 하는 서버와의 실시간 소켓 통신이 네트워크 환경에 따라 꼬여버릴 수 있었고, 유저가 서비스를 정상적으로 이용할 수 없었다. 사실 일종의 엣지 케이스여서 흔히 발생하는 경우는 아니었지만 안정성을 위해서는 개선이 필요했다. UI 상.. 2022. 7. 31. [220521] 개발자, 프로덕트(디자인) 팀과 협업 한 회사에서 딱 1년을 채우고 나니까 입이 막 터지네. 매일 하고 싶은 말이 떠오른다. 오늘은 동료 디자이너로부터 고마운 피드백을 받았다. 다음 주부터 본격적으로 개발을 실행할 프로덕트가 있어서 오전에 피그마를 보고 디자인 리뷰를 해서 전달 드렸는데, 그 리뷰를 계기로 피드백을 주신 것 같았다. 나한테 디자인 리뷰를 받으면 아이디어가 정리되고 방향이 선명해져서 도움이 되어 감사하다는 내용이었다. (사실 나도 열심히 숨기려고 하지만 머릿 속은 항상 대혼란이라 피드백을 받고 아주 잠시 몸둘 바를 모르긴 했다.) 사실 회사가 소규모다 보니 디자인 팀에서 개발 팀으로 넘어오는 핸드오프가 엄청 체계적이거나 상세하다고는 할 수 없는데, 그래서 디자인에서 개발로 이어지는 흐름에서 중간 단계를 하나 더 놓을 필요성을 .. 2022. 5. 21. [220520] 문제 해결 문제 해결보다 더 어려운 건 사실 문제를 알아차리고 원인을 정확하게 짚어내는 일인 것 같다. 해결을 찾고 시도하는 하기 위해서는 문제 인식이 선행 되어야 하기 때문이다. 어쩌면 진짜 문제가 뭔지 아는 것 자체가 문제 해결의 일부라고 볼 수도 있겠다. 무언가 잘못 되었다고 '느끼는 것', 이 잘못의 원인이 어디에 있는지 더듬더듬 찾는 것, 뭔가 잡히는 것 같을 때 여러 가설들을 세워서 문제가 제거되는지 확인해보는 것; 1년 차 중반까지만 해도 이런 프로세스를 정확히 이해하지 못했던 것 같다. 지금 생각해보면 1인분의 몫을 하겠다는 강박과 긴장 속에 눈 앞에 놓인 일들을 수행하기 급급했다. 다른 팀에서 오는 요청에 대해 스스로 한번 검토하거나 고민하는 단계 없이 그저 받아서 해치웠다. 그게 내 역할이라고 생.. 2022. 5. 20. [211216] 단상 오늘 여러 수정사항을 업데이트 해서 배포하고 코드리뷰도 받으면서 든 생각. 문제에 대한 해결 방법을 어떻게 찾을 것인지. 효율성 높은 방법을 우선 생각해보지만 최적이라고 할만한 건 없다. 검색도 해본 결과 대충 방법이 몇 가지로 추려지는데 마음에 드는 것도 없음. 이를테면 효율에 큰 차이는 없지만 가독성을 높이거나 라이브러리의 도움을 받거나. 이럴 때는 아예 제3의 방법을 생각해보거나 라이브러리의 원리를 단순하게 이해해서 적용해볼 것. 오늘 옆에서 도움을 받으면서도 스스로 아쉬웠다고 생각한 점이었음. 2021. 12. 16. 우아한형제들 경력 개발자 인터뷰 리뷰 2021 우아한형제들 경력 개발자 인터뷰 #2편 먼저는 풀스택 개발자는 빠르게 프로토타입이 필요하거나 여러 조직이 협업해야 하는 경우가 종종 발생할 때, 어떤 것이 필요한지 즉시 파악할 수 있다는 장점이 있습니다. 인프라부터 백엔드, 프론트엔드까지 각 스택(Stack)에서 필요한 일이 무엇인지, 어떻게 해야 병렬적으로 진행할 수 있게 되는지, 블로커(Blocker)가 무엇인지 등 계획 단계부터 확인이 가능합니다. 단점을 지적받고 고치기를 요구받는 사람은 고민에 빠져 스스로의 행동에도 제약을 만듭니다. 그로 인해 이전보다 장점을 발휘하기 어려워지므로 자신의 장점은 극대화하고, 단점은 동료들과 서로 보완하도록 해야 합니다. 단점 없는 사람 없고, 그런 단점들을 서로 감싸줄 수도 있어야 해요. 학교 다닐 때도.. 2021. 10. 4. 킨더구리 v2 프로젝트 후기 인생 첫 프로젝트였던 킨더구리를 약 한 달에 거쳐 개선했다. 사실상 새로운 프로젝트에 가깝기 때문에 개선이라고 하기에는 어폐가 있다. 프로젝트를 어느 정도 마무리했으므로 작업 과정과 이전 버전과의 차이점을 정리해보려고 한다. 킨더구리 작년 5월 즈음에 경기도 구리 소재의 유치원과 어린이집을 지도로 볼 수 있는 간단한 웹 어플리케이션을 제작하였다. 유저는 이 웹 어플리케이션을 통해 유치원과 어린이집을 각각의 민간, 공립 등의 유형에 따라 검색하고 리스트와 지도로 확인할 수 있다. 리액트로 클라이언트 단을 구성했다. 카카오맵 API를 사용하여 지도 조작을 하였고 경기도에서 제공하는 Open API로 데이터를 가져왔다. 서버 단은 서버라고 하기도 민망한데, 정적 파일을 내보내는 기능이 전부였다. 작년 말에 반.. 2021. 4. 13. 인턴 후기 :: 2021년 2월의 문제들 한 달 가량 일을 했고, 많이 배우고 느꼈다. 잊으면 안 될 것 같아서 기록해놓는다. 기술적인 면 #1 '틀린' 코드. 어떤 문제가 있었고 생각해낸 해결 방식 중 하나는 a 라우트의 A 컴포넌트에서 state와 props를 location.state에 담아 b 라우트의 B 컴포넌트로 이동했다가 다시 a 라우트의 A 컴포넌트로 돌아오는 것이였다. 로컬 개발 환경에서는 이렇게 해서 문제가 해결되었는데 배포를 하니 다시 동일한 문제가 발생하여 이 방법은 폐기시켰다. 이 방법은 사실 로컬에서 작동한다한들 그리 좋은 해결책은 아니였던 것 같다. 우선 다시 처음의 url로 돌아왔을 때 state를 통째로 다시 업데이트 해야했고, 부모 컴포넌트로부터 받는 props의 경우에는 자식 컴포넌트에서 업데이트를 해야했기 때.. 2021. 3. 8. 이전 1 다음
