저도 신입 병아리 개발자이긴하지만.. 첫번째 문제를 학원에서부터 느낀 게, 코딩 잘 하는 사람들이 뭔가 막히자마자 강사님에게 물어보는 경우는 거의 없었던 것 같아요. 반면에 뭐 에러나고 실행 안 되고 할 때마다 강사님 불러서 물어보는 사람들은 처음엔 실력에 큰 차이가 없어보여도 몇개월 지나면 스스로 해결한 사람들과 실력이 어마어마하게 벌어져있더군요. 그리고 6시간씩 붙들고 해결하려고하는 건, 확실히 업무적 측면에서는 생산성 저하로 볼 수 있기 때문에 좋은 행동은 아니지만 공부할 때는 하루종일이라도 혼자 계속 찾아보고 해결해보는 게 되게 좋은 방법이라고 생각해요. 문제를 확실하게 해결하고 재발 방지까지 하기 위해선 이 에러가 '왜'발생한 것인지 명확히 알아야하기 때문에 결국 구조를 파고들게 되면서 자연스럽게 필수적인 개념들을 습득하게 되고, 문제 해결에 직접적으로 도움을 준 방법이 아니었을지라도 그 헤딩의 경험이 결국엔 나중에 도움이 될 때도 많더라구요..ㅎㅎ
첫번째 문제(주니어가 찾지 않고 바로 물어보는 경우나 너무 오랜시간 끙끙대는것)에 관련해서 말하자면, 주니어들은 계속 문제 해결능력을 키우도록 냅두는게 좋아 보입니다. 하지만 시간이 제한되어 있으니, daily progress report를 통해서 관리자가 현재 junior의 문제를 지적하고 guideline만 주는게 효율적인것 같습니다. 결국 나중에 senior레벨로 진입했을 때 program solving능력에 따라서 실력이 분간되는데, 주니어때 부터 깊게 연구하는 버릇을 들이지 않으면 이 능력이 배양되기 힘듭니다. 결국 회사를 이끌어가는것은 senior 레벨이라는 전제하에 junior에 대한 기대는 낮추고 인력양성 기간이라는 관점에서 접근하면 시간은 걸리더라도 좋은 인력을 양성할 수 있습니다. 결론은 주니어의 실수 횟수나 능력은 관리자나 팀의 계획 및 선견에 달려있다고 봅니다.
혼자 고민해보는 게 30분에서 1시간정도가 가장 적당한 시간이군욤....! 항상 너무 많이 고민하면 진이 빠져버리고 너무 쉽게 물어보면 성취감 없이 맥 빠지고 ㅋㅋㅋㅋㅋ 그랬는데... 덕분에 뭔가 깨닫고 갑니다 ㅎㅎ 추천영상에 떠서 보기 시작했는데 영상들이 다 도움이 되는 것 같아요.... 코딩도 잘해야하지만 요새 가끔 개발자가 가져야 할 마음가짐(?)같은거나 성찰해봐야 할 점들에 대해서 알고 싶었는데 그런 점에서 정말 도움이 되어요...!
바로 물어보는 시대적 상황이 큰거 같아요 옛날에는 정보 구하기 힘든 만큼 직접 해보면서 찾아보는게 습관화 되는게 일반적인데 이제는 찾으면 바로 나오니 해보는것보다 바로 찾아보는게 습관화 되어있고 그게 가장 빠른 방법이니 회사에서는 물어보는게 가장 빠른 방법이니 바로 물어보는 경향이 큰거 같아요
1번은 사실 사수도 어느정도 감성이 있는 분이라면 이게 알아볼대로 알아보고 묻는지 바로 다이렉트로 와서 질문하는 상황인지 눈치챌 수 있죠.. 저는 10년 넘은 c 개발자 인데 당연히 어느정도 후배를 키우는것도 회사에서 선임자에게 돈을 더 많이주는 이유라고 보는데 질문을 할때 이렇게 봤고 저렇게 봤고 이걸 찾았는데 긴가민가하고 이건가 하는데 또 안된다 어떻게 해야할까요 이런 질문만 되도.. 충분히 노력해 봤구나 하면서 답을 주긴 주되 그 노력에서 어느 방법이 추가되면 다음엔 스스로 해결 할 수 있구나 하게 만들어 줘야죠
개발기간은 우리나라 외주들의 문제이기도 하죠. 매니저로 비유한 게 발주자로 치환해서 말하면, 프로젝트 하나 따겠다고 무조건 지르고 봅니다. 근데, 막상 해보니깐 기간이 더 걸릴 것 같으니깐 이상한 변명만 늘어놓고 개발은 개발대로 안 되고 나중에 가면 될대로 되라는 식으로 나오고 있죠. 무슨 학부생도 아니고 나중에는 어디가 아프다 어디가 아프다 집 안에 무슨 일이 있다 등 온갖 변명이 난무합니다. 주변에서 하루 이틀 본 게 아닙니다. 물론 무조건 빨리 만들어준다고 하면 좋다고 업체 선정하는 발주자도 문제이지만, 책임질 수도 없는데 자신있다고 된다고 해서 프로젝트 떠맡는 사람들도 문제라고 봅니다. 공대 출신들은 특히 영업이나 말빨이 안 되다보니 저런 것도 잘 설명해서 오히려 신뢰를 얻고 기간을 더 길게 잡으면서도 금액은 금액대로 받을 수 있어야 되는데, 일단 지르고 보니 참 개발자나 맡긴 사람이나 골치 아픈 경험을 하게 됩니다. 그래도 오늘 해주신 말씀보니 참 도움이 많이 됩니다. 단위를 바꾸고 x2를 하라는 말씀은 진짜 뼈가 되고 살이 되는 말씀이네요. 좋은 영상 많이 찍어주셔서 감사합니다! 구독하고 좋아요 항상 박고 다녀요!
키워드를 찾냐 못찾냐 차이 입니다. 뭘 모르는지 아는게 중요하죠. 서핑 겁나게 하면 키워드 끝자락이 나타나긴 해요. 그걸 캐치하는게 능력 입니다. 그리고 세팅 같은거는 회사 내에 노하우로 전수해줘야 한다고 생각해요. 세팅할 때 쓰는 시간은 아깝지 않나요? 세팅 끙끙대면 뭘 배우는지 잘 모르겠는 1인..
공감합니다. 영상 잘 봤구요, 멘토링으로 주니어를 키우고 있는데 이 영상이 생각나서 다시 찾아와 봤습니다. 단위를 바꿔서 곱하기 2 공식은 조금 과하다는 느낌이 들기는 한데, 저도 제 경험이 비추어 곰곰히 생각해봐야겠습니다. 개인적으로는 곱하기 2를 합니다. 공수산정에 실패해서 피 본뒤부터는.
* 실수 요약 1. 고민없이 물어보는 행위 - 사내 문서(Usage), StackOverflow 등 참조 - 30분~1시간 고민 (적절한 밸런스) 2. 여러가지 개발방안 생각하지 않는 행위 - A,B,C 안 리서치 훈련 - A,B,C 안 설계하고 상사에게 보고하고 질의! 3. 자신을 과대평가 - 개발기간을 넉넉히(본인 생각 X2) - Testing, 검증시간까지 포함
ㅎㅎ 20년차 개발자(개발이 재밌어서 , 아직도 코딩을 하는) 인데요, 지금까지 수많은 동료/상사/팀원등의 개발자를 겪어온 입장에서 완정 공감됩니다. 하나하나 모두 실제 개발현장에서 아주 흔하게 볼수 있는 유형 입니다. 단지 추가 하고 싶은 부분은 물론 주니어 개발자의 기준을 단지 경험 년수가 아닌 역량으로 판단할 경우라고 보이네요 ( 실제 신입이 아닌 경력이 많은 개발자도 말씀하신 3가지 실수를 무한 반복 하는 경우를 많이 봐서...)
3번째 너무 공감됩니다. 첫 프로젝트의 딱 저네요 ㅋㅋ 2번째. 다른 방법이 있다는걸 알아도, 주어진 개발기간 내에 다른걸 시도해볼 시간이 없어요. 최소한 구현은 해야하는데, 알아보다 구현도 못하면 최악의 상황이니까요. 1번째. 오래오래 끙끙대는 편이라 밸런스를 찾아야하는데, 구글링 첫페이지만 적용해도 어느샌가 시간이 너무 흘러 걱정입니다ㅜ
말씀하신거에 공감하면서 저기에 다가 주니어 개발자들은 assumption을 만드는 경우가 많은거 같아요. 당연히 회사에 경력이 짧아서 시스템을 다 이해하기 힘들고 한데 "이거일거야"라는 느낌으로 criteria를 잘못 이해하고 개발을 시작하구요 만들고 나면 결국에 일을 다 다시 해야하는 상황이 간혹 오더라구요. 모르면 물어보는게 오히려 좋을때가 있어요
솔직히 실수라기보다 , 경험이 없으니 발생할 수 있는 일들이라고 생각하네요. 저도 아래 후임 받아보니 나는 신입때 이런걸 생각해서 안물어보고 최대한 노력해보고 물어봤는데 , 너는 왜 이런 최소한의 노력을 안하고 바로 질문하냐 같은 생각을 많이했었구요. 근데 그사람 이 나의정답대로 안했을뿐 나름대로 고민했을 수도 있어요.
저는 회사에 저 혼자 개발자여서 모든 걸 혼자 해결 해야하는 상황입니다. 1. 문제가 발생하면 하루가 걸리든 이틀이 걸리든 최대한 찾아보고 고민해서 해결 해야해서 가끔 굉장히 비효율적일 때가 있는 것 같아요. 그렇지만 대부분의 문제를 직접 해결 한다는 부분에서 제 경험에 있어서 좋겠죠 :) 2. 무엇인가 만들어야할 때 시간을 많이 쓰더라도 DB나 프로젝트 구조 설계를 최대한 잘 해보려고 합니다. 어차피 혼자 관리 해야하기 때문에 이후에 유지보수를 최대한 적게할 수 있는 방향으로 하고, 코드도 무조건 짧게 보다는 직관적으로 알 수 있도록 관리하려고 하는 편입니당 3. 개발기간은 약간 의미가 없을 수도 있는 부분인데, 새로운 기능 추가하거나 변경할 때, 디자이너도 없어서 기획부터 디자인, 개발을 혼자 하다보니 빨리 할 수 있는한 빨리 하려고 하는 것 같네요. 저도 계속 혼자 하다보니 다른 분들이랑 같이 할 수 있는 뭔가 해보는 게 좋을 것 같은데, 혹시 좋은 팁이 있을까요~?
@@WonieSong 아 그런 방법이 있었군요 ! 최근에 처음으로 별 4개 짜리 프로젝트 버그 고쳐서 contributor 돼 봤는데, 좀 더 큰 프로젝트에 도전을 해봐야겠습니다 :) 감사합니다~! 워니님 제가 아직 파이썬을 안해봤는데, 이번주에 공부해보려구요~ 좋은 콘텐츠 감사해요^^
제가 게임개발자인데 초보자가 하는 실수는 일단 언어선택에 실수 다음으로 첨부터 그랙픽하는 사람이랑 둘이 같이 시작하는거 강추. 왜냐면 겜 다 만들어놓고 그래픽하는 사람이랑 같이 일할려면 돈문제가 모호해짐. 내가 죽어라 고생해 만들었는데 갑자기 누가 들어와 수익의 1대1로 나누자 하면 그게 머가 됨? 3대1 4대1... 그런것도 맞추기가 힘들고 올려고도 안함. 3번째가 겜을 욕심이 생기니 너무 거창하게 만듬. 그러다 만들다보면 이게 실제로 해보니 이거하나때문에 많은 문제가 발생하는걸 깨닫고 다 쳐냄. 그러다보면 시간만 낭비하는 꼴이 됨
딱 저네요 ㅋㅋㅋㅋ 저는 고3이고 이제 소프트웨어과를 가게 되었는데 이미 c언어를 배워서 막 제스스로 코딩을 하고 이걸 오류가 발생하면 길면 7일동안 끌고간 적이 있어서 ㅋㅋㅋ 엄청 시간을 소비해서 걱정이였는데 다음부터는 다른 프로그래머에게도 도움을 요청해야겠네요 ㅋㅋㅋㅋㅋㅋ
5년차 현직 개발자입니다. 선임개발자도 모든것을 알고있지는 않습니다. 단지 경험으로 해당 CASE를 검색하는거죠. 자신이 검색하고 찾으면 자신의 CASE를 하나 쌓아가는거죠. 개발자도 외과의사처럼 CASE BY CASE로 성장한다고생각합니다. 나중에는 그게 중요한 자산이 될겁니다.
저는 개발자?라고도 하기 애매하네요. 컴퓨터비전으로 석사하고 현재는 제조업 머신비전 엔지니어로 1년 4개월째 근무하고 있습니다. 스타트업에다 회사에 소프트웨어 담당하는 사람 수 자체가 적다보니 코드베이스가 좀 많이 부족한 상황에서 같이 만들어가는 입장이라 주니어인데도 불구하고 혼자 삽질하는 시간이 굉장히 많은 편입니다. 말씀하신 2배 전략?같은 걸 기간에 산정해서 넣으면 윗선에선 줄이라하고.... ㅎㅎ...... 사용하는 하드웨어에 대해서도 항상 바뀔때마다 다른 코드를 작성해야하는지라 구글링해도 안나오는게 대부분... 그래서 지금 남아계시는 단 한명의 사수분에게 물어보면 코드보라는 말로 어느정도 돌아오는데 그 코드볼 시간이면 강제로 줄여진 시간에 맞추기는 참......... 저짓거리하다 출장 세달반 다녀오고 하니 건강은 더 나빠지고 하니 '삽질하는 시간도 안주고 개고생하는데 이 돈 받으면서까지 남아있어야 돼나?'라는 생각에 자괴감만 드는군요.
첫번째는 예의 정도의 선에서 생각할수 있구요.... 왜냐하면 조금 찾아보고 나서 여쭙고 다녀야 설명을 이해하고 어디까지 찾아봤는데 여기서 문제인것같다고 최대한 정보제공을 해야 선임도 어느선으로 설명을 해야하는지 대략 감이 오거든요. 둘째는 주니어로서는 제일 어려운문제라고 생각합니다. 주니어 입장인 저는 기본적으로 불가능은 없다는 전제하에 찾기때문에 a b 정도는 방법을 알고, c 는 가능할것같고 d 라는 방법이 있는지도 모를때가 많더군요.... 이것은 경험이 계속 누적되야 개선될것 같구요, 세번째 워킹데이 산정은 주니어에겐 불가능하다고 생각됩니다. 이유가 딱히 설명 안할정도로 당연하다고 생각되구요, 29년차 개발자이신 분이 설명하신 바에 따르면 요구사항 분석에서부터 기획, 일정잡는 부분, 이에 대한 시니어급의 판단이 어느정도 있어야 착수할수 있기때문이라고 하시네요.
큰 회사나 주류 언어를 사용하는 회사는 그렇겠지요 주니어 개발자들을 탓할게 아니라 시니어 개발자들이 자기도 겪은일인데 주니어 개발자들이 빨리따라올수 있도록 제대로된 문서하나 안남기는게 문제라고 봅니다. 그런거 하나 제대로 남겨왔다면 이 분야가 더 빨리발전해왔을텐데요 4년차가 주니어 개발자에게 주는 조언이라.. 참.. 도움이 되지만 한편으로 시니어개발자들에겐 반성해야 할 주제입니다
저도 비전공자이고 국비지원 나왔는데 진짜 배이스가 되는 기초지식은 할 수 있는한 최대한 익히고 들어가야지 맞다고 생각함 그게아니면 야근해서라도 공부해야지 그런 마음가짐이 아니고서야 무슨 전공자랑 맞먹겠다고 자랑이랍시고 당연히 가르쳐줘야한다는 신입들 마인드보면 좀 웃음이 나온다ㅋㅋ 근데 전공자도 전공자 같지 않은 사람들 많은게 문제긴한데 객관적으로는 신입쪽은 비전공자랑 전공자랑 차이를 못느끼겠음 누가 더 열심히 요령껏 잘하느냐는 타고난것도 좀 있고 최소한 저는 사수에게 질문하기전에 구글에서 이렇게 검색해봤고 테스트서버에 적용시켜보니 여기서 문제가 나던데 이건 검색을 해도 나오는 자료가 없다는 식으로 대부분 물어보지 덮어놓고 전부 가르쳐달라는 짓은 절대 안함 그게 예의가 아니기도하고
초심자는 자신이 처음 예상한 개발기간의 2배가 걸린다고 생각하면 됨. 최소 2배 이상의 시간이 걸릴 것이라고 생각하면 되는데, 영상에서 나왔듯이 자신이 모르는 공정이나 출시까지의 여러가지 단계가 많을 수 있고 이에 따른 업무가 반복되며, 프리렌서 또는 아주 작은 회사라면 클라이언트의 변덕, 규모 있는 회사라면 다른 부서의 여러가지 사정 등 별의 별 상황이 발생하는데, 그러한 변수에 따른 자신의 일정 조정이 쉽지 않음. 애초에 넉넉히 정했으면 그 기간동안 상황 변화에 따라 여유롭게 대응해나가면 되는데, 클라이언트 또는 다른 부서는 그 처음 정한 일정을 가지고 다시 계획을 잡으니, 자신만 힘들어짐. 가끔씩 프리랜서 형식으로 웹 개발 일을 하곤 하는데, 클라이언트가 두달 정도 걸릴 만한 일을 맡기면서 급하다고 한달 만에 끝낼 수 있냐?라고 물어보면 한달은 고사하고 최소 2달은 걸릴 것이고 분명히 이 일은 3달에서 4달은 걸릴거다라고 답함. 그러면 급한 상황인데 이런 이런 기능만 있으면 된다라고 하면서 2달이면 확실히 되냐라고 되묻는데, 아니다 보아하니 분명히 3~4달 후에나 프로젝트가 완료될 거다. 지금 원하는 것만 하면 2달안에 할 자신이 있다 그런데, 100% 중간 중간에 또 다른 기능이나 변경사항을 요구할 거다. 그래서 마음에 드는 결과물이 나오는데까지 4개월은 족히 지나가있을 거다. 여지껏 경험상 그 누구도 예외가 없었다라고 대답하고 4개월까지 걸릴 수 있는 일임을 명확히 하고 일을 시작함. 2개월을 계약해놓고 중간중간 변동사항과 일정 가지고 실랑이 하는 것은 보통 곤욕스러운 것이 아니고, 애초에 여유있게 잡아야 마음도 안 급하고 여러가지 좋은 방법을 고민하고 찾아가면서 완성도를 높일 수 있음. 물론 회사라면 개발자 자신이 일정을 잡는 게 아니고 주어진대로 맞춰가야 하니 상황은 좀 다름.
앜ㅋㅋ 뭔가 주니어개발자들 행동 공감가네요 ㅋㅋ 제가 아직 대학생이라서 코딩작업을 하드하게 하는 것은 아니지만... 기말 프로젝트나 중간 프로젝트할 때, 어떻게 해야할지 몰라서 이틀 동안 문제 해결할려고 부여잡고 교수님께 여쭤봐도 직접 찾으라고 얘기하셔서 ㄹㅇ 죽을 맛이었던 적이 기억나네욬ㅋㅋㅋㅋ 그리고 개발기간은 정말로 많이 도움됐습니다. 저도 제 실력 과신하지 않고 단위 바꾸고 2배로해서 시험해봐야겠어요 ㅋㅋㅋ
제가 생각하기에는 말씀하신 부분들은 회사 내 신입사원을 위한 매뉴얼로 시행착오를 해결 할 수 있는 부분인데 대부분의 회사들이 개발 업무 매뉴얼이 부족한거 같아요. 한국에서는 특히 개발업무 신입교육과 업무매뉴얼이 제조업과 마찬가지로 기술직임에도 체계적이지 않더라고요. 대표가 잘 모르다보니 아예 맡겨버리거나 사수가 꼰대라서 신입에게 잔소리만 하고 제대로 안알려주는 경우도 많고요. 사람관리와 교육도 회사 역량이 필요한 부분인데 그걸 개인의 책임으로 넘기려는 느낌이 강한 것 같아요.
@@WonieSong 네 맞아요. 저는 정돈이 부족한 상태에서 속도와 성장을 동시에 추구하는 모습이 아이티 업계의 강점이자 약점이라고 생각해요. '기본', '상식' 같은 말들은 집단과 상황, 맥락에 따라 달라지는 말들이거든요. 초기 시행착오를 매뉴얼화 해서 교육시키는 것은 회사 사내 교육만의 역량은 아니라고 생각하고요. 학교 교육과의 연계나 실무교육과정에서도 함께 필요한 부분이라고 생각합니다. 답변해주셔서 감사합니다.
다 정말 공감해요,,첫번째 문제는 여러 교육을 진행하다보니까 시간 제한을 주는게 좋더라구요. 제가 생각할때 30분이면 할수 있는 일이면, 최대 2시간을 주고 1시간이 경과해도 피드백이 안오면 중간 점검을 해서 플로우를 정리해주면 웬만해서 제한시간안에 해결하시더라구요. 만약 해결 못했으면 제가 하는 방식을 알려주고 다른 방법으로 할수있는 블로그 글을 소개하는 편이예요. 막연하게 미션을 주면 너무 많은 정보를 찾아봐서 그런지ㅋㅋㅋ오히려 더 어렵게(?) 느끼는 것 같아요
@@WonieSong 사실 계속 신경쓰이고 제 작업시간이 부족해지긴 하지만 확실히 초반에 집중해서 교육하면 저랑 업무스타일도 비슷해지고 막히는 부분들을 듣다보면 저도 새로운 관점이 생겨서 힘들기도 하지만 좋은 점도 있는 것 같아요! 저는 많아봤자 멘티가 2명이었는데, 그 이상되면 트리형으로 관리를 해요ㅋㅋㅋ조금이라도 먼저 들어온 멘티한테 배운거 그대로 시키고 코드리뷰하면 뭐가 부족한지, 교육이 잘되고 있는지 확인이 되는 것 같아요.
지금 주니어 대리고 일하는데 개빡칩니다 제가 지금 9년차인데 디버그도 제대로 안하고 서버탓만 하고 서버가 이상하니 니가 고치세요 시전하고 제가 1분만에 코드 문제라고 풀어내면 띠용!! 이러고 있고 인프라 aws로 바꿔놨더니 니가 바꿔놓고 왜 배우라고 하느냐 이런 늬앙스나 지껄이고 개발 트렌드 맞춰서 가이드 주고 모든 레퍼런스를 다 주는대도 모른척 합니다 ㅋㅋㅋ 전 현재 인프라 웹개발까지 다 하고 있습니다 ㅠㅠ
다른 영상 보고 이 영상보면서 느꼈던 건, 요새 프로그래머들은 (워니님도 강조하셨던) 조각화 방식으로 공부를 하니 주니어 때 1번, 2번 같은 실수를 하는게 당연하다고 봅니다. 다른 걸 베끼고 그대로 복붙하는 방식으로 개발 공부를 하면서 실력을 키웠으니, 그 과정에서 모르면 생각 없이 바로 검색하거나 물어보기, 한 가지 방법으로 해답 찾기 등이 자연스레 내재될 수 밖에요. 그런 걸 생각하면 코딩 실력이 올라오는 속도는 느리더라도 옛날 방식으로 공부하는게 오히려 더 맞지 않나 하는 생각도 드네요.
좋은 의견이십니다. 전 좀 다르게 생각하는데요, 오히려 한국식으로 책/학원으로 공부를 하면 도와주는 사람이 없으면 그냥 아예 뭘 만들지를 못하고, 혼자서 계속 찾아 가면서 복붙이라도 하면서 만들어본 사람은 어떻게 해서든 답을 찾아서 해내는거 같아요. 직장에 처음 들어와서 주니어들이 실수 하는 것들은 사실 조금만 있으면 금방 고치는데 혼자 스스로 공부하는 습관이나 태도는 습득하는데 오랜 시간이 걸리는거 같아서 전 "옛날 방식" 이 개인적으로 비효율적인거 같아요
10년 넘게 it와 보안교육을 하는데 딜레마가 언제나 있습니다 "스스로 찾고 연구하고 설계하게 한다" (훈련형) => 장점 : 학생실력은 증대한다. 그리고 단계별 설계만 잘하면 모두 성공할 수 있다. 단점 : 체계적이지 않다고 느껴서 학생들 만족도가 떨어진다. 딜레마 : 집단강의를 하려면 훈련이 아닌 전달 패턴으로 해야하는데 대신 위에서 나오는 모든 단점이 다나옵니다. 상황판단, 위기대응, 커뮤니케이션은 모두 부족한데 학생은 모두 만족하고 학생모으기도 편함 단점 : 일을 잘 못하는 사람이 탄생함
1번은 확실한 내용이긴한데요.. 2, 3번은 한국 IT중소기업들이 기간자체를 버티지 못하고 주니어들을 힘들게 합니다.. 주니어들도 프로젝트 두세개 하다보면 느낌이란게 생기거든요 근데 항상 기간에 맞춰야 하니 시니어가 없는 주니어들은 맨땅에 해딩하기 바빠요.. 한국 중소기업에서 기간을 정할 수 있는 주니어들은 애초에 없을겁니다 그 기간을 위에서 정하고 통보하기만 할 뿐이죠.. 이걸 보신 개발자 희망자이시거나 이런 류의 중소기업 다니시는 분들은 어서 규모가 큰 중소기업이나 벤처/대 기업을 초반에는 들어가시길 추천드립니다 그래야 그나마 일찍 똥인지 밥인지 구별을 할 수 있게 됩니다..
워니님. 말씀이... 저는 주니어 인데 저희 회사는 워낙 작아서 시니어가 없어서 정말 3시간 이상도 찾아 돌아 다니고 docs 들도 다시 읽어 보고 난리 치고 고치는 경우가 많네요 ㅡ.ㅜ 그리고 개발 기간 잡는건 정말 ㅡ.ㅜ 하다보면 고구마 줄기 처럼 쭉쭉 딸려와서 들어 가는 시간들이 막 늘어나는데 시니어가 끌어 주지도 않고 이직을 해야 되나 고민 중입니다....
어쨌든 개발이라는게 이게 나라 언어 문화 불문이고 어느 정도 다 비슷한 부분이 있는거 같네요. 저도 영국에서 공부하고 한국에서 일하는 거지만 영국에서는 회사 경험이 거의 없어서, 다르지 않을까 생각을 했는데 워니님 말씀 들으니 이게 크게 다르지 않네요. 컴퓨터와 소통 하는 직종은 그거 자체로 비슷한 문화가 만들어지나 봅니다. ㅎㅎ
신입때가 생각나는 영상이네요 ㅎㅎ 사수가 무서운 분이어서 일 못끝낼거 같아도 말도 못하고 끙끙댔었는데.. 근데 먼저 맞는 매가 덜아프다고 안될거 같으면 바로 이야기 하는게 좋은거 같아요. 그럼 선배들이 커버칠 수 있는 여유가 생기기 때문에 조금 혼날거 안혼나고 크게 혼날거 덜 혼날수 있죠. 개발 기간 정하는건 연차가 쌓여도 어려운거 같아요 경험상 제일 좋은 방법은 문제를 쪼개서 생각하는 방법 같습니다. 현업에서는 M/H산정한다고 부르는데 설계에 몇주 개발에 몇주 테스트 디버깅은 몇주 잡고 거기서 더 쪼개서 무슨기능은 얼만큼 걸릴지 정하고 타임테이블을 만드는 거죠. 이게 익숙해지면 기능당 프로그램이 몇본이 될지까지 가늠해볼 수 있어요. 그러면 얼추 실제 개발공수랑 비슷해지고 일정을 맞출 수 있을지 없을지도 더 빨리 파악할 수 있어서 리스크를 줄일 수 있는거 같습니다
근데 구글링이나 스택오버플로우 너무 많이 쓰면 눈치 보인다는 이야기도 있는데... 근데 제가 얼마전에 면접 보러 간 회사도 큐비클안의 직원이 듀얼 모니터로 모디터 하나는 스택 오버플로우, 다른 모니터는 코딩 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 그거 보고 피식 ㅋㅋㅋ 페이스북 프로덕션 엔지니어도 우리 학교 아서 인포세션 하면서 "우리도 스택오버플로 쓴다" 이럼 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
![27년차 실리콘밸리 개발자의 인생 이야기 [한기용] 1부](http://i.ytimg.com/vi/nLL409se8sM/mqdefault.jpg)
개발기간 계산식이 뼈를 때립니다 ㅋㅋㅋㅋㅋ
ㅋㅋㅋ 그쳐?
개발팀의 규모가 작을수록 저 계산식이 더 정확한것 같네요... 제 선임 엔지니어는 티켓의 스토리 포인트 계산할때 "너 이거 하는데 얼마나 걸릴것 같아?"라고 물어보고는, 제가 답변하는 시간의 두배를 줍니다... 근데 그게 얼추 맞다는게 소름.
(음.. 이거 한 달 걸릴 것 같은데..? 그럼 단위를 바꾸고 X2를 해서...)
2년 정도 걸릴 것 같아요^^
ㅇㅈㅋㅋㅋㅋㅋㅋ
Wd-70 미친ㅋㅋㅋㅋㅋ
저도 신입 병아리 개발자이긴하지만.. 첫번째 문제를 학원에서부터 느낀 게, 코딩 잘 하는 사람들이 뭔가 막히자마자 강사님에게 물어보는 경우는 거의 없었던 것 같아요. 반면에 뭐 에러나고 실행 안 되고 할 때마다 강사님 불러서 물어보는 사람들은 처음엔 실력에 큰 차이가 없어보여도 몇개월 지나면 스스로 해결한 사람들과 실력이 어마어마하게 벌어져있더군요.
그리고 6시간씩 붙들고 해결하려고하는 건, 확실히 업무적 측면에서는 생산성 저하로 볼 수 있기 때문에 좋은 행동은 아니지만 공부할 때는 하루종일이라도 혼자 계속 찾아보고 해결해보는 게 되게 좋은 방법이라고 생각해요. 문제를 확실하게 해결하고 재발 방지까지 하기 위해선 이 에러가 '왜'발생한 것인지 명확히 알아야하기 때문에 결국 구조를 파고들게 되면서 자연스럽게 필수적인 개념들을 습득하게 되고, 문제 해결에 직접적으로 도움을 준 방법이 아니었을지라도 그 헤딩의 경험이 결국엔 나중에 도움이 될 때도 많더라구요..ㅎㅎ
첫번째 문제(주니어가 찾지 않고 바로 물어보는 경우나 너무 오랜시간 끙끙대는것)에 관련해서 말하자면, 주니어들은 계속 문제 해결능력을 키우도록 냅두는게 좋아 보입니다. 하지만 시간이 제한되어 있으니, daily progress report를 통해서 관리자가 현재 junior의 문제를 지적하고 guideline만 주는게 효율적인것 같습니다. 결국 나중에 senior레벨로 진입했을 때 program solving능력에 따라서 실력이 분간되는데, 주니어때 부터 깊게 연구하는 버릇을 들이지 않으면 이 능력이 배양되기 힘듭니다. 결국 회사를 이끌어가는것은 senior 레벨이라는 전제하에 junior에 대한 기대는 낮추고 인력양성 기간이라는 관점에서 접근하면 시간은 걸리더라도 좋은 인력을 양성할 수 있습니다.
결론은 주니어의 실수 횟수나 능력은 관리자나 팀의 계획 및 선견에 달려있다고 봅니다.
혼자 고민해보는 게 30분에서 1시간정도가 가장 적당한 시간이군욤....! 항상 너무 많이 고민하면 진이 빠져버리고 너무 쉽게 물어보면 성취감 없이 맥 빠지고 ㅋㅋㅋㅋㅋ 그랬는데... 덕분에 뭔가 깨닫고 갑니다 ㅎㅎ
추천영상에 떠서 보기 시작했는데 영상들이 다 도움이 되는 것 같아요.... 코딩도 잘해야하지만 요새 가끔 개발자가 가져야 할 마음가짐(?)같은거나 성찰해봐야 할 점들에 대해서 알고 싶었는데 그런 점에서 정말 도움이 되어요...!
도움이 된다니 저도 기뻐요!! ㅎㅎㅎ
바로 물어보는 시대적 상황이 큰거 같아요 옛날에는 정보 구하기 힘든 만큼 직접 해보면서 찾아보는게 습관화 되는게 일반적인데 이제는 찾으면 바로 나오니 해보는것보다 바로 찾아보는게 습관화 되어있고 그게 가장 빠른 방법이니 회사에서는 물어보는게 가장 빠른 방법이니 바로 물어보는 경향이 큰거 같아요
습관이 무섭네요
1번은 사실 사수도 어느정도 감성이 있는 분이라면 이게 알아볼대로 알아보고 묻는지
바로 다이렉트로 와서 질문하는 상황인지 눈치챌 수 있죠..
저는 10년 넘은 c 개발자 인데 당연히 어느정도 후배를 키우는것도 회사에서 선임자에게 돈을 더 많이주는 이유라고 보는데
질문을 할때 이렇게 봤고 저렇게 봤고 이걸 찾았는데 긴가민가하고 이건가 하는데 또 안된다 어떻게 해야할까요 이런 질문만 되도..
충분히 노력해 봤구나 하면서
답을 주긴 주되
그 노력에서 어느 방법이 추가되면 다음엔 스스로 해결 할 수 있구나 하게 만들어 줘야죠
진짜 세번째 너무 공감갑니다 ㅋㅋㅋ 그리고 첫번째는 신입이 좀 지나도 더 힘드네요. 혼자 구글링 하면서 찾다보면 1시간이 훌쩍 넘어가 있기도 하고... 참 ㅎㅎ 아직 많이 부족한가 봅니다.
개발기간은 우리나라 외주들의 문제이기도 하죠. 매니저로 비유한 게 발주자로 치환해서 말하면, 프로젝트 하나 따겠다고 무조건 지르고 봅니다. 근데, 막상 해보니깐 기간이 더 걸릴 것 같으니깐 이상한 변명만 늘어놓고 개발은 개발대로 안 되고 나중에 가면 될대로 되라는 식으로 나오고 있죠. 무슨 학부생도 아니고 나중에는 어디가 아프다 어디가 아프다 집 안에 무슨 일이 있다 등 온갖 변명이 난무합니다. 주변에서 하루 이틀 본 게 아닙니다. 물론 무조건 빨리 만들어준다고 하면 좋다고 업체 선정하는 발주자도 문제이지만, 책임질 수도 없는데 자신있다고 된다고 해서 프로젝트 떠맡는 사람들도 문제라고 봅니다. 공대 출신들은 특히 영업이나 말빨이 안 되다보니 저런 것도 잘 설명해서 오히려 신뢰를 얻고 기간을 더 길게 잡으면서도 금액은 금액대로 받을 수 있어야 되는데, 일단 지르고 보니 참 개발자나 맡긴 사람이나 골치 아픈 경험을 하게 됩니다. 그래도 오늘 해주신 말씀보니 참 도움이 많이 됩니다. 단위를 바꾸고 x2를 하라는 말씀은 진짜 뼈가 되고 살이 되는 말씀이네요. 좋은 영상 많이 찍어주셔서 감사합니다! 구독하고 좋아요 항상 박고 다녀요!
개발기간 재밌네요ㅋㅋ 저는 디자이넌데 디자인은 머리에 생각한 일정을 말하면 광고주(갑)가 그 일정에 나누기 2를 하라고 합니다...😂
😭
IT major 공부하고 있는 농인학생입니다. 앞으로도 계속 자막과 함께 유익한 영상 많이 많이 올려주세요!
와 개발기간 짧게 잡는거 공감한다 ㅋㅋㅋㅋ
자료가 있어도 검색어나 읽는 방법 자체를 모르는 사람이 많더라구요.. 질문을 하는 방법을 모르는 사람도 많고..
주니어 개발자들은 기본적으로 어느정도의 스킬을 가지고 입사하는지도 궁금하네요~
초기 입사 연봉이 10만달러 수준이라고 들었는데...한국개발자 기준이랑 비교해도 좋을거같아요 ㅋㅋ
맞아요 진짜 질문 잘 하는것도 스킬이에요 ㅠㅠㅠ
4달이나 기간을 주는 프로젝트가 얼마나 있을까 싶네요...
기획부터 개발에 서버세팅에 QA에 오픈까지 다 포함해서 3개월짜리로 풀야근하면서 일하고 하아....
좋은 회사 없나여 ㅋㅋ
Knife D 전 기획,개발,서버,디비 까지 해서 2달.. 첨에 4달로 제안했다가 대표가 뭐라하길래 겨우 잦고 시작했는데 결국 폭망.. 참고로 저 혼자 했었습니다
현재 미국에서 프론트엔드 개발자로 취업 준비중인 병아리 개발자입니다ㅎㅎ
진짜 꿀팁 정말정말 감사합니다!! 말씀하신 실수는 최대한 하지않도록 주의해야겠습니다
오 반가워요 데이빗님!! 다음 영상에서도 뵐 수 있기를 :)
ㅋㅋㅋㅋㅋㅋ 너무신기하게 예상기간 x2.5이면 항상되더라고요. 어느순간부턴간 머리속에서 2.5합니다.
이 분 너무 좋다
저도 가르치는 입장일 때 좀 막막한게 너 안물어보는 애들도 있고 너무 과하게 물어보는 애들도 있어서 그걸 어떤 적당한선으로 객관적으로 설명해주고 교육해줘야 할지가 항상 막막하더라구요.
비슷한 것 같아요.
신입에 가까운 개발자들이 오면 30분만 고민해보고 감이 안잡히면 길게 고민하지말고 물어보라고 말해줘요.
결과물 검수는 하기나름이라 항상 여유있게 잡으려고하지만 여건상 어려운 경우도 많은 것 같아요.
코딩을 완전 처음접하는 초보에게 도움되는 영상 정말 감사합니다 ㅠㅠ 감동했습니다. 킹워니 짱워니 갓갓워니
ㅋㅋㅋ 감사합니다
키워드를 찾냐 못찾냐 차이 입니다. 뭘 모르는지 아는게 중요하죠. 서핑 겁나게 하면 키워드 끝자락이 나타나긴 해요. 그걸 캐치하는게 능력 입니다. 그리고 세팅 같은거는 회사 내에 노하우로 전수해줘야 한다고 생각해요. 세팅할 때 쓰는 시간은 아깝지 않나요? 세팅 끙끙대면 뭘 배우는지 잘 모르겠는 1인..
ㅋㅋㅋ이 답글 완전 공감되네요. 개인적으로 개발환경, 서버환경 세팅하는 데 드는 시간이 제일 아깝지만 또 가장 기본이 되는거라서 스킵 할 수 없는 부분이죠...
공감합니다. 영상 잘 봤구요, 멘토링으로 주니어를 키우고 있는데 이 영상이 생각나서 다시 찾아와 봤습니다. 단위를 바꿔서 곱하기 2 공식은 조금 과하다는 느낌이 들기는 한데, 저도 제 경험이 비추어 곰곰히 생각해봐야겠습니다. 개인적으로는 곱하기 2를 합니다. 공수산정에 실패해서 피 본뒤부터는.
* 실수 요약
1. 고민없이 물어보는 행위
- 사내 문서(Usage), StackOverflow 등 참조
- 30분~1시간 고민 (적절한 밸런스)
2. 여러가지 개발방안 생각하지 않는 행위
- A,B,C 안 리서치 훈련
- A,B,C 안 설계하고 상사에게 보고하고 질의!
3. 자신을 과대평가
- 개발기간을 넉넉히(본인 생각 X2)
- Testing, 검증시간까지 포함
ㅎㅎ 20년차 개발자(개발이 재밌어서 , 아직도 코딩을 하는) 인데요, 지금까지 수많은 동료/상사/팀원등의 개발자를 겪어온 입장에서 완정 공감됩니다. 하나하나 모두 실제 개발현장에서 아주 흔하게 볼수 있는 유형 입니다. 단지 추가 하고 싶은 부분은 물론 주니어 개발자의 기준을 단지 경험 년수가 아닌 역량으로 판단할 경우라고 보이네요 ( 실제 신입이 아닌 경력이 많은 개발자도 말씀하신 3가지 실수를 무한 반복 하는 경우를 많이 봐서...)
3번째 너무 공감됩니다. 첫 프로젝트의 딱 저네요 ㅋㅋ
2번째. 다른 방법이 있다는걸 알아도, 주어진 개발기간 내에 다른걸 시도해볼 시간이 없어요. 최소한 구현은 해야하는데, 알아보다 구현도 못하면 최악의 상황이니까요.
1번째. 오래오래 끙끙대는 편이라 밸런스를 찾아야하는데, 구글링 첫페이지만 적용해도 어느샌가 시간이 너무 흘러 걱정입니다ㅜ
저도 첨엔 그랬어요 ㅋㅋ 하다보면 점점 더 성장하는거 같아요
하.. 내가 생각하는 개발 기간에서 길게 말하면, 윗 사람들은 줄이라고 쪼으고.. 타박하고.. 힘도 없는 개발자는 꾸역꾸역 기한을 맞추고.....
결론은 문제에 대한 리스크를
생각하느냐 아니냐가 중요한듯요~.
이건 개발 말고 연구나 다른 문제해결에도 어느정도 통용될 수 있는것 같아요.
좋은내용 잘 봤습니다 !
저는 컴공 나왔지만 개발 살려서 일하고있지 않습니다 ㅜ.
개발하시는분들 대단하시다고 생각해요.
느낀점이 많은 영상이였습니다... 얘기하시는 모든점들이 현재 제 문제점들이네요.... 빨리 고쳐야겠어요! 감사합니다 ㅠㅠ
저도 옛날에 이랬어요 ㅎㅎ 화이팅
말씀하신거에 공감하면서 저기에 다가 주니어 개발자들은 assumption을 만드는 경우가 많은거 같아요. 당연히 회사에 경력이 짧아서 시스템을 다 이해하기 힘들고 한데 "이거일거야"라는 느낌으로 criteria를 잘못 이해하고 개발을 시작하구요 만들고 나면 결국에 일을 다 다시 해야하는 상황이 간혹 오더라구요. 모르면 물어보는게 오히려 좋을때가 있어요
ㅎㅎ 제가 혼자 공부하면서 하다~하다(최소 6시간~1일이상 ㅎㅎ) 안되면 php스쿨에 물어봤는데, 사수가 있다는 것만도 정말 좋을것 같아요~^^
ㅎㅎ 맞아요 사수가 있는게 진짜 도움이 많이 돼요 막힐때 의지할 곳이 있으니
안녕하세요 ! 뉴욕에서 학교 졸업하고 프론엔드로 계속 어플라이하고 있는 중입니다. 올려놓으신 영상들 정말 더 와닿네요! 좋은 정보 정말 감사합니다!
화이팅입니다! Good luck :)
이건 주니어개발자 실수보다는 경험부족으로 일어나는 일 같네요. 경험부족이 죄는 아니니께...
Choi Patrick 저도 이거에 공감
그리고 개발기간 관련되서 실수하는 개발자의 공통된 심리는 본인이 하루에 24시간 일을 할 수 있다는 환상을 가지고 스스로 위한을 하기 때문에 마지막까지 말안하고 버티는 경우를 많이 봤네요.
솔직히 실수라기보다 , 경험이 없으니 발생할 수 있는 일들이라고 생각하네요. 저도 아래 후임 받아보니 나는 신입때 이런걸 생각해서 안물어보고 최대한 노력해보고 물어봤는데 , 너는 왜 이런 최소한의 노력을 안하고 바로 질문하냐 같은 생각을 많이했었구요. 근데 그사람 이 나의정답대로 안했을뿐 나름대로 고민했을 수도 있어요.
맞아요 :)
저는 회사에 저 혼자 개발자여서 모든 걸 혼자 해결 해야하는 상황입니다.
1. 문제가 발생하면 하루가 걸리든 이틀이 걸리든 최대한 찾아보고 고민해서 해결 해야해서 가끔 굉장히 비효율적일 때가 있는 것 같아요. 그렇지만 대부분의 문제를 직접 해결 한다는 부분에서 제 경험에 있어서 좋겠죠 :)
2. 무엇인가 만들어야할 때 시간을 많이 쓰더라도 DB나 프로젝트 구조 설계를 최대한 잘 해보려고 합니다. 어차피 혼자 관리 해야하기 때문에 이후에 유지보수를 최대한 적게할 수 있는 방향으로 하고, 코드도 무조건 짧게 보다는 직관적으로 알 수 있도록 관리하려고 하는 편입니당
3. 개발기간은 약간 의미가 없을 수도 있는 부분인데, 새로운 기능 추가하거나 변경할 때, 디자이너도 없어서 기획부터 디자인, 개발을 혼자 하다보니 빨리 할 수 있는한 빨리 하려고 하는 것 같네요.
저도 계속 혼자 하다보니 다른 분들이랑 같이 할 수 있는 뭔가 해보는 게 좋을 것 같은데, 혹시 좋은 팁이 있을까요~?
있어요! GitHub에서 별 300개 이상, 1000개 이하인 프로젝트 중에 승환님이 쓸만한거 하나 찾으셔서 버그 고치는걸로 시작해서 기능 추가까지 해보세요. 진짜 실력있는 개발자들이랑 일할 수 있는 기회가 될거에요
@@WonieSong 아 그런 방법이 있었군요 !
최근에 처음으로 별 4개 짜리 프로젝트 버그 고쳐서 contributor 돼 봤는데, 좀 더 큰 프로젝트에 도전을 해봐야겠습니다 :) 감사합니다~!
워니님 제가 아직 파이썬을 안해봤는데, 이번주에 공부해보려구요~ 좋은 콘텐츠 감사해요^^
수학좋아하는 사람이 해야댈듯....문제해결하는 과정자체를 좋아하는사람...난 아니다아...완전 다른계열사람 일하는거보니까 신기하네요. 저는 교육계열이라 말을 너무 많이해서 입이 마르는뎈ㅋㅋㅋㅋㅋ
전 말을 안해서 말라여 ㅠ
제가 게임개발자인데 초보자가 하는 실수는
일단 언어선택에 실수
다음으로 첨부터 그랙픽하는 사람이랑 둘이 같이 시작하는거 강추.
왜냐면 겜 다 만들어놓고 그래픽하는 사람이랑 같이 일할려면 돈문제가 모호해짐.
내가 죽어라 고생해 만들었는데 갑자기 누가 들어와 수익의 1대1로 나누자 하면 그게 머가 됨?
3대1 4대1... 그런것도 맞추기가 힘들고 올려고도 안함.
3번째가 겜을 욕심이 생기니 너무 거창하게 만듬.
그러다 만들다보면 이게 실제로 해보니 이거하나때문에 많은 문제가 발생하는걸 깨닫고 다 쳐냄.
그러다보면 시간만 낭비하는 꼴이 됨
스티브잡스 좋은 말씀 감사드립니다! 욕심이 생긴다는 말씀에 공감이 가네요 ㅎㅎ
딱 저네요 ㅋㅋㅋㅋ 저는 고3이고 이제 소프트웨어과를 가게 되었는데 이미 c언어를 배워서 막 제스스로 코딩을 하고 이걸 오류가 발생하면 길면 7일동안 끌고간 적이 있어서 ㅋㅋㅋ 엄청 시간을 소비해서 걱정이였는데 다음부터는 다른 프로그래머에게도 도움을 요청해야겠네요 ㅋㅋㅋㅋㅋㅋ
5년차 현직 개발자입니다.
선임개발자도 모든것을 알고있지는 않습니다. 단지 경험으로 해당 CASE를 검색하는거죠.
자신이 검색하고 찾으면 자신의 CASE를 하나 쌓아가는거죠.
개발자도 외과의사처럼 CASE BY CASE로 성장한다고생각합니다. 나중에는 그게 중요한 자산이 될겁니다.
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ개발기간 완전 공감이에요
개발자들은 다 똑같은건가요 ㅠㅠㅠ
ㅋㅋㅋㅋㅋㅋㅋㅋㅋ
저는 개발자?라고도 하기 애매하네요. 컴퓨터비전으로 석사하고 현재는 제조업 머신비전 엔지니어로 1년 4개월째 근무하고 있습니다. 스타트업에다 회사에 소프트웨어 담당하는 사람 수 자체가 적다보니 코드베이스가 좀 많이 부족한 상황에서 같이 만들어가는 입장이라 주니어인데도 불구하고 혼자 삽질하는 시간이 굉장히 많은 편입니다. 말씀하신 2배 전략?같은 걸 기간에 산정해서 넣으면 윗선에선 줄이라하고.... ㅎㅎ...... 사용하는 하드웨어에 대해서도 항상 바뀔때마다 다른 코드를 작성해야하는지라 구글링해도 안나오는게 대부분... 그래서 지금 남아계시는 단 한명의 사수분에게 물어보면 코드보라는 말로 어느정도 돌아오는데 그 코드볼 시간이면 강제로 줄여진 시간에 맞추기는 참......... 저짓거리하다 출장 세달반 다녀오고 하니 건강은 더 나빠지고 하니 '삽질하는 시간도 안주고 개고생하는데 이 돈 받으면서까지 남아있어야 돼나?'라는 생각에 자괴감만 드는군요.
말하신 부분에 많은 공감을 하게되네요
물어보기만 하는거 나쁜 습관이고 고쳐야 하는 부분인데 많은 주니어분들이 그러시죠 보통..
감사합니다 ㅎㅎ
^^ 이걸 지금이 아닌 초보 때 볼 수 있었으면 얼마나 좋았을까요 ^^
sangdo computer ㅎㅎㅎ 저도 이랬으니까요 ㅠㅠ 누가 말해주지
세번째 시니어 개발자는 너무 길게 잡는다
솔직히 개발기간 측정이 어렵다
10년차도 개발기간 계산하기가 어렵다
주니어는 일주일이나 2~3일정도 검토기간을 줘서 기간 산출하게끔 해줘야한다
시니어도 안해본거 개발하려고 하면 기간 산출하기가 어렵다
그렇죠 ㅠㅠ 개발기간 잡는게 원래 엄청 어려운거 같아요
첫번째는 예의 정도의 선에서 생각할수 있구요.... 왜냐하면 조금 찾아보고 나서 여쭙고 다녀야 설명을 이해하고 어디까지 찾아봤는데 여기서 문제인것같다고 최대한 정보제공을 해야 선임도 어느선으로 설명을 해야하는지 대략 감이 오거든요.
둘째는 주니어로서는 제일 어려운문제라고 생각합니다. 주니어 입장인 저는 기본적으로 불가능은 없다는 전제하에 찾기때문에 a b 정도는 방법을 알고, c 는 가능할것같고 d 라는 방법이 있는지도 모를때가 많더군요....
이것은 경험이 계속 누적되야 개선될것 같구요,
세번째 워킹데이 산정은 주니어에겐 불가능하다고 생각됩니다. 이유가 딱히 설명 안할정도로 당연하다고 생각되구요, 29년차 개발자이신 분이 설명하신 바에 따르면 요구사항 분석에서부터 기획, 일정잡는 부분, 이에 대한 시니어급의 판단이 어느정도 있어야 착수할수 있기때문이라고 하시네요.
정말 많이 공감가는 내용이네요. 경각심을 가지겠습니다.
SaeGeoul Jang 화이팅입니다! 개발자이신가봐요
@@WonieSong 인디게임 분야에서 노력하고있습니다. 아직 사람들과의 협업경험은 별로 없지만 내용 들어보고 공감이 많이 갔습니다. 실력에 자만하지 않고 정진하는것이 중요하다고 생각합니다.
저.... 썸네일 보고 딕헌터 님이 개발까지 하는줄 알고 들어왔네요... 너무 닮으셨어요.
zㅋㅋㅋ
이건 다른 연구개발분야에도 해당되는 얘기인 것 같군요...극 공감...
신기하네요!
큰 회사나 주류 언어를 사용하는 회사는 그렇겠지요
주니어 개발자들을 탓할게 아니라 시니어 개발자들이 자기도 겪은일인데 주니어 개발자들이 빨리따라올수 있도록 제대로된 문서하나 안남기는게 문제라고 봅니다.
그런거 하나 제대로 남겨왔다면 이 분야가 더 빨리발전해왔을텐데요
4년차가 주니어 개발자에게 주는 조언이라.. 참.. 도움이 되지만 한편으로 시니어개발자들에겐 반성해야 할 주제입니다
좋은 말씀 감사합니다 :)
시니어가 왜 반성해야함? 시니어가 신입들 교육하라고 뽑은 사람도 아니고 말이죠. 시니어도 자기들 일할려고 머리 엄청 굴리고 있는데 신입들이 와서 정성도 없는질문하면 빡칩니까 안칩니까?
입사 3주차 프론트개발자입니다
1번 3번 뼈맞았네용ㅎ
좋은영상감사합니다 :)
장재영 와 신입이시네요? 화이팅!
저도 비전공자이고 국비지원 나왔는데 진짜 배이스가 되는 기초지식은 할 수 있는한 최대한 익히고 들어가야지 맞다고 생각함 그게아니면 야근해서라도 공부해야지 그런 마음가짐이 아니고서야 무슨 전공자랑 맞먹겠다고 자랑이랍시고 당연히 가르쳐줘야한다는 신입들 마인드보면 좀 웃음이 나온다ㅋㅋ 근데 전공자도 전공자 같지 않은 사람들 많은게 문제긴한데 객관적으로는 신입쪽은 비전공자랑 전공자랑 차이를 못느끼겠음 누가 더 열심히 요령껏 잘하느냐는 타고난것도 좀 있고 최소한 저는 사수에게 질문하기전에 구글에서 이렇게 검색해봤고 테스트서버에 적용시켜보니 여기서 문제가 나던데 이건 검색을 해도 나오는 자료가 없다는 식으로 대부분 물어보지 덮어놓고 전부 가르쳐달라는 짓은 절대 안함 그게 예의가 아니기도하고
좋은 강의 잘 듣고 있습니다.ㅎㅎ 다음에 CSS도 코딩하는 영상을 빨리 보고 싶네요.. ^^
회사 홈페이지가 엄청 괴랄해서 포럼을 찾아가기 어렵다던가 혹은 주니어에게 그런 내용이 전달되지 않는 경우가 있어서 괴로울 때가 있습니다
너무 공감합니다. 그래서 포기했는데 다시 시작해야겠네요
저는 프로그래밍 관심을 갖고 있고 ,
현재는 plc프로그래밍을 하는 사람인데 공감가는 부분이 많네요.
재밋게 잘 보았습니다.
워니님 유튜브보고 저도 프로그램 짜보고 싶네요.
잘부탁드리겠습니다.
함께 해요! 저도 잘 부탁드립니다.
현제 미국 스타트업에서 일하고 있는 초보 프론트 엔드 개발자 입니다.
1~3 다 뼈 때리네요 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ
Thank you UA-cam recommendation :D
구독 박고 갑니다.
내용이 재미나네요.
공장에서 개발하는 우리랑은 다른세계라서.
초심자는 자신이 처음 예상한 개발기간의 2배가 걸린다고 생각하면 됨. 최소 2배 이상의 시간이 걸릴 것이라고 생각하면 되는데, 영상에서 나왔듯이 자신이 모르는 공정이나 출시까지의 여러가지 단계가 많을 수 있고 이에 따른 업무가 반복되며, 프리렌서 또는 아주 작은 회사라면 클라이언트의 변덕, 규모 있는 회사라면 다른 부서의 여러가지 사정 등 별의 별 상황이 발생하는데, 그러한 변수에 따른 자신의 일정 조정이 쉽지 않음. 애초에 넉넉히 정했으면 그 기간동안 상황 변화에 따라 여유롭게 대응해나가면 되는데, 클라이언트 또는 다른 부서는 그 처음 정한 일정을 가지고 다시 계획을 잡으니, 자신만 힘들어짐.
가끔씩 프리랜서 형식으로 웹 개발 일을 하곤 하는데, 클라이언트가 두달 정도 걸릴 만한 일을 맡기면서 급하다고 한달 만에 끝낼 수 있냐?라고 물어보면 한달은 고사하고 최소 2달은 걸릴 것이고 분명히 이 일은 3달에서 4달은 걸릴거다라고 답함. 그러면 급한 상황인데 이런 이런 기능만 있으면 된다라고 하면서 2달이면 확실히 되냐라고 되묻는데, 아니다 보아하니 분명히 3~4달 후에나 프로젝트가 완료될 거다. 지금 원하는 것만 하면 2달안에 할 자신이 있다 그런데, 100% 중간 중간에 또 다른 기능이나 변경사항을 요구할 거다. 그래서 마음에 드는 결과물이 나오는데까지 4개월은 족히 지나가있을 거다. 여지껏 경험상 그 누구도 예외가 없었다라고 대답하고 4개월까지 걸릴 수 있는 일임을 명확히 하고 일을 시작함. 2개월을 계약해놓고 중간중간 변동사항과 일정 가지고 실랑이 하는 것은 보통 곤욕스러운 것이 아니고, 애초에 여유있게 잡아야 마음도 안 급하고 여러가지 좋은 방법을 고민하고 찾아가면서 완성도를 높일 수 있음. 물론 회사라면 개발자 자신이 일정을 잡는 게 아니고 주어진대로 맞춰가야 하니 상황은 좀 다름.
앜ㅋㅋ 뭔가 주니어개발자들 행동 공감가네요 ㅋㅋ 제가 아직 대학생이라서 코딩작업을 하드하게 하는 것은 아니지만... 기말 프로젝트나 중간 프로젝트할 때, 어떻게 해야할지 몰라서 이틀 동안 문제 해결할려고 부여잡고 교수님께 여쭤봐도 직접 찾으라고 얘기하셔서 ㄹㅇ 죽을 맛이었던 적이 기억나네욬ㅋㅋㅋㅋ
그리고 개발기간은 정말로 많이 도움됐습니다. 저도 제 실력 과신하지 않고 단위 바꾸고 2배로해서 시험해봐야겠어요 ㅋㅋㅋ
ㅎㅎㅎ 다 똑같나봐요
인스타 친추 주셔서 보게되었는데, 저두 4년차.. ㅋㅋㅋ 공감되서 웃었네요 ㅋㅋ
이야기 잘듣고있어요. 앞으로도 부탁드려요^^
저도 잘 부탁드립니다!
제가 생각하기에는 말씀하신 부분들은 회사 내 신입사원을 위한 매뉴얼로 시행착오를 해결 할 수 있는 부분인데 대부분의 회사들이 개발 업무 매뉴얼이 부족한거 같아요. 한국에서는 특히 개발업무 신입교육과 업무매뉴얼이 제조업과 마찬가지로 기술직임에도 체계적이지 않더라고요. 대표가 잘 모르다보니 아예 맡겨버리거나 사수가 꼰대라서 신입에게 잔소리만 하고 제대로 안알려주는 경우도 많고요. 사람관리와 교육도 회사 역량이 필요한 부분인데 그걸 개인의 책임으로 넘기려는 느낌이 강한 것 같아요.
그렇게 생각할수도 있는데 식당 가면 포크랑 나이프 사용법을 처음부터 가르쳐 주지 않고 당연히 알거라고 생각하는거처럼 테크 기반 회사는 이런것들을 개발자의 기본 소양이라고 생각하는거 같아요
@@WonieSong 네 맞아요. 저는 정돈이 부족한 상태에서 속도와 성장을 동시에 추구하는 모습이 아이티 업계의 강점이자 약점이라고 생각해요. '기본', '상식' 같은 말들은 집단과 상황, 맥락에 따라 달라지는 말들이거든요. 초기 시행착오를 매뉴얼화 해서 교육시키는 것은 회사 사내 교육만의 역량은 아니라고 생각하고요. 학교 교육과의 연계나 실무교육과정에서도 함께 필요한 부분이라고 생각합니다. 답변해주셔서 감사합니다.
드라마 미생 보면 이런거 나오는데 ㅋㅋ
근데 상급자도 느낌 알잖아요! 고민하다 질문을
한건지,질문에 기본예의도 모르는 신입인지 ㅎ
근데 한국에는 적성도 안맞는데 주먹구구식으로 취업해서 시간만 때우다가는 식으로 취업하신 분들도 많을거에요.ㅠ
경험이 없어서 하는 이야기네요....^^ 개발일하면서 시간이 지나면 달라질것들... 많이들 도와줍시다..ㅎㅎ
그럴지도 몰라요!
경험상 그냥 빨리 물어보고 빨리 답해주는게 결과적으로 더 좋았습니다 ㅋ
코드베이스같은것도 일단 큰회사 가야 있지 소위 말하는 헬중소기업 이런데가면 아무것도없음 실력늘릴수가없음 ㄹㅇ
난 개발기간 계산식을 짤때
기능하나하나 나열한 뒤
개발 최소단위를 1일로 잡고 하나하나 더하면 별거없어도 2달은 나오던데
이게 좋은거같으요..
개발 기간 측정이 너무 공감되서 터졌네요 ㅋㅋㅋㅋㅋ
하 전 지금도 기간 잘 잡는게 너무 어려워요
다 정말 공감해요,,첫번째 문제는 여러 교육을 진행하다보니까 시간 제한을 주는게 좋더라구요. 제가 생각할때 30분이면 할수 있는 일이면, 최대 2시간을 주고 1시간이 경과해도 피드백이 안오면 중간 점검을 해서 플로우를 정리해주면 웬만해서 제한시간안에 해결하시더라구요. 만약 해결 못했으면 제가 하는 방식을 알려주고 다른 방법으로 할수있는 블로그 글을 소개하는 편이예요. 막연하게 미션을 주면 너무 많은 정보를 찾아봐서 그런지ㅋㅋㅋ오히려 더 어렵게(?) 느끼는 것 같아요
오 색다른 방법이네요? 혹시 그렇게 하면 사수가 시간을 비의식적으로 계속 신경 쓰고 있는 점에서 힘든 부분은 없으셨나요? 멘티가 한 명일땐 문제 없을 것 같은데 10명이면 정신이 아득할 것 같은데.. ㅠㅠ
@@WonieSong 사실 계속 신경쓰이고 제 작업시간이 부족해지긴 하지만 확실히 초반에 집중해서 교육하면 저랑 업무스타일도 비슷해지고 막히는 부분들을 듣다보면 저도 새로운 관점이 생겨서 힘들기도 하지만 좋은 점도 있는 것 같아요! 저는 많아봤자 멘티가 2명이었는데, 그 이상되면 트리형으로 관리를 해요ㅋㅋㅋ조금이라도 먼저 들어온 멘티한테 배운거 그대로 시키고 코드리뷰하면 뭐가 부족한지, 교육이 잘되고 있는지 확인이 되는 것 같아요.
오 넘나 좋은 방법 같아용
한국에서 스타트업 4년차인데 완전 공감합니다^^
맥북에서 스프링 개발환경 설정하다. 도커에 탑재된 데이터베이스와 연동이 안되서 하루정도 삽질하다보니 찾은 사실... 맥북의 시간 동기화가 안맞았던...
맥북 언어 및 지역에서 해외로 지역을 설정한뒤 다시 대한민국으로 바꾸니 데이터베이스 연동이 잘되던.... ㅠㅠ
mac os 업글할 때마다 그렇죠...
ㅎㅎㅎ 개발할때 우리 모두 삽질의 연속..
와..😢
지금 주니어 대리고 일하는데 개빡칩니다 제가 지금 9년차인데 디버그도 제대로 안하고 서버탓만 하고 서버가 이상하니 니가 고치세요 시전하고 제가 1분만에 코드 문제라고 풀어내면 띠용!! 이러고 있고 인프라 aws로 바꿔놨더니 니가 바꿔놓고 왜 배우라고 하느냐 이런 늬앙스나 지껄이고 개발 트렌드 맞춰서 가이드 주고 모든 레퍼런스를 다 주는대도 모른척 합니다 ㅋㅋㅋ
전 현재 인프라 웹개발까지 다 하고 있습니다 ㅠㅠ
네 저도 얼마전 이틀이면 끝낼거라고 생각햇던 스몰 프로젝트가 결국 한달이 걸렸습니닼ㅋㅋㅋ
개발자는 아직 아니지만 왠지 내 얘기
같네요 ㅋㅋㅋ
다른 영상 보고 이 영상보면서 느꼈던 건, 요새 프로그래머들은 (워니님도 강조하셨던) 조각화 방식으로 공부를 하니 주니어 때 1번, 2번 같은 실수를 하는게 당연하다고 봅니다. 다른 걸 베끼고 그대로 복붙하는 방식으로 개발 공부를 하면서 실력을 키웠으니, 그 과정에서 모르면 생각 없이 바로 검색하거나 물어보기, 한 가지 방법으로 해답 찾기 등이 자연스레 내재될 수 밖에요. 그런 걸 생각하면 코딩 실력이 올라오는 속도는 느리더라도 옛날 방식으로 공부하는게 오히려 더 맞지 않나 하는 생각도 드네요.
좋은 의견이십니다. 전 좀 다르게 생각하는데요, 오히려 한국식으로 책/학원으로 공부를 하면 도와주는 사람이 없으면 그냥 아예 뭘 만들지를 못하고, 혼자서 계속 찾아 가면서 복붙이라도 하면서 만들어본 사람은 어떻게 해서든 답을 찾아서 해내는거 같아요. 직장에 처음 들어와서 주니어들이 실수 하는 것들은 사실 조금만 있으면 금방 고치는데 혼자 스스로 공부하는 습관이나 태도는 습득하는데 오랜 시간이 걸리는거 같아서 전 "옛날 방식" 이 개인적으로 비효율적인거 같아요
@@WonieSong 좋은 답변 고맙습니다. 말씀하신 것 또한 충분히 많이 일어나는 일이긴 하죠. 어려운 문제네요...
사실 케이스 바이 케이스겠죠? ㅎㅎ
이제 개인 포트폴리오 준비해서 이력서 뿌리는데..학원에서 팀프로젝트 준비했을때 이거 혼자서 빡세게하면 두달이면 되겠는데? 아냐 두달이머야 한달이면 될거같은데..했는데 총 6개월 걸렸네요..ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ공부하겠습니다..
nova?
개발기간 산정할때 단위 바꾸고 곱하기 2 ㅎㅎ
개발자까지는 아니고 데이터 분석하는 입장인데 공감 많이 되네요 ㅠㅠ 특히나 찾아보면 나오는데 그걸 찾아내는게 실력인 것 같더라구요 다같이 열심히 공부합시다 죽는날까지 ㅎㅎ
DS KIL 데이터쪽도 비슷하군요 ㅋㅋㅋ
막상 하다보면 50분 쯤 고민 했는데 해결한 듯 하다가 안되고 그래서 늘 1.5시간정도 끙끙 앓게되더라고요
10년 넘게 it와 보안교육을 하는데 딜레마가 언제나 있습니다 "스스로 찾고 연구하고 설계하게 한다" (훈련형) => 장점 : 학생실력은 증대한다. 그리고 단계별 설계만 잘하면 모두 성공할 수 있다. 단점 : 체계적이지 않다고 느껴서 학생들 만족도가 떨어진다.
딜레마 : 집단강의를 하려면 훈련이 아닌 전달 패턴으로 해야하는데 대신 위에서 나오는 모든 단점이 다나옵니다. 상황판단, 위기대응, 커뮤니케이션은 모두 부족한데 학생은 모두 만족하고 학생모으기도 편함 단점 : 일을 잘 못하는 사람이 탄생함
개발기간은 보통 pm이 정해버리는 경우가 많은거 같아요. 이번 프로젝트도 넉넉히 두달 불렀더니 바로 한달로 기간 단축시키더라구요ㅠㅜ
그럼 다음엔 그걸 감안해서 한 4달 부르시면 안되나요?!
사람마다 다르긴해도 본인이 생각한 시간보다 길면 어떤 핑계를 대더라도 그거에 맞추는 분들이 있어요 ㅋㅋ 그럴거면 왜 일정 산정하라고 하는지..
그러게 말입니다 ㅠㅠ
1번은 확실한 내용이긴한데요..
2, 3번은 한국 IT중소기업들이 기간자체를 버티지 못하고 주니어들을 힘들게 합니다..
주니어들도 프로젝트 두세개 하다보면 느낌이란게 생기거든요
근데 항상 기간에 맞춰야 하니 시니어가 없는 주니어들은 맨땅에 해딩하기 바빠요..
한국 중소기업에서 기간을 정할 수 있는 주니어들은 애초에 없을겁니다
그 기간을 위에서 정하고 통보하기만 할 뿐이죠..
이걸 보신 개발자 희망자이시거나 이런 류의 중소기업 다니시는 분들은
어서 규모가 큰 중소기업이나 벤처/대 기업을 초반에는 들어가시길 추천드립니다
그래야 그나마 일찍 똥인지 밥인지 구별을 할 수 있게 됩니다..
좋은 말씀 감사드립니다.
시간이 걸리더라도 찾아봐야 제것이 되죠
워니님. 말씀이... 저는 주니어 인데 저희 회사는 워낙 작아서 시니어가 없어서 정말 3시간 이상도 찾아 돌아 다니고 docs 들도 다시 읽어 보고 난리 치고 고치는 경우가 많네요 ㅡ.ㅜ 그리고 개발 기간 잡는건 정말 ㅡ.ㅜ 하다보면 고구마 줄기 처럼 쭉쭉 딸려와서 들어 가는 시간들이 막 늘어나는데 시니어가 끌어 주지도 않고 이직을 해야 되나 고민 중입니다....
어쨌든 개발이라는게 이게 나라 언어 문화 불문이고 어느 정도 다 비슷한 부분이 있는거 같네요. 저도 영국에서 공부하고 한국에서 일하는 거지만 영국에서는 회사 경험이 거의 없어서, 다르지 않을까 생각을 했는데 워니님 말씀 들으니 이게 크게 다르지 않네요. 컴퓨터와 소통 하는 직종은 그거 자체로 비슷한 문화가 만들어지나 봅니다. ㅎㅎ
좋은 영상 늘 감사합니다.
프로그램셋팅 이것저것 물어보는거....ㅋㅋㅋㅋㅋㅋ 어제 그렇게했는뎈ㅋㅋㅋㅋㅠㅠㅠ
차라리 PM이랑 합의를 봐서 어떤 스타일인지 잡아놓는게 중요하다봅니다
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 개발 스코프ㅋㅋㅋㅋㅋㅋ 정말 얼추 맞는 거 같습니다.
ㅋㅋㅋㅋ 맞아영
게임개발기간을 6개월로 잡았는데 그럼 12년 걸린다는 건가요ㅋㅋㅋㅋㅋ
네 ㅋㅋㅋㅋㅋㅋ
맞데 ㅋㅋㅋ ㅋㅋㅋㅋ
터지고 갑니다ㅋㅋㅋㄱ
이건 개발자가 아니라 일반 회사에서 프로젝트 할 때도 해당되는 말이네요 ㅎㅎ
목소리너무좋아요 틀어놓기좋음
정말 공감 많이 되네요..ㅠㅠ
결론
0:53
4:23
6:21
10:32
개발기간 공식
자기가 생각한 기간의 단위를 up하고 두 배를 하라.
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
신입때가 생각나는 영상이네요 ㅎㅎ 사수가 무서운 분이어서 일 못끝낼거 같아도 말도 못하고 끙끙댔었는데.. 근데 먼저 맞는 매가 덜아프다고 안될거 같으면 바로 이야기 하는게 좋은거 같아요. 그럼 선배들이 커버칠 수 있는 여유가 생기기 때문에 조금 혼날거 안혼나고 크게 혼날거 덜 혼날수 있죠. 개발 기간 정하는건 연차가 쌓여도 어려운거 같아요 경험상 제일 좋은 방법은 문제를 쪼개서 생각하는 방법 같습니다. 현업에서는 M/H산정한다고 부르는데 설계에 몇주 개발에 몇주 테스트 디버깅은 몇주 잡고 거기서 더 쪼개서 무슨기능은 얼만큼 걸릴지 정하고 타임테이블을 만드는 거죠. 이게 익숙해지면 기능당 프로그램이 몇본이 될지까지 가늠해볼 수 있어요. 그러면 얼추 실제 개발공수랑 비슷해지고 일정을 맞출 수 있을지 없을지도 더 빨리 파악할 수 있어서 리스크를 줄일 수 있는거 같습니다
근데 구글링이나 스택오버플로우 너무 많이 쓰면 눈치 보인다는 이야기도 있는데... 근데 제가 얼마전에 면접 보러 간 회사도 큐비클안의 직원이 듀얼 모니터로 모디터 하나는 스택 오버플로우, 다른 모니터는 코딩 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 그거 보고 피식 ㅋㅋㅋ 페이스북 프로덕션 엔지니어도 우리 학교 아서 인포세션 하면서 "우리도 스택오버플로 쓴다" 이럼 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
그래서 테디코드나 고구마S카페에서도
주니어들이 질문하면 혼자 해결해보고
물어보는거냐고 묻는거구나..
역시 시니어개발자들은ㄷㄷ
ㅎㅎ 네 먼저 찾아보는게 중요한거 같아요
abcd는 공감 공감 바쁘다보면 생각을못할때두..ㅜ
맞아요 ㅎㅎ
저는 처음에 사수가 stack overflow how to ask 이거 읽고 요약해서 자기한테 설명하라고 하드라고요
엄청 좋은 사수를 두셨네요 ㅎㅎㅎ
@@WonieSong stack overflow how to ask 이게 뭐져?
저도 궁금합니다!
stack overflow 들어가보셔서 질문하는 방법 찾아보세요.
stackoverflow.com/help/how-to-ask 여기있네여 stack overflow가 사이트 이름인줄 몰랐음
미국에서 마지막학기 앞두고 취업준비중 입니다 :) 영상 너무 잘보고 있어요~~!
하트 눌러주셔서 돌아왓는데, 지금은 시애틀에서 잘 취직해서 열심히 일하고 잇습니다~~ㅎㅎㅎ 언젠간 뵐 기회가 있었으면 좋겠네요!
그리고 직장내 괴롭힘 금지가 시행되면서 못한다고 뭐라 하는것도 어쩌구 저쩌구 하는 거 보면 열받아서 얘기하는 거 포기했습니다 ㅋㅋㅋ