공학과 SW 개발의 정의
무엇을 배워야 할까?
공학의 정의
Dave Farley가 쓴 "Modern Software Engineering-Doing What Works to Build Better Software Faster"에 보면 공학과 SW 개발의 정의("A Working Definition of Engineering")에 대한 다음과 같은 구절이 있다.
공학은 실제 문제에 대한 효율적이고 경제적인 해결책을 찾는 경험적이고 과학적인 접근을 적용하는 것이다(Engineering is the application of an empirical, scientific approach to finding efficient, economic solutions to practical problems)
이 정의를 좀 더 자세히 살펴보자
1. 과학적 접근 외에 경험적 접근이기도 하다.
이 말은 지식도 중요하지만 그 지식을 활용한 경험을 통해 쌓은 접근도 중요하다는 의미로 여겨진다. 공학은 지식만 가지고는 안되고 그 지식을 활용한 경험도 크게 작용한다는 말이라고 생각한다. 그래서 공학은 지식만 중요한 것이 아니라 오랜 기간 지식을 쌓고, 경험을 통해 지식을 깊이 있게 이해하고 자신의 해결책을 만들어가는 것도 중요한 부분이라고 여겨진다.
종종 책을 보다가 이전에 고생한 경험에 대한 해결책을 발견한다. 그때는
"내가 이 책을 미리 봤으면 그때 그 문제를 좀 더 빠르게, 잘 해결했을 텐데..."
라는 생각을 했었다. 하지만 시간이 좀 더 흐른 후에는
"내가 그런 경험을 하지 않았다면 이 책의 이 구절을 이렇게 뼈저리게 이해했을까?"
라는 의문도 들었다. 어떤 책을 읽고는 상당히 이해했다고 생각을 하는 경우가 많다. 하지만 관련된 경험을 쌓고 1~2년 정도 후에 다시 읽으면 "이 책에 그런 구절이 있었나?"라는 생각이 들어 놀랄 때가 많다. "아는 만큼 보인다"라는 말이 있다. 어쩌면 공학을 추구하는 개발자로서 내게는 경험한 만큼 보이는지도 모르겠다.
결국 지식이 중요하지만 이를 실제적인 문제 해결(이게 개발자의 주 업무일 것 같다) 경험을 통해 체득해야만 제대로 자신의 것이 되는 것 같다.
2. 효율적이고 경제적인 해결책이어야 한다.
빠르게만 만들고 잘 만드려 노력하지 않는 경우를 많이 봐왔다. 이때 "잘 만들어야 한다"를 강조하면 종종 너무 잘 만드려고 시간을 과하게 들이는 경우도 본다. 아무래도 나는 관리자이기도 하기에 좋은 설계, 역량 증대만큼 업무에 기여하는 것도 중요하다. 이를 위해서는 경제적이어야 한다. 합리적인 시간을 들여 좋은 품질의 SW를 만들어야 한다. 어떻게 해야 할까? 팀에 TDD, 객체지향 설계 등의 역량이 뛰어난 개발자가 있다. 그분의 코드를 보고, 그분의 리뷰를 받은 아직 TDD, 객체지향 등에 대한 역량이 부족한 개발자는 어떻게 해야 할까? 그분처럼 되고자 1시간 만에 끝날 일을 2~3시간 들여서 해야 할까? 나는 아니라고 생각한다. 일단 1시간에 할 수 있을 만큼의 품질이 내 실력임을 인정하고 연습을 해야 한다고 생각한다. 1시간 동안 시험을 보는데 1시간 동안은 80점을 받고 100점을 받기 위해 1시간을 더 사용하겠다고 할 수 있을까?
품질이 부족하더라도 합리적인 기한에 맞춰 SW를 배포함으로써 기여해야 경제적인 것이라고 생각한다. 팀의 최고 개발자와 같은 수준의 품질만큼 잘 만든 SW만 배포한다면 어쩌면 팀에서 가장 개발 역량이 부족한 개발자는 SW를 배포할 수 없을지도 모른다.
3. 어떻게 하면 점차 나의 실력을 늘릴 수 있을까?
TDD, 객체지향 등은 꽤나 어려운 기술이라고 생각한다. 하루아침에 익숙해지기는 매우 어렵다. 오랜 기간의 연습이 필요하다. 연습은 어떤 문제를 가지고 해야 할까? 기한이 정해져 있고, 우리 서비스에 기여할 만큼 복잡한 기능 요구사항을 가지고 해야 할까? 아니다 내가 익숙지 않은 도구, 기술을 익힐 때는 쉬운 문제로 시간적 압박이 없는 상태에서 해야 한다. 즉 업무 시간이 아니라 업무 외 시간에 편안하게 느리게 연습해서 어려운 문제도 약간의 시간적 압박이 있는 상황에서도 풀 수 있도록 익혀야 한다.
"연습은 연습장에서 해야 한다"
야구 포수가 2루 송구 연습을 하는 것을 지켜본 적이 있다. 지도자는 공을 받고, 미트에서 공을 빼서, 팔을 스윙하고, 스텝을 밟아서 2루에 던지고, 마지막 자세를 잡기까지의 과정을 매우 작은 과정으로 나눠서 연습을 시켰다. 처음에는 느리게, 각 구분 동작을 끊어서 연습을 시킨다. 그러다 마지막에는 연결 동작으로 천천히, 그리고 마지막에는 전체 동작을 매우 빠르게 하도록 연습을 시킨다. 잘 안 되는 부분이 있으면 그 부분만 따로 반복 연습을 시킨다. 어려운 기술은 이렇게 배워야 한다. 전체를 살펴보되 천천히 구분 동작으로 연습을 하고, 서서히 속도를 높이는...
SW 개발의 정의
"Modern Software Engineering-Doing What Works to Build Better Software Faster"에서 SW 개발을 아래와 같이 정의하고 있다.
SW 개발은 발견과 탐색의 과정이다. 그래서 성공하기 위해 SW 엔지니어는 배우는 것에 전문가가 되어야 한다(Software development is a process of discovery and exploration; therefore, to succeed at it, software engineers need to become experts at learning)
발견과 탐색의 과정이 이라는 말은 어렵지 않게 이해가 된다. 대개 개발자들은 자신이 최근에 만들었던 것을 다시 만드는 경우가 없다. 그래서 늘 새로운 문제를 해결해야 하니 발견과 탐색을 잘해야 할 것이다.
이를 위해 각종 도구, 기술을 익히게 된다. 개발 관련 지식은 너무 자주 바뀌는 경향이 있다. Dave Farley는 자신의 경력 동안 15~20개 정도의 언어를 사용했다고 한다. 뭐 나도 꽤 많은 언어를 사용한 것 같다. 많은 것을 알게 되고, 알아야 한다. 즉 배워야 한다. 그러니 배우는 것에 전문가가 되어야 한다는 것이다.
개발자가 배워야 할 가장 중요한 기술은 무엇일까?
요즘은 개발자 교육을 위한 많은 서비스가 존재한다. 아무래도 비용이 상당하기 때문에 종종 특정 강의를 듣는 것에 대해서 자문을 구하는 주변분들이 있다. 나는 그분들에게 최근에 이렇게 조언을 한다.
"강의료를 지불하고 잘 만들어진 강의를 수강해서 빠르게 그 강의에서 다루는 지식을 얻을 수는 있을 것이다. 하지만 그게 정말 당신에게 필요한 기술인가?"
"앞으로 뭔가를 배워야 할 때마다 그런 강의를 통해서만 배울 것인가?"
"강사가 알려주지 않는 것 이상을 알기 어려울 텐데 괜찮은가?"
등의 질문을 하고는
"나는 지식을 빠르게 배우고, 연습해서 체득하는 기술을 익혀야 한다고 생각하고, 이건 누가 알려주는 것이 아니라 자신만의 방법을 반복적인 연습을 통해 얻어야 한다고 생각한다"
라고 답변을 한다. 배우는 방법을 연습하고 터득해서 배우기 전문가가 되어야 한다.
내가 처음 TDD를 접했을 때
처음 TDD를 접하고 약간의 공부와 연습을 하고는 TDD를 할 수 있다, 아니 한다고 생각했다. 하지만 후에 TDD 관련 강연을 준비하면서 라이브 코딩을 위해 연습을 엄청나게 한 후에야 손에 익는다는 것을 알게 되었다. 방법을 누가 알려 줄 수는 있을 것이다. 하지만 결국 내가 연습을 해서 내 것으로 만들어야 하고, 계속 개발자로 경력을 쌓으려면 남이 알려주지 않는(이런 영역은 책을 쓰거나 강의를 해도 대상자가 적어서 잘 안된다. 다수를 위한 책/강의는 쉬운 것을 다룰 수밖에 없을 것 같다) 어려운 기술도 스스로 배울 수 있는 역량을 만들어 가야 한다.
자 그럼 개발자 아니 비단 개발자뿐 아니라 전문가가 되고 싶은 분들이 배워야 할 것은 명확해지는 것 같다. 시중에 나와 있는 책, 강의 등에서 다루는 것을 비용을 들여 빠르게 배우는 지름길을 택할 것이 아니라 스스로 배울 수 있는 능력, 더 빨리, 잘 배울 수 있는 능력을 배우는 것이 핵심인 것 같다.
PS
케이타운포유(https://www.ktown4u.co.kr/)에서는 기획/개발자 채용합니다.
특히 데이터 분석에 관심이 있으시면서 mysql, postgresql, python에 경험이 계신 분 찾습니다.
관심 있으신 분들은 msbaek@ktown4u.com 으로 메일 주시면 됩니다.
