교육학

대학교 때까지는 전혀 관심이 없었지만 일을 하기 시작하면서 관심이 생긴 분야가 교육학이다. 대학교 때 교육학은 교사가 되기 위한 과목으로, 전산에 생각이 있었던 나에게 교육학에 대한 접근은 머나먼 일일 뿐이었다. 회사 일을 하기 시작하고, 특히 IT 업무에 있어 교육은 떨어질 수 없는 일 인지라 점차 관심을 끌게 되었다. 물론 교육 중 학습, 배우는 데 집중되어있지만, 배우는데 최고의 방법은 가르치는 것임을 얼핏 알고 있는지라 교육법에는 관심이 있다.

내가 바라보는 교육에 관한 지식의 방향은 다음과 같은 내용이 있다.

첫째, 교육법에는 내가 지식을 확실하게 쌓는 목적으로의 교육법에 생각이 있다. 완전히 교육의 목적으로 확립된 과정은 아니지만, 회사 IT 개발실의 업무 과정에는 리뷰, 세미나, 스터디 등의 일종의 교육행위가 시행되고 있고, 개인적인 학습은 회사 업무에 확립되지는 않지만, 일반적으로 권장된다. 이처럼 교육법은 업무과정에 이미 들어와 있고, 교육법의 이론적 지식이 있다면 조금 더 확실한 지식 획득의 방법이 될 수 있을 거로 생각한다.

둘째, 나는 프로그램 개발단계에 교육이라는 것이 들어가야 한다고 생각을 한다. 처음 일한 SI 파견 업무에서 결과물 인계가 잘 이루어지지 않는 것을 보고 처음 생각했었다. 꼭 SI 업무로 인계가 포함된 업무가 아니더라도, 결과물로 설명서를 작성하고 작업자 간 업무를 인수인계 과정에서 설명과 문서작성이라는 업무가 수행된다. 이는 이미 회사 업무에 포함된 업무이고, 이를 공식적 업무 수행단위로 발전시켜 나가야 개발방법이 더 발전할 수 있다고 생각한다.

셋째, 최근에는 코딩 교육에 대한 논의가 시작됨에 따라 일반적인 교육 가르치는 내용에 관심이 있다. 직접적으로 초등 중등 과외가 있다. 직접 과외로 끝날 수도 있지만, 회사에서도 후임을 이끌어가거나, 팀원을 이끌어 가는 경우도 비슷한 경우일 수 있고, 이처럼 회사에서 일부분 업무영역에 들어 있다고 생각한다. 리뷰, 세미나는 어느 정도 양방향을 고려한 과정이라면, 코딩 교육과 관련된 개념은 나의 지식을 정리하고 그것을 교육하는 조금 다른 접근을 가지는 분류해 본다.

나는 고등 교육 과정의 지식을 쌓고, 중등 교육 과정 정도를 가르치는 능력을 쌓고 싶다. 교육에 대한 이론적 정리를 통해 일반적 고등학생의 지식이 아닌 통찰을 가지는 지식을 쌓고 싶다. 고등 교육은 일반적으로는 거의 모두가 받는 교육이지만 대학을 나오더라도 배울 수 없는 내용을 가득히 담고 있다. 그리고 사족으로 지금 고등 교육과정에 있거나 아직 기회가 남아있다면 열심히하면 좋다는 이상적이 이야기를 하고 싶다. 내가 관심있어서 이야기하는 교육학은 일반적인 내용보다는 개인적 생각에 불과 하겠지만, 앞으로 이를 정리하며 전체적인 지식에 있어 통찰을 가지고 싶다.

느린 개발

개발이 복잡해 짐에 따라 점점 개발이 어려워지고 느려진다. 사실 처음부터 느렸으나 다른 사람도 초보 시절에는 느리다는 것을 알았는데, 지금 다시 나에게 소프트웨어 위기가 다가온다. 거기에 AI는 점점 발전하여 사람을 앞지른다. 어떻게 해야 빠르게 잘 개발을 할 수 있을까 생각해본다.

집중

집중이 필요하다. 그래야 재미도 있고 과정과 결과 모두 좋아진다. 불필요한 일은 최대한 줄이고 필요한 일을 주로 해야 한다. 항상 어떤 일을 할 때 다른 것들이 따라오곤 한다. 아주 급한 시험공부를 하는 데 있어 책상 정리와 같은 해야 할 것 같은 일들 그런 일을 어떻게 해결해야 할까. 결국, 책상 정리를 하지 않는 것이 공부를 잘하는 실력임이 분명하겠지만, 나는 잘 그러지 못하고 평소 책상을 정리해 두던가, 아주 빠르게 책상 정리를 끝내는 방법이 내가 하는 있는 방법인 것 같다. 내 방법을 인정하고 그렇게라도 집중을 위한 노력을 해야 하겠다.

도구

도구가 힘든 일을 도와준다. 그래픽 환경과 콘솔 환경, 그래픽 환경은 이해를 돕고 대신 속도가 느릴 수 있다. 콘솔 환경은 속도가 빠르지만 이해가 어렵다. 최근 추세라고 하기까지는 뭐하지만, 점점 해커의 방법이 주류로 올라오는 것 같다. 깃허브와 마크다운이 많이 사용되고. 에디터도 오픈소스가 유행하고, 콘솔 환경이 다시 유행한다. 생각을 바꿔 이러한 환경을 전환하기가 쉽지만은 않다. 하지만 생각을 바꿔가며 이런 것을 습득할 때 여러 가지 면에서 생각해 볼 수도 있고 머리도 말랑해지는 것 같아 도움은 되는 것 같다. 그래픽 환경은 이해와 테스트에서 좋다. 하지만 개발에서는 아직 단일프로세서 콘솔 처리가 내 머리에서 적합한 수준이다. 아직 멀티 코딩을 할 수도 없고 흐름을 따라가기 위해서는 단순해야 한다.

내가 어디로 가야 하는지는 잘 모르겠다 멈추어서서 생각해 보기에는 빠른 추세 전환과 계속해서 나오는 기술들에 등 떠밀려 떨어져 버릴 것 같다. 그냥 따라가려고 노력하고 잘 안 되고 그런 시기인 것 같다. 어떤 때는 다 똑같아 보여 별거 없는 모습을 보이다가도 한없이 높고 어려운 것이 삶인 것 같다.

테스트주도개발

TDD는 효율성이 떨어진다. TDD는 죽었다는 글이 공감을 얻은 지도 한참이지만 아직도 이상주의자(?)와 그렇지 않은 사람과의 논쟁은 계속되고 있다. 어떤 것이 절대적으로 좋다고 하기는 힘들지만 나는 TDD가 잘못되어 있다고 생각한다.

1. TDD가 이상적으로는 굉장히 좋은 방법임은 분명하다. 하지만 이는 사람과 잘 어우러지지 않는 방법이라 생각한다. 이상적으로 100%의 목표, 높은 커버리지를 지향하며 개발하는 것은, 심지어 1 더하기 1조차도 테스트를 해야 함은 많은 경우에 개발의 실패를 가져온다. 내 개인적 생각으로는 머리가 뛰어난 사람은 테스트를 생각만큼 잘 하지 않는다. 이러한 테스트 방법은 똑똑한 사람이 1+1=2를 테스트 하지 않는 것과 비교해 생각할 수 있다. 물론 나는 머리가 나쁘다 생각하고, 이러한 방법에 대해 조금 더 생각해봤고 그 과정과 결과에서 나온 생각을 이야기하려 한다. 커버리지는 기계적인 측정 방법이고 사람과는 잘 어울리지 않는 점이 있다. 여기에는 휴먼에러를 줄이려는 방법으로 커버리지를 높이는 기술적 방법이 있으나 아직 대부분 개발자가 일하는 환경은 그다지 자동화적이지 못하고 인간적인 데에 문제의 접점이 있다.
2. 또한, 문제는 시간과 복잡도이다. 테스트가 많아지면 유지해야 할 코드의 양이 많아진다. 이는 문서화의 문제점과 비슷한 것 같다. 문서화 양이 많아지면 문서의 정보를 유지하는데 어려움이 생기고 틀린 문서는 버그라는 문제를 가져온다. 테스트는 그래도 어느 정도 서로 간에 연관을 가지고 있기에 틀리는 경우가 비교적 적겠지만, 테스트의 깊이가 깊어져 유지가 힘들어진다면 결국 문서화에서 발생하는 것과 같은 문제가 생길 것이다.
3. 이와 비교해 유닛테스트 자동화는 굉장히 효율성이 높다. 이것은 어느 정도 TDD와 연관되어 있다. 가끔은 혼용되어 사용되고 있으나 나는 이 둘의 의미를 서로 다른 것으로 분리하고자 한다. 일반적으로 테스트가 필요한 사항들은 재사용할 수 있고 기능과 독립된 그리고 실제 동작을 확인할 수 있는 테스트로 작성되어야 하며 출력을 이용한 테스트와 다르게, 유닛테스트는 이러한 기능 요소에 부합하여 작성될 수 있다. 재실행이 가능한 테스트 코드는 계속 자동적인 테스트를 수행하여 오류를 줄여야 한다. 초급시절 기능을 만들 땐 그냥 기계적인 기능을 만든다. 이는 기계적인 TDD 테스트와 비슷하다. 경력이 쌓이고 서비스를 만드는 지금은 100% 커버리지 목표가 아닌 계속적 자동화를 지원하고 독립적인 테스트를 만들고자 한다. 내게 아직은 정립되지 않았지만 때로는 테스트를 먼저 생각하고, 때로는 기능을 먼저 생각해 설계하고 개발한다.
4. 개발은 개발을 위한 목적이 아닌 적절한 방법으로 목적을 달성하기 위한 활동이다. 때로는 오프라인 방법으로 문제를 해결해야 하고 때로는 완벽한 코드를 찾아야 하는 활동이라 생각하며 한 가지 방법론을 맹신하면 안 된다고 생각한다. 또한, 나는 개발자이기에 개발을 위한 활동이 필요하며 부수적인 활동 예를 들어 소프트웨어공학에 너무 빠져서는 안 된다고 생각한다.

best practice 구글 20% 룰

성공적인 사례를 생각해볼 때 기술적인 면과 경영적인 면 모든 면에 있어 성공사례로서 은 언급이 되는 구글의 20% 룰이다. 주어진 업무를 모두 수행할 때 20%는 자유로운 일을 수행할 수 있다.

사실 20%로 성공적인 결과물을 만들 수 있다면 구글에 들어갈 기술자이지 않을까 생각한다. 내 기준으로 현실적인 환경에서 성공적인 결과물을 내기 위해서는 더 많은 시간과 노력이 들어가야 할 것이다.

그런데도 20% 룰이 성공 사례로 확실한 점은 기술자는 기술적인 다른 업무를 수행해야 함이 분명하기 때문이다. 또한, 이미 20%보다 더 많은 시간을 이미 소모하고 있는지도 모른다. 아니면 낭비하고 있는지도 모른다. 프로세스를 정리할 때 보이지 않는 확실한 일을 정리할 때 그 프로세스를 개선할 수 있다고 생각한다. 문제를 정립하고 그 해결방안을 찾는다. 20% 룰은 보이지 않던 일을 정립하는 문제 개선의 활동이다.

주 업무와 다른 업무를 수행하는 것은 일반적으로 새로운 기술로의 접근을 가져온다. 일반적으로 엔지니어는 새로운 것에 관심이 많고 새로운 것을 통해 관점의 변화 가져올 수 있다. 신기술의 학습은 꼭 상당한 시간 후의 개선을 나타내지는 않는다. 오히려 지금 하는 일과 비교하여 생각하는 경우가 많아 지금 하는 주 업무에 개선이 더 많을 수 있다.

한때 20% 룰이 많이 언급되었었는데 최근은 다시 트랜드에서 벗어난 것 같다. 경영적으로 별로 효과를 얻지 못함 때문일 것이다. 이런 점에 엔지니어의 역할도 있었겠지만 단순한 트랜드 때문일지도 모른다고 생각하고, 지금도 나를 포함한 많은 엔지니어가 상당한 노력을 두 번째 프로젝트에 투자하고 있을 것으로 생각한다.