작년 11월부터 학생들과 진행한 자바 스터디가 오늘로 끝났다. 초반 시작할 때는 기존 스터디와 별다른 점이 있을까 생각했다. 그런데 스터디가 끝난 지금은 "정말 즐거운 경험이었고, 나 또한 많은 것을 배운 스터디였다."고 말할 정도로 즐거운 경험이었다. 스터디 초반에 다소 재미가 없었지만 일정 시점이 지나면서 느꼈던 즐거움은 다른 어떤 곳에서도 느낄 수 없는 소중한 경험이고, 추억이 되었다. 이 소중한 경험을 공유하려 한다.
스터디 진행 방식
스터디에서 전하고 싶었던 내용은 객체 지향 설계, 단위 테스트의 필요성과 테스트 주도 개발 방식, 리팩토링을 깊이 있게 경험할 수 있도록 하는 것이었다. 학생들이 만들고 싶은 소프트웨어를 하나 정한 후 단계적으로 만들어가면서 위 내용을 소화하는 것을 목표로 했다.
스터디 진행은 다음과 같이 진행했다.
- 각 스터디 주차별로 요구사항 목록을 정한 후 학생 개개인이 해당 기능을 구현해 온다.
- 스터디 시간에는 해당 요구사항을 짝 프로그래밍으로 구현하면서 이슈 사항에 대해 토론하는 방식으로 진행했다.
- 다음 시간까지 구현할 요구사항을 정리한다.
- 스터디에 대한 회고를 진행한다.
매주 위와 같은 방식으로 진행했다.
스터디 과정
각 주차별로 진행한 스터디 과정은 다음과 같다.
- 자바-1주차 - 요구사항 분석 : 1주차에는 구현할 소프트웨어를 정했다. 난이도나 규모로 봤을 때 지뢰찾기를 선택했다. 지뢰찾기 게임에 대한 요구사항을 분석했다. 요구사항 분석 과정에서 단계별로 어떻게 접근할 것인지에 대한 토론 과정이 있었다. 최초 5 X 5부터 시작할 것인지 여러 가지 방식으로 접근하다 1 X 1부터 2 X 2로 단계적으로 확장해 가는 방법으로 결론을 내고 요구사항을 정리했다.
- 자바-2주차 - 1 by 1 구현 : 개발 환경 정리하고, TDD에 대한 감을 찾아가면서 1 by 1에 대한 기능 구현했다.
- 자바-3주차 - 2 by 2 구현 : 처음 개발할 때는 클래스 이름 등에는 특별히 고민하지 않으면서 일단 개발하기 시작했다. 2 by 2 구현하면서 지뢰찾기에서 사용하는 용어들을 찾아 Grid, Square 등으로 이름과 메소드명을 리팩토링하는 가장 낮은 수준의 리팩토링을 경험했다.
- 자바-4주차 - 3 by 3 구현 : 게임의 핵심 기능을 구현하고 대부분의 기능을 구현완료했다. 대부분의 기능을 완료하고 학생간의 구현 속도에 차이가 나면서 서서히 재미가 떨어지는 경험을 했다. 동기부여에 대한 열정은 한 달이 정점인가라는 생각을 했다. 무엇인가 동기부여를 시켜줄 단계였는데 동기부여를 할 요소가 없었다.
- 자바-5주차 - 게임 기본 엔진 구현 완료 : 지뢰찾기 게임에 대한 기본 기능은 구현 완료했다. 게임의 완성도를 높이기 위해 추가적으로 구현해야할 기능도 많고, 소스 코드도 리팩토링할 부분이 많았다. 하지만 학생들의 동기 부여가 바닥으로 떨어지고 있었으며, 기말고사까지 겹치는 사태가 벌어졌다. 한동안 쉬는 것이 좋겠다는 결정을 했다. 이 시점에 정리했던 스터디 회고를 보면 다음과 같다.
- 자바-6,7주차 - 새로운 자료구조로 변환 : 기말고사가 끝나고 방학 시작한 후 스터디를 다시 시작했다. 거의 한 달만에 진행하는 스터디였다. 그런데 스터디를 새로 시작하면서 학생 중의 한명이 boundary condition을 효율적으로 처리하기 위해 Dummy 데이터를 가지는 새로운 형태로 구조를 바꿀 것을 제안했다. 자신이 구현한 소스 코드가 얼마나 좋은지에 대해 공유하면서 스터디가 다시 활기를 띠기 시작했다. 그런데 이 시점에 내가 한 가지 제약사항을 두었다. 기존에 개발한 테스트 코드가 깨지지 않는 상태에서 소스 코드를 리팩토링해야 한다는 것이었다. 즉, 실무에서 유지보수 단계에 발생할 수 있는 상황을 인위적으로 만들었다.
- 처음에는 상당히 단순하게 생각했다. 지금까지 새로운 구조로 변환하기 위해 기존의 구조를 완전히 바꾼 후 문제를 해결하기 위해 디버깅에 많은 시간을 쏟는 것이 일반적인 개발 방식이었다. 그런데 그런 방식으로 개발하지 못하도록 한 것이다.
- 6주차에 1시간 동안 새로운 자료 구조에 대한 설명을 하고 2시간 동안 문제를 풀기 위해 노력했다. 확장 가능한 구조로 바꾸지 않은 상태에서 가장 중요한 부분을 건드리는 순간 모든 단위 테스트가 깨졌다. 2시간 동안 깨진 단위 테스트를 해결하지 못했다. 하나를 해결하면 다른 곳에서 버그가 발생했다. 6주차는 이 상태로 마무리하고 각자 돌아가서 해결책을 찾아오는 것으로 마무리했다.
- 7주차가 되었다. 학생 한명이 설 명절이라 빠지고, 한 명은 일이 있어 빠졌다. 학생이 2명이나 빠진 상태였기 때문에 많은 내용을 다루기보다 설계를 통해 구조를 변경하는 시도를 했다. 자료구조나 알고리즘이 바뀌면서 변경이 되는 부분과 변경이 필요없는 부분을 어떻게 분리할 것인지에 대해 많은 시간을 토론했다.
- 이렇게 한참을 토론하던 중 한 학생이 "교수님, 운영체제가 하드웨어를 추상화함으로써 하드웨어가 변경되어도 운영체제에서 돌아가는 소프트웨어를 변경하지 않아도 되듯이 같은 구조로 설계하면 되겠네요."라는 통찰을 얻으면서 설계에 대한 방향을 찾아나가기 시작했다.
- 설계를 마무리한 후 구조를 바꾸기 위한 1단계 구현까지 완료했다. 이 때 참여한 2명의 학생과 나는 희열감을 느끼면서 흥분했던 기억이 난다. 정말 이 같은 생각으로 설계를 발전시킬 수 있을지 기대하지 않았는데 학생으로부터 구조가 바뀌어 갈 때의 흥분이란 그 무엇과도 비교할 수 없을 것이다.
- 자바-8주차 - 클래스 재설계 : 설이 끝난 후 모든 학생이 참여했다. 구조를 바꾸기 위한 1단계 작업이 진행된 후 구조를 바꾸기 위한 과정 속도가 빨라졌다. 학생들의 참여도 또한 이전과는 비교할 수 없을 정도로 높아졌다. 과정에 대한 참여도가 높아지는 것을 피부로 느낄 수 있었다. 이 때 재설계한 모습은 다음과 같다. 인터페이스를 추출하고 구조를 개선하는 설계만 마친 후 구현은 학생들에게 맡겼다.
- 자바-9주차 - 구조 개선 1차 완료 및 스터디 종료 : 간단히 소스 코드 리뷰만 하고 끝내려고 했으나 학생들의 통찰이 있는 질문을 통해 interface, abstract, concrete class, 상속, 조합 등 OOP 핵심과 관련된 모든 내용을 다루면서 학생들의 이해도가 높아지는 경험을 했다. 마지막 스터디에서 정말 즐거운 경험을 했다.
- 스터디에서 진행한 소스 코드는 https://github.com/javajigi/minesweeper 에서 확인할 수 있다.
회고
그 동안 이 같은 짜릿함을 느끼기 위해 힘들지만 스터디를 진행한 듯하다. 초반에 다소 지루하고 힘든 시간이 있었지만 시간이 지날 수록 느꼈던 희열감은 앞으로도 잊지 못할 듯하다. 학생들의 회고를 정리하면서 스터디를 마치려고 한다. 마지막까지 나를 믿고 같이 마무리한 선진, 영남, 건희, 택순에게 감사의 말을 전한다.
학생들의 목소리를 생생하게 들을 수 있는 음성 파일도 들어보면 재미있다.
스터디를 하면서 가장 큰 영감을 얻은 시점은 언제였으며, 어떤 영감을 얻었는가?
- 학생 A
- boundary condition을 제거하기 위해 Dummy Node를 추가하면서 객체의 역할이 명확해 졌을 때 즐거웠다.
- 설계하고 논리하는 과정
- 의외성으로부터의 배움
- 복잡한 논리를 인터페이스와 추상화 개념을 통해 풀어가는 것
- 학생 B
- Position 클래스 만들기, 인터페이스 활용 등 설계가 코드의 간결함과 명확함을 향상시키는데 큰 도움이 된다는 사실을 깨달았을 때
- 학생 C
- hashcode()와 equals()의 역할과 동작 방식을 이해했을 때. 메모리 참조에 대한 내용이 머릿 속에서 자연스럽게 도식화가 일어나고 있었던 점에 스스로 놀랐다.
- 인터페이스와 추상 클래스 이야기가 나왔을 때, 대충 그런 것이 있고 어떻게 동작한다는 것만 어렴풋이 기억하고 있었다.
- 그런데 프로그램 작성시에 전체 구조를 효과적으로 만들기 위해 어떻게 응용하는지 약간이나마 단서를 잡은 것 같다.
- 앞으로 무엇을 더 공부해야할지 방향을 찾는 듯한 느낌이다.
- 학생 D
- 다른 사람과 다른 생각이 같은 문제를 다른 시각, 다른 방법으로 보게 해 줄 때
- New Logic, Position, OOP
더 좋은 스터디를 하기 위해 개선해야 할 부분은 무엇인가?
- 학생 A
- 과제에 대한 압박이 조금 더 높으면 좋겠다.
- 작은 것이라도 직접 해봐야 더 많은 이야기를 할 수 있겠다.
- 학생 B
- 이번은 자율적인 참여 기반의 스터디였기에 스터디 후 그냥 지나가는 일도 종종 있었다.
- 하지만 스터디에서 다룬 내용에 대한 정리, 구현이 꼭 수반되어야 할 것 같다.
- 학생 C
- 없음
- 학생 D
- 학생에게 적당한 높이의 허들과 과제를 해결해 나가는 것에 대한 즐거움 공유
NEXT 수업을 우리가 진행한 자바 스터디와 같이 진행할 경우 적합한 부분과 우려되는 점은 무엇인가?
- 학생 A
- 장점은 기억에 오래 남는다. 아하! 하는 경우가 많다.
- 우려는 수업마다 배움의 정도와 양의 차이가 심하다.
- 학생 B
- 기본 프로그래밍 소양 - 조건문, 반복문 등의 사용이 자유로워야 이번과 같은 설계에 대한 논의가 가능할 듯
- 동기부여 정도의 차이 - 이번 스터디는 다들 동기부여가 잘 되어서 시너지가 잘 일어났지만 그렇지 않은 경우가 생기면 점점 허송세월하는 시간이 늘어날 수도
- 학생 C
- 좋은 점
- Programming Language(이하 PL)에서 다루는 이론, 철학적인 내용들이 실제로 프로그래밍 구현에서 어떤 역할을 하는지, 어떤 효과가 있는지 직접 경험하는 기회가 될 것 같다.
- 이와 같은 이론적 접근이 어쩌다 생겨났는지를 단편적으로나마 생각해 보면서 컴퓨터 프로그램이 어떻게 동작하는지를 생각해 보게 되지 않을까?
- 우려되는 점은 초반에 기초적인 문법을 익히기까지 시간이 꽤 들지 않을까?
- 좋은 점
- 학생 D
- 학생들의 과제에 대해 느끼는 난이도가 달라서 포기 또는 재미없어 할 수 있다. 과제 자체가 전체 수업에 주는 영향이 커짐
NEXT 수업과 자바 스터디에서 차이점이 있다면 무엇일까?
- 학생 A
- 자유롭게 이이기할 수 있었다. -> 의외의 아이디어가 많이 나옴 -> 쉼(쉬는 것 == 배우는 것)
- 즉, 자유롭게 이야기고 토론하면서 창의적인 아이디어가 나오는 경험을 했다.
- 학생 B
- 큰 차이점은 없는 것 같다. 스터디라서 강제성이 없다는 정도? 자바 수업을 많이 듣지는 못했고...
- 학생 C
- 스터디 쪽이 위에서 앞에서 말한 좋을 것 같은 부분을 더 충족시켜주는 것 같다.
- 학생 D
- 동기의 차이
- 스터디는 내가 필요하고 배우기 위해 스스로 찾아나선 것
- 수업은 그것보다는 수동적이게 되는 경향이 있다.
자바 스터디에 대한 전체 회고를 한다면...
- 학생 A
- 배움으로 봤을 때 높낮이가 있었지만 마지막에 느낀 배움은 앞으로 잊지 않고 계속 써먹을 만큼 강렬했다.
- 자유로움에서 오는 즐거움, '노는 것 == 즐거움 == 배움' 느낌
- 학생 B
- 뒤늦게 참여했지만 짧은 시간 동안 정말 많이 배웠다.
- 열정적이고 능력있는 동료들과 함께 자유롭게 상상하고 토론할 수 있는 환경에서 많은 성장이 일어난다는 사실을 체험했다.
- 학생 C
- 코딩 자체는 작년 이맘때보다 늘기는 한 것 같은데 뭘 더 해나가야 할지 갈피를 잡지 못하고 있었다.
- 그런데 이 스터디를 통해 앞으로 더 학습해야 할 부분이 무엇인지 감을 잡게 되었다.
- 학생 D
- 즐거웠다. 계속 이어나갔으면 좋겠다.