일본 현지 생활 수기 (KITA - 한국무역협회 제출 수기)

2022년 6월 일본 입국 후 6개월이 지난 시점에 회고록 느낌으로 작성한 후기입니다.

일본에서의 삶을 마무리하고 귀국한 현재로 보면 일본 회고록 1편 느낌이네요.

일본 회고록은 조만간 다음 편으로 돌아오겠습니다.

안녕하세요. 일본취업학교 2기 한민성입니다. 제가 작성한 글은 일본 취직을 결정하게 된 계기부터 현재 6개월간의 도쿄 생활에 있어 전반적인 본인의 회고록에 가깝습니다만 도움이 되셨으면 좋겠습니다.

[일본을 향한 첫 발] * 수강 중 챙겨야할 것, 취업준비 팁, 채용

소프트웨어학과를 전공하였고 졸업 전 호주에서 단기 인턴을 하면서 해외취업에 꿈을 키웠습니다. 졸업 후 일본 유학생활을 하는 친구의 영향으로 일본으로의 취업을 결정하게 되었습니다. 첫 번째 목표는 일본 취업비자 최소 요건 달성이었고 히라가나부터 시작해서 10개월이 걸렸지만 JLPT N2 자격증을 취득했습니다. 두 번째 목표는 해외취업에 최적화된 커리큘럼을 제공해 줄 수 있는 기관을 통한 내정 후 일본 입국이었습니다. 마침 한국무역협회에서 일본취업학교 2기 모집공고를 발견했고, 커리큘럼이 너무 마음에 들어 바로 지원했습니다. (일본취업학교 커리큘럼은 SCIT과정과 달리 IT 수업이 없고 다양한 분야의 일본 취업을 목표로 하는 과정입니다.) 저는 일본어 초급반에서 수업을 받았습니다만 IT 전공자였기에 SCIT 잡페어 일정 및 참가기업에 대한 정보를 취득 할 수 있었습니다. 따라서 저는 일본취업학교 과정과 별도로 10월 잡페어를 목표로 계획을 세웠습니다. 일본 입국이 최우선 목표였기에 부족한 일본어로도 내정 가능성이 있는 한인기업을 대상으로 우선순위를 정하고 2020년 7월 말 입학 후 약 3개월 동안 일본어 면접 연습과 포트폴리오 완성에 올인했습니다. 그 결과 10월 잡페어에서 합격하고 2020년 11월 내정 받게 되었습니다.

-> 개개인마다 주어진 상황과 조건들이 다릅니다. 히라가나도 몰랐던 저는 일본 취업이라는 큰 문제를 한 번에 해결하기보다는 문제를 쪼개고 하나하나 해결해 나가는 방식이 저에게 맞다고 생각했습니다. 그래서 일본에 입국할 수 있는 자격을 먼저 마련하고(비전공자는 기사자격증 + 일본어 자격증) 탄탄한 인프라를 제공받을 수 있는 기관을 찾았습니다. 수강 중 하나라도 더 배우겠다는 마음가짐으로 적극적으로 임한다면 동기, 선생님과의 좋은 관계는 자연스럽게 따라오는 것 같습니다. 가진 것을 서로 나누며 돕는 분위기가 형성된다면 시너지 효과가 난다고 생각합니다. 최우선 목표를 정하고 본인의 장점을 극대화할 수 있는 환경을 만들어 나가시면 좋을 것 같습니다.

[코로나로 인한 슬럼프] * 코로나, 채용

정확한 입국 시기는 코로나로 인해 정해지지 않았습니다만 기업과의 미팅을 통해 2021년 5월로 예상하고 있었습니다. 2021년 1월 일본취업학교 과정을 졸업하기 전까지는 커리큘럼에 충실하며 비지니스 일본어, 일본 문화에 대해 공부했습니다. 좋은 선생님들 덕분에 수업에 대한 만족도는 높았습니다. 과정 졸업 후 4개월 동안은 가족 및 주변 사람들과 시간을 보내며 일본에서의 생활을 준비했습니다. 하지만 입국 제한은 풀리지 않았고 입국 예정일이 계속 늦춰졌습니다. 입국 제한이 언제 풀릴지 모르니 입국을 기다리는 동안 한국에서 일자리를 찾는 것이 힘들었습니다. 저는 곧 일본에 갈 수 있다는 희망과 초조하게 시간 낭비만 하고 있다는 절망 속에서 이러지도 저러지도 못하는 생활을 지속했습니다. 그러던 중 기업과의 미팅에서 올해는 입국이 불가능할 것 같다는 소식을 들었습니다. 그 후로는 심적으로 지쳐서 그랬는지 프로그래밍과 일본어가 헤어진 전 애인처럼 마주치기 싫었습니다. 그리고 때마침 공공기관에서 일할 기회가 생겨 계약직으로 연구개발팀에서 일할 수 있었습니다. 그러던 중 2022년이 되고 반쯤 포기하고 있던 입국 절차가 빠르게 진행되었습니다. 많은 고민이 있었지만 계약직 계약을 종료하고 일본으로 향하기로 결정했습니다.

-> 세상에 쓸모없는 경험은 없습니다. 공공기관에서 일하면서 정부 정책에 맞춰 발 빠르게 대응해 나가며 세계적인 트렌드를 분석하는 일에 참여할 수 있었으며, 정말 좋은 사람들을 많이 만났습니다. 5년 후 10년 후 내 모습을 조금 더 구체화할 수 있었습니다. 그리고 역시 나는 고객의 요구사항에 맞는 기능을 기획하고 설계하는 일이, 그리고 그 서비스를 건담 조립하듯 완성해 나가는 일이 가장 재밌다는 것을 느꼈습니다. 저는 하나하나 직접 해봐야 아는 사람입니다. 그렇기에 목표를 향해 똑바로 가지 못하고 돌아갈 때도 물론 있습니다. 하지만 여러 경험을 통해 내가 좋아하는 것. 싫어하는 것을 알아가며 내 취향을 만들어 가고 있다고 생각합니다. 희망과 절망 사이에서 이러지도 저러지도 못하는 생활을 했을 당시도 여러 경험을 위해 노력했다면 하는 아쉬움이 있습니다. 여러분은 고민할 시간에 어떤 일이던 경험을 위해 일단 해보시길 바랍니다.

[도쿄의 봄, 초기 정착 준비] * 입국준비 팁

2022년 5월 25일 일본 입국 날이 정해졌습니다. 내정 받은 기업마다 다르겠지만 저 같은 경우 대부분의 입국 준비는 직접 했습니다. (기업과 연락을 통해 어떤 부분을 준비해야 하는지 확인하시면 좋겠습니다.) 가장 우선시해야 할 부분이 신용카드 만들기, 핸드폰 개통, 집 구하기입니다. 핸드폰 개통은 유학생들이 많이 이용하는 GTN 모바일을 통해 한국에서 미리 일본 번호를 개통하고 유심칩을 받아서 입국했습니다. (다른 동기들은 일본에서 개통했습니다만 핸드폰이 개통되기 전 초기 집 계약, 택배, 관공서 연락 등 여러 가지 문제로 고생했습니다.) 한국 번호는 정지하지 마시고 저렴한 요금제로 살려 두는 것을 추천합니다. 생활할 집은 오크하우스 라는 사이트를 통해 아파트먼트 타입의 집을 계약했습니다. 쉐어하우스도 제공하기에 오크하우스, 레오팔레스를 참고하시면 되겠습니다. 외국인들을 위한 다양한 서비스를 제공하기 때문에 초기 정착 시에는 좋은 선택이라고 생각합니다. (퇴거가 자유롭습니다.) 이렇게 집을 구하시고 직접 생활하시면서 앞으로 이사할 집의 기준을 세우시면 되겠습니다. (동기 중 한 명은 부동산을 통해 바로 집을 계약했지만 고가도로로 인한 소음이 너무 심해 위약금을 물고 다른 집을 다시 계약했습니다.) 5월 25일 입국 후 1주일은 일하기 전 준비를 했습니다. 구청에 가서 재류카드에 주소 등록을 하고 주민표를 받았습니다. 우체국에 가서 유쵸은행 통장과 카드를 발급받았습니다. 마이넘버 카드를 만들고 보험 가입을 했습니다. (핸드폰 개통과 월급통장 개설을 기업에서 도와준다면 직접 할 필요가 없습니다.) 위에 기술한 부분은 핸드폰 번호와 도장이 필요하니 참고하시기 바랍니다. 입국 전 1년 동안 일본어를 손에서 놓고 있던 터라 사실 여러 가지 시행착오가 있었지만 구글, 파파고와 함께 잘 끝낼 수 있었습니다. 봄 끝자락에서야 일본에 도착했지만 코엔지에서의 생활은 낯선 환경의 두려움 보다 앞으로의 설렘을 가져다주었습니다.

-> 혼자 일본에 도착하면 정말 막막합니다. 선배 동기들에게 연락하는 것을 두려워하지 말고 필요한 부분은 도움을 구하는 것이 좋다고 생각합니다. 일본에 살게 되면 동지애가 생깁니다. 도움을 받고 앞으로도 좋은 관계를 유지한다면 외로운 타지 생활 잘 적응할 수 있다고 생각합니다. 저는 일본취업학교 과정에서 입국한 동기들을 알지 못했기에 회사 입사 동기들과 소통했습니다만 여러분은 SCIT라는 훌륭한 인적자원 또한 가지고 계시니까 저보다 더 좋은 환경에서 시작할 수 있습니다. 그리고 꼭 일본어 공부 열심히 하고 오시기 바랍니다.

[도쿄의 여름, 파견 근무 시작] * 업무, 근무환경, 임금

저는 6월 1일 정식으로 입사했으며, 3개월은 수습 월급을 받았습니다. 세 전 180 세 후 150즈음 이었던 것 같습니다. 제가 입사한 기업은 파견 기업이기 때문에 입사 후에는 재택근무 형식으로 파견 준비를 했습니다. 파견되는 기업의 면접을 위해 헤어졌던 일본어 공부를 다시 시작했고, 이력서를 다시 정리했으며 예상 질문 답변을 뽑고 면접 준비에 돌입했습니다. IT 공부는 Java 복습, TDD(Test Drivec Development) - 테스트 주도 개발, 스프링 위주로 공부했으며 사내 홈페이지 유지 보수를 목표로 공부를 진행했습니다. 6월, 7월 2개월 동안 총 3번의 파견 면접 제안이 있었고, 한 번은 1차 면접은 통과했지만 고객사 측에서 일본 경력이 없는 점을 문제 삼아 탈락했으며, 한 번은 하고 싶지 않은 롤이었기 때문에 거절했습니다. 그리고 8월 1일 지금의 겐바에 들어오게 되었습니다. 현재 하는 프로젝트는 일본 석유회사가 사용하는 COBOL 언어로 개발된 물류, 판매, 회계 프로그램을 Java Spring Framework 기반의 통합 프로그램으로 개발하는 것입니다. 설계부터 개발 및 테스트까지 참여하는 프로젝트이다 보니 부담감이 엄청났지만 좋은 기회라고 생각하고 1인분만 하자는 생각으로 출근했습니다. (현재 겐바는 팀 리더, 4년차 선배와 동기들과 함께 팀 단위로 계약하게 되어 일본어가 부족한 저에게 있어서는 좋은 기회라고 생각합니다.) 하지만 익숙하지 않은 일본어 키보드와 업무환경, 프로젝트 파악을 위해 봐야 하는 엄청난 양의 일본어 서류들로 인해 막막하기만 했습니다. 하지만 매일 야근을 하며 서류들을 보다 보니 석유회사에서 사용하는 용어들에 익숙해졌고, 신기하게 안개가 조금씩 걷히기 시작했습니다. 8월 한 달은 저의 수습이 끝남과 함께 겐바에서 1인분을 할 수 있게 된 시간이었습니다. 항상 잠재력을 끝까지 끌어내 주는 팀리더와 친절한 선배, 같은 처지의 동기들과 함께 했기에 일본 겐바에서의 첫 한 달 동안 잘 적응했다고 생각합니다. 일본의 여름은 정말 습합니다. 빨래를 자주 하실 텐데 특히 남성분들은 돈키에서 세제 1회분씩 소분해서 파는게 있습니다.

-> 보통 규모가 있고 체계적인 시스템이 있는 기업의 신입 개발자들은 1년간 연수 목적으로 테스트 위주의 업무를 하게 됩니다. 하지만, 제가 취직한 기업은 체계적인 연수 시스템이 없고 야생과 같은 환경입니다만, 본인 능력에 따라 더 좋은 롤, 더 좋은 기회를 얻을 수 있습니다. (제 입사 동기 중 한 명은 뛰어난 일본어 실력과 개발 실력으로 풀 재택으로 본인이 하고 싶은 일을 골라서 하고 있습니다.) 각각 장단점이 있는 만큼 본인에게 맞는 선택을 하시기 바랍니다. 제가 느낀 바로는 본인에게 선택권이 있으려면 뛰어난 실력이 바탕이 되어야 합니다. 다시 한번 일본어 공부를 열심히 하고 오시기 바랍니다.

[도쿄의 가을, 본격적인 일본 생활 시작] * 임금, 거주지 환경, 물가 및 생활비, 의료환경, 취미

9월이 되고 수습이 끝났습니다. 제 월급은 세 전 270 세 후 235 정도가 되었습니다. (여기에 정기권 가격이 + 되네요.) ふくろ(봉투)를 못 알아들어 장을 볼 때 고생했던 날을 지나 이제 일본 생활에 적응을 했습니다. 여전히 프로젝트는 힘겹게 진행하고 있지만 출퇴근 시간의 뉴스 청취, 드라마 시청, 퇴근 후 스프링 공부는 습관처럼 자리 잡았습니다. 하지만 회화가 마음처럼 쉽지 않아 동기와 온라인 과외를 시작했습니다. 한국인 팀원끼리 일하다 보니 일본어가 생각만큼 빠르게 늘지는 않습니다. (그래도 매일 진행하는 회의와 일본 생활 자체에서 일본어에 많이 노출되다 보니 자연스럽게 늘기는 합니다.) 평일에는 나름 루틴을 정하고 생활하고 있지만 주말은 일본 생활을 즐기려고 노력했습니다. 도쿄 구석구석을 산책하고, 맛집 탐방을 했습니다. 가끔 여행도 다녔습니다. 동네에도 어느새 단골 집들이 생겼습니다. 회사에서 BizComfort라는 공유 오피스 회원카드를 제공해 주어서 가끔 다른 지역을 구경하고 공부를 하기도 했습니다. 키치죠지에 있는 공유 오피스가 기억에 남는데, 공원 산책 후 수조를 보며 공부할 수 있어서 기분전환에 좋았습니다. 주말에는 맛집 혹은 UberEats를 통한 배달, 평일에는 아침 샌드위치, 점심 자유, 저녁 도시락 이렇게 전부 사 먹는 생활을 하다 보니 식비는 80 정도 지출하는 것 같습니다. 저는 먹는 것으로 스트레스를 푸는 편이라 식비 지출이 많은 편입니다. (직접 요리해서 먹는 동기들은 40~50 정도의 지출을 한다고 들었습니다.) 9월 중순쯤 발가락을 다쳐 병원에 갈 일이 있었습니다. 뼈에 금이 가서 깁스를 하게 되었는데, 병원마다 다르겠지만 제가 진료받은 병원은 꾸준히 상태를 보며 지속적인 치료를 하는 것 같습니다. 그래서 생각보다 지출이 심했습니다. 꼭 회사를 통해 보험 확인하시고 보험증 챙겨가시기 바랍니다. 보험증이 없다면 비보험으로 계산 후 영수증을 보험증과 같이 가져가시면 환급받을 수 있습니다.

-> 사람마다 추구하는 바가 다르겠지만, 저에게 있어 현재 일본에서의 생활은 제 인생 목표의 한 단계입니다. 주니어 개발자로서의 시작, 일본 생활의 시작일 뿐입니다. 그래서 저는 현재 경험할 수 있는 것을 최대한 하려고 생각했습니다. 자기개발에 필요한 강의, 교제, 일본어 과외와 같이 성장을 위한 투자에 지출을 아끼지 않고 있으며, 새로운 것을 보고 듣고 맛보는 즐거움을 통해 스트레스를 해소하고 새로운 문화를 경험하고 있습니다. 다른 사람들의 눈에는 헤프게 생활하는 것처럼 보일 수 있지만, 저는 가장 빠른 성장을 위해 시간에 지출하고 있다고 생각하고 있습니다. 여러분도 정답이 있는 것은 아니니 본인에 맞는 생활패턴 공부 방법을 찾으시고 너무 스트레스 받지 말고 힘든 타지 생활을 즐길 수 있는 취미생활 찾으시길 바라겠습니다.

[도쿄의 겨울, 추위와 변화] * 이직, 업무환경, 산업 및 직무 동향

도쿄는 12월이 되니 갑자기 추워졌습니다. 한국에서는 보일러를 틀고 생활했는데, 일본에서 지내다 보니 집이 추운 게 정말 힘듭니다. 가만히 있어도 오들오들 떨리는 추위에 히터를 틀곤 하지만, 히터는 건조해서 잠깐잠깐 틀어야 합니다. 날이 추우니까 지치기도 하고 연말 분위기에 휩쓸려서 잔디밭 관리도 멈추고 IT 공부는 2023년의 저에게 미루고 있습니다. 일본어 과외는 계속하고 있지만, 퇴근 후 집에 오면 귤과 곤약 젤리 그리고 넷플릭스와 함께하네요. 그래도 양심에 찔려 넷플릭스는 일본 콘텐츠만 시청하고 있습니다. 회사 생활은 가을과 겨울 사이에 여러 변화가 있었습니다. 개인적으로는 주 2회 재택근무를 하게 되었습니다. 팀리더에게 신뢰를 얻었고, 일본어로도 원만한 소통이 가능해져서 발생한 이슈에 직접 대응할 수 있게 되었기 때문이라고 생각합니다. 팀적으로는 팀원 두 명이 이직하게 되었습니다. 한 명은 입사 동기였는데, 초반부터 팀리더와 소통에 문제가 있었고, 제대로 연수를 받지 못하고 갑자기 기능 설계에 투입되어 힘들었던 것 같습니다. 2개월 정도 이직 준비를 하더니 규모가 제법 큰 한국계 IT기업으로 이직했습니다. 다른 한 명은 4년 차 선배입니다. 선배는 헤드헌팅 사이트에 이력서를 올려 두고 항상 오퍼를 확인하곤 했습니다. Product Manager 롤을 준비 중이었는데, 외국계 기업에서 2년 후 PM 롤을 맡는 조건으로 오퍼가 들어왔습니다. 저도 이번 프로젝트를 진행하면서 PM 들과 회의를 진행하다 보니, PM 롤에도 관심이 생겼는데 선배와 소통하며 PM에 대한 고민도 해볼 생각입니다. 갑작스러운 팀원의 공백으로 인해 개발자가 투입되어야 하지만, ‘부룩스의 법칙’을 살펴보면 “지체되는 소프트웨어 개발 프로젝트에 인력을 더하는 것은 개발을 늦춘다”라고 합니다. 현재 기능 설계 막바지 단계에서 새로운 인력이 투입된다면 새로운 개발자가 프로젝트를 파악하고 인수인계를 받는 것에 저를 포함한 팀원들의 시간을 소비하게 되어 전체적인 퍼포먼스가 낮아질 거라고 생각합니다. 팀리더도 같은 생각인지 당분간은 힘들더라도 남은 팀원끼리 진행할 것 같습니다. 12월은 그래도 연말 휴가가 있어서 휴가를 기다리며 남은 기간 열심히 해보려고 합니다.

-> 한국도 마찬가지겠지만, 일본은 특히 더 함께 일한 사람들의 평가가 좋으면 기회가 많다고 생각합니다. 다르게 말하자면 팀원들 나아가서 프로젝트 구성원과의 관계가 좋으면, 좋은 프로젝트에 추천을 받습니다. 일을 잘하는 것도 중요하지만, 일본 특유의 예의, 배려 있는 말투와 책임감을 가지고 일정에 맞추는 능력이 중요하다고 느꼈습니다. 선배의 말에 따르면 현재 이직하는 기업에도 추천 제도가 있다고 들었습니다. 팀원들에게 일을 믿고 맡길 수 있는 팀원, 함께 일하고 싶은 팀원이 된다면 더 좋은 환경에서 본인의 커리어 관리를 할 수 있다고 생각합니다.

여기까지가 이제 만으로 서른이 되는 제 일본 현지 생활 수기였습니다. 여러 부분에서 개인적으로 경험하고 느낀 점을 정리해 보았습니다만, 아직 신입으로서 경험이 적다 보니 부족한 부분이 많은 것 같습니다. 끝에서 나이를 밝힌 이유는 저는 서른이 될 때까지 좋게 말하면 제가 하고 싶은 일을 찾기 위해 빙빙 돌아왔고, 나쁘게 말하면 시간낭비도 많이 했습니다. 하지만 해외에서 새로운 시작을 할 수 있었기에 후회하지 않습니다. 20대 30대 지금 이글을 읽으시고, 도전을 걱정하시는 분들 모두 늦지 않았다고 생각합니다. 올 한 해도 수고하셨고 새해에는 소망하는 일 모두 이루세요! 끝까지 읽어주셔서 감사합니다.

이해한 것을 조금 더 쉽게 기억하기 위해 다음과 같이 입출력을 정리하고 나서야 손이 움직였다. 뇌가 깨어나는 기분이랄까.. 각성 상태에서 11번째 문제까지 풀어나갔다. 10번째 문제와 11번째 문제를 복기하자면

백준 입출력과 사칙연산 10번째 문제 : 2588

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class Num_2588 {
    public static void main(String[] args) throws IOException {

        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int num1 = Integer.parseInt(br.readLine());
        String num2 = br.readLine();
        int count = 0;
        double sum = 0;

        for(int i = num2.length(); i > 0; i--) {
            int num = Integer.parseInt(String.valueOf(num2.charAt(i - 1)));

            System.out.println(num * num1);
            sum += num * num1 * Math.pow(10, count);
            count++;
        }
        System.out.println((int)sum);
    }
}

10번째 문제는 종이에 대충 설계하고 시작했음에도 num1을 String, num2를 int로 받아 첫 번째 입력 값의 1의 자리부터 n의 자리까지 순서대로 두 번째 입력값을 곱하여 출력되는 값이 의도와 맞지 않았다. pseudocode 작성을 손에 익혀야겠다.

백준 입출력과 사칙연산 11번째 문제 : 11382

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.StringTokenizer;

public class Num_11382 {
    public static void main(String[] args) throws IOException {

        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

        String str = br.readLine();
        StringTokenizer st = new StringTokenizer(str, " ");

        long a = Long.parseLong(st.nextToken());
        long b = Long.parseLong(st.nextToken());
        long c = Long.parseLong(st.nextToken());

        System.out.println(a + b + c);
    }
}

11번째 문제는 입력값의 범위를 제대로 확인하지 않고 long 타입 대신 int 타입으로 작성하여 제출 시 오류가 났다. 입력값의 범위를 잘 확인해야겠다.

앞으로 꾸준히 코딩 테스트 공부한 결과를 업로드하길 다짐하며! 30대 개발자들 파이팅..

本日は皆さんが新社会人としてそして我が社の一員として記念すべき第一歩を踏み出す日です。 오늘은 여러분이 새로운 사회인으로서 그리고 우리회사의 일원으로서 기념할만한 첫발을 내딛는 날입니다.

すべき:적당, 타당하다 'するのがよい' 踏み出す:ふみだす 내딛는

私の名前は烈子 제 이름은 레츠코입니다

都内の企業に就職が決まり今日から新生活が始まります。 도내의기업에 취직이 결정되어 오늘부터 새로운 생활이 시작되었습니다.

始まる:はじまる 시작되다 決まる:きまる 결정되다

新しい土地新しい出会い 새로운 곳, 새로운 만남

私の進む先に輝く希望あふれる未来 나의 앞날에 밝은 희망이 넘치는 미래

輝く:かがやく (눈부시게)빛나다 あふれる:가득차 넘치다

よーしこれが私の社会人生活第一歩！ 좋았어! 이것이 나의 사회인으로서 생활 첫발이야!

会社行きたくない 회사 가기 싫다

(目覚ましの音) 알람소리

目覚まし:めざまし 알람

10数えたら起きる 10까지 세면 일어난다

数える:かぞえる 세다, 셈하다

10数えたら私は模範的な社会人 10까지 세면 나는 모범적인 사회인

模範的:もはんてき 모범적

財布持った定期持った携帯持った忘れ物なし！ 지갑있고, 정기권있고, 휴대폰있고 잊은 물건 없음!

忘れた！ 깜빡했다!(잊었다)

歯軋り 이를 갊

歯軋りをする:はぎしりをする 이를 갈다

豚の鼻息 돼지의 콧김

鼻息:はないき 콧김

サンダルできちゃった 센들로 와버렸다.

超ありえない 정말 있을 수 없다.

大丈夫 どうせすぐ制服に着替えるし 괜찮아, 어짜피 바로 제복(일할 때 복장)으로 갈아 입을 거니까 -> 일할 때 신는 신발로 갈아 신을 거니까

し:하고, ~해서(이유) 着替える:갈아입다 どうせ:어짜피

もし途中で誰かと会ったら不思議な踊りを踊って上半身に注意を引きつければ多分気づかれない 만약 도중에 누군가와 만나면 이상한 춤을 춰서 상반신에 주의를 끌면 아마 들키지 않을거야

引き付ける:ひきつける 주의를 끌다 気付かれる:きづく 눈치채다 + られる(수동형) 들키다

前方にエレベーターホール 전방에 엘리베이터 홀

あの集団がいなくなったタイミングで突入する 저 집단이 없어진 타이밍에 돌입하면

集団:しゅうだん 집단 突入:とつにゅう　돌입

おはよこざいます烈子先輩！ 안녕하세요, 레츠코선배!

角田さん！ 츠노다상!

何ですか？その動き 뭐에요 그 움직임?

ん？えーと。。踊ってるだけ 응? 아.. 그게.. 춤추는 거야

金曜の飲み会の幹事の件ありがとうございました〜 금요일 회식 준비해주셔서 감사했습니다~

~の幹事:かんじ　~일을 받아서 처리하는 것

私の仕切り下手のせいで先輩に全部やっていただく形になっちゃって 思ったんですよ烈子先輩って優しくて素敵な人だなあって！ 제가 결산에 서툴러서 선배가 전부 해 주시는 모양이 되어버려서 생각했습니다 레츠코선배는 친절하고 대단한 사람이라고요!

仕切り:しきり　仕切金정산금의 준말, 칸막이, 결말을 지음, 결산

スルーかよ！ 본 거 같아!

スルー:통과하다 through

ああえっと このサンダル？バカだよね私 그러니까 이 샌들? 바보같아 나

今朝慌てて家出たからうっかり間違えて 오늘아침에 황급히 집을 나가는 바람에 깜빡 잘못해서

慌てる:あわてる (놀라서)당황하다, 황급히 굴다, 서두르다 うっかり:무심코, 멍청히, 깜빡 間違える:まちがえる 잘못하다, 틀리다, 실수하다, 착각하다, 잘못알다, 잘못 가지다

またご一緒してください 또 함께 해 주세요~ (또 얘기해요~)

先行ってます 먼저 갈게요~

ねね　このうわさ聞いた？　ここだけの話なんだけど 있지 그 소문 들었어? 우리끼리니까 하는 말인데

* 참고 Reat, Vue.js 같은 웹 클라이언트 기술을 사용하고, 웹 프론트엔드 개발자가 별도로 있으면, 웹 프론트엔드 개발자가 웹 퍼블리셔 역할까지 포함해서 하는 경우도 있다. 웹 클라이언트 기술을 사용하면, 웹 프론트엔드 개발자가 HTML을 동적으로 만드는 역할과 웹 화면의 흐름을 담당한다. 이 경우 백엔드 개발자는 HTML 뷰 템플릿을 직접 만지는 대신에, HTTP API를 통해 웹 클라이언트가 필요로 하는 데이터와 기능을 제공하면 된다.

규모가 커지면 아래와 같은 방식으로 개발하기 때문에 화면에 대해 고민할 필요가 없다. 상황에 따라 백엔드 개발자가 해야할 역할이 달라지기 때문에 2가지 방식 모두 할 수 있어야 한다. -> 뷰 템플릿을 하나 정도는 알고 있어야 한다.

인프런강의 - 김영한님의 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-1

reset -> 옛날 commit으로 branch 되돌리기. 좋아요 버튼과 싫어요 버튼 기능을 만드는 중에 요구사항이 변경되었다. 싫어요 버튼은 빼고 좋아요 버튼까지만 만들어야 한다. 다행히 좋아요 버튼을 다 만들었고 commit까지 했다.

돌아갈 commit에서 오른쪽 버튼 클릭 -> master를 이 커밋으로 초기화 클릭 HARD 옵션으로 로컬 작업물을 지우고 master를 뒤 시점으로 되돌린다. 로컬에 있는 master는 제대로 reset이 되었지만 원격에 있는 master는 아직 적용이 안되었다. push로 이력을 고쳐야 하는데 push를 누르면 이미 push 했던 이력을 고치는 push 이기 때문에 오류가 난다. force push 강력 푸쉬가 필요하다. force push -> 이미 원격 저장소에 적용한 commit들을 수정할 때 사용 (혼자 사용하는 branch 에서 사용) MAC사용자는 소스트리 설정 -> 고급 -> 강제 푸시를 허용 체크 (소스트리 최신버전 한국어 설정시 오류있음 언어 영어로 바꾸고 설정 고급 강제푸시 허용 체크박스 체크 후 푸시 강제푸시 체크)

reset 옵션 HARD reset - 이후에 변경사항이 있어도 없어도 전부 날려버리고 옛날 버전으로 commit reset MIXED reset - 버전을 reset 하긴 하지만 그 후에 변경사항들은 로컬에 저장만 해 줌 reset 해도 남기고 싶은 파일들은 stage 아래에 남겨 두겠다.

commit의 변경사항을 되돌리고 싶을 때 - revert

revert -> 방금 만든 commit을 revert하는 새로운 commit 생성 master에 잘못된 커밋을 올렸다. reset하고 force push하면 다른 사람들 히스토리에 영향을 준다. revert하는 커밋을 새로 만들자

reset -> 히스토리 완전 초기화 revert -> 히스토리 새로 쌓아가며 변경

master branch에 잘못된 commit을 했을 때 HARD reset 을 하고 force push를 하게 되면 master는 모든 사람이 보고있는 branch이기 때문에 다른 사람들이 수정 중이라면 conflict가 발생한다. 이력을 수정하기보다 새로운 이력을 만들면서 잘못된 commit을 날려버린다.

여러가지 commit에서 내가 원하는 commit 하나만 떼서 지금 branch에 붙이고 싶을 때 - cherry pick

• 가장 최근 latest branch에 버그가 있다. 버그가 수정된 branch는 master branch다. 버그가 수정된 부분을 latest에 반영시키려면 merge해야 한다.
• 하지만 master에 다른 수정사항이 너무 많아서 lastest랑 당장 merge가 불가능하다.
• 당장 merge할 수 없는 이유는 latest branch는 무조건 release를 위한 branch이고 master branch는 완벽한 코드가 있는 branch이기 때문이다.
• release된 latest branch에 버그수정 commit은 들어가야 한다.
• 버그를 수정한 commit만 똑 떼서 lastest branch에 붙인다 -> cherry pick

지금 master branch에 필요한 commit은 버그 수정한 commit이다. cherry pick 하고 싶은 master branch에 떼어 붙이고 싶은 commit에서 우클릭 후 cherry pick하기

amend -> 깜박하고 추가하지 못한 파일이 있을 때 방금 만든 commit에 살짝 추가하는 명령어

짱 기능 추가로 모든 변경사항을 한 번에 commit하려고 했지만, commit을 한 다음 추가 수정이 있었다. push를 할 수 있는 commit이 존재하고 변경 사항도 존재한다. 같은 버전을 나타내는 commit인데 나뉘어져서 다시 돌아올 때 불편하다. 소스트리 commit에서 커밋 옵션 클릭 -> 마지막 커밋 수정 -> 수정한 파일 스테이지 올리기 -> commit 이미 올린 commit 수정하는 변경사항이다. 주의필요 혼자 사용하는 branch가 아니라면 다른 개발자가 코딩을 하고 있다가 수정이 되면 모든 히스토리가 꼬인다. 이력을 변경하는 git 명령어는 혼자 사용하는 branch에서 해야 한다. 기능 개발을 하는 branch는 보통 혼자 사용한다. master, dev 같은 큰 branch가 아니라면 보통 혼자 사용하는 branch에서 작업한다.

작업 중 급한 버그가 발생했다. 하던 일 중단하고 버그부터 수정해야 할 때 - stash

stash -> 변경사항을 잠시 킵하고, 커밋은 하지 않을 때 다른 branch로 가서 작업을 해야 한다. 하지만 지금 작업중인 branch에는 commit 못한 파일들이 있다. 우측 상단 스태시 클릭 후 메세지 작성

버그 수정을 완료했다. 이제 다시 기능을 이어서 개발하려고 한다. 서랍에 넣어 둔 commit을 꺼낸다.

1. 작업 중에 여러 파일 변경사항이 생겼지만 급한 이슈가 발생했다.
2. stash로 서랍에 넣어두기 (tracked만 들어감)
3. 다른 브랜치 이동해서 이슈 작업
4. stash pop 하기

fork한 저장소에서 기능 개발을 마치고, 해당 코드를 원본 저장소에 merge해야 한다. 권한이 없다면 pull request를 보낸다.

1. 머지하고 싶은 두 브랜치를 선택한다.
2. 어떤 변경을 했는지 제목과 내용을 작성한다.
3. 단일 저장소에서 보낼 수도 있고, 포크한 저장소에서 보낼 수도 있다.

pull request로 merge 요청 보내기

1. 여러 개발자와 협업중이라면, 최대한 직접 merge는 피하고 모든 merge를 pull request를 통해서 진행한다.
2. 동료 개발자가 내 PR을 보고 코드를 리뷰할 수 있다.
3. 동료의 PR에 수정이 필요하다면 댓글을 달아 change request를 보낼 수 있다. (ex 이코드는 수정이 필요합니다. PM에게 듣기로는 timeout을 10초로 해야 합니다.)
4. 오픈소스에 PR을 보낼때는 contribution guideline을 반드시 참고해야 한다.

Able to merge라고 보여지면 comflict없이 merge 할 수 있다. conflict가 난다면 미리 내 저장소에서 해결한 다음 PR을 보내야 한다. Tip -> 내용에 내가 수정한 코드 스크린샷으로 첨부하면 상대방이 코드리뷰하기 쉽다. -> 원본 저장소에서 File changed 탭을 클릭하면 review를 달 수 있다. -> Conversation 탭에서 리뷰 확인 가능

GitHub에서 PR확인하고 merge하고 로컬 저장소로 pull 하면 완료

오픈소스 프로젝트에 기여하고 싶은데, push 권한이 없다. commit전 반드시 컬래버레이터 등록을 부탁해야 하나? (X) fork 기능을 통해 저장소를 통째로 복제 (O)

1. git 저장소를 내 계정으로 복제한다.
2. 내 계정의 저장소에 자유롭게 커밋, 푸시를 한다.
3. 내 저장소의 브랜치와 원본 저장소의 브랜치의 merge를 요청한다.

branch vs fork

branch 와 fork 모두 코드를 협업하기 위해 분기점을 나누는 방식이지만 특성이 다르다.

branch

• 하나의 원본 저장소에서 분기를 나눈다.
• 하나의 원본 저장소에서 코드 커밋 이력을 편하게 볼 수 있다.
• 다수의 사용자가 다수의 브랜치를 만들면 관리하기 힘들다.
• 작은 팀에서의 협업

fork

• 여러 원격저장소를 만들어 분기를 나눈다.
• 원본 저장소에 영향을 미치지 않으므로 마음껏 코드를 수정할 수 있다.
• 원본저장소의 이력을 보려면 따로 주소를 추가해야 한다.
• 오픈소스 프로젝트 등 불특정 다수의 협업

fork 실습

오른쪽 상단 부분 watch -> 이 프로젝트에 관심이 있어서 업데이트 받아보기 star -> 프로젝트가 마음에 든다 좋아요 표시 fork -> 나만의 copy본 만들기

소스트리 새로 만들기 -> URL 복제 -> 복사한 저장소 주소 -> 폴더 설정 후 copy

원본 저장소 변경 이력 보기 위해 주소 추가하기 (소스트리)

원본 저장소 주소 복사 다음과 같이 소스트리에서 원격 저장소 추가 원본 저장소 이름 upstream 으로 지정하고 복사한 저장소 주소 추가 이렇게 추가하지 않으면 fork한 저장소(내가 작업하는 copy한 내 저장소)의 이력만 볼 수 있다. 원본 저장소의 변경이력을 보고 싶다면 다음과 같이 원본 저장소 주소 추가하기 다음 과 같이 upstream 우클릭 후 fetch 하면 원본 저장소의 branch 와 변경 이력 모두 확인 가능

다음 그림 3과 같은 경우 다른 브랜치에서 각각 같은 코드를 수정했다면 충돌이 일어난다. 그럼 충돌이 일어난 부분을 수동으로 수정해야 한다. 충돌을 해결하면 다음과 같은 새로운 머지 커밋이 생성된다.

충돌 시 소스트리에는 다음과 같은 형태로 보여진다

======= 를 기준으로 충돌 부분을 알 수 있다. Current Change -> base 기준이 되는 브랜치 Incoming Change -> 들어오는 머지 될 브랜치

인간의 개입이 필요한 부분 -> 개발자 회의를 통해 '스파링 싫어요' 로 갑시다. '스파링 좋아요' 로 갑시다. 등등 결과물을 정한 후 직접 수정한다.

해당 코드를 수정하여 원하는 코드만 남기는 것이 conflict 해결이다.

1. 변경 사항의 모음이 아니고, 하나의 최종 코드모음이다.
2. 다만 기존 커밋과 비교해서 변경된 파일이 아니면 '변경되지 않았다' 라는 정보만 저장해서 용량이 무겁지 않다 (파일 상태를 관리)
   • svn은 바로 이전 커밋과 + 변경사항만 저장
   • svn이 git보다 커밋당 버전 용량은 가벼울 수 있지만 한 버전을 보려면 맨 처음 커밋부터 계산해야 한다 -> git보다 속도가 느리다
   • git은 이전 커밋만 보면 된다 -> svn 보다 속도가 빠르다

작업 공간에 파일 생성 후 파일 상태 -> 추적 안됨 git add를 하면 스테이지에 올라가게 됨 git commit을 하면 파일 상태 수정 없음으로 변하고 git push를 하면 원격 저장소에 올라감 app.js 수정하고 app.css 새로운 파일 추가하면 app.js는 파일 상태 수정, app.css는 아직 stage에 올라가지 않아서 추적 안됨 app.js와 app.css파일만 상태가 변하고, 스테이지에는 같이 올라감 git commit시 모든 파일의 상태가 수정 없음으로 돌아감

Git으로 추적하는 파일의 상태는 4가지

untracked (git에 한번 도 올리지 않은 파일)

1. 추적안됨

tracked 2. 수정 없음 3. 수정함 4. 스테이지 됨

내 작업공간에 있는 수정한 파일이나 새로 생성한 파일을 add를 통해 스테이지에 올려 '스테이지 됨' 상태로 변경하고 commit을 하면 '수정 없음' 상태로 돌아간다. '수정 없음' 상태가 된 파일은 다시 수정할 수 있다.

소스트리(SourceTree)설치

버튼 클릭으로 git 명령 실행하는 툴 소스트리 설치하기 https://www.atlassian.com/ko/software/sourcetree (google 소스트리 다운로드 검색 통해 진행)

소스트리 -> 새로 만들기 -> 로컬 저장소 추가하기 -> 로컬 레포지토리 열기 -> 더블클릭

소스트리에서 파일 상태 ? -> untracked ... -> 수정함

위의 파일상태처럼 새로 생성하거나, 수정한 파일을 소스트리의 gui를 통해 스테이지에 올린다. 아래 커밋메세지에 본인 이름이 뜨지 않는다면 소스트리 설정 -> 계정(인증) -> 추가-> 인증방식(OAuth) -> 프로토콜(HTTPS) -> 계정연결 -> github 로그인 후 진행 커밋 진행 시 다음과 같은 브랜치를 볼 수 있다 origin/master -> 원격 저장소에 push된 코드 master -> 아직 로컬에만 존재하는 코드 push 통해 원격 저장소에 올리고 브랜치 관리

MAC 소스트리 push 오류 저장소 설정 -> 원격 -> 저장소 url 변경 https://<토큰 값>@github.com/<사용자명>/<레포지터리명>.git

내 상태 로컬상태인 master가 origin즉 원격 저장소에 저장된 커밋보다 1개 뒤 라는 것을 알 수 있다. pull로 해당 커밋 받아오기

Git branch에 대해서

앞에서 실습한 것 처럼 순차적으로 commit push pull 할수는 없다. 여러 개발자가 함께 작업을 하게되면 위 그림과 같이 충돌 할 수 있는 상황이 대부분이다. 이와 같이 여러 가지로 커밋을 만들면 된다. 이렇게 나무의 가지가 여러갈래로 뻗어나가는 것 같이 생겨서 branch라고 한다. 한 가지에서 작업하면 충돌이 날 수 있다. 똑같은 코드를 동시에 고칠 가능성도 있다. 여러 가지로 각자 작업을 하고 합치는 시점에서 명시적으로 충돌을 해결할 수 있다.

git push origin master -> master 브랜치(기본 브랜치)에 커밋을 푸시해라 git branch cat -> cat 브랜치를 현재 시점에 만들어라

git checkout cat -> cat 브랜치로 이동해라 cat 브랜치에 커밋을 추가한다면 master 브랜치는 과거 커밋을, cat 브랜치는 새 커밋을 가리키게 됨

보통 브랜치는 새로운 기능을 추가할 때 만들게 됨

두 버전 합치기 merge

master브랜치의 최신 커밋(base)에 oct브랜치의 최신 커밋(compare)를 합치려고 한다. 먼저 head를 base가 될 master브랜치로 옮겨줘야 한다. -> master 브랜치로 이동 git checkout master git merge oct -> compare 브랜치인 oct를 나와 합치고 싶다 문어A는 고양4 + a(알파)니까 두 브랜치가 합쳐지면 결과물은 당연히 문어A oct와 master 브랜치 모두 문어A를 가리킨다. 이렇게 병합을 하게 되면 나의 로컬 master는 인덱스 수정 commit으로 이동한 것을 알 수 있다. 원격 저장소의 origin master는 아직 남아있다.

git push origin master -> 마스터에 merge했으니 master에 push 한다. 원격 저장소에도 적용 완료

버전관리란?

RPG 게임할 때 게임을 종료하기 전에 게임 데이터를 저장한다. 다시 게임을 시작할 때에는 이전에 저장한 데이터를 불러와서 이어서 게임을 할 수 있다. 문서작성시 Ctrl + Z 를 통해 뒤로 갈 수 있다. 이렇게 내가 원하는 시점(버전)으로 이동할 수 있게 해 주는 것이 버전관리이며, 이를 도와주는 툴이 버전 관리 시스템이다.

버전관리를 한다면 개발자 간의 협업을 위해 전체 개발 소스를 공유하면서 개발 파트를 나누어 개발할 수 있다.

Git

Git은 본인의 코드와 그 수정내역을 기록하고 관리하도록 돕는 버전 관리 프로그램이며, 로컬에서 프로젝트의 기록을 스스로 관리할 수 있도록 해준다. Git을 통해 브랜치를 생성하고 이전 브랜치로 복구, 삭제, 병합이 가능하다.

GitHub

GitHub는 Git 저장소를 관리하는 클라우드 호스팅 서비스. git 저장소 호스팅 서비스는 클라우드 기반으로 다른 사람과 소스코드 공유가 가능하며 git의 기본적인 기능을 확장하여 제공한다.

Git - 버전 관리 '프로그램' Git - 버전 관리, 소스 코드 공유, 분산 버전 제어 등등이 가능한 원격 저장소.

GitHub에 코드를 올리는 과정

1. 내 컴퓨터 프로젝트 폴더에 '여기는 Git repository 에요' 라고 명령 (git init)
2. 내가 변경한(코딩한) 파일 중 Git에 올리길 원하는 파일 선택 (git add)
3. 선택한 파일들을 하나로 만들고 설명 적기 (git commit -m "첫 커밋")
4. 내 컴퓨터 프로젝트 폴더에 GitHub 사이트에서 미리 만들어 놓은 GitHub 저장소 주소 알려주기 (git remote add)
5. 3.에서 하나로 만든 부분 GitHub에 올리기 (git push)

git init을 통해 Git 초기화를 하면 .git이라는 숨겨진 폴더가 만들어진다. 그럼 로컬 저장소가 되는데, 이곳에 내가 만든 버전 정보, 원격 저장소의 주소 등이 저장된다. 원격 저장소에서 내 컴퓨터로 코드를 다운 받아도 로컬 저장소가 자동으로 생성된다. 그렇기 때문에 이 점을 주의하고 한 폴더에 하나의 로컬 저장소만 유지해야 한다.

Git 다운로드, GitHub 계정 만들기 내 컴퓨터에 폴더 만들기 터미널에서 cd 폴더명 -> git init -> ls -al 로 확인

Commit = 하나의 버전 페이지 1,2,3 작성 -> commit -> 페이지 1,2,3 이 하나의 버전 페이지 2 수정 -> commit -> 페이지 1,2(수정),3 이 하나의 버전 페이지 2의 수정본이 이상하다면 전 버전으로 이동 가능

add = commit 으로 만들기 원하는 파일만 선택 페이지 1,2,3 작성 -> add -> 페이지 1,2 선택 -> commit -> 페이지 1,2 가 하나의 버전

commit시 사용자 설정 git config --global user.name "Minsung Han" git config --global user.email bestfriend1562@gmail.com

버전 생성 실습

1. VS Code에서 README.md, index.html 파일 생성
2. 원하는 파일 선택 git add README.md
3. 메세지를 달아 commit으로 만들기 git commit -m "프로젝트 설명 파일 추가"
4. 생성한 커밋 보기 git log

Commit Tip

1. commit은 '의미 있는 변동사항'을 묶어서 만든다.
2. 어떤 기능을 수정하는데 3가지 파일을 수정했다면 그 3가지를 묶어서 하나의 커밋으로 만든다.
3. 동료 개발자 혹은 미래의 내가 '어떤 기능 수정'시 어떤 파일을 수정했는지 파악할 수 있다.
4. 메세지는 적어야 나중에 후회하지 않는다.

원격 저장소 GitHub에 커밋 푸시하기

1. GitHub에 로그인하고 저장소 생성
2. 내 컴퓨터 폴더에 GitHub 저장소 주소 알려주기 git remote add origin https://github.com/아이디/이름 (저장소 주소 복사 붙이기)
3. 만든 커밋 푸시하기 git push origin master
4. GitHub 사이트에서 커밋 확인하기

만약 비밀번호 인증 오류가 뜬다면 설정에 들어가서 token을 삭제하고 다시 발급받아서 진행해야 한다. (MAC 은 keychain 에 들어가서 github에 관련된 부분을 삭제하고 진행)

clone = 원격 저장소를 내 컴퓨터에 받아오기 .git 까지 자동으로 생성

pull = 원격 저장소의 데이터 가져오기 clone으로 가져온 원격저장소에 새로운 데이터가 생겼다면 pull로 받아오기

만약 clone 로 가져온 원격저장소에 내가 수정한 파일을 push 하고 싶다면 권한이 있어야 한다.

GitHub 저장소 내 컴퓨터에 받아오기

1. 내 컴퓨터에 폴더를 만들고 GiuHub의 저장소 받아오기 git clone https://~ (저장소 주소 복사) . 반드시 . 을 찍어줘야 한다. 안 찍으면 새 폴더 생성한다.
2. 새로운 파일 생성 후 add->commit->push 해보기
3. GiuHub에서 새 커밋 확인하기

원격 저장소의 변경사항 내 컴퓨터에 받아오기

1. 내 컴퓨터에 폴더로 이동 후 새로운 파일 없는거 확인
2. 풀 명령어로 다른 개발자가 새로 올린 커밋 받아오기 git pull origin master
3. 새로 생긴 파일 확인