거의 다 만들었어요.

"거의 다 만들어서 2주후에 개발이 끝나요"

이 말을 이해할 수 있는가? 우리 주변에서 소프트웨어를 개발할 때 흔히 들을 수 있는 말이다.

개발자들도 이렇게 얘기하고 관리자나 경영자도 대충 알아듣는다.

하지만 이런 대화는 여러 오해를 양산한다.

영업 담당자는 2주후면 고객에게 소프트웨어를 제공할 수 있는 것으로 착각하기도 하고, 경험이 좀 있는 관리자는 아직 충분히 안정적이지 않거나 테스트가 남아 있다는 것도 알기도 한다. 하지만 정확하게 언제 고객이 쓸 수 있는 제품이 나오는지는 알 수가 없다.

그래서 우리는 좀더 전문적으로 제대로된 용어를 사용해서 커뮤니케이션을 할 필요가 있다.

우선 개발 단계별로 정확한 용어를 사용하는 것이 필요하다.

"개발"이라는 말은 너무나 모호하다. 사실 스펙을 쓰는 일부터 유지보수 까지 모두 개발이다.

그래서 분석/설계/구현/테스트 등 단계별로 세분화된 단어를 쓰는 것이 좋다.

따라서 "개발이 끝나요"보다는 "구현이 끝나요"가 좋다.

그 다음에는 개발팀에서 만들어내는 버전이 어느 정도 수준인지 표현할 필요가 있다. 내부 테스트를 진행할 수 있는 수준인지 필드테스트를 할 수 있는 수준인지 알려줘야 한다.

일반적으로 이런 수준을 표시하는 용어는 많이들 들어봤겠지만, 알파/베타/RC 등이 있다.

알파버전이란 모든 기능의 구현이 완료되었고 버그는 많지만 Show stopper가 없는 수준을 말한다. 주변에서 "개발이 다 됐어요"라고 말할 때도 자세히 살펴보면 알파 수준도 안되는 경우 많다. 기능이 99% 완료 되었으면 알파가 아닌 것이다. 예를 들어 설치 프로그램은 아직 개발을 안했다던지 간단한 기능의 일부가 미 구현상태면 알파가 아닌 것이다. 

따라서, 미국이나 인도나 어디에서도 알파버전이라고 하면 이 수준으로 이해를 하면 된다. 

그리고 알파버전 테스트에서 발견된 버그를 대폭 수정해서 버그를 많이 줄인 버전을 베타버전이라고 한다. 베타버전은 내부테스트를 하기도 하고 고객을 대상으로 외부 테스트를 하기도 한다. 베타버전은 버그는 있지만 꽤 쓸만한 버전이다.

RC버전은 Release Candidate의 약자로 테스트를 해보고 출시를 결정할 후보 버전이다. 따라서 대부분의 경우 아주 안정적이다. 출시가 결정되면 바로 고객이 사용하는 버전이다. 물론 버그가 없는 것은 아니지만 충분히 안정적이다.

따라서 알파/베타/RC등의 용어를 적절하게 사용해서 개발팀에서 만들어낸 버전이 정확하게 어느 정도 수준인지 전달을 해야 한다.

"2주후에 개발이 끝나요"보다는 "2주후에 알파버전 구현이 끝나요"가 좋다.

좀더 자세히 말하면 "2주후 금요일 오후3시 정각에 알파버전 소스코드 프리즈가 있습니다."라고 하면 좀더 정확한 의미가 전달된다.

개발자들은 3시까지 모든 소스코드를 Commit해야 하고,

빌드팀은 3시가되면 소스코드를 내려받아서 빌드를 하고

테스트팀은 3시쯤 되면 알파테스트를 시작할 준비를 하고 기다리고 있을 것이다.

관리자나 경영자는 당연히 테스트 일정을 알고 있고 언제 출시 예정인지 알고 있다.

이슈관리시스템을 보고 있으면 거의 실시간으로 발견되는 버그와 고쳐지는 버그의 현황을 볼 수 있다. 

하지만 아직도 대부분의 개발 현장에서는 이런식으로 커뮤니케이션이 이루어지지 않고 있는 것이 현실이다. 

알파/베타 등의 용어를 들어봤거나 사용하고 있어도 그 의미를 정확하게 사용하지 않고 있는 경우가 많고 개발자와 영어/관리자/경영자가 그 의미를 똑같이 공유하고 있는 않다. 서로 다르게 생각하고 있으면 커뮤니케이션에 문제가 자주 생긴다.

세계적으로 표준으로 사용하는 용어들이니 표준에 맞게 사용하고 모든 직원이 똑같이 공유를 해야 한다.

그래야 좀더 합리적인 일정으로 개발이 진행된다. 

고쳤으니 테스트 해주세요.

여기 두가지 테스트 방법이 있다. 우리 회사는 어떤 방법을 사용하고 있나 생각해보자.

첫째, 테스트 도중에 버그를 고쳐서 좀더 안정된 버전을 테스트팀에 계속 전달하는 방식이다.

테스트 한사이클을 도는데 2주일이 걸린다고 생각해보자. 테스트 기간내내 테스트 팀은 버그를 지속적으로 발견하여 보고를 할 것이다. 개발팀은 동시에 버그를 수정한다. 그리고 다음날 개발팀은 테스트팀이 보고한 버그를 많이 수정한 새버전을 테스트팀에 전달한다. 

테스트 팀은 새버전을 가지고 어제 테스트한 시점의 다음 단계부터 또 테스트를 진행한다. 이렇게 테스트 기간 내내 여러번 새버전을 받는다.

두번째 방법은 다음과 같다. 테스트가 2주가 걸리면 2주 동안 테스트 팀은 새버전을 절대로 받지 않고 한 버전을 가지고 테스트를 완전히 종료한다. 개발팀은 버그를 계속 고치지만 새 버전을 테스트 팀에 전달하지 않는다.

어느 방법이 더 효율적으로 보이는가? 많은 회사들이 첫번째 방법을 사용하고 있다. 믿기 어렵겠지만 사실이다. 첫번째 방법은 큰 문제가 있다. 테스트 기간 도중에 테스트 팀이 새로운 버전을 받으면 이전에 테스트 한 내용이 무효가 된다. 여기서는 그걸 무시하고 계속 테스트를 했기 때문에 테스트가 끝나도 끝난 것이 아니다.

그럼에도 첫번째 방법을 사용하는 이유는 있다. 도저히 테스트 할 수 없을 만큼 불안정한 제품을 테스트 해달라고 전달한 경우이다. 그래서 테스트 팀과 적당히 테스트를 하면서 차츰 안정화를 시켜가는 것이다. 이런 품질의 제품은 테스트를 할 필요가 없다. 이 경우는 테스트 팀을 개발팀의 딱까리로 생각하는 것이다. 

원래 테스트를 진행할 수 없을 정도의 제품을 테스트팀이 받으면 테스트를 중단하고 개발팀으로 다시 돌려보내야 한다.

이렇게 비효율적인 테스트가 우리 주변에서 흔히 벌어지는 이유의 원인 따지고 들어가면 앞단계인 분석과 설계가 엉망이거나 없기 때문인 경우가 많다. 

제품의 품질을 유지하기 위해서는 분석/설계도 중요하고 전문적인 테스트를 해야 한다. 대충 개발하고 테스트팀이 개발팀을 도와주는 형태로는 평생 주먹구구식 개발에서 못벗어나고 비용과 시간도 많이 들뿐만 아니라 개발팀은 잦은 야근에서 벗어나기도 어렵다.

앞으로 테스트에 관한 얘기를 좀더 쉽게 풀어서 써보도록 하겠다.

인해전술이 오히려 프로젝트를 망친다.

일정이 촉박하다고 프로젝트를 빨리 끝내고 싶은 마음에 프로젝트 초기부터 대거 인력을 투입하면 오히려 프로젝트를 망칠 가능성이 더 높아진다.

프로젝트 초기에 분석/설계 단계에는 그렇게 많은 인력이 필요하지 않다.

많은 인력을 분석도 안된 프로젝트에 투입을 하면 놀 수 없는 개발자들이 인터페이스도 정의가 안된 모듈이나 라이브러리를 만들기 시작한다. 이것들 중 대부분은 나중에 다시 만들어야 하고, 이것들을 버리기 아까워서 어떻게든 활용하려고 버티다보면 소프트웨어의 아키텍처가 점점 이상하게 된다.

많은 인력이 투입되는 단계는 구현단계이며 핵심 구현 인력들이 분석/설계 단계에 리뷰어로 참석할 수는 있다.  일정이 촉박하면 분석/설계를 최대한 빨리 끝내고 할일의 범위와 아키텍처를 명확히 한 후에 인력을 투입해야 한다.

필요한 라이브러리를 개발하지 말고 상용라이브러리를 구매하는 것도 일정을 단축하는데 도움이 된다.

가장 안좋은 방법이 프로젝트 초기에 시장통처럼 개발자를 잔뜩 투입하는 것이다. 소프트웨어 개발을 잘 모르는 경영자들이 이런 실수를 종종 하곤 한다.

우리 주변에서 1년짜리 프로젝트인데 10명의 개발자가 투입되면 10명이 12달동안 계속 같이 일하는 경우를 흔히 볼 수 있다. 이렇게 일정 투입 계획이나 현황만 보아도 개발이 얼마나 주먹구구식으로 진행되고 있는지 알 수 있다. 10명의 개발자가 투입되는 프로젝트도 초기 2,3개월 또는 3,4개월동안은 분석/설계를 담당하는 1,2명만 필요하다. 이 프로젝트에서 분석/설계를 담당한 엔지니어는 많은 개발자가 투입되는 구현기간에 같이 구현에 참여할 수도 있고 다른 프로젝트에서 또다시 분석이나 설계를 담당할 수 있다.

이렇게 인력이 효율적으로 순환이 되면 훨씬 적은 인력과 비용으로 많은 프로젝트를 효과적으로 진행할 수 있게 된다.

인해전술로 많은 인력을 투입하는 방법은 해당 프로젝트를 망치는 방법일 뿐만아니라 회사 전체적으로 효율적인 인력운영을 할 수 없게 만든다. 

1:10:100 rule

소프트웨어를 개발하는데 있어서 꼭 알아야 할 규칙이 하나 있다. 바로 "1:10:100 rule"이다.

성숙한 개발문화를 가지고 있는 회사는 전 직원들이 진정으로 그 의미를 알고 있고 실행하고 있다. 하지만 우리나라의 크고 작은 대부분의 소프트웨어 회사 임직원들은 그 의미를 모르거나 알고 있어도 단어의 의미로만 알고 있고 진정으로 깨우치고 있지는 못하다.

소프트웨어를 개발하면서 발생하는 많은 비효율과 문제들이 바로 여기서 출발하는 것이다.

그 1:10:100 rule을 설명한 그래프가 아래에 있다.

요구사항이 스펙을 작성하면서 바뀌면 "1"이라는 비용이 들지만 고객에게 전달된 다음에 바뀌면 "368"배의 비용이 들어간다.

요구사항이든 설계든 한단계 뒤에서 고치게 될 경우 2~5배의 비용이 들어가서 시간이 흐를수록 비용은 기하급수로 증가를 한다.

따라서 기획이 제대로 되어야 하고 분석 설계가 적절하게 잘되어야 하며 한창 개발중에 기획이 바뀌거나 요구사항이 바뀌면 그 수정 비용은 엄청나다는 것을 알야 한다.

말은 쉽지만 이를 진정으로 꺠닫고 실천하는 회사나 개발자를 만나는 것은 쉬운 일이 아니다. 

사실 개발자들은 기획에서 정확한 요구사항을 주지 않는 다거나 나중에 요구사항을 바꾼다고 불평이 많다. 하지만 많은 경우 불평은 하지만 그것을 현실로 받아들이고 스스로 이를 개선하려는 노력은 별로 하지 않는다. 오히려 상황이 그러니 분석, 설계를 제대로 하지 않고 대충 개발하다가 나중에 바꿔달라고 하면 또 대충 받아들여서 개발하고 이런 악순환을 반복하곤 한다.

이런 것을 극복하기 위해서 여러 방법론이 나오기도 하고 최근에는 Agile이 각광을 받고 있지만, 이런 방법론이나 기법으로는 이를 해결할 수는 없다. 정공법외에는 방법이 없다. 기획을 제대로 하고 분석 설계를 효율적이고 적절하게 하는 것이다. 또한 그 과정에서 모든 관련자가 책임을 지고 검토를 해서 문제가 없게 해야 하면 나중에 딴소리를 하거나 바꿔달라고 하면 안된다. 정말 중요한 변경 요청이 아니면 다음 버전으로 미루는 것이 좋은 전략이다.

전 임직원이 1:10:100 rule을 진정으로 깨닫고 있다면 글로벌 소프트웨어 회사가 될 수 있는 잠재력이 충분히 있다고 할 수 있다.

티끌모아 태산 (개발 시간 절약하기)

성숙된 개발문화를 가지고 있는 회사는 개발 절차가 아주 효율적으로 진행된다.

하지만 그렇지 않은 회사들은 불필요하게 낭비하는 시간이 아주 많다. 10초에서 몇십분까지 자잘한 시간을 낭비해서 이것들을 합치면 어마어마한 시간이 낭비된다.

시간을 꼭 사용해야 할 중요한 곳에는 아끼지 말고 시간을 써야 한다. 하지만 자동화를 하거나 시스템이 커버를 할 수 있는데 사람이 반복적으로 하고 있거나 과도한 안전장치를 갖춘 프로세스로 인해서 비효율적으로 시간을 낭비하는 경우가 정말로 많다.

10초, 1분이라고 별것 아닐 것 같은 시간이 모이면 생산성은 10%, 20%, 50% 떨어지게 된다.

소프트웨어 개발은 워낙 복잡하기 때문에 이렇게 10초, 1분씩 낭비되는 시간을 최대한 제거해 나가면서 개발을 지속적으로 효율적으로 발전시켜나가는 노력이 필요하다.

회사마다 여건이 조금씩 다르지만 몇가지 예를 들어보겠다.

10초라도 낭비하면 아까운 시간들이다.

• 빌드가 완전 자동화가 되어 있지 않아서 소스코드를 빌드할 때마다 약간이나마 중간에 수작업이 들어가는 시간 - 빌드는 완전 자동화를 구현해야 한다. 당연히 Command line으로 빌드가 되어야 하고 한번의 Enter로 최종 설치본까지 생성이 되어야 한다.
• 이슈(버그)관리시스템을 잘 관리해보고자 너무 많은 커스텀필드를 넣어서 이슈(버그)를 등록할 때마다 몇초씩 더 걸리는 시간 - 적당한 커스트마이징은 필요하지만 과도함은 삼가해야 한다.
• 이슈관리시스템이 있는데 보고나 관리를 위해서 별도의 자료를 만드는 시간 - 이슈관리시스템을 이용하면 원하는 View로 원하는 정보를 실시간으로 볼 수 있다. 관리자도 보고를 기다리지말고 직접 이슈관리시스템을 봐야 한다.
• 여러벌의 Branch에 같이 존재하는 버그를 동시에 고치기 위해서 수작업을 할 때 - SCM의 Merge기능을 믿지 못하거나 기능을 활용할 줄 몰라서 수동으로 Merge를 하는 행위는 정말 시간 낭비이다. 제대로만 사용한다면 SCM의 Merge기능은 막강하고 99.9% 믿을만하다. 수작업이 아니고 최종적인 확인 정도만 해도 되는 경우가 대부분이다.
• 개발자들의 주간 보고서 작성하기 - 이부분은 약간 논란의 이슈가 있다. 정말 간단한 주간보고서는 큰 무리가 없지만 부담스러울 정도의 주간보고서는 개발자들이 작성하지 않는 것이 좋다. 개발자들의 업무 기록은 이슈관리시스템 등에 다 남아 있다. 관리자는 개발자를 괴롭히지 말고 스스로 시스템을 보면 된다. 물론 기반시스템들이 잘 구축되어 있어야 한다.

이 외에도 코딩시 일반 업무시 절약할 수 있는 시간음 무궁무진하다. 이런 시간을 꾸준히 찾아서 제거해 나가는 노력이 필요하다.

재택근무가 가능한가?

우리 주변에는 비효율적인 개발 환경을 가지고 있는 회사들이 매우 많다. 상상외로 많다. 

스스로의 회사는 어떤가 생각해 보자. 나름대로 효율적인 개발문화를 가지려고 많은 노력을 해왔을 것이다. 그래서 과연 우리회사가 제대로 효율적인 개발문화와 환경을 가지고 있는지 궁금할 것이다.

이렇게 비교를 해보자. 당장 우리 회사의 개발자들이 모두 재택근무를 하면 어떻게 될까? 그리고 일주일에 딱 하루만 회사에 나와서 필요한 회의를 한다면...

대부분은 그렇게 해서는 회사가 돌아가지 않을 것이라고 생각할 것이다. 

그렇다면 아직 먼 것이다. 소프트웨어 회사가 효율적인 프로세스와 시스템을 갖추고 개발 역량과 성숙한 개발문화를 갖추고 있다면 얼굴보고 해야 할 일이 그렇게 많지가 않다. 일주일에 몇시간이면 충분하다.

일단 회의가 너무 많은가? 회의는 정말 비효율적이다. 꼭 필요한 회의가 아니면 대부분의 회의는 시간을 비효율적으로 사용하며 많은 인원의 시간을 한꺼번에 소비한다. 대분은 시스템으로 커버가 가능하다.

개발할 때마다 얼굴을 보고 설명을 해줘야 하는가? 주먹구구식 개발의 대표적인 현상이다. 효율적으로 작성된 SRS가 있다면 설명해줘야 하는 시간은 수십분의 일로 줄어든다. 줄어들어야 제대로 작성된 SRS이다.

수시로 물어봐야 해서 항상 자리에 붙어 있어야 하는가? 성숙한 개발 환경에서는 프로세스, 시스템, 문서등이 이를 대신한다. 

실제 이런 경험이 있는 않은 경우라면 즉, 기존의 적당한 주먹구구와 공력에 의해 개발을 했거나 비효율적인 프로세스를 적용해서 나쁜 기억만 가지고 있는 경우라면 이렇게 개발하는 것이 더 비효율적인 것이 아니냐고 반문을 하곤한다. 그렇게 하려면 문서를 너무 많이 적어야 하는 것이 아닌가? 프로세스나 시스템이 오히려 더 거추장스러운 것이 아닌가? 의문을 품을 수 있다.

책이나 인터넷을 보고 프로세스를 따라한 부작용이기도 하다. 태권도장에 가서 직접 태권도를 배우면 금방 되는 것이 책을 보고 배우면 대부분은 제대로 배우지 못하고 효율적이지 못한 것과 비슷하다.

프로세스, 시스템, 문서 모든 것은 개발을 빠르고 효율적으로 하기 위해서 존재하는 것이고 그보다 더 이상 이하여서도 안된다. 이는 제대로된 경험으로만 터득이 가능하다. 따라서 경험자나 전문가의 가이드가 필요한 것이다.

나름대로 개발 환경을 개선하기 위해서 열심히 노력한 경우라도 재택근무가 가능한 수준이 아니라면 아직 갈 길이 멀다는 것을 명심하자.

이제 효율적인 개발에 한발을 내딪였을 뿐이다.

개발자, 회사의 과거인가 미래인가

개발자는 소프트웨어 회사의 가장 중요한 자산이면서 서로 상반된 2가지 가치를 가지고 있다.

첫 번째는 ‘과거의 가치’이고

두 번째는 ‘미래의 가치’이다.

나는 과거의 개발자일까? 미래의 개발자일까? 스스로 판단하기는 어려울 것이다. 동료나 경영진에게 내가 퇴사를 하면 어떻게 될까?라는 질문을 해보면 짐작할 수 있다.

내가 퇴사를 하면 과거에 개발해 놓은 제품들을 어떻게 하지?라는 생각이 가장 먼저 들면 ‘과거의 개발자’에 가깝다.

반대로 내가 퇴사를 하면 과거에 개발해 놓은 제품들은 문제가 없는데 미래에 개발할 제품은 누가 개발하지?라는 생각이 들면 ‘미래의 개발자’라고 볼 수 있다.

회사나 개발자 입장에서 권장되는 개발자 타입은 미래 가치를 많이 지닌 “미래의 개발자”이다. 미래의 개발자가 지금은 가치가 적은데 미래에 가치가 높다는 의미가 아니다. 미래에 가치가 더 있고 시간이 흐를수록 점점 가치가 높아진다는 의미다.

과거의 가치를 더 많이 가지고 있는 ‘과거의 개발자’는 본인이 아니면 유지보수가 어렵게 소프트웨어를 개발해 놓았고, 대부분의 지식이 머리 속에 있기 때문에 동료나 신입개발자와 지식을 공유하기 어렵다. 본인이 의도해서 그렇게 한 것은 아니지만 결과적으로 자신이 과거에 만들어 놓은 소프트웨어를 인질삼아 회사와 인질극을 벌이고 있는 것과 같다.

물론 이런 개발자가 퇴사를 한다고 회사가 망하는 것은 아니지만 적게든 많게든 타격을 입게 되고 심한 경우 회사는 퇴락의 길을 걷기도 한다. 따라서 회사는 이런 개발자에게 질질 끌려 다니곤 한다. 이런 상태의 개발자는 스스로도 상황의 피해자일 뿐이다.

미래의 가치를 가진 ‘미래의 개발자’는 자신이 과거에 만들어 놓은 소프트웨어들은 후배들이 유지보수를 수월하게 할 수 있도록 개발 과정에서 적절히 문서화를 해 놓았고, 아키텍처를 깨끗하게 만들었으며 모든 이슈는 이슈관리시스템에 기록으로 남겨 놓았다. 그리고 Peer review를 통해서 이미 많은 지식을 동료들과 공유를 한 상태다.

이런 합리적인 개발 과정을 통해서 본인은 분석, 설계 능력이 꾸준히 향상되어 왔으며, 회사도 성장에 걸맞게 프로세스와 개발문화가 발전되어 왔다. 유지보수에 허덕이지 않으므로 신기술에 대한 연구에 소홀하지 않아서 미래에는 과거 제품들보다 한 단계 수준 높은 제품을 만들어 낼 것이다.

언뜻 보기에는 과거의 엄청난 폭풍 코딩을 통해서 짧은 시간에 많은 제품을 만들어내는 성과를 낸 ‘과거의 개발자’가 영웅처럼 보이지만 미래의 가치를 지닌 ‘미래의 개발자’가 진정한 영웅이다.

필자는 대기업부터 작은 소기업까지 여러 소프트웨어 회사를 다니면서 개발자와 경영진을 대상으로 소프트웨어 개발에 대해서 강연이나 세미나를 많이 한다. 그럴 때 이런 질문을 하곤 한다.

“오늘 회사를 그만둬도 당장 큰 문제가 발생하지 않는 사람 손들어 보세요”.

“오늘 회사를 그만두면 회사가 당장 큰 일 나는 사람 손들어 보세요”.

이 두 가지 질문 중에서 두 번째 질문에 손을 드는 사람이 상당히 많다. 특히 주변에 특정인을 가리키며 손을 들라고 하는 경우가 많다. 이런 사람은 십중팔구 ‘과거의 개발자’이다.

과거에 엄청나게 많은 일을 해냈지만 대부분은 유지보수에 치여 본인도 발전 못하고 격무에 시달리고 있는 경우이다. 수많은 문제와 이슈는 본인만 알고 있어서 수시로 불려 다니고 정작 본인은 개발할 시간이 없고 발전도 어렵다.

물론 ‘과거의 개발자’양산이 개발자에게 책임이 있는 것은 아니다. 소프트웨어 개발 환경이 회사에서 제공하는 프로세스, 시스템이 열악한 상태에서 전적으로 개발자의 내공에 의존을 하기 때문에 개발자도 어쩔 수 없이 ‘과거의 개발자’가 되어 버리는 것이다.

‘과거의 개발자’가 주도하는 회사는 엄청난 개발자 Risk를 안고 있는 것이다. 뛰어난 개발자가 많지만 이들이 한두 명만 나가도 회사가 휘청대며, 유지보수에 발목을 잡혀서 앞으로 나가기 어려운 상태인 경우가 많다.

회사는 개발자가 개발에 전념할 수 있고 개발 과정에서 꾸준히 성장할 수 있도록 환경을 제공해야 한다. 개발자 경력을 보장하는 것은 물론이고 프로세스와 기반시스템을 제대로 갖추고 개발문화 구축에 제도적인 노력해야 한다. 그렇게 해서 개발자 내공에 의존하는 개발이 아닌 시스템에 의존한 개발이 되어야 한다. 그런 환경에서야 개발자가 최고의 활약을 할 수 있다.

그래야 개발자도 행복하게 개발을 할 수 있고 회사도 개발자 Risk가 줄어든다. 이런 환경에서 성장하는 개발자는 신참때는 주로 코딩을 하지만 고참이 되어 갈수록 설계, 분석에 집중하고 문서를 통한 협업에 능숙해진다. 이런 방법이 개발자와 회사 모두에게 좋은 방법이다.

여전히 개발자의 내공에 의존한 개발 환경을 가진 회사에서 유지보수에 허덕인다고 개발자를 탓하지는 말자. 지금이라도 ‘미래의 개발자’를 위한 환경에 대해서 고민해보자.

책에도 다 있고 이론은 많지만 현실에서 실천이 어려운 것이다. 이론으로는 배울 수 없고 경험에 의해서 밖에 배울 수 없기 때문이다. 책과 이론은 약간의 도움을 줄 뿐이다.

이 글은 Tech it에 기고한 글입니다.