Java 로 만든 첫번째 Software Development

 

 

 

---

목차

• 전공과 수강 동기
• 과정 개요 및 학습 목표
• 실무 중심의 교육 방식
• MVC 아키텍처 이해와 구현
• 교육적 사용자 스토리와 학습 성과
• 개인 기여와 팀 협업의 균형
• 다양한 기술의 통합적 적용
• 소프트웨어 품질과 테스팅의 중요성
• 커뮤니케이션과 발표 능력
• 실제 개발 경험
  • 소통이 없는 개발팀
  • DB 설정(통일)이 없었다
  • 모든 것을 가라로 진행하자
  • 각기 다른 Branch에서 진행된 Test Case
• 문제 분석 및 현직자 피드백
• 결론 및 느낀 점

---

전공과 수강 동기

Enterprise Software Development 가 주 전공이기 때문에, Introduction to Software Development 을 수강했다. 내년이면 3학년이고, 졸업 년도 인 것도 있었다. Software 개발의 경험을 만들어 놔야지 향후에 도움이 되기 때문에..

 

 

(물론, 요즘은 산업혁명 마냥 AI 혁명이 와서 "재봉틀"을 쓰지 누가 굳이 "손" 으로 한땀 한땀 개발을 하겟냐! 라고 말을 하지만은, 기본적인 원리는 이해하고 잇어야지 앞으로 개발을 하는데 있어서 많은 도움이 되지..)

과정 개요 및 학습 목표

과제의 구성과 학습 목표 이 과정의 과제는 소프트웨어 개발 현장에서 흔히 볼 수 있는 프로젝트 기반 접근 방식을 채택하고 있습니다. 특히 주목할 만한 것은 Assignment 2가 전체 소프트웨어 개발 생명주기의 일부로, 구현 및 테스팅에 초점을 맞추고 있다는 점입니다. 명시적 학습 목표 과제 사양에서 직접 명시한 학습 목표는 다음과 같다: - 최소한의 감독으로 소프트웨어 개발 문제를 조사하고 해결하는 능력 개발 - 제약 조건 내에서 소프트웨어 개발 활동의 경쟁적인 목표를 결정하고 균형을 맞추는 능력 - 소프트웨어 기능을 생성, 수정 또는 확장하기 위한 개발 작업 계획 및 관리 능력 - 건전한 소프트웨어 공학 실무를 적용하는 능력 - 이해관계자에게 소프트웨어 및 작업 정보를 명확하게 전달하는 능력 이러한 목표들은 소프트웨어 엔지니어링 교육에서 중요시되는 ABET 학생 성과와도 밀접하게 연결됩니다. 실무에서 필요한 기술적 역량과 소프트 스킬을 균형 있게 개발할 수 있도록 설계되었습니다.

실무 중심의 교육 방식

Agile 방법론의 실제 적용 이 과제의 핵심적인 특징은 실제 산업에서 널리 사용되는 애자일 방법론을 적용한다는 점입니다. 학생들은 소프트웨어 스타트업 회사의 역할을 맡아 웹 애플리케이션을 개발합니다. 이는 Agile Learning의 개념과도 일치하는데, 속도, 유연성, 협업에 중점을 두어 팀이 스프린트를 통해 빠르게 움직이고 목표를 달성할 수 있게 합니다 애자일 학습은 일일 스크럼과 같은 간결한 회의를 통해 진행 상황과 학습에 대한 신속한 업데이트를 제공하는 방식으로 진행됩니다. 이러한 방식은 학생들이 실제 업무 환경에서 필요한 민첩성과 적응력을 기르는데 큰 도움이 됩니다.

MVC 아키텍처 이해와 구현

과제는 MVC(Model-View-Controller) 아키텍처를 따르도록 요구합니다. 이 아키텍처 패턴은 애플리케이션을 논리적 컴포넌트로 나누는 디자인 패턴입니다. 학생들은 이 과제를 통해: - 사용자가 View를 통해 요청을 전송하는 과정 - Controller가 요청을 받아 라우트 구성을 확인하는 과정 - 모델이 요청을 확인하고 결과를 생성하는 과정 - View 엔진을 통해 결과가 사용자에게 표시되는 과정 등을 직접 구현함으로써 아키텍처의 작동 원리를 깊이 이해할 수 있게 됩니다.

교육적 사용자 스토리와 학습 성과

과제에서는 학생들이 "Key Features Table"에서 기능을 선택하고, 백로그를 업데이트하며, 팀원에게 기능을 할당하고, Assignment 1에서 캡처한 사용자 스토리를 업데이트해야 합니다. 이는 교육적 사용자 스토리의 개념과 일치하며, 학습자가 학습 경험을 완료한 후 알아야 할 것, 이해해야 할 것, 또는 할 수 있어야 할 것에 초점을 맞춘 전문화된 애자일 요구사항입니다.

개인 기여와 팀 협업의 균형

이 과제에서 특히 주목할 점은 그룹 제출이지만 개별 평가 방식을 채택한다는 점입니다. 각 학생은 MVC 아키텍처 계층을 따라 소프트웨어 기능이나 모듈을 독립적으로 구현하고 테스트해야 합니다. 이러한 접근 방식은: - 학생들에게 개인 책임감을 부여합니다 - 모든 계층(Model, View, Controller)에 대한 심층적 이해를 장려합니다 - 동시에 통합된 작업물을 위한 팀 협업 기술을 개발합니다 이는 실제 소프트웨어 개발 환경에서 필수적인 "개인 책임과 팀 성공" 사이의 균형을 반영합니다.

다양한 기술의 통합적 적용

과제는 학생들이 다양한 기술을 통합적으로 적용하도록 요구합니다: - 웹 기술 (Java, JSP, JDBC, Java DB) - 데이터베이스 설계 및 연결 - 사용자 인터페이스 개발 (CSS 프레임워크 사용 가능) - CRUD 기능 구현 이러한 종합적인 접근 방식은 학생들이 단순히 개별 기술을 배우는 것이 아니라, 이들을 통합하여 작동하는 시스템을 구축하는 능력을 개발하도록 합니다.

소프트웨어 품질과 테스팅의 중요성

Assignment 2는 소프트웨어 테스팅에 상당한 중점을 두고 있습니다. 각 학생은 자신의 기능에 대한 테스트 결과와 결함 로그를 제출해야 합니다. 이는 소프트웨어 품질 보장의 중요성을 강조하며, 학생들이: - 테스트 계획 및 실행 방법을 배웁니다 - 결함 식별 및 기록 기술을 개발합니다 - 품질 속성이 소프트웨어 아키텍처와 설계에 어떻게 영향을 미치는지 이해한다 소프트웨어 아키텍처 평가와 설계 검토를 수행하는 능력은 전문적인 소프트웨어 개발 환경에서 중요한 기술입니다.

커뮤니케이션과 발표 능력

과제의 필수 요소 중 하나는 구현된 기능에 대한 구두/시각적 발표다. 이는 기술적 정보를 명확하게 전달하는 능력이 현대 소프트웨어 개발자에게 얼마나 중요한지 반영합니다. 학생들은: - 소프트웨어 설계 발표를 준비하는 방법 - 전문가 패널과 함께 소프트웨어 설계 검토를 수행하는 방법 - 소프트웨어 설계 검토에서 발생하는 조치를 처리하는 방법 등을 학습하게 된다.

---

 

Implementing & Testing

실제 개발 경험..

 

우선 시작하기에 앞서, 이후에 작성되는 내용들은 나의 경험과 감상을 주로 만들어졌다는 점을 알려 주고 싶다.

소통이 없는 개발팀

이상적인 개발팀에서는 매일 아침 스크럼을 진행하며, 각자의 작업 진행 상황을 공유한다. 또한 문제 발생 시 팀원들이 협력하여 해결책을 찾는다. 이런 방식은 프로젝트의 원활한 진행과 팀워크 강화에 도움이 된다. 그러나 실제 프로젝트 진행 과정에서는 이러한 이상과 현실 간에 차이가 발생하는 경우가 많다.

 

우리 팀은 초기부터 소통이 원활하지 않았다.

 

처음에는 각자가 바쁘다는 점을 고려해 크게 문제로 인식하지 않았다. 프로젝트가 학부 수준이며, 요구사항이 복잡하지 않았기 때문에 소통 부족이 큰 장애물이 되리라 예상하지 않았다. 하지만 시간이 지날수록 팀 내 커뮤니케이션 부재가 문제로 드러났다. 누가 어떤 작업을 진행하는지, 작업 진행 상황이 어느 정도인지 명확하지 않았다.

 

심지어 당일 작업이 이루어졌는지도 확인할 수 없는 상황이 반복되었다.

이메일이나 메신저를 통한 문의에 답변이 거의 없었으며, 팀원 간 상호작용이 현저히 줄어들었다.

그 결과 기능 중복 개발이 발생했고, 한쪽에서 수정한 코드가 다른 쪽에 의해 덮어쓰여지는 문제도 발생하였다.

 

이와 같은 상황은 ‘소통이 부족한 개발자’가 팀원이 아닌 단순히 독립적으로 일하는 개인과 다름없음을 보여준다. 물론, 이는 단순한 무관심이나 책임감 결여만으로 설명할 수 없다. 호주와 같은 개인주의 성향이 강한 문화에서는 불필요한 대화를 자제하는 경향이 있기 때문이다. 하지만 그러한 문화적 배경에도 불구하고

 

, 팀 단위로 협업하는 프로젝트에서는 최소한의 소통과 정보 공유가 필수적이다.

 

결론적으로, ‘팀’이라는 명칭 하에 협력하는 모든 구성원은 효과적인 의사소통을 통해 업무를 조율하고

문제를 해결할 수 있어야 한다.

DB 설정(통일)이 없었다

MongoDB Atlas: Cloud Document Database | MongoDB

MongoDB Atlas: Cloud Document Database

개발을 위해 사용해야할 DB.

 

앞서말한 소통이 없으면 자연스럽게 따라오는 일이기도 하다.

 

코드를 작성하는데 있어서 각자 다른 방식의 코드를 짜는 것이 습관화 되어있기 때문에,

코드 작성이나 개발에 앞서서, 개발의 계획이 중요하다.

 

어떠한, 몇번의 미팅이 자리잡아야하는지 아니면 어떤 것을 집중적으로 개발이 되었는지 말이다. 코드를 짤 때 변수명은 개발자의 철학이 담긴다고 한다. 예를 들어, a, b, c…0 이게 끝이 아니다. Prototype 의 전반적인 수정의 필요성이 여러번 있어 그것을 요구했을 때, 그룹장이라는 사람은 Prototype 을 수정하는 것을 원치 않아보였다.

 

또한 DB 가 완성되지 않은 상태에서 다음단계의 개발을 요구하는 경우도 많았었다.

 

내가 몇번이나 DB 가 수정이 되어야, 다른 것을 개발할 수 있다고 말을 했지만,

그것이 마지막까지 반영되는 것은 없었기 때문이랬다.

그 덕분에, 팀원들의 DB 들은 따로 놀았다

 

물론 DB 야, Scheme 를 수정하는 명령어로 나중가서 수정은 할 수 있겠지만, DB 가 수정되지 않은 상태에서 Tesst Run 을 어떻게 하겠는가. 결국 User 의 DB를 모두 갈아 엎어야 했다.

 

자신이 리더라고 칭했던 사람이 이렇게까지 타인에게 무관심해질 수야

모든 것을 가라로 진행하자

프로젝트가 초반을 지나 중반으로 접어들면서 Assignment 2는 개인 과제의 성격이 강해졌다. Assignment 1에서는 팀원들이 모두 동의해 ‘가라’ 방식으로 넘어갈 수 있었지만, 이번 과제는 각자의 실력이 드러나는 개인전이었기에 더 이상 허위로 작성하는 것은 불가능했다.

 

이는 리스크가 매우 큰 일이었고,

내 도덕적 양심에 따라 나는 반대의 목소리를 냈다.

허나 내 이야기는 반영 되는 적이 없었고. 결국은, 팀은 “일단 돌아가게만 하자”는 슬로건을 내걸고 나아갔다.

우리는 테스트도, 주석도, 문서화도 미루기 바빴다.

 

테스트는 “나중에 하지 뭐”, 주석은 “급한데 그런 거 쓸 시간 있나”, 문서화는 “어차피 우리가 다 아는데, 굳이?”라는 말로 정당화됐다. 기능은 하나둘씩 붙어갔지만, 코드의 품질은 점점 불균형해졌다. 테스트는 한 브랜치에서만 이루어졌고, 버그가 발생해도 원인을 추적하기 어려웠다. 주석이 없으니 서로의 코드는 물론, 며칠만 지나도 자신의 코드조차 이해하기 힘들어졌다. 또한, 앞서 말한 데이터 베이스도 획일화 되어 관리가 되고 있지 않으니까.

 

온라인 쇼핑 플랫폼을 만드는데 의미가 없어졌다. 결국 프로젝트 막판이 되어서야 우리는 코드 리뷰를 시작할 수 있었다.

각기 다른 Branch에서 진행된 Test Case

개인 Branch 에서 작동되는 것을 확인하기 위해 Test Run 을 하는 것은 첫번째 개발에 있어서는 아주 훌륭한 접근이다. Merge 를 하기 전에 오류가 없는 코드를 만들고 그리고 나서 Merge 를 하고 나서 또 다시 Test Run 을 해야하는 것이니까. 문제는 여기서 발생했다.

 

우리 훌륭한 "개발자" 분들은, 이것이 "개인"과제 인 것을 알고 나자 Merge를 하지 않을려 는 "못된" 심보를 가졌었다.

 

 

그도 그럴 것이, 앵? 어차피 제출해도 개인의 점수로 들어간다면 뭣하러 협조함?쿠쿠루삥뽕 ㅋㅋㅋ 그냥 내 기능만 만들어야지 ㅋㅋ 라는 심산인 것인데. 아주 논리적이고 합당한 처사라고 한다면야 할 말이 없긴 하다. 어딜 가던 장단 점이 있는 일이기에, 그것에 대해서는 내가 뭐라고 하겠는가....

 

물론, 개인 제출을 하는 것도 괜찮지만. 마지막 제출을 위해서는 Code 의 Similarlity(유사성) 을 피하기 위해서 (대학교는 기본적으로 plagirism 을 체크한다)는 한명이 제출을 하는 것을 권장하고 있다. 안 그러면, 시스템 상에서 채점을 시작하기 도 전에 코드나 글의 유사성으로 반려 되는 것이 다 반사라. 하나의 프로젝트는, 하나의 "최종"브랜치에서 작동을 확인해야한다.

 

문제 분석 및 현직자 피드백

운이 좋게도! , 개발의 길로 늦은 나이에 들어갔기 때문에서 일지는 몰라도 현직자가 피드백을 해 줄 수 있는 좋은 기회가 있었다. 개발이란 것이 본디 학교에서 배우는 "이론" 상의 한계는 분명하기 때문에 실무적 경험이 가장 중요한 것인지라. 내가 생각치 못한 Test Case 확보를 위해서 물어 봤었다.

 

 

 

 

 

 

 

 

 

 

 

 

결론 및 느낀 점

이러한 과제를 통해 학생들은 단순히 이론적 지식을 넘어, 실제 산업에서 필요로 하는 실무적인 소프트웨어 개발 기술과 경험을 얻게 됩니다. 애자일 방법론, MVC 아키텍처, 팀 협업, 테스팅, 그리고 효과적인 커뮤니케이션 - 이 모든 요소들은 현대 소프트웨어 개발 환경에서 핵심적인 역량입니다. 특히 주목할 점은 이 과제가 어자일을 활용해(learning agility)을 개발하도록 설계되었다는 것입니다.

 

어자일 은 개인이 익숙하지 않은 상황에 적응하고, 빠르게 학습하며, 대부분 자기 주도적인 방식으로 학습하는 능력입니다. 불확실성 시대에 최고의 성과를 내는 사람들은 자기 주도적이며 익숙하지 않은 상황의 불편함을 받아들일 수 있습니다. 결론적으로, 이 소프트웨어 개발 과제는 학생들이 단순한 지식 습득을 넘어, 복잡한 문제를 해결하고 실제 산업에서 성공하기 위해 필요한 전체적인 역량을 개발하도록 의도적으로 설계되었습니다. 이는 교육과 산업 간의 격차를 줄이는 효과적인 교육 방식의 좋은 예라고 할 수 있습니다.

 

---

 

소통방식이 하자가 있는 사람, 아니, 소통 능력에 하자가 있는 사람, 흔한 말로 사회성이 부족한 사람과 엮이는 것이 이렇게나 피곤할 일이었을까. 사람의 말을 들으려고 하지않으며, 본인의 방식을 고수하는 사람을 긍적으로 표현하면 "전문가" 라고 말하지만. 그 또한 본인의 한계를 깨닫고 상대의 눈을 맞추며 배울려고 하는 사람이 아니기 때문이랬다.

 

 

 

타인의 말을 공격적으로 받아들이는 사람이 있는 반면에, 자기가 한 말을 기억하지 못하는 사람이 너무 많다. 아니 기억하더라도 그 책임을 회피하기 위해 기억이 나지 않는다는 말로 빠져나가는 것이 아닐까 싶기도 하다.