아키텍처적인 판단과 비기능적인 요소, 품질요소에 대한 것을 기준으로 우선순위를 결정하는 것은 차라리 간단하다. 아리송하고 판단하기 어려운 것은 따로 있다. 서비스를 어떤 기능이나 어떤 서비스, 어떤 영역을 먼저 시작해야 하는 가?. 아니면, 서비스가 개시되고 돌아오는 버그 리스트와 추가 요구사항 등의 사용자의 피드백을 통해서 유지보수의 순서를 정하는 것 등이 아리송한 것이다.이번에 중점적으로 이야기하는 것은 개발자들에게 요구되는 요구사항과 업무의 작업 단위들은 왜 이렇게 많이 변화하고, 이러한 요동치는 환경들은 무엇 때문에 발생하는 것인지에 대해서 생각해본다.대부분의 소프트웨어 개발자들은 시시각각 변화하는 요구사항과 유지보수 업무의 홍수 속에서 점점 무덤덤해지면서, 자신들이 할 수 있는 일만을 하려고 하는 경향으로 변화해 간다. 그렇게 변화하면서 개발 조직 내에서 무력감에 빠져드는 현상을 맞이 한다. 그 모든 이유의 대부분은 최고 경영자나 경영진, 리더층의 결정장애이거나 판단 미스인 것이 대부분이다.슬프게도 최고 경영진에게는 소프트웨어 개발팀에서 업무를 제대로 처리해주지 않는다는 영업과 기획 조직들의 푸념이 늘어나는 이유는 소프트웨어 개발팀에서는 제대로 된 요구사항의 정의가 되지 않았고, 작업의 우선순위가 불분명하기 때문에 이런 기술적 판단 미스와 잘못된 기술 부채가 누적되어지기 때문이다.기술적 부채에 대해서는 다음에 이야기하고, 이번 이야기에서는 '작업'의 우선순위를 결정하는 부분에 대해서만 이야기해보자.우선순위를 결정하는 기준이 없거나, 기준에 대해서 의사소통이 안 되는 경우가 발생할 수 있다. 그리고, 대부분의 스타트업들은 이런 현상을 맞이한다. 물론, SI현장에서는 너무도 비일비재하게 반복되는 경우가 많기 때문에 이런 현상은 지금 이 순간에도 반복되고 있다.도대체 왜 이런 상황을 만들었는가? 그리고, 누가 이렇게 만들었는가? 분명, 스타트업 초기에는 의기투합했던 CEO와 기술 총 책임자가, 어느 정도 기업이 성장하고 나니, 업무의 우선순위와 요구사항의 폭주 속에서 서로 일기토를 벌이는 대립된 상황이 되어버린 것은 무엇 때문일까? 도대체 이렇게 개발업무가 뒤죽박죽 되어버린 것은 누구의 책임인가?아키텍처가 부재하고, 아키텍트 역할을 담당하는 사람이 없는 경우에는 이런 현상은 매우 당연하다. 오히려, 발생되고 있는 것을 모른다면 그것은 더 위험하다. 개발자나 담당자가 현상을 숨길 가능성도 매우 크다. 언제나 개발 리소스는 부족한 것이 정상이다.개발 일정은 촉박하고 만들어야 할 것은 많으며, 버그는 언제나 발생한다. 이런 사항들을 어떻게 처리하는 것이 가장 합당한 것인가에 대해서 삐딱한 아키텍트의 시선으로 몇 가지 정의하여 보자.한편으로는 이러한 상황은 매우 당연한 것이다. 소프트웨어 개발을 할 때에 수많은 업무들이 밀려온다. 또한, 요구사항들은 급변하고 시장 또한 급속도로 변화를 일으키는 것을 간과해서는 안된다.‘냉정하게 ‘경영진’이나 ‘개발 총 책임자’의 능력이 부실해서 그런 경우가 태반이다.‘라고 필자는 이야기하고 싶다. 그런 상황을 피하게 해야 하고, 그런 문제를 해결하기 위해서 최선을 다해야 하는 것이 그들이 해야 할 일이다. 그래서, 고액 연봉을 받는다. 그러니, 이런 문제는 그들이 해결해야 한다.결론은 그러하지만, 그런 상황을 좀 더 세밀하게 분석해보자.보통 이러한 일이 발생하는 경우의 가장 대표적인 문제는 경영진의 ‘경영 목표’가 불분명하고, ‘프로젝트의 골’에 대해서 가치의 설정을 제대로 못하고, 이에 대해서 조직원들에게 의사전달이 불분명할 때에 이런 상황들이 대부분 발생한다. 그리고, 결과는 불을 보듯 뻔하게 된다. ( 의사소통이 안되었다고 판단하기도 하지만, 대부분 일방통행으로 전달되어지는 지시사항들이 대부분이므로, 의사소통의 문제는 아니다. 그러니, 개발자나 기획자, 디자이너의 책임이 아니다. 그냥, 지시가 잘못된 거다. )물론, 전통적인 제조업체와 전통적인 관료조직에서는 이러한 문제를 해결하는 다양한 방법들이 연구되었고, 차근차근 일을 풀어나가는 방법에 대해서도 많은 해결책과 솔루션들이 등장한다. 하지만, ‘지적 생산’을 주 업무로 하고 있는 소프트웨어 개발에 있어서는 이러한 방법들은 정말 바보스러운 프로세스를 만들 뿐이고, 인원이 비대해지며, 불필요한 회의와 불합리한 결정들이 도배되는 경우가 많은 관료조직을 비대하게 만드는 경우가 많다. 이런 문제를 해결하겠다고, 조직의 구성 방법이나 조직을 관료화하고, Tree구조로 만드는 바보 같은 짓을 필자도 그런 실수를 반복했었다. (ㅡ.ㅡ;)스타트업으로 빠르게 시작한 기업이 어느 정도 매출을 일으키거나, 서비스가 완성되어 갈 때에, 대규모 인원을 확충하면서 발생되는 문제들은 아이러니하게도 대부분 비슷하다. 그 문제의 핵심중의 핵심은 그 ‘문제’ 들을 어떻게 나열하느냐이다.그렇다면, 이러한 문제들을 어떻게 명확하게 해야 하는가? 그것을 조금 더 명확하게 개발업무에 있어서 정의한다면. 소프트웨어 개발에 있어서 가장 초보적이고 기본적인 ‘업무의 요구사항’을 제대로 결정하는 것이다. 그리고, 이러한 ‘요구사항’을 어떤 방법으로 중요한 ‘업무의 우선순위’를 잘 결정하는 것이다.이런 ‘우선순위’를 결정하기 위하여 ‘요구사항’을 어떻게 잘 정의하는가가 이 문제를 보다 명확하게 하는 방법의 가장 핵심중의 핵심이 되겠다. 물론, 똑똑한 경영자와 리더가 앞에 나서는 것은 당연한 것이겠이고, 그러한 리더는 ‘요구사항’을 정말 명확하게 정의하고, To-be에 대해서 명쾌하게 정의할 수 있다. To-be가 명확하고, 만들고자 하는 제품과 서비스가 명확하다면 이런 혼란을 발생하지 않을 것이다.하지만, 불분명한 목표와 불분명한 요구사항은 결국, 소프트웨어 개발을 파국으로 만들어 버리는 첫 번째 문제점이다. 훌륭한 리더는 작은 요구사항과 작은 결정사항부터 명확하게 정의한다.소프트웨어 개발 업무의 우선순위를 결정하는 방법물론, 이 내용은 소프트웨어를 중심으로 IT설루션이나 서비스를 개발하는 업체를 대상으로 설명하기는 하지만, 일반적인 기업들도 요즘은 대부분 중요한 의사결정과 지적 프로세스들을 갖추어야 하기 때문에 발생되는 문제들은 대부분 대동소이하다고 하겠다.또한, 경영의 목표에 대한 설정과 과학적인 접근 방법은 경영학적인 관점이기 때문에, 그 부분에 대해서도 이 글에서는 논외로 하자. 보통 조직이나 기업은 제한된 리소스와 자원과 일정을 가지고 최대의 이익과 목표를 도달하기 위한 경영자의 판단에 의해서 결정되어지고 움직여진다. ( 그래서, 사장이 똑똑해야 한다. )대부분의 조직과 회사는 이미, 시작부터 그 결과를 예측할 수 있다고 보는 것이 합당하다. 이처럼, 냉정하게 경영의 목표를 명확하게 하고, 조직의 비전과 한 해의 목표와 프로젝트의 목표에 대해서 얼마나 잘 결정하느냐가 핵심적인 성공요소들이다. 목표가 명확하면, 업무 순위도 명쾌하다.아무리 개발자가 똑똑하다고 해도, 경영진의 삽질을 버텨낼 수 있는 것은 거의 ‘기적’에 가까운 일이기 때문이다. 결정하고 업무의 우선순위를 정의하는 사항들이나 체크리스트에 대한 이야기인 경영진들이 판단해야 하는 내용에 대해서는 필자의 경험( 중견기업의 임원 노릇 )을 바탕으로 다음 기회에 이야기하도록 하겠다. 아마도, 스타트업과 중견기업의 임원으로 일해본 필자가 해줄 수 있는 이야기는 필자 주변에서 물어보듯이 생각보다 많은 듯하며, 브런치를 통해서 자주 언급하고 이야기하도록 하겠다.정말 중요한 소프트웨어 개발 기업에서의 업무의 우선순위는 무엇으로 결정되어지는가? 그것은 대부분의 기업과 대동소이하다. 그것은 ‘기업이 추구해야 할 이익’이다. 그리고, 그 이익을 위해서 어떠한 경영적인 지표와 목표를 설정하느냐에 따라서 결정되어진다.이러한 결정사항이 개발업무의 우선순위에 가장 지대한 영향을 준다. 앞서 이야기했지만 경영지표를 설정하는 것은 이 글에서는 논외이다. 일단, 여기서는 경영의 목표는 명확하다는 전제하에서 매일매일 요구사항에 따르는 업무의 우선순위가 요동치게 되는 상황을 생각해보자. ( 일단, 똑똑한 경영진이 제대로 된 목표 설정을 했다고 본다. )하지만, 그렇게 목표 설정이 되어도, 요구사항과 업무의 우선순위가 요동치는 경우는 똑같이 발생하게 되는 경험을 하게 된다. 도대체, 왜? 이런 현상들이 발생되는 것이고, 왜? 우리는 이러한 변동되는 상황 속에 노출되어 있는 것일까?대부분의 소프트웨어 개발 업무들을 보면, 생각 이상으로 매번 계획에 없던 일은 수시로 발생하고, 발생된 업무들은 아이러니하게도 중요한 업무 리스트로 추가되는 해괴한 현상이 수업이 되풀이된다. 도대체! 왜? 그런 현상이 일어날까?시장의 매우(!) 변화는 당연하다.물론 이러한 상황을 여러 가지 상황으로 해석할 수 있겠지만. 대부분의 이런 식의 업무의 우선순위가 요동치는 이유는 '회사 주변의 변화'가 극심해서 벌어지는 현상 중의 하나일 수 있다. 이러한 경우는 극히 당연하며, 이 요동치는 것을 어떻게 프로세스에 반영하는가가 관건이다. 그래서, 해당 프로세스의 분석과 반영에 집중하면 최고의 프로세스를 얻을 수 있다. 대부분이거나 특히, 일등 경쟁업체가 있고. 그 업체의 행동을 주시해야 하는 팔로워 정책을 사용하는 업체의 경우에는 이런 일은 거의 매번 발생하는 경우이니, 어떻게든 이러한 변화를 탄력적으로 운용할 수 있는 환경을 만드는 것이 중요하다.분명, 더욱더 극심하게 발생하는 것과 소프트웨어 개발과 환경, 조직을 그에 맞추어야 하니까 발생하는 것이다. 냉정하게 해당분야의 1등 기업이 아니고서는 대부분 이러한 현상을 비일비재하게 만나게 된다. ( 보통 기업들은 애플과 같은 선도적인 기업이 아니다. ) 그리고, 이런 요동치는 '변화'에 따라서, 보통은 이러한 변화에 따라서 세부적인 실행방안과 전략, 결과물들이 변동되는 것인 어찌 보면 당연하고 지당한 범위의 변동일 수 있다.당연하게도 이러한 ‘시장의 변화’를 내부 조직원들에게 어떻게 전파하고, 의사소통하는 것이 효과적인 것인가에 대해서 더 많은 투자를 해야 하고, 해당 정보들을 빠르게 전파할 수 있는 방법들을 고안해야 한다.하지만, 시장은 그대로인데? 요구사항은 요동친다?그렇지만, 시장의 변화도 없고, 경쟁기업의 변화도 그다지 없는데도, 부서와 부서원, 개발자와 영업 등에 있어서 주요한 우선순위가 요동치고, 기준점이 없는 상황에서 방황하게 되는 현상은 왜 일어나는 것일까?재미있게도, 대부분의 '우선순위'변동은 이러한 외부요인에 의해서 발생하지 않는다는 점이다. 보통은 이런 '외부요인'에 대한 대응방안과 충격은 대부분의 회사와 조직에서 반응할 수 있도록 대처가 되어있는 편들이다. 그리고, 경영이나 관리조직은 그러한 것들을 탄력적으로 운영할 수 있는 다각도적인 방법들에 대해서 이미 익히 알고 있기 때문에, 대부분은 소프트웨어 개발 조직에 이러한 여파가 가지 않도록 최선을 다한다. (* 만일 이런 상황이 아닌데도 개발 조직에 여파가 전해진다면, 전적으로 관리조직이나 리더십의 문제, 의사소통 등의 문제들이 그대로 드러난 것이다. )정말 대부분의 '우선순위'의 변동은 엉터리 같은 상황에서 발생되는 경우가 생각 이상으로 많다. 그것의 대부분은 납득하기 어려운 모호한 이유와 상사의 변덕, 사내 정치의 비합리적인 결정 등에 따라서 변화되는 경우가 많다.물론, 대한민국의 SI특성상 거지 같은(?) 고객의 불합리한 요청사항 때문에 거지 밥상을 뒤엎듯이 변화하는 것 또한 엄연한 현실이고 사실이다. 하지만, 냉정하게 이러한 현실에 대해서 잘 알고 있으면서 대응을 하지 못한다는 것 또한 분명 능력과 실력의 문제이기도 하다. 분명, 거지 같은(?) 고객과 시장이라면 그에 응당한 대응조직이나 프로세스를 갖추어야 한다. 하다 못해, 술말 마시는 술상 무라도 동원하는 것이 합당하다. 대한민국 공공 SI의 성패는 ‘술자리’에서 결정되는 경우도 많다. (ㅡ.ㅡ;)정말 중요한 것은 이런 상황을 파악하는 것 그 자체가 중요한 것이다. 이처럼 정말 중요한 것은 업무의 요구사항에 대한 본질을 정확하게 파악하는 것이다.분명, 자신의 조직과 회사에서 '소프트웨어 개발업무의 우선순위'는 어떤 식으로 결정되어지며, 어떤 것들이 정말 중요한 업무인지 파악하고 분석하는 것이 가장 핵심적으로 필요하다. 아주 세부적인 우선순위에 대해서는 실제 해당 업무를 분석하고 정의해야 하지만, 일반적으로 이러한 ‘요구사항의 본질’을 정의하는 데 있어서, 최소한 두 가지의 스텝으로 업무를 구분하고, 다음의 4가지 정도의 업무형태는 구분해야 한다고 생각한다.현재 팀에 적합한 소프트웨어 개발업무의 우선순위를 결정하자!그것의 첫 번째 스텝은 정말 필요한 '0순위의 업무'와 '쓸데없고 필요 없는 일'을 구분하는 것이다. 그리고 남은 요구사항과 업무들은 일반적인 업무들이며, 그 업무들은 다음 스태프의 분석과 정의에 따라서 ‘고품질이 요하는 업무’와 ‘적정 품질을 요하는 업무’를 구분하는 것이다.이처럼 0순위 업무, 불필요한 일, 고품질 업무, 적절 품질업무의 4가지 스태프로 구분하여 업무의 우선순위를 정하는 것이 요구사항 분석의 첫 번째 단계이다. 그리고, 그러한 기준과 성격에 대해서 조직원들에게 폭넓은 이해를 구해야 하며, 그 부분에 대해서 공감대를 형성해야 한다. 대부분 기업의 목표와 비전은 그러한 것을 전제로 구성되게 된다. 그렇다면, 이러한 해당 업무의 성격은 어떻게 구분하는지 하나씩 살펴보자. 요구사항들에 대해서 구분이 어렵다면, 필자가 사용하는 방법을 한번 사용해 보라. 아래의 표는 요구사항의 우선순위를 평가하기 위해서 필자가 사용하는 방법이다. 점수를 만들어서 사용하는 것이 가장 간단할 수 있다.표1, 요구사항에 대한 가중치 리스트위의 표를 이용하거나 적절하게 요구사항의 가중치를 조절하여 ‘수치화’하는 것도 일부분 가능하다. 하지만, 이렇게 정량적으로 판단하는 것보다 더욱더 중요한 것은 ‘요구사항’은 ‘정성적’인 판단을 제대로 하는 것이다.0 순의 업무를 찾고 정의하자가장 쉽게 이야기하면. ‘기업의 이익을 가져다주는 확실한 것’이 명확하게 드러난 것을 의미한다. 몇 가지 부연설명을 하자면, 기업이 사활을 걸어야 할 신기술이 들어간 서비스, 매출 증대를 위한 새로운 시장에 진입하는 비즈니스 모델을 갖춘 서비스, 수익모델을 만들고 실현하기 위한 일련의 서비스의 Back-office 작업들, 현재 서비스 중인 소프트웨어의 위기사항을 타개할 해결책을 찾는 것 등이 이러한 '0순위 업무‘에 해당한다.더 명쾌하게 이야기하자면 '업무의 가치'가 명확하고, '업무의 요구의 원천'이 명확하고 정확하게 드러난 요구사항들 중에 '수익'이 명쾌하게 보이는 일이 이에 해당한다. 이러한 '업무'들은 개발 조직뿐만 아니라, 영업이나 기타 조직에서도 발 빠르게 대응하는 것이 가장 중요하다.보통 이러한 일들에 있어, 가장 중요한 것은 '타이밍'이게 된다. 말 그대로, 발생한 시기와 해결되는 시기의 주기가 가장 짧아야 한다. 말 그대로, 고객이 원하는 제품과 서비스를 의미한다. 그래서, 0순위로 진행해야 한다.또한, 이러한 타이밍은 기업에게도 큰 기회를 주지만, 해당 업무를 추진하는 부서와 개인에게도 큰 이익과 인사고과의 결과를 선사하기 때문에 정말로 의미 있고 중요한 업무가 된다. 다만, 이러한 0순위 업무의 구분을 해야 하는 경우에는 해당 조직과 회사에 당연하게도 인사고과나 인사정책 또한 잘 구성되어 있는 경우에만 이러한 우선순위의 결정이 의미가 있다. 또한, 결정되어지는 긴급한 의사결정에 대해서 신속하고 명확한 의사전달과 의사소통이 가능한 집단의 경우에게만 이러한 ‘0순위 업무’에 대한 정의가 가능하다.앞서 이야기한 인사정책이나 의사소통이 불분명한 조직에서는 아무리 ‘고객’이 당장 원하는 ‘서비스’와 ‘제품’이라고 하더라도. 소프트웨어 개발 조직에서는 생뚱맞게 튀어나온 불특정 한 업무로 밖에 받아들이지 않는다.그러한 ‘문화’와 ‘환경’을 갖추고 있지 않는 기업이라면, 이러한 ‘0순위 업무’는 가능한 발생시키지 않는 것이 최선이다. 그리고, 다음의 ‘불필요한 일’을 구분하는 정도로만 진행하는 것이 더 효과적일 수 있다.하지만, 잘 갖추어지고 유연한 소프트웨어 개발 조직에서는 이러한 이벤트적인 최고 결정사항을 발 빠르게 대처할 수 있다. 이러한 일들은 말 그대로, 잘 수행된 이후에 기업도 이익이고 부서도 신바람 나고, 개인도 업무 고과에서 큰 영향을 받을 수 있는 일이므로, 기업에 가장 큰 이익과 긍정적인 효과를 매우 크게 안겨다 주는 업무가 된다.가장 중요한 ‘문화’가 성립되어진 기업과 조직은 어떻게든 이러한 ‘0순위 업무’를 정말 잘 필터링하는 것이 해당 기업의 점진적인 성공과 성패의 최우선적인 결정사항이 될 것이다.보통 이러한 결정은 어느 정도 회사의 서비스와 제품이 성공적으로 시장에 안착한 다음, 시장이 확대되거나 해외 수출 등의 매출이 급속도로 증가하는 시점에서 심각하게 고려해야 할 사항들이다.그렇다면, 이러한 요구사항이나 업무는 어떤 식으로 결정하는 것이 최선일까? 여러 가지 의견이 있지만, 크게 두 가지로 나눌 수 있다. 하나는 대부분 이러한 업무는 특정 체크리스트와 회의에 의해서 결정될 수도 있다는 점. 또 다른 하나는 리더십을 가진 사람이거나 경험이 풍부한 사람이 직감과 경험에 의존하는 것이다.과연 어떤 방법이 효과적일까? 프로세스로 이러한 0순위 업무를 결정할 것인가? 직감과 경험에 의존할 것인가? 두 가지 모든 것을 고려할 것인가에 대해서는, 각 조직과 기업의 성격에 따라서 조금씩 다르다.다만, 정말 중요한 것은 ‘0순위 업무’를 제대로 구분하고, 이를 정하는 일련의 작업들을 수행하고 있는가 하는 점을 먼저 판단하는 것이다. 보통 이런 ‘0순위 업무’들은 너무도 명확하기 때문에 잘 드러나서 경험과 직관으로 결정하는 것이 더 효과적인 경우가 많다. 경험이 풍부한 고급 개발자나 아키텍트와 같은 인력을 보유하는 절대적인 이유이기도 하다.하지만, 문화적인 형성도 힘들고, 고급인력도 없다면, 다음의 ‘쓸데없는 일’을 찾는 것에 중점을 두어보자.현재 상황에서 ‘쓸데없는 일’을 구분하자.대부분의 소프트웨어 개발 조직에서 가장 잘해야 하는 작업은 정말로, '쓸데없고 필요 없는 일'을 구분하는 것이다. 냉정하게 지금 당장 필요 없는 업무, 해도 그다지 성과가 없는 업무, 의미가 부족한 업무 등이 이에 해당된다. 대부분 이러한 업무들의 대부분은 '업무의 가치'가 불명확한 경우와, 누가 만들고 요구한 것인가? 에 대한 요건이 불명확한 경우가 많다.이 두 가지에 해당되는 내용들이라면, 대부분 쓸데없는 일이나 요구사항으로 구분하여 정리하고 처리해야 한다. 물론, 요구사항의 수집이 잘못되었을 수 있지만, 그것은 수집의 문제에 대해서 다시 논하기로 하자. 요구사항 수집 공학과 관련된 이야기도 칼럼 중에 한번 이야기해야 할 내용이다.하여간 이러한 ‘쓸데없는 일’들은 분명, 현재의 작업에 등록되어 있고, 누군가가 하고 있으며, 어떤 지시에 의해서 실제 수행되는 경우가 상당수 존재한다. 이러한 대부분의 일들과 요구사항들을 살펴보면, 현재 등록되어진 대부분의 업무들 중에 10가지 중에 1~2가지 일들은 대부분 타성적으로 흘러 지나가는 경우가 대부분인 경우가 많다. 냉정하게, 현재 등록되어진 요구사항이나 업무에 해당하는 것들의 10~20%는 정말 '쓸데없는 일'들이 많다. ( 지금 당장 업무의 Task를 살펴보면, 이런 쓸데없는 일들을 찾을 수 있다. 왜? 자신도 모르게 버퍼 삼아서 등록해 놓은 업무, 팀장이 버퍼로 등록한 업무까지 정말 많다. )또한, 그 이외에도 대부분이 비즈니스 환경이 변하거나, 업무를 지시한 상사의 변덕 등으로 사라지는 업무들도 이에 해당한다고 볼 수 있다. 이러한 업무들은 해당 이벤트와 상황에 따라서 후순위로 처리되거나 하지 말아야 할 것들에 해당한다. 그렇다면, 이러한 쓸데없는 일들을 어떻게 구분해 내는가? 가장 대표적으로 구분하는 방법은 ‘만들어진 보고서’와 ‘결과물’이 소홀하게 관리되는 경우가 대부분 이에 해당한다고 보면 되겠다.이러한 쓸데없는 일들의 결과들을 살펴보면, 정말 심한 경우 보고서나 결과물에 대해서 보고를 받는 시간 10~20분 정도의 대충하는 경우도 많은 것이 대부분이다. 그리고, 실제로 관료화된 조직에서는 이러한 많은 업무들이 필요 없는 업무들로 구성되어진다.소프트웨어 개발 조직이 관료화된다는 것이 얼마나 비효율적인가 하는 점은 굳이 첨언하지 않아도 대부분의 개발자들이 잘 알고 있을 것이다. 소프트웨어 개발 조직이 관료화되어있다고 생각한다면, 대부분의 '소프트웨어 개발 업무'들은 쓸데없는 일에 30~40%의 일을 소모하고 있는 경우가 대부분이라고 봐도 무방하다.그래서, 이러한 업무들을 구분하는 방법으로는, '업무가 추진되고 나온 결과물'을 검토하는 시간과 결과물에 대한 반응을 살펴본후, 그 반응이 어떻게 내재화되는지에 대해서 검토하여 보면 대부분 알 수 있다.또한, 해당 서비스나 라이브러라, 산출물들이 얼마나 재활용되고 있으며, 효과적으로 반영되고 있는지에 대한 평가도 같이 하면, 이러한 ‘쓸데없는 일’을 찾아낼 수 있다. 대부분 이러한 업무들의 대표적인 것들이 냉정하게 신입사원들 대부분의 업무가 그러하고, 선임 직원들은 관성에 따라서 만들어 내는 업무들이 대부분 이러한 경우가 많다. 또한, 습관적으로 중복적인 업무들도 많이 발생한다. 이러한, 업무의 누수를 어떻게 잘 검토해 내느냐가 관건이고, 정말 필요한 일을 잘 판단하는 기본적인 체크를 할 수 있는 방법을 만들어야 한다.이러한 분리된 스텝으로 정말 필요한 일과, 정말 필요 없는 일을 구분하는 것만 체크하고 점검하여 진행하여도, 업무의 우선순위는 대부분 정해지고, 불필요한 일과 쓸모없는 일들을 제거할 수 있다. 물론, 냉정하게 이러한 업무를 제대로 해야 하는 것이 중간관리자나, 팀장들이 일을 잘하는 경우에 해당되겠다. 또한, 효과적인 의사소통이 많아지고, 효과적으로 대응하는 경우에 이러한 업무의 구분이 보다 명확해진다. (* 그렇다고, 의사소통을 많이 하겠다고, 회의시간만 길게 잡는 것 또한 불확실한 일처리를 의미한다. 대부분 그 방법은 해당 조직들이 더 잘 알고 있다. 어떤 장소에서 어떤 시간이 더 많은 대화를 나누는 것인지 잘 알고 있다. )최소한의 이러한 구분이 가능하다면, 좀 더 업무의 우선순위를 좀 더 세분화하여 정의할 수 있게 시도할 수 있다. 그것은 소프트웨어 개발에 있어 정말 중요한 정말 고품질을 요하는 업무와 적정한 품질로 처리해야 하는 업무에 대한 구분이다. 필자의 경험에 따르면 정말 고품질을 요하는 소프트웨어 개발의 범위는 전체 프로젝트 범위의 30%를 넘어선 적이 없다. 대부분은 변화가 있으며, 단순 처리되는 내용들이므로, 적절한 품질로 대응이 가능하다.단순한 crud성 화면 프로그램에 엔진에서 검토해야 하는 품질 절차와 리소스를 투입하는 바보 같은 짓을 되풀이해서는 안된다. 전체적인 품질 테스트에서도 충분하게 검토될 내용과, 단위 테스트와 아키텍처적인 관점에서 접근해야 하는 고품질의 영역을 제대로 구분해 내는 것 또한 소프트웨어 개발의 요구사항을 효과적으로 대응하는 것이다.해야 할 일중에 정말로 고품질을 요하는 소프트웨어 개발업무를 구분하자성과가 명확하게 보이는 개발업무로써, 해당 소프트웨어의 개발된 서비스의 실체와 가치가 완벽하게 드러난 일이다. 또한, 해당 서비스나 소프트웨어가 다른 개발팀이나 다른 서비스에 많은 영향을 주는 영역의 개발이라면 당연하게도 ‘고품질’이 요구된다.다만, 0순위처럼 '그 이익'이 정량화되지는 않았으나, 정성적인 기준에 의해서 그 가치가 명확해진 개발업무들이라고 보면 된다. 대부분 이러한 일들은 '요구사항'의 변화가 거의 없을뿐더러, 관료조직의 극성인 변덕스러운 직장상사도 필요한 요구사항을 틀지 못하는 경우가 많은 서비스이거나 업무에 해당한다.또한, 이러한 대부분의 고품질 개발일은 이러한 '최선을 다해야 하는 일'인 경우이다. 하지만, 업무 순위를 결정할 때에 잘못하는 것 중의 하나가. 매일, 매번 이러한 '최선을 다해야 하는 일', ‘고품질’로 결정되어진다는 것이다. 그렇지만, 그렇게 결정된 ‘고품질 속성’은 잘못 결정된 판단일 가능성이 높다. 고품질은 많아야 전체 업무의 30% 정도이다. 그 이상으로 책정된다면, 평가기준부터 잘못된 것이므로 다시 살펴봐야 한다.물론, 정확하게 일에 대해서 살펴보면 이렇게 구분하는 것은 대단한 업무 처리능력을 가진 기업이나 조직일 수 있겠지만. 그런 식으로 제대로 관리하는 기업은 한 번도 본 적이 없다. 관리의 S기업도 그렇게 정의하지는 않고, 안전이 가장 중시되는 항공기 관련 소프트웨어 개발에 있어서도 그런 식으로 기준을 정하지는 않는다. 이런 식으로 대부분의 업무가 '고품질'로 책정된다면, '업무의 중요도'를 잘못 판단하고 있는 것이다. 그러므로, 기준 작업과 검증작업을 다시 해야 한다.다만, 개발업무내용에서 그 사용가치를 찾기 힘들고, 만들어진 결과물 또한 다른 서비스나 개발 조직에 별다른 기여를 하지 못할 것이 명백하지만, 최선을 다해야 하는 개발업무가 있다. 그것은 '사장님' 또는 개발 총괄 책임자가 만들어낸 업무이다. 그것은, 개발업무 우선순위에 있어서 '책임'은 윗분들이 결정한 것이기도 하지만, 고위층의 경영적인 판단에 의해서 움직이는 전략적인 업무일 수 있다.보통 이러한 사항들은 '경영진의 의사결정'이기 때문에, 우선순위를 중요하게 책정해야 한다. 그리고, 이러한 ‘업무의 성격’은 명확하게 ‘요구사항’이나 ‘업무’에 명시가 되어야 한다. 그래야, 개발 조직은 개발함에 있어서 주저함이 없을 것이다.대부분은 고품질이 아니며, 적절한 품질요건으로 만족하는 개발 영역대부분의 '쓸데없는 일'이 아닌 보통의 개발업무들의 경우에 이 4번째에 해당한다. 이 소프트웨어 개발업무는 고품질이 아닌, 해당 개발업무의 기본적인 완성도만 추구하면 되는 일이다.또한, 이러한 업무들은 대부분 QC와 QA의 업무가 구분되어져 있고, 해당 리소스를 투입하고 있는 경우에는 이 부분으로 처리가 되는 경우가 더욱더 많이 정의되게 된다. 가능한, 품질관리에 투입되는 리소스를 최소화하는 것이 전체적인 개발의 성과를 향상하게 된다. 소프트웨어 개발업무를 어떻게 하든 이 영역을 80% 이상으로 끌어올리는 것이 개발을 효과적으로 수행하게 하는 것이다. 필자의 경험에 따르면 ‘고품질’은 20%, ‘저품질’은 80%의 영역으로 설정하고, 고급 리소스는 ‘고품질’에 투입하도록 하는 것이 가장 합당하다.일반적으로 소프트웨어 개발업무의 대부분의 구성 업무들은 이러한 '적당하게 해야 하는 업무'이다. 이 업무에는 '에너지'와 '시간'을 낭비하면 안 된다. 말 그대로, 적정하게 해야 한다. 그리고, 개발자들에게 ‘잉여’를 공급하게 하고, 반복적인 테스트와 품질 검토는 품질관리 조직에서 다양한 방법으로 접근하고, 문제의 발생을 추적하여 통보하여, 품질관리를 분리하는 것이 최선이다.‘고품질’은 품질의 주요한 권한과 책임을 ‘개발자’에게 주는 것이고, ‘저품질’은 품질을 프로세스에서 검토하여 통보하는 방법으로 수행하는 것이다. 이는 개발 조직의 최대한의 역량을 ‘고품질’에 집중하게 하고, 단순 반복 테스트와 같은 업무를 소프트웨어 개발 조직에 있어서 가장 중요한 ‘개발 조직’을 효과적으로 활용하게 하는 것이다.물론, 이러한 품질 관련 업무의 가장 중요한 고려사항은 직장상사나 동료들과의 커뮤니케이션을 가장 중요시하게 된다. 이러한 업무의 대부분은 '신뢰'가 전제가 되어야 하기 때문이다. 또한, 여기서 가장 중요한 것은 '신뢰받는 직장상사'와 ‘신뢰받는 부서’의 업무지시가 가장 핵심이 되게 된다. 또한, 이러한 업무의 우선순위가 정치적/심리적 변화에 따라서 변화되는 요구사항은 제대로 된 업무가 아닌 것이 된다. 이 부분이 가장 중요하다.일반적으로 이해하고 있는 에자일의 핵심적인 요소는 위에서 잠시 설명한 ‘신뢰’를 어떻게 의사소통하느냐가 관건이다.결론적으로 이야기하자면 소프트웨어 개발업무에 있어서 ‘업무의 우선순위’를 결정하는 요구사항을 분석하는 데 있어서 최고의 핵심 요소는 다음의 5가지를 잘 정의하는 것이다.1) 업무의 가치2) 업무의 원천( 누가 만들고 요구한 것인가? )3) 기업의 가치 추구4) 직장상사와 동료의 가치 추구5) 고품질이 정말 필요한 업무의 구분이러한 4가지의 관점을 어떻게 정성적이고 정량적인 방법으로 도출하며, 이를 의사소통하여 공통 관심사를 형성하느냐에 달려있다. 하지만, 현대의 관료화된 조직의 대부분들은 쓸모없는 요구사항들이 상당수를 차지하며, 해당 조직의 스트레스에서의 핵심 요소가 된다는 점이다.이와 같이 업무의 요구사항들을 어떻게 구분하는 것인가부터 시작하는 것이 '요구사항 공학'의 기본적인 정의이다. 냉정하게, '업무의 가치'는 그 기업과 조직이 가지고 있는 '비전'과 '골'에 영향을 받는다.그러므로, 경영진이 가장 똑똑해야 그 기업의 가치가 증대된다. 언제나 이야기하지만 경영자의 삽질을 이길 수 있는 슈퍼 개발자는 존재하지 않는다. 그것은 기적이다.

라이비오를 시작하며 이전 사업과는 다르게 어쩔 수 없이 안고 출발했던 핸디캡이 있었다."너는 개발자가 아니잖아."사실이다.아무래도 위제너레이션이나 오드리씨를 할 때는 영업과 마케팅 위주의 조직이었다보니 급하면 급한대로 내가 직접 할 수 있는 것들이 많았다. 하지만 앱 개발은 완전 다른 차원의 이야기라 (디자인은 직접 맡고 있지만) 새롭게 배워야 할 부분이 정말 많았다.'그래도 이제와서 어떻게 개발을 배우겠어.' 싶어서 공부를 시작했다가 그만두기도 몇 번.개발의 ㄱ자라도 잡아보자 싶어 HTML이나 CSS, PHP 같은 언어들을 끄적끄적 공부해보곤 했었는데, 기본서 수준이거나 Codecademy 따라해 본 것이 전부이다보니 실제로 뭔가를 해 볼 수준에는 전혀 미치지 못했다.그래서 이번에는 돈을 좀 쓰더라도 독학 말고 수업을 들어보자고 생각했다.새해를 맞아 큰 맘 먹고 백만원 상당의 패스트캠퍼스 수업을 질러 Swift3 를 배우게 되었다. (iOS 개발언어)(나만의 앱을 만들고 싶은데 넘나 어려운 것..........)벌써 오늘이 11강째인데 전체가 16강인 것을 생각하면 어느새 진도를 많이 뺐다.그런데 문제는,초기 문법 배울 때는 괜찮았는데예제 따라하기로 들어가면서부터 수준이 높아져 따라갈 수가 없다는 것이다.특히 지난 주에는 수업을 들으면서 동시에 절망하는 수준에 이르렀는데다들 아무 말도 없고 키보드 마우스 소리만 들리기에, 나만 이해를 못하고 있다는 생각에 중반부터는 아예 수업 듣기를 포기하고 조용히 yes24를 켜서 Swift 기본서를 주문했다. (빠른 상황판단ㅋㅋㅋㅠㅠㅠ)그런데 수업을 마친 후 강사님이 "오늘 너무 빨랐나요?"하고 물으니,수강생들이 너도나도 손을 들며 너무 빨랐다고, 놓쳤다고 얘길 하는 게 아닌가!나만 놓친게 아니라는 (어리석은..) 잠깐의 위로를 받았다.하지만 설날이 지나고,이제 좀 더 쉬워졌게지 하는 생각으로 오늘 11강에 들어갔더니 웬걸.여전히 어렵고, 이해가 0되는 현상이 발생했다.역시 공부에는 지름길도 속임수도 없다.아무래도 Swift 책을 때며 따로 복습해야 따라갈 수 있을 것 같다.슬프게도 두께가 이만큼이다. (1473페이지 중에 226페이지까지 복습했다^^............)*강사님이 쓰신 책도 있지만 Objective C 라는 다른 언어와의 비교를 중심으로 설명하셔서 초심자에게는 오히려 어려운 부분이 있었다. 아예 초보에게는 '꼼꼼한 재은씨의 스위프트3 (기본편)' 책을 추천한다. 제목만큼 꼼꼼하게 쓴 책이다. (홍보는 아닙니다만 책이 너무 좋아서 구매링크)뭐 하나 쉬운 것이 없지만, 그래도 서른이 되기 전에 좀 더 제대로 코딩 공부를 해 보게 되어서 다행이다.언어 + 수학 + 논리의 결합인 코딩은 어렵지만 꽤 아름답다.난 문돌이라 못 한다고 한계만 짓지 않으면 충분히 할 수 있을 것 같다.대신 만만하게 생각하지는 말고 꾸준히...........올해 안에 꼭 내 이름으로 된 앱 출시를 해봐야겠다.#라이비오 #비전공개발자 #iOS #Swift #인사이트 #경험공유

IT 서비스는 장애가 발생할 수 밖에 없습니다. 현대의 서비스는 지속적으로 커지고 복잡해지고 있습니다. 이를 해결하기 위한 MSA 구조는 장애의 규모를 줄여줄수 있지만 장애는 여전히 발생합니다. 그렇기 때문에 최근 애플리케이션 운영은 장애의 규모를 줄이고 장애를 빠르게 해결하는데 집중하고 있습니다.  그런데 이미 오래전부터 장애를 빠르게 해결하는 문화를 가진 지역이 있습니다. 바로 우리가 살고 있는 대한민국 서울입니다. 2000년에 엔터프라이즈의 IT 서비스가 태동될 때, 경험많은 해외 IT 기업들이 5년이 걸릴것이라 예상하는 ERP 시스템 통합을 한국의 기업들은 2년에서 3년만에 이뤄내는 기적(IT 지옥의 시작)을 이뤄냅니다. IT 기술이 전혀 없던 나라에서 빠르게 엔터프라이즈 IT 서비스들을 만들어 나가다보니 많은 문제들이 생겼습니다. IT 엔지니어의 혹사도 문제였지만 급하게 만들어진 IT 서비스들을 운영하는 것도 쉽지가 않았습니다. 2000년 중반의 어렵던 프로그래머의 삶을 대표하는 이미지이 때, 국내에 APM(Application Performance Mangement, 애플리케이션 성능 관리) 솔루션들이 혜성처럼 나옵니다. APM 솔루션을 통해 서비스 장애 원인을 알아낼 수 있었기 때문에 국내 엔터프라이즈 서비스를 운영하던 기업들에게 APM 솔루션은 단비와 같았습니다. 그리고 국내 APM 솔루션들은 해외 솔루션들과 비교되는 몇몇 특징을 가지고 있었는데, 그 중 하나가 실시간 어플리케이션 분석이였습니다. 그 중에서도 대표적인 실시간 분석 기능이 액티브 트랜잭션입니다. 액티브 트랜잭션애플리케이션 성능 분석 솔루션은 종료된 트랜잭션을 분석하는 기술입니다. 고객의 요청에서 응답까지의 과정을 트랜잭션이라고 합니다. 이렇게 완료된 고객의 요청을 하나 하나 분석하면 애플리케이션의 성능을 알아낼 수 있습니다. 그리고 액티브 트랜잭션은 종료되기 전의 트랜잭션을 분석하는 것입니다. 아직 완료되지 않은 트랜잭션을 분석하기 때문에 액티브 트랜잭션은 장애를 가장 빠르게 볼 수 있는 선행지표가 됩니다. 이해를 돕기 위해 아래에 벤더별 액티브 트랜잭션을 보여드립니다. 제니퍼소프트의 Active Service트랜잭션의 요청건수, 진행건수(Active Service), 완료건수가 상단에 나옵니다. 하단에는 다양한 방법으로 진행건수Active Service)를 보여주고 있습니다. 액셈의 Active Transaction트랜잭션의 요청건수, 대기건수(Active Service), 완료건수가 상단에 나옵니다. 하단에는 대기건수만(Active Transaction)를 보여주고 있습니다.와탭랩스의 Active Transaction트랜잭션의 진행건수를 원형으로 보여주고 있습니다. 와탭의 서비스는 대용량 분석을 위해 기존의 이퀄라이즈를 원형으로 보여주는 특징을 가지고 있습니다. 액티브 트랜잭션은 서비스를 오픈하는 과정에서 큰 효과를 보입니다. 아직 서비스가 완벽하지 않은 상태에서 부하 테스트를 하게 되면 서비스에 락이 걸리면서 트랜잭션이 연속으로 홀딩되면서 서비스 전체가 다운되기도 하는데, 이렇게 되면 종료된 트랜잭션으로는 분석이 불가능하기 때문입니다. 장애 상황에서의 액티브 트랜잭션장애 상황이 되면 일반적으로 액티브 트랜잭션의 양이 증가하게 됩니다. 아래는 와탭의 성능추이에서 볼수 있는 엑티브 트랜잭션의 건수를 표현하는 지표입니다. 평소 액티브 트랜잭션이 10건 이하였다면 아래와 같은 상황은 장애 상황일 확률이 높습니다. 마무리애플리케이션 성능을 분석하는 기준은 트랜잭션입니다. 데이터 분석 기준으로는 종료된 트랜잭션을 추적하는 것이 가장 중요합니다. 하지만 액티브 트랜잭션은 선행지표로서의 의미와 함께 종료된 트랜잭션으로 분석할 수 없는 상황을 알아낼 수 있는 중요한 지표이기도 합니다. 여러분이 사용하는 애플리케이션 성능 분석 도구가 있다면 액티브 트랜잭션 지표도 잘 활용하시기 바랍니다. #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지

프로그래머와 개발자는 다르다.커뮤니케이션에 대한 이야기를 하기 전에 프로그래머와 개발자의 차이에 대해 명확히 하려 한다. 먼저 프로그래머는 컴퓨터를 이용해서 프로그램을 만들거나 수정하는 일을 하는 사람이다. 프리랜서로 일하면서 외주 프로젝트를 맡거나 학교 과제를 하면서 프로그래밍을 하는 사람들 모두 프로그래머라 할 수 있겠다.반면, 개발자는 회사나 조직에 소속이 돼서 다른 사람들과 함께 일하면서 개발을 사는 사람이다. 즉 어딘가에 소속이 돼서 규칙이나 규율 혹은 그 조직의 원칙을 가지고 일을 한다면 개발자로 볼 수 있는 것이다. 정리해 보자면 모든 개발자는 프로그래머지만 모든 프로그래머는 개발자는 아니다. 프로그래머와 개발자를 굳이 나누어서 말하는 이유는 개발자에게는 커뮤니케이션 능력이 절대적으로 필요하기 때문이다. 이와 관련해 아주 적절한 비유를 소개하려고 한다. 이 비유는 칼럼니스트 임백준 님의 '개발자의 생명은 커뮤니케이션 능력'에서 가져왔다.(이 글도 아주 좋으니 읽어보는 것을 추천)비유를 해보자면 이렇다. 프로그래머나 해커는 강호를 떠돌면서 혼자서 행동하는 무사라고 한다면 개발자는 군대에 소속되어 있는 정규군이다. 칼럼에서는 정확이 이렇게 표현한다.외톨이 무사에게 생명은 칼 솜씨고 정규군의 생명은 규칙과 규율이다.칼 솜씨는 코딩 실력이 되겠고, 규칙과 규율은 다른 사람과의 커뮤니케이션 능력이라 볼 수 있겠다. 이것이 개발자에게 있어 코딩 실력이 중요하지 않다는 것은 아니다. 코딩 실력은 기본이요. 커뮤니케이션 능력도 반드시 필수적이라는 뜻이다. 군대에 속해서 전투를 치르기 위해서는 기본적인 전투능력이 필요하다. 즉, 개발자는 자기가 맡은 프로그래밍 업무를 성공적으로 수행할 수 있는 능력을 가져야 하고 이것 은 기본이다!좋은 개발자가 되기 위한 첫 번째 방법, '소통'많은 시니어 개발자들이나 개발 관련된 직종에서 오래 근무한 사람들이 가장 많이 하는 말 중 하나가 바로 커뮤니케이션에 대한 이야기다.  개발자를 뽑을 때 중요한 것이 커뮤니케이션 능력이라고 한다. 커뮤니케이션이 원활하지 않아 개발 업무에 차질이 생기는 일이 다반사며 원활한 커뮤니케이션은 막혔던 문제를 훨씬 더 빠른 속도로 풀릴 수 있게끔 만든다.그럼 구체적으로 좋은 커뮤니케이션을 하기 위해 어떻게 해야 하는지 알아보자. 한 번쯤 들어봤을 이야기들이긴 하지만 구체적인 실행방안들을 추가해서 실제 기업이나 조직에서 바로 적용할 수 있도록 했다.건설적인 대화를 하라!너무나 당연한 말이지만, 이 말이 얼마나 업무 현장에서 지켜지고 있는지는 의문이다. 먼저 건설적인 대화의 방법들을 살펴보기 전에 어떤 대화들이 건설적인 대화가 아닌지를 살펴보자. 그리고 그것을 어떻게 건설적인 대화로 바꿀 것인지 말할 것이다.(1) 대화가 끝났어도 명확한 합의점이나 결과, action item, 해결책이 나오지 않았다.- > 이 문제는 두 가지 이유에서 비롯된다. 첫 번째는 대화의 목적(대화를 하는 이유)이나 목표(해결하고자 하는 것)가 불문명해서 대화가 어느 방향을 전개되야 하는지 갈피를 못 잡기 때문이다. 그리고 두 번째는 대화가 끝난 후 테스크로 전환하는 일을 하지 않은 것이다.==> 대화의 목적과 목표를 분명히 하라! 이야기를 시작할 때는 목적과 목표를 분명히 하라. '우리 지금 이 문제를 해결하기 위해 이야기하는 거죠?' '이 문제를 어떻게 처리할지에 대해 이야기해 봐요.' 일차원적일 수도 있겠지만 이렇게 직접적으로 이야기하는 것이 원활한 커뮤니케이션을 하는데 더 효과적이다. 목적과 목표를 정하지 않고 이야기를 하게 되면 이야기가 중간에 표류할 공산이 크다.==> 대화가 끝난 후에는 반드시 대화에서 얻어낸 결과물들을 테스크로 전환하고 각자에게 배분하라! 업무적 성격의 대화인 경우 문제 해결에 대한 이야기일 가능성이 크다. 이때 액션 아이템이나 합의점이 도출되지 않았다면 건설적인 대화가 이루어지지 않은 것이다. 업무 관련 일이 아닐 경우, 단순 아이디어 회의일 경우에는 대화하면서 나온 아이디어를 적고 문서화시켜야 한다. 그래야 나중에 '너 그때 이렇게 말했잖아!' 하면서 싸우는 일이 없다. 결론이나 결과가 없는 대화는 나중에 그 문제로 인해 다시 대화하게 될 가능성이 크다. 그리고 그것은 곧 리소스의 낭비다.(2) 논쟁을 하다 삼천포로 빠지고, 논쟁이 논쟁을 위한 논쟁으로 변질된다.-> 대화를 하다 보면 항상 좋게 좋게만 흘러가는 것이 아니다. 또 원활한 커뮤니케이션이 의견 충돌이 없는 소통을 의미하는 것도 아니다. 의견이 충돌하되 그것을 건설적이고 긍정적인 방향으로 풀어내는 것이 커뮤니케이션 능력이다. 이 케이스는 목적과 목표의 설정이 제대로 이루어지지 않아서이기도 하지만 대화를 하는데 있어서 서로가 명확히 해야 할 부분을 하지 않아서이기도 하다.==> 논쟁의 지점을 분명히 하라! 특히, 논쟁 지점이 여러 가지라면 뒤죽박죽 이 얘기 저 얘기 다 하면서 시간 소모를 할 공산이 크다. 건설적인 논쟁을 위해서는 우리가 어떤 포인트 때문에 논쟁을 하는지 서로 동의하는 부분은 무엇이고 동의하지 않는 부분은 무엇인지 명확히 해야 한다. ==> 용어를 분명히 하라! 서로 쓰는 용어의 의미가 달라서 논쟁이 되는 경우도 많다. 같은 문제를 바라봐도 다르게 말할 수 있고, 다른 문제를 이야기하는데 같은 용어를 통해 이야기할 수 있다. 원활한 커뮤니케이션의 기본은 용어 통일, 논의의 통일이다. 같은 수준에서 이야기할 때 비로소 원활한 소통을 할 수 있다.커뮤니케이션에 있어서 핵심은 '당신'이다.물론, 커뮤니케이션은 쌍방의 문제다. 내가 문제일수도 있고 상대방이 문제일 수도 있다. 하지만, 원활한 커뮤니케이션에 있어서 상대방을 바꾸는 것은 매우 어렵지만, 나를 바꾸는 것은 상대방을 바꾸는 것보다는 수월하다. 그리고 진정으로 커뮤니케이션을 잘하는 사람은 커뮤니케이션을 못하는 사람과도 '잘' 하는 사람이다. 커뮤니케이션을 잘하는 개발자로 인정받고 싶다면 그 누구와도 잘 할 준비가 되어 있어야 한다.그럼 어떻게 바뀌어야 커뮤니케이션을 잘 할 수 있게 되는지 세 가지 조건을 통해서 알아보자.(1) 자신과 상대방의 커뮤니케이션 스타일을 파악한다.서로 누구의 잘못이라기보다는 방식의 차이 때문에 싸우는 경우가 다반사다. 말투, 어투, 말하는 방식, 시기 등 자신의 스타일을 모르고 상대방의 스타일을 이해하지 못할 때 커뮤니케이션은 막혀버린다. 가장 좋은 것은 글로 적어보는 것이다. 나는 이렇고 상대방은 이렇다. 직접적으로 적어본다면 보다 커뮤니케이션 스타일을 이해하기 쉬워진다. 그리고 커뮤니케이션 스타일을 이해하는 것만으로도 커뮤니케이션을 할 때 많은 도움이 된다.(2) 상대방이 당신에게 망설임 없이 커뮤니케이션할 수 있게 하라!어떤 사람과는 커뮤니케이션 시작 자체를 하기가 어려운 사람들이 있다. 바쁘거나 시작하면 논의가 이루어지지 않거나 많은 조건들이 있을 것이다. 특히, 이 부분에 대해서는 스스로를 돌아보기가 매우 힘들다. 이때는 딱 두 가지의 것을 확인하면 된다.첫 번째로는 주변에 커뮤니케이션하기 망설여지는 상대를 찾아보라. 그리고 그 사람과는 왜 커뮤니케이션이 망설여지는지 생각해 보고 나를 돌아보면 된다. 타산지석(他山之石)이라 했던가. 혹시 내가 커뮤니케이션이 망설여지는 사람이 아닌지 다른 사람을 통해 되돌아보자.두 번째로는 다른 사람에게 솔직하게 물어보는 것이다. 이 방법이 사실 제일 중요하다. 내가 커뮤니케이션에 있어서 부족한 점은 없는지 상대방에게 물어보는 것이 가장 효과적인 방법이다. 물론, 솔직한 말을 듣는 것이 처음에는 두렵고 상처가 될 수도 있다. 하지만, 이것은 당신을 가장 성장시켜줄 대화 중 하나다. 동료만큼 당신과 커뮤니케이션을 많이 하는 사람도 없을 테니 바로 옆자리의 동료에게 자신의 커뮤니케이션에 있어서 부족한 점을 솔직히 말해달라고 부탁하라!(3) 동료와 친밀한 관계를 형성하고 공감하는 것은 중요하다.여기 회사 동료와 친할수록 일의 효율이 올라간다는 연구결과가 있다. 커뮤니케이션의 기본은 열린 마음이다. 그리고 마음은 상대방에게 호의가 있을 때 더 쉽게 열린다. 좋은 커뮤니케이션을 위해서라면 사전에 좋은 관계를 형성하는 것도 중요하다. 좋은 관계와 좋은 커뮤니케이션은 서로 밀접한 상관관계가 있다.대화가 커뮤니케이션의 전부가 아니다.대화만으로 모든 커뮤니케이션을 할 수는 없다. 효율적이지도 않고 물리적으로 불가능한 상황이 있을 수도 있다. 원활한 커뮤니케이션을 위해서라면 적절한 도구의 사용이 필요하다. 즉, 협업 툴을 효과적으로 사용하여 자신이 하고 있는 일들을 상대방에게 알려주고 상대방의 업무를 파악하려고 노력하라!도구의 사용은 커뮤니케이션에 사용하는 비용을 엄청나게 절감해 준다. 자신이 커뮤니케이션에 자신이 없고 언변이 부족하다 생각한다면 도구를 잘 쓰는 방식으로 커뮤니케이션 능력을 향상시킬 수 있다. 지금까지 위에서 언급한 것들은 쉽게 바뀔 수 있는 것들이 아니다. 왜냐하면 지금까지 몸에 체화된 자신만의 대화 방식을 바꾸는 것이기 때문이다. 하지만 커뮤니케이션 도구의 사용은 프로그램이다. 프로그램은 사용법을 배우면 된다.예를 들어, ASANA라는 협업 툴로 자신과 동료의 업무를 리스트화하고 체크할 수 있다. 또는, 구글 캘린더에 자신의 스케줄을 올려서 일정을 공유할 수 있다. 협업 툴을 이용하면 일의 진행사항들을 쉽게 공유하고 상대방의 일정을 파악할 수 있다. 그리고 이런 정보의 공유는 원활한 커뮤니케이션의 기본이다. 이런 도구들을 통해 커뮤니케이션이 부족한 사람들도 충분히 좋은 '커뮤니케이터'가 될 수 있다.커뮤니케이션도 실력이다.다시 처음으로 돌아가 커뮤니케이션의 필요성에 대해 다시 강조하려고 한다. 어떤 사람은 개발자의 핵심은 개발 능력이고 커뮤니케이션은 잘하면 좋은 것이라 생각한다. 위에서도 언급했지만, 개발자는 떠돌이 무사나 용병이 아니다. 조직에 소속되어 있는 개발자라면 소통하고 커뮤니케이션을 하는 능력이 핵심이다.그래서 개발자가 되려는 사람들에 항상 하는 말 중 하나가 다른 사람과 함께한 협업 프로젝트를 해보라는 것이다. 함께 프로젝트를 하는 경험은 프로그래밍 능력을 향상시킬 뿐만 아니라 어떻게 함께 개발하는지에 대해 많은 고민을 할 수 있게 해준다. 단순히 프로그래머가 되려면 코딩 실력에만 집중하라! 그러나, 다른 사람들과 함께 개발을 하는 개발자를 지향한다면 반드시 커뮤니케이션 역량도 향상시켜라!Good Developer 두 번째는 커뮤니케이션에 대해서 다루었다. 다음 Good Developer 는 나쁜 개발자에 대해서 알아볼 것이다.

Angular의 A마크를 알아본 프론트엔드 개발자님!이 글은 새로운 플랫폼을 개발하고 있는 타운컴퍼니 개발팀으로 당신을 모셔보려는 글이에요.이들이 당신과 함께 일하고 싶은 동료입니다..타운컴퍼니팀은 알고 있습니다.잘 만들어진 편리한 앱과 고객의 이탈률이 얼마나 밀접한 관계가 있는가를요.1%의 스타트업에는 1% 개발자가 필요하며 그들이 1%의 플랫폼을 만든다는 것을요.자율적이며 열정이 넘치는 팀으로 즐겁게 높은 수준의 개발을 할 수 있는 환경이죠!당신에게 즐거운 회사, 좋은 동료가 되어 줄 수 있습니다.급여는 협의 후 결정이니 원하는걸 말해봐요!좋은 동료를 얻을 수 있다면 그정도가 어렵겠어요 ; )우리는 현재 플랫폼(townus.co.kr)이 많이 부족하다는걸 알고 있어요.그래서 완전 멋있게 새롭게 만들고 있는 중입니다 :)일단 우리는 협업툴 JIRA와 Confluence, Slack을 사용하고 있어요.우리팀은 Agile 칸반을 바탕으로 테스트 주도 개발, 코드 리뷰, 페어프로그래밍으로 프로젝트를 진행하고 있죠.도메인이 잘 분석된 명세서가 Confluence에 정리되어 있고 사용자를 위한 깊은 고민이 녹아있는 디자인이 Zeplin에 올라가고 있어요.- Back-End는 Django(DRF) 기반으로 개발되고 있고, AWS, Vagrant, Docker같은 기술을 사용해요.- Front-End는 Angular 5를 사용해서 개발하고 있고, Less, RxJS, Webpack 등의 기술을 사용하고 있어요.Angular 상용 프로젝트 개발 경험이 있다면 격하게 환영하며 모십니다. 리엑티브 프로그래밍, Ionic 경험이 있다면 더 좋구요!엥 이거 완전 나 아니냐!? 라는 생각이 들었다구요? 그렇다면 얼른 지원해야지 뭐해요!무엇보다 개발을 즐기고 오픈소스활동을 좋아하는 사람이라면,종종 맛있는것도 먹으면서 많은 대화를 나눌수 있지 않을까요? :>우리 개발자는 맥주제조도 할 줄 알거든요 (겁나 맛이 좋더라구요)물론 당신에 대해 알 수 있는 Github 주소와 이력서를 보내준다면 우리가 연락하기 더 쉬울거에요!아! 참고로 보충역 산업기능요원 편입도 가능하니 문의가 필요하다면 언제든 환영이에요!타운컴퍼니팀에게 연락하고 싶다면 02–561–0950 잊지말아요,[email protected]로 메일 보내준다면 언제든 답변줄게요 :D#타운컴퍼니 #개발자 #채용 #팀빌딩 #조직문화

사운들리는 '귀에 들리지 않는 소리'를 이용해서 컨텐츠를 전달할 수 있는 SaaS 플랫폼을 서비스하고 있습니다.제품의 구성요소는,음파를 송신할 수 있는 송신단음파를 모바일에서 수신할 수 있는 Android, iOS SDK그리고 컨텐츠를 제공하고 데이터를 수집, 분석하는 백엔드로 구성되어 있습니다.오늘은 구성 요소중 백엔드에 대해서 이야기 해보도록 하겠습니다.<그림 1. 사운들리 솔루션 구성도>사운들리의 인프라는 모두가 잘 아시는 아마존 웹 서비스를 이용하고 있으며, 크게 컨텐츠를 제공하는 API서버 부분, 로그를 수집, 분석하는 부분, 그리고 컨텐츠를 관리하는 CMS 부분으로 이루어져 있습니다.소프트웨어 스택Java : 현재 사운들리의 일부 시스템을 제외하고는 전부 자바로 작성되어 있습니다. Node.js로 시작하여 PHP를 거쳐 지금의 자바 기반의 시스템으로 구성하게 되었습니다. 다양한 사람들이 개발을 해오면서 각자 가장 잘할 수 있고, 빠르게 구현할 수 있는 언어로 개발되어 가다 현재의 자바로 통일되어 구성되게 되었습니다.Spring : API서버는 HTTP 기반의 REST API를 이용해 컨텐츠를 전달하고 있으며 스프링 프레임워크를 이용해 개발되었습니다. 이외에도 일부 분석에 스프링 배치를 사용하고 스프링을 편리하게 사용할 수 있게해주는 스프링 부트도 이용하고 있습니다.gRPC : 분산되어있는 서버들끼리 이기종 언어간 통신을 하기 위해서 Protocol Buffers 기반의 gRPC를 이용하고 있으며 서버들의 모니터링하는 서버와 에이전트들 사이의 통신 목적으로 사용합니다.Flume : 분산된 서버들에서 로그를 수집하는 역할을 합니다. 수집된 로그는 파일로 저장하며 실시간으로 볼수 있도록 엘라스틱서치에 같이 저장하고 있습니다. SDK에서 전송되는 로그 또한 웹서버의 엑세스 로그를 플럼 에이전트가 수집하는 방식으로 비동기로 처리하고 있습니다.ElasticSearch : 수집된 로그들을 실시간으로 확인하기 위해서 사용되며 Kibana를 이용해 시각화하고 있습니다.Angular.js : CMS의 프론트엔드는 Angular.js + Bootstrap을 이용해 개발되었으며, Bower를 이용한 라이브러리 관리, Grunt를 이용한 빌드 관리를 하고 있습니다.소프트웨어 개발/운영GIT : 소스코드는 git로 관리하며 Git-Flow를 이용한 브랜치 정책을 수립하여 가져가고 있고 저장소로는 깃허브를 이용합니다.Quality Practice : QA단계에서 제품을 테스트하기 전 개발자들은 QA 프로세스에 맞게 다음 3가지 기준으로 소스 코드의 품질을 관리합니다.코딩 컨벤션 : 사운들리 내부 코딩 컨벤션에 맞게 개발되었는지 확인합니다. Checkstyle의 규칙을 정의 및 자동화합니다.테스트 코드 : 단위 테스트 코드를 작성하며 테스트 결과는 모두 통과되어야 합니다.테스트 커버리지 : 단위 테스트 코드가 작성된 커버리지를 계산하며 현재 60%를 목표로 진행하고 있습니다.젠킨스 : 소스코드 저장소에 변동이 일어나면 젠킨스가 소스코드를 빌드하고 위에서 언급한 세가지에 대한 리포트를 작성합니다.소나큐브 : 무료 오픈소스로 코드 정적 분석을 해주며 및 QA 리포트를 같이 볼 수 있습니다.슬랙 : 인력이 적은 저희 팀도 슬랙을 적극적으로 개발/운영에서 사용하고 있습니다.팀 커뮤니케이션 : 팀원들 간의 의사사통을 위한 주요 수단으로 모든 팀원이 함께 사용하고 있습니다.분석 리포트 : 젠킨스나 배치를 통해 분석된 데이터들은 분석이 끝난 지표들은 슬랙으로 결과를 전송하여 모든 팀원이 볼 수 있도록 공유하고 있습니다.서버 모니터링 : 서버들의 이상 징후 감지나 배치 오류등을 슬랙을 통해 담당자에게 전송하여 조치할 수 있도록 합니다.애플리케이션 및 서버 모니터링 : 애플리케이션의 모니터링은 Naver에서 오픈소스로 공개한 핀포인트를 사용하고 있고, 서버 상태 모니터링을 위해 자체 개발한 모니터링 시스템을 사용하고 있습니다. 모니터링 데이터 수집을 하는 에이전트와 전체 시스템의 데이터를 관장 하는 서버간에는 gRPC를 이용하여 상태 체크를 합니다. 서버의 상태에 문제가 있을 때에는 slack을 통해 담당자들에게 알람을 주도록 시스템 설계를 하였습니다.개발 문화개발자들은 각각 개발을 할때 정해진 정책에 맞춰 브랜치를 만들어 개발합니다.각각 개발된 소스들은 저장소인 깃허브에 푸시된 후 깃허브의 댓글 기능을 이용하거나 오프라인을 통해 코드 리뷰를 진행합니다.리뷰가 끝난 후 합쳐진 소스는 QP 활동을 통해 분석이 됩니다.빌드가 실패할 경우 커피를 사야합니다 ^^ (커피를 얻어 먹으려는 것이 아닌 소스코드를 푸시하기 전 잘 확인하자는 취지입니다) AWSEC2 : 사운들리의 대부분의 구성 요소인 API서버와 로그 수집, 분석 서버, 엘라스틱서치, 플럼, CMS등이 모두 EC2에 구축되어 있습니다.RDS : 컨텐츠의 주 저장소로 데이터베이스 관리의 용이성을 고려하여 RDS의 Multi-AZ에 배포하여 Active-Standby로 구성되어 있으며 이 데이터들은 레디스와 로컬 캐시를 이용하여 API서버에서 활용하고 있습니다.S3 : 컨텐츠에 포함된 각종 정적 데이터들이 저장되며 수집된 로그들도 저장하여 보관됩니다. EMR : 로그 수집서버를 통해 S3에 저장된 로그들은 EMR을 이용해서 분석됩니다.Beanstalk : 개발 서버의 배포에 사용됩니다. 최근 IntelliJ의 플러그인이 업데이트 되면서 IntelliJ 15버전을 지원하게 되므로써 로컬에서 개발하고 개발 서버에 배포까지 편리하게 하고 있습니다. VPC : 인터넷이 필요 없는 서버들은 VPC 내부 private-zone에 배포 및 ELB를 통해 외부에서 접근하도록 구성되어 있습니다.<그림 2. AWS 배포 구성도>이상으로 사운들리에서 사용하고 있는 백엔드 소프트웨어들을 소개해 보았습니다. 적은 인력으로 빠르게 사업을 진행하는 스타트업에서는 비즈니스에 집중할 수 있도록 도와주는 다양한 툴이나 오픈소스를 이용하여 많은 도움을 받을 수 있는 것 같습니다. 또한 코드를 잘 작성하여 에러를 줄이는 것도 필요하지만 여유가 많지 않으면 최소한 제품의 에러에 빠르게 대응할 수 있도록 하는 방법도 필요한 것 같습니다.#사운들리 #개발 #개발자 #문제해결 #프레임워크 #스킬스택 #스택 #인사이트

Understanding node.js 글을 번역한 글입니다. 부족한 영어 실력이지만 공부를 위해 번역하여 틀린 내용이 있을 수 있습니다. 이런 부분이 있을 경우 댓글로 알려주시면 감사하겠습니다!! 글이 문답형으로 진행되니 감안하시고 읽어주세요!Node.js(이후 '노드'로 통칭)를 소개했을 때 사람들은 일반적으로 두 가지 반응을 보인다. 바로 알았다고 하는 반응 혹은 매우 혼란스러워 하는 반응이다.만약 너가 후자의 경우라면 노드를 설명하기 위한 내 시도가 있다.노드는 command line tool이다. 너는 파일을 다운로드하고 컴파일하고 소스를 설치한다.노드는 JavaScript(이후 '자바스크립트'로 통칭) 프로그램들을 터미널에 'node my_app.js'를 입력함으로써 실행하게 한다.자바스크립트는 V8 자바스크립트 엔진으로 실행된다. (구글 크롬을 빠르게 만드는 것이다.)노드는 네트워크와 파일 시스템에 접근하기 위한 자바스크립트 API를 제공한다.나는 내가 필요한 모든 것을 Ruby, Python, PHP, Java에서 구현할 수 있어!너의 말이 맞다! 미안하게도 노드는 너를 위해 오고 너의 일을 하는 별난 유니콘이 아니다. 이것은 단지 툴이고 적어도 지금은 너가 보통 사용하는 완벽한 툴들을 대체하지 않을 것이다.요점을 알려줘!ㅇㅋ. 기본적으로 노드는 같은 시간에 여러 가지의 일들을 해야할 때 매우 좋다. 코드를 작성하고 "나는 이것들이 동시에 작동했으면 좋겠어"라고 말해본 적 있니? 노드에서는 너의 코드를 제외한 모든 것들이 동시에 작동한다.엥??정말이다. 너의 코드를 제외한 모든 것들이 동시에 작동한다. 이것을 이해하기 위해 너의 코드는 왕이고 노드는 왕의 하인들이라고 상상해보자.한 하인이 왕을 깨워 왕이 필요한 것들이 있는지 물어보는 것으로 하루가 시작된다. 왕은 하인들에게 해야할 일 목록을 주고 다시 오랫동안 자러 간다. 하인은 이 할 일들을 동료들에게 나눠주고 그들은 일을 시작한다.하인이 일을 끝내면 그는 왕의 쿼터 밖으로 보고서를 나열한다. 왕은 한 하인씩 따로따로 들여보내고 그들의 보고서를 듣는다. 때때로 왕은 나가는 길에 하인에게 더 많은 일을 준다.인생은 좋다. 왕의 하인들이 동시에 왕의 모든 일들을 수행하는 동안 왕은 하나의 결과가 있는 보고서에만 따로따로 집중할 수 있다.짱이다! 하지만 그 어리석은 비유를 그만두고 컴퓨터적으로 말해줄 수 있니?ㅇㅋ. 간단한 노드 프로그램은 아래와 같을 것이다:너의 코드는 노드에게 파일을 읽고 쓰는 두가지 일을 주고 자러 간다. 노드가 일을 완료했을 때 이것을 위한 콜백이 실행된다. 하지만 그들은 동시에 실행되는 콜백이 될뿐이다. 콜백이 실행을 완료하는 동안까지 다른 모든 콜백들은 라인에서 멈춰있어야 한다. 게다가 그 콜백들이 실행될 것이라는 보장도 없다.그래서 나는 동시에 같은 데이터 구조에 접근하는 코드에 관해 걱정할 필요가 없지않아?맞다! 그것이 자바스크립트의 싱글 쓰레드와 이벤트 루프 디자인의 아름다움이다. 좋긴 하지만 내가 왜 노드를 써야해?한 가지 이유는 효율성이다. 웹 어플리케이션에서 너의 메인 응답 시간 비용은 대개 너의 모든 데이터베이스 쿼리들이 실행하는데 전력하는 시간들의 합이다. 노드에서는 제일 느린 쿼리를 실행하는 동안 응답시간을 줄이기 위해 너의 모든 쿼리를 즉시 실행한다.또 다른 이유는 자바스크립트다. 너는 노드를 브라우저와 백엔드 사이에서 코드를 공유하기 위해 사용할 수 잇다. 자바스크립트는 정말 다방면성의 언어다. 너가 과거에Python, Ruby, Java, PHP를 써왔다하더라도 아마도 어떤 자바스크립트를 선택해왔을 것이다.마지막 이유는 로우 스피드다. V8은 계속해서 행성에서 가장 빠른 동적 언어 인터프리터의 하나로 경계를 밀고 있다. 나는 자바스크립트만큼 적극적으로 속도를 위해 푸시되는 다른 언어를 생각할 수 없다. 게다가 노드의 I/O 설비는 정말 가볍고 너의 시스템의 가능한 많은 I/O 능력을 활용하게 다가가는 것이다.그러면 너는 내가 당장 내 모든 앱을 노드에서 구현하라고 말하는거야?그렇기도 하고 아니기도 하다. 너가 노드 망치를 휘두르기 시작하면 모든것들은 분명 손톱처럼 보이기 시작할 것이다. 하지만 만약 너가 데드라인이 있는 일을 한다면 너는 아래의 사항들을 기초하여 결정하고 싶을 수도 있다.- 적은 응답 시간과 높은 동시성이 중요한가? 노드는 이것에 정말 좋다.- 프로젝트가 얼마나 큰가? 작은 프로젝트는 괜찮다. 큰 프로젝트는 아마 신중하게 평가해야 한다. (이용가능한 라이브러리, 버그를 고치기 위한 리소스들, 투 업스트림 등)윈도우에서 노드가 실행되니?안된다. 만약 너가 윈도우라면 너는 리눅스와 함께 버츄얼 머신을 실행해야 한다. (VirtualBox를 추천한다.) 윈도우는 노드를 지원하는 계획이 있지만 그 포트와 함께 도와주기를 원하지 않는다면 앞으로 몇 달 동안 뜸들이지 마라.노드에서 DOM에 접근할 수 있니?좋은 질문이다! 접근할 수 없다. DOM는 물질적인 브라우저고 노드의 자바스크립트 엔진(V8)은 감사하게도 그 복잡한 모든것들과 분리했다. 그러나 사람들은 노드 모듈로써 DOM를 실행하여 일한다. 이것은 클라이언트 사이드 코드 유닛 테스트와 같은 매우 놀라온 가능성을 열어줄 것 같다. 이벤트 드리븐 프로그래밍은 어렵지 않니?그것은 너에게 달렸다. 만약 너가 juggle AJAX를 호출하는 방법과 브라우저에서 유저 이벤트들에 대해 이미 배웠다면 노드 사용 방법을 배우는게 큰 문제 아닐 것이다.그렇지 않다면 너가 유지 보수 디자인을 마련하는데 도움을 줄 수 있는 드리븐 개발을 테스트해라.노드는 누가 사용하고 있니?node wiki에 작고 불안정한 리스트가 있다. 야후는 YUI를 위해 노드를 경험중이고 Plurk는 거대한 comet을 위해 사용중고 Paul Bakaus(jQuery UI fame)은 노드 백엔드를 가지는 mind-blowing game engine을 빌드 중이다. Joyent는 노드 창시자인 Ryan Dahi를 고용하여 개발에 막대한 지원을 해주고 있다.아 그리고 Heroku는 실험적으로 hosting support for node.js를 발표했다.어디서 더 배울수 있니?Tim Caswell는 훌륭한 How To Node 블로그를 운영중이다. 트위터에서 #nodejs를 팔로우해라. 메일링 리스트를 구독해라. 그리고 IRC 채널 #node.js에서 시간을 보내라. 우리는 곧 200 lurker-mark에 도달해 간다. 또한 나는 계속 http://debuggable.com/에 글을 쓰고 있다. #트레바리 #개발자 #안드로이드 #앱개발 #Node.js #백엔드 #인사이트 #경험공유

이 포스팅은 총 2부로 이어지며 현재는 2부입니다.1부 : AWS 비용 얼마까지 줄여봤니?2부 : AWS Instance Scheduler Bot 적용기1부에서 AWS 비용을 절감하기 위한 Instance Scheduler에 대한 소개를 하였습니다. 2부에서는 Instance Scheduler의 설정을 손쉽게 변경하기 위한 Bot을 적용한 사례에 대해서 소개합니다.Bot의 필요성Instance Scheduler의 설정을 변경하기 위해서는 정보를 담고 있는 Dynamo DB 의 데이터를 변경해야 합니다. AWS Console을 이용하여 직접 수정할 수도 있지만 여전히 불편하고 느립니다. 더군다나 이를 이용하는 사용자가 DB Table의 구조와 AWS Console 사용법을 알고 있어야 하고 비 개발자라면 더 쉽지 않은 문제입니다. 하지만 Bot을 이용하면 사용자는 어려운 DB Query나 구조를 알아야 할 필요도 없고 손쉽게 채팅 메시지를 통해 Bot에게 질의하고 처리 결과를 응답받을 수 있습니다.Outgoing WebhookJANDI에서는 Incoming Webhook과 반대되는 개념으로 Outgoing Webhook을 제공합니다. 특정 키워드로 시작하는 메시지가 있을 경우 내용을 설정된 URL Endpoint에 POST로 Webhook을 보내줍니다. Webhook을 수신한 곳에서는 일련의 처리 후 메시지 데이터 형식을 맞춰 응답하게 되면 채팅창에 메시지를 표시하게 됩니다. 이를 통해 다른 외부 시스템과 연동할 수 있습니다.POST Data예를 들어 날씨 키워드로 Outgoing Webhook을 생성했다면 /날씨 메시지가 시작될 때 다음과 같은 데이터가 Webhook으로 발송됩니다.{ "token": "YE1ronbbuoZkq7h3J5KMI4Tn", "teamName": "Toss Lab, Inc.", "roomName": "토스랩 코리아", "writerName": "Gloria", "text": "/날씨 서울", "keyword": "날씨", "createdAt": "2017-07-19T14:49:11.266Z" } token을 이용하여 요청의 유효성 체크를 할 수 있고 text를 적절히 파싱 하여 요청에 부합하는 처리를 할 수 있습니다.ResponsePOST Data를 적절히 처리 후 결과를 채팅창에 응답 메시지를 표시하고 싶다면 아래와 같은 JSON Data를 Response body에 넣어주면 됩니다.{ "body" : "서울의 현재 날씨", "connectColor" : "#FAC11B", "connectInfo" : [{ "title" : "온도", "description" : "최고:28.00, 최저:24.00, 현재: 24.30" }, { "title": "날씨", "description": "흐리고 비" }] } 이를 이용하여 Instance Scheduler에도 적용해봤습니다.Schedule BotSchedule Bot은 Instance Scheduler의 Lambda 함수에 함께 포함되어 작동하며 스케쥴 조회 / 예외 설정, 서버 강제 시작/중지, 서버 상태 조회 등의 기능을 수행합니다.API Gateway와 Lambda 함수를 연결하여 Endpoint URL을 생성하고 Outgoing Webhook URL로 설정하여 Webhook으로 Lambda 함수가 실행될 수 있도록 하였습니다. Lambda 함수는 Cloudwatch를 통해서 실행되면 Scheduler가 작동되고 API Gateway를 통해 실행되면 Schedule Bot이 작동됩니다.Schedule Bot 명령어Schedule Bot은 다음과 같은 명령어를 수행합니다./서버 help : 도움말 /서버 [스케쥴명] status : 현재 서버 상태 조회 /서버 [스케쥴명] info : 오늘의 스케쥴 조회 /서버 [스케쥴명] info [YYYY-MM-DD] : 특정일 스케쥴 조회 /서버 [스케쥴명] exception info : 오늘의 스케쥴 예외 조회 /서버 [스케쥴명] exception info [YYYY-MM-DD] : 특정일 스케쥴 예외 조회 /서버 [스케쥴명] exception set [YYYY-MM-DD] [start|stop] [h:m] : 예외 설정 /서버 [스케쥴명] exception del [YYYY-MM-DD] [start|stop] : 예외 삭제 /서버 [스케쥴명] force_start : 서버 강제 실행 /서버 [스케쥴명] force_stop : 서버 강제 중지 Schedule Bot 작동 화면Schedule Bot은 서버병이라는 컨셉으로 인격화(?)에 힘썼습니다.스케쥴 정보 조회서버 상태 조회서버 강제 시작/중지명령어 오류마무리AWS 기반의 서비스를 운영하는 스타트업이라면 더욱더 현실적으로 부딪히는 비용 문제에 대해서 저희가 고민한 내용과 솔루션에 대해서 공유하였습니다.아직 적용기간이 길지 않아 절감비용에 대해 수치적인 데이터를 언급하기는 힘들지만 많은 금액이 절감될 거라 예상하고 있습니다.저희와 같은 고민을 하고 있다면 Instance Scheduler를 적극 권장합니다.#토스랩 #잔디 #JANDI #개발 #개발자 #AWS #도입후기 #일지 #인사이트 #경험공유

<button type="button">메뉴</button>* 오역 및 오탈자가 있을 수 있습니다. 발견하시면 댓글로 제보해주세요!** 브런치 에디터의 한계로 마크다운 적용이 되지 않아 가독성이 떨어지고 복사 기능이 지원되지 않습니다. 이왕이면 이곳에서 보시기를 권장합니다. >> 가독성 좋은 문서로 보기React 공식 튜토리얼 바로가기시작하기 전에무엇을 구현할 것인가대화형 틱택토 게임을 구현하려고 합니다.원한다면 최종 결과물을 여기에서 확인할 수 있습니다. 아직 코드가 이해되지 않거나 문법이 낯설어도 걱정하지 마세요. 튜토리얼에서 차근차근 틱택토 게임을 구현하는 방법을 배울테니까요.게임을 플레이해보세요. 이동 리스트에 있는 버튼을 클릭하여 클릭한 때로 돌아가고, 그 때로 돌아간 후 보드가 어떻게 보이는지 확인할 수 있습니다.게임에 익숙해지셨다면 탭을 닫으세요. 다음 섹션에서 간단한 템플릿을 가지고 시작할 것입니다.사전 준비HTML과 JavaScript에 익숙할 것으로 생각합니다. 하지만 HTML과 JavaScript를 사용해본 적이 없더라도 튜토리얼을 따를 수 있어야 합니다.JavaScript를 다시 봐야한다면 이 가이드를 추천합니다. 튜토리얼에서 JavaScript의 최신 버전인 ES6의 몇 가지 특징들인 화살표 함수, 클래스, let, const를 사용할 것입니다. Babel REPL을 사용하여 ES6 코드가 어떻게 컴파일되는지 확인해볼 수 있습니다.튜토리얼을 공부하는 방법튜토리얼을 공부하기 위한 두 가지 방법이 있습니다. 브라우저에서 코드를 작성하거나 컴퓨터의 로컬 개발 환경을 설치할 수 있습니다. 편한 방법을 선택하여 공부하시면 됩니다.브라우저에서 코드를 작성하기 원한다면가장 빨리 시작할 수 있습니다!새로운 탭에서 시작 코드를 여세요. 빈 틱택토 필드를 볼 수 있습니다. 튜토리얼에서는 이 코드를 수정하여 진행합니다.다음 섹션인 로컬 개발 환경 설정을 스킵할 수 있습니다. 바로 개요 섹션으로 넘어가세요.사용하던 에디터에서 코드를 작성하기 원한다면다른 방법으로 사용하는 컴퓨터에 프로젝트를 설치할 수 있습니다.이 방법은 필수가 아닌 선택 사항입니다!더 많은 준비 작업이 필요하지만 에디터의 편리함을 누리며 공부할 수 있습니다.만약 이 방법으로 공부하기를 원한다면 필요한 단계들이 있습니다.  1. 설치된 Node.js가 최신 버전인지 확인해보세요.2. 새로운 프로젝트를 생성하기 위해 설치 방법을 따르세요.$ npm install -g create-react-app$ create-react-app my-app3. 새 프로젝트의 src/ 폴더에 있는 모든 파일들을 삭제해주세요. (폴더 안의 내용만 삭제하되 폴더는 삭제하지 마세요)$ cd my-app$ rm -f src/*4. 이 CSS 코드를 src/ 폴더에 index.css 파일로 추가해주세요.5. 이 JS 코드를 src/ 폴더에 index.js 파일로 추가해주세요.6. src/ 폴더에 있는 index.js의 최상단에 아래 세 줄을 추가해주세요.import React from 'react';import ReactDOM from 'react-dom';import './index.css';이제 프로젝트 폴더에서 npm start 명령어를 실행하고 브라우저에서 http://localhost:3000 를 여세요. 빈 틱택토 필드를 볼 수 있습니다.에디터에서 문법 하이라이팅 설정을 하고 싶다면 이 문서를 따르세요.도와주세요! 막히는 부분이 있어요!막히는 부분이 생겼다면 지원하는 커뮤니티를 확인해보세요. 특히 Reactiflux chat은 빠르게 도움을 받을 수 있는 좋은 방법입니다. 어떤 커뮤니티에서도 필요한 대답을 듣지 못했다면 이슈를 제출하세요. 우리가 도와드립니다.다 끝났으면 시작해봅시다!개요React란 무엇인가요?React는 유저 인터페이스 구현을 위한 선언적이고 효율적이며 유연한 JavaScript 라이브러리입니다.React는 여러 종류의 컴포넌트들을 가지고 있지만 우리는 React.Component의 서브클래스를 사용하여 시작할 것입니다.  class ShoppingList extends React.Component {  render() {    return (            Shopping List for {this.props.name}                Instagram         WhatsApp         Oculus                );  }}// Example usage:XML과 비슷한 재밌는 태그들을 사용할 것입니다. 작성한 컴포넌트는 React에게 무엇을 랜더링하고 싶은지 알려줍니다. 그러면 React는 데이터가 변경될 때 올바른 컴포넌트들을 업데이트하고 랜더링합니다.여기에서 ShoppingList는 React 컴포넌트 클래스 혹은 React 컴포넌트 타입입니다. 하나의 컴포넌트는 props라 불리는 파라미터를 사용하고, render 메서드를 통해 표시할 뷰 계층 구조를 반환합니다.render 메서드는 랜더링하길 원하는 내용을 반환하면 React는 그 내용을 가져와 스크린에 랜더링합니다. 특히 render는 랜더링할 간단한 내용인 React 엘리먼트를 반환합니다. 대부분의 React 개발자들은 이 구조를 더 쉽게 작성할 수 있게 해주는 JSX라는 특별한 문법을 사용합니다.라 쓰면 빌드 시 React.createElement('div')로 변환됩니다. 위의 코드는 아래의 코드와 동일합니다.  return React.createElement('div', {className: 'shopping-list'},  React.createElement('h1', /* ... h1 children ... */),  React.createElement('ul', /* ... ul children ... */));전체 코드는 여기에서 볼 수 있습니다.createdElement()에 대해 더 많은 내용이 궁금하다면 API reference 에 자세한 설명이 있습니다. 튜토리얼에서는 createdElement()를 직접적으로 사용하지 않습니다. 대신 JSX를 사용할 것입니다.JSX에서는 중괄호 안에 JavaScript 문법을 사용할 수 있습니다. 각 React 엘리먼트는 변수에 저장하거나 프로그램에 여기저기에 전달할 수 있는 실제 JavaScript 객체입니다.ShoppingList 컴포넌트는 내장된 DOM 컴포넌트만 랜더링하지만  코드를 작성하여 커스텀 React 컴포넌트를 쉽게 구성할 수 있습니다. 각 컴포넌트는 캡슐화되어 독립적으로 동작할 수 있습니다. 이때문에 간단한 컴포넌트들로 복잡한 UI를 구현할 수 있습니다.시작하기시작 코드를 가지고 시작해봅시다.이 코드는 우리가 구현할 틱택토 게임의 틀을 가지고 있습니다. 필요한 스타일들을 준비해두었기 때문에 JavaScript만 신경쓰면 됩니다.세 가지 컴포넌트로 구성되어 있습니다.- Square- Board- GameSquare 컴포넌트는 하나의 <button>을 랜더링합니다. Board 컴포넌트는 9개의 사각형을 랜더링합니다. Game 컴포넌트는 나중에 우리가 채워 넣어야 할 공백이 있는 하나의 보드를 랜더링합니다. 지금 이 컴포넌트들은 아무런 동작도 하지 않습니다.props를 통해 데이터 전달하기본격적으로 시작하기 위해 Board 컴포넌트에서 Square 컴포넌트로 데이터를 전달해봅시다.Board의 renderSquare 메서드에서 Square 컴포넌트 prop에 value 값을 전달하도록 코드를 변경해주세요.  class Board extends React.Component {  renderSquare(i) {    return ;  }value 값을 보여주기 위해 Square 컴포넌트의 render 메서드 안의 코드 {/* TODO */}를 {this.props.value}로 변경해주세요.  class Square extends React.Component {  render() {    return (      <button className="square">        {this.props.value}      </button>    );  }}변경 전:변경 후: 랜더링된 결과에서는 각 사각형 안에 숫자가 위치합니다.지금까지의 코드는 이곳에서 볼 수 있습니다.대화형 컴포넌트클릭 시 "X"로 채워지는 Square 컴포넌트를 만들어봅시다. Square의 render() 함수에서 반환된 버튼 태그를 다음과 같이 변경해주세요.  class Square extends React.Component {  render() {    return (      <button className="square" onClick={() => alert('click')}>        {this.props.value}      </button>    );  }}이제 사각형을 클릭하면 브라우저에서 알럿창이 뜨는걸 확인할 수 있습니다.새로운 JavaScript 문법인 화살표 함수를 사용하였습니다. onClick prop에 함수를 전달하였습니다. onClick={alert('click')} 코드를 작성하고 버튼을 클릭하면 알럿창 대신 경고가 뜨게됩니다.React 컴포넌트는 생성자에서 this.state를 설정하여 상태를 가질 수 있습니다. 상태는 각 컴포넌트마다 가지고 있습니다. 사각형의 현재 value 값을 상태에 저장하고 클릭할 때 바뀌도록 만들어봅시다.먼저 상태를 초기화하기 위해 클래스에 생성자를 추가해주세요.  class Square extends React.Component {  constructor(props) {    super(props);    this.state = {      value: null,    };  }  render() {    return (      <button className="square" onClick={() => alert('click')}>        {this.props.value}      </button>    );  }}JavaScript 클래스에서 서브클래스의 생성자를 정의할 때 super(); 메서드를 명시적으로 호출해줘야 합니다.Square의 render 메서드에서 현재 상태의 value 값을 표시하고 클릭할 때 바뀌도록 수정해주세요.- <button> 태그 안의 this.props.value 를 this.state.value로 변경해주세요.- () => alert() 이벤트 핸들러를 () => this.setState({value: 'X'})로 변경해주세요.<button> 태그는 다음과 같습니다.  class Square extends React.Component {  constructor(props) {    super(props);    this.state = {      value: null,    };  }  render() {    return (      <button className="square" onClick={() => this.setState({value: 'X'})}>        {this.state.value}      </button>    );  }}this.setState가 호출될 때마다 컴포넌트가 업데이트되므로 업데이트된 상태가 전달되어 React가 이를 병합하고 하위 컴포넌트와 함께 다시 랜더링합니다. 컴포넌트가 랜더링될 때 this.state.value는 'X'가 되어 그리드 안에 X가 보이게 됩니다.이제 사각형을 클릭하면 그 안에 X가 표시됩니다.지금까지의 코드는 이곳에서 볼 수 있습니다.개발자 도구크롬과 파이어폭스의 React 개발자 도구 확장 프로그램은 React 컴포넌트 트리를 브라우저의 개발자 도구 안에서 검사할 수 있게 해줍니다.트리 안의 컴포넌트들의 props와 상태를 검사할 수 있습니다.설치 후 페이지에서 검사하길 원하는 컴포넌트를 오른쪽 클릭하고 "Inspect"를 클릭하여 개발자 도구를 열면 오른쪽 마지막 탭에 React 탭이 보입니다.CodePen을 사용하여 이 확장 프로그램을 동작시키고 싶다면 추가적으로 필요한 작업들이 있습니다.1. 로그인 혹은 회원가입을 하고 이메일을 인증받으세요.2. "Fork" 버튼을 클릭하세요.3. "Change View"를 클릭하고 "Debug mode"를 선택하세요.4. 새롭게 열린 탭에서 React 탭이 있는 개발자 도구를 볼 수 있습니다.상태 들어올리기이제 틱택토 게임을 위한 기본 블록들이 있습니다. 하지만 아직 각 Square 컴포넌트 안에 상태들이 캡슐화되어 있습니다. 더 원활하게 동작하는 게임을 만들기 위해 한 플레이어가 게임에서 이겼는지를 확인하고 사각형 안에 X와 O를 번갈아 표시해야 합니다. 누가 게임에서 이겼는지 확인하기 위해 Square 컴포넌트들을 쪼개지 않고 한 장소에서 9개의 사각형의 value 값을 모두 가지고 있어야 합니다.Board가 각 Square의 현재 상태가 무엇인지만 확인해야 한다고 생각할 수도 있습니다. 이 방법은 기술적으로 React에서 가능하기는 하나 코드를 이해하기 어렵고 불안정하고 리팩토링하기 힘들게 만듭니다.각 Square에 상태를 저장하는 대신에 Board 컴포넌트에 이 상태를 저장하는 것이 가장 좋은 방법입니다. 이 Board 컴포넌트는 이전에 각 사각형에 인덱스를 표시한 방법과 동일한 방법으로 무엇을 표시할지 각 Square에게 알릴 수 있습니다.여러 하위 컴포넌트로부터 데이터를 모으거나 두 개의 하위 컴포넌트들이 서로 통신하기를 원한다면 상위 컴포넌트 안으로 상태를 이동시키세요. 상위 컴포넌트는 props를 통해 하위 컴포넌트로 상태를 전달해줄 수 있습니다. 그러면 하위 컴포넌트들은 항상 하위 컴포넌트나 상위 컴포넌트와 동기할 수 있습니다.이와 같이 상태를 상위 컴포넌트로 들어올리는 것은 React 컴포넌트들을 리팩토링할 때 가장 많이 사용하는 방법입니다. 이 기회를 통해 연습해봅시다. Board에 생성자를 추가하고 9개의 사각형과 일치하는 9개의 null을 가진 배열을 포함한 상태로 초기화하세요.  class Board extends React.Component {  constructor(props) {    super(props);    this.state = {      squares: Array(9).fill(null),    };  }  renderSquare(i) {    return ;  }  render() {    const status = 'Next player: X';    return (             {status}                 {this.renderSquare(0)}         {this.renderSquare(1)}          {this.renderSquare(2)}                        {this.renderSquare(3)}          {this.renderSquare(4)}          {this.renderSquare(5)}                        {this.renderSquare(6)}          {this.renderSquare(7)}          {this.renderSquare(8)}                );  }}나중에 이것을 다음과 같이 생긴 보드로 채울 예정입니다.  [  'O', null, 'X',  'X', 'X', 'O',  'O', null, null,]현재 Board의 renderSquare 메서드는 다음과 같습니다.    renderSquare(i) {    return ;  }Square에 value prop를 전달하도록 수정하세요.    renderSquare(i) {    return ;  }지금까지의 코드는 이곳에서 볼 수 있습니다.이제 우리는 사각형이 클릭되면 발생할 변경 사항을 구현해야 합니다. Board 컴포넌트는 어떤 사각형이 채워졌는지 저장하고 있습니다. 그렇기 때문에 Square가 Board가 가지고 있는 상태로 업데이트할 방법이 필요합니다. 사각형의 컴포넌트 상태가 각자 정의되고 있기 때문에 Board가 Square의 상태를 가지고올 수 없습니다.보통의 패턴은 사각형이 클릭될 때 호출되는 함수를 Board로부터 Square에 전달하는 것입니다. Board 안의 renderSquare를 다시 변경해봅시다.    renderSquare(i) {    return (              value={this.state.squares[i]}        onClick={() => this.handleClick(i)}      />    );  }가독성을 위해 리턴 안의 요소들을 여러 줄로 나누고, 괄호를 추가하여 JavaScript가 세미콜론 없이 코드를 마무리하도록 했습니다.Board에서 Square로 value와 onClick 두 개의 props를 전달합니다. onClick Square의 rennder에 있는 this.state.value 를 this.props.value로 변경하세요.- Square의 rennder에 있는 this.state.value 를 this.props.value로 변경하세요.- Square의 rennder에 있는 this.setState() 를 this.props.onClick()로 변경하세요.- 더이상 각 Square가 상태를 가지지 않도록 Square에 정의한 constructor를 삭제하세요.모든 변경 사항을 구현한 Square 컴포넌트는 다음과 같습니다.  class Square extends React.Component {  render() {    return (      <button className="square" onClick={() => this.props.onClick()}>        {this.props.value}      </button>    );  }}이제 사각형이 클릭될 때 Board로부터 전달되는 onClick 함수를 호출합니다. 어떤 일이 일어나는지 되짚어봅시다.1. 내장된 DOM <button> 컴포넌트의 onClick prop는 React에게 클릭 이벤트 리스너를 설정하라고 알립니다.2. 버튼이 클릭될 때 React는 Square의 render() 메서드 안에 정의된 onClick 이벤트 핸들러를 호출합니다.3. 이 이벤트 핸들러는 this.props.onClick()을 호출합니다. Square의 props는 Board에서 명시한 것입니다.4. Board는 onClick={() => this.handleClick(i)}을 Square에 전달하고, 호출될 때 Board의 this.handleClick(i)가 동작합니다.5. Board에 있는 handleClick() 메서드는 아직 정의되지 않았으므로 코드는 오류가 발생합니다DOM <button> 엘리멘트의 onClick 속성이 React와는 다른 의미를 가집니다. Square의 onClick prop나 Board의 handleClick 메서드와는 다릅니다. React 애플리케이션에서는 속성에 on* 이름을 사용하고 핸들러 메서드에 handle* 을 사용하여 처리하는 것이 일반적입니다.사각형을 클릭해봅시다. handleClick을 아직 정의하지 않았으로 에러가 발생합니다. Board 클래스에handleClick 메서드를 추가해봅시다.  class Board extends React.Component {  constructor(props) {    super(props);    this.state = {      squares: Array(9).fill(null),    };  }  handleClick(i) {    const squares = this.state.squares.slice();    squares[i] = 'X';    this.setState({squares: squares});  }  renderSquare(i) {    return (              value={this.state.squares[i]}        onClick={() => this.handleClick(i)}      />    );  }  render() {    const status = 'Next player: X';    return (             {status}                 {this.renderSquare(0)}          {this.renderSquare(1)}          {this.renderSquare(2)}                        {this.renderSquare(3)}          {this.renderSquare(4)}          {this.renderSquare(5)}                        {this.renderSquare(6)}          {this.renderSquare(7)}          {this.renderSquare(8)}                );  }}지금까지의 코드는 이곳에서 볼 수 있습니다.이미 있는 배열을 수정하는 대신 squares 배열을 복사하기 위해 .slick()를 호출합니다. 왜 immutability이 중요한지 알고 싶다면 이 섹션으로 이동해주세요.이제 사각형을 클릭하여 다시 사각형을 채울 수 있어야 하지만 상태가 각 Square가 아닌 Board 컴포넌트에 저장되어 있어 게임을 계속 구현해나가야 합니다. Board의 상태가 변경될 때마다 Square 컴포넌트들은 자동으로 다시 랜더링됩니다.Square은 더 이상 각 상태를 유지하지 않습니다. 이들은 상위 Board 컴포넌트로부터 데이터를 전달받고, 클릭될 때 알립니다. 우리는 이 제어된 컴포넌트 같은 컴포넌트들을 호출합니다.왜 immutability가 중요할까전의 예제 코드에서 이미 존재하는 배열을 수정하지 않고 변경 사항을 반영하기 위해 squares 배열을 .slice()연산자를 사용하여 복사하였습니다. 이는 무엇을 의미하며 왜 이 컨셉이 중요할까요.mutation을 사용한 데이터 변경  var player = {score: 1, name: 'Jeff'};player.score = 2;// Now player is {score: 2, name: 'Jeff'}mutation을 사용하지 않은 데이터 변경  var player = {score: 1, name: 'Jeff'};var newPlayer = Object.assign({}, player, {score: 2});// Now player is unchanged, but newPlayer is {score: 2, name: 'Jeff'}// Or if you are using object spread syntax proposal, you can write:// var newPlayer = {...player, score: 2};mutation을 사용하지 않더라도(기본 데이터를 변경하여도) 결과적으로는 다를게 없습니다. 하지만 컴포넌트와 전체 애플리케이션의 성능을 향상시키는 장점이 있습니다.쉽게 Undo/Redo와 시간 여행하기immutability는 이 복잡한 기능들을 훨씬 더 쉽게 구현할 수 있게 해줍니다. 예를 들어 이 튜토리얼에서 우리는 게임의 다른 단계들 사이에 시간 여행을 구현할 것입니다. 데이터 변경을 피하면 우리가 이전 버전의 데이터를 계속 참조할 수 있게 해주고 원할 때 변경할 수 있게 해줍니다.변경 사항 트래킹하기변경되는 객체가 변경 사항이 있는지 아는 방법은 변경 사항이 객체로 만들어지기 때문에 복잡합니다. 그러면 이전 버전을 복사하기 위해 전체의 객체 트리를 현재 버전과 비교하고 각 변수와 값들을 비교해야 합니다. 이 과정은 갈수록 복잡해집니다.immutable 객체가 변경 사항이 있는지 아는 방법은 쉬워집니다. 만약 참조되고 있는 객체가 이전과 다르다면 이 객체는 변경된 것입니다. 이게 끝입니다.React에서 언제 다시 랜더링할지 결정하기React에서 immutability의 가장 큰 장점은 간단한 순수 컴포넌트들이 다시 랜더링될 때를 결정하기 쉽다는 점입니다.shouldComponentUpdate()에 대해 더 배우고 싶고 어떻게 순수 컴포넌트들을 성능 최적화 할 수 있는지 알고 싶다면 이 글을 보세요.함수 컴포넌트우리는 생성자를 지웠습니다. 사실 React는 render 메서드만으로 구성된 Square와 같은 컴포넌트 타입을 위해 함수 컴포넌트라 불리는 간단한 문법을 지원합니다. React.Component를 확장한 클래스를 정의하는 것보다 간단하게 props를 가져오고 랜더링 해야할 것을 반환하는 함수를 작성하는 것이 좋습니다.다음과 같은 함수를 사용해 Square 클래스를 변경하세요.  function Square(props) {  return (    <button className="square" onClick={props.onClick}>      {props.value}    </button>  );}여기서는 this.props를 둘 다 props로 바꿔야 합니다. 애플리케이션에 있는 여러 컴포넌트들은 함수 컴포넌트로 구현할 수 있습니다. 함수 컴포넌트는 더 쉽게 작성할 수 있고 React가 더 효율적으로 최적화할 수 있습니다.코드를 깔끔하게 만들면서 onClick={() => props.onClick()}을 onClick={props.onClick}으로 바꿨습니다. 함수를 전달하는 것은 이 코드만으로 분합니다. onClick={props.onClick()}는props.onClick을 호출하기 때문에 동작하지 않습니다.지금까지의 코드는 이곳에서 보실 수 있습니다.변화 가져오기지금 우리의 게임의 단점은 오로지 X만 플레이할 수 있다는 점입니다. 고쳐봅시다.기본적으로 첫 이동을 'X'가 되도록 설정해봅시다. Board 생성자에서 초기 상태를 수정해주세요.  class Board extends React.Component {  constructor(props) {    super(props);    this.state = {      squares: Array(9).fill(null),      xIsNext: true,    };  }이동할 때마다 xIsNext의 불린 값은 바뀌면서 상태에 저장되어야 합니다. Board의 handleClick 함수를xIsNext 값이 바뀔 수 있도록 수정해봅시다.    handleClick(i) {    const squares = this.state.squares.slice();    squares[i] = this.state.xIsNext ? 'X' : 'O';    this.setState({      squares: squares,      xIsNext: !this.state.xIsNext,    });  }이제 X와 O가 순서대로 번갈아 나타납니다. 다음에 무엇이 표시될 때 보여주기 위해 Board의 render에서 "status" 텍스트를 바꿔봅시다.    render() {    const status = 'Next player: ' + (this.state.xIsNext ? 'X' : 'O');    return (      // the rest has not changed변경 사항을 적용한 Board 컴포넌트는 다음과 같습니다.  class Board extends React.Component {  constructor(props) {    super(props);    this.state = {      squares: Array(9).fill(null),      xIsNext: true,    };  }  handleClick(i) {    const squares = this.state.squares.slice();    squares[i] = this.state.xIsNext ? 'X' : 'O';    this.setState({      squares: squares,      xIsNext: !this.state.xIsNext,    });  }  renderSquare(i) {    return (              value={this.state.squares[i]}        onClick={() => this.handleClick(i)}      />    );  }  render() {    const status = 'Next player: ' + (this.state.xIsNext ? 'X' : 'O');    return (             {status}                 {this.renderSquare(0)}          {this.renderSquare(1)}          {this.renderSquare(2)}                        {this.renderSquare(3)}          {this.renderSquare(4)}          {this.renderSquare(5)}                        {this.renderSquare(6)}          {this.renderSquare(7)}          {this.renderSquare(8)}                );  }}지금까지의 코드는 이곳에서 볼 수 있습니다.승자 알려주기언제 게임에서 이기는지 표시해봅시다. 파일 맨 하단에 헬퍼 함수를 추가해주세요.  function calculateWinner(squares) {  const lines = [    [0, 1, 2],    [3, 4, 5],    [6, 7, 8],    [0, 3, 6],    [1, 4, 7],    [2, 5, 8],    [0, 4, 8],    [2, 4, 6],  ];  for (let i = 0; i < lines>    const [a, b, c] = lines[i];    if (squares[a] && squares[a] === squares[b] && squares[a] === squares[c]) {      return squares[a];    }  }  return null;}Board의 render 함수에서 누가 게임에서 이겼는지 확인할 수 있도록 호출할 수 있습니다. 또 누군가 이겼을 떄 "Winner: [X/O]" 상태 텍스트를 표시할 수 있습니다.Board의 render에서 status를 선언을 수정해주세요.    render() {    const winner = calculateWinner(this.state.squares);    let status;    if (winner) {      status = 'Winner: ' + winner;    } else {      status = 'Next player: ' + (this.state.xIsNext ? 'X' : 'O');    }    return (      // the rest has not changedBoard에서 handleClick을 일찍 반환하여 이미 누군가 이긴 게임에서 클릭하거나 이미 칠해진 사각형을 클릭하는 경우 무시하도록 변경할 수 있습니다.축하합니다! 틱택토 게임을 완성하셨습니다! 이제 React의 기초를 알았습니다. 여기서 진짜 승자는 여러분입니다.지금까지의 코드는 이곳에서 볼 수 있습니다.히스토리 저장하기보드의 이전 상태로 되돌려 이전 상태가 표시되도록 만들어봅시다. 이동이 있을때마다 새 squares 배열을 만들었습니다. 덕분에 이전 상태의 보드를 쉽게 저장할 수 있습니다.상태에 이와 같은 객체를 저장해봅시다.  history = [  {    squares: [      null, null, null,      null, null, null,      null, null, null,    ]  },  {    squares: [      null, null, null,      null, 'X', null,      null, null, null,    ]  },  // ...]우리는 이동 리스트를 표시하여 응답할 수 있는 더 수준 높은 Game 컴포넌트를 만들고 싶습니다. 그래서 Square 상태를 Board로 들어올린 것처럼 Board의 상태를 Game으로 들어올려 최 상위 레벨에서 필요한 모든 정보를 저장해봅시다.먼저 생성자를 추가해 Game의 초기 상태를 설정해주세요.  class Game extends React.Component {  constructor(props) {    super(props);    this.state = {      history: [{        squares: Array(9).fill(null),      }],      xIsNext: true,    };  }  render() {    return (                                              {/* status */}         {/* TODO */}                );  }}그 다음 Board를 수정하여 props를 거쳐 squares를 가져오고 이전에 Square에서 했던 것처럼 Game에서 지정한 onClick prop를 만들어줍시다. 각 사각형의 위치를 클릭 핸들러로 전달하여 어떤 사각형이 클릭되었는지 알 수 있습니다. 필요한 변경 사항은 다음과 같습니다.- Board의 constructor를 삭제하세요.- Board의 renderSquare에 있는 this.state.squares[i]를 this.props.sqaures[i]로 대체하세요.- Board의 renderSquare에 있는 this.handleClick(i)를 this.props.onClick(i)로 대체하세요.변경 사항을 반영한 Board 컴포넌트는 다음과 같습니다.  class Board extends React.Component {  handleClick(i) {    const squares = this.state.squares.slice();    if (calculateWinner(squares) || squares[i]) {      return;    }    squares[i] = this.state.xIsNext ? 'X' : 'O';    this.setState({      squares: squares,      xIsNext: !this.state.xIsNext,    });  }  renderSquare(i) {    return (              value={this.props.squares[i]}        onClick={() => this.props.onClick(i)}      />    );  }  render() {    const winner = calculateWinner(this.state.squares);    let status;    if (winner) {      status = 'Winner: ' + winner;    } else {      status = 'Next player: ' + (this.state.xIsNext ? 'X' : 'O');    }    return (             {status}                 {this.renderSquare(0)}          {this.renderSquare(1)}          {this.renderSquare(2)}                        {this.renderSquare(3)}          {this.renderSquare(4)}          {this.renderSquare(5)}                        {this.renderSquare(6)}          {this.renderSquare(7)}          {this.renderSquare(8)}                );  }}Game의 render는 히스토리 전체를 보고 게임 상태를 계산하여 가져올 수 있어야 합니다.  render() {    const history = this.state.history;    const current = history[history.length - 1];    const winner = calculateWinner(current.squares);    let status;    if (winner) {      status = 'Winner: ' + winner;    } else {      status = 'Next player: ' + (this.state.xIsNext ? 'X' : 'O');    }    return (                                  squares={current.squares}            onClick={(i) => this.handleClick(i)}          />                        {status}         {/* TODO */}                );  }Game에 상태를 랜더링하고 있기 때문에{status}를 지우고 Board의 render 함수로부터 상태를 계산하는 코드를 지울 수 있습니다.  render() {    return (                      {this.renderSquare(0)}          {this.renderSquare(1)}          {this.renderSquare(2)}                        {this.renderSquare(3)}          {this.renderSquare(4)}          {this.renderSquare(5)}                        {this.renderSquare(6)}          {this.renderSquare(7)}          {this.renderSquare(8)}                );  }그 다음 Board에서 Game으로 handleClick 메서드를 옮겨야 합니다. Board 클래스에서 잘라내기를 하고 Game 클래스로 붙여넣을 수 있습니다.Game 상태는 다르기 때문에 수정해야 할 것이 조금 있습니다. Game의 handleClick은 히스토리 항목을 연결하여 새로운 배열을 만들어 스택에 푸시해야 합니다.  handleClick(i) {    const history = this.state.history;    const current = history[history.length - 1];    const squares = current.squares.slice();    if (calculateWinner(squares) || squares[i]) {      return;    }    squares[i] = this.state.xIsNext ? 'X' : 'O';    this.setState({      history: history.concat([{        squares: squares,      }]),      xIsNext: !this.state.xIsNext,    });  }여기에서 Board는 renderSquare와 render만 필요합니다. 상태 초기화와 클릭 핸들러는 둘 다 Game에서 동작합니다.지금까지의 코드는 이곳에서 보실 수 있습니다.이동 표시하기지금까지 게임에서 진행된 이동을 표시해봅시다. 이전에 React 컴포넌트가 클래스로 JS 객체이고 그 덕에 데이터를 저장하고 전달할 수 있다고 배웠습니다. React에서 여러 아이템들을 랜더링하기 위해 React 요소의 배열을 전달했습니다. 배열을 빌드하는 가장 흔한 방법은 데이터 배열에서 map을 이용하는 것입니다. Game의 render 메서드에서 해봅시다.    render() {    const history = this.state.history;    const current = history[history.length - 1];    const winner = calculateWinner(current.squares);    const moves = history.map((step, move) => {      const desc = move ?        'Go to move #' + move :        'Go to game start';      return (                 <button onClick={() => this.jumpTo(move)}>{desc}</button>             );    });    let status;    if (winner) {      status = 'Winner: ' + winner;    } else {      status = 'Next player: ' + (this.state.xIsNext ? 'X' : 'O');    }    return (                                 squares={current.squares}            onClick={(i) => this.handleClick(i)}          />                        {status}         {moves}                );  }지금까지의 코드는 이곳에서 볼 수 있습니다.히스토리의 각 단계에서 <button>이 있는 리스트 아이템을 만들었습니다. 이 리스트 아이템은 우리가 곧 구현할 클릭 핸들러를 가지고 있습니다. 코드에서 다음과 같은 경고 메시지와 함께 게임에서 만들어지는 이동 목록을 볼 수 있습니다.Warning: Each child in an array or iterator should have a unique “key” prop. Check the render method of “Game”.경고: 배열이나 이터레이터에 있는 각 자식은 유니크 "key" prop을 가져야한다. "Game"의 render 메서드를 확인해보세요.이 경고의 의미가 무엇인지 얘기해봅시다.Keys아이템 리스트를 랜더링할때 React는 항상 리스트에 있는 각 아이템에 대한 정보를 저장합니다. 만약 상태를 가진 컴포넌트를 랜더링한다면 컴포넌트가 어떻게 실행되는지와 관계없이 상태는 저장 되어야 하고 React는 네이티브 뷰의 뒤에 참고할 것을 저장한다.리스트를 업데이트할 때 React는 무엇을 바꿀지 결정해야 합니다. 리스트에 아이템들을 추가하고, 지우고, 재배열하고, 수정할 수 있습니다.이 코드가 아래의 코드로 변경된다고 상상해봅시다.  Alexa: 7 tasks leftBen: 5 tasks leftBen: 9 tasks leftClaudia: 8 tasks leftAlexa: 5 tasks left사람의 눈에는 Alexa와 Ben의 자리가 바뀌고 Claudia가 추가된 것처럼 보인다. 하지만 React는 단순한 컴퓨터 프로그램이므로 여러분의 의도를 알지 못합니다. React는 리스트의 각 요소에서 key 속성을 지정해달라고 요청합니다. 문자열은 형제로부터 각 컴포넌트들을 구분합니다. 이 경우에 alexa, ben, claudia는 구분할 수 있는 키가 됩니다. 만약 아이템들이 데이터베이스의 객체와 일치시켜야 한다면 데이터베이스 ID을 사용하세요.{user.name}: {user.taskCount} tasks leftkey는 React에서 제공되는 특별한 속성입니다(ref에서 더 확장된 기능). 엘리먼트가 만들어질때 React는 key 속성을 가져오고 반환된 엘리먼트에 직접적으로 key를 저장합니다. key가 props의 한 부분으로 보일지라도 이것은 this.props.key로 참조할 수 없습니다. React는 어떤 하위 엘리먼트가 수정될지 결정하는 동안 알아서 key를 사용합니다. 컴포넌트가 자신의 키를 알 수 있는 방법은 없습니다.리스트가 랜더링될 때 React는 새로운 버전의 각 엘리먼트를 가져오고 이전 리스트에서 매칭되는 키를 가진 것을 찾습니다. key가 세트에 추가될 때 컴포넌트는 만들어집니다. 키가 삭제될 때 컴포넌트는 소멸됩니다. 키들은 React가 각 요소를 구별할 수 있도록하여 다시 랜더링하는 것을 무시하고 상태를 유지할 수 있게 합니다. 만약 컴포넌트의 키를 바꾼다면 완전히 지운 후 새롭게 생성됩니다.동적으로 리스트를 빌드할 때마다 적당한 키를 할당할 것을 강력 추천합니다. 만약 적당한 키를 가지지 못한다면 이를 위해 데이터를 재구성하여야 할지도 모릅니다.특정한 키를 구분하지 못한다면 React는 경고를 주고 배열 인덱스를 키로 사용합니다. 이는 올바른 선택이 아닙니다. 만약 리스트에 있는 엘리먼트들을 정렬하거나 리스트에 있는 버튼을 통해 지우거나 추가하면 명시적으로 key={i}를 전달하는 방법을 사용한다면 경고를 표시하지는 않지만 동일한 문제를 발생시키므로 대부분의 경우에 추천하지 않습니다.컴포넌트의 키가 전부 다를 필요는 없지만 관련있는 형제들 사이에서는 유니크해야 합니다.시간 여행 실행하기이동 리스트를 위해 우리는 각 단계에서 유니크 ID를 가졌습니다. Game의 render 메서드에서 키는로 추가하면 경고는 표시되지 않습니다.    const moves = history.map((step, move) => {      const desc = move ?        'Go to move #' + move :        'Go to game start';      return (                 <button onClick={() => this.jumpTo(move)}>{desc}</button>             );    });지금까지의 코드는 이곳에서 보실 수 있습니다.아직 junmTo가 정의되지 않았기 때문에 이동 버튼을 클릭하면 에러가 발생합니다. 지금 표시된 단계가 무엇인지 알기 위해 Game 상태에 새로운 키를 추가해봅시다.먼저Game의 constructor에  stepNumber: 0를 추가해주세요.class Game extends React.Component {  constructor(props) {    super(props);    this.state = {      history: [{        squares: Array(9).fill(null),      }],      stepNumber: 0,      xIsNext: true,    };  }그 다음 각 상태를 업데이트하기 위해 Game의 jumpTo 메서드를 정의해봅시다. 이 메서드에서는 xIsNext를 업데이트하고, 이동의 인덱스가 짝수라면 xIsNext를 true로 설정합니다.Game 클래스에jumpTo 메서드를 추가해주세요.handleClick(i) {    // this method has not changed  }  jumpTo(step) {    this.setState({     stepNumber: step,      xIsNext: (step % 2) === 0,    });  }  render() {    // this method has not changed  }Game handleClick에 상태를 업데이트 하기위해 stempNumber:history.length를 추가하여 새로운 이동이 있을 때마다  stepNumber를 업데이트 합니다. 현재 보드의 상태를 읽을 때 handleClick이 stepNumber라고 보고 클릭하는 시간대로 상태를 되돌릴 수 있습니다.  handleClick(i) {    const history = this.state.history.slice(0, this.state.stepNumber + 1);    const current = history[history.length - 1];    const squares = current.squares.slice();    if (calculateWinner(squares) || squares[i]) {      return;    }    squares[i] = this.state.xIsNext ? 'X' : 'O';    this.setState({      history: history.concat([{        squares: squares      }]),      stepNumber: history.length,      xIsNext: !this.state.xIsNext,    });  }이제 히스토리의 각 단계를 알기 위해 Game의 render를 수정할 수 있습니다.  render() {    const history = this.state.history;    const current = history[this.state.stepNumber];    const winner = calculateWinner(current.squares);    // the rest has not changed지금까지의 코드는 이곳에서 보실 수 있습니다.이제 이동 버튼을 클릭하면 보드는 즉시 그때 표시된 게임으로 변경됩니다.마무리틱택토 게임을 플레이 해보세요.- 틱택토 게임을 플레이 해보세요.- 한 명의 플레이어가 게임에서 이길 때를 이를 알려줍니다.- 게임이 진행되는 동안 이동 기록이 저장됩니다.- 게임 보드의 에전 버전을 표시하기 위해 시간을 되돌릴 수 있습니다.잘 동작하네요! React가 어떻게 동작하는지 잘 아셨기를 바랍니다.최종 결과물은 여기에서 확인하세요.시간이 더 있거나 새로운 스킬들을 연습해보고 싶다면 해볼 수 있는 몇 가지 아이디어가 있습니다. 점점 더 어려운 순으로 배치해두었습니다.1. 움직임 리스트에서 (col, row) 형태에 각 움직임 위치를 표시하세요.2. 움직임 리스트의 선택된 아이템을 볼드처리하세요.3. 하드 코딩한 것들 대신 사각형을 두 개의 루프를 사용하여 Board를 다시 작성하세요.4. 오름차순 혹은 내림차순 뭐든지 움직임을 정렬하는 버튼을 추가해보세요.5. 누군가 이겼을 때 무엇 때문에 이겼는지 세 개의 사각형을 하이라이트하세요.튜토리얼이 진행되는 동안 우리는 엘리먼트, 컴포넌트, props, 상태를 포함한 React의 수많은 컨셉들을 다뤘습니다. 각 주제에 대한 깊은 설명을 원한다면 남은 문서를 확인하세요. 컴포넌트 정의에 대해 더 많이 배우고 싶다면 이 문서를 확인하세요.#트레바리 #개발자 #안드로이드 #앱개발 #Node.js #백엔드 #인사이트 #경험공유 #React #리액트 #리액트가이드 #한글 #번역 #문서번역

Overview주니어 개발자는 시스템 아키텍처(System Architecture) 또는 시스템 디자인(System Design)이라는 단어에 덜컥 겁부터 먹습니다. 지금 진행하고 있는 개발에만 집중하다 보니 큰 그림을 놓치고 있는 게 아닐까 란 생각이 들었죠. 조금 더 큰 그림을 보고자 공부를 시작했습니다. 문득 같은 생각을 하는 주니어 개발자 분들도 많을 것 같다고 생각했어요. 그래서 이번 글은 시스템 아키텍처에 ㅇ_ㅇ? 뀨? 하는 표정을 짓는 주니어 개발자들을 위해 썼습니다.상상의 나래: 가상의 패션 e커머스상상의 나래를 펼쳐봅시다. 패션 e커머스 서비스를 이용하는 김유저 씨가 구매한 옷이 마음에 들어 상품 리뷰를 남기고 싶어한다고요.김유저 씨는 본인의 착용 사진과 텍스트 리뷰를 작성하고 ‘리뷰 등록하기’ 버튼에 엔터를 탁! 누를 겁니다. 그런데 말이죠. 김유저 씨는 요청하고 싶은 웹서버의 IP 주소를 모르기 때문에 요청을 보낼 수가 없습니다.내 정체를 알려줘: DNS (Domain Name System)그래서, DNS(Domain Name System)에게 물어봅니다. 서버의 도메인 이름으로부터 해당 서버의 IP 주소를 알려주는 것이 바로 DNS입니다. 도메인 이름에 대한 질의를 하고, 만일 해당 도메인 이름이 DNS에 ‘A Record’ 형태로 등록이 되어 있다면 도메인 이름에 해당하는 IP 주소를 응답으로 돌려줍니다.서비스에서 자체 DNS 시스템을 가지고 있을 수 있습니다. 예를 들어 Route 53, Cloud Flare같은 서비스가 있습니다. 그렇다면 또 한 가지 의문이 생깁니다. 왜 서비스는 시스템적 부담을 안고서 자체 DNS 서버를 구축하고 있는 걸까요? 그 이유로 두 가지를 꼽을 수 있습니다.첫 번째로는 신뢰도가 높습니다. 직접 DNS Record를 관리 및 운영하기 때문입니다. 두 번째로는 보안이 우수합니다. 만약 공개하고 싶지 않은 IP 주소, 예를 들어 Database IP 주소 같은 건 공개하지 않습니다. 1)작업장소: Web Server이제 웹서버의 IP 주소를 알았으니 통신을 시도합니다. 웹서버는 웹서비스에서 필요로 하는 다양한 요청과 그에 대한 응답을 제공합니다. 클라이언트가 리뷰에 대한 사진과 텍스트를 등록하고 싶다면 웹서버에게 등록하라는 요청을 보내야 합니다.웹서버에서 요청을 받으면 사용자가 요구한 대로 사진과 텍스트를 등록하고, 그에 대한 결과 정보를 응답으로 보내줄 것입니다. 웹서버 내부에서는 그 과정에 필요한 연산을 수행합니다. 서버 개발자는 이 연산에 대한 코드를 작성하고요.센스가 없는 서버:API (Application Programing Interface)서버는 사람이 아닙니다. 센스나 재치가 없죠. 미리 정의되지 않은 요청은 대응하지 못합니다. (어버버버버 퉤! Error 404!) 그래서 약속한 요청을 보내면 약속한 방식으로 응답해줄게라고 명세를 제공합니다.약속한 요청으로 데이터를 보내면 원하는 요청에서 데이터를 정제해 잘 처리했는지, 또는 처리된 데이터를 약속한 방식(예를 들어, JSON 방식)으로 내보내죠. 웹서버는 정의된 API에 맞춰 요청과 응답을 합니다.그런데 웹서버가 수많은 요청을 받고 응답하면 과부하가 일어날 수도 있습니다. 사용자 수가 어마어마한 규모로 늘어나서 서버가 펑! 하고 터진다면, 김유저 씨는 서비스를 더 이상 이용할 수 없을 겁니다. 이용하고 싶지도 않을 겁니다!따라서, 서버가 감당하는 요청을 나누기 위해 같은 역할을 하는 서버 장비 수를 늘릴 수도 있습니다. 그러면 요청이 각기 다른 웹서버 장비에 분산되어 한 번에 감당할 수 있는 요청 수가 더욱 많아집니다.이 구역의 매니저는 나야: Load Balancer그림처럼 서버가 4대 존재하는 상황이라면, 서버 4대에 일을 적절히 분배해주는 역할이 필요합니다. 그것이 로드 밸런서(Load Balancer)입니다. 로드 밸런서가 서버에게 일을 나누는 방법론은 여러 가지가 있습니다.Random: 랜덤으로 분배하기Least loaded: 가장 적은 양의 작업을 처리하고 있는 서버에게 요청을 할당하기Round Robin: 순서를 정하여 돌아가며 작업 분배하기많이 쓰는 로드 밸런서의 종류는 Layer 4, Layer 7을 꼽을 수 있습니다.Layer 4 Load Balancer: 데이터의 내용을 보지 않고 IP주소 및 TCP/UDP 정보에 따라 단순히 분배를 해줍니다.Layer 7 Load Balancer: 서버가 하는 역할이 분리되어 있는 환경에서 데이터의 내용을 보고 각기 맞는 역할을 하는 서버에게 분배를 해줍니다.로드 밸런서는 클라이언트가 요청을 보내야 할 서버를 골라야 하는 부담을 덜어주며, 로드 밸런서에게 할당된 vIP (가상 IP)로 요청을 보내기만 하면 로드 밸런서에서 알아서 작업을 나눠줍니다. 서버에서는 적절한 로드 밸런서를 사용하면 들어오는 요청이 여러 장비에 분산되어 처리량이 늘어나고 응답 시간이 줄어드는 효과를 기대할 수 있습니다. 컨텐츠 저장소: CDN(Content Delivery Network)이제 웹서버가 클라이언트의 요청에 의해 웹페이지에 대한 응답 결과를 돌려줬습니다. 이때 클라이언트의 화면에 렌더링해야 하는 수많은 이미지가 필요합니다. 이 이미지들을 웹서버가 전부 주려면 데이터의 용량이 너무 크고, 무거워서 서버가 헥헥거리죠. (서버가 죽으면 어떻게 될까요? 클라이언트님이 경쟁사로 환승하겠죠.. 안 돼요..) 따라서 웹서버는 직접 이미지를 주는 대신 CDN(Content Delivery Network)에게 요청하라고 이야기합니다. CDN은 일반적으로 용량이 큰 컨텐츠 데이터(이미지, 비디오, 자바스크립트 라이브러리 등)를 빠른 속도로 제공하기 위해 사용자와 가까운 곳에 분산되어 있는 데이터 저장 서버입니다. 클라이언트는 용량이 큰 컨텐츠 데이터를 가까운 CDN에 요청해 멀리 있는 웹서버에서 직접 받는 것보다 빠르게 받을 수 있습니다. CDN이 동작하는 방식에는 크게 Push CDN, Pull CDN이 있습니다. Push CDN: 서버에서 컨텐츠가 업로드되거나, 변경되었을 때 모두 반영하는 방식 Pull CDN: 클라이언트가 요청할 때마다 컨텐츠가 CDN에 새로 저장되는 방식 두 방식 모두 장단점이 있습니다. Push CDN은 모든 컨텐츠를 갖고 있기에 웹서버에 요청할 일이 없지만 유지하는데 필요한 용량과 비용이 많이 필요하겠죠? Pull CDN은 클라이언트가 요청한 컨텐츠가 있으면 바로 응답하지만 그렇지 않을 땐 데이터를 웹서버로부터 가져와야 하기 때문에 서버에 요청하는 부담이 존재합니다. 컨텐츠명은 그대로인데 내용만 변경되었다면 인지하지 못하고 옛버전의 컨텐츠를 제공하죠. 그래서 Pull CDN에 들어가는 컨텐츠는 TTL(Time To Live)이 적용됩니다. TTL이란 유통기한이라고 생각하면 쉽습니다. 일정시간이 지나면 해당 데이터가 삭제되는 것이죠. 이런 방식이 적용된다면 Pull CDN의 최대 단점을 보완할 수 있습니다. 이렇게 보완이 되면 수정된 데이터에 대해서도 대응이 가능하며 서버의 용량 즉, 비용적 부담이 해소될 겁니다.소중한 내 데이터: Database서비스를 제공하다 보면 클라이언트의 소중한 정보, 이력, 상품 가격, 상품 정보 등 다양한 데이터를 저장하고, 또 제공합니다. 하지만 수많은 데이터를 웹서버에 전부 저장하고 사용하기엔 데이터의 양이 너무 많아 저장 공간도 부족하고, 데이터를 원하는 모양에 맞게 정제하기가 어렵습니다. 그래서 데이터를 저장하는 데이터베이스 서버가 따로 존재합니다.민감한 정보를 다루는 데이터베이스는 ACID라는 성질을 만족해야 하는데요.Atomicity(원자성): 데이터베이스에 적용되는 명령이 중간만 실행되지 않고 완전히 성공하거나 완전히 실패해야 한다는 것을 의미합니다. 반만 적용된 명령이 있다면 헷갈리겠죠.Consistency(일관성): 데이터베이스가 수행한 명령이 일관적으로 반영되어 있어야 한다는 의미입니다. 예를 들어 계좌에 돈을 입금했는데 잔고에 반영되지 않는다면 당황스러울 겁니다.Isolation(고립성): 데이터베이스가 수행하는 명령 도중 다른 명령이 끼어들지 못한다는 것을 의미합니다.Durability(지속성): 성공적으로 수행한 명령은 영원히 그 이후 상태로 남아있어야 한다는 걸 의미합니다. 갑자기 하루 뒤에 명령이 취소되거나 이전 상태로 롤백되면 안 됩니다. Replication (복제 / 이중화)큰 시스템에서는 똑같은 데이터베이스가 여럿 존재한다고 하는데요. 그렇다면 왜 비용적인 부담을 안으면서까지 복제 데이터베이스를 구축해놓는 걸까요? 만약에 데이터베이스가 정상적으로 동작하지 않는다면 클라이언트의 데이터를 변경하지 못하며, 클라이언트가 원하는 정보를 제공하지 못하는 불상사가 일어나게 됩니다. 글로만 써도 벌써 땀이 납니다. 그러므로 복제해놓은 데이터베이스를 얼른 마스터로 등업해 데이터 흐름에 차질이 없도록 대비해야 합니다.만약 하나의 데이터베이스가 어떤 일을 수행할 때 다른 요청들은 계속 기다려야 합니다. 그렇다면 데이터를 변경하는 데이터베이스는 하나, 읽기만 하는 데이터베이스는 여러 대가 존재해도 되지 않을까요? 바로 여기서 Master-Slave의 개념이 탄생합니다.master-slave-replicaMaster-Slave Replica (a.k.a 주인-노예)요청을 분산하기 위해서 데이터베이스를 늘리다 보면 master-slave 토픽이 등장합니다.Mater: CRUD(Create, Read, Update, Delete)가 모두 가능Slave: R(Read)만 가능Master가 데이터를 변경할 동안 읽기에 대한 요청은 Slave에게 보내집니다. 그렇게 하면 읽기 요청은 분산되어 훨씬 더 수월하고 빠른 속도로 데이터 처리가 가능할 것입니다. 만약 Master가 변경된다면 아래 계급인 Slave, Replica 데이터베이스에게도 이 정보를 전해야 합니다. 다시 말해, 자신에게 들어온 요청(Query)을 동일하게 보내 빠른 시간 안에 동기화를 시켜주죠. 하지만 동기화도 시간이 걸리는 작업이므로 무한대로 Slave Replica를 늘려 확장하기는 어렵습니다.Master-Master Replica의문이 하나 생길 겁니다. “여러 대의 Master를 두어서 변경도 가능하고, 읽기도 가능하게 하면 되지 않을까?”앞서 언급했듯이 같은 데이터의 변경 가능한 데이터베이스는 하나여야 할 것입니다. 동시에 같은 데이터를 변경했을 때 갈등을 해소하기 위한 방법론은 존재하지만, 그 방식이 복잡하고 오래 걸립니다. 안정성도 낮아지고, 효율도 떨어집니다. 그래서 Master-Slave 아키텍처를 선호하는 것이죠.Sharding그러면 같은 데이터베이스 테이블을 동시에 변경하는 건 불가능한 걸까요? 그것을 해소하기 위해 샤딩(Sharding)이라는 방법론을 사용합니다. 샤딩된 테이블은 개념적으론 하나의 테이블처럼 보이지만 사실 그 내용물이 쪼개져 있습니다. 쪼개는 방법은 여러 가지 선택할 수 있습니다만, 분명한 건 겹치는 데이터 없이 쪼갠다는 것입니다. 그래서 같은 테이블이어도 쪼개져 있다면 그 테이블에 동시에 접근해 데이터를 변경할 수 있는 것이죠.이외에 서비스별, 기능별로 쪼개어 데이터베이스를 관리하는 Federation 등 많은 데이터베이스 디자인 방법론이 존재합니다.시스템 아키텍처가 가지고 있어야 할 최소본 아키텍처요점: 시스템 아키텍쳐에서 고려해야 할 성질이렇게 간단한 시스템 아키텍처의 면면을 살펴봤습니다. 시스템 개발자라면 시스템을 디자인하면서 반드시 고려해야 할 성질들을 만날 텐데요. 위에서 소개한 내용들 역시 아래의 성질들을 충족하기 위해 탄생했다고 볼 수 있습니다.Scalability (확장성): 10만 명의 요청을 처리할 수 있는 시스템과 1000만 명의 요청을 처리할 수 있는 시스템은 다릅니다. 확장성을 고려한 시스템은 앞으로 클라이언트 수가 늘어났을 때 무리 없이 모든 요청을 처리할 수 있을 겁니다.Performance (성능): 속도와 정확성을 말합니다. 요청한 내용을 정확하고 빠르게 돌려주어야 합니다.Latency (응답 시간): 모든 요청은 클라이언트가 불편해하지 않을 정도로 빠른 시간 안에 돌려주어야 합니다.Throughput (처리량): 같은 시간 안에 더욱 많은 요청을 처리한다면 좋은 시스템입니다.Availability (접근성): 사용자가 언제든지 시스템에 요청을 보내서 응답을 받을 수 있어야 합니다. 비록 서버 장비 한두 대가 문제가 생겨 제 기능을 하지 못하더라도 사용자는 그 사실을 몰라야 합니다.Consistency (일관성): 사용자가 서버에 보낸 요청이 올바르게 반영되어야 하고, 일정한 결과를 돌려주어야 합니다. 요청을 보낼 때마다 불규칙한 결과를 돌려준다면 믿을 수 없는 서비스가 될 것입니다.결론발로 그렸나 싶을 정도의 그림과 기나긴 글을 마무리 지으며주니어 개발자로서 시스템 아키텍처를 공부하면서 느낀 점이 있다면 시스템에 대한 완벽한 대응은 없으며, 모두 장단점이 존재한다는 것입니다. (이것을 보통 trade-off라고 표현합니다.)하지만 설계하는 서비스를 잘 알고 서비스에서 무게를 둬야 할 부분을 파악한다면, 그에 맞는 시스템을 설계하고 디자인할 수 있을 겁니다. 김유저 씨도 만족시킬 수 있을 거고요. 꼬박 이틀을 밤새워서 쓴 글이 아직 시스템 아키텍처를 두려워하는 다른 주니어 개발자분들에게 도움이 되었으면 합니다. 이번에는 시스템에서 아주 기초적인 부분을 공부했으니 다음 글에선 MSA(MicroService Architecture)를 씹어봅시다! 겁이 나고 무서워도 외쳐보세요. “Hello, System Architecture!”이 세상 모든 주니어 개발자분들, 퐈잇팅입니다.참고1) 추가적인 이점에 대하여: 웹서버에서 요청을 보낼 때 database 도메인 네임으로 보낼 경우, 멀리 있는 공인 DNS 서버 (예를 들면 google public DNS server: 8.8.8.8)에 물어오는 것보다 자체 DNS 서버에 물어오는 것이 훨씬 더 빠른 속도로 응답을 받아올 수 있습니다.출처GitHub - donnemartin/system-design-primer: Learn how to design large-scale systems. Prep for the system design interview. Includes Anki flashcards.글오연주 사원 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발자 #개발팀 #인사이트 #경험공유 #주니어개발자

한화정밀기계의 협동로봇 HCR-5 / 출처 - 한화정밀기계　이제 번거로운 작업은똑똑하고 안전한 협동 로봇에게 맡기세요!　제조 산업의 다양한 과정들이 점차 기계화되어가고 있습니다. 기계화의 과정에서도 사람이 개입되어야 하는 번거로운 과정들이 남아있기 마련인데요. 사람이 꼭 필요한 섬세하고 동적인 역할까지 수행하면서 기계의 편리성을 살릴 수 있는 ‘협동 로봇(코봇)’의 탄생으로 그 고민이 해결되었습니다.머지않은 미래에 협동 로봇의 춘추전국시대가 예상되는 가운데, 2017년 시장에 진입한 한화정밀기계의 HCR 시리즈 협동 로봇은 뒤늦게 시장에 합류했지만, 유려한 디자인과 다양한 기능, 안전성을 고려한 특색 있는 제품 생산으로 전 세계 고객들의 사랑을 받으며 점유율을 확대해가고 있습니다. 협동 로봇의 발전으로 개발과 연구를 전문으로 하는 직업도 탄생했는데요. 한화정밀기계에는 협동 로봇 전문가집단인 로봇사업부가 존재합니다. 이 부서의 수장인 장우석 로봇사업부장에게 자세한 이야기를 들어보겠습니다.　Q. 안녕하세요. 우선 협동 로봇에 대해 간단히 설명 부탁드립니다!한화정밀기계 장우석 로봇사업부장 / 출처 - 한화정밀기계안녕하세요. 한화정밀기계 로봇사업부의 장우석입니다. 산업 현장에서 사람들을 돕기 위해 만들어진 로봇이 바로 협동 로봇입니다. 이들은 정확성과 일관성이 요구되는 반복적인 업무들을 처리하는데요. 기존의 반복적인 업무를 대신하고, 작업자는 주관적인 판단이나 유연성이 요구되는 일을 할 수 있도록 돕는 것이죠. 현재의 협동 로봇 이전에 주로 사용했던, 기존의 산업용 로봇은 굉장히 한정적인 업무만을 수행할 수 있었습니다. 가령 물건을 하나 옮긴다고 가정하면, 그에 맞는 고난도의 컴퓨터 프로그램을 입력해야 그 일을 할 수 있습니다. 만약 다른 장소로 물건을 옮기려고 한다면 조립공정을 멈추고 중장비를 사용해 옮겨야 합니다. 따라서 시간과 비용이 굉장히 많이 듭니다. 반면 협동 로봇은 이러한 번거로운 과정들을 한 번에 해결해줍니다. 특히, 한화정밀기계의 HCR 협동 로봇은 사용자 친화적인 인터페이스를 갖추고 있어서 작업자가 작동법을 익히는데 하루도 채 걸리지 않습니다. 또한, HCR 협동 로봇의 워크플로를 세팅하거나 변경할 때는 단순히 필요한 항목들만 클릭해 바꾸면 됩니다.싱가포르 합자법인 공장에서 HCR-5를 생산하고 동남아시아 시장에 공급할 예정인 한화정밀기계 / 출처 - 한화정밀기계　Q. 한화가 로봇 산업에 진출하게 된 계기는 무엇인가요?한화그룹은 4차 산업혁명의 일환으로 로봇 산업을 시작했습니다. 다양한 분야 중 저희는 협동 로봇에 초점을 맞췄고, 작년에 국내 최초의 협동 로봇인 HCR 시리즈를 출시했습니다.한화그룹은 항공엔진, 에너지, 산업 장비, CCTV 카메라와 같이 다양한 산업 분야에 관심을 두고 있습니다. 이러한 시장을 키우고 선두가 되기 위해, 한화는 정밀기계, 동작 조종 기술, 사물 인식 소프트웨어, 자동 내비게이션과 같은 분야에서 전문성을 높이고 있습니다. 이러한 모든 것의 중심이 바로 로봇 산업입니다.이렇게 다양한 산업 지식, 경험 그리고 기술을 바탕으로 로봇사업부를 키울 수 있었고, 지금의 HCR 시리즈 같은 제품을 시장에 내놓을 수 있게 된 것입니다. 특히 로봇 공학 분야와 소프트웨어 개발에 매우 높은 전문성을 가진 인력을 보유하여 협동 로봇 기술 개발(R&D)을 빠르게 진전시킬 수 있었습니다.　한화정밀기계와 싱가포르 정밀 엔지니어링 전문 업체인 PBA 그룹의 합자법인 "PBA-Hanwha Robotics"의 개소식 모습 / 출처 - 한화정밀기계　　Q. 한화 협동 로봇의 제품 현황과 고객 반응은 어떤가요?한화정밀기계의 협동로봇 HCR-5 / 출처 - 한화정밀기계한화정밀기계는 현재 세 종류의 협동 로봇(HCR)을 출시하였으며, 각각 3kg, 5kg, 12kg의 무게를 들 수 있습니다. 이 세 종류의 협동 로봇은 크기가 작고, 옮기기 쉬우면서 방대한 범위의 업무를 진행할 수 있기 때문에 다양한 업무 지원이 필요한 중소 제조 기업에 이상적인 모델이라 할 수 있습니다. HCR 시리즈의 시장 내 고객 반응은 매우 호의적입니다. HCR 시리즈만이 가진 가장 큰 장점은 사용자가 단일 제어 장치에서 두 개의 HCR 협동 로봇을 실행할 수 있다는 점입니다. 그렇기 때문에 운영비가 최대 10%까지 절감되는 효과가 있죠. 거기에 HCR 시리즈 조작이 쉽다는 점까지 장점으로 작용하면서 시간을 절약하고 생산성을 더욱 높일 수 있습니다.　　기능과 안정성을 모두 잡은 HCR 시리즈만의 디자인　또한, 고객들은 HCR 협동 로봇의 수려한 디자인을 가장 크게 평가합니다. 보통 산업용 기계는 튀어나온 부분들이 있어서 긁히거나 부딪힐 위험이 있는데 HCR은 부드러운 곡선 모양으로 제작되어 안전하고 디자인이 뛰어납니다. 산업 디자인은 보이는 게 전부가 아닙니다. 사람들이 협동 로봇과 같이 일할 때 실제로 안정감을 느낄 수 있어야 합니다. 그런 이유로 더 안전하고 부드럽게 보이도록 곡면을 살려 디자인했습니다. 디자인과 기능 면에서도 HCR 시리즈는 매우 안전한 제품입니다. HCR 협동 로봇은 작업자의 옆에서 업무를 보조하는데, 자동 충돌 감지 기능이 있어서 부딪히면 즉각적으로 작동을 멈춥니다.　2017 iF 디자인 어워드, 제품 디자인 부분에서 본상을 수상한 HCR 협동 로봇 / 출처 - 한화정밀기계　Q. 협동 로봇의 미래에 대한 예측과 향후 개발하고자 하는 협동 로봇은?미래에는 AI와 딥러닝, IoT 등 4차 산업혁명을 대표하는 기술들이 접목된 협동 로봇이 시장을 주도할 것이라 예측합니다. 특히 AI와 딥 러닝 기술로 인해 조만간 로봇 산업에는 큰 지각 변동이 있을 것이라 예상합니다. 원래는 5년이나 10년 주기로 일어날 것으로 생각했는데, 이제는 그것보다 더 앞당겨질 것 같네요. 예전에는 몇 년 더 걸릴 것으로 생각했던 기술들이 AI와 딥러닝 기술이 접목된 지 2년 반 만에 이미 구현되고 있으니까요!그래서 한화정밀기계에서는 앞으로 생산될 제품에 AI나 빅데이터, IoT를 어떻게 접목하고, 실제로 어떻게 적용될 수 있을지에 대해 연구하고 있습니다. AI가 접목된 협동 로봇은 어떠한 상황이나 조건에서도 최대한 쉽게 일을 수행할 수 있습니다. 특히 기술 접목 분야에서 한화그룹은 다양한 산업군과 계열사가 있다는 것이 매우 큰 장점인데요. 다양한 계열사에 자문하면서 실제로 협동 로봇이 어떻게 업무에 적용이 되고, 앞으로 어떻게 발전시킬지 논의하고 있습니다.　협동로봇 합자법인 공장 투어 모습 / 출처 - 한화정밀기계　한화정밀기계의 장우석 부장은 피처폰에서 스마트폰 시대로 바뀌었듯이, 로봇 시장도 향후 몇 년 이내로 큰 패러다임 전환이 일어나리라 전망했습니다. 단순히 몇 개의 일을 수행하는 로봇에서 거의 모든 일을 처리할 수 있는 로봇으로 변화하는 것입니다. 협동 로봇 시장은 아직 초기 단계에 있으며 시장 규모도 매우 작지만, 앞으로의 사업 성장 가능성이 매우 큰 분야입니다.한화정밀기계는 현재 유럽과 동남아시아 시장의 큰 성장 가능성을 두고 사업에 박차를 가하고 있는데요. 단기적인 목표는 시장점유율을 매년 두 배로 늘리는 것이며, 장기적인 목표는 협동 로봇 분야에서 세계적인 선도 기업이 되는 것이라고 합니다.4차 산업혁명에 힘입어 자동차와 스마트 팩토리를 중심으로 기술 트렌드를 이끄는 기업을 목표로, 글로벌 로봇 시장을 선도하는 기업이 되기 위해 끝없는 노력을 거듭하고 있습니다. 점차 확대되는 협동 로봇 시장을 선도하는 한화정밀기계의 미래를 함께 응원 부탁드립니다!#한화 #한화그룹 #한화정밀기계 #구성원인터뷰 #직무정보 #기업정보 #기업문화 #비전 #목표 #채용정보 #공채정보

안녕하세요. 스타일쉐어 개발팀의 김현준입니다. 훌륭한 엔지니어링 경험을 공유하고 싶어 만든 블로그이지만, 아직까지는 그런 일이 없었던지라, 창피한 장애 경험을 공유하고자 합니다.배경:웹 서비스 디플로이는 프로덕션 웹 서버에서 업스트림 master를 풀 받아 리로드하는 방식으로 진행하고 있습니다.CSS, JS 등의 파일들은 CDN을 위해 매 빌드마다 디플로이 이전에 S3에 업로드합니다. Git 커밋의 SHA1 해시를 키로 사용합니다.장애:어제 새벽 서비스에 긴급한 패치가 있었습니다. 하지만 이 커밋은 8분 후 다시 롤백되는데…오늘 오후 디플로이 이후에 갑자기 웹 사이트의 스타일이 전부 깨져보이기 시작했습니다.심지어 아무리 커밋 로그를 살펴봐도 존재하지도 않는 커밋 해시로 파일을 요청하고 있었습니다.원인:롤백을 git revert 명령으로 하는 대신에, 이전 커밋으로 HEAD를 돌리고 git push --force로 업스트림을 덮어썼습니다.해당 커밋은 이미 디플로이가 되어있었지만, 되돌린 이후에 다시 디플로이를 하지 않았습니다.다음 디플로이할 때 해당 웹 서버 로컬에서 업스트림 master를 풀 받자, (개발자의 로컬이나, GitHub에서 보이는 커밋 트리와 달랐기 때문에) 서로 다른 커밋 해시를 가지게 되었습니다.404교훈:force-push를 (창피한 실수라던지, 지저분한 여러개의 커밋이라던지) 이력을 남기고 싶지 않을 때 사용하는 경우가 있는데요. 이는 위의 사례처럼 해당 커밋을 이미 풀 받은 다른 개발자의 로컬을 꼬이게 하거나, 장애를 유발할 수가 있습니다. 롤백을 하고 싶은 경우엔 revert 명령을, 커밋을 정리하고 싶은 경우엔 각자의 브랜치에서 충분히 rebase를 한 뒤에 올리는 습관을 꼭 가져야겠습니다.#스타일쉐어 #개발 #개발자 #개발팀 #인사이트 #후기 #일지