스타트업/개발팀38 좋은 개발자, 어떻게 구할까? 불을 끄러 다니다보니, "좋은 개발자"라는 말을 믿지 않게 되었다. 그런 개발자는 없다. 천재 개발자, 훌륭한 개발자 많이 만나봤지만, "좋은 개발자"와는 멀었다. 나에게 "좋은 개발자"란, "함께 일을 해봐서 좋은 개발자라고 남에게 소개할 수 있는 사람." 그런 사람들이다. 아무리 좋다고 추천받은 개발자도 내가 직접 겪어보기전까진 판단하지 않는다. 내가 판단하는 좋은 개발자 이런 사람이다. (1) 일을 믿고 맡길만한 개발자. (2) 일처리를 똑부러지게 해주는 개발자. (3) 꼭 결과를 내어주는 개발자. 일을 믿고 맡긴다는 건 이런 의미다. - 결과를 내기 위해 행동한다. - 행동하기 위해 선택한다. - 선택하기 위해 자신만의 기준, 행동방침이 있다. - 자기 기준을 가질 정도로 경험이 있다. - (기준.. 2020. 11. 22. 개발자들은 왜 Slack 을 쓸까? "카카오톡 쓰면 안되나요?" "디스코드 쓰면 안되나요?" 정답은 이렇다. "안돼요 !!!" 좀 이상하다. 개발자들은 왜 꼭 Slack 을 써야 할까? 채팅이라면 카카오톡이 더 편하다. 초대하기가 더 쉽기 때문. 게이머들한텐 "디스코드"가 더 인기다. 음성채팅도 되고 모양도 슬랙이랑 똑같이 생겼으니까. 그런데 왜 꼭 "Slack"을 쓰라고 할까? 이유가 있다. 딱 이 시나리오 때문에 그렇다. 스타트업에서 웹 개발자, 단말개발자, 백엔드개발자 3명이 모여서 서비스를 만든다. 런칭을 하고 나니 모니터링을 해야 한다. 접속자 통계도 확인해야 한다. 시스템이 다운되면 모두에게 "비상알람"이 가도록 해야 한다. 음, "관리자 페이지"를 만들어야겠군. 그런데 업무량이 만만치 않다. 서버도 분리해야 하고, DB도 분리.. 2020. 10. 4. 채용팁 : 갑과 을의 차이점 7가지 갑, 을 계약서를 만들어봤다면 알겠지만, 아닌 경우라면 잘 모른다. 보통 계약서에서는 이렇게 쓴다. 일을 의뢰하고 돈을 주는 사람을 "갑" 노동력을 제공하고 돈을 받는 사람 "을" 정확하진 않지만 개인적으로는 일제강점기부터 그러지 않았을까 싶다. 영어권에서는 A, B라고 쓴다. 변질 그냥 돈주는 사람을 "갑", 노동력 판매자를 "을"이라고 한다. 여기에 초극강 자본주의적 세계관이 들어간다. "돈 주는 사람이 왕이다." 그래서 "갑"은 명령하고, "을"은 따른다. 현대판 노비제도처럼 인식된다. 미디어는 자극적인 소개가 필요하니까, "명령하고, 따른다는 행동"에만 초점을 맞춘다. 하지만, Why를 따지기 시작하면 관계가 쉽지 않다. 돈이란 게 영원하지 않기 때문이다. 갑과 을의 차이점 제목이 다소 자극적이긴.. 2020. 7. 8. 개발자들이 코드리뷰를 하는 이유 이 글은 "코드리뷰"가 뭔지 처음 들어보는 학생들을 위한 글이다. 또는 그런 걸 전혀 모르는 CEO를 위한 글이다. "코드 살펴보기" 단순히 그렇게만 생각하지 말고, 조금 더 세련되게 이해해보자. 1. 그 : “코드리뷰 해야 한대.” 나 : “???” 그 :“그걸 해야 한대.” 나 :“???” 갑자기 코드리뷰 회의가 잡혔다. 회의실에 프로젝트를 쏘면서 모든 개발팀이 모여서 코드를 보며 회의를 한다. 괜히 누군가 한마디 던진다. A : “저거 저렇게 하면 안되고 ….” B : “아, 저건 이런저런 이유로 저렇게 만든거구…” A : “그래도 저건 저렇게 하면 안되구…” B : "..." 암튼 그랬다. 월급주는 경영진이 시킨 일이니까. 뭐 돈 드는 것도 아니니까 해보기로 했다. 그렇게 “코드리뷰”란 걸 처음으.. 2020. 6. 21. 스타트업, SI개발자를 채용해도 될까? SI 하다가 "스타트업”으로 가는 개발자. 그런 사람을 채용해야 하는 CEO를 위한 글이다. 성공한 경험도 있고, 실패한 경험도 있다. 원인과 결과는 매우 닮아 있었다. 실패도 재현가능하고 성공도 재현가능하다. 미리 알면 피해갈 수 있다는 뜻이다. 사례 하나에 불과하겠지만, 도움이 되면 좋겠다. 서비스 만들기 인프라부터 서비스까지 만들어야 했다. 서비스를 운영해서 돈까지 벌어야 했다. “User”를 모으고 Activity 를 만들어내야 했다. 맨땅에서 시작하다보니 경험있는 친구들이 필요했다. 흔한 사업이 아니다보니 경험 가진 친구를 구하기 힘들었다. 일부라도 해봤던 친구들을 구해야 했다. SI 분야 밖에 없었다. 다행히 모두 좋은 친구들이었다. 태도까지 굉장히 훌륭했다. 빠른 성과와 목표달성에 아주 잘 .. 2020. 6. 20. 개발자 채용. 적재적소 원칙은 처음부터 고려하자. 미생 "애는 쓰되 자연스럽고, 열정적인데 무리가 없어. 어린 친구가 취해있지 않더라구요." 미생에서 오차장이 "장그래"를 소개하는 말이다. 칭찬하는 말이기도 하다. 솔직히 이런 친구 만나면 탐이 난다. 한 번 가르쳐보고 싶고, 오래 두고 사귀어보고 싶다. 젊은 친구든 아니든 관계없이 말이다. 현실은 어떨까? 그렇다면, 현실은 어떨까? 현실은 이렇다. "애를 쓰는데 부자연스럽고, 열정적이지만 무리한다." 그래서 항상 부담스럽고 시끄럽다. 서로의 마음이 다치고 크고 작은 소란들이 일어난다. 갈등중재를 위해 많은 시간이 투입되고, 집중해야 할 때를 놓쳐버리게 된다. 그런데, 취해있다는 것. 그건 무슨 뜻일까? 30대 30대 땐 자신을 증명하려고 애를 쓴다. 조직에 인정받으려고 애를 쓴다. 조금만 칭찬을 받아도.. 2020. 3. 16. 시스템 안정화와 개발자 채용에 대한 고민 시장을 돌아다니면서 "자주 관찰되는 현상"이다. 안 그런 기업도 있지만, 그런 기업들도 아주 많다. 옳고 그름을 가리려는게 아니라, 현상을 기록하기 위해 정리한다. 01.시스템의 딜레마 Dilemma of System 법칙1 : "모든 시스템은 시간이 지날수록 더러워진다." 개발자는 시스템을 깨끗하게 유지하려고 한다. 당연하다. 깨끗한 시스템이 문제파악하기도 좋고, 장애처리하기에도 빠르다. 물론 이럴 때도 있다. "더 이상 안됩니다. 이건 완전히 갈아엎어야 해요." "이건 이제 수명을 다했어요." 음, CEO는 고민이 된다. 새로 만들것인가, 고쳐서 쓸 것인가? 새로 만들면 돈이 많이 들것 같고, 고쳐서 쓰면 돈이 적게 들것 같다. 그런데 궁금하다. 시스템을 새로 만들면 진짜 괜찮은걸까? 돈이 한두푼 들.. 2020. 2. 27. 소프트웨어 개발자의 딜레마 시장을 돌아다니면서 자주 보게 되는 현상이다. 현상을 기록하기 위해 정리한다. "개발자의 딜레마" Dilemma of Software Developer 법칙 : "대부분의 개발자는 의사결정권자에게 시스템의 문제를 이해시키는 데 실패한다." * 의사결정권자 Stakeholder = CEO, 담당이사 등 대부분의 개발자는 자신이 처한 문제를 보고하기 위해, 그 문제가 회사의 큰 부담이 될거라고 예상하기 때문에, 또는 미래에 새로운 문제가 될 거라고 믿기 때문에 경영진에게 매우 심각하다고 보고하려한다. 그러나 그 심각성에도 불구하고, 보고는 매우 자주 실패하고 만다. 오히려 상황이 악화되기도 한다. 그래서, 개발자는 문제가 생겼을 때 보고할 것인가 말것인가를 놓고 고민하게 된다. 관찰되는 현상 개발자는 의견을.. 2020. 2. 25. 개발자들이 맥북을 쓰는 이유 개발자들은 왜 맥북을 쓸까? 예뻐서.... 그 이유는 빼고. 1. 서버개발자 윈도우는 Unix 서버 개발을 하기에 완전 빵점이다. 환경변수, 커맨드라인의 명령어, 모든 게 다르다. 미리 연습해 볼 수가 없다. 별거 아닌 것 같은데, 복잡한 서버 작업을 많이 하다보면, 이런 사소한 작업이 크리티컬한 장애로 이어진다. 경험상 99% 확률로 발생한다. 그래서 돈많은 기업은 상용장비랑 똑같은 예비환경을 만든다. 1~2억짜리 Staging 장비환경을 구축한다. 그냥 Unix 노트북 사주면 될 일을... 쩝. 물론 완벽히 해결되진 않는다. 환경이 다르기 때문에 서버 반영 전후에 꼭 점검작업을 해야 한다. 그런데 Unix 기반 PC가 있을까? 있다. 그게 MacOS 다. 엇, 그럼 Linux 는? Linux 는 mi.. 2020. 2. 10. 이전 1 2 3 4 5 다음 반응형
