수업 질의응답

• 최종 성적 및 평가 항목별 점수는 인포21에서 확인함

[문제 1]  

첫번째 기사의 핵심 키워드가 관리자와 직원인 부분에 집중함

Project Management에서 본 것 처럼, 대형 과제는 어쩔수 없이 일단 Waterfall을 도입하는 경우가 많음. 혹은 별도의 개발 관리를 전담하는 조직에서, 개발 조직을 관리하고자 하는 경우가 많음. 따라서 개발팀 차원에서 Scrum 등으로 운영되는 경우 관리자(혹은 관리 조직)의 관리 애로는 필수 불가결함. Waterfall 방식의 과제가 아니더라도 기사의 맥락 상 Face-to-Face(대면)의 관리를 희망하는 관리자들의 입장이 커 보인다는 것을 파악할 수 있음

두번째 기사도 유사하게 “개발 일정과 제작 공정”에 대한 문제를 이야기 하여 관리의 애로를 이야기함. 따라서 첫번째와 두번째 기사는 준비없이 코로나로 급박하게 시작한 원격 근무가,

소프트웨어 개발 프로젝트 관리 측면에서 어려움이 있던 것을 보여주는 기사들로 이해할 수 있음. 근본적인 해결책은 Waterfall 방식 혹은 Face-to-Face로 운영되는 대형 과제가 원격 개발에 맞춰서 조정될 필요가 있음. 단기적으로는 첫번째 기사 중 데이터와 정보에 엑세스하는 데 어려움이 있다는 등의 부분은 직원의 경우도 애로를 표현하기에, 개발팀 차원의 Scrum 데이타 등을 관리자 들도 확인 하도록 시스템적인 개편을 수행하는 등의 노력은 필요함.

결국 코로나 이후의 하이브리드 업무 방식에서는 이런 개선 사항이 반영된 새로운 원격 근무 체제가 나타날 것으로 예상함. 위와 같이 수업 내용에서 나타난 고유명사들과 본인의 생각을 논리적으로 기술하는 것을 기준으로 평가함. 이외에 소통의 부재, Digital-Nomand, Co-work 협업 툴 등으로 답한 경우는 내용의 깊이와 량에 따라 부분 점수를 부여함

추가로, 채점시 느낀 것으로, 개발직이 아닌 경우에 대해서, 무조건적으로 나이가 많다, 소프트웨어 사용에 둔하다, 새로운 것을 두려워 한다, 개발에 대해서 일체 모른다는 등의 편견 혹은 일반화의 오류를 갖지 않도록 함

[문제 2]

시험 범위 기준, 주어진 환경에서 가장 효율적으로 고려할 수 있는 방법은 TDD와 Re-factoring 준비임

TDD 관련, 동료가 진행자 역할을 하고 있으므로, 본인은 동료의 코드를 시험할 test code를 미리 개발하여,

향후 동료의 skeleton 코드를 실험할 체계를 마련하여 개발 시간 단축을 도모할 수 있음

주어진 환경이, 백지 상태에서 코드를 개발하는 부분을 감안한다면,

미리 회사 내부의 기존 code repository 검색 혹은 선배에 대한 조언을 구하는 과정에서 효율적인 설계 구조를 고민할 수 있음

따라서 동료가 고민하여 결정한 설계 구조와 본인이 미리 대비한 설계 구조를 상호 비교하고 토론할 준비를 할 수 있음

특히 Agile의 개발 과정에서 Re-factoring 단계는 반드시 거쳐야 할 단계기도 하니, 

일단 skeleton 개발로 몰입할 동료를 대신하여 보다 효율적인 설계안을 찾아볼 수 있음

추가로 활용 가능한 오픈소스 소프트웨어에 대한 서베이도 가능하나, 이는 개발전 진행할 사항일 수 있음

단, 상기 과정도 Pair Programming 안에서 동시에 동료와 함께 진행할 수 있음

추가로, 채점시 느낀 것으로, 코딩 가이드라인은 모든 사내 개발자가 지켜야 하는 ‘기본 소양’ 임. 파트너 개발자가 생산적인 소프트웨어 개발 활동을 하는 시점에, 그 옆에서 코딩 가이드라인을 공부하거나 정한다는 것은 기본이 되지 않은 것으로 볼 수 있음. 그리고 TTD가 아니고 TDD 이며, 꽤 여럿 학생이 잘못 적었으니, 추후 면접/인터뷰 등에서 틀리지 말것

[문제 3]

실제로 박사 학위를 받고 회사에 입사한 교수님도 겪었고, 여러 회사/조직에서 이루어지는 사례임

다음의 사항들이 고려대상이 될 수 있음

. 주기적인 보고와 의견 수렴 : 수업 내용 중 Agile/Scrum의 인간 상호관계 및 정기 미팅. 굳이 Scrum을 언급 하지 않아도, 내가 문제를 제대로 이해하고 있는지, 맞는 방향으로 가고 있는지에 대한 확인, 그리고 상급자가 나의 작업 상태를 이해하고 있는지는 매우 중요함. 따라서 정기적인 보고와 상급자로부터의 확인 및 의견 수렴이 필요함

. 같은 부서 선배/동료와의 토론과 의견 수렴 : 수업 내용 중 Agile. 결국 사람들과의 관계에 문제가 없다는 것을 보여야 하며, 추가적으로 이미 회사에 입사한 선배들에게 의견을 들음으로써, 이미 존재하는 기존 해법의 조기 습득, 본인이 제시한 방안에 대한 개선 아이디어 확인 등 소프트웨어 결과물을 질과 개발 시간을 줄이는 효과를 기대함

. 과거 회사내 유사 개발 사례 확인 및 재활용 : 수업 내용 중 Software Maintenance 및 Design Pattern. 대부분의 회사는 신입이 백지부터 코드를 만드는 것에 부담감을 가짐. 아울러 회사는 고유의 coding guideline이 있는데, 신입이 이를 완벽하게 지킬지 여부도 불투명함. 따라서 기존에 유사한 문제에 대한 코드가 회사내 repository에 있는지를 확인하고, 이를 재활용하는 것은 관리자를 안심시키고 개발 기간을 줄이는 방법임

. 회사 공인 소프트웨어 개발 도구 및 프로세스 활용 : 수업 내용 전체에 걸친, 단계별 개발 도구와 방법론 등을 확인하고, 이를 준수(활용)하면서 개발함으로서, 독단적인 개발 환경 구축과 운영을 하지 않고, 협업이 가능한 인재라는 모습을 어필함

. 오픈소스 소프트웨어 확인 및 활용 : 수업 내용 중 오픈소스와 Project Management. 회사내 repository와 함께 개발 기간을 단축하고 (검증된 오픈소스의 경우) 코드의 신뢰성을 확보하는 좋은 방법임. 특히 회사에서 공인하여 전체적으로 사용하는 오픈소스 소프트웨어들을 확인한다면, 결과물로 내놓을 소프트웨어에 대한 신뢰도를 더 높히는 계기가 될 것임

. TDD/Profiling 등 시스템적인 실험 및 성능 측정 : 수업 내용 중 Test and Enhancement와 Design Pattern. 누구나 돌아가는 소프트웨어를 만들지만, 안정적이고 고성능으로 돌아가는 소프트웨어를 만드는 경우는 많지 않음. 따라서 TDD 방법론을 적용한 테스트 코드들의 사용과, Profiler를 활용하여 개발한 소프트웨어의 성능을 수치로 명확하게 보여주고, 문제가 되는 병목 구간 부분을 도출하여 개선하는 과정은 개발자로서의 가치를 높히는 결과를 야기함

이외에 수업에 근거한 의미있는 답변 여부를 평가함

추가로, 채점시 느낀 것으로, 문제가 “혼자” 개발을 진행하는 것인데, 팀작업/개발업무분장 등으로 설명하거나 혹은 강의노트에서 좋아보이는 이야기를 그냥 가져다가 인용하는 경우가 있음. “회사가 본인 개인의 역량을 평가해서, 앞으로 얼마의 돈을 줄 것인지 결정”하는 일인데, 문제를 벗어난 행동은 추후 돌이킬수 없는 결과를 야기할 수 있다는 점을 명심 했으면 함 (일이 벌어지기 전의 사소한 행동이, 일이 벌어지고 난 후 돌이킬 수 없는 후회로 남는 것을 사회에서 꽤 많이 경험 할 수 있음. 예를 들면, “협업” 과제가 아닌데 스스로 지시를 깨고 “협업”을 하는 것, 지각하지 말 것, 노트북과 서랍은 반드시 잠글 것, 화면 보호기는 반드시 회사에서 정한 시간에 암호 모드로 잠기도록 설정할 것, 접속하지 말라는 웹 사이트는 절대 접속하지 말 것 등임)  

[문제 4]

오픈소스 소프트웨어 관련 기사 등의 수업 내용을 곰곰히 생각해 보면 분야별로 다른 답이 나옴

일단 네이버/NC/삼성전자/다음카카오 등은 글로벌하게 오픈소스를 만들고 개방하고 주도하는 노력을 많이 하고 있음

본인 혹은 학생의 관심사에 도달 하기에는 너무 전문적인 소프트웨어다 보니, 학부 학생 수준에서 알기 어려울 순 있음

하지만 위와 같이 소프트웨어 개발자의 역량이 높은 회사를 제외하면, 대부분의 경우 오픈소스 소프트웨어 소비자인 경우가 많음

이유를 생각해 보면, 사용자에게 서비스를 제공하기 위한 수단 차원에서 오픈소스를 사용하지,

오픈소스 자체가 목적이 되는 경우 혹은 오픈소스를 더 개량해야할 만큼 구체적인 문제가 드러나지 않는 경우가 많음

결국 도구 적인 관점에서 오픈소스를 사용하고, 문제가 있으면 자체 수정하나 기여 까지는 안하는 경우가 많음

그럼에도 오픈소스를 하는 이유는, 도구적인 관점과 자체 수정(in-housing)을 위한 인력은 반드시 필요한 부분임

이에 회사에서 사용하는 오픈소스를 잘 다루고 내부 수정까지 하기 위한 인력은 상시 채용하고 있음

더불어 개인적으로도 관심 분야의 오픈소스를 찾아 기여하거나, 새롭게 만들어서 공개 하는 경우,

해당 오픈소스를 활용하는 회사로부터의 취업/컨설팅 기회가 있으며, 자아실현적인 면도 매우 우수한 장점이 있음

위와 같이 구체적인 현실속 사례와 함께 개인적인 의견을 논리적으로 설명함

추가로, 채점시 느낀 것으로, 영어 지문의 의미를 제대로 이해하지 못하는 경우가 있는데, 논지는 15세 학생의 성급함(?)에 대한 전문 프로그래머의 진지한 조언임. 그런데 “세상이 몰라주는 불운의 어린 모짜르트”로 이해하는 경우가 종종 보임