배민 개발 문화가 궁금하다면? 요즘 우아한 개발

 

 

Keyword : 데일리 스크럼과 회고

업무 시작 전 함께 모이는 데일리 스크럼 시간을 가집니다. 이 시간에 실제 업무에 참여하는 것처럼 파일럿 프로젝트의 진행 상황이나 이슈를 공유합니다. 이 외에도 한 주를 되돌아보는 주간 회고도 함꼐 진행하는데요, 주간 회고는 한 주를 마무리하는 금요일에 다음과 같이 진행합니다.

• 배포 일정을 함께 보면서 이슈 체크
• 일주일 간 공유한 정보 소개 및 관련한 내용에 관해서 이야기
• 논의가 필요한 내용에 대해서 회고 시간을 활용해서 논의 진행
• 한 주간 진행했던 업무에 대해서, 진행하면서 겪은 이슈를 공유하며 마무리

: 데일리 스크럼과 회고하는 문화가 부러웠다. 반성을 해야만 성장을 할 수 있다고 생각한다. 회사생활을 하다보면, 정말 하루가 빨리가고, 한 달, 몇 년이 순식간에 지나간다. 이런 시간이 헛되지 않으려면, 회고 하는 문화가 정착되어야 한다.

 

회고가 되지않으면, 스스로의 문제점에 대해서 파악할 수 없고, 몇 년째 일해도 제자리를 맴도는 결과로 이어질 수 있다고 생각한다. 매주 공유와 회고를 꾸준히 한다면 분명히 과거보다 꾸준히 나아질 것 같다.

 

그리고 공유를 하면, 스스로가 어려워하는 문제점은 누군가에게 식은 죽 먹기일 수 있기에 업무적으로 조금 더 효율적으로 돌아갈 것 같다. A라는 지점에서 Z라는 목적지까지 갈때에 과정에서 이정표가 없으면 전혀 다른 W, X 지점으로 도달할 수있다.

 

반대로, 중간중간 방향성에 대해서 의심하면서 조정해간다면, 원래 일정보다 조금 더 걸릴 수는 있지만, Z라는 목적지로 정확하게 갈 수 있다고 생각한다. 이런 중간중간의 방향성의 조정이 공유와 회고에 있는 것 같다.

 

 

 

Keyword : 문서

일반적으로 문화는 코딩 그 다음인 경우가 많습니다. 하지만 B마트 프론트엔드 파트에서는 업데이트되지 않은 문서를 발견하면 즉시 최신 내용으로 업데이트하는 것이 우선입니다. 그만큼 문서화가 중요한 문화로 자리 잡고 있습니다. 실제로 온보딩을 진행하면서도 문서가 잘 작성된 덕분에 많은 궁금증의 해답을 언제든지 쉽게 찾을 수 있었습니다.

: 최근 문서화에 대해서 중요성을 느끼고 있다. 이번 '요즘 우아한 개발' 책을 읽고나서 팀 단위로 문서화가 힘들지라도, 개인적으로라도 문서화를 해야겠다라는 필요성을 느꼈다.

 

문서화 분류 예

1. 업무 흐름도 만들기

• 중학생이 봐도 한눈에 이해할 수준의 업무 흐름도 간략화해서 만들기
• PPT로 만들어서 문서화해두면, 인수인계할 때에도 좋을 것 같

 

2.자주쓰는 코드 템플릿화

• 자주 쓰는 코드들에 대해서 바로바로 복붙해서 가져다 쓸 수 있도록 템플릿화하면 화면 개발이 쉬워진다.
• 화면코드 뿐만 아니라 자주쓰이는 유효성 체크나 기능코드들에 대해서 추가적으로 템플릿화를 한다.

 

3. 개발 중 에러 기록

• 개발하는 과정에서 에러들을 모아두는 문서. 에러기록들을 모아두면, 팀원들이 에러를 만났을 때 같은 이유에서 에러가 발생했다면 에러 기록 참고해서 빠르게 해결이 가능함 > 결론적으로 업무시간 단축가능

 

 

 

 

Keyword : KPI ( Keep, Problem, Try )

Keep : 잘하는 점, 계속 했으면 좋겠다 싶은 점

Problem : 뭔가 문제가 있다 싶은 점, 변화가 필요한 점

Try : 잘하는 것을 더 잘하려면, 문제가 있는 점을 해결하려면 우리가 시도해볼 것들

: 이 부분은 비단 업무뿐만 아니라 개인적인 삶에서도 적용해보고 싶은 개념인 것 같다. KPI.

 

 

 

 

Keyword : 반복되는 질문

똑같은 질문을 100번 하면 100번이라도 대답해주겠어요

 

우리 팀에서 경계하는 것 중에 하나가 '반복되는 같은 질문에 신경질적인 반응을 보이는 것'입니다.

 

같은 질문이 계속된다는 것은 업무 프로세스상 문화가 덜 됐거나, 의사소통이 명확성이 떨어지는 등의 문제가 있다고 볼 수도 있습니다. 또 어쩌면 해당 비즈니스 프로세스 자체가 문서화로는 해결되지 않을 정도로 복잡할 수도 있습니다.

질문한느 것을 막아서는 안 되겠지만 질문이 왜 반복되는지, 그럴 필요가 없게 만들 수는 없는지 고민이 필요해 보입니다. 문제의 초점을 '질문하는 사람'에서 '질문받는 사람'으로 돌립니다. 질문하는 사람에게 '왜 자꾸 질문해요?'라고 나무라는 게 아니라, '왜 자꾸 같은 질문이 나올까? 내가 질문을 덜 받으려면 어떻게 할까?'라고 생각해보는 것이지요.

: 너무 맞는 말이다. 후임이 계속해서 같은 질문을 한다면, 귀찮아할게 아니라 '문서화'할 기회일 수 있다.

 

문서화가 잘 되면 서로 편해진다. 누군가 똑같은 질문을 반복한다면, '문서화'할 기회라고 인식하고, 시간을 들여서라도 꼭 문서화를 해야겠다.

 

당장에 시간이 들지만, 장기적으로 오히려 시간을 아끼는 것과 같다.

 

 

 

 

 

Keyword : 약간의 설명은 필요해

코드와 최대한 가까운 거리에 주석으로 이유를 적어두는 것이 좋습니다. 최소한 관련 사항이 명시된 문서 링크라도 달아두어야 합니다. 주석보다 더 나은 방법은 500원을 더하는 테스트 코드를 명확하게 작성해두고, 테스트 코드의 메서드명 혹은 설명에 이유를 적어두는 겁니다.

: 가끔씩 코드를 짜다보면, 다시 봤을 때 이해되지 않을 것 같은 코드를 만들기도 한다. 로직자체가 복잡한 코드는 변수명을 아무리 정성스럽게 만들어도, 제3자가 봤을 때 이게 무슨 코드인지 단번에 파악하기 힘들다.

 

이럴 때에는 주석을 달아줘야 한다. 주석을 너무 길게 달기보다는(오히려 더 피곤해짐) 핵심만 간단하게 달아준다. 특히 해당 코드 가까이에..!

 

ps. 물론, 가장 좋은 코드는 주석이 필요없도록 깨끗하게 짜여진 코드다. 깨끗한 코드는 짧은 코드를 의미하지 않는다고 생각한다. 효율적으로 기능을 하면서, 제3자가 코드를 봤을 때 일반적인 독서를 하는 것처럼 자연스럽게 읽히는 코드라고 생각한다.

 

 

 

 

 

 

Keyword : 통합시연

통합 시연의 목표는 성공이 아니라 실패를 빠르게 잡아내는 데 있습니다. 최선을 다해 시연을 준비하되 뭐가 문제인지 파악하는 데 주안점을 둡니다. 실패를 비난하는 것은 시연의 목표가 아닙니다. 시연의 목표는 여러 팀이 만든 각종 API는 의도대로 구현되었고, 호출되고 있는가? 기획자의 의도대로 구현된 것이 맞는가? 기획자의 의도대로 했지만 오히려 불편한 점 찾기 등이 있습니다.

: 개발시간을 잡아먹을 정도로 잦은 통합시연을 지양해야겠지만, 적어도 운영전까지는 2~3주 간격으로 통합시연을 하면 좋을 것 같다.

 

예를 들어 1년짜리 프로젝트인데 1년동안 개발하고, 마지막 날에 시연을 하면 오류투성일 가능성이 크다. 반면 1개월에서 2개월 단위로 통합시연을 갖는다면, '사용자 입장'에서 프로그램을 사용해볼 수 있다.(개발과정에서는 개발자의 관점으로 개발하기때문에 예외상황이나 사용성에 불편함을 인식하기 쉽지 않다.)

 

통합시연을 통해서 사용의 불편성이나 예외상황에 대해서 어느정도 파악이 가능해진다. 파악을 통해서 수정하고, 또다시 시연하고 피드백, 수정하는 과정이 필연적인 것 같다.

 

위와 같은 과정을 개구리가 우물에서 나오는 것에 비유하고 싶다. 끊임없이 우물 밖으로 나와야한다. 우물 밖으로 나와도 여전히 우물이다. 이 점을 깨닫고 부단하게 우물 밖을 나오려고 노력해야한다.

 

 

 

 

 

 

 

Keyword : 사용자가 편해야 한다.

사용자의 입력 유효성 검사는 항상 서버에서 해야 하며, 특히 계산 로직은 사용자 편의를 위해 프론트엔드에서 일시적으로 해서 보여줄 수는 있으나 최종 결과는 서버에서 재계산해야 합니다.

: 서비스가 입력받는 값이 많고, 사용자 입장에서 귀찮은 부분이 많으면 사용자는 서비스를 이탈하게 된다.

 

개발된 프로그램은 결국 사용자에게 서비스를 제공할 수 없으면 고물이라고 생각한다. 이러한 고물이 되는 케이스를 피하기 위해서는 최대한 귀찮고 불편한 부분은 프로그램을 개발하는 사람이 전적으로 부담해야한다고 생각한다.

 

개발자가 편하게 만든 프로그램은 어떤 사용자도 사용하지 않는다.

 

 

 

 

 

 

 

Keyword : 유산이 이왕이면 좋은 걸로

프로젝트를 계획할 때 레거시 제거도 프로젝트 범위에 포함하자.

수많은 레거시가 제거되지 못하는 가장 큰 이유는 바로 '일정'이 부족해서 일겁니다. 처음 프로젝트를 시작할 때 전체 일정을 산정하는데, 대부분 프로젝트에서 레거시 제거를 프로젝트 범위에 포함하지 않습니다. 하지만 이 과정이 생략됨으로 인해서 발생하는 부작용은 생각보다 큽니다.

: 레거시(legacy)란 '유산'을 뜻한다. 즉, 기존에 개발된 것들을 뜻한다. 시간이 지날수록 새로 코드들이 추가되거나 삭제된다.

 

이 과정에서 계속 유산처럼 물려받는 코드들이 남는다. 이러한 레거시 코드들 중에서 사용되지 않는 코드들도 많이 존재한다. 굳이 제거하지 않는다고 해서 당장에 큰 문제가 되지 않지만, 시간이 지날수록 문제로 이어질 확률이 커진다.

 

실제로 현업에서 프로젝트 기간을 산정할 때 거의 레거시 제거의 기간을 포함하지 않는다. 아니 전혀하지 않는다. 그저 신규로 개발하거나, 유지보수는 일정만 포함한다. 이 부분은 조금 아쉽다. 물론 회사 입장에서 제한된 인력으로 빠르게 프로젝트를 쳐내는 건 맞지만, 문제를 계속해서 덮어두는 느낌이 들기도 한다.

 

최근 신규 프로젝트가 시작되었는데, 일정 산정에 대해서 아쉽다. 새로운 환경에서 처음하는 개발자들도 포함되어있는데, 너무 개발기간을 촉박하게 잡은 것 같다. 그뿐만 아니라 신규 개발을 하면서 기존 유지보수도 해야하기때문에, 너무 개발할 시간이 없는 것 같다. (결론은 야근해야지? 인가)

 

최소한 나라도 기존 개발을 하는 과정에서 한 화면에 대해서 개발이 완료되면 필요없는 코드는 없는지 확인하는 습관을 가져야겠다라는 생각이 들었다.

 

내가 작성하는 코드는 레거시가 된다.

: 결국, 내가 짠 코드들도 레거시가 된다. 누군가에게 물려줄 유산이라면 이왕이면 좋은 것이여야 하지 않을까 싶다.

 

코드를 읽다보면, 정말 잘 짜여진 코드는 글처럼 읽히고, 성의없이 기능만을 위한 코드는 정말 욕이 나온다. 나의 현재 코드는 욕과 글의 중간이기에 조금도 글처럼 보이도록 노력해야겠다.

 

 

 

 

 

 

Keyword : 코드에 대한 오너십

가급적 코드에 대한 오너십을 명확하게 정하는 것이 좋습니다. 공통으로 사용하는 기능이라고 하더라도 오너십을 부여하고 이를 주기적으로 관리하는 것과 관리하지 않는 것에 차이는 큽니다. 아무도 관리하고 있지 않은 때에 장애인지 및 장애 복구가 전반적으로 늦어지고 장애 확산 가능성도 훨씬 커질 수 있습니다.

: 이 부분도 요 몇 달새 정말 중요하다고 느낀 부분이다. 적어도 내가 개발한 화면들에 대해서는 소유권이 있다고 생각해야한다.

 

책임감을 갖고, 최소한 오류는 발생되지 않도록 해야한다. 현재 문제가 많은 프로젝트에 참여하고 있는데, 정말 오류가 너무 많다. 적어도 최소한의 책임감을 갖고, 코드에 대한 오너십이 있었더라면, 이정도는 아니였을 텐데 하는 아쉬움이 든다.

 

그래서 나라도 더더욱 코드에 대한 오너십을 갖고, 이 화면은 완벽하다고 싶을정도로 꼼꼼하게 작업하는 중이다.

 

결과는 다음 주부터 테스트결과가 예정이지만, 확실한 건, 보완된 화면들이 이전보다는 더 완벽에 가까워졌다라는 사실에 만족해야겠다.

 

테스트 결과가 암울해도 계속 보완해나가면 되기때문에 딱히 걱정은 되지 않는다. 1차적으로 회사 수석님께서 하셨는데 큰 문제없이 통과되어서 오늘은 꽤 기분이 좋았다.

 

 

 

 

 

 

 

Keyword : 외부라이브러리 선택 기준

1. 제어권의 유무 : 직접 작성한 코드를 사용하는 것이 아니기에 외부 라이브러리를 수정하거나, 수정 요청하는 등의 작업이 가능해야 합니다. 직접적으로 코드를 제어할 수 있거나 수정 요청 시 빠르게 반영되는 것이 중요합니다.

 

2. 공식 지원 유무 : 스프링 진영, 정확하게는 스프링 부트 환경에서 공식적으로 지원하는 라이브러리인지도 중요한 기준이 될 수 있습니다. 프레임워크 차원에서 외부라이브러리의 의존성을 관리하고 지원하기 때문에 조금 더 안정성이 올라갈 수 있습니다.

 

3. 커스텀 지원 : 사용자의 입맛에 맞게 확장할 수 있는 형태인지도 중요합니다. 이러한 확장 퐁니트가 잘 열려 있으며 사용하는 데 어려움이 없는 것도 중요합니다.

 

4. 안정성 : 많은 사람이 사용하고 검증한 라이브러리인지 등 안정적으로 운영 중인지에 대한 요인들을 검토합니다.

 

5. 마지막 수정/커밋 : 위에서 제시한 기준을 충족하려면 사용자가 요구하는 방향으로 지속해서 유지보수되어야 하기 때문에 마지막 커밋은 중요합니다.

 

: 아직 외부 라이브러리를 채택할 수 있는 책임권한은 없지만, 알아두면 좋을 것 같은 내용인 것 같다.

 

이 부분을 읽으면서 맛집을 찾는 과정과 비슷하다는 느낌을 받았다. 맛집은 일단 요청사항에 대해서 언제나 환영하는 편이고, 모든 프로세스(과정)이 안정적이다. 끊임없이 개선하고 발전시킨다.

 

외부라이브러리를 채택하는 기준 = 맛집 선정 기준