처음에는 그냥 기능 구현을 하면 되지만 프로젝트의 크기가 커지다 보면 ‘제대로 정리해두지 않으면 정말 안 될 것 같은 순간’들을 맞이하게 됩니다. 그냥 만들면 쉬운 요구사항도 기존 코드에 확장하는 것이 쉽지 않고, 점점 디버깅도 힘들어지는 걸 느낍니다. 이러한 문제에 부딪힌 많은 프론트엔드 개발자가 기존 구조에서 조금씩 더 나은 아키텍처와 프레임워크 형태, 그리고 라이브러리리를 제안했습니다. 덕분에 짧은 시간 안에 새로운 아키텍처들과 방법들이 꾸준히 탄생했습니다.
오늘 해볼 이야기는 ‘어떻게 하면 조금 더 효율적으로 다 같이 개발을 설계하고 진행할 수 있을지’에 대한 이야기입니다. 아이디어를 구체화하고 기획 구현을 시작하면 이제 ‘이걸 어떻게 태스크로 나눠서 분배해야 하는지’, ‘진행도는 어떻게 체크해야 하는지’, ‘다른 사람들은 어디까지 했는지’ 등 프로젝트 파악이 필요합니다. 태스크 및 일정 관리에 정답은 없겠지만, 직접 스프린트를 진행하면서 긍정적인 효과를 보았던 BDD(Behavior Driven Development)와 SDD(Schema Driven Development)를 바탕으로 프로젝트 설계 및 일정 관리에 대해 한 번 이야기해보겠습니다.
좋은 폴더 구조에 관한 이야기는 개발자들 간의 끊임없는 떡밥입니다. 정답이 있지 않고 프로젝트의 특징이나 크기, 주관적인 해석에 따라 정말 여러 가지 방법들이 존재하기 때문입니다. 마치 ‘좋은 코드란 무엇일까?’와 같은 급의 질문이 아닐까 생각이 듭니다. 이번 글에서는 좋은 폴더 구조 이야기 중 먼저 컴포넌트에 한정해서 한번 이야기해보려고 합니다. 컴포넌트를 정리하거나 아키텍처 혹은 디자인 시스템을 검색하다 보면 한번쯤은 만나게 되는 바로 Atomic Design Pattern에 대한 이야기입니다.
함수형 프로그래밍을 배우면서 깨달은 것이 있습니다. 실제 함수형 프로그래밍의 본질은 그렇게 어려운 것이 아닌데 이걸 설명하기 위해서는 대단히 어려운 일이 많았습니다. 아마 함수형 프로그래밍에 쓰이는 용어들이 대부분 낯설기 때문일지도 모릅니다. 최근 함수형 프로그램을 더 깊이 공부하다가 실제로 알려주고 싶었던 것이 방법이나 용어가 아닌, 코드를 함수형으로 생각하는 ‘함수형 사고 패러다임’이라는 걸 깨달았습니다. 그래서 오늘은 함수형 사고 패러다임을 바탕으로 새롭게 함수형 프로그래밍에 관한 글을 써보려고 합니다.
이번 글은 일하는 방식에 대한 이야기입니다. 소프트웨어 사업은 거대하기에 혼자서 다 할 수 있는 것이 아니기에 언젠가는 함께 일해야만 합니다. 애자일과 구글 스프린트를 접하면서 그동안 겪었던 경험을 바탕으로 협업 방식을 바꾸기 위한 시도를 많이 했었습니다. 일부는 성과가 있었고 일부는 맞지 않는 방법들도 있었습니다. 오늘은 제가 경험한 Best Practice를 찾아가는 이야기를 통해 어떻게 협업을 하면 좋은지에 대한 주관적인 의견을 설명하고자 합니다.