한재중 : 10. 이원준 (사수: 정진호)

일자	내용	생각/의견/해야 할 일
2020-06-26	커피 마시며 간단히 근황 이야기 유지보수했던 것보다는 신규 개발이 더 재미있음 유지보수의 경우, 기존 구조/언어 버전을 그대로 유지해야 해서 흥미가 떨어짐 신규 개발에서는 다양한 시도/적용을 할 수 있음 → (HJJ) 유재철 선임에게 적극적으로 의견 개진을 해 달라고 부탁함 OVG 하면서 WPF 구현과 MVVM 적용을 해 볼 수 있어서 좋았음 → (HJJ) 추후에 정리하면 팀 회의 등을 통해서 공유 해 달라고 요청함
2020-03-30	수습 종료 면담 10:00~11:00 @지상사업부회의실 인상 깊었던 일 AWS 관련된 작업 → 어떤 정보도 없는 상태에서 일을 진행했던 것이 다소 힘들었었음 자랑하고 싶은 일 AWS 관련된 작업 → 어떤 정보도 없는 상태에서 일을 진행했던 것이 다소 힘들었었음 → 이 상황에서도 작업을 잘 진행해서 영상 데이터 수신 및 처리까지 진행한 것 아쉬웠던 일 개인 역량 부분 일을 하다가 어떻게 해야 할 지 방향성을 잡지 못했을 때, 한 번에 진행하지 못하고 했다가 지웠다가를 반복했음 (선임자의 지시로 인해 번복) background 지식이 없음에 의해 발생할 수 밖에 없었다고 생각함 → 일을 진행하면서 알아가야 하는 부분이라 생각함 경험을 통해서 대처 방안을 생각할 수 있다고 생각함 선임자의 의도를 제대로 파악하지 못한 부분도 있었음 → 잘 물어보고 본인이 이해한 바를 선임자에게 확인하면 됨 올 해 이루고 싶은 일 functional language 공부를 지속 → 단순 스크립팅에서 벗어나서 전체 구조를 잡아보면서 프로젝트를 만들어보고 싶음 → VS Plugin (C# lamda 지원, F# 으로 만들기) 만들기 → 연말에 팀회의에서 공유 팀/팀장에게 하고 싶은 말. 요청하고 싶은 것. 팀 만족하고 있음. 딱히 무언가는 없음 팀장 딱히 없음 기타 하고 싶은 말 불만보다는 소망 여러가지 새로운 기술들 예를 들면 Winform 대신에 WPF 사용하는 등을 하고 싶음. C# v8 사용하고 싶음 → 신규 과제에서 의견을 제시하여 적용이 가능함. 예를 들면 OVG OVG 의 경우, Waterfall 방식 보다는 agile 방식으로 구현을 했으면 함.
2020-03-16	수습 종료 발표 코멘트 이원준 수습 종료 발표.m4a 참석자: 신동석, 이태경, 김인영, 정찬규, 박근석, 한재중, 이원준 신중한 대답, 조심스러운 답변들이 느껴졌음. 좋을 수도...안 좋을 수도... 좋게 보면 충분한 생각을 해야 한다는 것으로 보이고... 안 좋게 보면 빠져나갈 구멍을 항상 준비한다는 것으로 보이고... (이) 자신감 있고 깔끔한 발표였음 (이) 기대대비 입사 후 같은 점, 다른 점? 대전에 위치해서 사람들이 잘 안 와서 사람이 나가면 업무가 과중된다고 들었는데 팀 회의 시에 채용 관련 내용 보면 역시 채용이 쉽지 않은 것 같음 다른 점은 딱히 없었음 (신) 수습 평가 점수 제일 잘 받는 것과 못 받은 것은? (한) 아직 평가 결과가 전달되지 않았음 (신) 이번에 수신받은 Suomi 데이터에서 RGB 영상데이터를 뽑아서 나에게 전달하기까지 얼마나 시간이 걸릴 것 같나? 2~3일 정도 (신) 그 근거는? 위성 데이터 스펙 확인 1일, 그것을 기반으로 영상데이터 만들어내는데 1일 (신) 팀장의 생각은? (한) 무리수가 있다고 생각함. 위성 데이터 포멧 스펙을 아직 모름. 위성 데이터 포멧을 찾고 적용하는데까지 시간이 생각보다 많이 걸릴 수 있음 (신) 알지도 못하는 데이터의 유효성을 확인하는데 어떻게 3/20 까지로 기한을 잡았나? 기존 경험을 바탕으로 잡았나? (한) 대답은 못했지만...그러함... (이) 공통모듈에 대한 비평을 하자면? Json 관련 모듈이 없어서 아쉬웠음. 추가가 필요함 XML 에서 리스트를 생성할 때, 항목을 묶기 위한 객체가 필요함. 공통모듈의 문제인지, XML 자체의 문제인지 모르겠음 비슷한 XML 형식이 있는데, 안의 내용이 살짝 다르다고 해서 클래스를 아예 다르게 만들어줘야 함. Inner Class 를 못 읽고 public class 만 읽은 부분이 아쉬웠음 (이) 유지보수 측면에서는? 왜 내가 사용하지도 않는 gdal 같은 코드가 있어야 할까? 덩어리가 크면 프로젝트/코드 확인하기가 어려움 프로젝트 별로 사용하는 gdal 의 버전이 달라서 컴파일 시 어려움을 겪기도 했음 (이) 어떻게 개선할 수 있을까요? 공통모듈 덩어리가 너무 큼. 세분화 했으면 함 (정) XML 과 관련된 문제와 관련해서는 상속 구조를 사용하면 클래스 중복 문제는 해결될 것임. 참고하기 바람. (정) 개인 블로그에서 회사 자료가 올라가지는 않는가? 보안을 신경써야 함 회사 코드라기 보다는 일반적인 내용을 올리고 있음 예를 들면 nlog 에서 날짜별로 파일 저장을 위해서 config 설정을 어떻게 해야 하는지... (박) 친구들에게 자랑을 많이 한거 같은데 이번에 지원 많이 했나? 아직 지원할 상황이 아니라 내년에 지원하지 않을까 함 (이) 채용 관련해서 제도에 문제가 있다고 생각한 부분은 없나? 채용된 이후에 연봉 계약을 미리 하는 것이 아니라 다니다가 계약을 하는 것이 이상하기는 했음 다른 곳에 다니는 사람을 데려올 때, 어려울 수 있는 부분이라 생각함. 명확한 연봉을 제시할 수 없기 때문임 (이) 추천 제도를 활용하려면 1년 만근해야 가능함. 이상하지 않나? 1년 만근을 해야 추천할 수 있는 것은 맞다고 생각함. 이득을 얻지 못하더라도 내가 추천한 사람이 회사에 온다는 것 자체가 좋을 것 같음 (이) 코드 리뷰 받아봤나? 없음. 코드 리뷰라 할 만큼 받아본 적은 없음 부분적으로만 코드에 대한 지도를 받았음. 풀 리뷰를 받아본 적 없음 (이) PR 도 만들어본 적 없나? CAS 작업에서 브랜치 생성해서 작업을 했지만 PR 을 직접 사용해 본 적은 없음 (정) 다른 사람이 작성한 코드는 좀 봤나? CAS 작업이 코드 변경을 해야 하는 것이었기 때문에 연관된 코드들을 찾아봤음 (정) 기존 코드가 마음에 들었나? 코딩 컨벤션이 충돌하는 부분이 있어서 이렇게 해도 되는 것인가?? 하는 생각이 들긴 했음 (이) 수습 종료하기 전에 Git Flow 를 수행(PR)하기를 바람. 팀장이 챙겨줘야 함. 어떤 기준으로 검토하는지 합을 맞추는 것이 필요함. (이) 리팩토링 책은 왜 보나? 개인적으로 개발을 할 때, 마음가는대로 구현했었음. 더 나은 코드를 짜기 위해서 읽고 있음 (이) 실력 향상이 됐다는 것을 어떻게 확인할 수 있나? 명확한 확인 방법이 있다고는 생각하지 않는다. 반복적으로 하다 보면 언젠가는 '어? 이건 아닌데...' 에서 끝나는 것이 아니라 '어? 이거 이렇게 하면 되겠는데?' 로 변할 수 있을 것 같다. 그 때, 뿌듯함을 느낄 것 같음 (이) 리팩토링 책에서 리팩토링을 언제 하라고 되어 있나? 과제에서 기능 단위로 개발이 끝날 때나 기능 추가를 해야 할 때, 뭔가 이상한 부분이 있으면 하라고 되어 있음 (이) 리팩토링을 잘하기 위한 조건은? 코드 스멜이 느껴질 때 (이) 그건 코드를 바꿔야 할 때고 잘하기 위한 조건은? 잘 모르겠음 (이) 테스트가 필요함 (이) 리팩토링을 실천한 부분이 있나? 회사 업무하면서 한 것은 없음 C# 은 아니고 개인 프로젝트에서 테스트 코드를 작성한 경험이 있음 (이) 회사에서 테스트를 짜 본 적이 없나? 있다. 하지만 TDD 까지는 아니고 코드가 동작하는지 정도만 테스트했음. 그 이상을 한 적은 없음 (이) 상호간에 정해진 규칙을 잘 수행하기 위해 단위 테스트를 잘 짜야 하고 그것은 습관이고 노력임. 남은 수습 기간 동안 그 부분을 몸소 체험할 수 있기를 바람. (신) 수습이 필요하다고 생각하나? 그걸 깨달으려면 수습이 아닌 상태로 회사를 다녀봐야 알 것 같음. 현재 답변하기 어려움 (→ 이런거...노련함...) → 상반기 성과 점검 시에 팀장이 다시 물어보기!!! (이) 후배를 데려온 상태에서 사수를 하라고 하면 지금의 사수와 본인은 어떤 점을 다르게 하고 싶나? 수습 과정 동안 정진호 선임과 업무적으로 많이 부딪히지 못했음 (이) 전유길이나 팀장과 비교한다면? 모르겠음. 똑같이 할 것 같음. 일이 생기는대로 주고 확인하고 등등... (이) 사수는 상사고 본인은 졸자라고 관계를 정의할 수 있나? 등급적인 관계가 아니라 직무적인 관계라고 정의하고 싶음. 매니저, 엔지니어... 의견을 말할수는 있겠지만 일단은 주어진 일을 잘 마무리하는 것이 본인의 역할이라 생각함 (이) 사수는 어떤 것을 해 줘야 하는지 느낀 것은 없나? 작업 환경 초기 세팅, 도메인 지식 전달 도메인 지식을 얻을 수 없는 분야라서 도메인 지식 전달이 주요했음 (박) 본인이 잘 모르는 것, 궁금한 것이 생기면 어떻게 하나? 이슈는 정리해서 한 번에 물어봄 Yes/No 만 필요한 것은 바로 가서 질문함 (박) 문서를 친절하게 작성하고 싶다고 했음. 형식은 노력하는 부분이 보이는데 내용은 어떻게 노력할 수 있나? 분석 문서의 경우, 분석을 더 꼼꼼하게 하고 지식을 제대로 쌓아야 함 내가 한 일 정리는 한 일의 순서 및 정보를 명확/꼼꼼하게 해야 함 (박) 일을 하다가 더 나은 방법을 알게 됐을 때, 이전에 작업한 것에 대해서는 어떻게 하는 편인가? 그냥 둠 (이) 회사 문화, 부문 문화에서 바꿨으면 하는 것은? 아직 잘 모르겠음. 팀회의 말고는 참여한 다른 회의가 거의 없었음. 과제 진도 점검 회의를 참석해서 분위기를 보고 싶었으나 아직 경험해 보지 못했음 많이 느껴봐야 좋은 것인지 안 좋은 것인지 알 수 있을 것 같은데...아직은 그 수준에 닿지 못한 것 같음 → 상반기 성과 점검 시에 팀장이 다시 물어보기!!!
2019-12-06	2차 면접 무모함 99.8, 도덕 9.6, 업무 관리 역량 2 (100점 만점) 업무 스케줄 관리 필요! 대답할 때, ~잖아요 많이 씀. 쓰지 않도록 관리 필요 논쟁을 좋아함 → 건설적인 논쟁 → 감정적으로 번지기 전에 자신의 주장을 멈추는 편 술 마시는 것 좋아함 본인만의 코딩 규칙은 딱히 없음 규칙은 이해하지 못하겠더라도 따르는 편 약속을 지키지 않은 사람과 같이 일하기 어려움 대세보다는 살짝 아류에 꽂히는 스타일. 마이너 취향 핵심 전달 능력을 키워야 함!!! → 정리를 하면서 말하는 연습을 해야 함 스스로 메모하는 습관이 있다고 함 삶의 주요 가치 (키워드) 성장의지, 성공한 미래에 대한 확신 꿈(목표) 높은 수준의 개발자 나만의 프레임워크 언어 철학 인디게임 회사의 핵심가지 모름

한재중 : 10. 이원준 (사수: 정진호)

Attachments: