개발자 하루살기 의미를 알아보겠습니다. 이등병 때 싫어하는 고참이 있었습니다. 언젠가 같이 보초를 설 때였습니다. 고참은 제대 날짜가 가까워서인지 제게 이런저런 이야기를 해주었습니다. 앞으로 군생활할 때 어떤 마음으로 해야 하는지 알려주었습니다. 그 중에 가장 기억이 남는 말은 “전역 날짜 세지 말고 그냥 오늘만 잘 살아라.”라는 문구였습니다. 이 말은 아직도 어떤 일로 힘이 들 때 늘 기억하는 말입니다. 그리고 버틸 힘을 줍니다. 이제 개발자 하루살기에 대해 이야기해보겠습니다.
그러므로 내일 일을 위하여 생각하지 말라. 내일 일은 내일이 생각할 것이요, 한날의 괴로움은 그날로 족하니라 – 성경 마태복음 6:34
목차
Toggle개발자 하루살기 중요성
오늘 하루의 중요성을 강조하는 현인들의 이야기는 많습니다. 미국의 유명한 감독인 론 하워드는 “절대 어제를 후회하지 마라 인생은 오늘의 나 안에 있고, 내일은 스스로 만드는 것이다.”라고 말했습니다. 또한 미국의 저술가인 앨버트 허버드는 “내일 일을 훌륭하게 완수하기 위한 최선의 준비는 오늘 일을 훌륭하게 완수하는 것이다.” 라며 오늘에 최선을 다하는 것이 미래를 준비하는 최선의 길임을 강조했습니다. 데일 카네기의 자기관리론에서는 아래와 같은 말이 있습니다.
“내일을 맞이하는 최선의 방법은 모든 능력을 집중해 오늘 해야 할 일을 잘 하는 데 있다. 당연히 내일에 대해 생각해야 한다. 세심하게 생각하고, 계획하고 대비해야 한다. 하지만 걱정해서는 안 된다.”
오늘이란 시간은 결코 다시 오지 않습니다. 어제의 시간은 이미 지나갔고 내일이란 시간도 오직 한 번 옵니다. 그래서 개발자 하루살기가 중요합니다. 괴테는 행복의 다섯 가지 원칙에 대해 이렇게 말했습니다.
“행복의 다섯 가지 원칙, 첫째, 지난 일에 연연하지 않을 것, 둘째, 미워하지 않을 것, 셋째, 사소한 일에 화내지 않을 것, 넷째, 현재를 즐길 것, 다섯째, 내일은 신에게 맡길 것” 어느 것 하나 쉬운 게 없습니다. 하지만 현재를 즐기는 것은 오늘을 열심히 사는 것이고 내일을 신에게 맡기라는 말은 카네기의 말처럼 걱정하지 말라는 의미입니다.
“성공은 하루하루 반복해서 쏟는 작은 노력들의 총합이다.” – 로버트 콜리어
“성공을 위해 치러야 하는 대가는 당면한 일에 몰두하는 피나는 노력, 그리고 승패와 상관없이 그 일에 최선을 다했다는 확신이다.” – 빈스 롬바르디
- 이렇게 개발자 하루살기를 잘 수행하면 원하는 목표에 이를 수 있습니다.
개발자 하루살기 3가지
1. 자기 일처럼 하기
- 개발자에게 오늘 하루를 산다는 의미는 무엇일까요? 그것은 어떤 일이든 자기 일처럼 하는 것입니다. 이 말은 쉽지 않습니다. 회사의 비전, 상사의 도덕성, 같이 일하는 동료들의 모든 것들이 개발을 자기 일처럼 하는 것을 방해합니다. 일정을 무리하게 세워 철야 및 주말 출근을 강요한다던가, 과정은 무시한 채 일의 결과만 보고 질타하는 것, 동료의 까칠한 언행, 상사의 방관 등이 개발자의 사기를 저하시킵니다. 이런 일들이 지속되다 보면 코드 품질은 현저히 떨어지게 마련입니다. 임시방편 코드로 긴박한 상황만 모면하는 결과물들이 모여 결국 시간은 시간대로 들이고 서비스는 할 수 없는 수준에 이릅니다.
- 경영진들은 돌아가는 결과만 보고 무리하게 사업을 진행하게 됩니다. 정작 서비스가 임박하면 개발자들은 또 날밤을 갈아넣어 일정을 맞추면 잦은 장애로 개발진들은 힘들어 합니다. 이런 일이 반복되면 개발자는 살기 위해 퇴사를 결정합니다. 재고의 여지는 없습니다. 하루 빨리 이 상황에서 모면하는 게 최선이라 생각합니다. 많은 스타트업이 이런 일을 겪습니다.
- 경영진은 시간을 주었음에도 서비스 품질의 제품은 나오지 않고 개발진은 무리한 일정으로 시연만 가능한 서비스가 나올 수 밖에 없다고 불평합니다. 이런 겹이 좁혀지지 않으면 원하는 서비스를 만들 수 없습니다. 개발자들만 길게는 1년이나 반년 만에 교체되어 나갈 뿐입니다. 하나의 제품을 만들 때 제작자가 바뀐다는 것은 큰 위험요소입니다. 실력이 부족해 교체하는 것은 당연하지만 실력있는 개발자가 잘못된 개발 프로세스 안에서 괴로워하다 나가는 것은 심각한 문제입니다. 내부 개발문화를 바꾸는 것 밖엔 답이 없습니다. 하지만 이게 현실적으로 가능할까요? 경영진의 입장에서 생각해보겠습니다.
2. 일정 확고히 하기
- 스타트업은 새로운 서비스를 만들어 고객을 확보해야 합니다. 그 고객이 일반 사용자일 수도 있고 대형 클라이언트일 수도 있습니다. 사업모델을 검증하는 측면에서는 고객들에게 많은 시연을 거치고 그 니즈를 확인해야 합니다. 기획팀이 심사숙고한 제품기획서를 가지고 개발팀이 서비스를 개발하고 있다고 가정하겠습니다. 사업팀은 해당 서비스를 이미 고객들에게 홍보하고 있습니다. 고객이 지금 겪고 있는 문제를 해결할 수 있는 서비스라면 언제 제품을 사용해 볼 수 있는지 문의합니다. 사업팀은 이미 만들어져 있는 서비스를 홍보하고 있고 개발팀은 이 서비스를 한창 개발하고 있습니다. 고객사는 이미 만들어져 있는 서비스라 빠른 시일 내에 눈으로 확인해보고 싶습니다. 그리고 고객이 특별히 원하는 요구사항들이 있습니다.
- 한두 달 이내의 기간과 새로운 요구사항 때문에 기존의 개발 계획은 백지화됩니다. 이 때부터 짧은 일정 내에 요구사항들 개발해야 합니다. 그러다보니 개발팀은 클라이언트 시연에 초점을 맞추어 시연용으로 개발할 수 밖에 없습니다. 이것은 과연 누구의 잘못일까요? 스타트업은 하루빨리 고객을 확보해서 살아남아야 하고 개발팀은 안정적인 서비스를 만들기 위해서는 시간이 필요합니다. 참 어려운 문제입니다. 하지만 결국 이것은 회사의 재정적인 능력과 관련되어 있습니다. 재정이 풍부한 회사는 일정과 인력 투입에 여유가 있습니다. 하지만 그렇지 않은 회사는 살기 위해 어쩔 수 없이 압박을 받을 수 밖에 없습니다. 이런 상황에서 개발자들은 어떻게 해야 할까요? 어디가든 일정은 빡빡하기 나름입니다.
3. 보고 명확히 하기
- 이 때 개발자는 보고체계를 명확히 해야 합니다. 일정을 보다 상세하게 세워서 시연용 개발과 서비스 개발을 분리해야 합니다. 그리고 경영진을 설득해야 합니다. 기능개발을 한다라고만 이야기하면 경영진들은 그 때 제품 개발이 마무리된다는 것으로 인식합니다. 백엔드 개발이라면 해당 기능을 구현하는 것과 안정화한다는 것은 다른 이야기입니다. 백엔드는 많은 요청과 고려해야할 변수들이 많이 있습니다. 그것들을 고려해서 개발하지 않으면 서비스는 불가능합니다.
- 자기 일처럼 한다는 것은 일을 단순히 열심히 한다는 것을 의미하지 않습니다. 일정 산출, 그에 따른 위험을 보고하고 어떤 것을 선택했을 때 얻을 것과 잃을 것을 확인해야 합니다. 또한 번아웃이 오지 않게 자신을 관리할 능력도 필요합니다. 번아웃이 오면 개발자를 지속해야 할 지 회의가 올 수도 있습니다. 개발의 탈진으로 개발을 그만두는 사례도 많이 있습니다. 저 또한 그런 경험들이 있습니다. 하루를 잘 살기는 어렵습니다. 어쩌면 하루를 버틴다는 의미가 맞을 수도 있습니다.
개발자 하루살기 정리
하루를 열심히 사는 것은 중요합니다. 개발자 하루살기는 현명하게 내일을 위해 사는 것이 핵심입니다. 개발자의 번아웃을 경계하십시요. 이것은 여러 이유로 서서히 다가올 수 있습니다.
개발자 하루살기 참고 자료
도서 추천 : 일을 잘 맡기는 기술