대략 1년 반 전, 5.0 롤리팝과 함께 나타난 RecyclerView. ListView 를 이용할 때 아주 기초적이고 정석적인 개념으로 사용되던 ViewHolder pattern 을 반 강제화? 하면서 동시에 성능까지 개선한 ListView 의 개량버전.앱 시장이 활성화되면서 한 가지 타입의 뷰만 반복적으로 보여주는 단순한 구성보다는 다양한 타입의 뷰를 보여주는 앱들이 많아지고 보편화 된 시점에 이것을 구현하기 위한 Adapter.getView 메소드는 혼돈.chaos 가 되었지요. 가독성을 높일만한 나름대로의 시도를 해보고 있을 때, RecyclerView 가 갑툭튀 했고 이걸 이용하면 원하는 만큼의 많은 타입의 뷰를 “가독성 좋게 만들어 볼 수 있겠다” 라는 생각이 들었습니다.그래서 RecyclerView.Adapter 를 상속 받아 다양한 타입의 뷰를 바인딩 할 수 있게 도와주는 헬퍼 클래스, MultiItemAdapter 라는 것을 만들어 보게 됐습니다. 구 회사 프로덕트에 적용해보기도 하고, 개인 프로젝트에 넣어보기도 하고, 토스랩에서 서비스하고 있는 “잔디”에 녹여내보기도 했는데 나쁘지 않은 느낌이들어 그 과정을 공유하고 많은 분들께 피드백도 받고 싶습니다. 또, 어떻게 더 잘 활용하고 계신지 여쭙고 싶습니다.RecyclerView.Adapter 의 이해를 위해 단순단순하게 만들어보자public class BasicAdapter extends RecyclerView.Adapter { private List mItems = new ArrayList<>(); @Override public MyViewHolder onCreateViewHolder(ViewGroup parent, int viewType) { View itemView = LayoutInflater.from(parent.getContext()) .inflate(android.R.layout.simple_list_item_1, parent, false); return new MyViewHolder(itemView); } @Override public void onBindViewHolder(MyViewHolder holder, int position) { holder.mTextView.setText(mItems.get(position)); } class MyViewHolder extends RecyclerView.ViewHolder { private TextView mTextView; public MyViewHolder(View itemView) { super(itemView); mTextView = (TextView) itemView.findViewById(android.R.id.text1); } } ... 이런 식으로 구현하면 되는군, 하지만 내가 최종적으로 원하는 건 다양한 ViewHolder 를 다뤄야 되는 건데 ViewHolder 가 많아지는 경우 inner class 는 쓰면 안되겠다! ViewHolder 들은 따로 패키지 만들어서 관리하자. 음 근데 ViewHolder 를 구성하고 난 다음 어떻게 그려지는 지에 대해 궁금하면 다시 어댑터를 찾아가야 되고, 반대로 어댑터에서 ViewHolder 내 구성요소가 어떻게 생겼는지 궁금하면 다시 ViewHolder 찾아가서 뒤져봐야되는 군. 이건 비효율 적인 것 같다. ViewHolder에 뷰를 그리는 메소드를 하나 만들자. 아 기왕이면 추상화된 클래스를 만들어 돌려돌려 쓰자. 하나 더 Generic 을 사용하자.public abstract class BaseViewHolder extends RecyclerView.ViewHolder { public BaseViewHolder(View itemView) { super(itemView); } public abstract void onBindView(ITEM item); } 뷰를 그리는데 쓰이는 객체는 Generic 을 이용하면 ViewHolder 안에서 그리는 작업 또한 해결이 가능하겠군! 이걸 이용해서 다시 만들어보자.public class MyViewHolder extends BaseViewHolder { private TextView mTextView; public MyViewHolder(View itemView) { super(itemView); mTextView = (TextView) itemView.findViewById(android.R.id.text1); } @Override public void onBindView(String item) { mTextView.setText(item); } } ... public class BaseAdapter extends RecyclerView.Adapter { private List mItems = new ArrayList<>(); @Override public MyViewHolder onCreateViewHolder(ViewGroup parent, int viewType) { View itemView = LayoutInflater.from(parent.getContext()) .inflate(android.R.layout.simple_list_item_1, parent, false); return new MyViewHolder(itemView); } @Override public void onBindViewHolder(MyViewHolder holder, int position) { holder.onBindView(mItems.get(position)); } public void setItems(List items) { mItems.clear(); mItems.addAll(items); } @Override public int getItemCount() { return mItems.size(); } } 음 원하는 모양새다. 근데 이제 Adapter 에선 ViewHolder 에 들어갈 layout 이 어떤 건지 관심꺼도 되겠네. 게다가 ViewHolder 에서 layout 궁금하면 다시 또 찾아와야 되는게 문제다. 좀 더 명시적인 방법으로 Factory method 로 생성자를 제한해보자. RecyclerView.ViewHolder 는 View 를 가지는 생성자가 강제되니 이렇게 바꾸자.public static MyViewHolder newInstance(ViewGroup parent) { View itemView = LayoutInflater.from(parent.getContext()) .inflate(android.R.layout.simple_list_item_1, parent, false); return new MyViewHolder(itemView); } private MyViewHolder(View itemView) { super(itemView); mTextView = (TextView) itemView.findViewById(android.R.id.text1); } 이렇게 하면 어떤 layout 을 다루고 있는지도 금방 알 수 있겠다. 이 정도만 되도 구색을 다 갖춘듯하니 이 느낌으로 다양한 타입의 뷰들을 다뤄보자.public class BasicMultiTypeAdapter extends RecyclerView.Adapter { public static final int VIEW_TYPE_A = 0; public static final int VIEW_TYPE_B = 1; private List mItems = new ArrayList<>(); @Override public BaseViewHolder onCreateViewHolder(ViewGroup parent, int viewType) { if (viewType == VIEW_TYPE_A) { return AViewHolder.newInstance(parent); } else { return BViewHolder.newInstance(parent); } } @Override public void onBindViewHolder(BaseViewHolder holder, int position) { holder.onBindView(mItems.get(position)); } public void setItems(List items) { mItems.clear(); mItems.addAll(items); } @Override public int getItemCount() { return mItems.size(); } @Override public int getItemViewType(int position) { if (position % 2 == 0) { return VIEW_TYPE_A; } else { return VIEW_TYPE_B; } } } 음 깔끔하긴 하다. 근데 getItemViewType 이 스크롤 할 때마다 불릴 텐데, 분기도 많고 연산이 생겼을 때 스크롤 속도에 괜한 영향을 줄 듯? view type 을 차라리 미리 가지고 있게 만들자. 또! 가만보니 한 타입의 객체를 이용해서 다른 스타일로 뷰를 보여줄 뿐이었네. 이것도 여러가지 객체를 담을 수 있게 만들어야지.뷰를 그릴 대상이 될 객체랑 타입을 가지는 Wrapper class 를 만들어서 해결하자. 이러면 Adapter.onBindViewHolder 랑 Adapter.getItemViewType 도 해결이 되겠군.public abstract class MultiItemAdapter extends RecyclerView.Adapter { private List mRows = new ArrayList<>(); @SuppressWarnings("unchecked") @Override public void onBindViewHolder(BaseViewHolder holder, int position) { holder.onBindView(getItem(position)); } @SuppressWarnings("unchecked") public ITEM getItem(int position) { return (ITEM) mRows.get(position).getItem(); } public void setRows(List mRows) { mRows.clear(); mRows.addAll(mRows); } @Override public int getItemCount() { return mRows.size(); } @Override public int getItemViewType(int position) { return mRows.get(position).getItemViewType(); } public static class Row { private ITEM item; private int itemViewType; private Row(ITEM item, int itemViewType) { this.item = item; this.itemViewType = itemViewType; } public static Row create(T item, int itemViewType) { return new Row<>(item, itemViewType); } public ITEM getItem() { return item; } public int getItemViewType() { return itemViewType; } } } MultiItemAdapter 완성.네, 저는 이렇게 만들어서 1년 반 정도 필요한 부분(복잡해 질만한 부분)에 이 클래스를 상속받아 구현했습니다. 사용방법을 예로들어 데이터베이스나 서버로부터 긁어온 아이템들을 타입에 따라 A, B로 나눠서 보워줘야 한다면,// MutiItemAdapter 구현 public class AdvancedItemAdapter extends MultiItemAdapter { public static final int VIEW_TYPE_A = 0; public static final int VIEW_TYPE_B = 1; @Override public BaseViewHolder onCreateViewHolder(ViewGroup parent, int viewType) { if (viewType == VIEW_TYPE_A) { return AViewHolder.newInstance(parent); } else { return BViewHolder.newInstance(parent); } } } // Activity 나 Fragment 등 view 요소에서 ListAdapter item setting. public void setItems(List items) { List rows = new ArrayList<>(); for (int i = 0; i < items xss=removed>이렇게 해주면 됩니다. 그런데 위 사용방법을 보면 추가적인 새로운 타입(Row)의 List 와 반복문을 돌려야 된다는 것이 단점으로 보이는데요. 그럼 이 클래스를 사용하지 않고 직접 구현한 결과를 좀 볼까요?public class NormalItemAdapter extends RecyclerView.Adapter { public static final int VIEW_TYPE_A = 0; public static final int VIEW_TYPE_B = 1; private List mItems = new ArrayList<>(); @Override public RecyclerView.ViewHolder onCreateViewHolder(ViewGroup parent, int viewType) { if (viewType == VIEW_TYPE_A) { View itemView = LayoutInflater.from(parent.getContext()) .inflate(android.R.layout.simple_list_item_1, parent, false); return new AViewHolder(itemView); } else { View itemView = LayoutInflater.from(parent.getContext()) .inflate(android.R.layout.simple_list_item_1, parent, false); return new BViewHolder(itemView); } } @Override public void onBindViewHolder(RecyclerView.ViewHolder holder, int position) { if (holder instanceof AViewHolder) { Item item = getItem(position); ((AViewHolder) holder).getTextView().setText(item.getName()); } else { ((BViewHolder) holder).getTextView().setText("I am B."); } } private Item getItem(int position) { return mItems.get(position); } public void setItems(List items) { mItems.clear(); mItems.addAll(items); } @Override public int getItemViewType(int position) { if (getItem(position).getType().equals(Item.ITEM_TYPE_A)) { return VIEW_TYPE_A; } else { return VIEW_TYPE_B; } } @Override public int getItemCount() { return mItems.size(); } } 뭐, 나쁘진 않습니다. 이 정도 수준으로 개발이 끝나도 되고 추가적인 확장이 필요하지 않아보인다면 굳이 MultiItemAdapter 를 쓸 필요가 없습니다.중요성을 가지는 리스트 위주의 화면에서 위와 같이 개발된다면 당장 보이는 제 불만은 onCreateViewHolder, onBindViewHolder 계속해서 분기가 들어가게 되고 getItemViewType 에서는 계속 해서 List 데이터에 접근해야 한다는 것입니다. 접근 자체가 큰 문제, 큰 영향을 끼치지 않을 정도 규모의 자료구조라면 논외로 치더라도, 뷰 타입이 조금만 늘어나도 onCreateViewHolder, onBindViewHolder 의 덩치는 엄청 커질 겁니다.예를들면 맨 마지막 아이템 타입이 B 이고 현재 추가 될 아이템 타입이 A인 경우에는 다른 형태의 디바이더를 넣어야 한다던지 하는 추가적인 확장이 이루어져야 한다면 골치가 꽤 아플겁니다. 특히 저는 위 예와 비슷하게 뷰 타입에 따라 각기 다른 아래 위 마진값을 요구받을 때, ViewHolder 마다 이전 데이터를 참고하게 만들고 동적으로 Visibility 처리를 하거나 MarginLayoutParams 를 고치는 것이 비효율적으로 느껴져서 height를 주입받는 DividerViewHolder 를 하나 만들어 사용하곤 했습니다. 이렇게 하니 각각의 ViewHolder 들이 데이터들에 의존적이지 않게 코딩이 가능했었습니다. 한 가지 더 예를들어 리스트 중간 중간 광고가 보여지게 되고 이 광고 클래스는 완전히 다른 객체로부터 보여줘야 한다 라고 했을 때 MultiItemAdapter 를 이용하면 쉽게 해결이 가능합니다.정작 근 1년간 “잔디”를 만들면서는 자주 쓰진 않았는데, 작년부터 각광받기 시작한 MVP 패턴을 사용할 때 View 에서의 로직을 최소화 하려고 한다면 써먹을 수 있는 모델로 적합하지 않나 생각이 들면서 다시 사용하기 시작했습니다. Presenter 에서 Row 를 만들어 던져주면 View 는 그것을 그대로 사용하게 만들 수 있다는 생각이 들었거든요.(아직까지는 비교적 크지 않은 부분에서만 사용하게 되서 View(MainThread)에서 Row 를 만들게 코딩해 놓은 컴퍼넌트가 더 많네요 흑흑) 더 복잡한 구조를 갖는 컴퍼넌트를 만들어야 할 때는 비동기 스레드에서 Row 까지 만들어 내보내는 것도 해볼까 하는 생각도 듭니다.제 눈에만 괜찮은 구조인지, 생각지도 못한 치명적인 단점이 있진 않은지, 구조나 설계 측면에서 안 좋은 점은 있지 않은지, 논리없이 Generic 으로 “퉁” 치고 있는 코드는 아닌지, 여러가지가 많이 궁금합니다 ^^ MultiItemAdapter 를 쓴 것과 안 쓴것의 정말 심플한 비교 소스를 열어놓았습니다 MultiItemAdapter 또, 여러분들은 어떻게 구현하고 계신지요? 여러분의 관심이 필요합니다 ! :)#토스랩 #잔디 #JANDI #개발 #개발자 #인사이트 #경험공유

 버즈빌 개발팀의 모바일 스터디 그룹이란? 모바일 잠금화면 미디어 플랫폼 ‘버즈빌’의 개발팀이 진행하는 모바일 스터디 그룹이란, 모바일이라는 큰 주제를 핵심으로 하여 크고 작은 연관된 기술을 리뷰하고 토의하는 스터디 모임입니다. 2018년 7월에 처음 개설되어 현재까지 매주 진행하고 있으며 특정한 기한 없이 지속적으로 진행할 예정입니다. 모바일이라는 핵심 주제를 고지하기는 했지만 사실상 개발에 관련된 모든 주제가 이야기될 수 있으며, 개발 언어, 특정 라이브러리 및 프레임워크, 개발 관련 툴, Google I/O와 같은 각종 컨퍼런스 등 거의 모든 것이 저희의 관심사입니다. 심지어 한 번은 자주 쓰는 단축키에 대해서도 토의한 적이 있습니다. 어떤 목적을 갖고 만들어졌는가? 개발이라는 일은 특히나 최신 이슈에 민감한 분야인 것 같습니다. 빈번하게 일어나는 OS 업데이트와 그에 따른 이슈 처리, 주요 컨퍼런스 내용에 따른 개발 트렌드 변화, 갑작스레 혜성처럼 등장한 개발 라이브러리… 저희 개발자들은 이러한 이슈에 항상 귀를 기울여야 하며, 그에 대해 생각을 정리할 필요가 있습니다. 또한 이러한 기술 습득은 저희 직원들의 커리어에도 중요한 지표가 될 것은 자명하지요. 그러나 실제 업무에 집중하다 보면 자칫 이러한 이슈에 대해서 멀어지게 되고는 합니다. 숲을 보지 못하고 나무만 보는 꼴이랄까요. 모바일 스터디 그룹은 바로 이러한 점을 해결해보기 위해서 개설됐습니다. 적어도 1주일에 한 번씩은 업무에서 잠시 떨어져 다양한 개발 주제로 생각을 정리해보자는 게 이 스터디의 목적이며, 다재다능한 그룹원들의 참여 아래 훌륭하게 진행되고 있습니다. 어떻게 진행되고 있는가? 우선, 매주 월요일 점심마다 스터디가 진행되고 있습니다. (스터디를 할 경우 회사에서 점심을 제공하고 있어 회사의 모든 스터디 모임이 더욱 활성화되는 것 같습니다.) 스터디 주제는 1주일 전에 그룹원들과 이야기를 통해서 정하고 있고, 주제가 정해지면 자발적으로 주제에 대해 학습하며 자료를 공유합니다. 스터디 당일에는 일정 시간을 개별 학습하는 용도로 사용하고, 그 후에 각자 공부한 내용을 바탕으로 자기 생각을 이야기합니다. 기본적으로 상황에 맞게 자유롭게 진행되기 때문에 꼭 위와 같은 방식을 고수하지는 않습니다. 때로는 특정 주제에 대해서 스터디원이 세미나를 희망하기도 하는데, 이 경우 발표자가 자료를 만들어서 세미나를 진행하기도 합니다. 한 번 했던 주제에 대해서 다수가 흥미를 가질 경우 다음 주에 조금 더 깊이 있는 이야기를 나누거나 실제 실습을 해보는 시간을 갖기도 합니다. 아직 시도하지는 않았지만, 주요 컨퍼런스 영상을 보는 시간으로도 활용할 생각입니다. 어떤 주제를 진행했는가? 모든 주제를 나열할 수는 없지만, 대표적인 사례에 대해서 전달하겠습니다.  RxJava : Reactive 진영의 자바(Java) 라이브러리. 그 내부 원리와 구조 학습 Unit Test : JUnit 4, Mockito, Robolectric의 활용과 실전 예제 학습 Kotlin(코틀린) : 안드로이드(Android)에서의 Kotlin 트렌드 확인. Kotlin의 장단점 분석 MVP / MVVM : 안드로이드(Android) 아키텍쳐로 바라보는 MVP / MVVM의 내용 및 차이 학습  이 외에도 여러 주제에 대해서 지속해서 스터디를 진행했지만, 위 내용은 스터디원이 전체적으로 공감하고 도입 의지를 이끌었다는 점에서 인상적이었던 것 같습니다. 특히 코틀린과 같은 경우는 실험적으로 프로젝트에서 도입을 진행하고 있고, 코드 간결화, Null-Safety 측면에서 큰 장점을 느끼고 있습니다. 이처럼 저희 스터디는 학습하게 된 내용을 단순히 지식으로 놔두지 않고 실제 프로덕션에 도입까지 충분히 진행 할 수 있으며, 반대로 실제 프로덕션에 더 좋은 기술을 도입하기 위해서 다양한 주제를 찾아가고 있습니다.버즈빌의 스터디는 무엇이 다른가? 개인적으로 꽤 많은 스터디에 참여해 봤다고 생각합니다. 다양한 주제는 물론 강의형, 토론형 등 여러 방식으로 진행해본 경험이 있습니다. 그중에는 1년 넘게 유지되면서 다양한 지식을 습득한 모임도 있었고, 몇 번 해보지도 못하고 와해한 안타까운 케이스도 있었습니다. 덕분에 좋은 스터디란 무엇인가에 대해 꽤 고민을 해봤고 어떤 부분이 중요한지 나름대로 생각하고 있는 부분이 있습니다. 그리고 그러한 측면에서 버즈빌의 스터디는 좋은 스터디라고 분명히 말씀드릴 수 있습니다. 그렇다면 구체적으로 어떤 점이 버즈빌의 스터디를 좋게 만드는 것일까요? 그 이유는 다음과 같습니다. 첫째, 버즈빌의 수평적인 문화 버즈빌의 사내 문화는 수평적이고 자율적인 문화로 유명합니다. 소위 고루한 잔소리꾼 문화가 없기 때문에 자신의 의견을 누구나 자유롭게 이야기합니다. 사내문화가 스터디와 무슨 상관이 있냐 하실 수 있지만, 수직적인 조직의 사내 스터디와 비교했을 때 큰 차이를 볼 수 있었습니다. 버즈빌의 스터디에서는 여러 사람이 어떠한 권위에 눈치 보지 않고 자유롭게 자신의 의견을 제시하며, 듣는 이 또한 어느 의견이든 함부로 가늠하지 않고 진지하게 받아들입니다. 이는 단순히 스터디 토론에서만 적용 되는 것이 아니라, 스터디 시스템에 대해서도 불합리하거나 개선하고 싶은 점을 여과 없이 이야기합니다. 그리고 그들의 의견을 피드백하여 시스템이 지속적으로 개선되고 있습니다. 결국은 버즈빌의 수평적인 문화가 스터디 문화 자체도 현실적이고 합리적으로 바꿔나간다고 할 수 있습니다. 둘째, 뛰어난 구성원 스터디에서 구성원은 분명 굉장히 중요한 요소입니다. 구성원의 역량과 열정에 따라서 스터디의 질과 지속력이 결정됩니다. 그런 측면에서 버즈빌은 상당히 축복받은 조직임에 틀림없습니다. 당장 제 옆만 둘러봐도 어디서 이런 분들이 나왔을까 싶을 정도로 뛰어난 역량의 소유자가 많으니까요. 아마 인사팀에서 일을 잘하고 있나 봅니다. 여하튼, 버즈빌에는 다재다능한 인재가 정말 많습니다. 각종 분야에 있어서 상당한 지식을 보유하신 분도 굉장히 많으시고, 무엇보다 개발을 좋아하고 새로운 기술을 배우는 것에 긍정적입니다. 열정이 넘친 나머지 스스로 일정을 잡아서 기술 세미나를 진행하기도 하지요. 이런 분들과 함께 하는 스터디, 안 좋을 수가 없습니다. 셋째, No 강제, No 의무 제가 생각하는 좋은 스터디의 중요한 요소는 지속력입니다. 아무리 좋은 스터디라도 무리한 일정과 과제의 압박이 있다면 지속되기 힘들다고 생각합니다. 단발성으로 집중하여 어떤 지식을 습득하려는 게 아닌 이상은, 결국 얼마나 꾸준히 스터디원이 참여하고 공부를 할 수 있는지가 중요합니다. 그러한 측면에서 볼 때 참가를 강제하고, 어떠한 의무성인 과제를 부여하는 것은 지양해야 합니다. 공부는 스스로의 의지에 의해서 수행되어야 하며, 스터디 시스템에서 이를 강제 해봤자 결국은 보여주기 식의 활동밖에 되지 않습니다. 사람이 어떻게 모든 주제에 항상 열정적으로 공부를 하겠습니까. 그렇기에 스터디라는 시스템보다는 사람이 우선이어야 하며, 공부는 본인의 자유입니다. 위와 같은 요소로 인해 전 결론을 내봅니다. 버즈빌에서 굉장히 좋은 스터디를 하게 되었다고. 결론 버즈빌에서 스터디는 CEO 분들을 비롯하여 많은 구성원이 장려하고 권장하는 부분입니다. 그들은 직원의 역량 강화가 곧 회사 역량의 강화라는 인식을 바로 갖고 있으며, 이를 위해 정책적으로 지원하는 방안을 마련해주고 있습니다. 스터디 제도뿐만 아니라 각 개인이 성장할 수 있도록 동아리 지원, 자기개발비 지원 등은 물론 읽고 싶은 책은 무제한으로 제공 해주고 있습니다. 어쩌면 이러한 사소한 점 하나하나가 버즈빌의 소중한 자산이 아닐까 생각하며, 이만 글을 마무리 짓습니다. 감사합니다.작가소개 Ethan Yoo, Software Engineer (Android) 안녕하세요. 버즈빌에서 안드로이드 부분 개발을 담당하고 있는 Ethan (이든)입니다. 개발이라는 주제로 다양한 곳에 관심사를 갖고 있고, 동료와 함께 개발 이야기를 하는 것을 좋아합니다. 메인 언어는 자바(Java)를 사용하고 있지만, 코틀린(Kotlin) / 파이썬(Python) / 자바스크립트(JavaScript) / 하스켈(Haskell) 등 다양한 언어에 대해 경험이 있습니다. 최근에는 시스템 아키텍쳐에 관심을 갖고 반응형 프로그래밍, 함수형 프로그래밍 등이 안드로이드와 어떤 구조로 표현 될 수 있을지 고민하곤 합니다. 제가 만든 서비스가 세상을 바꿀 수 있기를 희망하고, 이를 위해 버즈빌에서 오늘도 열심히 개발을 하고 있습니다.

최근 Xcode 9.3 버전이 배포되었습니다. 이 버전에는 가장 최신의 Swift 4.1 버전이 포함되어 있습니다. Swift 4.1에는 여러 흥미로운 개선사항들이 많지만, 치명적인 버그도 존재합니다. 바로 딥링크를 통해 앱을 여는 경우 크래시가 발생하는 문제입니다. StyleShare에서는 QA 과정을 통해 문제를 발견할 수 있었습니다.만약 여러분의 애플리케이션이 아래 조건을 모두 충족할 경우 문제가 발생합니다:Swift 4.1 버전을 이용해서 빌드한 경우Deployment Target이 iOS 11.0 미만인 경우AppDelegate에서 application(_:open:sourceApplication:annotation:) 메서드를 구현한 경우문제를 재현하기에 가장 좋은 방법은 Safari 앱을 이용하는 것입니다.1. iOS 기기 또는 사뮬레이터에서 Safari 앱을 구동합니다.2. 주소 입력란에 앱이 지원하는 딥링크 URL을 입력한 뒤 이동합니다. (e.g. myapp://)3. 앱이 구동됨과 동시에 강제 종료됩니다.이 버그는 Swift 이슈 트래커에 SR-7240 티켓으로 이미 등록되어 있습니다. Resolved 상태로 표시되지만 이번 Xcode 9.3 버전에는 포함되지 않은 것으로 보입니다. 다행히 댓글에 한 개발자가 문제를 해결할 수 있는 workaround를 공유해두었는데요. 이 방법을 이용하면 당장의 문제는 해결할 수 있습니다. AppDelegate 메서드의 annotation 파라미터의 타입을 Any에서 Any?로 변경하는 것입니다.- func application(_ application: UIApplication, open url: URL, sourceApplication: String?, annotation: Any) -> Bool + func application(_ application: UIApplication, open url: URL, sourceApplication: String?, annotation: Any?) -> Bool<iframe width="700" height="250" data-src="/media/0ce1fe8c63fca7a6c953233b94406d02?postId=ed495077c36" data-media-id="0ce1fe8c63fca7a6c953233b94406d02" data-thumbnail="https://i.embed.ly/1/image?url=https://avatars2.githubusercontent.com/u/931655?s=400&v=4&key=a19fcc184b9711e1b4764040d3dc5c07" class="progressiveMedia-iframe js-progressiveMedia-iframe" allowfullscreen="" frameborder="0" src="https://medium.com/media/0ce1fe8c63fca7a6c953233b94406d02?postId=ed495077c36" style="display: block; position: absolute; margin: auto; max-width: 100%; box-sizing: border-box; transform: translateZ(0px); top: 0px; left: 0px; width: 700px; height: 100px;">UIApplicationDelegate에 정의된 메서드 시그니쳐와 다르기 때문에 컴파일러가 경고를 표시하지만 무시하셔도 됩니다.만약 새로운 버전의 앱을 릴리즈 할 계획을 가지고 계시다면 이 이슈를 꼭 확인하시길 바랍니다. 이 버그는 페이스북 로그인 등 다른 앱을 이용한 로그인이나, 카드 결제 후 주문서로 돌아오는 흐름에서 큰 문제를 일으킵니다. 이 글이 여러분들께 도움이 되길 바랍니다.Swift Korea 그룹에서 Xcode Release Notes에도 같은 내용이 있다는 것을 제보해주셨습니다. Swift Compiler 섹션의 Known Issues 4번째 항목입니다.#스타일쉐어 #개발팀 #개발자 #개발후기 #경험공유 #인사이트

스푼을 만드는 사람들 다섯 번째 이야기클라이언트팀의 유일한 여성 개발자 Julia를 소개하고자 한다.바나나 최대 몇 개까지 드세요?"마케팅팀 썸머에겐 아귀찜이 있다면, 저에겐 '바나나'입니다. 저는 바나나 우유도 좋아하고, 바나나 한 송이를 그 자리에서 혼자 다 먹을 만큼 좋아해요. 카카오톡 이모티콘도 바나나 이모티콘을 가장 많이 사용할 정도로요. 바나나는 맛도 있지만, 먹으면 기분이 좋아지는 과일이에요"(인터뷰 후, 줄리아에게 바나나 한 다발 선물해드렸습니다. 맛있게 드셨길 바라요)Q. 할머니 감성을 가지셨다고 들었는데, 사실인가요? "네, 모르시는 분들이 많으시겠지만 저는 친구들이 '할머니'라고 불러줘요. 이유인즉슨, 건강에 관심이 워낙 많아서 영양제도 잘 챙겨 먹고 꽃무늬 옷이 많거든요. 정확히 말하면 꽃무늬 치마! 그리고 사석에서는 고향(전라도) 사투리를 많이 써서 그런 것 같아요"줄리아 닮은꼴: 닥터 슬럼프 아리 '줄리아'를 더 알아가고 싶어요본인은 어떤 사람이라고 생각하세요?독한 사람 - 저는 웬만한 것에 있어서 타의적으로 절대 포기를 하지 않아요. 제 스스로가 싫증이 날 때까지는 꼭 끝까지 해내고 말거든요.그래서 전 제 스스로를 독한 사람이라고 말하고 싶어요. 이전부터 개발자로서 커리어를 쌓아오셨나요?"저는 원래 문과생이에요. 비전공자죠. 대학 때 독어를 전공했고, 개발과는 사실 거리가 먼 사람이었어요. 저는 이 전에 많은 경험들을 해왔어요. 세계일주를 하고 싶어서 해상 승무원 준비도 했었고, 중국에서 무역회사에서 근무도 했었고요. 통역도 잠시 했었고, 이 전에는 앱 공모전 기획자로서의 삶도 있었어요. 앱 공모전 기획자라는 건, 회사 및 대회를 홍보하기 위해 직원 대상 또는 시민을 대상으로 행사 및 공모전을 기획해서 행사업체를 고용하거나 직접 운영하는 업무랍니다. 그리고 현재는 안드로이드 개발자로 커리어를 쌓고 있습니다."많은 커리어를 거쳐 개발자가 되신 계기가 있다면?"저는 인생 계획을 짧으면 5년, 길게는 10년씩 잡고 살아가요. 20대 때는 해보고 싶은 게 너무 많았고, 지금도 여전히 많아요. 그래서 20대는 정말 하고 싶은 모든 걸 해보자라는 마음으로 살아왔어요. 30대가 되면서 조금 더 안정적으로 살고픈 마음이 생기기 시작했고 무엇보다 하나의 전문적인 직업을 가지고 싶단 욕구가 커졌어요. 그래서 개발을 선택하게 되었습니다."책상에 약이 굉장히 많네요?"제가 아까 할머니 감성이 있다고 했는데.. 저는 건강을 엄청 챙기거든요.. 그래서 탕비실에도 돼지감자 차 및 영양제 등 굉장히 뭘 많이 챙겨 먹습니다. 그래서 제 책상엔 비타민 등 영양제가 가득하답니다!"집에서 가져온다는 돼지감자 차 당신의 회사생활이 궁금합니다Q. 여성 개발자로 일하는 삶은 어떤가요?"사실 저는 '개발'을 하는 일을 성별로 나누고 싶지는 않아요. 남자 개발자가 많은 이유는 아무래도 공대에 남성 비율이 더 많기 때문이라고 생각이 들기도 하고, '여자' 이기에 특별히 다르다거나 불편한 점은 없어요. 아직은 신입 개발자이다 보니, 배우고 있는 시점이기도 하고요. 그저 열심히 배우는 단계라고 봐주시면 좋을 것 같습니다 :) 무엇보다 제 위로 8년 차, 14년 차 선배분들과 함께 일하면서 정말 많이 배우고 있습니다."Q. 일하면서 언제가 가장 뿌듯하세요?"개발을 하시는 분들은 공감하실 텐데.. 안되던 문제가 갑자기 될 때(?)에요. 분명히 어제는 안됐는데, 오늘은 되는 날이 있거든요. 반대인 경우도 있고요. 그때 정말 뿌듯(?)하고 행복해요. 또 다른 하나는, 보통 다른 곳은 신입 개발자는 보조만 하는 경우가 많거든요. 하지만 팀원들이 저를 믿어주셔서 제가 새로운 기능을 맡아서 짠 추가 코드가 프로덕트에 적용이 될 때가 정말 뿌듯해요."Q. 회사 다니면서 가장 기억에 남는 일이 있다면?"제가 입사 후 함께 처음으로 새로운 국가에 출시했을 때요. 저는 새로운 국가에 서비스를 출시할 때마다 너무 기대되고 업무가 더 즐거워져요. 조금 더 다양한 업무가 주어지고, 생각도 더 많이 하게 되거든요. 그리고 저는 건강에 정말 신경 많이 쓰는데, 저번에 Jun 이 막내 특집(?)으로 홍삼 음료를 주셨는데.. 너무 취향 저격인 거예요. 딱 제가 정말 좋아하는 건강한 맛! 그래서 그날도 너무 행복했어요."Q. 어떤 사람과 일하고 싶으세요?배울 점이 있는 사람이요. 저 또한 누군가에게 배울 점이 있는 사람이고 싶어요.줄리아 업무 공간 당신의 사생활이 궁금합니다Q. 안드로이드 개발자는 안드로이드만 사용하나요?"모두가 그런 건 아니겠지만, 저는 사실 여태 살면서 안드로이드 폰만 사용했었어요. 무엇보다 저는 안드로이드 캐릭터가 너무 귀엽다고 생각하기에.."Q. 주말에는 무엇을 하며 시간을 보내세요?"저는 지난 1년간은 매주 주말마다 코딩 스터디를 해왔어요. 아무래도 비전공자에 늦게 시작한 개발자다 보니 엄청난 노력이 필요하거든요. 지금도 스터디를 하고 있어요. 그리고 2019년부터 목표는 한 달에 한 번쯤은 리프레쉬하기 위해 가까운 곳이라도 여행을 가려고 노력하고 있어요."Q. 개발자가 된 후 삶에 있어 변한 점이 있다면?"예전에는 어떤 것을 설명하거나 표현할 때, 굉장히 문과적(?) 이게 표현을 했었던 것 같아요. 지금도 완전히 바뀌진 않았어요. 하지만, 무언가 문제가 있을 때 원인과 결과를 먼저 파악하는 성향이 생겼달까요? 그리고 편견일 수도 있지만 조금 더 프로페셔녈 해 보이고 싶어서 백팩이나 후디를 자주 입습니다!" 비전공자로서 개발자를 꿈꾸는 사람들에게 "먼저, 비전공자라 하여 못할 거라는 생각을 하지 않으셨으면 좋겠어요. 저도 여전히 배우고 있는 입장이지만 생각보다 비전공자 중에 개발자로서 훌륭하신 분이 굉장히 많거든요. 늦더라도 정말 하고 싶은 마음이 있다면 꼭 도전하라고 말하고 싶어요. 그리고 꼭 영어 공부하세요. 아무래도 문서들이 영어로 되어있으니, 영어를 배워두면 번역기의 도움이 없이도 되기에 큰 도움이 되고 시간이 절약되거든요! 아, 그리고 개발을 배우고자 만약 학원에 가서 수업을 들을 예정이시라면, 수업을 듣기 전에 혼자라도 미리 예습을 하고 가셨으면 좋겠어요. 학원을 다닌다고 해서 정말 모든 걸 알려주진 않거든요. 얼마나 열심히 하고 노력하느냐에 따라 성패가 달린다고 생각합니다."안드로이드 팀원들이 줄리아를 한마디로 표현한다면?Derek 曰:  “줄리아는 강한 사람이라고 생각합니다. 외부의 환경에 흔들리지 않고 자신의 꿈을 향해 계속 전진하는 강한 사람이라고 생각합니다.”Yong 曰:  "낯선 길에서 의지를 잃지 않고 가고자 하는 길을 걷는 사람, 그리고 미소가 예뻐서 꽃 같은 사람입니다" 

좋은 개발자 소개해주세요.많은 기업 관계자분들을 만나면서 항상 듣는 말이다. 스타트업에 있어서 인재 채용이 항상 문제기는 하지만, 이것은 비단 스타트업에만 국한되지는 않은 것 같다. 지난 코드스테이츠 데모데이 때는 카카오와 SK텔레콤 같은 대기업과 더불어 스마트스터디, 데일리호텔 기업 관계자분도 참여해 주셨다. 이것을 보면 대기업이든, 규모가 꽤 있는 기업이든 좋은 개발자를 찾는 것은 어려운 것 같다.기업들이 이런 말을 하는 것을 보면 개발자를 찾는 수요는 빠르게 증가하고 있는데, 기업들의 입맛을 맞추면서 개발을 할 수 있는 '좋은 개발자'는 많이 없는 듯하다. 이런 상황에서 코딩 교육 스타트업 코드스테이츠가 많은 기업 관계자분과 개발자분들을 만나고 코딩 교육을 하면서 느낀 점을 통해 어떤 개발자가 좋은 개발자인지에 대하 포스팅을 하려 한다.이것을 통해 좋은 개발자라는 개념을 구체화할 것이다. 좋다는 개념을 명확히 해서 어떤 것들이 좋아야 좋은 개발자인지, 또 소위 말하는 좋은 개발자가 되기 위해서 어떤 노력들을 해야 하는지 글로 풀어갈 것이다. Good Developer 시리즈 첫 번째 포스팅, 좋은 개발자의 5가지 기준좋은 개발자의 5가지 기준좋은 개발자에 대한 생각은 개인마다 또 기업마다 다를 것이다. 아래의 기준들은 많은 기업 관계자분들과 개발자분들을 만나고, 코드스테이츠가 교육을 하면서 느낀 좋은 개발자의 기준들이다. 아래의 조건들이 좋은 개발자의 충분조건이라고 할 수는 없지만, 필요조건이라고는 할 수 있을 것 같다. 코드, 생산성, 커뮤니케이션, 학습, 관리 능력 이 5가지 관점을 통해 어떤 개발자가 좋은 개발자인지 알아보자.1. 코드의 리딩과 라이팅좋은 코드를 짤 수 있는 역량은 좋은 개발자가 되기 위한 필수적인 기준이다. 하지만, 대부분의 개발자들에게 어떻게 하면 좋은 코드를 짤 수 있는지 물어보면 쉽게 답하는 사람은 많지 않다. 그래서 구체적으로 어떤 능력이 있어야 좋은 코드를 짤 수 있는지, 코드의 리딩과 라이팅의 관점에서 살펴보고자 한다.많은 주니어 개발자들이 처음 회사에 입사해서 해야 하는 것 중 하나는 코드의 리딩(reading)이다. 자신이 처음으로 개발을 시작하지 않는 이상 이미 개발된 소스들을 보고 어떻게 동작하는지 또 변수, 함수, 메서드들의 네이밍(Naming)은 어떤 식으로 하고 있는지 파악해야 한다.코드의 리딩 능력은 업무 환경에 적응하는 능력과는 별개로 자신의 업무를 파악하고 또 다른 사람과 커뮤니케이션할 때 매우 중요하다.  그리고 코드를 잘 읽으면 어디가 잘못되어 있는지, 어떻게 고쳐야 하는지 쉽게 파악할 수 있다. 그리고 이것이 코드를 잘 짤 수 있는 역량으로도 직결된다.리딩 능력과 더불어서 중요한 것이 바로 코드 라이팅(writing) 능력이다. 라이팅은 코드를 잘 짜는 것과 별개로 네이밍(Naming)을 잘하고 이해하기 쉽게 코드를 쓰는 것을 의미한다. 코드 리딩 능력이 뛰어나지 않은 개발자라도 잘 정돈되고 직관적으로 네이밍 되어 있는 코드들을 보면 쉽게 읽을 수 있다.코드 라이팅 능력은 협업하고 코드를 구조화하는 과정에서 매우 중요하다. 코드 라이팅 능력이 떨어진다면 다른 사람이 자신의 코드를 이해하는데 오랜 시간을 소모하게 만들 뿐만 아니라 나중에 가서는 자신조차 자신의 코드를 이해하는데 오랜 시간이 걸릴 수 있다. 이렇기 때문에 안정된 코드, 돌아가는 코드를 짜는 것과 별개로 다른 사람과 자신이 이해하기 쉬운 코드를 짜는 능력은 매우 중요하다.좋은 코드를 짜기 위해서는 다른 사람이 어떤 코드를 짰는지 알아야 하고 내 코드를 다른 사람들이 쉽게 읽을 수 있도록 해야 한다. 개발자는 결국 코드로 말한다. 코드 라이팅 능력이 떨어진다는 것은 코드로 '잘' 말하지 못한다는 것을 의미한다. 또 코드 리딩 능력이 떨어진다는 것은 다른 개발자가 코드로 말하는 것을 '잘' 듣지 못한다는 것을 뜻한다. 좋은 개발자의 조건으로 항상 따라붙는 좋은 코드를 짜는 방법은 코드 리딩과 라이팅 능력이 선행되었을 때 가능할 것이다.2. 빠른 생산성좋은 코드를 짜는 것이 좋은 개발자가 되는데 중요한 조건이기는 하지만 유일한 조건은 아니다. 개발은 필연적으로 시간과의 싸움이다. 그래서 좋은 개발자의 조건 중 하나가 바로 생산성이다. 우리나라의 많은 개발자들이 야근에 시달리는 것도 결국은 생산성과 연결되어 있다.(물론 조직문화도 크게 작용한다. 그리고 CEO의 마인드도...)안정적이고 완벽한 코드를 짜는 것도 중요하지만 때로는 시간과 타협해서 돌아가는 코드를 짜는 것만으로 만족해야 할 때가 있다. 특히, 리소스가 부족한 스타트업에서는 시간이 생명이다. 환상적인 코드를 짤 수 있는 개발자라 할지라도 그 시간이 천년만년 걸린다면 당장 돌아갈 수 있는 코드를 돌릴 수 있는 개발자 보다 좋은 개발자라고 하기 힘들 것이다.투입한 시간 대비 얼마만큼의 코드 생산성이 나오는가? 시간이 생명인 많은 스타트업에서는 안정적이고 완성도 높은 코드를 짜는 개발자보다 생산성 높은 개발자를 선호할 가능성이 크다. 첫 번째 기준인 코드 리딩과 라이팅 능력에서 자신이 없다고 걱정할 것 없다. 자신의 코드 생산성이 좋다면 좋은 개발자로서의 중요한 기준을 하나를 충족한 셈이니까.3. 원활한 커뮤니케이션위의 두 가지 기준이 개발 자체에 대한 능력이었다면, 커뮤니케이션 능력은 다른 사람과 협업하는 능력에 대한 기준이다. 혼자서 개발하는 개발자는 극히 드물다. 코딩 = 개발이 아니다. 코딩은 개발의 한 과정이며 개발을 할 때에는 다른 구성원들과 수많은 상호작용을 해야 한다. 왜냐하면 개발자는 결국 사람들과 일하기 때문이다.그래서 많은 기업들이 개발자를 채용하는 기준에서 '원활한' 커뮤니케이션을 내세운다. 개발과 관련 없을 것 같은 커뮤니케이션은 사실 엄청나게 중요하다! 커뮤니케이션 문제로 발생하는 비용 문제(단순히 돈이 아니다.)는 상당하다.어느 정도 개발 경험이 있는 사람은 누구나 공감할 수 있을 것이다. 같이 일하고 싶은 개발자와 아닌 개발자가 있다는 사실을 말이다. 단지 사람이 좋고 나쁨을 떠나서, 대화를 하는데 숨이 턱 막히는 사람이 있고 대화를 하면 할수록 막혔던 부분이 풀리거나 새로운 아이디어를 떠오르게 만다는 사람이 있다.원활한 커뮤니케이션은 사실 어느 직군에나 해당되는 말이지만, 개발처럼 한 가지 테스크에 여러 사람이 집중적으로 달려드는 업무에 있어서 그 중요성이 더 부각된다. 당신은 원활한 커뮤니케이션 능력을 가지고 있는가?4. 업무 관리, 사람 관리 능력업무 관리와 사람 관리는 사실 개발자 직군에 국한된 역량이 아니라 모든 직군에서 필요로 하는 역량이다. 개발에 치중해야 할 개발자가 좋은 개발자가 되기 위해 이런 것들까지 신경 써야 할 이유는 무엇일까? 위에서도 언급했지만, 개발 = 코딩이 아니다. 개발을 한다는 것은 테스크를 나눠 할당하고 기간에 맞춰 완성시키는 일이다. 이 과정에서 필요한 상호작용, 업무 관리, 생산성이 모두 개발의 과정이다.업무 관리와 사람 관리를 잘 하는 사람은 막말로 그냥 일 잘 하는 사람이다. 좋은 코더가 아니라 좋은 개발자가 된다는 것은 일을 잘하는 사람이 되어야 한다는 뜻이다. 업무 관리는 테스크를 나누고 할당하고 데드라인을 설정하는 일이 아니더라도 나에게 주어진 테스크에 대해 스스로 관리하는 능력까지 포함한다. 결국 자신의 업무 관리를 잘하는 사람은 생산성에서 두각을 나타내리라.주니어 때 좋은 개발자로 인정받고 연차가 쌓이면 시니어가 되고 관리자 직급으로 올라갈 가능성이 크다. 이때 주니어 때 좋은 개발자였다고 시니어 개발자일 때도 좋은 개발자일 거란 보장은 없다. 시니어가 돼서도 좋은 개발자가 되고 싶다면 업무 관리와 사람 관리하는 능력이 필수적이다. 특히, 한국에서는 개발자의 종착지는 관리자일 정도로 연차가 많은 사람이 개발을 하고 있는 경우는 극히 드물다. 이런 상황에서 좋은 개발자로 인정받아 마지막까지 살아남기(?) 위해서는 이 두 가지 능력이 필수적이다.5. 지속적인 학습위에서 제시한 네 가지 능력이 모두 없다고 실망할 것 없다. 좋은 개발자가 되기 위하 마지막 조건, 지속적인 학습이 있기 때문이다. 지속적인 학습은 좋은 개발자가 계속해서 좋은 개발자로 남을 수 있게 만들어주고 일반 개발자가 좋은 개발자가 될 수 있게 만들어주는 중요한 조건이다.개발은 빠르게 변한다. 모든 직군 중에서 가장 학습을 많이 해야 하는 직군을 뽑으라면 자신 있게 개발자라 말할 수 있다. 빠르게 변화하는 환경 속에서 지금 좋은 개발자라 해서 몇 년 후에도 좋은 개발자라고 단정 지을 수 없다. 개발자는 숙명적으로 끊임없이 배워야만 한다. 좋은 개발자가 되기 위해서는 더더욱.지속적으로 배운다는 것이 단순히 새로운 것을 익히고 지식의 지평을 확대해 나간다는 것만을 의미하지 않는다. 지금 현재 소위 나쁜 개발자(코드 퀄리티, 생산성, 커뮤니케이션, 관리능력 모두 떨어지는 개발자)가 블록체인 신기술을 배운다고 해서 좋은 개발자가 되겠는가? 즉, 코딩 지식에 대한 고민뿐만 아니라 위에서 언급한 네 가지 기준에 대한 학습도 필요하다.학습에 측면에서 많은 분들이 간과하고 있는 것이 지식의 질이다. 단순히 지식의 양적인 측면에만 매몰되면 깊이 있는 지식을 얻기 힘들기 때문이다. 물론, 현재의 시대적 흐름을 읽고 최신 트렌드 기술을 습득하는 것은 중요하다. 하지만 그보다 더 중요한 것은 자신이 알고 있는 지식들을 깊이 있게 아는 것이다. 끊임없는 학습, 그리고 깊이 있는 학습만이 좋은 개발자를 계속해서 좋은 개발자로 만들어 준다.좋은 개발자를 위해지금까지 좋은 개발자를 위한 5가지 조건에 대해 알아 보았다. 코드 리딩과 라이팅, 생산성, 커뮤니케이션, 사람과 업무 관리 그리고 지속적인 학습. 이외에도 중요한 조건들이 많지만 많은 개발자를 만나고 교육해오면서 가장 필요하다고 생각하는 5가지 조건을 적어보았다.개발자가 되는 것은 쉽지 않다. 좋은 개발자가 되는 것은 더더욱 쉽지 않다. 좋은 개발자를 양성하기 위해 노력하는 교육 스타트업으로써 어떤 개발자가 좋은 개발자인지 파악하기 위해 항상 노력 중이다. 이 노력을 코드스테이츠만 알고 있는 것이 아니라 다른 분들에게도 공유드리고 싶다. Good Developer 포스팅을 통해 어떤 개발자가 좋은 개발자인지 또 좋은 개발자가 되기 위해서는 어떻게 해야 하는지 이야기할 예정이다. 좋은 개발자의 길은 멀지만 Good Developer를 통해 한층 쉽게 걸어갈 수 있었으면 좋겠다.

새로운 IT 기술의 등장과 기업 환경의 변화로 새로운 과학 경영 기법들이 비즈니스 유행어처럼 등장하고 사라지지만 그 가운데서도 변하지 않는 것이 있다면 프로세스 개선과 관련된 대한 끊임없는 노력과 관심일 것입니다.프로세스 마이닝은 이벤트 로그를 기반으로 비즈니스 프로세스를 분석할 수 있는 프로세스 관리 기술입니다. 정보 시스템에서 기록한 이벤트 로그에 포함된 패턴 및 세부 정보를 식별하기 위해 별도의 분석 알고리즘이 이벤트 로그 데이터에 적용됩니다. 프로세스 마이닝은 프로세스의 효율성과 이해를 향상시키는 것을 목표로 하며, “자동화된 비즈니스 프로세스 발견” ABPD (Automated Business Process Discovery)이라는 좀 더 일반화된 명칭으로 불리기도 합니다.이러한 프로세스 마이닝은 어디서 갑자기 나온 개념은 아니고 기존 비즈니스 프로세스 관리 기법에 대한 연구와 데이터 분석 기술이 합쳐져서 나온 산물이기에 “비즈니스 프로세스”와 관련된 기술들을 살펴보고 프로세스 마이닝과의 연관성을 찾아보고자 합니다.BPM (Business Process Management)프로세스 마이닝은 일반적으로 BPM과 데이터 마이닝이 겹치는 중간 영역에 위치합니다.BPM은 비즈니스 프로세스를 발견, 모델링, 분석, 측정, 개선, 최적화 및 자동화하기 위해 다양한 방법을 사용하는 운영 관리 기법을 의미하며, 프로세스를 관리하여 기업 성과를 향상시키는 데 중점을 둡니다. 좁은 의미에서 BPM은 업무 프로세스를 사전에 모델링하고, 설계된 프로세스 대로 업무 결제, 승인, 구매 등의 업무 등이 자동화되어 흘러갈 수 있도록 도와주는 IT 시스템을 지칭하기도 합니다..BPM은 Top-Down 방식으로 프로세스 모델을 그려서, 해당 프로세스 모델 대로 업무를 수행하도록 강제하는 방식이라면 프로세스 마이닝은 이미 수행된 업무로부터 프로세스 모델을 도출하는 Bottom-up 방식을 따릅니다.  하지만 점점 복잡해져 가는 기업 업무 활동을 BPM처럼 중앙 집권적 방식으로 모든 것을 통제하기에는 한계가 있습니다.  BPM의 통제를 벗어난 다양한 여러 시스템을 업무 관점에서 통합적으로 관리하고 모니터링하기 위해서는 개별 시스템은 그대로 두고 이로부터 쏟아져 나오는 로그를 통해 프로세스를 관리하는 분권적 방식이 BPM의 한계를 보완하는 역할을 합니다. RPA (Robot Process Automation)로봇 프로세스 자동화 (RPA)는 소프트웨어 로봇 또는 AI (인공 지능) 작업자의 개념을 기반으로 하는 사무 자동화 기술의 새로운 형태입니다.소프트웨어 '로봇'은 컴퓨터 시스템의 사용자 인터페이스와 상호 작용하는 인간의 행동을 복제하는 소프트웨어 응용 프로그램입니다. 예를 들어, ERP 시스템에 데이터 입력을 실행하거나 실제로 비즈니스 프로세스를 수행하는 것이 소프트웨어 로봇의 일반적인 활동이 될 것입니다. 소프트웨어 로봇은 사람과 동일한 방식으로 사용자 인터페이스(UI)에서 작동합니다. 이것은 기존에 애플리케이션 프로그래밍 인터페이스(API)에 기반한 전통적 형태의 IT 통합과 크게 다릅니다. 즉, 사용자 인터페이스의 데이터 아키텍처 계층을 기반으로 한 기계 간(machine-to-machine) 통신 형태를 취합니다.앞서 언급한 BPM이 프로세스 개선을 위해 프로세스 자체를 재설계하고 변경하려는 방식이라면 RPA는 사람이 하던 현재 방식을 그대로 모방하여 소프트웨어로 대체하여 자동화하는 방식입니다. 이러한 RPA가 업무에 더 많이 적용될 수록 더 많은 시스템 로그가 나올 것이고 이에 대한 성과 분석과 모니터링이 필요해질 것입니다. 프로세스 마이닝은 RPA 도입 전 초기 단계에 전체 프로세스를 분석하여 RPA가 적용될 만한 구간을 식별하여 타당성을 검증하고, RPA 도입 이후의 전후 비교를 통해 지속적으로 업무 효율성을 측정할 수 있는 방법을 제공합니다.앞서 살펴본 것처럼 BPM, RPA, Process Mining 이 세 가지는 서로의 영역을 다투는 것이 아니라 상호 보완적인 존재로 볼 수 있습니다.프로세스 마이닝은 “프로세스”와 관련된 다양한 시스템과 활동들에 대해서 데이터에 근거한 현재 프로세스의 모델링 및 성과 측정 방법을 제공합니다. 이를 통해 과거 혹은 신규 프로세스 혁신 기법들과 맞물려 해당 시스템 및 방법론이 성공적으로 수행될 수 있도록 자동화된 “업무 조언자” 역할을 수행하게 됩니다. [참고 자료]https://en.wikipedia.org/wiki/Business_process_managementhttps://en.wikipedia.org/wiki/Robotic_process_automationhttps://www.minit.io/blog/robotic-process-automation-and-process-mininghttps://medium.com/towards-data-science/unleash-the-value-of-process-mining-4e3b5af4e9d8http://www.cdevworkflow.com/bpm-life-cycle/https://www.uipath.com/blog/the-robotic-process-automation-infographic#퍼즐데이터 #개발팀 #개발자 #개발후기 #인사이트

1. 스타트업이라고 테스트를 생략해도 되는건 아니다. 테스트코드는 부가적인 코드가 아니라 제품에 포함되는 코드다. 테스트 없이 코드만 있는 제품은 디바 궁터지는거 바라보고 있는 격.2. 정기적으로 개발문서를 업데이트하지 못할꺼 같으면, 아예 만들지 말자. 차라리 그시간에 테스트 코드를 읽기좋게 짜서 개발문서로 활용할 수 있게 하자. 예제는 최고의 개발문서다.3. 많은 곳에서 디자인 패턴을 과하게 쓰지 말라고 조언하는데, 이게 쓰지 말라는 뜻이 아니다. 쓸 곳에는 쓰자. 제발.4. js 개발자에게 라이브러리를 잘 다루는 것은 중요하다. 그러나 그보다 더 중요한 건 js 그 자체를 잘 다루는 것이다. js 좀 공부하자..!5. 짝코딩하자. 너와 내가 만나면 더하기가 아니라 곱하기다.#플레이팅 #개발자 #개발 #인사이트 #꿀팁 #조언

레진엔터테인먼트는 글로벌(한국, 일본, 미국) 서비스를 운영하고 있기에 다양한 사람들의 재능과 욕구에 관심이 있습니다. 우리는 웹 접근성에 관심을 기울여 조금 특별한 욕구를 가진 사람들의 문제를 해결하려고 합니다. 소수의 특별한 욕구는 모두의 욕구와 연결되어 있다고 생각하기 때문입니다.조금 특별한 욕구를 가진 사람WHO는 세계 인구의 15%에 해당하는 사람들이 장애가 있는 것으로 파악하고 있습니다. 그리고 보건복지부 장애인 실태조사에 따르면 후천적 장애 발생률은 90% 수준입니다. 이런 통계에 따르면 한 개인이 일생을 살면서 장애인이 되거나 일시적으로 장애를 체험하게 될 확률은 무려 13.5%나 됩니다.저는 적록 색약입니다. 약한 수준의 장애로 분류할 수 있죠. 채도가 낮은 상태의 적색과 녹색을 쉽게 구별하지 못합니다. 충전 중 적색이었다가 완충이 되면 초록색으로 변하는 LED가 박혀있는 전자제품은 전부 망했으면 개선하면 좋겠어요. 전 세계 남성의 8%가 색약이고, 여성은 0.5%가 색약입니다. 대부분 적록 색약이고 마크 저커버그도 적록 색약입니다. 만화가 이현세 선생님도 적록 색약이고요. 한편 색약인 사람은 빛의 밝고 어두움을 구별하는 능력이 뛰어난 것으로 밝혀져 있어 저격과 관측에 탁월한 능력을 발휘합니다. 숨어있는 저격수 빨리 찾기 게임을 해 보세요. 위장 사진 1, 위장 사진 2, 위장 사진 3. 색약인 사람이 이길 것입니다.전맹 시각장애인은 마우스 포인터와 초점을 볼 수 없으므로 키보드만을 사용해서 웹을 탐색합니다. 키보드와 음성 낭독에 의존하지만, 키보드 기능을 정말 잘 다루죠. 그래서 키보드 접근성 문제를 해결하면 시각장애인뿐만 아니라 키보드를 능숙하게 사용하는 사람들의 사용성이 높아집니다. 소수의 특별한 요구사항을 해결하는 것이 모두를 위한 설계와 연결되어 있습니다.결국, 누구에게나 특별히 다른 측면이 있고 그것을 고려할 때 "모두를 즐겁게 하라!"라는 우리의 좌우명에 한 걸음 더 가까워질 수 있다고 믿습니다.도저히 풀 수 없을 것 같은 숙제웹 접근성을 소개할 때 많이 듣는 질문이 있습니다.장애인이 우리 서비스를 이용해요?매출에 도움이 돼요?시간과 비용이 많이 필요하지 않아요?이 질문에 대한 제 대답은 다음과 같습니다.이용한다면 기쁠 것 같아요.큰 도움은 안 될 거예요.조금은 그렇죠. 하지만 반환이 있어요.레진코믹스와 같이 이미지 기반의 콘텐츠를 서비스하는데 웹 접근성을 준수하려고 노력한다는 것은 무모한 도전에 가깝습니다. 왜냐하면, 현재로서는 전맹 시각장애인 고려가 없고 논의조차 쉽지 않기 때문입니다.하지만 달에 갈 수 없다고 해서 일찌감치 체념할 필요는 없겠지요. 쉬운 문제부터 하나씩 풀어 나아가길 기대합니다. 로켓에 올라탔으니까 금방 갈 수 있지 않을까요?W3C 표준을 우리 언어로W3C에서는 WCAG 2.1이라는 웹 콘텐츠 접근성 지침을 제시하고 있고요. 국내 표준 KWCAG 2.1 또한 있습니다. 국내 표준은 W3C 표준에서 중요도가 높은 항목을 우리 언어로 정리한 것이기 때문에 결국 어떤 지침을 선택해서 따르더라도 괜찮습니다.하지만 표준 문서는 너무 장황하고 전문 용어가 많아 다양한 분야 전문성을 가진 직원들과 함께 보기에는 한계가 있다고 생각했습니다. W3C 표준을 근간으로 하되 비전문가도 15분 정도면 읽고 이해할 수 있을 만큼 정리된 문서가 필요했고 레진 웹 접근성 가이드라인 사내 표준을 제안하고 공개하게 됐습니다.의미를 전달하고 있는 이미지에 대체 텍스트를 제공한다.전경 콘텐츠와 배경은 4.5:1 이상의 명도 대비를 유지한다.화면을 400%까지 확대할 수 있다.키보드만으로 조작할 수 있다.사용할 수 있는 충분한 시간을 제공한다.발작을 유발하는 콘텐츠를 제공하지 않는다.반복되는 콘텐츠 블록을 건너뛸 수 있다.모든 문서의 제목은 고유하고 식별할 수 있다.링크와 버튼 텍스트는 콘텐츠의 목적을 알 수 있다.섹션에는 의미있는 마크업과 헤딩이 있다.문서의 휴먼 랭귀지 속성을 제공한다.문맥 변경은 예측할 수 있다.폼 콘트롤 요소에 설명을 제공한다.실수를 예방하고 정정하는 것을 돕는다.HTML 문법을 준수한다.WCAG 2.1 지침의 1.1.1 항목 예를 들어 볼게요.All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. 사용자에게 제공되는 모든 텍스트 아닌 콘텐츠는 아래 나열된 상황을 제외하고 같은 목적을 수행하는 대체 텍스트를 제공한다.원문 표현보다 아래와 같이 다듬은 표현이 좋다고 보는 것이죠.의미를 전달하고 있는 이미지에 대체 텍스트를 제공한다.물론 사내 지침은 너무 단순하게 표현했기 때문에 지침마다 ‘부연 설명, 관련 예시, 기대 효과, 관련 표준, 평가 도구’ 텍스트와 링크를 간략하게 제공하고 있습니다. 사실상 W3C 표준에 대한 링크 페이지라고 생각해도 괜찮습니다. 사실이 그런걸요.맺음말레진 웹 접근성 가이드라인은 사내 유관 부서 담당자분들께 공유하고 동의를 얻어 사내 지침으로 결정하고 공개할 수 있게 됐습니다. 긍정적으로 검토해 주신 사우님들 감사합니다.레진 웹 접근성 가이드라인은 W3C 표준을 요약한 버전에 불과하므로 누구라도 복제(Fork), 개선 요청(Pull Requests), 문제 제기(Issues)할 수 있습니다."Design for all, amuse everyone!"

안녕하세요. 언제 어디서나 함께하는 코딩 교실 엘리스입니다 :)아이디어만 좋다면 뭐든 실현해볼 수 있는 시대! 지금은 '프로그래밍'이라는 강력한 무기를 통해 원하는 세계를 실현할 수 있는 잠재적 가능성이 폭발적인 때입니다. 그리고 그 기회는 비단 '개발자'라는 특정 직업에 국한하지 않더라도 각계 분야에 펼쳐져 있는데요. 이미 마케터, 기획자, 디자이너, 콘텐츠 창작자, 금융업계 종사자, 지리학자, 연구원 등 다양한 분야의 많은 사람들이 프로그래밍을 통해 각자의 영역과 세계 곳곳을 새로운 곳으로 만들고 있습니다.높은 급여와 삶의 질을 보장하고 나의 꿈을 펼칠 수 있는 탁월한 수단인 프로그래밍.프로그래밍을 업으로 삼고 있는 사람들의 시작은 어땠을까요?이 글에서는 소프트웨어 엔지니어가 되고자 이제 막 마음먹은 분들을 위해 프로그래머가 되기 위한 다섯 가지 짚고 넘어가면 좋을 팁들을 알려드릴게요.STEP 1. 개발 친화적인 환경 찾아가기서당개 삼 년이면 풍월을 읊는다컴퓨터 공학 전공자와 비전공자가 가지게 되는 가장 큰 차이는 무엇일까요? 개발에 대한 이론 지식? 개발 능력?물론 모든 게 상대적인 것이겠지만 일반적으로 한 가지 큰 차이가 있다면 바로 '환경'이라고 할 수 있을 듯합니다. 내 주변에 개발과 관련된 자원이 얼마나 풍부한가 하는 점입니다.전공자가 개발을 시작하고자 마음을 먹으면 주위에서 좋은 리소스를 쉽게 찾을 수 있습니다. 한편 비전공자는 개발 공부를 시작하려고 할 때 레퍼런스로 삼을만한 좋은 예가 없으니 망망대해에 홀로 떠있는 기분이 들 수밖에 없겠죠! 그렇다고 해서 반드시 컴퓨터 공학 전공에서부터 다시 시작하거나 고액의 학원에 다닐 필요는 없습니다. 먼저 개발과 관련된 인적, 물적 자원이 풍부한 곳으로 적극적으로 다가가보세요. 작은 환경의 변화가 큰 변화의 시작점이 될 수 있습니다.엘리스가 추천하는 방법!온라인 커뮤니티 활동하기 : 코딩과 관련된 페이스북 그룹에 가입하여 많은 정보를 접하고 질문도 하면서 활동해보세요. 나와 비슷한 상황인 사람을 만나 서로 도움을 주고받을 수도 있고, 내 롤모델이 될만한 훌륭한 개발자를 만나 공부의 동력이 될지도요!개발 동아리, 스터디 등에 참여하기★ 엘리스 코딩 클래스 활용하기 : PC로도, 모바일 앱으로도 언제 어디서든 프로그래밍을 위한 환경에 접속하세요! 엘리스에 로그인하는 것만으로 공부하기 위한 모든 리소스를 얻을 수 있을 뿐만 아니라 과목별 채팅방을 통해서 함께 공부하고 있는 수강생들, 과목 튜터와의 활발한 대화에 참여할 수 있습니다. STEP 2. 강력한 동기와 조력자 만들기하늘은 스스로 돕는 자를 돕는다컴퓨터 공학 전공자라고 하면 모두 다 개발을 잘할까요? 적어도 아주 조금은 더 잘할까요? 대답은 NO!아무리 많은 이론을 배웠다고 해도 직접 개발을 하지 않는다면 아무런 소용이 없겠지요. 이해도가 다르기 때문에 배움의 속도는 조금 다를 수도 있겠지만 이런 차이보다는 개인의 학습 의지와 동기가 얼마나 분명하냐가 더 중요합니다.막연하게 '개발자'라는 너무 먼 목표만 보고 달리는 것보다는 보다 가까이에 있고 달성하기 쉬운 분명한 목표를 단계별로 설정해보세요. 그리고 '즐거움'을 느낄 수 있는 수단을 찾아 목표 달성을 위한 집중력을 높이세요. 동시에 내가 어려움에 처하거나 헤매고 있을 때 도와줄 조력자가 있다면 금상첨화!Photo by Mimi Thian on Unsplash엘리스가 추천하는 방법!동기 부여를 위한 작은 목표 설정 : 지식 습득 및 학습과 관련된 목표로 그룹 스터디 참여, 부족한 부분의 프로그래밍 강의 완강, 책 한 권 떼기 등이 있을 수 있고, 더 적극적인 형태의 개발 경험을 위해 공모전, 경진 대회 등 기간과 보상이 정해져 있는 대외 활동 참가 및 수상도 좋은 목표가 될 수 있을 거예요.★ 엘리스 코딩 튜터 활용하기 : 엘리스에는 학습을 도와주는 튜터가 있습니다. 엘리스 튜터는 답을 알려주는 사람이 아니라 답을 찾는 법을 알려주는 길잡이입니다. 공부하다가 막힐 때, 길을 잃은 것 같을 때 엘리스 튜터를 멘토로 삼아 보세요! 구독 및 트랙 이용 시 담당 튜터가 배정되어 개인 채팅방을 통해 1:1 튜터링을 받을 수 있고, 클래스 수강 시 단체 채팅방을 통해 언제든 질문할 수 있습니다.STEP 3. 원하는 개발 분야 탐색해보기  콩 심은 데 콩 나고 팥 심은 데 팥 난다개발에는 아주 숱~한 다양한 분야가 있습니다. 그리고 그 분야에 따라 특성도, 익혀야 하는 언어와 기술도 천차만별인데요. 아래 몇 개의 개발 분야와 사용 언어 및 기술에 대해서 적었으니 참고해보세요. 그리고 이보다 더 다양한 개발의 세계를 탐색해보면서 흥미가 가는 분야가 있다면 구체적으로 검색하고 공부를 시작할 계획을 세워보세요.Photo by Victoriano Izquierdo on Unsplash잘 모르겠다 or 코알못이다파이썬은 분야를 막론하고 많은 분야에서 사용되며 익히기에 쉬워 처음 코딩을 시작하는 입문자에게 가장 적합한 언어 중 하나입니다. 개발 언어부터 접해보고 싶다면 파이썬 언어 학습에서 시작해보세요!웹 개발 '콩 심은 데 콩 나고~'라는 속담을 인용했지만, 사실 다양한 개발 영역의 많은 지식들이 서로 겹치는 부분도 있고, 어느 한 분야를 잘할 수 있을 때 다른 분야로 전향하거나 옮겨가는 일은 보다 수월할 수 있습니다. 개발의 시작을 보다 쉽게 하고 싶다면 웹 개발부터 접근해보세요. 공부할 수 있는 자원이 풍부하고 추후 다른 개발 분야로의 전향도 가능하기 때문이에요.프론트엔드프론트엔드 개발은 주로 웹 환경에서 사용자와 맞닿는 가시적인 부분을 개발하는 영역입니다. 사용자가 코드를 작성하지 않고도 컴퓨터에게 명령을 내리는 등의 의사소통을 그래픽적으로 쉽게 할 수 있도록 가시적으로 만들어주는 것이 바로 프론트엔드 개발자의 역할이라고 할 수 있는데요. 예를 들어 엘리스에 로그인하고 싶을 때 '로그인 버튼을 클릭'하여 쉽게 로그인할 수 있는 인터페이스도 프론트엔드에 해당합니다. * 익혀야 하는 기본기 : HTML, CSS, JavaScript* 좀 더 나아가서 : JavaScript의 프레임 워크인 React.js 또는 Vue.js 또는 Angular.js 백엔드/서버백엔드 개발은 웹 환경에서 보통 사용자에게는 보이지 않는 서버(컴퓨터) 단의 개발을 의미하며, 사용자가 웹 상에서 활동함으로 인해 쌓이는 데이터가 모이는 DB(Data Base)를 다루는 영역을 개발합니다.* 익혀야 하는 기본기데이터베이스에 대한 지식 : MariaDB, PostgreSQL, MongoDB 등. 서버 쪽의 언어- 금융, 제약 등 전통적인 대기업 : Java의 프레임 워크인 Spring을 많이 사용- 과거 많이 쓰이던 기술 : Php(학습 속도와 개발 속도가 빠르며 무료!)를 많이 사용- 요즘 떠오르는 기술 : Python 기반 프레임 워크인 Django 또는 Flask. JavaScript의 프레임 워크인 Node.js* 좀 더 나아가서 : 클라우드 컴퓨팅 기술 Amazon AWS 또는 Azure에 대한 지식데이터 사이언스 - 데이터 분석가21세기에 가장 각광받는 직업 중 하나로 떠오른 '데이터 사이언티스트'에 대해서 모두 다 한 번쯤은 들어보셨을 거예요. 데이터 사이언스 분야에도 아주 복잡하고 다양한 영역들이 존재하는데요. 통상 데이터 사이언스라고 하면 수학 및 통계에 대한 지식, 컴퓨터 공학에 대한 지식, 인공지능 및 머신러닝과 관련된 기술을 사용하게 됩니다. 너무 많아 보이나요? 아래에는 데이터 사이언스의 많은 영역 중에서도 '데이터 분석가'로서 꼭 알아야 하는 내용을 적었습니다.* 익혀야 하는 기본기수학적 지식 : 통계, 선형대수학분석을 위한 언어 : Python, R* 좀 더 나아가서 : 머신러닝 기술임베디드 개발계산기, 에어컨, 자동차 등의 기계가 일정 기능을 컴퓨터처럼 수행할 수 있도록 기계 내부의 하드웨어 시스템을 구축하는 것이 임베디드 개발입니다. 사물 인터넷(IoT, Internet of Things)이나 하드웨어 부품과 관련된 분야에 관심이 간다면 임베디드 개발에 대해서 좀 더 알아보세요!* 익혀야 하는 기본기임베디드 개발 언어- 가장 많이 사용하는 언어 : C언어 - 국내 전통적인 대기업 : Java- 수요가 많은 언어 : Python (임베디드 분야에서도 빠지지 않고 자주 사용하는 언어! 국내 채용 사이트에서 임베디드 관련 개발 스택으로 많이 요구.)* 좀 더 나아가서 : 무선 통신 기술에 대한 지식*(공통) 개발자라면 익히고 있어야 할 기본기 : Git을 사용한 버전 관리 방법엘리스가 추천하는 실습 기반 과목HTML/CSS | JavaScript | 모바일 웹 코딩Git과 Git 버전 관리 (6월 오픈 예정)Python 기초 I | Python 기초 IIC 언어 | C++Java 기초 및 심화인공지능/머신러닝 기초 | 프로그래밍 수학데이터 분석 | Numpy, Pandas | 크롤링 | Kaggle 문제R 기초 |  R 패키지 | R 데이터 분석STEP 4. 실습, 프로젝트 기반으로 공부하고 개발 경험 쌓기구슬이 서 말이어도 꿰어야 보배다책을 사고 인강을 결제해도 직접 만들어보면서 익히지 않으면 절대 내 것이 될 수 없는 것이 또 개발!처음 언어를 익히는 단계에서부터 실습 기반으로 직접 코딩하고 그 결과를 확인해보면서 학습하는 것이 중요해요! 필요한 공부를 실습 단위로 쪼개어 직접 구현해보면서 익히고, 좀 더 나아가서는 프로젝트 단위로 구현하면서 실전 기술을 습득해보세요. 또한 실무에서는 혼자 개발하는 것이 아니라 뭐든 '협업'해야 하기 때문에 혼자 하는 프로젝트 외에도 여러 사람들과 함께하는 그룹 프로젝트의 경험이 큰 도움이 될 거예요. 자기소개서, 포트폴리오, 면접 시에도 어떤 프로젝트에서 내가 맡은 부분은 어느 부분이었고 어떻게 주도적으로 이끌었는지가 관건이 될 수 있습니다.엘리스가 추천하는 방법!★ 온라인 코딩 실습으로 기본기 다지기 : 엘리스는 별도의 코딩 환경 세팅 없이 온라인에서 바로 코딩 문제를 풀고 내가 짠 코드의 결과를 확인할 수 있어서 실습 기반으로 학습하기에 탁월한 플랫폼입니다. :) KAIST, SKT, 삼성 SDS 등에서도 활용하는 검증된 플랫폼에서 코딩 실습으로 기본기를 다지세요!프로젝트 단위로 혼자서 만들어보기 : 프로그래밍 언어의 기본에 익숙해졌다면, 직접 A to Z를 구현하는 작은 프로젝트를 통해 실제 필요한 기술이 뭔지 파악해가며 실전 기술을 익혀보세요. 그룹 프로젝트에 참여해서 협업 경험을 통해 익히기 : 취업을 위해서 중요한 것 중 하나인 '협업'능력! 그룹 프로젝트에 참여하여 비단 개발 실력뿐만 아니라 실무에 필요한 다양한 역량 또한 길러보세요.STEP 5. 포트폴리오, 시험 준비하고 개발 직군에 지원하기시작이 반, 그 이상이다!아시겠지만 개발자가 되면 끝인 그런 일은 없겠죠. (어떤 직무에서도 마찬가지일 거예요.) 끊임없는 공부, 새로운 기술 연마, 리팩토링, 문서화, 코딩 공부 코딩 공부!그러니 완벽에서 시작해야 한다는 생각은 버리고 지금까지 최선을 다해온 결과물을 가지고서 개발 직군에 지원하세요. 실제 개발자로 일하게 되면 그 속에서 배우고 성장할 수 있는 자원이 훨씬 더 많아집니다!'자리가 사람을 만든다'라는 말이 괜한 말이 아니니, 더 큰 성장과 가능성이 있는 곳으로 가기 위한 준비와 지원을 주저 없이 해보시길 바라요!Photo by Green Chameleon on Unsplash엘리스가 추천하는 방법!나를 잘 보여줄 포트폴리오 만들기 : (사용한 언어 / 프레임 워크 / 앞의 것을 적용하여 프로젝트에서 내가 한 역할) 별로 정리해두고 내가 커밋한 코드와 함께 보여주기.   블로그 쓰기 : 거창한 것이 아니어도 좋으니 공부하면서 느꼈던 것, 새로 알게 된 지식들, 프로젝트하면서 고민했던 것들을 블로그로 정리해보세요. 내가 구현한 것들을 이미지를 통해서 가시적으로 보여줄 수 있다면 금상첨화!★ 엘리스에서 알고리즘 시험 준비하기 : 이미 많은 수강생 분들이 엘리스 알고리즘 과목을 통해서 코드를 발전시키고 알고리즘 시험 및 취업에 성공하고 있습니다. :) 대기업 입사를 준비하시는 분이라면 엘리스 알고리즘 과목들을 꼭 수강해보세요.이다음의 6번째 스텝은 무엇이 될까요? 아마도 1~5 스텝을 계속 반복해나가면서 익숙해지고, 다른 역할로 각각의 스텝에 참여하게 되는 일이 아닐까요.엘리스는 누구나 프로그래밍을 통해 원하는 일을 할 수 있도록 좋은 강의 콘텐츠와 서비스, 플랫폼으로 여러분의 다섯 스텝에 함께하고자 합니다. :) 막막한 초심자 분들에게 앞으로의 방향성을 그려보는 데에 조금이라도 도움이 되길 바라며 글을 발행합니다.그럼 엘리스에서 만나요! >> 엘리스 아카데미 바로가기* 이밖에 조언, 첨언, 질문 등을 댓글로 남겨주시면 이 글의 독자분들에게 큰 도움이 됩니다.

안녕하세요. 엘리스입니다!지난 8월 말, 엘리스의 야심 찬 첫 해커톤이 있었습니다. 이번 해커톤은 매주 금요일 찾아가는 문제 ‘금요일에 코딩하는 토끼’에 대한 수강생 여러분의 성원에 힘입어 개최되었습니다.주제는 ‘코딩 문제의 A에서부터 Z까지 직접 설계하고 제작한다.’ 해커톤에서는 아이데이션 단계에서부터 문제 기획과 코딩, 채점을 위한 그레이더 제작까지 코딩 문제의 모든 것을 다루었습니다. 물론 실제 문제 동작을 위해 실행과 채점을 반복하며 디버깅하여 완벽한 실습 문제를 만드는 것 역시 이번 경연의 핵심이었는데요.이를 통해 모든 참가자 여러분들은 일일 엘리스 아카데미 실습 문제의 출제자가 되었습니다. 어떤 과정을 거친 어떤 결과물들이 있었을까요?해커톤 현장 스케치해커톤의 소개를 경청 중이신 참가자 여러분.지금까지 프로그래밍 문제를 많이 풀어보셨을 여러분이, 반대로 문제의 출제자가 되어 문제를 구성하는 관점에서 생각해보고 채점 방식까지 고민해본다면 프로그래밍에 대한 이해도를 더 높일 수 있을 것이라는 기대로 이와 같은 해커톤이 기획되었습니다. 교육자로서 엘리스 플랫폼의 다양한 기능을 직접 이용해볼 수 있는 것은 일석이조의 이점이었죠!경직된 분위기를 깨고 뇌를 말랑말랑하게 만들기 위한 아이스 브레이킹 시간은 팀 대항전으로 진행되었습니다.간단한 코딩 문제를 가장 먼저 맞히는 팀이 점수를 얻는 스피드 코딩 게임을 통해서 순발력을 높이고, 잠시 후 해커톤에서 본격적으로 사용하게 될 엘리스 플랫폼과 친해질 시간도 가질 수 있었습니다.'그림 그리기 게임'에서는 각 팀 디자이너들의 창의력이 폭발! 개발과 관련된 온갖 단어들을 1초 만에 그림으로 표현해야 하는 설명자의 재치와 크로키 실력(?)이 강조되었던 순간이었는데요. 승자는 '오즈'팀! 모두 오즈 팀 디자이너의 그림 실력에 입을 다물지 못했다고 합니다.게임을 하는 동안 어느새 어색했던 처음의 분위기가 파괴되었습니다. ^^ 1시간 동안 문제의 초안을 기획하는 시간이 주어지고, 이어 각 팀의 아이디어 발표 시간이 있었습니다.해커톤의 룰은 아래와 같았는데요.실행 가능한 프로그래밍 문제 1개 출제.동화를 모티브로 한 문제 스토리를 기획.채점 가능한 그레이더 제작.모든 팀들이 알고리즘 문제를 기획해주셨습니다. 동화의 서사구조를 논리적으로 단순화하거나 변형하여 알고리즘 문제에 녹여낸 과정이 인상적이었습니다.아이데이션 단계에서는 문제의 완성된 모습이 전부 그려지지는 않았지만 많은 고민의 흔적과 창의적인 생각들을 엿볼 수 있어 이로부터 탄생될 프로그래밍 실습을 기대할 수 있었습니다.밤샘 코딩 중...우승 문제 소개기획하고 코딩하고 디자인을 하다 보니(!) 어느새 날이 밝아왔습니다. 이제 남은 것은 팀별 결과물 발표와 우승팀 시상 뿐!'금코토'를 패러디하여 팀 명을 지어주신 어린 왕자 팀. /* prince */로고까지 깨알 섬세!모든 팀이 각기 다방면에서 강점을 부각하는 문제를 출제해주셨기 때문에 우열을 가리기 어려웠는데요. ‘금코토’배 해커톤이라는 이름에 걸맞게 금코토 과목의 취지와 가장 부합하는 문제를 출제한 팀에게 가산점을 주어 우승팀을 선발하였습니다. 그 결과 대망의 우승 문제는...거울나라의 앨리스팀의 ‘케이크와 병’ 단순한 명료한 문제 구성과 초등학생도 이해할 수 있는 쉽고 친절한 프레젠테이션으로 인상 깊었던 문제였습니다. 완성도, 문제 활용도 면에서 금코토 문제를 능가하며 단순하면서도 재미있게 풀 수 있는 문제라는 심사위원들의 평가가 있었습니다. 우승팀인 거울나라의 앨리스 팀 전원에게는 엘리스 굿즈를 선물로 보내드립니다. :)이밖에 겁쟁이 사자를 동물의 왕으로 만들기 위해 용기의 성을 짓는 알고리즘 문제를 낸 오즈의 마법사 팀의 문제는 스토리에 착안하여 자칫 복잡해질 수 있는 내용을 세세한 문제 설계로 극복하려 했던 점이 우수하게 평가받았습니다. 술주정뱅이 별에 사는 만취한 아저씨를 옮기는 알고리즘 문제를 낸 ‘목요일에 코딩하는 어린 왕자’ 팀은 참신성과 '넓이 우선 탐색', '깊이 우선 탐색', '다익스트라 알고리즘'을 모두 공부해볼 수 있도록 한 문제 구성 면에서 높은 평을 받았습니다.큰 상품도 내걸지 않았던 첫 해커톤이었는데도 참가자분들 모두가 열과 성을 다해 밤을 새워 문제를 만들어 주셨습니다. 모든 참가자 여러분들께 감사의 말씀 전합니다. :) 해커톤 이후 진행한 설문 조사에서 100%의 확률로 모든 분들이 다음 해커톤에 재참가 의사를 밝히셨는데요. 모두 첫 해커톤을 즐겨주셨던 것 같네요. 엘리스에서는 앞으로도 해커톤을 지속적으로 개최할 예정입니다. 코끝 시려질 때쯤 더욱 풍성하고 유익한 기획의 해커톤으로 찾아뵐 예정이니 많은 관심 가져주세요!*금코토 — ‘금요일에 코딩하는 토끼’라는 엘리스 아카데미 과목의 줄임말. 매주 금요일 저녁때쯤 업로드되는 문제로, 특정 루트로 토끼가 움직이도록 코딩해야 하는 콘셉트와 귀여운 휴보 래빗이 특징입니다. >>문제 풀어보기(무료)

안녕하세요. 스포카 개발팀에서 서버 관련 개발 업무를 담당하고 있는 문성원입니다. 오늘은 스포카 서버의 구조와 사용된 기술들에 대해서 함께 살펴보겠습니다.스택이란?먼저 스택(Stack)이란 용어에 대해서 함께 생각해보죠. 컴퓨터 과학을 공부하신 분들이라면 선입후출(FILO)이나 스택 오버플로우(Stack Overflow)등의 개념으로 익숙하실만한 용어기도 합니다. 그런데 서버 구조를 설명한다면서 왠 스택이냐구요? 다행히(?)도 지금부터 살펴 볼 스택은 솔루션 스택(Solution Stack)입니다. 스포카 서버라는 큰 솔루션이 원활히 동작하기 위해서 쓰이고 있는 각종 서브 시스템과 컴포넌트들의 묶음을 이야기하는 것으로 바꿔말하자면 이 글에서 다룰 기술 이야기는 모두 이 스택에 관한 이야기입니다.2011년 12월 현재 스포카 서버를 구성하고 있는 스택은 다음과 같습니다.DotcloudLinux 2.6.38.2nginx 0.8.53uwsgi 0.9.8.5Python 2.6.5Redis 2.2.2Celery 2.2.7Amazon Relational Database ServiceMySQL 5.5.12Amazon Simple Storage ServiceDotcloudDotcloud는 지금부터 설명드릴 스택을 묶어서 제공해주는 PaaS(Platform as a Service)의 일종입니다. Amazon Elastic Cloud Computing(Amazon EC2) 기반으로 동작하며 거기에 더해 손쉬운 확장과 배포가 장점입니다. 스포카 서버는 데이터베이스(Amazon RDS)와 업로드되는 데이터(Amazon S3) 이외의 모든 서비스를 Dotcloud를 통하여 제공하고 있습니다.nginx, uwsgi. 그리고 WSGI기본적으로 스포카 서버는 HTTP 형식의 요청을 받아 응답을 돌려주는 웹 어플리케이션입니다. 이러한 처리는 1차적으로 nginx를 통해 이뤄지는데, 이 중 서버사이드에서 처리가 필요한 경우에는 uwsgi라는 데몬이 이 처리를 담당합니다. (구버젼의 Apache Tomcat을 사용하시던 Java개발자분들은 Apache Tomcat과 Apache httpd와의 관계를 떠올리시면 편합니다.)이 경우 uwsgi는 일종의 어플리케이션 컨테이너(Application Container)로 동작하게 됩니다. 적재한 어플리케이션을 실행만 시켜주는 역할이죠. 이러한 uwsgi에 적재할 어플리케이션(스포카 서버)에는 일종의 규격이 존재하는데, 이걸 WSGI라고 합니다.(정확히는 WSGI에 의해 정의된 어플리케이션을 돌릴 수 있게 설계된 컨테이너가 uwsgi라고 봐야겠지만요.) WSGI는 Python표준(PEP-033)으로 HTTP를 통해 요청을 받아 응답하는 어플리케이션에 대한 명세로 이러한 명세를 만족시키는 클래스나 함수, (__call__을 통해 부를 수 있는)객체를 WSGI 어플리케이션이라고 합니다.정리하자면 스포카 서버는 WSGI에 맞게 작성된 프로그램을 nginx와 uwsgi를 통해 운용하여 요청을 처리하는 웹 어플리케이션이라고 할 수 있습니다.RedisRedis란 키-값(Key-Value) 저장 서버로 확장이 용이하며 속도가 우수합니다. 스포카 서버에선 이를 내부적인 임시 데이터 관리와 Celery의 작업(Task) 분배에 사용하고 있습니다.CeleryCelery는 Python으로 작성된 비동기 작업 큐(Asynchronous task queue/job queue)입니다. 앞서 소개한 작업(Task)를 브로커(Broker, 스포카 서버는 Redis를 사용)를 통해 전달하면 하나 이상의 워커(Worker)가 이를 처리하는 구조입니다. 포인트 적립-공유에 따른 분배처리, 포스팅 기능, 페이스북/트위터 공유등의 비동기 처리가 필요한 작업을 Celery에 위임하여 처리하고 있습니다.Amazon Relational Database Service대부분의 웹 어플리케이션과 마찬가지로 스포카 서버는 영속적으로 저장되어야하는 정보(회원 목록, 구매 내역)들을 디스크 기반의 데이터베이스(Database)에 저장합니다. Amazon Relational Database Service(Amazon RDS)는 Amazon EC2를 기반으로 그러한 데이터베이스를 간편하게 관리(모니터링, 백업, 접근제어)할 수 있게 도와주는 웹서비스입니다. Oracle과 MySQL을 지원하는데 스포카 서버는 그 중 MySQL을 사용하고 있습니다.Amazon Simple Storage ServiceAmazon Simple Storage Service(Amazon S3)는 Amazon RDS와 마찬가지로 Amazon EC2를 기반으로 한 데이터 저장 관리 서비스입니다. 스포카 서버에 업로드 되는 사진이나 문서등의 파일들을 통합하여 관리하여 서버의 인스턴스를 늘려 확장하는 경우에도 문제없이 대처할 수 있도록 하는 것이 주 목적입니다.#스포카 #스택 #개발 #개발자 #개발팀 #인사이트 #조언 #스킬스택 #스택설명

출근이 즐거워지는바로고의 복지 문화13가지안녕하세요, 바로고 입니다.바로고 직원들의 출근이 즐거워지는13가지 이유바로복지 문화 13가지가 있기 때문이죠^^[바로고 복지문화]바로고 복지 문화에 대해자세히! 알고 싶다면 클릭!뼈가 되고, 살이 되는외부 인사 초청 강연훌륭한 팀워크와 업무 효율을 높이는유익한 외부 인사 초청 강연!맛있는 음식과 함께 해봐요^^2017년 9월 7일외부 인사 초청 강연강연자헬로네이처 허광남 CTO뼈가 되고 살이 되는강연의 주제는고객 행동 데이터 보면서 개발하기강연은바로고 본사에서 진행되었습니다.강연을 본격적으로 시작하기 전프로젝터로 점검하고간단한 담소를 주고받으며편안한 분위기를 만들어주시는 허광남님뼈가 되고 살이 되는 강연이그동안 바로고에서 진행된 만큼오늘의 강연 또한 기대됩니다!고객 행동 데이터 보면서 개발하기Elastic Stack오늘 강연은1. 데이터 시각화의 가치2. 오픈소스 시각화 패키지 Elastic Stack3. 유용한 플러그인 소개4. ELK 적용 사례위의 같은 순서로 알차게 진행되었습니다.시작부터 집중하는바로고의 직원들업무에 바쁘다 보면다른 정보를 습득하거나다른 분야의 사람들과 의견을 공유할 여유가 없을 수도 있어요.이렇게 외부 인사 초청 강연을 통해다양한 의견을 공유하고리프레쉬 하는 기회가 생기는 것에바로고 직원들의 만족도가 높은 편입니다.이번 강연의 핵심이었던Elastic Stack 의 특징에 대해간단히 설명해보겠습니다강연의 내용을 함께공유한다는 것에도 의미가 있어요^^Elastic Stack 특징-Google Analytics(GA)의 데이터로사이트 접속 통계를 구할 경우원하는 대로 데이터를 획득하기 어렵다.-자체 서버의 모든 로그를 100% 수집할 수 있기 때문에데이터에 대한 신뢰성이 높다.-파라미터 값별로 통계를 볼 수 있기 때문에정확한 데이터 분석이 가능하다.-검색엔진(lucene)이 포함되어 있어빠르게 데이터를 검색할 수 있다.-모두 오픈소스이며 자유롭게 사용이 가능하다.자유롭게 질문을 주고받으며의견을 공유할 수 있었던 의미 있는 시간이 되었습니다.이번 강연에서도다양한 의견을 주고받고같은 문제에 대해다양한 시각이 존재한다는 것을알게 된 계기가 된 것 같습니다.바로고 직원 모두에게의미있는 시간이 되었으리라 생각합니다.오늘 열정으로 강의해주신허광남님께 진심으로 감사의 말을 전합니다.또 다른 시각에서 접근하는고객에 대한 접근 방법뼈가 되고 살이 되는알찬 시간이 되었습니다.감사합니다!바로고의 외부 강연이 끝날 시간 즈음그 시간이 바로 점심시간열심히 강의 들었으니에너지 충전이 필요합니닷!모두 수고하셨습니다.선택이 아닌 필수#배달 #배달대행바로고날씨 좋은 9월, 야외에서 오늘은 쉬는 날, 집에서누구와 함께 든 어디에서든내가 원하는 곳으로 배달!-전국 배송망을 갖춘바로고에서라면가능합니다.배달대행[바로고 공식 홈페이지]