인생이란
2022년 5월 회고
2022년 5월 회고
2022.06.024월 다짐 돌아보기 👍 블로그 글 주기적으로 읽기 배운 것 리마인드 다짐 복기 👍 아침 공부시간 알차게 쓰기 하기 싫어서 멍때리면 그 상태 빨리 눈치채고 블로그 포스팅을 하던지 책이라도 읽기 😢 회고 작성을 위해 배운거, 반성할거를 틈틈이 개인 메모장에 작성해두는 습관 들이기 아직 습관이 들지 않았음 5월에 한 거 팀원들을 대상으로 AWS 인프라 구성하기 세미나를 진행함 헤이조이스에서 주최하는 ${} 개발자로 살고 싶은데요 컨퍼런스 참석 후 후기 작성함 쿠팡의 장주란님 : 엔지니어 관점에서 쿠팡의 역사와 성장 구간별 필요했던 선택(아키텍처, 개발 문화의 변화)에 대해 들을 수 있어서 좋았다. 워킹맘의 고민과 이를 어떻게 풀어나가셨는 지도 짧게 들어서 좋았음! 무신사의 조연님 : 넘모 머싯는 분이어따.. ..
2022년 4월 회고
2022년 4월 회고
2022.05.103월과 4월 회고를 몰아서 작성함 😁 공유한 것 팀원들을 대상으로 인프라 세미나 진행 희희! 원래 발표 극혐인데! 넘모 재밌었다! 좋았던 점, 아쉬운 점은 위 포스팅에 함께 정리해둠! 복습하기 많은 인싸이트를 제공해준 함께자라기 책 요약 다시 읽음 2021년 회고 다시 읽고, 그때 다짐 복기 내가.. 이런 다짐을 했었던가..? 대부분 얼추 하고 있는데... 매월 책 한 권 읽겠다고 다짐을 했었다는 걸.. 방금 알았다... 😢 내가 부족한 분야에 대해 매월 책 한 권 읽기 🙂 피드백 주기를 짧게, 월간 회고를 시작하자 → 이번 회고가 첫 시작이다. 참고로 1월은 연말회고로 퉁친다. 🙂 월간 회고에 내가 성취한 것과 아쉬운 점을 작성 🙂 페이스북과 트위터를 시작 → 개발자분들을 팔로우하고 그분들이 하는 말을..
2022년 2월 회고
2022년 2월 회고
2022.02.282021년 연말 회고 때 월간 회고를 시작해서 피드백 주기를 짧게 가지기로 결심했다. 내가 성취한 것을 축하하고 더 개선하기 위해서 보완방법에 대해 생각하는 시간을 갖기 위해서다. 그때의 다짐을 지금(한달 뒤)까지 잘 하고 있는 지 확인해보겠다. 지난 Action 🙂 피드백 주기를 짧게, 월간 회고를 시작하자 → 이번 회고가 첫 시작이다. 참고로 1월은 연말회고로 퉁친다. 🙂 월간 회고에 내가 성취한 것과 아쉬운 점을 작성 🙂 내가 부족한 분야에 대해 매월 책 한 권 읽기 🙂 페이스북과 트위터를 시작 → 개발자분들을 팔로우하고 그분들이 하는 말을 보면서 이런 생각을 하는 사람들이 있구나, 요즘 이분들은 이런 책을 읽는구나를 알 수 있었다! 🙂 습관은 만들되, 불필요한 과정은 생략하자 → 좋아좋아! 영양제..
2021년 회고 (나만의 성장 시스템 가꿔가기)
2021년 회고 (나만의 성장 시스템 가꿔가기)
2022.01.232021년의 변화 👉 개발자로서 성장 19년, 20년도에 공부했던 걸 21년도에 보상받는 느낌이었다. 그 동안 개똥멍청이로 자책하며 공부했는데, 우연찮게 공부했던 것들을 실무에서 활용하면서 신나고 재밌게 일을 할 수 있었다. 근데 이 것과 별개로 회사 일이 너무 바쁘고, 개인적으로 이벤트들이 많아서 자기 계발에 시간을 많이 들이지 못했다. 원래는 회사 일과 나의 성장이 맞물릴 수 있게 하려고 노력했는데, 진짜 이번에는 정신력을 다른 데에 다 써버렸고 지쳐서 나 자체를 성장시키는 일에는 힘을 못썼다. 공부가 적금이라면, 21년도의 나는 과거의 내 적금(공부)을 바탕으로 이자를 받아 먹으며 지냈던 한 해였다. 적금도 별로 하지 않아서 원금이 커지지도 않았는데 이자만 타먹었으니, 21년도의 방탕함은 올해의 내..
코딩보단 개발, 내가 되고 싶은 개발자의 모습
코딩보단 개발, 내가 되고 싶은 개발자의 모습
2021.06.20보통 사람들이 개발자가 하는 일은 주로 코딩(텍스트 창에 영어를 잔뜩 타이핑하는)이라고 생각한다. 그렇기 때문에 코딩을 잘 하는 개발자가 좋은 개발자라고 생각하는 분들도 많다. 나도 처음 개발자로서 월급을 받을 때에는 그렇게 생각했다. 요즘에는 생각이 조금 다르다. 좋은 개발자의 조건 중 코딩이 있는 건 맞지만, 코딩을 잘 한다고 해서 좋은 개발자는 아니라는 생각이 든다. 좋은 개발자가 되기 위해서는 일단, 개발자가 하는 일이 무엇인지 나열해봐야할 것 같다. 개발자에게 코딩이란? 첫 회사(SI)를 다닐 때 참석했던 회의에서 받았던 질문이 아직도 기억에 남는다. "이 화면 개발하는 데에 얼마나 걸렸어요?" 이 질문을 들었을 때 많이 당황했다. 그 질문을 한 고객과 함께 회의에 참여하고 요구사항을 논의한 게..
SI개발자가 스타트업으로 이직한 이유
SI개발자가 스타트업으로 이직한 이유
2021.01.05이 글을 쓰는 이유는 다른 사람들은 나와 같은 선택을 해야할 때 너무 고생하지 않고 결정하길 바라는 마음이다. 오랫동안 SI에서 개발하던 나는 막연하게 스타트업으로 이직을 해보고 싶었다. 기술적으로 성장하고 싶고, 실제로 사람들이 사용하는 서비스를 개발하고 싶었다는 게 첫번째 이유였다. 하지만 그 이유 하나로 이직을 하기에는, 지금 SI 개발자로서 누리고 있는 것들을 포기하는 게 너무 아쉬웠다. 그렇게 몇 달을 고민했지만 사실 어떻게 고민해야하는 지도 몰랐고, 뭘 고민해야하는 지, 누구에게 조언을 구해야 하는 지도 몰랐다. 그냥 인터넷만 뒤적거리면서 남들 생각을 들어보려고 허우적거렸다. 이것도 좋아보이고, 저것도 좋아보이고, 이걸 포기하기도 아쉽고, 저것도 놓치고 싶지 않고... 시간을 허비한 끝에 스타..
2020년 회고
2020년 회고
2021.01.01새해를 맞이했다. 지난 2020년은 나에게 새로움이 가득한 한 해였다.특히 SI에서 스타트업으로 필드(?)를 바꾸면서 많은 변화가 일어났다. 목차 SI에서 스타트업으로 이직 스타트업에서의 나 운동하자! 💪👀💪 2020년 나의 공부방법, 블로그 2021년 새해 목표 (1) SI에서 스타트업으로 이직 이직 결심 "그래, 떠나자!" 이번 해에 나에게 있어 가장 큰 변화는 필드(?)를 변경한 것이다. 자세한 내용은 아래 글에 참고하길 바란다. prohannah.tistory.com/130 SI개발자가 스타트업으로 이직한 이유 SI vs 스타트업을 비교하기 전에... 일단 내가 경험한 SI는 특정 대기업에 엮인 거대한 단일 생태계라서, 내 이야기를 보고 'SI는 다 이렇구나.'라고 일반화하지는 않았으면 좋겠다. ..
스타트업 채용 공고에 속지 말자
스타트업 채용 공고에 속지 말자
2020.11.28좋은 스타트업은 없다. 나와 맞는 회사, 나와 맞지 않는 회사, 그리고 나쁜 회사만 있을 뿐이다. 채용 공고를 보고 솔깃하기 전에 스타트업에 대한 환상을 깨고 있는 그대로 바라보자. 스타트업도 회사다 유니콘처럼 스타트업에 대한 실체없는 전설은 가득하다. 스타트업은 자유롭고, 직원 복지가 좋고, 능력이 뛰어난 자를 우대하고, 직원의 성과를 보상해주고, 수평적인 문화고, 직원들의 역량 향상을 지원하고, 새로운 기술에 항상 도전적이고, 효율적으로 조직을 운영할 거야! 스타트업이라는 단어 대신 회사를 넣어서 잘 생각해보자. 스타트업과 회사는 같은 조직체를 지칭하는 데, 스타트업에 대해서는 긍정적인 일반화가 가득하고, 회사에 대해서는 부정적인(사실적인) 일반화가 가득하다. 아래는 내가 했던 경험과 약간의 상상력을..
팀문화를 위한 작은 발버둥
팀문화를 위한 작은 발버둥
2020.11.14목마른 자가 우물을 판다. 회사의 대부분이 TF팀 형태로 그때 그때 프로젝트 구성원이 매핑된다(?). 서로 공유하는 업무 체계가 없는 상태에서 다양한 사람들과 일을 하다 보니 자연스럽게(?) 팀문화랄게 딱히 없고, 좋은 노하우와 경험이 전파되지 못하는 상황인 것 같다. 드디어 바쁘게 돌아가던 프로젝트에서 숨구멍이 트였고, 같은 업무를 하는 동료들끼리 힘을 모아 여러 시도를 시작했다. 데일리 스탠드업 미팅 아이스 브레이킹 용이기도 하고, 별다른 커뮤니케이션 비용을 들이지 않고 근황이나 업무 현황을 캐치하기 좋다. 삭막한 TF팀에서 한줄기의 빛 . 매일 5분~10분 정도로 진행하기로 했다. 주간 회고 회고를 통해 자체적인 피드백 시스템을 적용했다. (+속풀이) 현 회사에서 구성하는 묘한 TF팀은 각 팀원이 ..
협업을 위한 작은 발버둥
협업을 위한 작은 발버둥
2020.11.11협업 방식의 중요성을 깨달았다 우리 회사의 독특한 조직문화 입사 6 개월 차, 이 회사는 굉장히 독특한 조직 문화가 있다. 그것은 바로 아무런 문화가 없어 보인다는 점이다. 흔히들 체계가 없다고 말하는데, 우리 회사는 disorder나 mess의 의미가 아니라 그냥 없다. undefined에요. 초반에는 어떤 체계를 만들어가던지 회사 차원에서 시도라도 했으면 좋겠다.라고 생각했었는데, 지금은 오히려 깨끗한 상태라서 팀원 레벨에서 이러한 시도를 할 수 있으니 다행이라고 생각한다. 그리고 이번 TF팀의 동료 개발자분들도 적극적으로 참여해주었다 :) 불편했던 협업 과정, 특히 파편화된 커뮤니케이션 채널 우리 회사는 구두, 구글 행아웃(업무용 메신저), 각종 문서를 통해 협업한다. 모든 회사가 이 정도 채널들을..
개발자를 존중하는 회사 (feat. 역할별 책임)
개발자를 존중하는 회사 (feat. 역할별 책임)
2020.10.16흔히들 말한다. "우리는 개발자를 존중합니다. (그러니 오세요.)" 나는 개발자를 존중하는 회사에서 일하고 싶다. 사실 기획자든, PM이든, 디자이너든지 본인의 역할과 그에 따른 책임이 존중되는 회사에서 일하고 싶은 것은 당연하다. 서비스는 다양한 역할의 사람들이 협력을 하며 만들어지는 것이다. 서비스를 만들어가는 과정에서 각 역할은 모든 과정에 참여한다. 단지 각 역할의 책임이 다르기 때문에 서비스를 만들어가는 단계에 따라 역할별 중요성이 크고 작다는 차이가 있을 뿐이다. 각 역할을 존중한다는 것은 각자의 책임을 수행하기 위해 주도적으로 의견을 냈을 때, 그것을 긍정적으로 검토하되 그에 대한 사이드 이팩트, 혹은 추가로 고려해야 할 사항에 대해 논의하는 것이라고 생각한다. 즉, 모두 본인의 책임과 다른..
요구사항을 정의할 수 있는 역할이 명확하지 않을 때 (feat. 개발자와 조직문화)
요구사항을 정의할 수 있는 역할이 명확하지 않을 때 (feat. 개발자와 조직문화)
2020.10.14특정 기능에 대해 기획자와 PM의 의견이 달라요 최근에 있었던 일을 통해 조직 내에서 특정 책임(기획, PM, 개발)을 수행하는 역할의 구분이 모호할 때, 특히 요구사항 정의하는 기획자의 역할이 모호할 때 생기는 일을 말해보겠다. 일단 각 회사마다 직함이 같더라도 수행하는 업무가 다를 수 있으니, 현 직장에서 내가 바라본 역할과 책임에 대해 정의해보겠다. (현 프로젝트에서는 기획자와 PM을 수행하는 사람이 나누어져 있다.) 기획자 : 사용자의 니즈(건강 관리)를 충족하기 위해 필요한 기능(로그인, 출석체크, 퀴즈 등)을 정의하고, 사용성을 높이기 위해 기능 제공 방식을 요구사항으로서 정의 PM : 프로젝트의 일정과 인력 배분, 구현해야하는 기능의 우선 순위 등 프로젝트 전반을 관리 기획자가 요구사항을 정..