안녕하세요, 라이언 입니다.
3월에는 개발자라면, 한 번쯤은 관심을 가져봤을 책인,
“요즘 우아한 개발” 이라는 책을 읽어보았습니다.
너무 당연한 부분이지만, 많은 양의 업무에 밀려 하지 못했던 것들,
아니면, 별 거 아닌 것 처럼 생각할 수 있는 요소들이라, 간과했던 부분이 치명적인 이슈가 될 수 있는 부분,
이런 부분들을 이 책을 읽으면서, 많이 깨닫게 되었습니다.
특히 회사의 문화가 결국에는 해당 제품/서비스를 사용하는 고객들까지 영향을 끼칠 수 있겠다고도 생각한
그런 책이었습니다.
“우아한 형제들”의 문화
- 같은 것을 여러번 물어봐 화내지 않는 자세
- 이는 질문을 받는 사람이 제대로 문서화를 하였는지 검증하는 문화라고 합니다.
- 문서화를 하지 않았을 수도 있고, 문서화를 했더라도 그 내용이 본인만 알도록 작성된 내용일 가능성이 높습니다.
- 그래서, 너무 당연한 내용, 같은 내용을 물어봐도, 이는 질문자가 꼼꼼히 찾아보지 못한 잘못이 아닌, 담당자가 제대로 문서화하지 않았다는 책임을 지는 문화를 형성한다고 합니다.
- 이런 “우아한 형제들”의 자세는 개발자의 부담을 꽤나 줄여줄 수 있으며, “너무 사소한 것 까지 물어봐서 혼나진 않을까?” 라는 걱정을 덜 수 있는 좋은 문화라고 생각합니다.
- 저도 사실은 작업한 내용들에 대해 문서화를 하긴 하지만, 누구나 읽어도 바로 이해할 정도로 꼼꼼히 하지는 않는 편이라고 생각합니다. 이 부분을 읽으면서, “나에게는 너무 당연한 지식으라 이런 부분을 왜 물어보지?” 라는 생각을 좀 지양하고, “내가 좀 더 어떻게 하면 설명을 더 잘할 수 있을까?“, “좀 더 문서화를 직관적으로 할 수 있도록 어느 부분을 개선할까?” 와 같은 고민을 하는 것이 더 가치있는 방식임을 깨달을 수 있었습니다.
- 어떻게 보면, 본인이 만든 시스템은 끝까지 본인에게 책임을 부여한다는 문화가 아닐까 싶습니다. 또한, 남에게 내가 한 결과물을 어떻게 쉽게 설명할 수 있을까? 라는 전달력에 대한 능력향상도 포함하는 좋은 시너지를 불러일으킬 수 있다고도 생각합니다.
- 만든 사람이 수고로우면 쓰는 사람이 편하고, 만든 사람이 편하면 쓰는 사람이 수고스럽다.
- 서비스를 만드는 개발자의 입장으로서, 이는 매우 공감되는 내용입니다.
- 이거는, UI/UX 에 좀 더 영향이 크다고도 할 수 있는데요, 백엔드도 쿼리문에 대한 속도라던지, 느린 처리의 비동기화등.. 아예 연관이 없다고는 생각하지 않습니다.
- 그리고 이 부분은 개발 속도와 트레이드 오프한 상관관계를 가진다고 생각합니다. 좀 더 시간을 기울여 편의성을 증가하고자 하면, 그 만큼 사용하는 고객이 편해질 수 밖에 없습니다.
- 그리고, 이런 편의성은 정말로 아주 사소한 부분에서 갈리게 된다고 생각합니다.
- 예를 들면, 파일 업로드 시, 드래그 앤 드롭을 지원한다던지,
- 폼을 제출하기 전, 필수 사항이 있을 때, 미 기입된 사항을 강조하여 표시해준다던지.. (alert로 하나씩 알려주는거 말고요.. ;;)
- 어떤 UI에 대한 수정사항이 발생하였을 때, 실수로 다른 창으로 이동하는 거나, 탭이 닫히는 것을 막는다던지..
- 복수개의 데이터를 빠르게 처리하기 위해서, INSERT를 N번 돌리는게 아닌, Multi Insert를 사용하여, 빠르게 처리한다던지..
- 정말 진짜, 기능적으로는 문제없지만, 이런 사소한 하나하나의 요소가 고객에게는 다른 경험을 선사한다고 생각합니다.
- 이는 장기적으로, 고객의 이탈율을 줄이는 좋은 전략이 될 수 있다고 생각하고 있습니다.
- 우아한 형제들은 이런 사소한 부분들을, 고객이 사용하는 앱 뿐만 아니라, 가게 업주와 같은 관리자가 사용하는 페이지에서도 항상 고려하여 작업한다고 합니다.
- 기술 부채를 막기위한 2주간의 리팩토링 기간
- 코드를 기한 내에 맞춰 작성하다 보면, 갑자기 변경되는 기획이나, 마감기한을 맞추기 위해서, 코드컨벤션을 어기거나, 성능을 고려하지 않는 코드들이 쌓이기 시작합니다.
- 우아한 형제들에서는, 이런 부분을 해결하기 위해, 1년에 2주의 시간을 비워서, 해당 기간에는 기존 프로젝트의 리팩토링만 하는 기간을 제공합니다.
- 이를 통해, 기술부채를 줄이고, 깔끔한 코드를 유지할 수 있습니다. 또한 직접 짬을 내서 수행하는 것이 아니고, 공식적으로 지원하는 기간이므로, 더욱 적극적으로 리팩토링을 수행할 수 있습니다.
- 저는 이 문화가 생각보다 괜찮게 다가왔습니다. 사실 코드가 중간중간 이상해지는 가장 큰 이유가, 기획 변경/데드 라인, 이런 부분들이 가장 크다고 생각합니다.
- 그 당시에는 오픈이 목적이니, 어쩔 수 없는 자신과의 타협을 하여, 좋지 않은 코드를 작성했을 가능성이 큽니다.
- 이런 부분을 해결하려면, 별도로 시간을 내어 따로 해야하는데 쉽지 않습니다. 리팩토링 작업은 동작하는 결과물이 그대로이기 때문입니다.
- 이런 부분을 회사 차원에서 직접적으로 2주간의 시간을 내어, 투자한다는 그 결단이 정말로 대단한 것 같습니다!
백엔드 개발자로서의 인상깊었던 부분
- 페이징 limit에 대한 검증 처리
- 흔히 페이징 처리를 할 때, 프론트의 입력 값에 의존하는 방식으로 처리하는 경우는 매우 흔합니다.
- 프론트가 단순히 1페이지 요청을, limit 값을 1억개 이렇게 요청해도 허용되는 식으로 말이죠.
- 하지만, 이런 API 요청이 날라오면, 백엔드에서는 곤란합니다. 진짜 DB에 데이터가 매우 많이 있을 경우, 진짜 1억개 줘야합니다.
- 이런 성능 이슈가 발생할 수 있는 페이징 처리는 반드시 limit의 맥시멈 값을 지정하여, 부하가 일어날 상황을 만들지 않도록 해야 한다고 합니다.
- 이 또한, 저는 편하게 개발하려는 개발자가 겪는 업보가 아닌가 생각합니다.
- 로그인 실패횟수 처리
- 네이버나, 카카오, 구글 등, 대기업들의 서비스에서는 매우 당연히 볼 수 있는 기능입니다.
- 하지만, 규모가 작은 서비스에서는, 이런 당연한 기능이 빠져있는 경우를 많이 볼 수 있습니다.
- 이는 결국 브루트 포스(Brute Force) 공격 기법을 허용하는 서비스로, 계정이 뚫릴수도 있는 가능성을 보여줍니다.
- 이는 단순히, 서버에 대한 보안 조치가 절대 아니고, 고객을 위한 보안 조치입니다.
- 물론 고객이 너무 쉬운 비밀번호를 사용하여, 브루트 포스 공격이 허용되는 경우가 대다수라, 고객에게 책임을 전파할 수도 있지만,
- 신뢰성 있는 서비스를 제공하기 위해서, 최소한으로 서비스 제공자가 이런 보안 처리는 반드시 해야 한다고 생각합니다.
- PK는 Integer가 아닌 BigInt 으로?
- Integer로 설계하면, 일반적으로, 1부터 사용한다고 하면, 21억 정도의 데이터를 기록할 수 있습니다.
- 하지만, 추후에 서비스가 커지면, 따로 BigInt로 다시 확장시켜야 합니다. (이 과정은 매우 리스크가 클 가능성이 있습니다.)
- 그래서, 그냥 애초부터 고정적인 부분이 저장되는 테이블은 제외하고, 계속 데이터가 쌓이는 테이블의 PK는 BigInt로 설정하는 것을 추천한다고 합니다.
- BigInt는 900경 가량의 수를 저장할 수 있다고 합니다.
- 저 또한, 서비스 DB를 설계할 때, 이런 확장성을 간과했었는데, 이런 사소한 부분을 빨리 알아서 다행이라고도 생각합니다.
- 또한, 연관된 FK 컬럼도 마찬가지로 모두 BigInt로 맞춰줘야 합니다. ORM을 사용한다면, 클래스 데이터 형식도 마찬가지 입니다.
픽스가 나아가야 할 개발 문화 방향성?
픽스는 아직 9명으로 구성된, 작은 소규모 기업입니다.
개발자 한 명, 한 명이, 하나의 주도적인 프로젝트에 대한 모든 작업을 진행하고 있습니다.
그렇기에, 스스로의 기준이, 곧 프로젝트의 개발 기준이 되며, 개발자의 역량에 따라
프로젝트의 완성도가 좌지우지 되는 경향이 큽니다.
현재로써는 규모에 대한 제약으로 인해, 많은 기업들이 하고 있는 좋은 개발 문화를 받아들이기에는 한계가 있다는 점을
확실히 인지하고 있습니다.
하지만, 점진적으로 나아가기 위한, 그 기반이 되는 문화는, 지금부터라도 미약하게 나마, 가져가야 할 것 같다고 생각합니다.
제이슨(대표님) 께서, 픽스에 다양한 문화를 정착하기 위해, 여러 시스템을 벤치마킹하며 픽스에 도입하려고 하려고 항상 노력하고 계십니다.
회사의 문화가 곧, 자산이고, 그런 부분들이 모여 고객들에게 더 가치있는 서비스를 제공할 수 있다고 생각합니다.
저는, 현재 이 게시글을 작성하는 시점을 기준으로, 입사 10개월 정도 되었습니다. (곧 1년 이네요!!)
그 동안 제이슨, 단테 등 여러 팀원 분들께 다양한 지식을 배웠습니다. (항상 감사합니다!)
10개월을 다니면서, 아직 픽스의 개발문화는 아직 체계적이지 않고, 부족한 것이 많다고 생각합니다.
이는 규모에 대한 제약이 가장 컸을 것이라고 생각됩니다.
최근 들어, AI의 도입, 회사 내부시스템에 공을 들여 점점 기반을 확립하고 있으며,
개발 업무에 필요한, 체계적인 시스템을 하나씩 확장 도입 해가면서,
점점 틀이 잡히고 있습니다.
요즘에는 AI 에이전트 기술이 많이 발전되어, 모든 팀원들이 좀 더
회사가 표준으로 지향하는 방식에 좀 더 가깝게 개발할 수 있는 시대가 되었습니다.
과거에는 직접적인 코드 리뷰를 통해, 진행될 수 있었던 것들이, AI 시대에는 체계화된 문서를 통해서,
AI 에이전트를 통해, 간접적으로도 같은 효과를 얻을 수 있다고 생각합니다.
인원 부족의 제약적인 문제점을, AI 에이전트를 통해 대체할 수 있는 시대가 왔으므로,
픽스에서는 좀 더 적극적으로 AI를 통한 체계적인 개발 문화를 만들어나갈 수 있다고 보고 있습니다.
이를 위해서는, 현 상태를 꼼꼼히 문서화하는 습관을 먼저 자리잡는 것부터 시작해야겠습니다!
책 추천 대상 및 마무리
IT업계의
기획자, 개발자 라면, 한 번쯤은 보는 것을 추천드립니다.
개발의 문화를 주도하는 기업의 문화를 간접적으로 체험할 수 있는 책입니다.
너무 당연하게 여겨오거나, 사소해서 무시했던 것들을, 다시 되돌아보게 해준 그런 책이었습니다.
글 읽어주셔서 감사합니다.
답글 남기기