개발팀 운영과 관련된 조언이나 컨설팅 문의가 최근 들어 하나 둘 들어오고 있습니다. 요즘은 캘리포니아쪽에 있는 회사 중 한 곳과 집중적으로 컨퍼런스콜을 진행하면서 조언을 해주고 있습니다.
오늘은 실무 개발자분들과 인터뷰 한 내용들을 정리해보고 왜 이런 질문들이 필요한지 생각을 해보고자 합니다.
오늘 해야 할 일을 어떻게 파악하십니까?
이 질문의 목적은 업무 프로세스가 제대로 구축되어 있는지 확인하기 위한 것입니다. 개발팀에 대한 컨설팅을 할 때 저는 2~3명의 개발자에게 이 질문의 답변을 들었으면 한다고 밝힙니다. 헤더분들이 특정 프로세스를 따른다고 말하더라도 실무 개발자들이 아무런 얘기를 하지 않는다면 그건 부정적인 신호입니다. 개발자들이 서로 다른 얘기를 한다면, 그 또한 부정적인 신호로 볼 수 있습니다.
높은 수준의 팀에서는 이 질문에 대해 일관적인 대답을 들을 수 있습니다. 그것은 모든 개발자가 업무 프로세스를 잘 알고 있으며, 프로세스가 단순해서 개발자들에게 부담되지 않고 도움이 되고 있음을 의미합니다.
좋은 대답의 예는
“우리는 새로운 기능과 버그를 고치기 위한 (몇) 주 단위의 스프린트를 진행하며 매일 서로에게 했던 일을 공유합니다. 우리와 함께 일하는 제품 관리자는 고객 대응에 임하면서 개발자들에게 새 기능과 버그 수정의 우선 순위를 잘 조정해줍니다.”
나쁜 대답의 예는 아래와 같습니다.
“회사에 오면 어떤 문제가 터졌는지 살펴봅니다. 거의 매일 비상사태입니다.”
제가 “스크럼”이나 다른 특정한 방법론을 언급한 것이 아님을 분명히 했으면 좋겠습니다. 저는 회사가 사용하는 개발 프로세스의 이름에는 관심이 없으며 그들이 매일 매일 “어떻게 업무를 진행하는지”를 더 중요하게 생각합니다.
버전 관리 도구로는 무엇을 사용합니까?
좋은 도구의 사용은 좋은 팀의 지표가 됩니다. 어떤 팀이 구시대적인 버전 관리 도구를 사용하고 있다면, 아마 그것 말고도 철 지난 도구를 많이 사용하고 있을 것입니다. 게다가 그들은 좋은 도구를 사용함으로써 얻는 효율을 그다지 중요하게 여기지 않을듯 합니다.
이 질문 다음으로는 업무 진행 방식에 대해 질문을 하면 좋습니다. “분기점(branch)을 사용하나요?” “재배치(rebase)와 병합(merge) 중 무엇을 선호하십니까?” 이런 질문은 그들이 사용하는 도구에 얼마나 전문적인 지식을 가졌는지, 그리고 그들에게 무엇을 기대할 수 있는지를 알 수 있습니다. 예를 들어 이 대답만으로도 그 회사에 가면 뛰어난 사람을 만날 수 있다는 확신을 얻을 수도 있지만, 오히려 Git에 대한 기초 교육을 맡을 것 같다는 예감을 하게 될 수도 있습니다.
이 질문은 개발 도구에 대한 전반적인 토론을 시작할 수 있도록 하며, 모두에게 좋은 통찰을 가져다줄 수 있습니다.
유닛 테스트를 작성하십니까?
어떤 팀을 유닛 테스트 활용 사례를 바탕으로 평가할 때는 신중해야 합니다. 유닛 테스팅에 대한 질문을 했을 때 기분이 좋아 보인다면 일반적으로 좋은 신호입니다. 그에 반해 왜 유닛 테스트를 작성해야 하는지, 유닛 테스트의 결점은 무엇인지에 대해 설명하지 못한다면 도그마에 빠져 있다는 징후로 볼 수 있습니다. “시간이 없다”는 등의 변명을 들며 테스트를 작성하지 않는다고 말한다면, 저는 좋지 않은 신호로 생각합니다.
지속적 통합(CI) 프로세스를 갖추고 있습니까?
제가 아는 최고의 개발팀은 Jenkins, Travis, 그리고 BuildBot 같은 도구를 사용합니다. 그 팀이 CI 도구를 사용하고 있지 않다면 관련 개념을 알고 있는지 알아봐야 합니다. 만약 모른다면 이건 제 경험상 좋지 않은 신호입니다. CI 시스템을 갖추고 있다는 것은 그 팀이 자동화에 대한 믿음을 가지고 있다는 의미이며, 이는 매우 좋은 신호가 될 수 있습니다.
어떤 팀에게 이 질문은 지속적 배포(CD)에 대한 토론으로 이어지게 합니다. 지속적 배포는 지속적 통합과 관련은 있지만 다른 개념입니다. 웹 개발자 직군이라면 적어도 CD에 대해 들어봤길 기대해 봅니다. 그리고 건강한 개발팀은 CD를 시스템에 부분적으로라도 적용하려고 시도합니다.
추가로 이어질 수 있는 질문들
- 당신의 팀은 CI가 실패했다는 알림을 받으면 오류를 수정하기까지 보통 얼마나 걸립니까?
- 구축된 CI 시스템에서 좋은 점 / 안 좋은 점은 무엇입니까?
- CI가 실행되는 데 시간이 얼마나 걸립니까? 더 빠르게 만들 수 있습니까?
어떤 지표를 측정합니까?
이 질문은 정답이 없으며, 그 팀이 소프트웨어의 성능을 측정하기 위한 노력을 하고 있는지 파악하기 위한 것입니다. 웹 개발팀은 보통 서버 응답 시간이나 요청 처리량, 사용자 수, 클라이언트 사이드의 반응성 등의 성능 지수에 대한 답변에 치중하는 경향이 있습니다. 하지만 이와 관련된 토론은 서로 다른 언어를 사용하는 사용자의 수, 브라우저 오류, 캐시 히트/미스 비율, 그리고 무수히 많은 다른 주제들로 이어질 수 있습니다. 만약 팀이 지표 측정에 시간을 들이고 있지 않다면, 이는 그들이 데이터에 기반을 둔 결정을 내리지 않고 있다는걸 의미합니다. 실제로 측정된 진짜 데이터를 기반으로 성능을 판단하는 팀에 좋은 점수를 매길 수 있습니다. 하지만 이는 성능 측정뿐 아니라 다른 많은 것들에도 적용될 수 있습니다.
만약 인터뷰 중인 개발자가 이 질문과 관련된 많은 대답을 할 수 있다면 그 팀은 높은 수준을 가지고 있다는 좋은 신호로 볼 수 있습니다. 만약 그들이 왜 굳이 그런 지표를 측정해야 하는지 모르겠다고 말한다면, 부정적인 신호로 보면 됩니다.
다시 도그마에 대한 법칙이 여기에서도 적용이 됩니다. 그 팀이 굳이 가치 있고 활용 가능한 정보를 제공하지 않는 데이터를 측정하고 있으면서도 당신에게 만족할 만한 대답을 주지 못한다면, 그것은 크게 잘못된 경고의 신호로 받아들이셔야 합니다.
추가로 이어질 수 있는 질문들
- 제품의 가장 중요한 지표는 무엇입니까?
- 성능 측정 시스템으로 무엇을 사용합니까? (예, MixPanel, statsd, 기타)
어떻게 버그를 찾고 수정합니까?
좋은 팀은 보통 전용 테스터를 가지고 있으며 개발자는 서비스의 품질에 공을 들입니다. 진짜로 수준 높은 팀은 놀랄 만한 테스트 자동화를 갖추고 있습니다. 어떤 팀은 전용 테스터나 테스트 자동화를 갖추기에는 너무 작지만 그게 나쁜 팀이라는 의미는 아닙니다. 저는 그 팀이 가진 프로세스가 어떤지 확인하기 위해 이 질문을 합니다. 이 질문을 통해, 개발자들이 너무 바빠서 다른 일을 할 수 없을 정도인가? 버그를 찾고 우선순위를 매기기 위한 제대로 된 프로세스를 가지고 있는가? 사용자에게 버그를 찾게 놔두고 있는 건 아닌가? 라는 질문들에 답을 얻을 수 있습니다.
추가로 이어질 수 있는 질문들
- 버그 수정 우선순위를 어떻게 매깁니까?
- 어떤 버그 트래킹 도구를 사용합니까? (그 도구는 어떤 점에서 마음에 들지 않습니까?)
- 버그 트래킹에 Excel을 사용합니까?
- 현재 버그 트래킹 도구에는 몇 개의 버그가 있습니까?
- 버그 수정에 얼마나 걸립니까? (최소 / 최대 / 일반적으로)
협업 도구로 무엇을 사용합니까?
제 경험상 높은 효율은 가진 팀은 다양한 협업 도구를 사용합니다. 그들은 주로 협업을 위해 채팅 서비스(Slack, IRC, HipChat, Jabber)와 코드 리뷰 서비스(Gerrit, GitHub, GitLab, Review Board)를 사용합니다. 물론, Email도 사용합니다. 저는 이 질문을 통해 개발자들이 서로 하는 일을 알고 있는지 알아보려 합니다. 물론 제가 여기서 말하는 ‘안다’의 기준은 일반적인 의미의 ‘안다’이며 서로를 아주 자세하게 속속들이 알고 있다는 의미는 아닙니다. 또 협업 도구를 잘 활용하고 있는지도 확인합니다. 가장 간단한 예는 자동 빌드 시스템에서 실패가 발생했을 때의 이메일 자동 알림 여부 같은 것입니다. 그리고 웹 개발팀이라면 시스템에서 심각한 오류가 발생했을 때, 일정 수준 이상의 네트워크 처리량이 발생했을 때 채팅방에 자동으로 알림이 오는 것 같은 사례가 있을 수 있습니다.
어떤 프레임워크를 사용합니까?
프레임워크에 대한 저의 취향은 2가지로 나뉩니다.
- 나는 현대적인 것을 좋아한다.
- 나는 새로운 것을 좋아한다.
어떤 팀이 Motif로 AIX 데스크톱 앱을 만들고 있다면 저는 거기에 흥미를 느끼지 못할 것 같습니다. 하지만 모두가 그렇지만 않습니다. 이건 무척 개인적인 차이라서 이 주제에는 취향에 대한 확실한 이해를 바탕으로 접근해야 합니다.
구축된 프레임워크에 대한 취향에는 상관없이, 그 팀이 왜 그 프레임워크를 선택했는지 이해하는 것이 중요합니다. 시대를 너무 앞서간 기술을 사용하고 있는가? 그들은 프레임워크를 마치 속옷을 갈아입듯이 바꾸지는 않는가? 그들의 코드가 매달 바뀌는 프레임워크로 인해 산산조각이 나 있지는 않은가? 너무 오래된 프레임워크를 버리지 못하고 있는 건 아닌가?
왜라는 관점에서, 저는 얼마나 많은 개발자가 그들이 사용할 기술을 결정하는 데 관여하고 있는지를 이해하려 합니다. 관리자들이 기술 결정 권한을 독점하고 있는가? 관리자들이 개발자들에게 결정을 양보하고 있는가? 이 주제에 대한 답을 확실히 이끌어내기 위해 보통 이런 질문을 합니다. “프레임워크 X를 어떻게 도입하게 되었나요?“. 만약 개발자들이 답을 하지 못한다면 나쁜 신호이거나, 아니면 그들이 그 회사에 온 지 얼마 되지 않아서 잘 모르는 것일 수도 있습니다.
저는 개발팀이 그들이 사용하는 오픈 소스에 직접 참여(contribute)하는 것을 좋아합니다. 이는 그들이 그저 단순히 코드를 사용하기만 하는 것이 아니라 참여를 할 수 있을 만큼 충분히 잘 알고 있다는 말이기 때문입니다. 오픈 소스 커뮤니티에서 활동을 하는 사람들이 제가 함께 일하고 싶은 사람들입니다. 만약 그 회사가 개발자들의 오픈 소스 활동을 적극적으로 지원한다면 더욱 좋습니다. 왜냐하면, 그 회사는 오픈 소스 진영의 일부가 된다는 것의 의미를 잘 이해하고 있다는 말이기 때문입니다.
만약 그 팀이 개발에 도움을 줄 수 있는 도구가 이미 있는데도 새로운 도구를 처음부터 새로 만들고 있다면, 저는 걱정이 될거 같습니다. 물론 여기에는 예외가 있긴 합니다. 예를 들어 Facebook은 도구를 직접 만들어서 사용해 오고 있습니다.
함께 작업해볼 수 있습니까?
만약 그 팀과 일하는 형태가 어떤 것인지 확실히 알고 싶다면, 실제로 함께 일해보길 추천합니다. 만약 그 팀에 대한 모든 것을 알 수 있길 원한다면, 그 회사에 가서 반나절만 함께 일해보시길 바랍니다. 만약 그 팀이 이 제안을 기꺼이 수용한다면 매우 좋은 신호로 볼 수 있다고 생각합니다.
다음 작업 마감은 언제입니까?
이 질문은 그 회사가 실제로 적용하고 있는 개발 프로세스에 대해 당신에게 더 많은 것을 알려 줄 수 있는 질문입니다. 이 질문 자체로서는 그렇게 많은 정보를 얻을 수 없지만, 여기에 아래의 질문들을 추가한다면 많은 사실들을 알 수 있게 됩니다.
- 누가 마감 기한을 결정합니까?
- 저번 마감 기한은 지켜졌습니까? 만약 그러지 못했다면, 이유는 무엇입니까?
높은 수준의 팀은 마감 시간을 지키는 것에 모두 동의합니다. 제대로 지켜지지 않는 마감 기한은 그 팀이 제대로 굴러가고 있지 않다는 신호입니. 또는 최소한 그 개발자는 일정을 결정하는 회의에 참석하지도 못했다는 의미입니다.
새로운 개발 환경을 세팅하는데 얼마나 걸립니까?
이 질문은 그 회사가 개발자 경험을 위해 얼마나 많은 노력을 하고 있는지를 측정할 수 있게 도와줍니다. 개발자가 컴퓨터를 세팅해서 코딩을 시작하기까지 몇 시간, 며칠, 몇 주가 걸리는가? 그 과정은 자동화가 되어 있는가 아니면 수동으로 직접 해야 하는가? 이는 그 팀이 소프트웨어 개발에 직접 관련되어 있지는 않지만 도움을 주는 “보조 활동”에 얼마나 능숙한지를 당신에게 말해줄 수 있을 것입니다. 그리고 그런 활동에 얼마나 큰 가치를 두고 있는지도 알려줄 것입니다.
어떤 회사들은 개발 환경 설정 프로세스가 너무나 빨라서 개발자들이 입사 첫날에 코딩을 시작할 수 있다는 사실에 자부심을 가지고 있기도 합니다. 이는 그 회사가 개발자들에게 깔끔한 개발 경험을 제공한다는 사실을 무척 중요하게 여기고 있다는 걸 보여줍니다.
만약 개발자라면 위 질문들에 대해 스스로 답변을 해보는 과정에서 개선할 점들을 찾아볼 수 있는 좋은 계기가 되지 않을까 생각해봅니다.