지난 4월 "우리는 모의장애훈련에 진심입니다 – Part 1."에서 모의장애훈련을 소개한 이후, 많은 분들이 관심을 보여주셨는데요. 이번 Part 2 글에서는 Part 1에 이어 구체적인 모의장애훈련 사례를 공유하고자 합니다.

Part 1 글에서 모의장애훈련이 무엇인지, 참가자별 역할과 진행 과정, 모의장애훈련 평가, 수확과 계속되는 고민을 말씀드렸습니다. 마지막에는 독자분들이 적용해 볼 만한 소소한 팁을 드리기도 했습니다. Part 2에서는 모의장애훈련의 평가 부분을 좀 더 세밀하게 다루어보겠습니다.

물론, 지난 글에도 평가가 있었지만 참가자와 리더의 소감에 가까운 내용이어서 그 이후에 진행한 정량적 평가의 노력과 이 과정을 통해 얻게 된 생각에 대해 자세히 말씀드리겠습니다.

후반부에는 지난번 글을 보신 독자분들이 문의하신 질문과 그에 대한 생각을 적어보았습니다.

자 그럼, 시작해보겠습니다.

1. 모의장애훈련 평가

평가 왜 필요한가?

저에게 “평가” 하면 가장 먼저 떠오르는 건 학교 다닐 때에 받아본 성적표입니다. 부족한 면이 드러나면 많이 부담스럽죠.

우리는 평가의 긍정적인 면에 집중하여 진행해 보았습니다. 도움이 필요한 영역이 무엇인지 파악해서 집중하고, 모의장애훈련이 꼭 필요한 팀이 어디인지도 파악해서 훈련의 효과를 높이고자 했습니다. 어떤 부분에서 얼마나 개선되는지 파악해서 이후 방향을 잡아갈 때 도움을 줄 것으로 생각했습니다. 모의장애훈련의 효과가 적은 영역에서는 다른 방법으로 개선하도록 구분하여, 막연하게 모의장애훈련 하나로 모든 장애대응이 나아질 것이라는 막연한 기대를 경계 했습니다.

정량적 지표 발굴의 과정

지난 훈련에서 타 팀보다 더욱 긍정적이었던 팀 유형을 분석하고, 정기적으로 진행을 희망하는 의견 등을 모아 정량적 지표를 발굴해 보았습니다. 정량적 지표를 활용하면 타 팀보다 장애대응 준비가 더욱 필요한 팀을 찾을 수 있고, 모의장애훈련을 계속 진행하면서 어떤 변화가 발생하는지 파악할 수 있어 다양한 관점의 지표 후보군을 만들어 보았습니다.

이 지표를 선정할 때 가장 고민했던 점은 이 지표를 받는 팀에서 쉽게 이해하고 수용할 수 있을까? 하는 점이었습니다. 정량적으로 측정하게 되면 이에 해당하는 팀에서는 평가에 대한 거부감을 가질 수 있기 때문에 담당팀에서 이해하고 소화할 수 있는 항목을 선정하는 것이 중요했습니다.

그리고 두 번째 고민했던 점은 장애 재발을 막는 활동 등 전사적으로 중요하게 보는 사항을 지표에 반영하는 것이었습니다. 지난 장애대응에서 아쉬웠던 점이 무엇인지 분석했습니다. 지표가 개선된다면 이 문제도 함께 해결이 되어가는 것이니 전사적인 방향과 지표, 활동이 한 목표를 바라보게 되는 것이죠.

그리고 마지막으로 여러 개의 지표가 모여 최종 하나의 지표와 이름으로 부를 수 있도록 했습니다. 여러 개로 흩어진 지표로 본다면 직관적이지 않고, 전반적으로 개선되고 있는지 파악도 어렵다보니, 각 지표를 모아 하나의 지표인 “장애대응에 대한 팀별 위험도” 지표를 만들었습니다.

이름을 짓고 나니, 모의장애훈련은 장애대응에 대해서 팀별로 위험도를 낮춰서 모든 팀이 안정적인 장애대응 준비를 갖출 수 있는 환경을 만들어주는 것으로 방향을 잡았습니다.

장애대응에 대한 팀별 위험도에 대해 5단계로 구분해서 안내 했습니다.
5단계는 처음 측정한 값을 기준으로 이보다 높은 대상을 세 분류로 나누어, 큰 관심이 필요한 군/좀 더 큰 관심이 필요한 군/나아가 아주 큰 관심이 필요해 위험도를 낮춰야 하는 시급한 대상군을 나누었으며 평균값보다 낮은 대상도 덜 큰 관심군과 작은 관심군으로 나누어 전혀 신경을 쓰지 않아도 되는 경우는 없도록 설계 했습니다. 지속적인 추적이 목적이기 때문에, 이 기준 값과 단계는 이후에도 동일하게 유지 했습니다.

이 지표를 통해 가지려는 목표는 다음과 같았습니다.

• 1차 목표: 아주 큰 관심군에 속한 팀의 위험도를 낮춘다.
• 2차 목표: 전사 위험도포인트의 평균을 낮춘다.
• 최종 목표: 모든 팀이 가장 안정적인 단계, 작은 관심군이 된다.

그렇게 해서 측정해 본 각 부서별 위험도 포인트는 다음 표와 같았습니다.

<처음 진행할 때 수집한 정보입니다. 아주 큰 관심군도 몇 개 보이네요.>

이제 장애대응에 대한 팀별 위험도지표를 구성하는 카테고리와 세부 지표들을 설명하겠습니다.

3가지 카테고리에 대한 설명

장애대응에 대한 팀별 위험도(앞으로는 장애대응 위험도라고 부르겠습니다.)는 위험도포인트로 표현이 되고, 높을수록 위험한 수치를 가집니다. 장애대응 위험도를 산정하는 세 가지 카테고리를 조직, 팀이 겪은 장애, 장애후속조치로 구분하였습니다.

1) 조직

지난 훈련을 통해 훈련이 도움되었다는 의견을 모아보니, 다음의 두 경우가 가장 많았습니다.

• 우리 팀의 신규 입사자들도 장애훈련을 통해 좀 더 장애 대응 능력을 높일 수 있었습니다
• 새로 만들어진 팀이나 새로 오픈하는 서비스에서 훈련을 통해 장애를 대비하는 팀워크가 향상되었다

그래서 첫 번째 카테고리로 조직을 선정하고 첫 번째 세부 지표로 최근 입사자의 비율을 선정했습니다.

또, 장애 훈련을 경험했는지, 경험했다면 얼마나 시간이 지났는지를 두 번째 지표로 만들었습니다. 최근 입사자의 비율이 높더라도 훈련을 통해 장애대응 절차를 경험했다면 조직 카테고리의 위험도 수치가 낮아지도록 구성 했습니다.

조직 카테고리의 계산은 다음과 같이 계산 합니다.

• 조직 카테고리 = 최근입사자 비율 포인트 x 가중치(4) + 가장 최근 모의장애훈련의 경험 포인트 x 가중치(8)

모든 지표들은 기준값에 따라 상/중/하로 나누고 그에 따른 포인트를 정한 뒤 가중치를 곱해서 합산하는 방식으로 계산 했습니다.

2) 팀이 겪은 장애

장애를 많이 접한 팀에서는 나름의 대응 방안이 공식/비공식적으로 수립되어 있습니다. 오히려 장애가 많은 팀에서는 자주 대응을 하다보니 훈련의 필요성과 효과가 떨어지게 됩니다. 그래서 장애를 분석할 때 장애가 발생한 빈도보다 지난 장애에서 개선할 점이 있는지를 주요 지표로 삼았습니다.

예를 들어 외부 시스템에서 발생한 문제가 고객이 인식하기도 전에 해소된 장애 같은 경우는 위험도 증가가 매우 적고, 반대로 모니터링에서 놓쳐 고객의 문의를 받아 대응하는경우, 장애 전파에 시간이 많이 소요된 경우 등에는 위험도가 많이 증가하도록 했습니다.
(외부시스템 장애에 대해 노력해 온 좀더 상세한 이야기는 “외부 시스템 장애에 대처하는 우리의 자세” 글을 참조하세요.)

장애 카테고리를 구성하는 요소는 다음과 같습니다.

• 장애 인지수단: 내부에서 모니터링에서 놓쳐 고객의 문의가 접수된 경우 많은 포인트 부여
• 장애 전파 소요시간: 전년도 평균 전파 소요시간에 비해 얼마나 신속했는지에 따른 포인트 계산. 특히 장애전파를 하지 않고 대응한 경우엔 가장 큰 포인트 를 부여
• 내/외부 장애: 장애 원인이 내부인 경우 많은 포인트 부여
• 장애 등급 가중치: 장애 영향도가 높은 장애등급의 경우 많은 가중치 반영

각 장애별 계산결과를 팀 단위로 합산하여 반영 했습니다. 그리고 특정기간이내 발생한 장애만 수집하여, 최근 장애와 관련한 활동이 얼마나 적절했는지 검토할 수 있도록 준비 했습니다.

3) 미처리 장애후속 조치

이번 카테고리는 미처리 장애후속 조치입니다. 장애가 발생한 뒤에 장애원인을 분석하고 이를 해결하는 개선방안을 잡는 후속절차가 진행됩니다. 이 후속조치는 장애의 재발을 방지하는 작업으로 가장 먼저 진행되어야 하나, 다른 작업을 진행하다보면 놓치는 경우가 발생합니다. 잠재적인 위험이 계속 남아있는 것이죠.

그래서 목표일정이 없는 장애 후속조치 또는 목표일정이 지난장애 후속조치에 발생했던 장애 위험도를 반영한 뒤에 팀별로 합산하여 계산 합니다. 각 항목은 장애대응 위험도 계산에도 활용하고, 각 팀별로 장애훈련 시나리오를 설계하고 이를 검토하는 시점에 팀장, 테크리더에게 후속조치 진행에 대해 안내 드립니다. 혹 필요한 도움이 있다면 요청도 받고, 일정과 우선순위 조정도 함께 진행 합니다.

그리고 이 접근이 실제 도움이 됩니다.

미처리 장애후속조치를 구성하는 요소는 다음과 같습니다.

• 경과 시간: 장애후속조치의 완료일자가 오래 경과되면 많은 포인트 부여
• 장애 등급 가중치: 장애 영향도가 큰 경우 많은 가중 값 반영

발굴한 지표 안내 및 활용

위와 같이 고심하여 지표를 만들고 놓고 사용도가 떨어진다면 참 아쉽겠죠? 안내와 활용에 대해 다음 사항을 고민했습니다.

정량화 지표 안내 및 사용자 활용 방안 제공

가장먼저 안내메일을 발송 했습니다. 정량화 지표를 만들었고, 이후에 장애대응 위험도에 따라 진행한다는 내용으로, 취지와 절차, 기대사항을 포함해서 안내했습니다.

<자세한 내용을 확인하실 분은, 회사에 입사하시면 됩니다.>

이 메일을 보내고 여러 팀으로부터 반가워하는 메일을 받았습니다.

두 번째 장애대응 위험도를 언제 누구라도 조회할 수 있도록 구성했습니다. 그래서 이번 모의장애 훈련의 대상팀으로 선정되지 않았다 하더라도 현재 우리 팀의 상황을 파악할 수 있도록 안내했습니다.

그리고 다음 달 모의장애훈련의 대상팀을 선정한 뒤 안내 메일을 보낼 때에 각 팀 단위로 어떤 이유에서 대상에 선정되었는지 설명하는 내용을 함께 보내드렸습니다.

즉, 장애대응 위험도 측정을 통해 나온 결과가 하나의 지표로 표현이 되면서 동시에 어떤 부분에 중점적으로 개선 활동이 필요한지 안내했습니다.

사실, 이 작업의 많은 부분은 건강검진 결과를 많이 모방했습니다. 신체 지수, 검사 결과를 모두 모아서 어떤 것을 개선해야 할지 알려주는 것과 유사하게 안내하도록 구성했습니다.

<각 팀마다 이렇게 하나하나 메일을 발송하고 사전미팅에 초대 했습니다.>

매월 상위등급 3 ~ 4개 팀을 대상으로 다음달 진행을 안내했습니다. 모의장애훈련을 진행한지 얼마 안 된 팀이라 하더라도 위험도가 계속 높은 팀은 훈련을 진행하도록 준비했습니다.(다행히 이 경우는 발생하지 않았습니다.)

정량화 지표 활용해서 얻은효과

정량화 지표를 통해서 장애대응 위험도가 가장 높은 팀을 파악하니, 뜻밖에 ‘시스템신뢰성개발팀’이었습니다.전사의 인프라의 안정성을 담당하는 팀으로 한 번 장애가 발생하면 범위와 심각도가 크고, 장애 후속 조치의 영향도가 넓으면서 난이도가 높았습니다. 최근 합류한 인원이 많으면서 다른 팀의 모의장애훈련 진행을 도왔지, 직접 경험한 적이 없었습니다. 파악된 즉시 모의장애훈련을 준비하고 진행해, 장애대응의 위험도를 53% 낮출 수 있었습니다.(정말 고생이 많은 시스템신뢰성개발팀이 어떤 일을 하는지는 다음 문서를 참조하세요: 시스템신뢰성개발팀을 소개합니다.)

정성적 효과, 그래도 필요하다

정량적인 효과를 측정하면서 얻을 수 있는 많은 장점에도 정성적인 파악이 필요하다는 것을 알게 되었습니다. 한 팀 한 팀 인터뷰를 통해 각 팀의 ‘이야기, 사연’을 알 수 있습니다.

개발팀 A의 사연입니다.

“새로 팀이 만들어지면서 운영 중인 서비스의 장애를 대비해야 했습니다.
챙겨야 할 많은 작업들 중에 장애의 이야기는 부담스럽기도 하고 서로 아직은 어색해서 논의가 어려웠는데, 장애훈련을 준비하는 과정에서 팀장과 설계자가 함께 이야기하고, 장애훈련 회고하면서 팀원들의 고민이 무엇인지 듣고 개선작업을 진행하는 것이 좋았습니다.

무엇보다도 팀원들의 합이 맞아가는 것을 볼 수 있었습니다. 실제 장애상황에서도 전체 팀원들이 훈련처럼 함께 대응하면서 더 팀웍도 좋아진 것도 체감할 수 있었고요. 그런 의미에서 좋았습니다. 팀웍은 모의장애훈련을 통해 얻은 눈에 보이지 않는 팀의 정말 큰 수확이며 자산이었습니다.”

개발팀 B팀의 사연은 다음과 같습니다.

“모의장애훈련 이후 개선사항으로 팀 내의 장애대응 절차를 정리해야겠다 하고 의견이 모였습니다. 이때에 이미 이 내용을 고민하여 적용했던 다른 팀의 사례를 전달받아, 우리 팀도 좋은 사례를 따라하면서 준비할 수 있었습니다.

잘하고 있는 타 팀에서 하는 활동이 궁금했는데, 이에 대해 참조할 수 있어서 좋았습니다.”

개발팀 C팀의 사연을 들어보았습니다.

“팀장과 설계자는 매번 장애대응을 하고 있습니다. 모의장애훈련에서 얻은 효과는 저희가 장애에서 살짝 벗어나 바라보면서 배우는 것입니다. 매번 장애대응 안에서만 있다가 바깥에서보니, 유관부서는 무슨 관심사가 있는지, 특히 어떤 내용을 포함해서 전달 해주면 좋을지, 그리고 왜 답답해하는지 잘 알 수 있었습니다. 다른 팀의 관점으로 우리 팀을 바라볼 수 있는 유익한 기회였습니다.

다음엔 이 내용을 고려해서 장애대응하겠습니다.”

이렇게 이야기를 발굴하면 다음 모의장애훈련을 진행할 때 도움이 됩니다.

첫 번째 이야기한 것 처럼, 팀워크가 좋아졌다는 것은 정량화하기 어려운 항목이기도 하고 무리하게 정량화하다 보면 복잡해지니, 이렇게 스토리로 이야기할 내용은 다른 방법으로 안내하는 것이 효과적인 것 같습니다. 서로 보완적인 셈이죠.

모의장애훈련을 평가해본다면?

정량적 측정 결과 효과를 확인할 수 있었습니다.

매월 전사 장애대응 위험도의 수치가 급격히 낮아졌습니다.
첫 달 대비 둘째 달에 11% 감소했으며, 둘째 달 대비 셋째 달에 17% 감소했습니다.
이는 장애훈련을 진행한지 오래된 팀에서 훈련을 진행했다는 점과 미처리 건수를 사전 미팅 때 안내하고 개선한 활동도 있습니다만, 지표가 없었다면 진행에 따라 얼마나 효과가 있었는지 파악이 어려웠을 겁니다.

정성적 평가도 놓지 말아야 한다는 점도 알 수 있었습니다. 예를 들어 팀워크가 좋아졌다는 것을 무리하게 정량화하다 보면 너무 복잡해지다 보니, 스토리로 풀어갈 것은 그대로 남기고 전달하는 것이 더 효과적인 것 같습니다. 서로 보완적인 셈이죠.

여기까지 우리가 고민하고 적용하면서 검토한 모의장애훈련 평가에 대해 이야기 드렸습니다.
사실, 측정한 기간보다 지표를 만들고 검토한 시간이 더 많이 소요된 것 같습니다. 대신, 지표를 만드는 노력은 한 번이지만, 측정은 계속되니, 그 이후 효과를 확인하는 가장 쉬운 방법이 될 것 같습니다.

2. 모의장애훈련 에피소드

지난번 모의장애훈련에 대한 글과 장애대응에 따른 글을 보고 회사 내/외부의 독자분들께 받은 질문과 답변드린 내용을 모아보았습니다. 여기까지 읽으신 분들께 감사드리며 차근차근 이야기하듯 답변을 이어가 볼게요.

장애와 관련한 활동을 할 때 어떻게 관련 팀의 호응을 얻어낼 수 있었나요?
가장 많이 받은 이 질문부터 답변을 드려 볼게요. 장애는 이야기하기 껄끄럽고, 장애대응 프로세스는 더욱 어려운 주제입니다. 그렇지만, 조직에서 이 내용을 회피하면 장애를 대비하는 능력이 향상될 수 없습니다. 고객에게 오랜 시간 불편을 드리는 상황이 계속 발생할 수 있는 것이죠.

그래서 우리는 가장 먼저 “신뢰 자산"을 쌓는 데 노력했습니다. 개발팀에서 어떤 부분이 장애대응에 어려운지, 전파받는 곳과 의사결정하는 곳에서는 어떤 것을 원하는지 계속 듣고 어려움을 해결하는데 집중했습니다. 장애대응실 상황에서 어려움이 있다면 장애를 함께 대응했습니다. 부족한 것은 장애 대응이 모두 마친 뒤에 나중에 이야기했습니다.

그리고 모의장애훈련을 통해 장애를 더 잘 대응하는 방법을 팀 안과 밖에서 이야기할 수 있는 자리로 만들었습니다. 전사적으로 바라보는 목표에 도달하려면 우리 팀에 무엇이 필요한지 이야기하고, 그 자리에 장애대응 절차를 담당하고 있는 팀도 함께 참여해서 다른 팀의 사례, 궁금한 점을 이야기드렸습니다. 그리고 개선을 요청할 때 장애대응 절차를 다시 한번 살펴보고 최대한 반영하도록 했습니다.

마지막으로 장애 종료 이후 장애의 책임이 개인에게 있지 않다는 점을 계속 지키며 후속작업을 진행했습니다. 구체적으로는 장애 보고서 작성을 요청할 때 담당자가 장애 복구를 모두 마치고 하루쯤 뒤에 확인했습니다.(급한 상황에서는 좀 더 일찍 물어보기도 했습니다만.) 원인 분석과 해소 조치를 할 때에도 우리가 배워야 할 것이 무엇인지 찾아내었습니다. 간혹 자책하고 있는 개발자가 있다면, 팀으로 해결할 수 있는 것이 무엇인지 같이 찾아보았습니다.

이런 과정을 통해 프로세스를 담당하고 장애를 지원하는 조직, 모의장애훈련을 진행하는 담당자와 개발팀의 구성원들과 신뢰가 쌓이고, 그 신뢰 자산을 가지고 이 일을 진행했습니다.

신뢰 자산이 충분하지 않을 때, 장애대응 절차와 훈련 등 모든 활동을 진행하는 팀과 관련팀은 서로 같은 생각하기 어렵고 모두 소모적인 상황이 벌어지는 어려움이 있습니다. 신뢰를 쌓는 것이 우선입니다.

모의장애훈련이 실제 장애에 얼마나 도움을 주었나요?

모의장애훈련은 장애를 방지하는 것에는 큰 도움을 주지 않습니다. 장애에 취약한 부분을 발견하고, 아키텍처를 개선하는 등의 작업이 더 효율적입니다.

대신, 장애가 발생할 때 팀과 관련 조직이 유기적으로 장애를 대응하는 과정의 숙련도를 높이는데 효과적입니다. 정량적으로 장애대응에 대한 팀의 준비 수준을 높이는 것을 이야기한 것처럼, 그 부분에 도움을 줍니다. 사례를 통해 본다면, 다수의 팀에서 훈련 후 얼마 안되어 실제 장애를 맞을 때, 기존보다 팀원들의 손발이 맞고 놓치지 않고, 관련팀에서 대응하는데 필요한 정보를 묻기 전에 전달할 수 있었다는 의견을 들었습니다. 이 부분이 실제 장애 때 도움을 주는 영역으로 생각합니다.

장애 발생의 방지는 찾아가는 기술위원회, 아키텍처 리뷰 등을 통해 장애에 취약한 구조를 검토하고 개선하는 작업을 진행했고, 모니터링 강화와 시스템 오픈 전 체크리스트 등 다른 다양한 활동을 진행했습니다.

모의장애훈련을 진행하면서 아쉬운 점은 없나요?

모의장애훈련은 저도 아직 안 가본 길입니다. 하나하나 밟아가며 진행하는 작업입니다.
그래서 진행하고 나서 아쉬운 점이 있는데, 자동화와 세부적 마일스톤이 아쉽습니다.

위에서 말씀드린 장애위험 지표를 선정한 뒤에 곧바로 자동화를 했다면 어땠을까 합니다. 특히 지표수집의 자동화가 가장 가슴 아픈 부분인데, 주기적으로 집계할 때 며칠간의 시간이 소요되었습니다. 조직이 변동될 때 이전 집계 내용과 팀/조직이 달라지는 것을 검토하는데 시간이 많이 소요되었습니다. 빠르게 수집하고 검토할 수 있도록 자동화 했다면 더 효과적이었을 것 같습니다. 좀 더 나은 방법으로 변화를 줄 때에도 효과적이었을 것 같네요.

두 번째 아쉬움은 세부적 마일스톤입니다. 탄탄히 다질 때와 앞으로 나설 때를 판단하기 쉽지 않습니다. 탄탄히 다지고 있다 보면 경험을 반복하면서 얻는 점도 있지만, 다음 단계로 나서는 시기를 놓칠 수 있습니다. 전체적으로 이후 단계들의 큰 그림은 있었지만, 세부적으로 작은 단계들에 대한 계획과 적절한 시점을 준비하고 있었다면 더욱 좋았을 것 같네요.

왜 아는 내용으로만 모의장애훈련을 진행 했나요? 전혀 경험하지 못한 시나리오로 진행해 볼 수도 있지 않나요?

이에 대해서도 아쉬운 점으로 남습니다. 다만, 취지를 말씀드리면 모의장애훈련은 지난 장애 상황에서 장애를 대비하는 주 인력이 빠졌을 때에도 팀의 다른 인원들이 해결할 수 있도록 준비하는 것이 최우선 목표였습니다.

그래서 알고 있는 시나리오, 장애를 가장 많이 겪은 분이 설계한 내용을 기반으로 진행했습니다. 이 내용을 보시는 독자분들의 상황과 회사 환경에 맞춰서 진행해 보시면 좋겠습니다.

우리 회사에 적용해 보고 싶어요!

이대로 적용하신다면, 낭패를 겪을 수 있습니다. 무엇보다도 우선 고려할 것은 우리 조직에 무엇이 필요한가?입니다.

필요를 진행자 입장이 아닌, 관련 팀의 의견과 필요를 듣고 진행해 보시길 바랍니다. 위에서 말씀드린 ‘신뢰 자산’이 충분히 확보된다면 더욱 좋을 것 같습니다.

그리고 이 모든 활동의 목표를 ‘고객’으로 삼아서 진행하시면 좋겠습니다. 여러 가지 이야기를 드렸고, 적용의 팁을 드렸는데 최종적 목표는 고객에게 얼마나 안정적인 서비스를 할 수 있을까?라는 점입니다. 이것을 잊지 않고 꾸준히 검토하고 실행해 간다면 독자분들의 서비스도 더욱 안정적이 될 겁니다.

나가면서

이제 Part 2를 마무리하게 되니, 밀렸던 숙제를 한 느낌입니다. 조금씩 밟아보지 않은 길을 걷다 보니 여기까지 왔습니다.

저와 같이 고민하고 계시는 분들께 작지만 유용한 참조 자료가 되면 좋겠습니다. 다른 분들의 도전 이야기를 듣고 싶고, 저 또한 그 이야기를 들으면서 배워가고 싶네요.

긴 글 읽어 주셔서 감사합니다.

<이번 시즌 3의 20번째이자 2022년의 마지막 훈련을 진행한 팀과 함께 찍은 사진을 올립니다>

관련 글

우리는 모의장애훈련에 진심입니다 – Part 1.

세미나 들여다 보기

• 2022. 9. 29.(목) 저녁 7시
• 우아한Tech 유튜브 라이브

기술 커뮤니티의 가치. 개발자분들이라면 이미 잘 알고 계시겠죠?
우리는 커뮤니티를 통해 성장하고, 공부하고,
때로는 커리어를 키워가고 있습니다.

그렇다면 기업에게 있어 기술 커뮤니티는 어떤 가치가 있을까요?
최근 많은 관심을 받고있는 ‘디벨로퍼 릴레이션’은 무엇일까요?

개발자, 기술커뮤니티, 그리고 기업을 잇기 위해
디벨로퍼 릴레이션은 어떤 일을 하는지
등장배경부터 기업별 사례까지 찬찬히 이야기 나눠봅니다.

추천 대상

• Developer Relations가 무엇인지 궁금하신 분
• 기술 커뮤니티가 기업에 어떤 가치를 가지고 있는지 궁금한 분
• 개발조직 문화만들기 등 대내외 개발자 커뮤니케이션을 고민하고 계신 분
• 개발자가 고객인 회사를 운영하거나, 채용 브랜딩을 고민하시는 분
• 사내에 Developer Relations 관련 팀 빌딩을 고민하시는 분

발표자 소개

조은옥 / 우아한형제들 Developer Relations

개발자의, 개발자에 의한, 개발자를 위한 전략을 고민하는 비개발자(!)
관계(Relations)의 가치와 진정성을 기업 전략에 담아내고
변화와 성과로 이어지게 하는 일을 고민하고 있습니다.

광고회사에서 첫 커리어를 시작했다가, 세상의 변화를 이끌어가는
IT 기술을 동경해 IBM으로 이직, 디벨로퍼 릴레이션의 길을 걷기 시작했습니다.
지금은 우아한형제들에서 기술조직의 문화와 역량을 알리고 브랜딩하는 일을 하고있습니다.

(전) IBM Korea 디벨로퍼 애드보케이트팀 Developer & University Relations Manager
(전) IBM Korea 디지털 마케팅팀 유통/소비재/게임/헬스케어 산업 담당자
(전) 제일기획 디지털 캠페인팀 디지털콘텐츠 프로듀서

번역서
"기업의 성공을 이끄는 Developer Relations"(2022, 한빛미디어)

지난 우아한테크세미나가 궁금하다면?
우아한Tech YouTube에서 확인하세요! [클릭]

우아한Tech 소식을 빠르게 받고 싶다면?
우아한Tech 뉴스레터를 신청하세요! [뉴스레터 신청하기]

세미나 들여다 보기

• 2022. 8. 31.(수) 저녁 7시~9시
• 우아한Tech YouTube 라이브

애플리케이션 보안, 즉 흔히 말하는 취약점 진단은 안전한 앱 운영을 위해 꼭 필요하죠.
그러나 개발 vs 보안…!
이 관계는 숙명적으로 부딪힐 수 밖에 없는데… 

우아한형제들의 보안 담당자가 말합니다.
개발자가 꼭 알아둬야 할 보안은 무엇일까요?
앱 보안을 위해 해야하는 일은 어떤 것이 있을까요?
취약점 진단은 어떻게 진행할까요?

개발자분들이 가장 많이 부딪힐
보안 이슈들과 요즘의 보안 트렌드들을
예시와 함께 설명드립니다

1부에서는 보안에 대해 잘 모르더라도 알기 쉽게 소개해드리고
2부에서는 개발자, 특히 백엔드 쪽 분들께 흥미로울 내용을 다뤄봅니다.
개발의 발전과 보안관의 괴리, 인증과 인가, 최근 많이 나오는 IDOR 취약점과 핫하게 쓰이는 JWT로의 인증방식 등.

입문부터 트렌드까지 짚어보아요

추천 대상

• 보안에 대해서 잘 모르지만 알아두고싶은 분
• 개발vs보안! 부딪혀본 경험이 있으신 분
• Application Security, 즉 취약점 진단 쪽에 관심이 있는 분
• 보안에 관심있는 백엔드 개발자

발표자 소개

권현준 / 우아한형제들 인프라보안팀

권현준 / 우아한형제들 인프라보안팀
선린인터넷고등학교를 졸업하고 바로 보안업계에 뛰어들어 8년째 일하고 있는 Application Security Engineer입니다.
현재 우아한형제들에서 제공하고 있는 서비스들의 안전성을 위해 취약점 진단/ 모의해킹 등 다양한 업무를 수행해나가고 있습니다.

• (현) 우아한형제들 인프라보안팀
• (전) 하나금융그룹 하나금융티아이 IT보안센터

저서
"누구나 쉽게 따라하며 배우는 웹해킹 첫걸음"(2022, 비제이퍼블릭)

지난 우아한테크세미나가 궁금하다면?
우아한Tech YouTube에서 확인하세요! [클릭]

우아한Tech 소식을 빠르게 받고 싶다면?
우아한Tech 뉴스레터를 신청하세요! [뉴스레터 신청하기]

세미나 들여다 보기

• 2022. 7. 27.(수) 저녁 7시~9시
• 우아한Tech YouTube 라이브

개발자는 개발만 잘 하면 되는 줄 알았는데 말이죠
그런데 웬걸! 써야 할 글이 왜 이리 많을까요.

요구 사항을 정확하게 정리해야 하고
협업 과정에서 문제없이 의사소통을 해야 하고

사용자를 위해 오류 메시지를 직접 써야 할 때도 있고
개발 가이드를 써야 할 때도 있고…!

그거 아시나요?
글쓰기에 진심인 우아한형제들에는
개발자 여러분이 글을 더 잘 쓸 수 있도록 돕는 ‘테크니컬 라이팅 코치’가 있습니다.

커뮤니케이션 오류를 줄이고, 오래 보존할 수 있는 효과적인 의사소통법 "글쓰기".
일상 업무 속 글쓰기, 기술 블로그 작성부터 때로는 책 출간까지.
어떻게 하면 쉽게 시작할 수 있을까요?

우아한형제들 테크니컬 라이팅 코치와 함께 그 힌트를 얻어 보세요!

추천 대상

• 글을 쓰고는 싶은데 어디에서부터 시작해야 할지 막막한 분
• 글을 거의 써 본 적이 없는데 잘 쓸 수 있을지 걱정하는 분
• 테크니컬 라이팅이 무엇인지 궁금하신 분
• 글쓰기로 개발자의 성장을 장려하는 문화가 궁금한 분

토크 순서

• 시작하기: 개발자를 위한 글쓰기 문화에 진심인 우형
• 발표 세션: 기술 글쓰기, 어떻게 쓸 것인가
• 패널 토크: 테크니컬 라이팅 코치와 함께, 시작해요 글쓰기!
• LIVE Q&A

연사 소개

유영경 / 테크니컬 라이팅 코치

운명적으로 ‘테크니컬 라이팅’ 업무를 시작한 지 어언 20년이 된 글쓰기 코치.
다양한 IT 기업에서 UI 메시지, 사용자 가이드, 개발 가이드 등을 작성하고 검수하면서 글쓰기가 어렵다는 분을 많이 만났는데요.
의외로 다른 글쓰기와 달리 ‘기술 글쓰기’는 요령과 원칙을 익히면 누구나 잘 쓸 수 있습니다.

글쓰기는 생각보다 어렵지 않고, 다 쓰고 나면 성취감과 재미까지 느낄 수 있음을, 많은 분께 알려드리고 싶습니다.

저서
"개발자를 위한 글쓰기 가이드"(2021, 로드북)
"웹 기획자가 알아야 할 서비스 글쓰기의 모든 것"(2013, 위키북스) 등

김민석 / (전)테크니컬 라이팅 코치

평범한 소프트웨어 엔지니어 업무를 하던 중 우연히 ‘Developer Relations’라는 새로운 세계로 발을 들이게 되었습니다.
회사의 기술블로그 편집 위원장을 맡아 기술 기고문의 주제 발굴, 작성, 검수와 피드백을 담당하는 한편,
영문 기술 아티클의 한글화 작업을 맡기도 했습니다.

‘쓸모없는 소재는 없다’는 마음가짐으로 개발자 글쓰기를 위한 브레인스토밍 및 코칭을 하고 있습니다.

지난 우아한테크세미나가 궁금하다면?
우아한Tech YouTube에서 확인하세요! [클릭]

우아한Tech 소식을 빠르게 받고 싶다면?
우아한Tech 뉴스레터를 신청하세요! [뉴스레터 신청하기]

[EVENT] 우아한테크세미나 후기 쓰고 로지텍 키보드를 GET!

한 달에 한 번씩
우아한형제들의 기술이야기를 전해드리는 월간 <우아한테크세미나>
매월 알찬 이야기로 여러분을 찾아뵙고 있는데요,

점점 많은 분들이 참여해주시는 성원에 힘입어!
그리고 열심히 공부하는 개발자 여러분을 위해!
이벤트를 준비했습니다
이름하야 <우아한테크세미나 알찬 후기 공모전>

참여방법?

2022년 1월~6월 우아한테크세미나 중
한 편을 보고 후기를 쓴 블로그 링크를
dev_relations@woowahan.com으로 보내 주세요.
좋은 후기를 선정해 1분께 로지텍MX 키보드&마우스 세트를 드립니다.

응모기간: 2022. 7. 25.(월)까지
당첨자 발표: 2022. 7. 29.(금) 당첨자 개별연락

우아한테크세미나 보러가기

세미나 들여다 보기

• 2022. 6. 29.(수) 저녁 7시~9시
• YouTube 라이브

정말 개발자는 다 안 된다고 할까요?
디자이너는 정말 1px에 집착할까요?
기획자는 스펙도 일정도 자주 바꾸는 변덕쟁이라구요?

프로덕트는 어떤 사람들이 만드는 지 궁금한 분들을 위해
우아한형제들에서 서비스하고 있는 웹툰 플랫폼,
‘만화경’을 만들고 있는 개발자, 디자이너, 기획자를 모셨습니다.

회의 때 분명 같은 이야기를 한다고 생각했는데
알고 보니 모두 다른 이야기를 하고 있었던 경험이 있다면?
최선의 사용자 경험을 만드는 과정에서
개발자는, 디자이너는, 기획자는 무엇을 가장 먼저 생각하는지 궁금하다면?

직무 별 업무 특성과 그에 따른 관점의 차이를 이야기하며 협업의 실마리를 함께 찾아보아요.
3직군의 솔직한 협업 이야기가 궁금하다면 우아한테크세미나에서 만나요!

추천 대상

• 프로덕트는 어떤 사람들이 만드는지 궁금하신 분
• 기획, 디자인, 개발 직무의 업무 시 관점 차이가 궁금하신 분
• 왜 우리는 수많은 스프린트를 진행하면서 매번 같은 고충에 부딪히는걸까 생각해보신 분
• 다른 회사, 다른 팀은 어떻게 일할까? 궁금하신 분

토크 순서

• WELCOME & EVENT
• [패널소개] WHAT IS 만화경?
• [패널토크] 개발자/디자이너/기획자 삼파전!
• LIVE Q&A

읽고오면 좋아요! 만화경 구름톡 개발기
1편) https://techblog.woowahan.com/6803
2편) https://techblog.woowahan.com/7949

만화경 앱 다운로드해보기
https://manhwakyung.onelink.me/Te4S/woowatech

연사 소개

구지민 / 만화경 서비스 기획
우아한형제들에 신입 기획자로 입사해서 만화경 프로덕트의 첫 모습을 만들었습니다.
그리고 지난 3년 동안 서비스와 함께 성장하고 있습니다.
디자인하고 설계한 모든 것이 경험으로 이어진다는 마음으로 기획합니다.

채상아 / 만화경 안드로이드 개발자
사람을 자유롭게, 기술의 문턱을 낮추기 위해 개발을 하고 있습니다.
함께 일하고 싶은 사람이 되기 위해 늘 고민하는 개발자입니다.
지금은 만화경에서 누구나 즐길 수 있는 웹툰 앱을 만들고 있습니다.
저서: https://fastcampus.co.kr/books/211175

안윤경 / 만화경 서비스 디자인
새롭고 재밌는 것을 만드는 걸 좋아합니다.
만화경 사용 경험이 매력적으로 느껴지도록 디자인하고 있습니다.
다양한 관점과 피드백을 수용하여 더 나은 제품을 만들 수 있도록 노력합니다.

지난 우아한테크세미나가 궁금하다면?
우아한Tech 유튜브에서 확인하세요! [클릭]

5월 30일 월요일 저녁 7시! 알림설정하고 본방사수하세요

혼자서는 성장할 수 없는 시대!
함께 공부하고 성장하기 위해 우아한형제들이 고민한 방법은?!
그리고 우아한형제들 개발자들이 풀어내는 그 소소하지만 알찬 경험과 노하우!
다 함께 편안한 분위기에서 이야기 나눠보아요

위의 유튜브 링크를 클릭하고 "알림설정"을 클릭하세요

토크순서

WELCOME! 모두의 무럭무럭 성장을 위하여! (19:00~19:20)
Developer Relations팀 조은옥&구은희

오늘의 토크쇼 패널 소개 (19:20~19:35)

패널 토크 (19:35~20:35)

• 서로에게 멘토와 멘티가 되어줄 수 있다면, 우아한멘토링 (마광휘)
• 함께 공부하고 나누는, 우아한스터디 (윤태원)
• 글쓰는 습관을 들이고 있는 개발자의 이야기 (송요창)
• 공부하고 성장하는 노하우?! (ALL)

라이브 Q&A 및 안녕! (20:35~21:00)

‍패널소개

구은희 / Developer Relations팀

마광휘 / 커머스웹프론트파트 #우아한멘토링
"우아한형제들에서 웹 개발하는 마광휘입니다.
제가 하는 일이 주변 사람들에게 좋은 영향이 있으면 좋겠습니다."

윤태원 / 커머스플랫폼팀 #우아한스터디
"우아한형제들에서 프론트엔드 개발을 하고 있는 윤태원입니다.
배움 속의 다양한 즐거움을 찾기위해 노력하고 있어요!"

송요창 / 선물하기서비스팀 #프론트엔드글쓰기
"우아한형제들에서 프론트엔드 일하는 운좋은 프로그래머 송요창입니다.
평범한 사람들이 모여서 비범한 일을 할 수 있다고 믿고 있어요."

여러분이 알고 있는 “멘토링”은 어떤 것인가요?
‘지도자와 조언을 구하는 자? 스승과 제자? 팀장과 신입사원..?’
이 글에서는 많은 분들이 알고 있는 멘토링 방식과는 조금 다를 수도 있는, 이게 멘토링 맞아? 라고 할 수도 있는.. “우아한멘토링”에 참여했던 개발자분들과의 인터뷰 내용을 보여드리고자 합니다.

우아한멘토링은 우아한형제들 개발자 5명을 필두로 시도해 본 그룹 멘토링 프로그램인데요.

“다양한 환경, 다양한 시각을 가진 개발자들이 모여 각자의 고민을 토로하고 의견을 공유하는 것만으로도 함께 성장할 수 있지 않을까?”

라는 물음에서 출발하여, 내부 개발자와 타사 개발자가 함께 모여 멘토와 멘티의 역할을 크게 구분 짓지 않고 특정한 주제에 대해 자유롭게 의견을 나누는 시간으로 계획하였습니다.

우아한멘토링에 함께할 6명의 타사 개발자를 모집하였고, 각기 다른 11명의 멤버가 모여 두 달간 매주 (무려 점심시간을 이용해..ㅎㅎ) 돌아가며 한 가지 주제에 대해 멘토링하는 방식으로 진행하였습니다.

우아한멘토링 참여자 중 타사 소속 개발자 몇 분을 모시고 솔직한 인터뷰를 나눴는데요,
과연 우아한멘토링에 참여했던 멤버들은 어떤 고민을 가지고 함께 이야기했을지, 멘토링이 끝난 후 소감은 어떨지, 그 내용을 여러분에게 공개합니다.

Q. 간단한 자기소개와 함께 우아한멘토링에 신청하게 된 계기를 말씀 부탁드려요.

이재상님(스타트업 창업)

안녕하세요! 저는 현재 클라우드 보안 솔루션을 개발하는 스타트업을 창업하여, 백엔드 개발을 맡아서 일하고 있는 이재상이라고 합니다.
학부를 졸업하자마자 창업을 하다 보니, 다른 개발 조직의 협업 문화가 궁금했던 찰나 우아한멘토링을 알게 되어 신청했습니다.

• 재상님의 주제 "개발 조직 문화와 협업 문화"

장일규님(보험권 SI 근무)

안녕하세요:) 현재 고객사 프로젝트에서 9개월 차 일하고 있는 장일규라고 합니다.
주니어이다 보니 주변에 제 속마음에 고민과 걱정들을 편하게 이야기 나눌 개발자가 없었어요.
우아한 형제들에서 스터디를 한다는 공고를 봤는데, 개발 스터디가 아닌 주니어 개발자를 대상으로 멘토링을 한다는 내용을 보고 바로 지원하게 되었습니다!

• 일규님의 주제 "SI 개발자가 성장하고 이직하는 방법"

신은지님(스타트업 근무)

안녕하세요! 저는 지속 가능한 서비스를 만드는 백엔드 개발자, 신은지 입니다.
제가 재직 중인 회사는 한참 성장 중인 소규모 스타트업으로, 팀 내에 경력직 사수가 없었습니다.
회사가 성장하면서 점점 해결되지 않는 문제들이 쌓여만 가는 상황에 답답함을 느끼게 되었는데요, 혼자서 고민했던 문제들을 공유하고, 저와 비슷한 연차의 개발자분들은 요즘 무엇을 고민하고 있는지 알아보며, 저의 Next step을 그려보고 싶었어요.

• 은지님의 주제 "개발 방법론과 타 직군에 대한 이해 높이기"

현정호님(스타트업 근무)

안녕하세요. 현정호입니다! 저는 이커머스 스타트업에서 프론트엔드 개발자로 근무하고 있습니다.
우아한멘토링의 존재를 처음 알게 된 것은 광고로 기억합니다.
멘토링의 존재를 알았을 때, 너무 좋은 기회라고 생각한 한편 지원 자격 조건도 없었고, 기업에서 진행하는 멘토링이었기 때문에 경쟁률이 상당히 높을 거라고 생각했습니다. 그래서 신청 당시에도 " 반드시 참여하겠다!" 라는 마음보다는 "지금 나의 상황과 고민을 솔직하게 작성하고 마음 비우고 기다려보자.." 라는 마음으로 신청했습니다.

• 정호님의 주제 "프로그래밍 학습 방법과 로드맵 공유"

정재훈님(전 우형 근무, 현 스타트업 근무)

안녕하세요. 우아한형제들에서 데이터엔지니어 ‘였던’ 정재훈입니다.
지금은 기술로 즐거움을 만드는 것을 목표로, 또 다른 도전을 해보려 이직하게 되었습니다.

Q. ‘그때 그 순간!’, 멤버로 발탁되었을 때의 심정이 어떠셨나요?

신은지님(스타트업 근무)

솔직히 잘못 본 줄 알았어요! ㅎㅎ
버스에서 졸면서 아무 생각 없이 메일함을 열어봤다가 ‘우아한스터디 멤버가 된 것을 환영합니다!’ 라는 메일 제목에 잠이 확 깼던 기억이 나네요.
바로 별표 눌러서 메일을 저장하고 수도 없이 들어가 봤어요. 혹시 메일을 잘못 보냈다는 정정 연락이 올까봐 잠깐 무섭기도 했습니다.

또 한편으로는 제가 올바르게 고민하고 있다는 것을 확인받은 기분이 들었습니다.
주니어로서 충분히 할 수 있는 고민이라고, 이 시기를 이겨내는 게 중요하다고 답변을 받은 것 같았어요.

메일 본문에 기재되어 있던 신청자 수를 보고, 힘들게 잡은 기회니 최대한 많은 것을 배워와야겠다는 생각도 들었습니다.

이 후기를 쓰면서 다시 합격 메일 열어봤는데 여전히 기분이 좋네요!

(수도 없이 들어가본 합격 메일..)

Q. 우아한형제들 멘토로 참여해 주신 재훈님이 뿌듯하실 것 같은데요, 우아한멘토링을 함께 구상하고 또 직접 참여하게 된 계기가 있으셨나요?

정재훈님(전 우형 근무, 현 스타트업 근무)

우아한형제들은 ‘테크레인저스’라는 그룹이 있는데, 개발조직의 발전을 위해서 고민하고 활동하는 그룹입니다. 테크레인저스 안에서도 활동분야가 나눠져있는데요. 저는 내부소통 활성화 분야에서 활동하고 있었지만, 교육분야에도 관심이 있어서 교육분야 회의할 때 슬쩍 들어갔었습니다.

당시에 대내외적으로 참여할 수 있는 스터디그룹이 만들어지고 있었고, 무언가 하자고 이야기가 나오더군요. 당시 몇 달 전에 한국장학재단에서 진행했던 기업탐방 및 대학생 멘토링에 멘토로 참여했었던 것이 기억에 많이 남기도 해서 제안을 하게 되었습니다.
그리고, 다른 분들이 동의를 해주셔서 진행하게 되었지요.

Q. 우아한멘토링 멤버는 멘토로 참여하는 우형 개발자분들이 직접 선발하였는데요, 어떤 기준으로 선정을 하였나요?

정재훈님(전 우형 근무, 현 스타트업 근무)

굉장히 많은 분들이 신청해 주셨는데요. 소수만을 선정해야 해서 어려웠습니다. ^^;;

우선, 멘토링 기회가 많을 수 있는 분들은 제외했습니다.
적어도 대기업에 다니시는 분들은 작은 기업에 다니시는 분들보다 기회가 많을 것이라 생각했습니다. 당연히 우아한형제들 구성원들도 제외를 했지요.

그다음으로, 신청 계기에 진심이 느껴지는 분을 먼저 선정했습니다.
(우아한형제들은 모든 것에 진심이니까요…? ㅎㅎㅎ)

가급적이면, 1팀 1인을 하고 있거나, 산적해 있는 업무를 홀로 감당하고 있는 것 같은 분들, 주위에 멘토 역할을 해줄 수 있는 분이 없어 보이는 분을 우선적으로 선정하려고 했습니다.

더 많은 분들과 함께하고 싶었지만, 여건이 그럴 수 없어서 많이 아쉬웠습니다.

Q. 높은 경쟁률을 뚫고 오신 분들이군요! 직접 참여해 보니 우아한멘토링과 기존에 알던 멘토링과의 차이점이 있었나요?

현정호님(스타트업 근무)

기존의 멘토링이 멘토가 멘티에게 1:1로 솔루션을 제시하는 방식이었다면,
우아한멘토링은 멘토는 물론이고, 다양한 환경에서 일하고 있는 많은 개발자들과 함께 각자의 고민과 관심사를 얘기하며 서로의 의견을 공유하는 자리였습니다.

정재훈님(전 우형 근무, 현 스타트업 근무)

보통은 멘토링을 하면 멘토의 경험을 공유하는 위주로 진행되는데, 우아한멘토링은 진행 방법 등 논의 과정에서 멘티분들도 멘토링의 진행에 직접 참여하는 형태로 진행되었습니다.

이 과정에서, 멘티의 고민을 공유하고, 이에 대해 멘토들이 의견을 이야기하는 형식으로 진행하니까 좀 더 실질적으로 멘티에게 도움이 되었고, 더 많은 주제에 대해 이야기를 나눌 수 있는 시간이 되었던 것 같습니다.

Q. 우아한멘토링은 멘티의 고민이나 사연을 매주 하나씩 다뤘는데요. 특별히 이야기 나누고 싶었던 고민 주제는 무엇이었나요?

장일규님(보험권 SI 근무)

저는 “성장”에 대한 고민이 있었습니다. 고객사 프로젝트에서 사용하는 기술들에 대해
“이직 시 기술 스택과 맞을까.? 내가 사용하고 있는 개발 환경은 괜찮을까..?”
라고 드는 생각들이 시간이 지날수록 불안하고, 점점 성장이 멈추고 있다는 생각이 들었습니다.

또한, 실무를 하다 보니 코딩과 별개로 업무적인 부분에 대한 흥미도가 있어야 하고, 전문 지식의 중요성도 깨달았습니다.

지금도 개발을 하고 있지만, 현재에 만족하지 않고 더 성장하고 노력하여, 전문가가 될 수 있는 도메인을 찾아야겠다는 생각을 하게 되었고, 여러 개발자분들에 경험과 조언을 듣고 싶었습니다.

이재상님(스타트업 창업)

저는 "개발 조직 문화와 협업 문화"라는 주제에 관심 있었습니다.
아무래도 제가 다른 경력이 있는 상태로 창업을 한 것이 아니기 때문에, 저희 팀이 맞게 개발을 하고 있는지, 다른 조직은 어떻게 개발하고 있는지 궁금했습니다.

이에 우아한형제들 개발자분들과 다른 멘티분들은 본인이 속한 개발 조직에서 어떻게 개발을 하는지와 조직 문화가 어떻게 구성되어 있는지 듣고 싶었습니다.

Q. 그렇다면 참여해 보고 나니 가장 기억에 남는 세션은 무엇인가요?

장일규님(보험권 SI 근무)

워킹 타임에 성장할 수 있는 방법이라는 세션이 가장 기억에 남습니다.
지금은 아니더라도 언젠가 저에게도 사수가 없는 환경에 놓일 수도 있고, 주니어 연차 때 멘토분들은 어떤 방법으로 성장하셨는지 무척 궁금했어요.

멘토분 중에 광휘님께서 사수가 없는 환경에서 성장을 위해 블로그를 시작하고, 피드백을 받을 수 있는 곳이 없어서 개발자 포럼에 코드를 올리면서 느낀 점은 "좋은 피드백"은 사수에게 나오는 게 아니라 "좋은 개발자"에게 나오고, "다양한 사람의 생각과 토론"이 거쳐져야 쓸만해진 다는 말이 인상 깊었어요.

언젠가 저에게도 사수가 없는 환경이 왔을 때, 극복할 수 있다는 동기 부여가 되었습니다.

신은지님(스타트업 근무)

모든 세션이 의미있었고 큰 도움이 되었지만, 역시 저는 제 세션 개발 방법론과 타 직군에 대한 이해 높이기가 제일 기억에 남네요ㅎㅎ

제가 계속 고민하던 것들에 대해 조언을 구할 수 있었고, 앞으로 무엇을 해야 할 지에 대해 그림을 그려볼 수 있었거든요.

추천해 주신 방법을 직접 적용해 보고, 또 새로운 문제를 찾고, 그걸 해결하는 과정을 반복하면서 멘토링 이전보다 확실히 즐겁게 일하게 되었어요. 팀원들과 소통하고 협업할 때 똑같은 이야기를 계속 반복하거나 했던 작업을 롤백하고 다시 개발하는 일이 많이 줄었죠.

Q. 우형 재직자로 참여한 재훈님의 느낀 점은 또 다를 것 같은데요. 타사 개발자들의 고민을 함께 나누며 느낀 점은 어떤 것이 있나요?

정재훈님(전 우형 근무, 현 스타트업 근무)

다들, 과거에 제가 했던 고민들도 비슷하게 하시더군요. 그래서 이런 자리가 더 소중하다고 생각합니다.

항상 고민거리는 많고, 생각한 대로 해보고는 있는데 잘 하고 있는 지도 모르겠고, 개선할 것은 계속해서 개선하고 싶고 해서 피드백을 되도록 많이 받고 싶어 하는데요.
직접적인 피드백이 아니더라도 이런 자리에서 각자 경험을 공유 받는 것만으로도 저에게도 좋은 피드백이 되었습니다.

이런 고민에는 세대 차이가 없는 것 같다는 생각도 들었습니다.

Q. 우아한멘토링 참여 전과 후 본인에게 느껴지는 어떤 변화가 있었나요?

이재상님(스타트업 창업)

우아한멘토링을 하고 나니 제가 가진 개발적인 고민을 다른 조직의 개발자분들과 깊게 이야기 할 기회가 많지 않았다는 점을 알게 되었습니다.
이에 우아한멘토링이 소중한 기회였고, 좋은 경험이 된 것 같아 뿌듯합니다.

아마 다음에도 우아한형제들에서 비슷한 프로그램을 진행하면 무조건 참여할 것 같습니다

신은지님(스타트업 근무)

사실 평소에 주위 개발자 지인들과 고민에 대한 이야기는 잘 하지 않는 편이에요.
왠지 일과 관련된 고민이나 커리어에 대한 이야기는 쉽게 꺼내질 못하겠더라구요.

하지만 우아한멘토링을 통해 내 고민을 말하고, 남의 고민을 듣고, 거기서 또 새로운 주제를 공유하면서 남들과 고민을 공유하는 게 큰 도움이 된다고 느꼈어요.
또한, 시야가 넓어지는 건 물론이고, 비슷한 관심사를 공유할 수 있으니 즐겁기도 했어요.

이런 기회가 좀 더 자주 있으면 좋겠다고 생각했고, 우아한멘토링 뿐만이 아니라 좀 더 다양한 개발자 커뮤니티에서 활동해 보고 싶습니다.

이번 우아한멘토링을 계기삼아 선후배, 또는 동료 개발자들이 아무런 대가가 없어도 적극적으로 서로를 돕는 개발 문화에 일조해보려구요ㅎㅎ

Q. 그렇다면 혹시 우아한멘토링에서 얻은 조언을 실제로 업무나 개발방법에 적용해보기도 하였나요?

신은지님(스타트업 근무)

네! 조언대로 개발 중 짧은 싸이클의 반복을 통해 빠르고 많은 피드백이 가능하게 했어요.
확실히 뭔가 완성물이 있으니 피드백을 받기도 쉽고, 어디에 문제가 있는지, 또는 어디서 문제가 발생할 여지가 있는지 빠르게 캐치할 수 있었습니다. 데일리 스크럼에서 진행상황이나 고민을 공유하면서 일정의 조율과 계획의 수정도 이전보다 훨씬 수월하게 해낼 수 있게 되었어요. 채팅방이나 오프라인에서 빠르게 오고간 이야기들을 최대한 모두 백로그를 남기면서 변경사항을 잊지 않고 체크하는 습관도 가지게 되었구요.

리팩토링과 코드리뷰도 적극적으로 시도해 봤습니다. 과거의 내 코드를 마주하면서 참 많은 생각이 들더라구요.
스스로도 몰랐던 코드 습관도 알게 되었고, 앞으로 이런 일은 절대로 하지 말자는 다짐도 해본 적이 있습니다.
예전에 짰던 코드를 수정하면서 오히려 처음 코드를 짤 때보다 더 많이 공부한 것 같아요ㅎㅎ

(기록의 흔적)

Q. 두 달간의 대장정! 우아한멘토링 참여한 소감과 느낀 점을 말씀해 주세요.

현정호님(스타트업 근무)

제가 느낀 우아한멘토링의 가장 큰 장점은 "다양한 환경에서 일하고 있는 개발자들과 소통"입니다.
우아한형제들의 개발자와 스타트업에서 다양한 환경에 있는 개발자들과 각자의 고민과 관심사를 얘기해 볼 수 있다는 것 자체가 저에게는 너무 큰 장점으로 다가왔습니다.

멘토링을 진행하면서 많은 것을 배웠습니다. 저에게 너무 소중한 시간이었고 다음에 또 이런 기회가 온다면 꼭 참여하고 싶습니다!

장일규님(보험권 SI 근무)

멘토님 말씀 중에 "회사는 목적이 있는 집단이고 급여를 주는 곳이기에, 개인의 목표와 성장을 회사 업무에 억지로 쑤셔 넣으면 안 된다."라는 말이 저를 돌아볼 수 있는 시간이었습니다.
과거의 저는 최종 목표를 이루기 위한 추상적인 목표는 있었지만, 단기적이고 구체적인 목표가 없었어요.

우아한 멘토링은 끝났지만, 멘토, 멘티분들의 조언과 경험으로 느낀 것들을 통해 제가 고민했던 것들을 극복하기 위한 목표를 세워봤습니다.

저의 공부 방법은 책과 인터넷 강의를 통해서 깃헙에 정리하는 게 전부였지만, 2022년부터는 프로젝트 베이스로 무언가를 만들어 보고, 그 안에서 나아가고, 정리하고 학습한 내용들을 적용해 보려고 합니다.

이번 멘토링을 통해 성장에 있어서 가장 중요한 건 주변 환경에서 성장을 제공해주는 게 아니라 스스로 성장을 위해 노력하고 쟁취해야 한다는 것을 깨달았습니다.

• 일규님의 우아한멘토링 회고 글

Q. 마지막으로 못다한 이야기가 있다면요?

현정호님(스타트업 근무)

두 달이라는 시간이 너무 빠르게 지나간 것 같습니다.

멘토링을 진행하면서 저는 얻은 것이 많지만 반대로 제가 다른 분들에게 도움을 드린 부분은 별로 없는 것 같습니다.
당시 저는 사수 없이 혼자서 스타트업에 입사한 신입 개발자였기 때문에, 제가 알고 있던 지식이 너무 제한적이었습니다. 사실 멘토링을 진행하면서 단어의 의미를 몰라서 중간중간에 구글링을 했던 적도 있었던 만큼 많이 부족했다고 생각하는데요. 이러한 부분에서 죄송스러우면서도 한편으로는 동기부여가 되었습니다.

좋은 기회 주셔서 감사합니다!

(모든 것이 끝나고 회고 겸 인터뷰하는 마지막 모습)

우아한멘토링은 우아한스터디 중 하나로 시도해 본 과정이었는데요. 단순한 스터디 모임으로 보기는 어려운, 그렇다고 널리 알려진 멘토링 방식과는 사뭇 다른 새로운 시도였습니다.

우아한멘토링을 통해 어쩌면 만날 일이 없었을, 서로 다른 소속과 경험을 가진 개발자가 모여 같은 주제로 공감대를 형성하며 이야기를 나눴다는 것이 흥미로운데요.
오히려 서로 다른 소속과 환경에 있기에 더 솔직하게 각자의 고민을 털어놓을 수 있던 것은 아니었을까 하는 생각도 듭니다.

우아한형제들 Developer Relations 는 내&외부 개발자가 함께 성장하고 교류할 수 있는 기회를 만들어나가기 위해 노력하고 있는데,
DevRel 담당자로서 이번 우아한멘토링을 통해 소그룹이더라도 조금 더 자유롭게 서로가 소통할 수 있는 시간을 앞으로도 시도하면 좋겠다고 생각해 본 계기가 되었습니다.

각자의 고민과 경험을 솔직하게 공유해 주신 우아한멘토링 멤버 여러분에게 감사를 전하며, 앞으로의 길을 늘 응원합니다.

왜 코드리뷰를 해야할까요?

많은 개발자들은 흔히들 말하는 “백발의 개발자"를 꿈꿉니다.
그렇게 되기 위해서는 경력이 쌓이는 만큼 그에 걸맞은 개발자로서의 역량을 갖추어야 합니다.
학교에서 교수님에게서 배운 것으로 SW 개발 역량은 부족합니다.
현업에서 개발자들의 역할은 자신의 이론이나 알고리즘을 구현하는 것으로 끝나는 것이 아니라
첫 출시(Delivery) 후에 지속적으로 요구되는 기능 변경, 추가 등의 요구사항을
안정적으로 빠르게 반영하는 운영성 개발이 더 많은 비중을 차지하기 때문입니다.

코드리뷰는 출시 전에 결함을 발견하는 것이 가장 중요한 목적이겠지만,
팀원들과 주고받는 피드백을 통해 상호 성장을 할 수 있는 가장 좋은 활동이라고 생각합니다.

일반적으로 SW는 출시가 계속될 수록 개발 리소스가 더 많이 요구되지만 생산성이 저하되는 특성을 자주 보입니다.
코드리뷰 활동은 업무 수행을 통해 주고받는 공유를 통해 출시가 계속되어야
SW의 개발 생산성이 저하되지 않고, 또 개발 비용을 높이지 않아서
생산성 향상에 기여할 수 있는 실행 안이라고 생각합니다.

본 강연에서는 이러한 측면에서 왜 코드리뷰를 해야 하는지?
코드리뷰가 왜 어려운지? 효율적인 Pull Request 작성기법과 리뷰 기법,
코드 리뷰를 잘하기 위해 필요한 기술 등에 대해서 알아봅니다.
마지막으로 코드리뷰 강의를 하면서 나왔던 질문들에 대해서 알아봅니다.

추천대상

• Java 기반으로 설명을 하지만 기술 스택과 무관하게 개발자로서 성장을 고민하시는 분들
• 개발 조직의 생산성에 대해서 고민하시는 분들(개발 리더, 기획/사업 부서 리더 등)

‍연사소개

백명석 / SK Planet, 11번가 자문위원

초등학교 때 퍼스널 컴퓨터를 처음 접하고 막연히 컴퓨터공학과를 가야겠다고 생각했습니다.
아주 단순한 프로그램이었지만 내가 작성한(사실 거의 단순 타이핑 수준) 프로그램이
동작하는 것에서 즐거움을 느꼈고, 계속해서 새로운 것이 나오고
이를 공부하고 실행되는 것에 아직도 즐거움을 느끼는 것 같습니다.

지속적으로 발전할 수 있는 SW 개발에 관심이 많고,
복잡한 비즈니스 로직을 알아보기 쉽게 풀어내는데 관심이 많습니다.
회사와 서비스를 위해 개발조직의 나아갈 방향을 세우고
구성원들과 소통하고 Align 하여 함께 목표를 향해 달려가는 것을 많이 해왔습니다.
개인적으로는 Java, 객체지향, TDD(특히 Refactoring), 개발 문화, 개발자 성장, 코칭 등에 관심이 많습니다.

• SKPlanet / 11번가(주), 2016.11-현재(그룹장, 자문위원)
• Daum / Kakao, 2006.03-2016.10(유닛장, 파트장)

지난 우아한테크세미나가 궁금하다면?

우아한Tech 유튜브에서 확인하세요! [클릭]