한때 방송사에서 ′경영′이라는 단어가 생소했던 시절이 있었습니다. 몇 개의 방송사가 방송 시장을 과점하고 있었기 때문에 재원은 여유가 있었고, 방송사간의 경쟁은 큰 의미를 주지 못했습니다. 당시에는 프로그램을 ′제작′하고 뉴스를 ′보도′하는 것만이 방송사의 활동이었습니다. 그러나 방송 환경이 과거와는 비교되지 않을 정도로 변한 지금, ′경영′을 빼놓고는 방송을 말할 수 없습니다. 종합편성채널, CATV, 위성방송, 인터넷 등 지상파방송의 지위를 위협하는 많은 매체들이 방송시장에서 경쟁을 부추기고 있습니다.KBS 역시 이 경쟁에서 자유로울 수 없습니다.우수한 프로그램이라 하더라도 효율성과 경제성을 바탕으로 제작하지 않으면 누구도 방송사의 생존을 보장하지 않습니다. ′방송사를 경영하는 것′,  다시 말해 ′조직의 비전을 제시하고 자원을 효율적으로 집중하고 배분하는 역할을 하는 것′이 '기획행정'의 존재이유입니다.　우리는 가장 가까이에서 방송을 바라보고 있습니다.KBS는 한국을 대표하는 공영 방송이며 영국의 BBC, 일본의 NHK 등 세계 일류 공영 방송과 어깨를 나란히 할 수 있는 방송입니다. 세계 방송의 흐름을 읽고 국내 방송 환경을 개척하며 한국방송을 굳건히 세우는 일. 또 5년 후, 10년 후의 KBS를 조망하고 바람직한 방송 위상을 확립하는 일. 여러분이 정책을 기획하고 조직과 예산을 관리하는 기획예산국과 같은 곳에서 일하게 된다면 여러분은 KBS의 미래로 밤잠을 설칠 수도 있을 것입니다.　′기획행정′은 방송과 함께 합니다.뛰어난 방송 제작을 위해 재원을 마련하고 인력과 물자를 적절히 배분 하는 일이 그것입니다. 대시청자서비스를 담당하며 시청자 제일주의를 실현하는 시청자권익보호국, 공영방송의 소중한 재원인 수신료를 관리하는 수신료정책국, 업무처리의 타당성을 점검하는 감사실, 인력채용·운영과 제도 전반을 다루며 인재를 육성하는 인적자원실, KBS의 주요 정책을 개발하고 예산 및 계열사·지역국을 관리하는 기획예산국, 광고국, 자산을 관리하고 직원 급여 및 후생복지, 제작비, 결산·세무를 담당하는 총무국 등 한정된 자원으로 최적의 최선의 노력을 기울이고 있습니다. ′기획행정′은 방송 제작의 일선에서도 그 역할을 충실히 수행하고 있습니다.방송국은 물론 방송을 만드는 곳입니다. 하지만 방송의 이면에는 한 컷의 화면을 위해 온갖 정성을 아끼지 않는 엔지니어, 카메라맨, 디자이너, 작가, 세트제작요원, 분장사, 오디오맨, 효과맨 등 수많은 사람들이 함께 하고 있습니다.′기획행정′은 이러한 다양한 분야의 전문가들을 방송이라는 정점에서 어우르는 역할을 하고 있습니다. 편성운영부, 보도운영부, 콘텐츠운영부, 라디오운영부, 제작리소스운영부 등은 방송 현장에서 제작자들과 호흡을 같이 하고 있습니다.  KBS, 디지털 이성과 아날로그 감성이 맞물리는 곳사회는 생산성과 효율성에 입각한 정글의 법칙만이 존재하고 있습니다. 일상에 얽매여 자신보다는 조직의 논리에 갇히기 쉽습니다. 사회인이 된다는 것은 스스로의 생계를 유지하는 것 뿐만 아니라 사회 속에서 자신의 가치를 실현하고 존재의 의미를 확인하는 일입니다. KBS는 최소 투자, 최대 이익의 실현이라는 경영의 논리를 바탕으로 기업을 운영한다는 점에서는 사기업과 같지만 국가기간방송으로서 방송의 이념과 목표를 더욱 소중히 하는 곳입니다. 원리원칙을 지키는 디지털 경영이 KBS의 경영 목표지만, 구성원들이 아날로그의 개성과 장점을 마음껏 구현할 수 있도록 그 토대를 마련해 주는 곳이기도 합니다.　KBS는 여러분을 향해 두 팔을 활짝 펼치고 있습니다!선택은 여러분의 몫입니다.　#한국방송공사 #KBS #KBS공채 #직무정보 #직무소개

올해 2월에 썼던 글을 이제야 올려봅니다. 태블로는 아직 잘 사용하고 있습니다. : )“아무개 님, 지난번에 요청한 자료 언제까지 받을 수 있죠?”다행이다. 꿈 이었다.가벼운 발걸음으로 출근하던 중 일감 하나가 떠오른다. 간밤의 꿈이 꿈 만은 아니었던게다.아뿔싸, 아직 시작도 못했는데.오늘 할 일을 내일로 미룬 자의 아침은 발걸음이 무겁다.Business Intelligence 라는 것이 있다. 뭔가 멋드러진 단어의 조합처럼 보이지만, 현실은 그리 아름답지 않다. 대부분의 시간을 비슷한 일을 반복하며 숫자를 맞춰야하고 엑셀과 SQL 에 빠져 살기 일쑤다. 잘못된 데이터라도 발견되면 이걸 어디서부터 수습해야 하나 고민해야 한다. (끝이 없는 재귀호출)반복, 반복, 반복. 비용을 줄이자.반복은 비용이다. 한두번 반복되는 일을 최적화 하는 것은 최적화 자체가 비용 이겠지만, 매일같이 반복되는 일, 주기적으로 찾아야 하는 데이터들은 그 자체만으로도 최적화의 대상이다.특히나, 아직 성장하고 있는 ‘스타트업’ 이라면 회사의 데이터가 잘 정리되어 있을리 만무하다. 몇몇 데이터는 잘 관리되고 있겠지만, 상당수는 흩어져 있을 것이다. 어느 순간을 지나면 이들을 모으는 게 일이 되어버린다. 임계점을 넘어서버린 일을 한다는 것은 손을 더럽히는 일이 된다는 뜻이기도 하다. 아무쪼록 그대에게 이 임계점을 분간할 지혜가 있기를.시간 비용을 절약하자스타트업의 구성원들에게 가장 중요한 것은 무엇일까? 나의 짧은 생각으로는 사람과 시간이라고 생각된다. 이 중에서 BI 툴이 해결해 줄 수 있는 것은 무엇일까?나 스스로에게 질문해보니 이런 답이 나온다. ‘사람은 쉽게 바뀌지 않는다’ 그럼 시간은? 다행히, 시간은 모두에게 공평하게 주어진다.‘그럼 이 시간을 아껴보자!’여기에 하나 더, 내가 모르는 것이 있었다.앞으로 회사가 데이터를 다루는 스펙트럼을 얘상할 수 없다는 것이다.Zeppelin무엇을 사용할까 고민하던 중 가장 먼저 떠오른 것은 다름 아닌 제플린 이었다.< 이 형님들 말고 >(출처 : http://fortune.com/2016/07/26/led-zeppelin-stairway-heaven-appeal/)아파치 제플린은 한국에서 시작해 아파치 인큐베이터에 들어간 오픈소스 데이터 분석 및 시각화 툴 이다.장점은 개발자에게 익숙한 노트북 기반이라는 것과 강력한 인터프리터를 통해 다양한 데이터 소스에 접근할 수 있다는 것이다.나프다 팟캐스트에서 들은 내용인데, 트위터의 경우 태블로에서 제플린으로 갈아탔다는 이야기도 있었다.기본적으로 프로그래밍이 가능하기 때문에 어떤 형태의 데이터를 요구해도 제공할 수 있다는 장점도 있다.물론, 단점도 있다. 먼저 시각화 부분이 약하다는 것이다. D3.js 를 같이 사용하면 보완할 수 있지만 개발자의 꾸준한 지원이 있어야 할 것이었다.더불어, 비개발자들에겐 노트북 형태로 데이터를 가공하는 것에 진입장벽이 있다고 생각 했다.한번쯤 사용해보고 싶었지만 개발 리소스가 부족한 우리 상황에는 맞지 않다고 생각했기에 다음을 기약해본다.Spotfire, Amazon Quicksight, Google Data Studio다음으로 찾아본 툴 들은 바다 건너에서 잘 사용 되는 몇가지 것들 이었다.Spotfire 는 레퍼런스도 충분했지만 다음에 등장한 강력한 후보로 인해 제외됬다.아마존 퀵사이트는 잠깐 사용해봤지만 회사의 요구사항을 맞추는데 부적절해 보였다.구글의 데이터 스튜디오 역시 기능에 제약이 많았다.아마존과 구글의 솔루션은 무료로 사용할 수 있거나 가격이 합리적이라는 장점도 있었다.Spotfire 역시 비싸지 않은 가격이었다.태블로, 그리고 plotly태블로는 동료 직원의 지인 중 사용해본 분이 있어서 직접 만나서 여러가지를 물어볼 수 있었다. 나중에 알았지만 한국에 공식 총판이 있어서 메일로 문의하면 다양한 안내를 받을 수 있었다.태블로는 장점이 많은 툴이다. 다양한 데이터 소스를 지원하며, 강력한 시각화를 통해 데이터를 분석할 수 있다.데이터를 유연하게 다룰 수 있어서 여러가지 인사이트를 얻는데 도움을 줄 것이라 생각됐다.온라인 튜토리얼도 잘 되어있고, 한국에서 오프라인으로 기초교육도 받을 수 있다.종합적으로 비교해 본 결과 비슷한 성격의 툴 중에선 가장 강력한 툴 이었다.유일한 단점이라면 가격이다.plotly 는 리서치 중 가장 마지막으로 접했는데 대시보드로도 사용할 수 있고 노트북에도 붙일 수 있는 라이브러리 형태로 제공되는 툴 이었다.데이터 분석에 주로 사용되는 파이썬, R, 매트랩에 모두 사용 가능했고 훌륭한 시각화도 가능했다. 학생이라면 아주 저렴한 가격으로도 이용이 가능하다.단점이라면, 개발자에게 더 친화적 이라는 것과 데이터 커넥터가 태블로에 비해 부족하다는 것 이었다.BI 툴, 개발자와 분석가 중 누구에게 더 쉬워야 할까?회사마다 개발자의 비중이 다르다. 스타트업 이라고 해서 개발자들로만 이루어진 것도 아니고, 이미 안정적으로 비즈니스를 운영하는 회사라고 해서 개발자가 적은 것도 아니다.각 회사가 처한 상황에 따라 어떤 툴을 사용할 지는 다를 것이다.나는 우리 회사가 어떤 BI 툴을 써야 최적일지 생각해 봤다.같은 작업을 하는데 있어서 시간을 줄여줄 수 있어야 하고, 앞으로의 변화에 유연하게 대응할 수 있는 툴이었으면 했다.개발자의 지원을 최소화 하면서 비즈니스를 이해하는 분들이 적극적으로 사용하는데 어려움이 없었으면 했다.가격적인 면도 중요했지만, 국내에서 사용하는데 참조할 수 있는 레퍼런스, 교육이 풍부한 것도 선택에 한 축이 되었다.모든 것을 종합해 본 결과 태블로 만한 것이 없다고 생각됐다.< 이제 데이터와 사랑에 빠져 볼까? >(출처 : https://www.youtube.com/watch?v=2onPdVj5zgQ)여러분들의 상황은 어떤가.지금 사용중인 툴이 충분한 효과를 가져다주고 있는가? 혹시 기존에 익숙하던 것을 습관적으로 사용하고 있지는 않나?대부분의 스타트업은 부족한 인원으로 복잡한 이슈를 해결하기 위해 고군분투 중일 것이다.특별히, 데이터를 들여다보고 최적화를 해야하는 업무를 담당하는 사람이라면 지금 이 순간도 머리를 싸메고 고민에 빠져 있을 것이라 생각된다.데이터 때문에 잠이 부족한 그대에게, 비슷한 고민을 하는 분들에게, 아무쪼록 이 글이 조금이나마 도움이 되었기를 바란다.#8퍼센트 #에잇퍼센트 #협업 #업무프로세스 #팀워크 #수평적조직

최진님은 내가 처음으로 만난 UX 기획자다. 지난 회사에서 새로운 사업 아이디어가 나올 때마다 했던 이야기가 있다.A: “새로운 서비스 개발을 시작합시다!"B: “그럼 기획은 누가 하나요?"A: “적당히 나눠서 해야죠."나에게 기획자라 하면 개발해야 할 것을 완벽하게 정리해서 가져다주는 마법사였다. 하지만 당시 그 일을 해줄 수 있는 사람은 없었고 매번 그 지점에서 갈등이 생기곤 했었다.8퍼센트에 처음 왔을 때 “오. 이 회사에는 기획자가 있네?”라고 생각했었다. 밑도 끝도 없이 일하기 편하겠다는 생각을 했던 것 같다. 당시만 해도 기획자에게 어떤 결과물을 기대해야 하는가? UI와 UX는 어떻게 다른 건가? 기획자와는 어떻게 일하는 것이 좋은가? 등등을 전혀 몰랐었는데 이제 진님을 통해서 하나씩 배워가고 있다. 어떻게 생각해 보면 B2B 플랫폼 개발자에서 B2C 서비스 개발자로 바뀌면서 알아야 할 것들을 배워가는 과정이라고 할 수 있겠다.내가 기획 했으니 너는 들으라. (이효진 대표님 지켜주지 못해 미안해요.)자 그럼 내가 8퍼센트의 최진님을 통해서 알게 된 'UX 기획자의 역할'을 살펴보자. (내가 잘못 알고 있다면 진님 탓이다)사람들을 토론의 장으로 데려온다.기존까지 생각하던 기획자는 모든 것을 고려한 이후에개발자: “더 이상 변경은 없는 거죠? 이대로 개발만 하면 되는 거죠?”기획자: “네!"를 할 수 있는 문서를 건네주는 사람이었다.이렇게 마법같이 한번에 최적의 솔루션을 찾는 일은 일어나지 않는다하지만 이제는 기획자에게 기대하는 바가 달라졌다. 100%를 한 번에 하는 것이 불가능하다는 것을 알고 있고, 혹시나 가능하더라도 효율적이지 않다는 것도 알고 있다. 60%를 빠르게 만들어서 회사 내 구성원들을 토론에 적극적으로 참여시키는 것이 기획자의 역할이라고 생각한다. 아무것도 없는 상태에서 무언가를 만들어내는 것은 어렵다. 당연히 그 상태에서는 생산적인 논의도 되지 않는다. 하지만 다른 사람이 해 놓은 것에 대해서 평가하는 것은 다들 손쉽게 하지 않는가. 기획자가 가져온 초안을 바탕으로 CS팀은 고객이 되어 기능을 검토하고, 그래픽 디자이너는 결과물을 상상하고, 개발자는 다른 모듈과의 연관성, 사용해야 할 라이브러리를 검토한다. 여기서 부터가 적극적인 시작이다.8퍼센트의 연결고리 최진. 직접 그린 그림에서 힙합 매니아임을 알 수 있다좋게 말하면 8퍼센트에서는 최진을 중심으로 일이 돌아간다. 하지만 실제는 그냥 이리저리 치이고 여기저기 불려 다니는 인터럽트 인생이다.답을 찾아 준다.그냥 주는 것이 아니라 찾아 준다는 것이 중요하다. 제품을 만들다 보면 결정해야 할 것들이 너무나도 많다. 버튼의 위치, 폰트의 크기, 안내 문구, 페이지 전환을 할 것인가? 에러 상황은 어떻게 처리할 것인가? 등등. 이런 질문들에 대해 답을 줄 수 있는 사람이 명확한 경우도 있다. 예를 들면 디자인을 할 때 “이런 식의 구현이 가능한가요?”라고 물으면 개발자가 답을 해 줄 수 있다. 하지만 대부분은 고객에게 던지는 질문이다. 이런 질문들에 대한 답을 찾아 주는 것이 기획자의 역할 중 하나라고 생각한다. 그 답은 영업팀에서 가지고 있을 수도 있고, 고객서비스팀에서 가지고 있을 수도 있다. 하지만 우리 모두는 그 질문을 기획자에게 던지고 기획자는 그 질문에 대한 답을 찾아 준다.프로덕트 팀의 피어리뷰 시간에 아기새님이 진님에게 전달한 피드백컨베이어 벨트를 따라 걷는다.요구사항의 정리부터 기획, 디자인, 개발, QA, 릴리즈에 이르기까지 모든 과정을 지켜보는 한 사람이 있다. 기획자다. 이 사람이 제 역할을 하지 않으면 '방과 방 사이' 같은 일이 발생한다. 기획자는 프로젝트를 시작되게 한 고객의 요구사항이 정확히 다시 고객의 손에 전달될 때까지의 과정을 지켜본다. 컨베이어 벨트를 따라 걸으며  방향이 빗나갔을 때에는 바로잡고 놓친 사용자 패스가 있을 때에는 이를 채워 넣는다. 때로는 최초의 가정이 틀렸을 때 빨간 버튼을 눌러 컨베이어 벨트를 멈추는 역할을 한다. 결국 모든 과정이 완료되어 고객에게 제품이 전달되었을 때 기획은 끝이 난다.제품에 대한 책임을 진다.원래 결정하는 자가 책임을 지는 법이다. 제품이 시장에서 좋은 평가를 얻지 못할 때 사람들은 그 책임을 돌릴 곳이 있다. 기획자다.쟤가 그렇게 하라고 했어요. (흥. 난 몰라)물론 8퍼센트는 그 책임을 서로 미루지 않고 다 함께 진다. 하지만 진님은 그 책임을 무겁게 느끼고 있다. 외부에서 쓴소리가 들려올 때 받는 스트레스를 보면 알 수 있다.이 정도가 내가 생각하는 UX 기획자가 하는 일이다. 다른 회사의 UX 기획자가 하는 일과 얼마나 다를지는 모르겠다. 크게 깨닫지 못하고 있었는데 글로 정리하고 보니 UX 기획자는 서비스를 만드는 회사에서 대단히 중요한 사람이다. 새삼 감사한 마음이 든다. 사실 진님은 지금까지 이야기한 UX 기획 외에도 UI 설계도 함께 맡고 있다. 진님이 8퍼센트에서 하는 일을 좀 더 알고 싶다면 진님이 직접 쓰신 글을 읽어 보자.진님은 브런치에 글을 쓴다. 무려 나보다 5배나 많은 구독자를 가지고 계신 인기 작가(질투로 인해 표현이 좀 꼬인 것을 이해해 달라) 이시니 램프의 요정 GENIE의 브런치를 방문해 보시길 바란다. 직접 그린 그림과 함께 글을 쓰시기 때문에 브런치 메인의 웹툰 작가 리스트에서도 종종 찾을 수 있다. 때로는 긴 글 보다 한 장의 그림이 훨씬 더 많은 것들을 전달할 수 있음을 알기에 참 부러운 능력이다. 그러고 보니 진님의 추천으로 나도 개인 블로그에서 브런치로 넘어와서 재미있게 글을 쓰고 있으니 이 자리를 빌려 감사함을 표해야 하겠다. 진님의 구독자 수를 따라잡을 때까지 열심히 해보겠다.청순한(?) 외모도 갖고 있고 일에서는 완벽을 추구하지만 신은 역시 공평하다. 사람이 허술하다.그 누군가는 이렇게 말했다.처음에는 시크한 이미지여서 다가가기 어렵지만 조금만 지나면 이런 허술한 점들을 아주 손쉽게 발견할 수 있어서 사람들을 편하게 해주는 반전 매력이 있다.처음에 진님과 일을 했을 때에는 자신의 기획안에 대한 불안감과 일을 이끌어 나가는 것에 대한 부담감이 느껴졌다. 하지만 최근에는 그런 것들이 점점 느껴지지 않는다. 발전하고 있다는 증거다. 진님은 자신의 위치와 역할에 대해서 끊임없이 고민한다. 그 질문을 내게 던진다면 내가 만나본 유일한 UX 기획자이기에 진님이 UX 기획자로 어디쯤에 있는지 나는 잘 모르겠다고 답해야겠다. 하지만 지금처럼 치열하게 고민하고 노력한다면 내가 만난 최초의 UX 기획자가 최고의 UX 기획자로도 남을 것이라고는 확실히 말해줄 수 있겠다.진님의 인생사진으로 마무리!같이 일하는 동료에 대한 글을 쓰는 것은 쉽지 않다. 특히 조직도(회사 내에서 별 의미는 없지만)에서 상하 관계에 있는 사람에 대한 글을 쓰는 것은 꽤 부담스러운 일이다. 그래도 이 기회를 빌어 동료에 대한 고민을 깊게 해본다.#8퍼센트 #에잇퍼센트 #협업 #기획 #기획자 #UX기획 #팀워크 #팀플레이 #조직문화 #기업문화

원칙(Principle)은 중요합니다. “난 원칙대로 살지 않겠어!” 라고 외치고 싶더라도, 원칙이 있고 원칙을 충분히 이해하고 있지 않다면 그저 사춘기 소년/소녀의 이유 없는 반항 정도로 밖에 들리지 않을테니까요. 사실 대부분의 이런 경우 원칙 보다는 “규칙(Rule)대로 살지 않겠다”에 가깝지만, 여기에서는 그냥 넘어가도록 하죠. 소프트웨어 개발에도 다양한 원칙들이 존재합니다. 학부 수업에서 잠깐 들었거나 이런 저런 글들을 읽다가 접해 봤을 이런 원칙들은 실제 서비스를 만들면서 바쁘게 기능을 추가하고 버그를 수정 하느라 어느새 기억 속에서 잊혀지곤 하죠. 정신없이 기능을 구현하다가 문득 코드를 돌아봤을 때 ‘이게 왜 여기에 있지’ 라는 의문이 든다면 한 번쯤 원칙을 되새겨 보라는 신호가 아닐까요? 이 글에서는 Clean Architecture 와 Clean Code 등의 저자로 유명한 Uncle Bob(Robert C. Martin)이 얘기하는 S.O.L.I.D Principles 에 대해 얘기해 보려고 합니다. SOLID 원칙은 밥 아저씨가 2000년도 자신의 논문 Design Principle and Design Patterns 에서 OOD(Object-Oriented Design)를 위해서 제안한 5가지 원칙의 앞 글자만 떼서 붙여졌습니다. Object-Oriented Design 을 대상으로 제안된 원칙이지만 Agile 개발 등의 개발 방법론 핵심 철학에도 적용될 수 있는 개념들 입니다. S.O.L.I.D Principles Single Responsibility Principle Class 는 오직 한 가지의 책임이 주어져야 하고, 오직 한 가지 이유에서만 변경되어야 합니다. 보고서를 편집하고 출력하는 모듈에 대해서 생각해 볼까요. 해당 모듈은 두 가지의 이유로 변경될 가능성이 있습니다. 보고서의 내용이 바뀌었을 때도 변경되어야 하고, 보고서의 형식이 바뀌었을 때도 변경되어야 합니다. 편집 과정 때문에 모듈을 변경하다 보면 해당 변경 사항이 출력 부분에도 영향을 미칠 가능성이 상당히 높습니다. 이 경우 내용을 편집하는 모듈(i.e 내용을 담당하는 모듈)과 출력하는 모듈(i.e 형식을 담당하는 모듈) 두 가지로 나뉘어야 합니다. “할 수 있다고 해서 해야 한다는 뜻은 아닙니다.” Open / Closed Principle Class, Module, Function 등의 소프트웨어 구성 요소는 확장(extension)에 대해 열려 있어야 하며, 변경(modification)에 대해 닫혀 있어야 합니다. 어떤 모듈이 Data Structure 에 필드를 추가하거나 함수를 추가하는 등 확장이 가능하다면 그 모듈은 확장에 대해 열려 있다고 표현합니다. 반면에 어떤 모듈이 수정 없이 다른 모듈에 의해 사용될 수 있다면 그 모듈은 닫혀 있다고 표현합니다.  public class CreditCard {     private int cardType;       public int getCardType() { return cardType; }       public void setCardType(int cardType) { this.cardType = cardType; }          public double getDiscount(double monthlyCost){          if (cardType == 1) {              return monthlyCost * 0.02;          } else {              return monthlyCost * 0.01;          }     } }  위 CreditCard class 에 새로운 카드 타입을 추가하려고 하면 getDiscount 함수를 변경할 수 밖에 없습니다. 이 경우 Open/Closed Principle 을 위반된다고 볼 수 있습니다. “코트를 입기 위해서 개복 수술을 할 필요는 없으니까요.” Liskov Substitution Principle 프로그램 상의 Object 들은 프로그램의 정확성을 해치지 않으면서 하위 타입의 Instance 로 변경 가능해야 합니다. 하위 타입 함수 인자의 반공변성(Contravariance), 하위 타입 함수 반환 타입의 공변성(Covariance), 상위 타입의 예외를 상속하지 않는 추가적인 예외 발생 금지 등의 요구 사항이 있습니다. OOP 에서 상속 개념을 배울 때 이해를 돕기 위해 주어진 몇 가지 예시들이 있었을텐데, 우습게도 우리가 생각하기에 타당한 상속에 관한 예시들 중 의외로 원칙을 위배하는 경우가 많습니다. Liskov Substitution Principle 을 위반하는 대표적인 예시는 정사각형과 직사각형입니다. 정사각형은 직사각형의 일종이니 Square가 Rectangle을 상속받는 것이 충분이 타당한 것으로 보입니다. 정말 그럴까요? Rectangle 의 넓이를 구하는 함수의 테스트를 구성해 봅시다.  Rectangle rect = new Rectangle(); rect.setWidth(10); rect.setHeight(20); assertEquals(200, rect.getArea());  여기에 new Rectangle() 대신에 new Square()가 rect 에 할당되면 어떻게 될까요? 넓이는 400 을 반환하기 때문에 테스트는 실패하겠죠. 정사각형이 직사각형을 상속 받으면 Liskov Subsitution Principle 을 위반한다고 볼 수 있습니다. 상속은 문제를 해결하는데 있어서 상당히 유혹적인 방법입니다. 하지만 상당히 많은 경우에 상속을 오용할 가능성이 높습니다. “오리처럼 생기고 오리처럼 꽥꽥 거리더라도, 배터리가 필요하다면 오리가 아닙니다.” Interface Segregation Principle 많은 것을 아우르고 일반적으로 사용 가능한 하나의 interface 보다 특정 클라이언트를 위한 여러 개의 interface 가 낫습니다. Xerox는 Stapling(프린터기가!?), Fax 등의 다양한 기능이 포함된 신규 프린터 소프트웨어를 개발 도중, 더이상 개발이 불가능할 정도로 프로그램이 번잡 해졌다는 것을 인정하고 밥 아저씨에게 도움을 요청합니다. 문제는 Job Class 하나가 모든 기능을 다 구현하고 있다는데 있었습니다. 이 비대한 Class 는 Client 입장에서 사용되지도 않을 모든 함수를 알 수 있게 구성 되어 있었죠. 이 문제에 대해 밥 아저씨는 Interface Segregation Principle 을 적용하여 각 Client 입장에서 사용해야 하는 함수 만을 가지고 있는 각 interface 들을 따로 만들었습니다. 그리고는 다음에 나올 Principle 인 Dependency Inversion Principle 을 통해서 해당 기능을 구현하게 함으로써 문제를 해결했습니다. Dependency Inversion Principle “추상화에 의존해야지, 구체화에 의존하면 안됩니다.” 상위 계층의 모듈은 하위 계층의 구현이 아니라 추상화에 의존해야 합니다. 상위 계층이 하위 계층의 구현에 의존하던 전통적인 의존 관계를 역전 시킴으로써 상위 계층이 하위 계층의 구현으로부터 독립되게 할 수 있습니다. 예를 들어 Dependency Injection 은 이 원칙을 따르는 방법 중 하나 입니다. Conclusion 세상에 나쁜 프로그램은 있습니다. 당장 눈에 보이는 기능이 똑같다고 같은 프로그램인 것은 아닙니다. 생각보다 많은 코드들이 ‘그 곳에 넣을 수 있기 때문에’, ‘그 곳에 넣어도 돌아가기 때문에’ 깊은 고민 없이 그 곳에 정착합니다. 당장 좀 더 빠르게 기능을 추가해서 주변 사람들의 박수를 받을 수도 있습니다. 허나 이것들이 쌓이면 더이상 손댈 수 없는 코드가 되고, 문제를 느끼고는 Refactoring을 하자고 다짐하고, 모두 엎은 다음 또 다시 같은 코드를 만들게 되겠죠. 쉬운 코드가 가장 만들기 어려운 코드이고, 그런 좋은 코드는 좋은 원칙으로 부터 나옵니다. 변화에 적응할 수 있는 프로그램, 의도가 쉽게 읽히는 프로그램, 문제 발생 가능성이 적은 프로그램, 쉽게 확장할 수 있는 프로그램 등 좋은 프로그램을 만드는 것은 우리가 실제로 목표하는 것을 달성하기 위해서 정말 중요합니다. 이는 그저 경험이나, Tweak 만으로 이루어지지 않습니다. 다양한 신규 기술들과 Framework 들을 두루 섭렵하면서 활동 반경을 넓히고 경험을 쌓았다면, 가끔은 잠시 서서 원칙에 대해 되돌아 보는 것은 어떨까요?   *버즈빌에서 활기찬 개발자를 채용 중입니다. (전문연구요원 포함)작가소개 Whale, Chief Architect “Keep calm and dream on.”