[ WIL ] 8-2, 이전 기록(7월 요약) 개발에 대하여(개발 문화, 개발 실력, 비즈니스와 개발), 고객에 대하여(고객 중심의 개발, 비즈니스 중심의 개발, 기술 중심의 개발)

이전 기록, 개발에 대하여, 고객에 대하여

 

벌써 8월 2주차이다. 회고글을 쓸 때면, 날짜에 적응하기가 쉽지 않다. 분명 마지막 포스팅이 지난 주인 것 같은데, (작성 시점)가장 마지막글과 시간차이는 벌써 한달이다... 오늘도 나는 반성한다.. 주마다 이슈가 없어서 기록할 내용이 없었더라면, 이런 생각이 들지 않았을 텐데(설령 이렇다면, 공부 기록을 내용으로 추가하지 않았을까?) 매주 수 많은 이슈들이 발생했기에, 이를 기록하고 돌이켜보는 행위를 하지 못한(혹은 안한)것에 대해 아쉬움이 많이 남는다. 

 

나는 옵시디언을 통해 매일 업무 일지를 작성하고 있다.

 

그래도 이러한 불행(?)중 다행으로 매일매일 작성하는 DailyRocrd를 통해 지난 날들을 돌이켜볼 수 있었다. 최근들어 DailyRocrd(이하 기록)의 덕을 많이 보고 있다. 정신없이 진행되는 일정 속에서 잊거나 잘못 기억하는 일을 바로 잡을 수 있었다. 

 

최근에는 내 스스로 기억의 한계를 많이 느끼고 있기에, 좀 더 기록에 집중해야 겠다. 업무도, 개인적인 기록도 말이다.

 

내용 구성
- 이전 기록
- 개발에 대하여
- 고객에 대하여

 

 

---

이전 기록(7월 ~ 현재까지)

 

사실 아직도 7월이 지나갔다는 사실이 믿기지는 않다만(기록을 안한것을 믿을 수 없다..) 지난 날들에 대한 기록을 빠트리기에는 너무 귀한 경험들이 있었기에, 간략하게라도 기록해보고자 한다. 내용은 (있을만한 것도 없긴하다만) 한치의 거짓도, 과장도 없다.

 

 

7월 1주차

회사의 엄청난 위기에 직면한 뒤, 이를 극복하기 위한 시도로서 개발 스프린트가 처음으로 시작된 시점이었다. 최소한의 기획과 최소한의 필요한 기능을 정의하여, 고객 중심의 개발, Lean한 개발을 추구하기 시작한 시점이다.

 

스프린트는 2주단위로 지정이 되었으며, 나의 첫 스프린트는 알림톡 자동화 작업과 개발 환경 재설정이었다.

• 알림톡 자동화 작업: 운영에서 수동으로 발송하는 알림톡을 자동화 하는 작업으로, 운영의 리소스를 효율적으로 사용하기 위해 작업 우선순위의 첫번째로 선택이 되었다.
• 개발 환경 재설정: 4월~ 6월까지 3개월간 업무를 진행하면서, 시도했던 개발 환경 세팅(Git 전략, 컨벤션 등)의 비효율성, 설계의 오류 등을 개선하기 위해 우선적으로 작업 대상이 되었다.

 

7월 2주차

주된 업무는 스프린트 작업이지만, 스프린트 작업의 문제점을 바로 경험할 수 있었다.

• 스프린트 업무를 진행하기 위해서는, 사전작업(기획, 개발 기획)이 진행이 되어야 한다.
• 실무에서는 스프린트 업무 이외에도 핫픽스, 개선 사항, 요청사항, 데이터 추출 등 다양한 업무가 존재한다.

스프린트 개발을 하기 위해서는 기획이 필요했는데, 나는 기획 이전에 명확하게 해야할 업무가 없었다. 조금 더 정확하게는 할 업무들이 많았지만(핫픽스, 버그 개선) 정리가 되어 있지않고, 구두로 두리둥실하게 떠다니고 있어, 내가 잡을 수가 없었다.

• 식사 혹은 고객과 미팅을 통해 접수된 불편사항(개선사항)은 기록되고 있었으나, 개발 측면에서 해당 사항이 관리되지 않고 있었다.
• 기록된 내용은 다른 내용에 묻혀 조금씩 잊혀지다, 다시 해당 이슈가 언급 되었을 때, 이야기가 되는 문제가 있었다.

 

나는 백로그를 노션을 통해 관리했다.

 

이를 개선하고자, 백로그 개념을 도입했다. 동기적인 스프린트 작업에 대하여, 효율적으로 업무를 진행하기 위해 도입하였는데, 기대이상으로 만족스러웠다.

 

• 개선 사항을 개발 측면에서 인지할 수 있게 되었다.(관련 작업이 있는 경우, 함께 작업할 수 있었다.)
• 버그(개선 사항)을 잊지 않게 되었다.
• 개발 업무를 조금 더 효율적으로(독립적, 비동기적)으로 할 수 있게 되었다.
• 시스템이 개선되는 것을 시각적으로 확인할 수 있었다.(팀원간 소통 개선)

 

우리의 스프린트 첫 배포. 버전이 올라갔다.

 

그리고 드디어 첫 스프린트 배포가 이뤄졌다. 첫 버저닝 업데이트였는데, 사소한 부분이지만 감회가 새로웠다.

 

7월 3주차

1회차 스프린트가 마무리 된 뒤, 사전에 식별되지 못한 개선사항, 문제점을들 수정하느라 정신이 없었다. 7월 3주차에는 기능 개발 시, 사이드 이펙트의 무서움을 다시금 인지하게 된 한 주였다.

 

7월 4주차

스프린트 2회차가 마무리되는 한 주로서, 2회차 스프린트에서는 후기문제를 개선하는 작업을 진행했다. 개발 스프린트 2회차를 진행하면서, 나는 역시 프론트엔드 영역에 취약함을 느끼기 되었다. 우스갯소리로 HTML, CSS는 코딩이 아니라고 하는데, 나는 가장 어려운 영역이 HTML, CSS이지 않나? 하는 생각을 한다.(레거시를 추적하는 전재하에..)

 

7월 5주차

2회차 스프린트를 진행하면서, 기획 때보다 거대해진 개발 범위 탓에 백로그를 처리하지 못했다. 이로 인해 백로그가 상당히 많이 쌓였있었는데, 7월 5주차에는 백로그를 처리하는 작업에 포커스를 맞춰 작업을 진행했다. 

 

백로그를 작업할 때면, 고객 피드백 혹은 운영 피드백이 즉각적으로 오게 되는데 고객 만족 피드백을 받게되었을 때 아드레날린은 그 어떤 아드레날린보다 더 강력한 듯 하다.

 

각 주차별 작성하지 못한 더 많고 다이나믹한 이슈들이 많았으나, 정말 간력하게 정리해보았다. 이전 작성한 기록들을 다시 다 확인하면서 크게 두가지의 생각이 들었는데, 조금 웃프다.

• 정말 정신없이 개발만 하며 살았구나
• 정말 정신없이 열심히 개발했는데, 생각보다 큰 임팩트를 내진 못했구나

 

이러한 생각, 그리고 이번 8-2주차 발생했던 다양한 일들을 바탕으로 이번주 회고를 시작해본다.

 

---

개발에 대하여

 

나는 개발을 정말 좋아한다. "왜 개발이 좋냐?" 질문한다면,  이전에는 "문제를 해결하는 과정이 즐겁다." "설계를 하는 것이 무대를 만드는 것 같아 재밌다.", "정답은 없지만 오답은 있는 분야라서", "개선해 나가는 과정에서 아드레날린이 난다" 등 다양한 이유들이 먼저 떠올랐는데, 이제는 그냥 좋다라는 말이 먼저 나오는 듯하다. 나는 개발을 "개발이라서 좋아한다."

 

하지만 최근들어 많은 고민들이 생겼다. 이전에는 하지못한 고민들인인데, 크게 3가지의 내용들이다.

• 비즈니스와 개발: 비즈니스는 사회의 문제(충족되지 못한 영역)를 해결할 때, 그 사업의 임팩트가 존재한다. 그리고 개발은 문제를 해결한다.
• 개발 문화: (천재 개발자가 아닌 이상)개발은 혼자 할 수 있는 영역이 아니다. 혼자 할 수 도있지만, 내가 생각하는 이상향을 생각해본다면, 개발은 절대 혼자 할 수 없다. 개발 팀 내부뿐만아니라, 개발팀-외부 에서도 말이다.
• 개발 실력: 개발 실력은 중요하다. 하지만, 어떤 것이 개발을 잘한다고 할 수 있는가? 에 대한 질문과 답을 할 때, 그 답은 상황에 따라 다르다.

 

비즈니스와 개발

비즈니스와 개발, 비슷하면서도 다른 것 같다.

 

비즈니스와 개발은 밀접하게 연관되어 있음에는 부정할 수 없는 사실이다. 연관이 있다고 하면, 비즈니스와 개발 사이의 조화(조율)이 절대적으로 중요한데, 나는 개발자라서 인지 개발(메인)을 비즈니스(서브) 중심적(이하 전자)으로 바라보고 있었다.

• 내가 생각하는, "개발영역에서의 비즈니스 중심적으로 바라본다는 것"은 (사용할 수 있는)기술을 기반으로, 고객 중심적, 도메인 중심적 개발을 진행하는 것을 의미한다.

 

하지만, 최근에는 비즈니스(메인) 중심적인 사고에서 출발하여, 개발(서브)을 적용하는 생각(이하 후자)으로 전환되고 있다.

• 내가 생각하는, "비즈니스에서 개발 중심적으로 바라본다는 것"은 고객 중심적, 도메인 중심적 생각을 기반으로, 개발을 진행하는 것을 의미한다.

 

사실 전자와 후자의 차이는 종이한장 차이이다. 전자와 후자 모두 고객 중심적, 도메인 중심적 개발을 진행한다는 결과적인 공통점이 존재하기 때문이다. 다만 차이점은, 비용을 기술비용(기술 부채 등)으로 볼것이냐, 혹은 사업적인 비용(인건비, 매출와 같은 실제 비용)으로 볼것이냐? 의 차이라고 생각을 한다.

 

 

개발영역에서 비즈니스 중심적으로 생각하기

나는 개발이 있어 비즈니스가 존재한다 생각했다.  그러나 이러한 생각에는 잠재적인 큰 문제점(위험요소)이(가) 존재한다.

• 비즈니스에 쓸모없는 개발을 하게될 가능성이 높아지게 된다.
• 팬시한 기술과 열정을 쏟아부어 개발을 진행하였으나, 실제 해당 기능을 사용하는 사람이 없을 수 있다.
• 결과적으로, 도박적인 개발이 이뤄진다.(사업적으로나, 개인적인 부분(동기부여)으로서)

이러한 잠재적 위험요소를 인지한 뒤에는 나의 생각이 후자로 변경되게 되었다.

 

 

비즈니스 영역에서 개발 중심적으로 생각하기

전자의 생각에서 개선된(?) 생각으로 나는 비즈니스 영역에서 개발 중심적으로 생각하는 생각으로 바뀌게(성장) 되었다.

• 비즈니스가 있어 개발이 존재하며, 우리(개발자)는 비즈니스 중심적인 사고로서, 기능개발을  해야한다.
• 비즈니스에 필요한 기능개발(고객의 충족되지 않은 문제점)을 통해 비즈니스적 임팩트를 낼 수 있다.

이러한 생각 관점의 전환을 이후, 우리의 서비스(큐리어스)의 개발에 대하여 다른 시각으로 접근하기 시작했다.

 

 

개발문화

뛰어난 개발문화를 가진 팀의 모습을 보여달라고 했다. 우리 팀의 모습같기도하고..

 

팀 문화는 중요하다.(팀핏은 어떠한가?)

그러나, 이러한 생각을 하는 것에서 가장 중요한 것은 "문화"이다. 팀문화가 "개발 -> 비즈니스 중심"이라고 한다면, 내 생각은 잘못된 생각이 된다. 나는 다행이도, "비즈니스 -> 개발 중심"의 팀 문화를 가진 팀에 속해 있다.

• 팀 문화는 사내 전체, 개발 영역 모두 동일하다.(비즈니스 중심 -> 개발 중심)

그리고 "팀 문화는 계속해서 변화한다(흐른다)"고 생각하기에, "특정 생각(전자 혹은 후자)의 생각이 항상 옳다 혹은 특정 생각이 맞고 틀리다라고 말하는 것은 잘못되었다"고 생각한다.(상황에 따라 다르다.)

 

 

만약 개발(기술)중심적인 개발을 한다면?

비즈니스 중심의 개발을 진행하면서, 마음한구석에는 사용하고싶은 이상적인 기술중심의 개발이 존재하긴한다. 최근에는 이와 관련하여 함께 일하는 대엽님(CTO)과 이야기를 나눴는데, 이 대화 속에서도 내 개인적인 많은 변화가 있었다.

• 지날 날의 나는, 개발의 최종 종착지는, EDA(Event-Driven-Architecture), DDD(Domain-Driven-Design)이라고 생각했다. 그리고 사용해보고 싶고, 적용해보고 싶은 기술 1순위로 두가지를 뽑았다.
• 현재의 나는, 비즈니스적으로 반복되는 일, 비용이 많이 지출되는 일을 해결하고싶어한다. 이와 관련하여, CI, CD 적용, K8S 적용 등고객에게 안정적이고 지속적인 서비스를 제공하기 위해 필요하다 생각되는 기술을 적용하고 싶다는 생각이 들었다.

 

나는 성능 최적화에 관심이 많았다. 하지만, 성능 최적화를 위해 기술적으로 Deep(?)한 기술의 필요성은 생각보다 비즈니스에서 필요하지 않은 경우가 많다는 것을 깨달았다. 생각보다 성능 최적화가 필요한 수준의 비즈니스는 가까운 미래보다는 먼 미래에 가까웠다.

하지만 이 이야기의 전제는 "최소한의 아키텍처를 갖추고, 최소한의 기능 요구사항을 구현했다는 전제하에, 트래픽의 증가로 인한 성능최적화의 필요성이 언급되었을 때"를 기준으로 이야기한다.

 

 

개발 실력

잘하는 개발자의 모습이라고하는데... 일단 나는 아닌듯 하다.

 

잘(?)하는 개발자

비즈니스 중심이든, 개발 중심이든, 다른 어떤 생각이 되었든 개발자는 개발을 잘해야한다. 그런데 최근에는 개발을 잘한다는 것에 대해 스스로의 생각 확립이 되질 않는다.

• 기능 개발을 빠르고 정확하게 이뤄내는 것이 잘하는 개발자이다.(빠르고 정확하게의 기준은 무엇인가?)
• 비즈니스적 측면에서 다양한 시도를 할 수 있도록 유연한 (아키텍처) 설계를 할 수 있는 개발자가 잘하는 개발자이다.(다양한 시도의 기준은 무엇인가?, 유연함의 기준은?)
• 고객과 소통(혹은 팀과 소통와)와 같은 소프트 스킬이 뛰어난 개발자가 잘하는 개발자이다.(소통이 잘된다의 기준은 무엇인가?)

 

정답은 없다는 것을 알고 있으나, 나는 잘하고 싶다. 그렇다면, "어떤 것이 잘하는 것인가?" 에 대한 기준을 세워야하는데 아직 세우질 못했다. 

• 작성일 기준, 내가 세운 잘하는 개발자는, 비즈니스적 다양한 시도를 할 수 있도록, 유연한 아키텍처를 설계할 수 있는 사람이다.
• 유연한 아키텍처를 설계할 수 있는 사람은 선택을 최대한 늦출 수 있도록 하는 설계를 하는 사람이다.
• "비즈니스적 다양한 시도는, 프로그래밍 설계를 실제 비즈니스와 (최대한)동일하게 설계되었을 때 이뤄 낼 수 있다" 생각한다.

 

 

---

고객에 대하여

 

개발에 대하여 다양하게 고민하게되면서, 자연스럽게 이어지는 고민에는 고객에 대한 고민이 있었다. 어떤 것을 중심으로 생각하느냐에 따라 고객의 정의가 조금씩 달라졌기 때문이다.

• 고객중심의 개발: (고객은 실제 우리 서비스이용자를 의미하며, 우리의 고객에는 리더와 수강자가 존재한다.)고객 중심의 개발에서는 리더중심의 개발 혹은 수강자 중심의 개발을 하게 된다. 하지만, 리더(혹은 수강자)중심의 개발은 고정되지 않는다.
• 비즈니스 중심의 개발: 비즈니스 중심의 개발에서는 비즈니스가 고객이 된다. 고객에게 필요한 것을 제공하는데, 즉 비즈니스에게 임팩트가 있는 개발을 하게된다.(사업중심적)
• 기술 중심의 개발: 기술중심의 개발에서 고객은, 개발자(기술)이다.  팬시한 기술을 사용하고, 적용한다.

 

일단 가장먼저, 기술 중심의 개발은 제외하였다. 그리고 남은 고객중심의 개발, 비즈니스 중심의 개발이 핵심이 되었는데, 이와 관련하여,  흥미로운 CEO와 CTO 사이의 대립이 있었다.

• 기술중심적인 개발은, 이전에 이미 잘못된 생각이라 생각했기 때문에 고객에 대한 고민에서 제외하였다.

 

우리가 생각하는 고객(은 다르다.)

프로덕트의 방향성을 이제는 CTO가 잡아가기로 하였는데, 이와 관련된 일정과 개발 우선순위를 정할 때, 서로 중심적으로 생각하는 부분의 차이 때문에 발생한 문제였다.

• CEO: 비즈니스적으로 이득을 볼 수 있는 개발을 우선적으로 하자.
• CTO: 우리는 고객중심의 개발을 진행할 것이고, 이를 기반으로 하게된다면, 비즈니스적 임팩트는 자연스럽게 따라올 것이다.

사례를 언급하여 이야기할 때, CEO와 CTO 사이의 차이점은 정말 종이한장 차이라는 것을 알 수 있었다.  두분의 공통점은 고객중심이었지만, 생각의 근본(Root)이 달랐다.

• CEO: 비즈니스에서 시작하여, 고객을 고려한다.(비즈니스적인 행동1을 하자! 이러면 고객에게 이런 효과도 줄 수 있어.)
• CTO: 고객의 문제에서 시작하여, 비즈니스를 고려한다.(고객은 이러한 문제를 겪고있어. 이 문제를 해결하는데, @비용이 소모되고, @한 비즈니스적 임팩트를 가질 것으로 예상돼)

 

이러한 흥미로운 대화 이전에 나는 이미 고객중심의 생각이 중요하다 생각하고 있었기에, CTO분의 생각에 조금더 편향된 생각을 하고 있었다. 하지만, 반대되는(?) CEO의 입장과 생각을 들어보면서, 현재 중요시하는 "고객중심적인 사고"는 다소 위험할 수도 있겠다는 생각이 들었다.

• 고객의 문제에서 시작하는 사업은 안전을 추구하는 방식이다.(혁신을 만들어 낼 수 없다.)
• 고객의 문제에서만 시작하려는 행동은 앞으로 나아갈 수 없다.(힘들다.)

 

어느정도 공감이 되는 내용이기도 했으나, 이에 대하여 나는 반대되는 의견이 떠오르기도 했다.

• 혁신은 새롭고 팬시한 것을 만들어 내는 것만이 혁신이 아니다. 내 불편함을 해소할 수 있는 것만으로도 충분히 혁신이될 수 있다.
• 발생할 수 있는 문제를 고려하는 것은 좋은 사고이나, 발생하지 않은 문제를 위해 행동하는 것은 (다른것이 완벽하지 않는 이상)위험한 투자이다.
• 우리는 위험요소를 최소한으로 하며, 최대한의 효과를 볼 수 있는 행동을 해야한다.

 

하지만 하나 분명한 것은, "고객 중심의 사고도 중요하지만, 비즈니스적인 사고 또한 상당히 중요하다"는 것이다. 

• 고객 중심의 사고를 할 때, 고민이 될 때면 비즈니스적으로 고민해보자.
• 고객 중심적인 사고를 하고, 비즈니스적으로 고민을 했는데 고민이 해결되지 않는다면, 개발적으로 고민해보자.

 

결국 어느하나 중요하지 않은 것이 없다. 핵심은 "상황에 따라 중요한 것이 계속해서 변화한다"는 것이다. 상황에 따라 다르다는 말을 개인적으로 싫어하는말이지만, 이럴 때 만큼은 정말 최고로 적절한 문장이 아닐까? 

• 나는 "상황"이라는 것을 구체적인 예시와 근거를 들수 있는 실력과 경험이 부족하여 지금와 같은 표현의 한계를 갖고있다.

 

---

8-2주차를 돌이켜 볼 때

 

8월 2주차는 한주동안 느낀 생각보다는 그간 있었던 일들을 정리하고, 생각을 정리하는 한 주였던 것 같다. 개발적인 고민은 줄어들고, 고객에 대해 고민하고, 사업에 대해 한번더 생각해보는 시간이 많았다.

 

개발적인 고민은 사실 기본값이었다는 표현이 조금 더 적적한듯싶다. 다만, 개발(기술)적 고민은 자연스럽게 줄어들게되었고, 고객의 목소리에 조금 더 집중하게 되었다. 

 

3분기 팀 KPI, 개발 KPI를 달성하기위해 한주간 정말 열심히 달렸는데, 남은 기간동안도 열심히 더 달려봐야겠다.

 

 

개발 좋아! 사업 재밌어! 고객 목소리 행복해! 난 행복해!!