maya

극도의 간결함으로 신뢰성을 추구하는 법 - Site Reliability Engineering (2016)

2021-04-04T22:54:40Z

소프트웨어 시스템은 본질적으로 동적이며 불안정하다. 소프트웨어 시스템은 진공실에 들어있을 때만 완전히 안정적이다. 만일 우리가 기반 코드를 더 이상 변경하지 않는다면 더 이상의 버그도 나타나지 않을 것이다. 기반 하드웨어와 의존하는 라이브러리를 절대 바꾸지 않는다면 이런 컴포넌트들에서도 버그는 나타나지 않을 것이다. 현재 보유한 사용자 층을 더 이상 확대하

자동화는 구글러에게만 해당되는 이야기가 아니다 - Site Reliability Engineering (2016)

2021-04-04T22:54:45Z

구글에서 시행하는 대부분의 자동화는 문제가 많다. 그 이유는 자동화가 핵심 시스템과는 별개로 유지보수되므로, 일종의 불일치, 즉 기반 시스템이 변경되었음에도 불구하고 자동화 시스템은 그에 따라 변경되지 않음으로써 발생하는 문제로 골머리를 앓기 십상이기 때문이다. 그 의도가 무엇이든 간에, 두 시스템의 결합도가 강할수록 우선순위가 애매해지고, 그에 따라 제

추천사 : 쉽지 않은 도전을 정면으로 마주하기 - Site Reliability Engineering (2016)

2021-01-06T03:56:39Z

이 책은 한 회사가 하나의 비전을 가지고 쓴 에세이의 모음이다. 그들이 다뤘던 공통의 주제와 공통의 특성이 각 장에서 반복적으로 언급될 것이다. 그리고 이를 통해 각자 서로 다른 관점을 가지고 있는 상황에서 어떻게 선택했는지, 그리고 얽히고설킨 이해관계를 해결하기 위해 어떻게 협업했는지를 알 수 있게 될 것이다. 이 책의 내용은 강제적인 이론이 아니다.

너무 많은 삽질 업무는 공론화해야 한다 - Site Reliability Engineering (2016)

2019-07-14T01:12:57Z

삽질이 항상 사람들을 피곤하게 하는 것은 아니다. 특히 삽질의 양이 얼마 되지 않는다면 그렇게 문제가 되지는 않을 것이다. 예측이 가능하고 반복되는 작업들은 큰 무리 없이 처리할 수 있다. 이런 업무들을 처리하면 성취감이 있으며, 빠른 시간 내에 처리할 수 있다. 그다지 위험하지도 않고 스트레스도 적은 편이다. 몇몇 사람들은 이런 업무 특성에 이끌려 삽질에

어떤 작업이 삽질로 분류되는가 - Site Reliability Engineering (2016)

2019-07-13T16:18:43Z

우리가 말하는 삽질(toil)이란 단순히 '하고 싶지 않은 일'을 의미하지만은 않는다. 그렇다고 관리를 위한 허드렛일이나 지저분한 일을 의미하는 것도 아니다. 만족과 즐거움을 느낄 수 있는 업무에 대한 선호는 사람마다 모두 다르다. 누군가는 손수 직접 하는 반복적인 작업을 좋아할 수도 있다. 물론 반드시 수행해야 하며 삽질로 분류해서는 안 되는 업무들도 있

이기면 그대로, 지면 바꾸기 - Algorithms to live by the CS

2019-07-12T06:58:50Z

컴퓨터과학에서 탐색과 이용 사이의 긴장은 '다중 슬롯머신 문제'라는 시나리오에서 가장 명확하게 나타난다. 슬롯머신들이 꽉 들어찬 카지노로 들어간다고 상상하자. 슬롯머신마다 승률이 다르게 설정되어 있다. 물론 문제는 승률을 미리 알지 못한다는 데 있다. 게임을 시작하기 전에는 어느 기계가 가장 수지가 맞는지, 어느 기계가 돈을 계속 꼬라박게 만드는지를 전혀

의사결정의 시간 - Algorithms to live by the CS

2019-07-08T07:04:07Z

시간의 흐름이 모든 의사 결정 문제를 '최적 멈춤 문제'로 바꾼다. "최적 멈춤 이론은 해당 행동을 취할 시간을 선택하는 문제에 관한 것이다." 최적 멈춤을 다룬 결정판 교과서라 불리는 책에 적힌 첫 문장이다. 인간 조건을 이보다 더 간결하게 묘사한 말은 찾기 힘들다. 우리는 주식을 사거나 팔기에 알맞은 시점이 언제인지 판단한다. 또 특별한 날을 위해 보

후회를 최소화하는 알고리즘 - Algorithms to live by the CS

2019-07-07T08:56:27Z

"나는 이 일을 시도하면 80세가 되었을 때 후회하지 않으리라는 것을 알았죠. 내가 진정으로 엄청난 무언가가 될 거라고 생각했기 때문입니다. '인터넷'이라는 이 아이템에 참여하려 했던 시도를 후회하지 않을 것이라고요. 심지어 실패해도 후회하지 않으리라는 것을 알았어요. 시도하지 않으면 후회할지도 모른다는 것도 알았고요. 그랬다가는 매일 후회하며 살아가리라는

[스크랩] 라이엇게임즈가 고민하는 '조직화된 경험' - 랭크 게임 이상의 경쟁에 대한 단상

2019-06-30T17:15:57Z

오늘은 랭크 게임과 프로 경기 사이의 수준에 있는, 아직 제대로 이루어지지 못하고 있는 경쟁에 대해 말씀드리고 싶습니다. 우리 대부분은 스테이플스센터나, 메르세데스-벤츠 아레나나 상암 경기장에서 경기를 할 만큼 게임을 잘하지는 못합니다. 하지만 그렇다고 해서 심장이 요동치고 아드레날린이 솟구치는 팀 플레이를 할 수 없다는 의미는 아니죠. 프로 경기만

나 자신과 내가 만든 틀을 들여다보세요 - [RiotGames] 플레이어 행동, 버그 등에 대하여

2019-06-30T04:11:14Z

리그 오브 레전드를 더 잘하려면 어떻게 해야 하나요? 실패는 성공의 어머니 이 말 귀가 따갑도록 들어보셨겠지만 부정할 수 없는 진리이기도 하죠. 지금 브론즈라면 이제 겨우 시작한 것 아닌가요? 오래 플레이한 경우라면 사실 실력 향상을 진지하게 고민해 본건 얼마 되지 않았을 겁니다.실력이 어느 정도이든 새 챔피언을 처음 플레이할 땐 처참하게 당하게 마련이

좋은 개발자, 좋은 기획자 - Signs that you're a good programmer

2019-05-19T15:58:04Z

코드와 설계로부터 감정을 분리한다. 문제를 다른 사람에게 전하기 전에 먼저 시도하고 작동하는지 확인한다. 유용할 때 사용하고, 더 이상 사용하지 않으면 기꺼이 버린다. 명세를 글자 그대로 받아들이지 않고 누가 작성했고 뭘 생각했는지 찾으려 노력한다. 프로그램을 매일 사용할 사람들을 쫓아다니며 이야기를 나눈다. 자신의 도구나 라이브러리를 직접 만든다. 출처

아키텍처와 의존성 질문 6가지 - Why should I care about an architecture?

2018-10-05T02:43:51Z

왜 이렇게나 많은 프로그래밍 언어와 프레임워크가 있는거지? 누구에게 고수준 프로그래밍 언어가 필요하지? 기계는 저수준 어셈블리 보다 고수준 언어를 선호하나? 당신의 프로젝트에서 정말 작은 수정인데 두려움을 가졌던 적이 있는가? 당신이 작성한 시간이 좀 지난 코드를 다시 이해하기위해 얼마나 많은 시간을 소비했는가? 새로운 동료에게 당신의 프로젝트의 아키텍쳐를

툴(Tool)과 라이브러리(Library)의 함정 - 인터랙티브 디벨로퍼

2021-09-02T12:01:43Z

하지 않는 것과 할 수 없는 것에는 큰 차이가 있다. 라이브러리를 사용하는 것이 문제가 되진 않는다. 문제는 라이브러리를 사용해 만들어진 결과물이 자신의 실력이라고 생각하는 경우이다. 그때 본인의 실력에 대해 거짓말을 하게 되는데, Collector가 되기 쉽다. Collector란, 실력을 쌓는 데 시간을 쓰지 않고 라이브러리를 수집하는 데 더 많은

대부분 긴급하지 않다 - Adrenaline Junkies and Template Zombies

2018-08-23T08:16:14Z

고객이 뭔가를 요청하면 즉시 프로젝트를 시작한다. 잠정적인 이익을 따져보지 않는다. 프로젝트 기간은 어이없이 촉박하다. 새 프로젝트는 이미 과도한 업무에 시달리는 영웅에게 더 많은 일거리를 안기므로 우리의 영웅은 더더욱 바빠진다. 이렇듯 조직은 아주 아주 바빠야 한다는 욕심을 끝없이 채워간다. 이런 조직 대다수는 자신들이 기민하다고 믿는다. 확정된 사안이

모두가 언제나 미친 듯이 바쁘다 - Adrenaline Junkies and Template Zombies

2018-06-09T13:51:15Z

*아드레날린 중독증에 걸린 조직이 보이는 특성* 1) 우선순위가 계속 변한다. 2) 어제까지 모든 결과물이 나왔어야 했다. 3) 시간이 언제나 부족하다. 4) 모든 프로젝트가 긴급하다. 5) 긴급한 프로젝트가 계속 쏟아진다. 6) 모두가 언제나 미친 듯이 바쁘다. 이런 문화는 필사적인 급박함을 효율적인 생산성이라 믿는다. 이렇듯 급박함을 장려하는 문화 속

필요 → 수요 - Change by Design

2018-05-31T01:19:42Z

디자이너의 임무는 필요를 수요로 전환시키는 것이다 - Peter Ferdinand Drucker

"내가 그렇게 말하지 않았습니까" - User Stories Applied

2020-06-19T20:22:19Z

사용자 스토리를 전형적인 요구사항 문서 형식처럼 번호를 부여하여 다음과 같이 만들 필요는 없다. 4.6) 사용자는 검색 조건과 일치하는 채용 정보를 볼 수 있다. 4.6.1) 사용자는 채용 정보에서 설명을 볼 수 있다. 4.6.2) 사용자는 채용 정보에서 급여 수준을 볼 수 있다. 4.6.3) 사용자는 채용 정보에서 위치를 볼 수 있다. 이러한 모든 세

프로젝트를 실패하는 방법 - User Story Applied

2023-01-06T03:07:42Z

프로젝트가 성공하기 위해서는 다양한 정보가 필요하다. 일부는 고객, 사용자, 때로는 분석가, 해당 분야 전문가, 소프트웨어를 사업적, 조직적 시각에서 바라보는 사람들이며, 그 반대편은 기술팀이다. 만일 어느 한쪽이 의사소통에서 우위를 차지한다면 프로젝트는 실패하게 된다. 비즈니스 쪽 사람들이 우위를 차지하게 되면, 그들은 기능과 마감시한을 동시에 요구할

사람와 과업의 결합 - Netflix 채용 페이지를 보다가...

2018-08-23T08:46:48Z

A great workplace combines exceptional colleagues and hard problems. 훌륭한 직장은 뛰어난 동료와 어려운 문제를 결합합니다.

이유도 목적도 없이 90%가 죽는다

2017-12-05T03:29:16Z

[매일경제 디지털영상국 기획·그래픽_안희은]