대표 번역가 : 백재영


실리콘밸리를 꿈꾸는 개발자.
현재 LF 플랫폼 개발팀에서 있으며 요즘은 번역의 어려움과 재미를 한창 느끼는 중이다. 


원문 링크





스프링 빈이 진짜 뭘까?


오늘 Spring Boot Application 내부에서 무슨 일이 벌어지고 있는지 이해하려고 하는 중 멘붕이 왔다.


스프링을 처음 접하면서 꽤 많은 시간을 구글링과 문서 읽기에 쏟아부었지만 ‘빈'과 같은 기본적인 개념에 관해서는 사전지식을 전제로 한다고 알고 있었다.


Pivotal의 스프링 팀에 있는 내 친구이자 동료인 Mark Fisher가 내게 찾아와 설명해주는 대신 나는 이것에 대해 글을 쓰기로 약속했다.


그 결과는 지금 보고 있는 이 블로그와 여기에 있다. https://github.com/markfisher/spring-boot-hello-world


태초에 XML이 있었다

스프링은 자바 애플리케이션이 종속된 메인 클래스를 구성하는 데에 J2EE보다 더 간단한 XML 기반의 방식을 제공한다.


단순히 모든 것을 자바의 new를 이용하여 인스턴스화하는 것은 이상적인 것이 아니었다. 이는 모든 종속성을 코드에 기술해야하므로 로컬 테스트를 위한 데이터베이스와 CI 또는 프로덕션을 위한 다른 데이터베이스를 쉽게 사용할 수 없었기 때문이다.


데이터베이스 커넥션같은 것들을 추상화한 자신만의 팩토리를 만드는 대신, 스프링은 이 모든 것들을 XML 하나로 제공한다.


스프링은 구동시 환경에 특정한 XML을 읽어들이고 XML에 있는 것들을 기반으로 해당 클래스의 인스턴스를 생성한다.

 

그리고 이런 인스턴스들은... 이런 식의 (beans)이다.

 

ApplicationContext.getBean()

 

지금은 @Annotation이다

세월이 흘러 XML은 @Configuration @ConfigurationProperties 같은 주석이 달린 자바 코드로 대체되었다.

 

Screen Shot 2017-10-11 at 10.11.48 PM.png


팩토리 메소드에 @Bean이 달린 것에 주목하라.


설정 클래스가 META-INF/spring.factories에 포함되어 있으면, 스프링 부트 애플리케이션은 시작시 자동으로 팩토리 메소드를 호출하여 해당 클래스의 싱글턴 인스턴스를 생성한다.


이건 마법이다

그리고 이런 인스턴스는 여전히 이라 불린다


Spring Initializr와 모든 starter들은 다 뭐냐고?

이제 configuration scanning이 뭔지 알았으니 스프링 부트 스타터의 역할은 더 이해하기 쉬울 것이다.


스프링 부트 애플리케이션의 종속성에 스타터를 포함시킴으로써 스프링은 스타터 내부의 설정 클래스를 검색하여 해당 스타터에 대한 을 자동으로 생성하게 된다.

 

Initializr injection

짠!



저작자 표시 비영리 동일 조건 변경 허락
신고

설정

트랙백

댓글








대표 번역가 : 백재영


실리콘밸리를 꿈꾸는 개발자.
현재 LF 플랫폼 개발팀에서 있으며 요즘은 번역의 어려움과 재미를 한창 느끼는 중이다. 


원문 링크





나는 2년 전에 엔지니어링 관리자가 되었다. 관리자로 있는 동안 주된 과제 중 하나는 우리 팀에 대한 나의 리더십과 코딩을 하고 싶은 욕구 사이의 균형을 잡는 것이었다.


분명 이런 일로 고군분투 하는 것은 나만은 아닐 것이라 생각한다. 그래서 내 생각을 공유하고자 한다.



왜 엔지니어링 관리자가 기술적으로 뛰어나야 하는가


나는 실무 위주의 기술적으로 뛰어난 관리자가 엔지니어링 팀(그리고 대부분의 시간에 딜버트의 법칙을 벗어난 팀)의 최고의 리더라고 생각한다. 기술적으로 뛰어난 관리자로서 당신은,

  • 팀원들이 수행해야 할 직무에 관련된 숨겨진 복잡성을 이해하고 팀원들과 더 쉽게 의사소통할 수 있으며 제품 또는 마케팅 같은 비 기술적인 관계자들의 메시지를 단순화 할 수 있을 것이다.

  • 팀원들을 효율적으로 이끌고 기술영역에서 솔선수범할 수 있을 것이다.

  • 팀이 쓸 수 있는 툴과 프레임워크를 숙지하고 더 나은 기술적 방향을 제시할 수 있을 것이다.

  • 팀원들의 신뢰와 존경을 더욱 받기 쉬워질 것이다. 이것은 비기술적 관리자들은 그럴 수 없다는 뜻은 아니다.

  • 향후 컨트리뷰터로 돌아갈 수 있도록 여지를 두어라.


기술력을 갈고 닦는 것은 정말 좋은 생각이라는 것에 다들 동의할 것이다. 그러나 이것들은 도전이 없이는 불가능하다.




코더 vs 멘토


당신이 직면하게 될 첫 번째 도전은 엔지니어로서 그리고 멘토로서의 갈등이다. 엔지니어로서는 팀이 직면한 모든 흥미로운 기술적 도전들을 해결하려 할 것이다. 반면, 멘토로서는 능력을 향상시키고 더 나은 개발자가 되고자 하는 팀원에게 (도움이 되는) 문제를 주고 싶어 할 것이다.


시니어 개발자가 부족하고 주니어 개발자가 많은 팀에서는 이 문제가 심각해질 수 있다. 그럴 경우, 엔지니어링 관리자는 자신의 역할에서 멘토십을 더욱 강조해야 한다.


당신의 팀을 성공적으로 만들어라

어떤 코딩보다도 팀과 팀원들이 우선이다. 당신이 코딩하는 데에 전념할 수 있는 필요조건은 팀이 성공했을 때이다.


관리자로서 당신은 제품을 만드는 것이 아니라, 제품을 만들 수 있는 팀을 꾸리는 것이다. 따라서 팀을 성공적으로 운영하는 것이 자신을 평가할 수 있는 주 목표 및 척도가 되어야 한다. 만약 당신이 행복한 엔지니어들로 구성된 성공적인 팀을 이끈다면 팀의 성공은 따라올 것이고, 팀원과 상사에게 성과를 설명하려는 일에 시간을 덜 보낼 수 있을 것이다.

의사 결정에 병목 현상이 없는 능력을 갖춘 실력있는 팀원들로 이루어진 자립심 있는 팀은 당신이 뭔가 다른 일을 할 수 있도록 해줄 것이다.



당신의 말에는 더 많은 무게가 있다


나에게 또다른 도전은 팀이 기술 문제를 해결하는 방법을 논의할 때 너무 강하게 내 의견을 표현하는 것이었다. 전 팀원과의 feedback session에서 팀원이 알려주기 전까지는 이 문제에 대해 알지 못했다. 그녀는 “우리가 기술 토론을 할 때 당신은 너무 독단적이에요… 팀원들에게 더 양보해야 해요.”라는 식으로 말했다.


일부 관리자는 정말 강경하고 권위있게 말을 하지만, 그것은 다른 이들이 가질 수 있는 의견차를 표현하지 못하게 방해할 수 있고 이는 좋지 못한 해결책으로 귀결될 수 있다는 것을 깨달았다.


그래서 내 조언은?



답을 하기보다는 항상 마지막으로 이야기하고 질문해라

이것은 아무리 강조해도 지나치지 않다. 관리자는 자신의 글이나 말하는 모든 단어가 어떤 식으로든 팀원의 아이디어나 제안을 잠재적으로 침묵시킬 수 있다는 것을 충분히 인지해야 한다.


더 나아가 James Everingham은 양자 역학 비유에서 관리자의 단지 관찰만으로도 프로젝트의 결과를 바꿀 수 있다고 이야기한다.


관찰자 효과는 직장에서 실제로 발생하며, 프로젝트의 관리자가 되는 것만으로도 프로젝트 결과에 영향을 끼칠 수 있다. 종종 관리자는 팀원들을 불러 칠판에 적기 시작하면서 “우리가 해야 할 것들” 또는 “내가 생각한 것들” 또는 “이것에 대해 생각해볼 수 있는 한 방법은...” 이라고 말할 것이다. 그들은 가치를 높이려 노력한다. 또한 우리도 항상 가치를 높이길 원한다. 그러나 여러분이 권위자의 자리에 있고 이런 식으로 한다면 당신은 제한된 결과를 초래한 것이며 성공의 길을 크게 제한한 것이다.



개발자 vs 관리자


내가 직면한 더 큰 도전은 개발자의 시간표와 관리자의 시간표를 조합하는 것이었다. Paul Graham의 말에 따르면,

대부분의 영향력 있는 사람들은 관리자의 시간표에 있다. 이건 지시의 시간표이다. 그러나 프로그래머나 작가같이 뭔가를 만드는 사람들에게는 시간을 사용하는 또다른 방법이 있다. 그들은 보통 적어도 반나절 단위로 시간을 사용하는 걸 선호한다. 글이나 프로그램을 한시간 단위로 쓸 수는 없다. 1시간은 간신히 시작할 시간이다.


간단히 말해서, 관리자의 단편적이고 수동적인 회의 중심의 일정은 코딩에 필요한 집중 요구 사항(일종의 Deep Work 같은)을 잘 나타내지 않는다. 관리자와 엔지니어의 일정은 서로 반대된다고 말할 수 있다. 엔지니어는 가능한 주의가 산만하지 않아야 하는 반면, 미팅에 참석하지 않거나 다른 팀과 소통하지 않는 관리자는 조직에서 충분히 눈에 띄지 않는다는 평을 받을 수 있다.


두 일정을 섞지 마라


http://dilbert.com/strip/2012-05-30



시도조차 하지 마라. 이건 좌절을 느끼게 해주고 비생산적인 방법이다. 물과 기름처럼, 이것들을 분리하고 독립시켜서 본연의 상태 그대로 유지하는 것이 가장 좋다.


나는 점심시간과 같은 자연스런 방해와 내 일정을 분리하려 노력한다. 오전 내내 회의를 계속하고, 지친 상태에서 엔지니어로 돌아와 오후를 보내며 어려운 프로그래밍 문제에 집중하려고 한다. 적어도 일주일에 두 번은 그렇게 하려고 노력한다.

나는 충분한 점심시간을 갖고 가급적이면 사무실 밖에서 산책하면 회의에 있었던 신경을 끊고 다시 돌아와 상쾌한 마음으로 생산적으로 코딩을 할 수 있다는 것을 알게 되었다.


엔지니어일 때는 가능한 집중을 방해하는 모든 것들을 피해야 한다. 우선 이메일을 꺼라. 그리고 브라우저에서 주의를 산만케 하는 모든 탭ㅡ가령 Facebookㅡ을 닫거나 새 브라우저를 열어 찾으려 하는 문서만 참조해라. 끝으로, HipChat/Slack도 꺼라. 물론 긴급 이슈가 생겼을 때 팀원이 당신을 찾을 수 있도록 몇몇의 커뮤니케이션 채널은 항상 열어 놓아야 한다.


생산적이고 집중력을 발휘할 수 있다는 것은 당신의 육체 그리고 정신에 크게 의존한다. 주위 환경을 바꾸거나 조정함으로써(다른 책상/장소에서 일하거나, 특정 유형의 음악을 듣거나 무엇이든 간에), 정신을 최대한 생산적으로 만들 수 있다.


Cal Newport의 책 Deep Work에서 심도깊은 작업을 처리하는 법에 대해 더 많은 요령을 얻을 수 있다.



코드 병목 현상


바쁜 일정을 감안할 때, 아마도 빠른 시일 내에 코딩을 마치기 힘들 것이고, 따라서 아마 일부 기능은 프로덕션에 병합되거나 배포되기 힘들 것이다. 더 나쁜 것은,  뭔가 잘못되기라도 한다면, 운영중인 사이트의 이슈나 파이프라인이 깨졌을 때와 같은 기술적 문제를 급하게 처리하지 못할 수도 있다.


팀의 리더로서 당신은 팀원들이 회의나 대화에 방해받지 않고 코딩에 집중할 수 있도록 분주히 움직여야 한다. 다시 말해서, 당신의 일은 코딩하는 것이 아니라 팀원들이 효율적으로 코딩할 수 있도록 하고 팀원의 성과를 부각시키는 것이다.


코드를 꼭 출시할 필요는 없다??

한 친구와 프로덕션 코드에 직접 참여하고 관여하는 매니저들에 관해 이야기 나눌  때 이런 조언을 해줬다.

팀의 병목이 되어선 안된다. 당신의 도움 없이 모든 기술적인 문제를 해결할 수 있도록 팀원들을 지도하고 멘토가 되어야 한다. 결코 프로덕션 코드를 작성할 필요가 없어야 한다. 코딩에 시간을 많이 할애하는 것은 비기능적인 궂은 일이다. 빌드를 더 빠르게 만들고, 공통된 코드들을 한 라이브러리로 추출해라. 팀의 일을 보다 생산적이고 재미있게 만들어 줄 수 있는 것들을 찾아라. 또한 사내에서 또는 개인적으로 개념 증명(Proofs Of Concepts) 코딩에 초점을 맞추거나 팀에서 사용할 신기술을 찾아본다거나 사이드 프로젝트를 진행함으로써 기술력을 유지시킬 수 있다.


나는 이 충고를 마음에 새겼고 그 결과에 더할 나위 없이 만족했다. 그 과정에서 내가 팀에서의 기술적 병목 현상이 아니란 사실을 알았을 뿐만 아니라, 팀원이 스스로 도전에 직면하고 배우면서 더 나은 개발자가 되어 스트레스를 덜 받게 되었다.


내 기술적 지식을 전달하기 위해 나는 흥미있는 주제에 관해 페어 코딩을 하고, 전 팀에 걸쳐 기술적 문제를 다같이 해결하거나 그저 기술적 지식과 의견을 공유하기 위한 “클린 코드 세션” 또한 운영한다.


요즘 내 코딩의 대부분은 Expedia(익스피디아 알렉사 스킬 같은), markpress 같은 사이드 프로젝트, 쓸모 없지만 쿨한 Rolex GMT 크롬 시작 탭 확장같은 사이드 프로젝트이다.



결 론


코딩까지 할 수 있는 관리자가 되는 것은 마치 투잡을 갖는 것과 같다. 매우 힘들고 또한 많은 헌신이 필요하다. 팀을 이끌고 성장시키는 것과 당신의 기술력 향상 사이에 균형이 잘 잡히지 않으면 벅차거나 지칠 것이다.


나는 리더십과 코딩을 모두 사랑해야 한다고 말하고 싶다. 관리자로서 또는 개발자로서 자신을 성장시키는 데에 더 많은 시간을 할애해야 하기 때문이다. 그러나 그만한 가치가 있다! 결국, 이런 게 삶 아니겠는가.



더 읽어볼 거리





편집자 주 : 이 아티클의 번역 및 배포를 위해 원저작자에게 연락을 했는데, 마침 원저작자인 Joan Gamell의 아내가 한국 분이라며 이 글의 번역 검토도 해주었습니다. 아울러, 함께 일하는 동료 중 한국 분이 이 글의 표현이 잘못 전달되지 않도록 여러 가지 제안도 해주셨습니다. 이 자리를 통해 다시 한번 감사드립니다.

또한 Joan Gamell은 이 글을 읽고 한국의 독자들은 어떤 생각을 하는지 나누고 싶어 합니다. 여러분의 생각과 경험 등을 함께 나누어 주시면 더 많은 사람들에게 도움이 될 것 같습니다. 


저작자 표시 비영리 동일 조건 변경 허락
신고

설정

트랙백

댓글









대표 번역가 : 오치문


개발자는 문제를 해결하는 사람이라고 믿는, 카페모카를 좋아하는 평범한 개발자.

현재 카카오 검색팀에서 일하고 있으며 문제를 깔끔하게 해결하는데 관심이 많다.


원문 링크





데이터 레이크


데이터 레이크(Data Lake)는 빅데이터(Big Data) 세계에서 데이터 분석 파이프 라인의 중요한 구성 요소 중 하나를 설명하기 위해 최근 10년간 등장한 용어입니다. 이것은 조직에서 누구나 분석할 때 필요한 모든 원시 데이터를 저장하는 단일 저장소를 갖는 것을 의미합니다. 일반적으로 사람들은 레이크(단일 저장소)의 데이터를 처리하기 위해서 하둡을 사용하지만, 데이터 레이크의 개념은 하둡보다 광범위합니다.

 

조직에서 분석하고자 하는 모든 데이터를 한 곳에 모은다고 들었을 때, 저는 바로 데이터 웨어하우스(그리고 데이터 마트[1])의 개념이 생각났습니다. 그러나 데이터 레이크와 데이터 웨어하우스 간에는 중요한 차이점이 있습니다. 데이터 레이크는 그것이 어떤 형태든, 데이터 소스가 제공하는 그대로의 원시 데이터를 저장합니다. 데이터 스키마에 대한 가정은 없으며 각 데이터 소스는 원하는 스키마를 사용할 수 있습니다. 따라서, 자신의 목적에 맞게 데이터를 이해하는 것은 데이터 소비자에게 달려있습니다.

Screen Shot 2017-06-29 at 11.08.09 AM.png

 

이것은 기존에 비해 진일보 한 것인데, 많은 데이터 웨어하우스들은 스키마 문제로 인해 멀리 가지 못했습니다. 데이터 웨어하우스는 모든 분석 요구에 대해 하나의 스키마 개념을 사용하는 경향이 있습니다. 저의 견해는 이런 단일 통합 데이터 모델은 아주 작은 조직을 제외하면 비현실적이라는 것입니다. 조금이라도 복잡한 도메인을 모델링하려면 각각의 데이터 모델과 함께 여러 개의 BoundedContext가 필요합니다. 분석 측면에서 보면, 자신이 수행 중인 분석에 적합한 모델을 사용하는 여러 분석가들이 필요합니다. 원시 데이터만 저장하도록 전환하면 데이터 분석가가 이 책임(각 컨텍스트에 맞게 이해하고 모델링 하는 것)을 지게 됩니다.

 

데이터 웨어하우스의 또 다른 문제점은 데이터 품질을 보장하는 것입니다. 데이터에 대해서 신뢰할 수 있는 하나의 소스를 얻으려면, 다른 시스템에서 어떻게 데이터를 수집하고 사용하는지에 대해 많은 분석이 필요합니다. 어떤 데이터에는 시스템 A가 좋고, 다른 데이터에는 시스템 B가 좋을 수 있습니다. 예를 들면, 시스템 A는 더 최근의 주문에 대해 좋을 수 있지만, 반품이 포함되지 않은 조건에서 한 달 또는 그 전의 주문에 대해서는 시스템 B가 더 좋을 수 있습니다. 무엇보다도, 데이터 품질은 종종 주관적인 문제이며, 각 분석마다 데이터 품질 문제에 대해 서로 다른 허용 오차를 가집니다. 심지어 무엇이 좋은 품질이냐에 대한 개념도 다릅니다.

 

이것은 데이터 레이크에 대한 흔한 비평을 야기합니다. 단지 광범위한, 다양한 품질의 데이터 쓰레기장이라는 것, 좋게 말해 데이터의 늪이라는 비평입니다. 비평은 타당하면서도 부적절합니다. 새로운 분석론에서 화제가 되고 있는 명칭이 ‘Data Scientist’입니다. 비록 이것이 남용되고 있는 명칭이지만, 여기에 속한 많은 사람들이 과학 분야에서 견고한 배경을 가지고 있습니다. 그리고 어떤 훌륭한 데이터 과학자는 데이터 품질 문제에 대해 모든 것을 알고 있습니다. 시간이 지남에 따라 온도 판독 값을 분석하는 간단한 문제를 생각해 봅시다. 측정치에 미묘하게 영향을 미치거나, 장비의 문제로 인한 이상, 센서가 작동하지 않는 기간 등의 이유로 일부 기상 관측소의 이전을 고려해야만 합니다. 하지만 많은 정교한 통계 기술이 데이터 품질 문제를 해결하기 위해 만들어졌기 때문에 이런 문제를 해결할 수 있습니다(즉, 어느 정도 오차가 있어도 관측소를 이전하지 않아도 됩니다). 데이터 과학자들은 항상 데이터 품질에 회의적이며, 의심스러운 데이터를 다루는 데 익숙합니다. 그래서 그들에게 데이터 레이크는 중요합니다. 왜냐하면 그들은 원시 데이터로 작업을 하고, 불명료한 데이터를 정제하는 메커니즘보다는, 데이터를 이해하기 위해서 더 나은 분석기술을 적용하는 것을 신중하게 고려해볼 수 있기 때문입니다.

(역자 주. 간단히 정리하면, 저자는 데이터 쓰레기장이라는 비평에 대해서, 데이터 레이크에 다양한 품질의 데이터가 섞여있는 것은 인정하지만 데이터 분석 기술로 커버할 수 있다는 것을 이야기 하고싶은 것같습니다.)

 

일반적으로 데이터 웨어하우스는 단순히 데이터를 정제하는 것뿐만 아니라 분석하기 용이한 형태로 모읍니다. 그러나 이 과정에서 데이터의 일부가 버려질 수 있기 때문에 데이터 과학자들은 이점에 대해서도 반대하는 경향이 있습니다. 데이터 레이크는 반드시 모든 데이터를 저장하고 있어야 하는데, 그 이유는 어떤 사람이 오늘 혹은 2년 내의 데이터에서 가치를 찾아낼지 모르기 때문입니다.

 

저의 동료 중 한 명이 최근의 한 사례를 들어 이 점에 대해 설명했습니다.

“우리는 우리의 자동 예측 모델과 회사의 계약 관리자들이 작성한 수동 예측을 비교하려고 했습니다. 그러기 위해서 우리의 모델을 당시의 데이터로 학습시키고, 우리의 예측 결과와 그 당시 관리자들의 예측 결과를 비교하려고 했습니다. 우리는 지금 정답을 알고 있기 때문에, 이 방법은 정확도 시험에 적합했습니다. 이 시험을 시작했을 때, 관리자들의 예측은 끔찍했고 불과 2주 만에 만들어진 우리의 단순한 모델 조차도 그들의 예측보다 나았습니다. 우리는 이 엄청난 성과를 사실로 받아 들이기에는 의심스럽다고 생각했습니다.

많은 테스트와 분석 후에 우리는 관리자의 예측들과 관련된 타임 스탬프가 잘못되었다는 것을 알게 되었습니다. 이 값들은 월 말 처리 보고서에 의해 수정되었던 것입니다. 간단히 말해서, 데이터 웨어하우스에 저장된 예측 값들은 쓸모가 없었습니다. 우리는 예측 비교를 수행할 방법이 없을 것이라고 우려했습니다. 더 많은 분석 후에 우리는 이 보고서가 저장되어 있는 것을 발견했고, 그 당시의 실제 예측을 추출할 수 있었습니다. (우리는 다시 관리자들의 예측보다 나은 결과를 얻었지만, 여기에 많은 시간이 필요했습니다).”

 

원시 데이터의 복잡성은 데이터를 보다 관리하기 쉬운 구조로 조정할 수 있는 여지가 있음을 의미합니다(또한 상당한 양의 데이터를 줄일 수 있습니다). 데이터 레이크에는 직접 접근하도록 해서는 안됩니다. 데이터 레이크에 저장된 가공되지 않은 데이터(원시 데이터)를 이해하기 위해서는 많은 기술이 필요합니다. 데이터 레이크를 이용해서 일하는 비교적 적은 사람들이 레이크에 있는 데이터로 일반적으로 유용한 뷰를 발견합니다. 또한 그들은 많은 양의 데이터 마트들을 만들어내는데, 각각의 데이터 마트는 하나의 bounded context에 맞는 특정한 모델을 갖습니다. 그렇게 되면 많은 다운스트림 사용자들이 이런 레이크쇼어 마트들을 각 컨텍스트에 맞는 신뢰성 있는 데이터 소스로 취급할 수 있습니다.

Screen Shot 2017-06-29 at 11.08.39 AM.png

지금까지 저는 데이터 레이크를 기업 전체의 데이터를 통합하는 단일 지점으로 설명했지만, 이것이 원래 의도 된 것은 아니라는 점을 이야기 해야겠습니다. 데이터 레이크는 James Dixon이 2010년에 처음으로 쓴 표현인데, 그의 의도는 데이터 레이크가 하나의 데이터 소스로 사용되는 것이고, 여러 개의 데이터 소스가 ‘water garden’으로 형성되는 것이었습니다. 이런 기원에도 불구하고, 지금은 일반적으로 데이터 레이크가 많은 데이터 소스들을 통합하는 것으로 사용되고 있습니다. [2]

 

데이터 레이크를 분석 목적으로만 사용하고 운영 시스템들 간의 연동을 위해 사용해서는 안됩니다. 운영 시스템과의 연동은 이 목적으로 설계된 RESTful HTTP 호출이나, 비동기 메시징 같은 서비스들을 이용해야 합니다. 데이터 레이크는 운영용 통신망으로 사용 하기에는 너무 복잡합니다. 데이터 레이크의 분석으로 인해 새로운 운영 통신 경로가 만들어질 수 있지만, 이런 것들은 데이터 레이크를 통해서 하기보다는 직접 구축해야 합니다.

 

데이터 레이크로 유입되는 모든 데이터가 장소와 시간에 대해 명확한 출처를 가져야 한다는 것은 매우 중요합니다. 모든 데이터에는 데이터가 어떤 시스템으로부터 유입되었는지, 그리고 언제 데이터가 생성 되었는지에 대한 명확한 흔적이 있어야 합니다. 그러므로 데이터 레이크는 역사적인 기록을 포함합니다. 이런 기록들은 아마도 Event Sourced 시스템과 자연스럽게 어울리는 도메인 이벤트들을 데이터 레이크에 저장할 때 발생할 것입니다. 하지만, 현재의 상태를 데이터 레이크로 정기적으로 덤핑하는 시스템에서도 역시 발생할 수 있습니다(소스 시스템에 시간과 관련된 것은 없지만, 시간에 따른 데이터 분석이 필요할 때 유용한 접근방식). 이에 따른 결과로, 데이터 레이크에 입력된 데이터는 변경되지 않고, 한 번 기술된 기록은 삭제될 수 없으며(나중에 잘못된 것으로 판별될 수는 있지만), Contradictory Observations(모순된 관찰)를 예상해야만 합니다(예를 들어, 같은 id로 처음에 들어온 값과 나중에 들어온 값이 달라질 수 있는 문제).

 

데이터 레이크는 스키마가 없으므로, 어떤 스키마를 사용할지는 소스 시스템에 달려 있고, 스키마가 없음으로 인해 발생하는 혼란을 처리하는 방법은 데이터 소비자가 결정해야 합니다. 게다가 소스 시스템은 자신이 유입시키는 데이터 스키마를 자유롭게 변경할 수 있으며, 소비자는 이에 대처해야 합니다. 당연히 우리는 가능한 한 최소한의 영향을 미치는 변화를 선호하지만, 데이터 과학자들은 데이터를 잃어버리는 것보다는 차라리 지저분한 데이터를 선호합니다.

 

데이터 레이크는 매우 커질 것이고, 저장소의 대부분은 스키마 없는 큰 규모의 구조를 지향합니다. 이것이 일반적으로 사람들이 데이터 레이크를 구현하는 기술로 하둡과 HDFS를 사용하는 이유입니다. 레이크쇼어  마트들의 중요한 작업 중 하나는 처리해야 하는 데이터의 양을 줄이는 것입니다. 그렇게 함으로써 대용량 데이터 분석에서는 많은 양의 데이터를 처리할 필요가 없게 됩니다.

 

원시 데이터의 범람에 대한 데이터 레이크의 욕망은 개인정보와 보안에 관해 난처한 질문을 야기합니다. Datensparsamkeit(독일어. 데이터를 캡처하고 저장하는 방법에 대한 자세로서 우리가 실제로 필요한 데이터만 처리해야 한다는 내용)의 원칙은 모든 데이터를 캡처하려는 데이터 과학자들의 욕구와 대치됩니다. 데이터 레이크는 공개된 바다를 선택하는 것을 좋아하는 크래커들에게 유혹의 대상이 됩니다. 소규모 데이터 과학 그룹에 한해서 데이터 레이크에 직접 접근하도록 제한하면 이 위협이 줄어들지만, 이 그룹이 항해 중인 데이터의 개인 정보 보호에 대해 어떻게 책임을 질 수 있는지에 대한 질문을 피할 수 없습니다.

 

 

Note

1 : 데이터 마트는 조직에서 단일 부서를 위한 것인 반면, 데이터 웨어하우스는 전 부서를 아우르는 통합을 위한 것이 일반적인 구분입니다. 데이터 웨어하우스가 모든 데이터 마트의 조합이 되어야 하는지, 아니면 데이터 마트를 데이터 웨어하우스에 존재하는 데이터의 논리적 하위 집합(뷰)으로 볼 것인지에 대해서는 서로 다른 의견들이 존재합니다.

 

2 : 이후의 블로그 포스트에서 Dixon은 데이터 레이크와 ‘water garden’의 구별을 강조하지만, (주석에서) 그것은 사소한 변화라고 말합니다. 제가 생각할 때 핵심은 데이터 레이크가 많은 양의 데이터를 가공되지 않은 상태로 저장한다는 것이고, 피더 스트림의 수는 별로 중요하지 않다는 것입니다.

 

감사 인사

Danielo Sato, David Johnston, Derek Hammer, Duncan Cragg, Jonny Leroy, Ken Collier, Shripad Agashe 및 Steven Lowe에게 내부 메일링 리스트에서 이 게시물의 초안을 논의한 것에 대해 감사의 말을 전합니다.

 

 

저작자 표시 비영리 동일 조건 변경 허락
신고

설정

트랙백

댓글

Deview 2016 행사가 다음 주로 다가왔습니다.


도서정가제로 인해 더이상 독자들에게 도서 할인 행사를 진행할 수 없어 어떻게 조금 더 재미있는 시간을 함께 만들어볼까 고민하던 차에 페이스북을 통해 여러 가지 의견을 수렴하여 몇 가지 이벤트를 기획하게 되었습니다.




참석 하시는 많은 분들의 참여 부탁드립니다.

저작자 표시 비영리 동일 조건 변경 허락
신고

설정

트랙백

댓글

이 글은 미국에서 data scientist이고 machine learning 분야 박사학위자이며 현재 senior software engineer인 유시진(가명)님이 유학을 준비 중이거나 미국에서 IT 업체에 취업을 하고자 하는 개발자들에게 도움을 주고자 글을 작성하여 저에게 보내주신 내용을 제가 정리하여 공유해드리는 글입니다. 

​조금 더 많은 분들에게 도움을 드리고자 새롭게 시작한 브런치의 매거진에도 함께 공유를 합니다. 꼭 가명으로 올려달라고 하셔서 그냥 딱 생각난 이름을 도용했으니 많은 여성분들은 오해 없으시길 바랍니다.




이 글은 미국에서 구직 중이신 분들께 도움을 드리고 싶어서 썼습니다. 제가 그동안 구직 활동을 하면서 경험했던 것들을 정리해서 말씀드리겠습니다. 즉, 제 경험을 바탕으로 한 것이니 주관도 들어갈 수 있습니다. (본 글은 지원자가 미국에서 학교를 다니는 기준으로 하겠습니다.)


미국의 채용 과정(job process)은 다음과 같습니다.


일자리 지원(Job apply) -> 초기 전화 심사(Initial Phone Screen, 채용 담당자, 선택사항) -> 온라인 평가(Online assessment, 선택사항) -> 전화 인터뷰(Phone Interview) -> 현장 인터뷰(Onsite Interview) -> 일자리 제안(Offer)


1. 일자리 지원

회사에 지원하는 방법은 여러 가지가 있지만 제일 좋은 방법은

1.1 본인의 대학에서 열리는 채용 박람회(Career Fair)에 가는 겁니다. 이력서(Resume)를 주고 채용 담당자(Recruiter) 또는 엔지니어(Engineer)와 이야기를 나눌 건데 30초 안으로 자신의 강점을 말하는 게 중요합니다. 보통 회사는 대학 채용 박람회에 올 때 며칠 안으로 인터뷰를 진행하는 경우가 많습니다. 즉, 보다 빨리 채용될 수 있습니다.

1.2 두 번째 방법은 LinkedIn입니다. LinkedIn에서 job tab으로 들어가셔서 지원을 하거나 LinkedIn에 이력서를 상시 업데이트하면 채용 담당자에게서 연락이 자주 옵니다. 또는 본인이 가고 싶어 하는 회사의 엔지니어와 connection 요청을 하시는 것도 좋은 방법입니다. 채용 담당자에게 email로 직접 본인의 이력서와 원하는 job link를 문의하는 것도 좋습니다.

1.3 가장 보편적인 방법은 회사 웹사이트에 들어가서 지원하는 겁니다. 단점은 이 중 가장 시간이 오래 소요됩니다. 이력서가 수시로 들어오기 때문에 채용 담당자가 놓치는 경우가 많습니다.

1.4 제일 중요한 점은 각 팀마다 요구하는 기술사항이 다르므로 한 회사에서도 여러 군데에 본인이 원하는 직군에 이력서를 많이 보내는 게 좋습니다.


2. 초기 전화 심사(채용 담당자, 선택사항)

말씀드렸듯이 이는 선택사항입니다. 채용 담당자가 본인이 이 역할에 잘 맞는지 더 자세히 알기 위해 엔지니어와 인터뷰 전 전화로 이 사람이 업무를 잘 수행할 수 있는가 알아보는 시간을 갖습니다. 이를 통과하면 채용 담당자가 엔지니어 팀에 이력서를 넘기고 보통 팀 매니저가 결정을 합니다. 시간은 보통 10~15분 정도가 소요됩니다. 


3. 온라인 평가(선택사항)

요즘 온라인 평가(테스트)를 채택하는 회사들이 (e.g. Yelp, Amazon) 많습니다. https://www.hackerrank.com/ 사이트를 자주 사용하고요. 문제가 주어지고 본인이 원하는 프로그램 언어(program language)를 선택하신 후 algorithm을 작성하면 자동으로 사이트에서 채점을 합니다. 주어진 시간은 20분 ~ 1시간 정도입니다. Data structure를 공부했으면 그렇게 어렵지는 않지만 한국에서만 정규 교육을 받은 분들에게는 연습이 요구됩니다. 저도 한국에서 학부를 나왔지만 미국은 algorithm 구현하는데 수업을 많이 투자하기 때문에 처음에는 어렵습니다.


4. 전화 인터뷰

아마 가장 많이 접하실 거고 가장 많이 떨어지기도 하는 테스트입니다. 크게 인터뷰는 두 가지로 분류할 수 있습니다. 30분짜리 인터뷰이면 아마 지식 혹은 경험(knowledge) 부분만 물어볼 텐데 꽤 어렵습니다. 1시간짜리 인터뷰가 제일 보편적이고요, 10분 정도 이력서 심사(resume screen)를 하고 바로 코딩(coding) 문제로 들어가거나 지식 혹은 경험(knowledge) 부분을 조금 물어볼 수 있습니다. 코딩 테스트(coding test)를 할 때는 인터뷰어가 문제를 불러주고 본인이 인터넷을 통해 코딩을 하게 되는데 Google doc 같이 실시간으로 본인의 코드를 보게 됩니다. 이 중 주의할 부분은 인터뷰어가 중점으로 두는 사항은 (1) 문제를 잘 이해했는가? (2) 어떻게 문제에 접근하는가? (틀려도 좋습니다. 과정이 중요합니다.) (3) Big O notation에 대해서 잘 이해하는가? (4) Data structure에 대해서 잘 아는가? 를 가지고 판단합니다.

코딩을 할 때는 반드시 코딩만 하지 말고 "당신이 원하는 요구사항은 input이 이럴 때 이러한 output을 원하는가"를 꼭 물어보시고, 코딩을 하면서 "나는 data structure 중 linked list를 사용하겠다. 이유는 ~~~이고 timecomplexity는 이렇게 나올 것이다. 내가 만드려고 하는 algorithm은 대충 이러한 procedure를 가질 것이다"라고 먼저 설명을 한 다음 코드를 짜야합니다. 그리고 코드를 짜면서 꼭 말을 하면서 해야 합니다. 안 그러면 인터뷰어가 이 사람이 뭐하는 건지를 모르겠죠? 말을 하면서 코드를 짜야 본인을 더욱 어필할 수 있습니다. 코딩이 끝난 다음은 디버깅(debugging)을 해야 합니다. input에 어떤 값을 넣고 본인 코드에서 어떠한 일들이 일어나고 output으로 원하는 결과가 나온다는 것을 인터뷰어에게 디버깅하면서 보여주는 게 좋습니다.


말씀드리고 싶은 것이 많지만 간략하게 정리만 해 드리는 게 목적이므로 책을 소개하고 넘어가겠습니다.

https://www.amazon.com/Cracking-Coding-Interview-Fourth-Programming/dp/145157827X/?&&-14&+interview+questions

PDF로 찾으시면 다 나오고요, 다 보실 필요는 없고(1) Arrays and Strings (2) Linked Lists (3) Stacks and Queues (4) Trees and Graphs (5) Sorting and Searching (6) Recursion 정도만 공부하시면 도움이 많이 되실 겁니다.



5. 현장 인터뷰

전화 인터뷰를 잘 보셨으면 당일 ~ 일주일 내에 채용 담당자가 채용 인터뷰 초대를 할 겁니다. 현장 인터뷰는 직접 회사에 가서 시험을 보는 겁니다. 3시간 ~ 5시간 정도 소요되고요, 그 이상을 하는 경우도 있습니다. 비행기표와 호텔비, 식사비는 보통 회사에서 모두 지원을 합니다. 인터뷰는 칠판에 코딩을 하거나 지식 혹은 경험(knowledge)에 대해서 물어보는 식입니다. 코딩은 전화 인터뷰보다 어렵고요, http://www.geeksforgeeks.org/ 또는 leetcode.com에 나오는 문제 수준입니다. 지식 혹은 경험(knowledge) 부분은 아무래도 벼락치기는 상당히 어렵습니다. 저의 경우에 MapReduce를 인터뷰어가 전혀 모른다고 가정을 한 다음 칠판에 설명을 해보라는 식이었습니다. 그리고 시스템을 어떻게 구현할 것인지 아키텍처를 그려보라고도 하고, 아키텍처가 마음에 들면 세부적인(detail) 부분을 물어봅니다. 즉, 현장 인터뷰에서는 본인의 모든 실력을 다 발휘하셔야 합니다.


6. 일자리 제안

이 모든 것을 통과하시면 합격 통지를 받으시게 됩니다.


두서없이 썼네요. 아무튼 도움이 되셨길 바랍니다.



편집자 주 1 : 기고자께서 대부분의 용어를 영문으로 작성하여 주셨으나 가급적 읽기 편하게 한국어로 바꾸었으며, 프로그래밍 용어의 경우는 그대로 영문으로 표기해 었습니다.

편집자 주 2 : knowledge의 경우는 지식이라는 뜻도 있지만 아무래도 개발자의 경험 또한 인터뷰 당시 중요하게 보는 듯하여 '지식 혹은 경험'이라고 번역하였습니다. 

저작자 표시 비영리 동일 조건 변경 허락
신고

설정

트랙백

댓글


티스토리 툴바