경험주의
소프트웨어 공학은 공학(Engineering)일까? 아니면 공예(craft)일까?
이 둘은 서로 배타적이지 않고, 칼로 무 자르듯 나눠서 얘기할 수는 없다고 생각한다.
각각의 방법에 대해서 조금 더 알아보자
공학적인 측면
Modern Software Engineering: Doing What Works to Build Better Software Faster에서 David Farley는 공학적인 측면에 대해서 자세히 다룬다.
특히
- 과학적 접근법
- 복잡성을 다루는 기술
- 점진적 접근법
- 반복적 접근법
등에 대해서 자세히 다루는데 거대하고 복잡한 소프트웨어를 다루는데 필요한 과학/공학적 지식에 대해서 잘 알려준다.
이 책에서 개인적으로 가장 와닿은 부분은 과학적 접근법과 복잡성을 다루는 기술이었다.
과학적 접근법
Characterize(특징화): 현재 상태를 관찰
Hypothesize(가설): 당신의 관찰을 설명할 수 있는 서술, 이론을 만듦.
Predict(예측): 가설을 기반으로 예측
Experiment(실험): 예측을 테스트
가설의 형태로 추측 → 몇 가지 예측을 시작 → 그 예측을 확인하는 방법을 찾으려고 노력함
위와 같은 과정을 거친다. 학교 때 과학 실험을 할 때 배웠던 그런 절차이다.
이 방법은 의도한다는 점에서 매우 중요한 것 같다. 문제를 어찌어찌하다 보니 풀게 되는 경우는 동일한 문제를 다시 만나도 제대로 풀기 어려울 수 있다. 하지만 위와 같이 상태를 관찰하여 가정을 세우고 실험을 통해 틀린 부분을 제거해 나가는 접근법은 실험 전에 의도가 있었기에 동일한 문제에 동일한 해결책을 시도할 수 있는 강점이 있다.
고등학교 때 어떤 수학 문제를 만났을 때 어찌어찌 답안을 참조하며 문제를 풀면 빨리 풀 수는 있어도 그 문제가 시험에 나오면 다시 틀렸던 경험이 있다. 이 경우 다시 처음부터 자신의 몸에 익도록 원리를 이해해 가며 푸는 연습을 해야만 그 문제가 다시 나왔을 때 잘 풀 수 있었다.
소프트웨어 개발에서 문제를 해결할 때도 마찬가지이다. 어떤 문제를 만났을 때 무엇이 해결책인지는 모르겠지만 이리저리 해 보니 문제가 풀린 경우가 있다(이런 경우를 과학적 접근법의 반대 경우로 우연에 의한 프로그래밍 Programming by Coincedence라고 함). 당장은 문제 해결이 시급하겠지만 반드시 후에 문제를 처음으로 돌려놓고 과학적 접근법에 기반해서 해결책을 찾아봐야 한다.
지금까지 설명한 접근법은 학교에서 많이 배우고, 연습할 수 있었다. 특히 대학에서 전산 관련 학과를 공부한 분들이라면 전공과목 과제를 풀 때 이런 접근을 많이 했던 것이 기억이 날 것이다(다른 전공 수업에서도 유사한 과정이 있을 것이라고 생각함). 합리적, 논리적 사고에 기반해서 가정을 세우고, 실험을 해서 다음에도 동일한 문제는 이 방법으로 해결할 수 있다는 것을 보이는 경험말이다.
공학적인 측면은 경험적인 부분도 있지만 지식적 측면이 강한 것 같다. 그래서 학교에서 다양한 전공과목을 공부한 것이 도움이 많이 되는 것 같다.
그럼 실제 개발자의 삶은 어떨까? 서비스 개발자들은 구현하고 배포하면 그때부터 80% 이상의 업무가 시작된다. 즉 최초 개발해서 배포할 때까지의 비용은 20%가 안 되고, 이후 운영을 하면서 기능을 추가하고, 기존 기능을 변경 등의 운영 업무가 80% 이상을 차지한다. 이런 부분은 대학교에서 교수님들에게 배우기 어렵다고 생각한다. 교수들의 대부분은 서비스를 운영해 본 경험이 없으실 것이기 때문이다.
공예적인 측면
소프트웨어 장인정신을 강조하는 분들은 소프트웨어 개발의 공예적인 측면을 많이 강조한다.
운영을 하다 보면 공예적인 측면이 많이 필요하다고 느끼는 것 같다. 책에서 답을 찾을 수 없는 경우가 많은데 함께 일하는 동료 개발자들에게서 배우는 경우가 많기 때문이다.
게다가 요즘은 개발자들의 업무가 예전과 많이 달라졌다고 생각한다. 내가 처음 서비스 개발을 할 때는 OS(Unix, Linux 등), WAS, Web Server. DB Server 등을 직접 설치하고, 설정을 했었다. 또 그때는 자체 IDC를 가지고 있는 Daum, 네이버 등의 사업자들이 서비스를 하기에 매우 유리했었다.
그런데 지금은 어떤가? 퍼블릭 클라우드에서 클릭을 하면 내가 원하는 세팅이 된 서버를 쉽게 구축할 수 있다(나는 잘 못한다. 하지만 우리 조직엔 잘하는 분들이 많다). 그리고 spring만 하더라도 spring-boot가 나오기 전에는 제대로 설정을 하여 원하는 기능을 사용하기 위해 알아야 할 것이 정말 많았다. 하지만 지금 Spring Initializr 에서 원하는 모듈을 선택하면 쉽게 설정이 완료된 프로젝트를 다운로드하여서 사용할 수 있다.
진입 장벽이 엄청나게 낮아졌다. 개발자도 그만큼 많아졌다. 특히 코로나 이후 자본이 온라인으로 몰리면서 개발자가 엄청 늘었다고 생각한다. 하지만 개발자 역량은 다소 낮아지지 않았나 싶다.
예전엔 신규 입사자(학교를 갖 졸업한 신입이 아닌 경력이 있는)가 입사를 하면 위키 주소 알려주면 알아서 적응하고, 이후에 일을 할당했었는다. 꽤 많은 신규 입사자들이 이런 방식에서도 빠르고 적응하고 성과를 냈었다.
요즘은 이 방식보다는 짝프로그래밍이나 몹프로그래밍을 통해 알려주는 것이 훨씬 빠르고, 효과적으로 온보딩하는데 도움이 된다고 생각한다. 즉 공예적인 측면, 경험적인 측면이 더 필요해진 것 같다.
개발자는 더 많이 필요해지고 있고, 환경이 좋아진 만큼 빠르게 개발을 해야 하는 분위기에서 알아서 하라고 던져주기보다는 같이하면서 빠르게 온보딩시키는 게 맞다고 생각한다. 게다가 신규 입사자들이 어려워하는 것은 개발 자체가 아니라 배포, 배포 후 검증, CS 대응 등인데 이런 업무는 함께 일하지 않고는 배우기 어려운 영역이기 때문이다.
과학자들은
예전에 어느 글에서 과학자들은 자신이 고안한 이론이 맞다고 확신하는데 2시간이 되는데, 다른 과학자들을 설득하는 데는 98시간이 걸린다는 글을 본 적이 있다. GPT에서 물어보니
알버트 아인슈타인의 "The World As I See It"에는 다음과 같은 문구가 있습니다:
"I believe that a scientist looking at nonscientific problems is just as dumb as the next guy—and when he talks about a nonscientific matter, he sounds as naive as anyone untrained in the matter. Since our customary way of thinking does not help us to understand the strange things about atoms, we have to develop new skills. It is just as difficult to explain to a physicist the errors he has made in nonscientific matters as it is to explain to any nonscientist the intricacies of physics. Thus, he is unable to engage in a conversation about the finer points of life. Since he cannot communicate with the layman, he must be content to stay within his field. He has his work cut out for him, however. If he is not careful, he will spend the rest of his life trying to prove what he knows to be true. In science, we only have two hours to convince ourselves that a theory is true; the remaining 98 hours are spent convincing everyone else."
라고 대답을 하는데 진실인지는 모르겠다.
우리가 작성하는 코드의 목적은 컴퓨터에게 우리가 원하는 일을 시키는 것이 첫 번째 목적이다. 하지만 그것 외에 함께 일하는 동료들에게 내 코드의 의도를 이해시키는 것도 우리 코드의 목적이다.
이때 내 코드가 이론적 바탕이 있다면 쉽게 내 의도를 설명하거나 설득할 수 있다. 예를 들어 템플릿 메서드 패턴을 적용하기 좋은 코드에 템플릿 메서드 패턴을 적용했다고 하면 이 패턴을 아는 다른 동료 개발자들은 쉽게 이해할 수 있을 것이다. 개발자들도 과학자들처럼 우리 동료 개발자들을 설득(?) 하기 위해 노력을 해야 한다.
이론과 경험이 조화를 이뤄야
결국 이론과 경험이 조화를 이뤄야 한다는 것이 내 결론이다.
경험적인 부분이 반드시 필요하지만 이론적 성장과 동반되었을 때 둘의 시너지가 폭발적으로 증가한다.
책을 보다가 어느 부분에서 "아하"하는 지점이 종종 있다. 과거의 경험으로 의문이 있었던 부분에 대해서 답을 제공하는 영역을 만났을 때이다. 이럴 때 "왜 내가 이 책을 이제야 봤을까? 미리 봤더라면 그때 그 문제를 쉽게 풀 수 있었을 텐데..."라는 생각이 든다. 하지만 내가 "아하"할 때 종종 그 책을 그전에도 읽었던 적이 있다(그 책에서 설명하고 있는 해결책이 필요했던 문제를 만나기 전에). 적어도 내게는 문제를 만나서 어려움을 겪고 난 후에 책에서 답을 찾는 게 효과적인 것 같다. 책을 미리 보는 것은 도움이 될 수는 있지만 문제를 먼저 겪었을 때만큼 효과적이지는 않았던 것 같다.
나중에도 개발자로 살고 싶다
내가 1on1 등을 통해 개발자들과 면담을 하면 대개 나중에도 개발자로 살고 싶다고들 한다.
나이가 많아져도 개발자들과 밀접하게 어울리며 개발 업무를 하려면 경력에 맞게 잘해야 한다고 생각한다. 경력이 많다고 개발 자체를 얼마나 잘하겠는가? 적어도 나는 내 경력만큼 잘하지는 못한다.
그럼 어떻게 해야 할까? 내 경우는 규모를 늘리는 것이었다.
- 주니어 때는 나 혼자 잘하고,
- 팀장이 되었을 때는 나뿐 아니라 팀원들(10여 명)이 잘하도록 도우며 잘하고,
- 본부장이 되었을 때는 수백 명(200~300여 명)에 달하는 구성원들이 잘하도록 도무여 잘하고,
이런 규모로서 기여를 하려고 노력을 했었다.
다행히 팀원, 팀장을 거친 개발자로서 나의 경험이 구성원들과 공감대를 쌓기에 유리했었던 것 같다.
(본부장/임원 급이 되었을 때는 개발자들과 업무를 잘하는 것 외에 회사를 위해 다른 기여도 해야 했지만 그건 이 글에서는 제외한다)
아마 내 경우처럼 규모가 아니라 다른 영역에서 시니어 개발자/리더로서 가치를 찾을 수도 있을 것이다.
오늘은 경험주의에 대해서 갑자기 생각이 나서 글을 정리해 봤다.
