본문 바로가기

이현진 성장기

충남대학교 SW 아카데미 조교 기록 1주차

CNU SW 아카데미 조교를 맡게 되었다. (22.07.04)

 

CNU SW Academy

CNU SW 아카데미 ? 대상자: SW 취업 준비 중인 충남대 4학년 재학생과 졸업생 교육기간: 4개월(16주, 8시간/1일) 교육내용: SW 교육과정 (백엔드, 프론트엔드, 클라우드, AI/데이터) 특징: 참여기업과 수

sites.google.com

 

이 글은 내가 조교활동을 한 내용을 정리한 글이다. (07.04 ~ 07.08)

 

 

1주차 발표 웹은 어떻게 발전했는가. (07.05)

1주차 - 이현진.pdf
12.46MB

정보화본부 3층에 가서 발표를 진행했다. 처음에 화면 공유가 잘 안되서 시간을 많이 잡아먹었다.

발표 내용은 소프트웨어 마에스트로 컨퍼런스에서 발표했던 내용을 조금 수정해서 발표 했다.

질의 응답까지 한 한시간 정도 한 것 같다.

 

1주차 질의 응답 정리

 

Q. 공부할 자료를 찾는 방법?

A. 대기업들은 기술블로그와 유튜브 채널를 가지고 있는데 그 기술블로그를 읽으며 이해가 안되는 키워드들 유튜브나 Velog등 개발자 블로그에 검색을 해서 찾아나가면서 공부한다.

 

Q. 백엔드 엔지니어가 알아야할 프론트엔드 지식? & 프론트엔드와 백엔드의 경계

A. 백엔드 엔지니어라 해도 프론트엔드의 기본적인 지식은 가지고 있어야한다고 생각한다. html, css, JavaScript와 프론트엔드와 통신을 어떻게 하는가. 또 이런 지식을 얻으려면 같이 팀이랑 같이 프로젝트를 하는게 좋다. 소통을 하면서 알아야하는 경계가 명확해 질 것.

 

Q. git의 경우 git bash를 사용한 방식이 아닌 sourcetree나 git desktop과 같은 방식도 추천해주셨는데 실제 기업에서도 명령어가 아닌 UI방식을 사용하는지 궁금합니다.

A. 안녕하세요.  고생하셨습니다. 소스트리 같은 것도 많이 씁니다. 다만 커맨드라인으로 하는 방법도 익숙해져야 한다고 생각합니다. 저는 깃 브랜치들이 복잡해졌을 때  시각화해서 보기 위해  소스트리나 git graph(vscode extension)를 활용합니다.

 

Q. 실제로 기업에서 프로그램을 만든다고 하면 디자인 패턴을 생각하고 적용해서 코딩하는지 궁금합니다. 

A. 안녕하세요. 이현진 조교입니다. 저도 학생이라 기업이 아닌 제 생각을 말씀드리겠습니다.  디자인 패턴은 어떤 문제에 대한 해결책이 일반화되어서 패턴으로 만들어진 것으로 알고 있습니다. 따라서 디자인 패턴을 생각하고 만든다기 보다는 주어진 문제에 대해서 객체의 역할,책임을 나눈 후에 그 객체들의 상호 작용(협력)을 생각하면서 개발을 하면 특정 디자인 패턴에 수렴할 것 같습니다.  하지만 반대로 숙련된 개발자들은 경험이 많기 때문에 '이 문제는 이 디자인 패턴을 쓰면 좋은 설계를 할 수 있어' 이렇게 말할 수 있을 것 같습니다. 또한 모든 기술이 그렇듯이 이 문제에 대해 이 디자인 패턴이 최우선이라고 말할 수도 없을 것 같습니다. 패턴, 기술들에는 trade off가 존재하니까요. 글이 길어졌는데 제 생각의 결론은 객체지향에서 중요한 것은 '특정 디자인 패턴을 적용해서 코딩을 해야 겠다' 보다 '객체들에 부여된 책임이  자율적인가', '인터페이스와 구현의 분리'등 객체들의 역할,책임,협력 관계에 더 집중하면 디자인 패턴이 따라올 것이고 체화도 될 것 이라고 생각합니다.  저도 객체지향을  아직 잘 몰라서 최근에 '객체 지향의 사실과 오해'라는 책을 읽었는데 재밌었어요. 추천합니다. 고생하셨습니다.

 

Q. interface DI( 를 이용하면 의존성 역전 원칙을 ) 지켜 객체간 의존도를 낮출 수 있습니다. 객체간 의존도가 높아졌을 때 발생할 수 있는 문제들이 궁금합니다.

A. 객체 지향 설계에서 객체는 충분히 자율적이어야 합니다. 객체에 의존도가 높아지면 말그대로 한 객체가 어떤 일을 하기위해 많은 객체를 의존하므로 객체가 주어진 책임을 완수하지 못할 것 같습니다.

 

Q. 프로젝트를 구현할 때 모든 메소드에 대해 구현을 하고 전체 틀을 잡는 것이 아니라로직에 따라 코드를 작성하며 필요한 메소드를 만드는 방식으로 구현하셨는데 거대한 규모의 프로젝트에서도 해당 방식으로 구현하는지 궁금합니다.

A. 제가 강의를 보진 않아서 이 질문에서 읽은대로만 제 생각을 말씀드리겠습니다.

객체는 각자가 맡은 책임이 중요합니다. 모든 메서드를 구현하고 전체 틀을 잡는 것은 객체의 책임을 모두 알고 있다는 전제하에 가능할 것 같습니다. 책임을 알고 있다는 것은 메서드 구현을 할 수 있다는 것을 의미하지만, 처음부터 어플리케이션의 수 많은 객체중 하나를 잡고 메서드를 구현하는것은 옳지 않다고 생각합니다. 객체하나의 메서드 구현이 중요한게 아니라 객체가 각자 맡은 책임을 다하는 존재로 보고 그 객체의 의존관계를 생각하며 다른 객체와 어떤 협력을 할 수 있는지 설계한 후에 다른 객체와의 협력에서 그 객체가 어떤 일을 할 수 있는지 인터페이스를 설계하고 그 후에 구현을 하는게 맞다고 생각합니다.