현업 솔루션 이해 (1)

Q

• 왜 다른 거 놔두고 GET, POST로 모든 걸 때워요? 어쩌다 그렇게 됨?
  • 현장에서 아주아주 옛날 버전을 쓰는 경우도 있다. 거기까지 다 호환성을 챙기려다보니 그래 됐다. 근데 delete 이런 기능 좋긴 해.
• 왜 HTTP 상태 코드 안 쓰고 새로 만들어서 써요?
  • 필요한 만큼만 원하는 대로 쓰고 싶었기 때문
• 암호화라는 게 뭐 SHA-256 이런 알고리즘 이름은 많이 알려져있잖아요. 그러면 이게 입출력 로직이 이미 밝혀진 게 아닌가? 그거 써도 보안 ㅇㅋ인가요? 그러니까 내 말은 암호화 로직을 뭘 쓰는지 말하면 리버스 엔지니어링이 가능한 거 아니냐는 말임.
  • 해시를 알면 된다. 공부해보세요. 해시 중요합니다.
  • 간단히 쓰자면 공개키와 비공개키가 둘 다 있어야 복호화가 가능한데 보통 쓰이는 키는 공개키고 비공개키는 복호화를 하는 주체만 갖고 있음. 그러니까 공개키랑 암호화 알고리즘을 알아봤자 비공개키가 없으면 복호화가 안되고, 그 공개키와 비공개키의 쌍을 해시로 관리한다는 것 같음.
• 요즘 면접 트렌드
  • B2B, B2C 나눠서 생각하면 좋을 것 같다. B2B로 서류를 쓰면 그에 맞는 용어를 잘 써야 하고, B2C라고 타겟을 삼으면 그에 맞게 쓰고 뭐 그런 목표 설정을 똑바로 한 다음에 자소서를 써라.
  • 만약 다 붙고 면접 갔으면 질문 자체가 달라짐. B2C 면접 가면 첫 질문이 우리 회사 제품에서 어떤 점 개선해야 할지 생각해봤음? 물어봄. 5가지 대답하래. → 사실 자사 제품 및 서비스에 대한 관심과 애정 테스트한거임
  • B2B는 면접에서 뭘 물어보느냐,,, 보안적 이슈가 되게 많이 나옴. 사용자 시각화를 해야 하는데, 보안적으로 어떻게 할 거야? 라는 식으로 물어본대. 요즘 보안 예민하죠. 그래서 더 많이 물어보는 것 같음.
    • (자사 기술 스택) 써보셨나요? 안써봤으면 일 못할텐데 어쩔거임? → 그래서 아무거나 다 먹어보라는 거임.
• F-BI는 데이터 수집+모니터링까지만 하는 거임 아님 설비에 제어 권한이 있음?
  • 원청 데이터는 수정할 수 없다. 우리는 각 설비에 대한 전문가가 아니기 때문이고, 그 전달 주체는 공장장임. 의사결정권자들이 우리 제품을 보고 의사소통하고 판단하고 처리하고 확인할 뿐임.
  • 그럼 시간이 너무 오래걸리지 않음?
  • 라인이 멈출 때를 대비해서 버퍼를 좀 둔다. 수리 여유 시간을 주는 거임.
• 요즘 다양한 기업에서 사내 AI 많이 쓰는데, BI는 어떻게 써먹고 있나?
  • 우리는 코파일럿 많이 쓴다. AI한테 일단 뭔가 시킨 다음 사람이 고침. 일을 시키면 반쪼가리만 해오거든. 근데 결과를 보면 이제 한두줄만 조금 고치면 해결될 수준이거든. 사람은 그걸 고침.
  • 지금은 AI를 써서 얼마나 빠르게 문제를 딱딱 해결하는가가 중요함
  • 괜히 맨땅 헤딩하지 말고 그냥 AI 쓰세요
• 면접 끝나고 더 할말 있냐 할 때 똘똘한 질문 하나씩 하고 나가면 되게 좋아하신다. 그냥 나가면 관심 없나? 함.
• 스프링부트나 닷넷 자바 이런 거 비중 어케됨?
  • 일단 레거시와 신규 플젝이 있을거잖아요. 신규는 다 자바로 가자는 얘기가 나오고 있고 레거시 → 신규 개편 프로젝트는 C#에서 자바로 가는 게 많다. 그래서 둘 다 알고 쓸 줄 알아야 한다. 앞으로도 그래 할듯.
• 인도 공장에서 하루 8키로 걸었다는데, 님 프엔이잖아요. 프엔이 공장에 그렇게 많이 나가?
  • 개발자들이면 다 방구석에 있는 줄 알죠. 나는 프엔이기 이전에 프로젝트 리더임. PL은 주재원과 현장 사람들이 주문하면 바로 달려가서 처리하거나 안되면 안된다 말하는 직책임. 근데 문제가 뭐야? 모든 현장직들의 전번을 알 수가 없어. 그래서 가서 물어봐야돼.
• 그럼 문제 생기면 많이 소환되나? 아뇨.
  • 문제가 생기면 현장직에게 전화를 하고 설비 담당이 해결한다.

현직자 특강 오전

• 현대오토에버에 제공하는 플랫폼 생김새 보여줌
  • 뭐 로그인 권한 관리 메뉴 관리 등등 코어 로직을 제공사에서 별도 관리한다 하심
  • 제조 특화 플랫폼이기 때문에 안정적이고 빠르게 서비스를 제공하기, 최소 비용으로 개발할 수 있게 제공하기 등등이 우선이라 함
• 현대오토에버는 SI기업이에요 SI 아세요?
  • 서비스 기업은 서비스만의 뽄새가 있고 SI는 SI만의 뽄새가 있어요
  • SI는 고객사를 위해 어떤 플랫폼이나 서비스를 다 개발해서 갖다주는 외주 기업
  • 그럼 서비스 기업과의 차이가 뭐예요? 일단 자율성 떨어진다 ㅇㅋ 하셨고 다음 차이는 못들었음^^
  • 자율성이 떨어진다는 말이 무슨 뜻이냐? 고객사가 원하는 요건 비용 기간 맞춰서 타협해서 일해야 한다는 거임
• 어떤 서비스를 만들 때 요건을 정의를 해야죠. 요건은 두 가지예요. 기능적 요건과 비기능적 요건
  • 기능적 요건: 메뉴가 어디에 있어야 하는지, 화면에는 무엇이 나와야 하는지 등
  • 비기능적 요건: 렌더링 속도 성능 등. 백엔드 경우 API 호출 응답 시간 제한. 고객의 경우 “2초 안에는 이게 나오면 좋겠다”라는 식.
  • 개발 처음 할 때는 이런 요건을 정의해놓고 시작하는 게 좋다.
• 지금 AI 잘만 쓰면 뭐든 다 해. 이제 필요한 건 소프트스킬과 아키텍처 능력이에요. AI한테 시키는 것도 그런 정의가 잘 되어 있어야 해요.
• 오늘 할 건 요건에 대한 얘기. 내내 그것만 할거임. 머리에 개념 박아놓고 가게 해줄게.
• 근데 웹 개발 요구하신 이유는 좀 알겠음. 그렇지 대체로 보통 플랫폼은 웹으로 제공되긴 해.
• 어떤 프로젝트를 하든 공통적으로 들어가는 요건이 있다. 로그인, 계정 관리 등등
  • 생각을 해봐. 개발자마다 로그인 로직이 달라. 누가 하면 기깔나게 로그인이 잘되는데 누가 하면 로그인만 해도 메모리가 터지고 서비스가 터져. 입구컷을 당해. 그럼 얼마나 힘들겠어요. 이런 걸 공통화시키고 플랫폼화해서 만든 게 SFaaS다.
  • 만약에 공통요건을 다 다른 사람들이 개발한다 생각해봐요. 상위에서 아무리 뭘 시키고 던지고 해도 만들기가 참 힘들어요. 그런 구조면 일이 진행이 안돼요. 구조적 문제를 해결하기 위해 자꾸 이런 플랫폼이 생기는 거야.
  • 제조 IT는 사용자가 많지 않아요. 공장 내부 인력들만 사용하는 서비스예요. 트래픽 많지 않죠. 게다가 요새 공장에 사람도 줄어요. 많아봐야 천명대야. 요즘 그정도 트래픽 무난하지. 그정도만 하면 됨 ㅇㅇ.
• 요즘 개발할 때 중요한 게 데브옵스 체계를 갖추는 거다. 요즘엔 개발하고 던지고 하지 않는다. 운영까지 애프터 서비스를 해야 한다. 그러니 님들도 준비할 때 그것까지 생각하셔야 돼요. 나 프론트 하고 싶어 한다고 프론트만 하면 안돼. 백 하고 싶어 한다고 그냥 무지성으로 자바 스프링부트 잡고 코드 짜내면 안돼 클로드가 더 잘해. 데브옵스 체계 공부도 같이 하세요.
• 서비스를 운영한다는 건 개발에서 끝나는 게 아니에요. 사실 운영팀이 따로 있어야 하는데 SI에는 그게 없어. 그냥 개발팀이 북 치고 장구치고 다 해. 근데 AI가 있어서 그게 돼. 그러니 님들은 같이 공부하세요.
  • 들으면 들을수록 웹앱반 가셔야 하지 않나 싶어짐.
• 잘하는 사람은 걍 보여요. 고만고만한 인간들은 다 비슷하게 생겼어요. 님들 지금 취준하시니까 최대한 넓게 학습하는 거 권장드립니다. 어디까지?는 AI가 다 알려줌. 질문을 많이 하세요. 요즘엔 시간 없고 환경 안좋다 주변에 현업자가 없다 이런 핑계 안통함. 지피띠니가 다 알거든요. 질문 많이 하고 쪽 빨아먹으세요. 머리로 외우기만 하지 말고 집에 가서 바로 지피띠니 굴리세요. 만들어. 함 해봐. 산출물 관리도 해야 할 거 아님.
• 산출물은 어떻게 관리하겠어요? 깃허브? 그건 개발자들만 쓰는 거잖아. PM님이나 고객사 등등 다른 사람들도 볼 수 있는 것에는 컨플루언스 Jira 같은 거 씁니다. 이력 관리 산출물 관리 이런 거 해요.
• 개발자들끼리 소통은 어떻게 할까요?
  • 주석 좋은 방법이에요. 주석 잘 쓰는 것도 중요해요.
  • 깃이라는 게 협업관리 툴인데 이 개발이라는 게 형상 관리가 참 어려워요. 깃이 그게 다 되게 해준거임. 변경 추적 이력 관리가 다 됨.
  • 개발 중 생기는 이슈에 대해서는 코드리뷰를 한다. 각자 브랜치를 따서 지라 마일스톤에 매핑되는 브랜치를 따서 각자 작업을 하고 마스터 브랜치에 머지 Req를 올려. 그럼 파트별로 코드리뷰 하고 그러는 거야.
  • 그래서 글을 쓰는 역량도 중요합니다. 개발자의 글쓰기 같은 책 많이 보세요. AI 생성은 되지 근데 개발자 각각의 가치관이라는 게 있잖아요. 누구는 클린코드 관점에서 중복 제거에 곤조,,가 있으시거나 파이프라인을 짜는 게 중요한 사람이 있으니 다 리뷰 스타일이 다름. 리뷰 쓸 때 글로 잘 써야 상대가 다시 물어볼 일 없겠죠?
  • 글 못쓰는 인간들은 자꾸 대면으로 해결하려고 해. 저 그거 되게 싫어하거든요.(라고 강사님이 말씀하심)
  • 요약: 글 잘 쓰기 똑바로 쓰기, 산출물 관리 함 해보기. 누가 봐도 다 이해할 수 있는 문서 작성하기.
• 네카라쿠배 테크 블로그 문서 많이 참고하세요 그런 글 쓰시라고요. 일단 개발을 해봐. 요건 정의랑 산출물 관리 정도만 해도 커트라인은 넘을 수 있지 않을까.
• 현차 특 “안해봤으니까 시키지 할 수 있는 방법 찾아와” 쇳물부터 차까지 전부 다 하려 함. 고로? 현차 취업하고 싶으시면 이런 정신을 좀 미리 박아놓고 오세요 정신 나갑니다. 자소서에도 쓰시고요.
• 강사님은 강제로 프론트 전직당하셨다 함. 근데 SI 기업은 이렇게 시킨다 함.
• 클린코드 읽어보세요 꼭 하세요 진짜 꼭 보세요
• 신입은 어차피 못하는 거 다 알아서 기술스택 별로 신경 안씁니다. 서류와 실제 머리의 차이는 면접에서 5분만 봐도 알아. 완벽해지려고 하면 안되십니다. 내가 어디까지 알아야 하지 라는 고민을 안해도 돼요 그냥 거기까지 안물어봄. 신입 채용에서 보는 건 성장 가능성임. 성장 가능성, 잠재력이 있고 그 사람의 깔이 우리 깔이랑 맞는지 보는거임.
• 말을 잘 하셔야 돼요. 제일 어려운 거 아는데 잘 해야함. 말할 때 안 좋은 버릇 있는 것도 서로 알려주면서 고치고 그러셔야 해요. 개인 플젝 하지 말고 팀플을 하세요. 뭐 대단한 걸 1인창업할 거 아니면 의미 ㄴㄴ임. 최소 5명. 리더가 제일 좋음. 그건 당연한거임.
• 팀장을 해보면 전체 프로젝트의 사이클도 알 수가 있어. 팔로워는 그걸 몰라.
• 개발은 안어려워. 어려운 건 고객 응대임. 오토에버는 SI 기업이잖아. 클라이언트가 갑임,, 거기에 프로젝트의 목숨이 달렸음.
  • 만약 커뮤 능력이 딸리면 현업 가서 다 들켜요.
• MSA 구조 알아두세요
  • 옛날엔 하나의 프로젝트로 관리를 했는데 요즘은 이것저것 붙은 게 많으니까 빌드 배포가 오래걸리고, 파츠 하나가 고장나면 다같이 죽어버려서 MSA가 생겨났다
  • 도메인이나 서비스 단위로 나눠서 아키텍처를 구성하는 방식임
• 요즘 시대에 코드 직접 짜는 건 별로임. AI가 더 잘함. 근데 프롬프트를 잘 쓰는 건 님들이 배워야 함. 사실 클린코드 기반으로 해줘 하고 주문해도 되긴 하는데, 조직마자 코드 스타일이 있고 기존 코드베이스가 있기 때문에 냅다 그렇게 주문하면 안됨. 그거 잘못 건드렸다가 전부 뒤엎어버리는 경우가 있음.
• 협업용 브랜치에 대한 지식은 신입에게도 요구됨. 바로 협업해야 하니까.
• 깃, 지라, 컨플루언스까지는 형상 관리랑 산출물 관리 툴임. 이 이후에는 CI/CD가 나오지.
• 프로젝트 폴더를 어떤 구조로 구성하는지, 어떻게 개발하고 배포하는지 다 표준화 가이드가 있다(오토에버 기준임)
• AI로 개발했으면 하신 거예요. 문제는 그거 해놓고 아는 게 없는 게 문제임. AI 쓰는 건 ㅇㅋ인데 하고 나면 알아야 돼. 리드미 만들고 산출물 관리하고 그래야돼.
• 네이버 메인 사이트 보고 기능적/비기능적 요건 정의하기. 생각할 시간 10분, 발언시간 1분 준다.
  • 비기능적 요건은 수치로 얘기할 것. 수치가 근거임.
  • 안 보고 말하기 연습 필요
  • 생략하는 거 괜찮음. 면접에서는 시간 잘 안 줘. 길면 잘린다.
  • 툭툭 던지기만 하는 것은 의미가 없고, 연결성이 있고 깊이가 있어야 한다.
  • 너무 많은 기능을 나열하는 것은 그다지 가산점 X, 비기능/기능 둘 다 하랬는데 하나만 하는 것도 X. 요구받은 질문에 대해 답변이 안 된 거다.
  • 기능과 비기능 요건의 쌍이 맞아야 한다.
  • 원하는 게 뭔지 잘 생각해봐. 해외 나가고 싶어한다고 아무 나라나 다 좋은 거 아니잖아요. 잘 생각하셔야돼.
• 채용 공고에 직무에 대한 설명이 모호하다면 진짜 그 모호한 일을 다 시키기 위해 그렇게 쓴 거임. 구체적으로 직원에게 원하는 업무가 있다면 공고에 쓸 것이다. 그렇지 않았다는 것은 모든 일을 다 시켜야 하기 때문임.
  • 신입은 기본적으로 아무것도 모른다고 전제한다. 하지만 뭐든 다 할 수 있어야 돼.
• 세일즈포스 주가 폭락. ERP 제공하는 SaaS 회사인데, 요즘 AI 에이전트때문에 경쟁력 급락해서 그렇게 됐음. AI로 자체개발이 가능할 것 같거든. 예전엔 100명 쓰던 일이 이제 두세명 들어가서 딸깍 하면 되거든.
• 채용 시장이 아주 별로이긴 한데, 그건 님들 잘못은 아님. 하지만 힘들 것임,, 힘들면 남탓 하고 덜 힘들면 본인 탓 하세요. 열심히 하세요. 관상 좋다 잘 될 거야.

현직자 특강 오후

SFaaS 아키텍처

• 클라이언트와 서버
  • 클라(프론트): 사용자가 보는 화면. 서버로부터 데이터를 받아서 노출된다.
    • Vue.js 쓴다. (자스 진짜 근본없는 언어임 유명함)
    • 의외로 프론트가 보안을 함
    • Language: Vue3
    • Development: Screen layout and FE API calls, built and located in the static path of the FE
  • 서버: 백엔드. DB에서 데이터 가져와서 프론트에 보여주기.
    • Language: Java
    • Development: Authentication/Authorization, Security, WebSocket s2erver, BE API calls
  • DB: 요즘 MySQL이나 포스트그레 쓴다
    • Language: Java
    • Development: Responsible for DB CRUD operations
• MSA: 서비스를 각자 추구하는 방향에 맞게 잘 쪼개서 관리한다.
• 툴 & 환경
  • 인텔리제이: 주요 자바 IDE
  • DBeaver: 데베 관리 도구
  • K8S, 깃랩, Rancher, 넥서스
  • MariaDB, MSSQL, PostgreSQL, MySQL
  • Harbor, AWS
• 그 외 언어 및 의존성
  • 자바 17버전, 스프링부트 3.3
• 프로젝트 룰
  • 프/백은 공통 프레임워크를 상속받아 구성하는 프로젝트로 분리
  • 트라이 캐치 사용 ㄴㄴ, 멀티 트랜잭션 같은 경우에만 예외적으로 사용
  • 컨트롤러에 업무 로직 금지, 서비스에서 처리
  • 변수는 카멜 케이스
  • REST API: get, post만 사용, 카멜 케이스 사용
• REST API
  • 대부분 스프링부트 룰임.
  • GET, POST만 사용하기로 했는데, delete 같은 게 필요할 때는 status code로 구분함. 그러니까 보낼 땐 POST로 보냈는데 까보면 delete인 거임. → 아니 왜요???
  • URI는 카멜 케이스, 마지막에 슬래시 금지
  • “form-data” 규칙 적용
  • 만약 GET을 써야 하는데 파라미터 사이즈 문제로 POST를 쓰는 경우 API에 특정 네임을 포함할 것
• 응답 데이터 포맷
  • 업무별 오류 코드, 오류 및 성공 메시지, 오류 및 성공 다국어 메시지 코드
  • HTTP 상태 코드 말고 따로 만들어서 쓴다 함 → 왜 HTTP 코드 말고 새로 만들어서 써요???
• 메시지 코드: 업무팀별 프리픽스 + 자동 채번
• 로그 규칙,, 뭐 내가 하나하나 따라적으라고 보여주는 건 아닌 것 같고
  • annotation 지정, 로그 레벨 구분 등 있음
  • 전체적으로 다수의 개발자가 동시에 투입되는 상황에서 혼선을 최대한 방지하기 위한 규칙들로 구성됨. 사유 또한 그러함.
• jasypt 암호화: Java 언어로 개발된 간단한 암호화 및 복호화 기능을 제공하는 라이브러리.
  • 학생이 하는 거면 평문으로 하더라도 일단 만들었다는 점에 ㅇㅋ
  • 프로덕트는 그러면 안돼. 평문 저장 절대 안돼. 님들도 이거 함 해보세요.
• REST API에서는 대부분 JSON 주고받는다
  • 우리는 Jackson, gson 쓴다
• XSS 필터 사용: 요청 링크에 자바스크립트 코드를 넣어서 뭔가 멋대로 실행하게 하는 공격임
• 라이브러리 구성은 다 중앙에서 정해서 비즈니스 개발자들한테 지정해준다
• CORS 정책: 도메인 간 리소스 요청을 제어하는 보안 기능
  • 남이 뭔가 리소스를 던졌을 때 방어함
• 프레임워크 뭐 쓰는지 알려주시는데 아무리 봐도 다 받아적으라고 보여주는 건 당연히 아니고 그냥 그렇구나 정도로 들으면 되지 않을까
• Redis 아세요? 램에서 동작하는 DB거든요. 되게 빠름. 캐시 가능. 기술 면접에서 질문받을 수 있으니까 한번쯤 봐둬라.
• 웹소켓이 뭔지 아세요? 채팅 프로그램 같은 데서 이걸로 소통을 많이 해.
  • 브라우저에서 서버로 요청을 하잖아. 웹은 클라가 서버로 요청하는 게 기본임. 근데 서버가 클라한테 메시지를 보낼 일이 있는 거임. 생각보다 많음. 대표적인 경우가 채팅임. 서버 → 브라우저로 데이터를 보낼 때 쓰는 게 웹소켓임. 면접 기출 스택입니다 알아두세요.
• SMTP: 메일 발송을 위한 서버
• 스웨거 아세요? https://www.ibm.com/docs/ko/integration-bus/10.0.0?topic=apis-swagger
  • 보통 프가 백한테 명세 좀 줘라 하면 스웨거 보여줌
  • 면접 기출 스택임^^
• 컨트롤러: 요청하는 엔드포인트를 적는 곳임. 스프링부트 3 레이어 아키텍처 공부해보세요. 면접 뭔말알?
• 웹개발 똑바로 공부 안하고 들으려니까 좀 뭔소리야 싶긴 하다
  • 근데 대체로 어디서 뭘 어떻게 할지 다 정해져있다는 정도의 소리로 들림
  • 매뉴얼 딱딱 좋다
• API 키 뭔지 아세요?
  • 권한 관리임. 내가 이 데이터를 요구하기에 적절한 자격을 갖췄음을 나타냄.
  • 키를 서로 사전에 정의해놓고 누구는 되는지 누구는 안되는지 정해둔 거임.
  • 어디서 주는대로 받아서 쓸 생각만 해봤지 이걸 주는 입장에서는 어떻게 관리하는지는 한번도 생각 안해봤음. 프/백 팀마다 API 키를 생성해놓고 각자 나눠가져서 쓴대.
  • 키 잘못 주거나 내 키로 남의 데이터 요청하면 권한 없음 오류 보내기
• 스케일아웃: 서버 수량을 늘리는 게 스케일아웃임. 성능은 그대로인데 쪽수가 늘어난 거임. https://library.gabia.com/contents/infrahosting/1222/

데이터 파이프라인

• 차량 생산에 대한 데이터 파이프라인 구축 및 운영 중이다
• 설명 너무 빨라요 일단 최대한 써보겠음
• 일단은 권역별로 각자 데이터를 쓰긴 하는데, 그걸 한번 싹 모아서 중앙에 가져온다. 각자 쓰는 게 DH(데이터 허브), 중앙에 모아오는 게 DSP임. 그 다음으로 그걸 데이터 마트로 다시 전달해서 그게 서비스로 제공됨.
  • 수집 → 통합 → 분배 → 서비스 정도로 이해함
• 기본 크기가 테라~페타 단위라서 대용량에 맞춘 스택 쓴다. 하둡 쓴다.
• 공장은 데이터가 다양해서 각 소스마다 맞춤으로 데이터 수집을 해야 한다.
• 이번에 설명할 것은 하둡을 중심으로 데이터를 어떻게 처리하고 다루는지 그 과정 및 부차적인 부분들,, 이라고 알아들었음
• 하둡 HDFS
  • 하둡의 분산 파일 시스템. 하둡의 핵심임.
  • 데이터를 설정 가능한 크기의 블록으로 나누어 저장. 데이터 회복성과 병렬처리를 위해 여러 대의 서버에 복제본 저장
  • 메인 노드와 데이터 노드로 구성되고, 데이터 노드가 그 복제본들임. (마스터-슬레이브는 이제 구시대 어휘다)
    • 데이터 용량이 n배로 늘어나지만 뭐 하나 죽어도 서비스가 지속되고 데이터도 살려놓을 수 있다.
    • 통째로 복제본을 만드는 게 아니라, 3개의 블록을 4개의 노드가 2개씩 나눠갖는 방식임.
• 하둡 MapReduce
  • 저장한 데이터로 통계 내고 이것저것 하는 기능임
  • 3단계 구성
    1. map: 읽은 데이터를 키값 쌍으로 변환해서 맵 태스크로 병렬처리함.
    2. 셔플: 1에서 만든 걸 리듀스로 전달
    3. reduce: 중복 키를 통합/집계/결합해서 데이터의 사이즈를 줄여서 반환함.
  • 되게 좋은 기능이긴 한데 단점이 확실함
    • 자바로 일일이 작성하는 게 너무 골때림. 개발자한테나 할만한 일이지 그 외의 인간들에게 못해먹을 일이었음. 이 기능이 필요한 건 분석가들인데 분석을 하려면 개발자한테 일을 시켜야 해서 모두가 불편해짐.
    • 로직 자체가 좀 비효율적임. 최적화를 1도 안했음. 잘 모르고 맵리듀스 만들면 서버 터진다. 진입장벽임.

---

이 아래로 하둡 맵리듀스 대체재

• 아파치 스쿱
  • RDBMS와 하둡 사이의 데이터 이관을 지원하는 툴. 양방향.
  • 슬프게도 지금은 개발 중단됨.
• 아파치 하이브
  • 맵리듀스에 저장한 것을 SQL 비슷하게 쿼리할 수 있게 함. 하둡의 데이터 웨어하우징 기술.
  • 자바를 몰라도 하둡을 쓰게 만들어줬음.
  • 단점: 좀 느림. 맵리듀스 갔다가 또 어디 갔다가 해서 좀 느림. 그리고 하둡만 쓸 수 있잖아 요즘 기술이 얼마나 많은데.
• 프레스토 트리노
  • 대규모 병렬처리 플랫폼
  • 하둡+다양한 RDBMS 호환 가능
  • 많이들 쓰시는데 결국 그렇게 빠르진 않음. 디스크 I/O를 많이 하거든요.
• 아파치 스파크
  • 인메모리 분산 데이터 처리 프레임워크
  • 대규모 데이터셋을 여러 머신에 분산하여 병렬 처리하도록 설계된 오픈소스 프레임워크
  • 배치 처리, 실시간 스트리밍, 머신러닝, 호래프 처리 등 다양한 워크로드를 단일 플랫폼에서 지원
  • 스파크는 맵리듀스 기반의 하둡과는 다른 기술로, 메모리 기반 계산을 활용하여 더 빠른 데이터 처리를 제공
  • 스파크 드라이버(Driver)와 익스큐터(Executor)라 불리는 워커 프로세스로 구성되어 있으며, JVM 위에서 동작하는 분산 컴퓨팅 엔진
  • 맵리듀스의 디스크 기반 처리와는 달리 스파크는 메모리에 데이터를 캐싱하여 반복 작업의 성능을 크게 향상
• 아파치 에어플로우
  • 워크플로우를 관리하고 조정하는 오픈소스 플랫폼
  • 스케줄링만 한다. 복잡한 작업들을 플로우 형태로 만들어서 관리 가능

---

데이터 표준화

• 서로 다른 명칭과 유형으로 표현된 동일한 대상을 하나로 통일하는 것
  • 예: 협업하기 위한 표준어
  • 이 일을 수행하는 게 거버넌스임
• 이거 강연하신 분은 데이터 엔지니어라고 하심. 그렇담 앞으로 내가 할 일도 데이터 엔지니어다. 이름이 항상 헷갈렸어.
• 메가 단위의 데이터를 처리하는 일과 테라 페타 단위의 데이터를 처리하는 일은 근본부터 다르다. 그냥 다른 일임.
• 업무 중 스트레스 상황: 누가 임의로 컬럼을 살짝 변경하면 모든 워크플로우가 갑자기 다 빨간불 뜨기 시작함. 긴급점검 해야 함. 스트레스임. 이거 말고도 이슈는 차고 넘침. 어떤 경우에는 데이터가 너무 많이 생성돼서 끌고오다가 서버가 터져버림.
• 서버를 다루기 때문에 서버 관련 능력도 직무 요구사항에 포함됨.
• 통계학은 하면 좋지만 필수적으로 요구되는 직무는 아님. 물론 기반이 되긴 하지만 보통 눈앞에 닥치면 다 하더라^^ 뭐 백엔드 하다가 오시는 분들도 많고 신호 처리도 많이 하다보니 전자공학과 산업공학과에서도 잘들 온다.
  • 통계학의 쓸모는 리팩토링, 연산 최적화 등에 유용하다. 다만 지금은 하루하루가 서버와의 전쟁임..
• 오픈소스 선택하기: 최근 커밋이 2년 전이다 → 사후관리가 1도 안되고 있는 거임. 이런 거 피하면 최악은 면할 수 있다. 정답은 없고 최악을 면하는 것뿐임.
• 현차라는 하나의 그룹사 안에 여럿 속해있긴 하지만, 법적으로 서로 데이터를 공유하면 안된다. 그래서 현대 기아 모비스 데이터 다 분류하고 권한 관리하는 것도 할일 중 하나임.
• 분석 역량이라는 건 어떤 직무든 다 갖춰야 한다. 용량 계산 같은 것 말이에요. 다만 분석가라는 스페셜리스트에 대해서는 좀 더 심도 있는 분석이라고 보면 된다. 가설 검증 머신러닝 이런 거. 분석은 누구나 하되 목표나 지향에 따라 스페셜리스트와 non-스페셜리스트가 구분된 것뿐임.

Factory BI 프론트엔드

• BI 뭔지 알아요? 비즈니스 인텔리전스요.
  • 경영자들과 산하 관계자들의 의사결정을 도와주는 툴 및 플랫폼을 말함
• 우리는 제조 데이터를 기반으로 사용자들이 좀 더 품질이나 가격적인 측면 등등 여러모로 의사결정을 돕는 플랫폼임
• 주로 어떤 상품을 개발 중인지, 어떤 시스템 구축 중인지 보여주는 느낌으로 진행하겠다
• 팀 구성
  • 팀장
  • F-BI 전개 팀: 사용자 배포
  • F-BI 서비스개발그룹
• 대기업이나 스타트업, 중견이 BI 툴을 상당히 많이 쓴다. 태블로나 마소. 무료 평가판이라도 꼭 한번 써보는 걸 추천함. 그걸 써봐야 사용자들이 뭘 어떻게 쓰는지 이해할 수 있다
• 역할을 나눕시다. 요즘은 경험이 많고 의사소통을 잘하고 애자일한 문제해결이 가능한 사람이 중요합니다. 프/백 구분 없이 널찍하게 관심 좀 가져보세요.
• F-BI팀의 개략적인 역할: 통합 지능형 공장 관리 체계 구축
  • 공장에서 나오는 데이터로 사용자들의 의사결정을 돕는 플랫폼이 근본임
  • 쌓인 데이터 많잖아요. 그걸 어떻게 할 수 있을까 고민하는 거임
• 인도는 냄새가 많이 난다
• 자동차는 프차도의 거쳐서 만드는데, 불량 나면 안되죠. 그래서 후공정을 합니다. 문제 있으면 뜯어서 고쳐서 다시 조립하는 거임. 그 후에 소비자에게 간다.
• 강연자님 입사한지 만으로 1년이 안됐다고 하심.
  • 약 1년 간 가장 중요했던 건 프차도의
• 모든 자동차 공장이 프차도의라는 큰 틀은 비슷하게 쓰지만 그 안에 들어가는 세부 사항이 다 각기 다르다. 그러니 데이터가 다르다. 그래서 하나의 알고리즘으로 다종다양한 사용이 어렵다. 매번 요구가 들어올 때마다 다 만든다.
• 온습도가 너무 높거나 낮으면 도장이 잘 안돼.
• 공장마다 설비마다 데이터를 표현하는 이름이라든가 범주라든가 그게 다 다르다. 그걸 IoT 플랫폼이 1차적으로 정리해준다.
• 여러 설비가 데이터를 내뱉고 IoT 플랫폼이 살짝 정리하고 그걸 백엔드가 받아서 처리하고 프론트가 보여준다 라는 흐름임
• 공장에서 공통적으로 쓰는 BI 화면
  • 중에 각인 품질관리가 뭐냐? 사실 로트 트래킹임. 주문자 정보를 생산 중인 차량에 기록해서 공정마다 확인하고 차량 자체도 어느 공정 진행 중인지 추적하는 거임.
• 공장 특화 BI 화면
  • 주문제작임.
• 면접에서 가장 많이 하는 질문 왜 이 스택을 선택했느냐? 거의 모든 면접에서 나옴. 보통은(경력직/부캠 기준) 회사에서 시켜서라고 대답하는데 그러시면 안됩니다. 회사/부캠이 추구하는 방향이 뭐뭐했는데 내 보기엔 뫄뫄 스택이 좋을 것 같았다. 그래서 건의도 해봤고 의견도 구해봤는데 이래저래해서 결국 이 스택을 쓰게 됐다. 라는 식으로 사연을 잘 쓰셔야 한다.
• 컨플루언스 써봤어요? 뭐뭐 써봤어요? 라는 질문을 면접에서 많이들 한다. 뭐든 일단 걍 써보세요. 컨플루언스 노션 지라 3개는 꼭 써보셔라. 일단 경험을 해보면 회사에 들어가는 것도 그렇지만 들어가서 적응도 잘 할 거다.
• 지원하고자 하는 회사가 어떤 스택을 쓰는지 암암리에 알아내고 미리 써보고 들어가면 굿임
  • “깃허브는 흔하게 많이 써서 되게 중요하다” → 필수지 가산점은 아닌듯
• 우리 팀은 AI는 제공하지 않는다 왜냐? 데이터의 소중함 때문임
  • 고객들이 데이터가 막 나오잖아요? 그걸 받아서 일단 학습을 시켜야 하는데 그 데이터 받기가 안되고 있음
• 강연자님이 계속 질문을 기다리시는데 이 내용도 낯설어서 뭐 할 말이 없음
• HMGMA에 아틀라스가 대충 2년 안에 투입되기로 했다. 여기 좋아요.
• 참고자료: https://www.hyundaimotorgroup.com/ko/news/CONT0000000000171618