북리뷰11 우리 모두는 브랜딩이 될 수 있다 - [오늘부터 나는 브랜드가 되기로 했다] 책을 읽고 퍼스널 브랜딩에 대한 관심을 이어가기 위해 이 책을 읽었다. 이 책이 퍼스널브랜딩과 관련해서 입문할 수 있도록 도움말을 던져주는 책이지 않을까 싶다. 최근 6주간의 퍼스널 브랜딩 워크숍 수강 후에 개발자로 어떤 방향성을 갖고 살아야 하는지 깊이 이해하고 싶었다. 이 책은 총 4부로 나뉘어 나 자신이라는 작은 스코프에서 시작해 점차 확대해나가는 내용이 담겨있다. 퍼스널브랜딩에 대한 설득을 기업의 브랜드를 인용해서 전달한다. 많은 내용이 유용했지만, 그중에서도 꽤 와닿았던 내용은 다음과 같았다. 1. 나의 브랜드를 찾는 과정은 취향을 찾는 것과 같다. 2. 보여주고 싶은 '나'와 '보이는 나'는 다르다. 3. 우리의 브랜딩은 브랜드와 ING의 결합이다. 이 3가지가 가장 기억에 남았던 부분이고, 이 책은 시.. 2023. 3. 5. 심플한 소프트웨어를 진심으로 고민해본 적이 있나요? - [심플 소프트웨어] 책을 읽고 심플 소프트웨어 책을 읽고, 내가 회사에서 하고 있던 행위가 떠올랐다. 한 때는 아키텍쳐 내에서 강한 의존이라는 버그를 끊어내기 위해 온갖행위를 했다. 과거에 했던 프로젝트 중에 Notification 프로젝트가 기억에 남는다. 이 프로젝트는 유저에게 메세지 채널을 통해 메세지를 전달하는 프로젝트이다. Slack, Email, MMS 등 메세지 채널이 될 수 있는 컴포넌트가 있고, 프로젝트 안에서 MMS 을 받지 못한다면, 카카오톡으로 메세지를 전달하도록 한다. 카카오톡으로 메세지를 읽지 않는다면, 메일로 전달한다. 내결합성에 대해서 고민했었다. Update 가 아니라 Append 만 할 수 있는 코드 만들기 이 책에서 '복잡성은 감옥이다' 부분에서 재밌는 일화를 이야기한다. 이미 퇴사한 사람에게 코드에.. 2023. 3. 1. 성장에 대해서 - [개발자 원칙] 책을 읽고. '개발자 원칙'은 골든레빗에서 출판한 책으로 우리나라에서 유명한 테크리더 9명의 개발자 원칙에 대해서 이야기하고 있다. 이 책을 읽으면서 성장이라는 키워드에 대해서 궁금증이 들었다. 더 나은 개발자로 살아가기 위한 원칙이라는 키워드로 9명의 테크리더는 자신들의 이야기를 한다. 그 과정에 성장이라는 키워드가 포함된다. 서로 다른 관점에서의 9가지 방식의 성장을 책 속에서 찾을 수 있다. 한편으로는, 우리는 어떤 것을 보고 성장했다고 판단하는 걸까? 라는 물음표가 생겼다. 자신만의 방법론을 통해서 이루고자 하는 것을 이루는 것. 마이너한 법칙을 만들어 꾸준히 지키는 것. ‘의존 할 수 없는 것에는 의존하지 말아야 한다‘ 라는 원칙으로 개발자 인생을 사는 테크리더, 이직을 통해 자신이 원하는 목적을 달성하는 .. 2023. 1. 31. [언카피어블] 책을 읽고 이 책은 조용히 묵직하게 메시지를 던진다. 느낀바는 2가지다. '문제를 발견하고 끈질기게 해결한다.'와 '안주함'이다. 책에서 '혁신전략쌓기'를 논리적으로 설명하는데, 논리적이지 않는 나에게 혁신전략쌓기는 이런것 같다. 문제가 있고, 그 문제를 풀기 위한 온 신경을 그곳에 집중한다. 어떻게든 수단과 방법을 가리지 않고 해결하려 한다. 그 문제를 해결하고자 하면 또다른 문제를 발견하게 된다. 그러다 또다시 끈질기게 해결하려고 하다보면 또다른 문제를 발견한다. 이것이 반복적으로 동작됨으로써 아무도 범접할 수 없는 혁신을 만들어 낼 수 있다. 내멋대로 해석해보면, 머릿속에 든 단어는 '존버' 였다. 왜일까? 내가 몸담고 있는 생태계는 가만히 있으면 도태되니까, 내가 해결해야될 문제를 해결하기 위해서는 어떻게든.. 2022. 4. 22. [The Nature of Software Development] 을 읽고나서 🔖 이 책을 읽게된 이유는 트레바리 테크유닛으로 이직을 한 뒤로 풀리지 않던 고민이 하나 있었기 때문이다. 코딩은 코딩이다. 개발은 개발이다. 명시적이고, 부담감이 느껴지지 않는다. 그러나 '개발 업무는 개발 업무이다.' 라고 말하는 것에 스스로 부담감을 느꼈던 적이 더러 있었다. 그 이유는 간단했다. '한 가지 개발 업무를 빨리 처리한다.' 라는 개념으로 다가가기에는 기민하게 움직여야 하는 트레바리 테크유닛에서는 쉽게 적용될수 있는 것이 아니기 때문이다. '이 일정까지 동작하는 소프트웨어를 보여주세요.' 라고 말한다. 적당히 일을 쪼갰고, 그 일을 하면 된다. 그런데 문제가 있다. 이 일정까지 동작하는 코드를 단순히 동작되게만 하면 되는걸까? 아니다. 일정한 속도로 테스트 할 수 있는 환경과 기반 그리고 .. 2022. 2. 20. [나는 왜 이일을 하는가?]을 읽고나서 🧾 트레바리라는 서비스를 통해 이 책을 읽을 수 있었다는 것은 큰 행복이였다. 사실 몃 년전에 구매를 해놨지만 읽지 않았기 때문이다. 이 책은 단순히 사이먼사이넥이 말하는 골든서클(Why, How, What)의 이론을 증명하기 위한 내용만 포함되어 있다고 생각하지 않는다. 내가 하고 있는 이 일을 왜 해야되는 걸까? 라는 질문에 대해서 여러 방향의 정답 찾기 를 도와주는 책이라 생각한다. 현 트레바리 CTO인 완수형과 대화하던 중 이런 얘기를 했었다. "형이 생각하기에 아마추어와 프로의 차이가 무엇인것 같은가? 주니어 개발자와 시니어 개발자의 차이는 무엇인거 같은가?" 라는 질문을 했던 적이 있었다. 이 때 완수형이 말한 얘기중에 인상깊었던 것은 이 부분이였다. "자신의 가치관을 중심으로 코드를 작성했는가?.. 2022. 1. 31. 놈이 기다리네요. 끈덕이게. - '아이디어 불패의 법칙' 놈이 기다리네요. 끈덕이게. 틀림없이 금세 먹잇감을 찾아낼 겁니다. 늘 그래왔으니까. 저 이빨을, 저 촉수를 누구도 벗어나지 못합니다. 이렇든 저렇든 실패라는 야수가 우리 모두를 덮칠 겁니다. 제대로 만들기 전에, '될 놈'을 만들어라 트레바리 스타텁-시리즈A 3번째 모임의 책으로 읽게 되었다. 마치, 학교에서 주최하는 특강 세미나에 앉아 "너희가 만약 사업을 해야 한다면?" 이라는 주제의 강의를 듣고온 것같은 착각이 드는 책이였다. 이 책에서 말하고자 하는 것은 글의 마지막 부분에 요약본으로 남기며, 이 책을 읽으며 흥미로웠던 점에 대해서 먼저 적어보려 한다. ✅ 우리가 자주 활용되는 프로토타입과 프리토타입은 무엇이 달랐을까? 연구소에 근무하던 시절 Proof of Concept(PoC)라는 명목하게 .. 2022. 1. 2. 잠시 창업자의 마음으로 - '디커플링' 마지막장의 디커플링 책을 내려놓고, 잠시 지금까지의 책 내용을 되돌아 보며 생각한 첫번째 행위는 잠시 나를 내려놓고 창업자의 마음으로 주변 서비스를 둘러보는 것이였다. 책에서 말하는 디커플링이란, 말 그래도 분리하기, 해체하기, 끊어내기이다. 기존의 기업이 고객에게 제공하는 소비 활동 사이를 끊어내는 것을 말한다. 이런 행위를 통해 특정 시장에 파괴적인 혼란을 불러일으켜 혁신적으로 시장을 장악하는 것을 말한다. 책에서 말하는 디커플링의 5단계는 아래와 같다. 1단계: 타킷 세그먼트의 고객 가치사슬을 파악한다. 2단계: 고객 가치사슬을 재정의한 비즈니스 모델에서 말한 가치 유형로 분류한다. 3단계: 고객 가치 사슬 중 약한 부분을 찾는다. 4단계: 약한 사슬을 분리한다. 5단계: 경쟁기업의 반응을 예측한다.. 2021. 11. 28. [책] 도메인 주도 설계 철저 입문 - 나루세 마사노부 리뷰 아마도 올해 초부터였을까? Slipp 커뮤니티에서 사이드 프로젝트를 하기 위해 지인에서 Join을 부탁했을 때부터 도메인 주도 설계는 끊임없이 나의 꼬리표를 달게 되었습니다. 사이드프로젝트내에서 먼저 도메인 주도 설계론을 창시한 에릭 에반스의 책을 처음 접하게 되었습니다. 이 책을 읽으면서 느꼈던 점은 도메인 주도 설계라는 것은 서비스내에서 정말로 중요한데, 코드로서 이를 표현하는 방법은 무엇이 있을까- 어떻게 해야될까? 라는 고민이 있었습니다. 이 책을 어느 정도 읽었을 쯤, 그 다음 책으로 반 버논의 '도메인 주도 설계 구현' 를 읽기 시작했습니다. 제가 필요로 했던 드디어 코드로서 도메인 주도 설계를 설명해주면서 개념 하나하나를 이해해 나갔습니다. 그러나, 읽으면서도 정말 포기하고싶다는 생각을 10.. 2020. 10. 29. 함수형 사고 - [5] 진화하라. "100개의 함수를 하나의 자료구조에 적용하는 것이 10개의 함수를 10개의 자료구조를 적용하는 것보다 낫다." - 앨런 펄리스 객체지향적인 명령형 프로그래밍 언어에서 재사용의 단위는 클래스와 그것들이 주고받는 메시지이다. 이것들은 클래스도표로 표시된다. 1. 적은 수의 자료구조, 많은 연산자 - 복잡한 자료구조를 직접 만들어야 하는 객체지향에 비해, 함수형은 주요 자료구조(map, set, list)와 거기에 따른 최적화된 연산들을 선호. - 그래서 XML을 파싱 할 때도, 함수형프로그래밍은 자료구조를 따로 만들 필요가 없다. - 스칼라에서 크롤링하는 코드를 보면 신기할 따름 -PlayJson ) 2. 문제를 향하여 언어를 구부리기 대부분의 개발자들은 복잡한 비지니스 문제를 자바와 같은 언어로 번역하는.. 2019. 7. 26. 함수형 사고 - [4] 열심히보다는 현명하게 패러다임을 바꾸면 더 적은 노력으로 더 많은 일을 할 수 있는 득을 보게 된다. 함수형 프로그래밍에서 나타나는 많은 구조들이 그렇다. 흔히 볼 수 있는 문제들을 구현할 때 짜증나던 것들을 제거해준다. 이 장에서는 메모이제이션과 게으름 설명을 보자. 4.1 메모이제이션 메모이제이션은 다음과같은 상황에서 유용하다. 시간이 많이 걸리는 연산을 반복적으로 사용해야 한다는 가정 주어진 매개변수를 사용하여 연산을 할 때마다 그값을 매개변수를 키 값으로 하는 캐시에 저장한다. 후에 이 함수가 같은 매개변수로 호출되면 다시 연산하는 대신에 캐시의 값을 리턴한다. 함수 캐싱은 전형적인 컴퓨터과학의 트레이드오프이다. 이 방법은 좋은 성능을 위해서 메모리를 더 많이 사용한다. 캐싱 방법이 제대로 작동하려면 함수가 순수해야 .. 2019. 7. 26. 이전 1 다음
