ToC
모빌리티서비스
- C++ ROS 프로그래밍 기초: 패키지 생성, 빌드, 첫 빌드 후 환경설정, 실행
- 토픽, 서비스, 액션 인터페이스: 인터페이스 패키지 만들고 기본 파일 생성 후 빌드. 오류 해결 실패 시 깃허브 소스 다운받아 실행하기.
- C++ ROS 2 패키지 설계: 소스 코드 다운로드 및 빌드. 토픽 서브스크라이버/서비스 서버/액션 서버 실행, 토픽 퍼블리셔, 서비스 클라이언트, 액션 클라이언트 실행.
- 팁: 강의와 똑같이 복붙해도 안되면 직접 쓰기(유니코드 문제)
알고리즘
유전 알고리즘: 어떤 문제에 대해 랜덤한 답안들을 생성하고 2개씩 골라 섞어서 더 나은 답안 찾아가기.
유전 알고리즘은 해의 경우의 수가 너무 많아 일일이 찾거나 확정적인 알고리즘을 사용할 수 없는 문제에 사용할 수 있다. 기계학습과 비슷하게 문제 영역에서 최적해를 찾아가는 과정이다. 문제 영역에는 여러 가지 지역 최적해가 존재할 수 있는데, 목표는 전역 최적해를 찾는 것이지만 한 번 지역 최적해를 향해 가기 시작하면 그 흐름에서 빠져나오기 어렵다. 그러므로 ‘진화’를 이용하여 지역 최적해를 빠져나와 다른 더 좋은 해를 찾아간다.
유전 알고리즘에서 랜덤이 적용되는 부분은 다음과 같다.
- 초기 답안 풀 생성: 로또 찍는 것처럼 아무 답안이나 원하는 개수만큼 생성한다.
001100010110
등과 같이 유전자스럽게 표현한다. - 교배할 부모 선택: 자연선택의 원리를 적용하되, 안 좋은 답안도 선택될 확률이 남아있게 한다.
- 교배: 두 부모의 답안을 섞는 방식은 알고리즘 작성자 마음대로 한다. 굳이 랜덤하게 섞지 않아도 된다. 일정하기만 하면 된다.
- 돌연변이: 낮은 확률로 교배가 완료된 자식이 돌연변이를 일으킨다.
- 한 세대의 교배 수: 교배를 통해 생성된 자식이 기존의 세대를 대체하는 방식과 관련이 있으며, 작성자 마음대로 쓴다.
생물학의 개념을 빌려왔기 때문에 용어도 생물학의 용어를 그대로 따서 쓴다.
- chromosome: 문제 영역에 대한 답안. 각각의 부모, 자식을 나타냄
- gene: 답안의 각 자리(글자)
- schema: 유전자에서 보이는 특정 gene의 패턴. 대체로 좋은 결과를 보였던 일정한 패턴을 말한다. 꼭 연속하여 위치할 필요는 없다.
소프트웨어분석및설계
졸업생 깜짝 특강
- ‘개발’의 분야는 아주 다양하고, 한 사람이 모든 일을 혼자서 다 할 수 없으니 직무 선택이 첫 번째다. 혼자서 모든 일을 할 수 있다고 해도 회사에서는 올라운더 잡캐보다 특정 클래스 특화 캐릭터를 선호한다.
- 직무 선택에는 본인의 성향이 중요하다. 토이 프로젝트 등에서 맡았던 역할 중 특히 좋았던 역할을 생각해보면 도움이 된다. 뭐가 됐든 일단 부딪히고 깨져보는 건 도움이 된다.
- 각종 회사별 기술블로그 추천: 어떤 회사가 무엇을 사용해 뭘 하는지 보고 배워라. techblogposts.com 나는 플라네타리움에 관심이 있음. 트위터에서 오픈소스 프로젝트 기여할 사람 찾는다고 하는 거 본 적 있음.
- 학부 공부 이외에도(혹은 졸업 후에도) 필요에 따라 추가 교육 준비: 국비 지원 과정, 온라인 강의(유/무료), 부트캠프(boottent) 등
- 단순 실력 향상 목적 학원 X, 협업 경험 목적 O: 학원의 광고 멘트는 보통 상술이다. 기본기, 자격증은 학원에 안 가도 충분히 가능(방향성 잡기는 어려울 수 있음), 포폴 목적/취업 연계 등 목적은 괜찮.
- 자격증: 회사 바이 회사지만 취업에 큰 영향을 주지는 않음. 일부 보수적인 분야에서는 자격증을 중시할 수 있으나 기본적으로 프로젝트 경험의 질과 양을 우선함.
- 포폴 정리: 지금까지 했던 일(학과, 알바, 동아리 등) 모두 정리, 필요한 기술 스택과 연계해 어필할 강점 파악. 평소 정리가 중요하다.
- 코딩 테스트 준비: 미리 하는 게 좋을 것이다. 핵심 자료구조, 알고리즘 공부하고 편한 언어 사용. 파이썬, 자바 추천.
- 기술 면접 준비: 서류 전형 준비할 때 같이 준비. 본인이 사용한 기술을 선택한 이유. IT 관련 기초 지식 중시하는 회사 많다. 비전공자가 이해할 만큼 쉽게 잘 설명하는 것도 가산점 요소. 모의 면접 추천.
- 인성 면접: 결과가 노력에 비례하지 않을 수 있다는 점에서 기술 면접보다 어려울 수 있음. 회사와 분위기가 맞는 사람인지 보기 때문. 정답이 없고 순위를 매기지 않는 전형이기 때문에 떨어진다고 상처받지 말고 서로 인연이 아니었다 생각하길. 기술 면접과 연계되는 내용은 트렌드에 따라 다르기 때문에 알아서 자료 참고. 유튜브 ‘면접왕 이형’ 추천, 잡플래닛 면접 후기, 취준생 커뮤니티 참고 가능.
- 각종 취준 경험과 기록은 모두 정리해서 모아두기: 면접 질의응답 자료와 코딩테스트 문제들
- 입사 이후: 취업해도 공부는 안 끝난다(!) 4년간의 배움, 6개월만에 바닥난다. 학부에서 꼭 머리에 안 들어오는 과목은 취업하면 그렇게 그렇게 필요해진다. 혼자 울면서 공부하면 힘들고 어차피 공부는 모두가 다 해야 하니까 팀원이든 동기든 같이 공부할 사람을 찾고 붙잡고 공부해라. 서로 공부할 분야가 다르다면 인증 모임이라도 만들어라. 같은 분야 공부가 가장 좋지만 IT는 결국 하나의 흐름으로 모이기 때문에 분야가 달라도 같이 공부하는 게 훨씬 좋다.
- 뭘 공부하면 좋은지 추천: roadmap.sh
- 프론트엔드: 자바스크립트, HTML, CSS, 리액트
- 게임(클라이언트): 유니티+C#(캐주얼), 언리얼+C++(MMORPG)
- 백엔드: DB 필수(MySQL, PostgreSQL(여기까지 관계형DB), NoSQL(비관계형 DB, 대용량 처리에 적합), 몽고 등등 다양하니 찾아보라)
- 게임: C#, C++
- non-게임: 자바, 스프링(스프링부트)
- 안드로이드: 자바, 코틀린
- 알고리즘: 파이썬 추천. 실무에서 시간복잡도를 고려할 줄 아는 것이 중요함(문제를 풀라고 직접 시키지 않지만 서비스의 질과 연관됨)
- 한 번 취직 후 타 직무로 이직하기 쉽지 않다는 점 고려 필요
- 직무와 분야에 따라 수학, 알고리즘 등 별도 역량 필요: 요즘 유니티 엔진 등 엔진이 잘 되어 있어서 직접 깊게 공부하는 건 필요에 따라 다르고 필수는 아님(연구직을 하겠다면 필요할 수는 있음)
- 프론트엔드: 자바스크립트, HTML, CSS, 리액트
- 야근
- 비게임: 사람이 자산이기 때문에 길게 일할 수 있게 잘 보살펴 준다. 물론 야근 있을 수 있음. 급하거나 큰 일이 생기면 야근을 몰아서 하게 될 수도 있는데 그럴 때는 야근 수당 또는 보상 휴가라는 게 있다. 재택 근무, 유연 근무 등 다양한 방안이 있음.
- 게임: 야근 꽤 있을 수 있음. 타이핑 치다가 제대로 못들었음
- 연구와 개발의 차이: 개발은 끊임없이 개발하고 테스트하고 확인하는 과정이 쉴새없이 몰려옴. 사용자의 반응을 볼 수 있다. 연구는 개발처럼 몸이 바쁘진 않은데 머리를 열심히 써야 함. 눈에 보이지 않는 성과를 내야 함.
- 일과 생활의 분리: 공부 등등도 중요하지만 지속 가능한 게 중요하니 일과 삶은 분리해야 한다. 조금이라도 일과 관계 없는 시간을 마련해야 할 것(삶의 동기부여). 욕심내지 않으면 공부할 시간도 있다. 조금씩 꾸준해도 발전은 있다.
- 포폴용 프로젝트의 깊이: 학생에게 현직자 수준 기대하지 않음. 혼자 할 수 있는 일을 5명이 나눠서 했다 X, 5명분의 일을 5명이 했다 O. 프로젝트 마감 후에 발견한 개선점은 메모해두고 면접에서 활용 가능. 본인이 하고 싶은 프로젝트를 하는 게 좋다. 현직자만큼의 깊은 수준을 바라지 않는다.
- 컴공 전공 후 “개발자” 이외 직무: QA, 인증/보안, 데이터 분석, 기획, 은행(디지털 전환) 등
- 구글링으로 진행한 프로젝트의 ‘깊이’(코드와 로직 복붙): 완전 복붙은 좀 아니고, 약간 변형해서 활용 가능하면 됨. 같은 역할을 하는 코드라도 다양한 상황에 따른 적절한 선택 능력이 있으면 됨.
시퀀스 다이어그램
- 시스템의 동적인 측면을 모델링, 다수의 객체를 대상으로 하며 하나의 다이어그램에 여러 개의 시나리오가 표현될 수 있다. 동기 메시지와 비동기 메시지를 구분한다(응답도 구분한다).
- 정적 모델(클래스 다이어그램)은 처음부터 완성될 수 없다. 동적 모델과 서로를 보완하며 완성한다. 만약 동적 모델이 타당하다면 정적 모델은 동적 모델에 표현된 오퍼레이션만 가져야 한다.
- 시퀀스 다이어그램에 표시된 화살표에 병기된 오퍼레이션은 화살표의 목적지가 갖는 것이다.
- 액터가 시스템의 실행 종료 후 결과에 관여하는 것은 오퍼레이션으로 취급하지 않고, 다이어그램에 표기하지 않는다.
- 여러 개의 시나리오가 함께 표현된 시퀀스 다이어그램을 보고 포함된 시나리오를 분리해서 해석할 줄 알아야 하며, 여러 개의 시나리오를 하나의 다이어그램으로 나타낼 줄 알아야 한다.
소프트웨어디자인패턴
- Mediator중재자 패턴
- 객체 간의 의존 관계가 복잡한 상황의 컨트롤타워. 다수의 컴포넌트가 직접 통신하면 디버깅이 어려워지고 프로그램이 복잡해지기 때문에 통신을 총괄하는 중재자를 만듦. 컴포넌트 간의 직접 통신을 금하고 중재자를 통해서만 통신하게 함.
- 단일 중재자 객체 내부의 다양한 객체 간의 복잡한 관계망을 캡슐화. 단일 중재자가 모든 통신을 중재하기 때문에 그에 대한 로직을 전부 혼자 가진다(특정 어플리케이션에 맞추어 만들어짐). 그렇기 때문에 다른 어플리케이션에 재사용하기는 어렵다.
- 소통이 필요한 컴포넌트와 중재자, 구체컴포넌트와 구체중재자. 컴포넌트는 중재자를 갖고, 구체중재자가 구체컴포넌트를 모두 갖는다. 구체컴포넌트는 각자 중재자를 갖는다. 구체컴포넌트의 모든 통신은 구체중재자에게 전달되고, 중재자가 대신 통신한다.
- 시퀀스 다이어그램 시험에 낸다
- 일반적으로 로직을 분산시키는 것을 지향하는 객체지향의 개념과 달리 한 곳에 집중하는 패턴. GUI 어플리케이션에서 효과적이다.
- Observer구독알림 패턴(Publish-Subscribe 패턴)
- 어떤 사건이 발생하면 바로 알고 싶은데, 매순간 확인하기는 비효율적이니 사건의 주체가 사건 발생 시에 구독자에게 알림 전송.
- 구독 알림 패턴: 구독/구독 취소 기능
- 특정 사건에 대해 알림을 받고 싶은 고객과 모든 사건에 대해 알림을 보내고 싶은 쇼핑몰의 이해관계 충돌 문제 해결
- 관찰대상과 관찰자, 구체관찰대상과 구체관찰자. 관찰대상은 쇼핑몰, 관찰자는 고객에 비유.
- 관찰자가 보기보다 수동적임. 이름은 관찰이지만 직접 관찰하지 않고 상태를 통지받는다.
- Model/View/Controller(MVC)에 잘 사용됨