Community

개발자 99% 커뮤니티에서 수다 떨어요!

← Go back
Assignment 13 - TIL (2022. 5. 29.)
by pksl
#pragmatic
2년 전
1,276

오늘의 TIL 3줄 요약

  1. 프로젝트에서 사용하는 단어들을 여태 구두로만 합의했었는데 사전(Dictionary)처럼 문서화해서 따로 정리해야겠다.

  2. 미래를 위해 협업에 활용되는 짝 프로그래밍 방법이나 몹 프로그래밍 방법을 숙지해두자.

  3. [Topic 48. 애자일의 핵심]을 구성원에게 공유해 잘 나아가고 있는지 한 번 점검해보자.

TIL (Today I Learned) 날짜

2022-05-29

오늘 읽은 범위

  • 8장. 프로젝트 전에 (p.349 ~ p.376)

책갈피

  • 자신이 뭘 원하는지 정확히 아는 사람은 아무도 없다. (p.350)

  • 프로그래머는 사람들이 자신이 원하는 바를 깨닫도록 돕는다. (p.351)

  • 요구 사항은 피드백을 반복하며 알게 된다. (p.354)

  • 사용자처럼 생각하기 위해 사용자와 함께 일하라. (p.355)

  • 정책은 메타데이터다. (p.356)

  • ‘프로젝트 용어 사전’ 을 만들고 관리하라. (p.360)

  • 생각의 틀을 벗어나지 말고, 틀을 찾아라. (p.364)

  • 제약을 범주별로 나누고 우선순위를 매겨라. 목공에서는 작업에 필요한 목재를 재단할 때 가장 긴 조각을 먼저 자르고, 남은 나무에서 작은 조각들을 잘라낸다. 비슷한 방식으로 우리도 제일 구속이 심한 제약부터 파악해 내고 나머지 제약을 그 안에서 맞춰 보아야 한다. (p.364 ~ p.365)

  • 간단히 표현하면 딴짓을 한 사람이 의식적으로 노력한 사람보다 복잡한 문제 해결 과제를 더 잘 해냈다. (p.365)

  • 코드에 혼자 들어가지 말라. (p.371)

  • 애자일이 전반적으로 작동하게 하려면 좋은 설계를 만들어야 한다. 좋은 설계는 무언가를 바꾸기 쉽게 하기 때문이다. 바꾸기 쉽다면 모든 층위에서 아무런 주저 없이 문제를 바로잡을 수 있을 것이다. (p.376)

오늘 읽은 소감

프로그래머가 아닌 이상 요구 사항을 전달할 때 모든 케이스나 예외 처리까지 고려해 전달하는 기획자는 거의 없다고 볼 수 있다. 아니, 설령 프로그래머라 하더라도 요구 사항을 제시할 때 누락되는 부분들이 생기기 마련이다. [Topic 45. 요구 사항의 구렁텅이]에서는 이런 식으로 공백이 많은 요구 사항을 어떻게 완성품으로 만들어 낼 수 있는지 노하우를 알려주고 있다. 핵심은 [Topic 7. 소통하라!]에서 다룬 것처럼 머리를 맞대고 ‘피드백’을 활발하게 주고받는 것이다.

코딩하다 보면 구현에 어려움을 겪어 막히는 구간을 마주하기 마련이다. [Topic 37. 파충류의 뇌에 귀 기울이기]에서는 프로젝트의 시작이나 설계에 관한 망설임과 불안함에 대한 것이라면, [Topic 46. 불가능한 퍼즐 풀기]는 구현 자체가 난해해 구현 방식이 그려지지 않을 때의 해결 방법들을 제시하고 있다.

7장 TIL에서 막힌 부분이 있다면 목표를 작게 분할해서 핵심 로직이 되는 중요한 것부터 차근차근 처리해 나아간다고 적어 두었다. 하지만 정말 어려운 문제를 마주한 경우엔 그것조차 쉽지 않다. 그럴 때 나는 생각의 틀에 갇혀있는 것이라고 여겨 틀에서 벗어나기 위해 다음과 같이 접근한다.

  1. 타인에게 설명하듯이 가벼운 내용으로 문서를 작성(정리)한다. ‘왜?’ 라는 질문을 계속 던지면서, 왜 그렇게 생각했는지에 대해 쭉 작성해보고 보통은 그 과정에서 스스로 다른 길을 찾아내거나, 만약 못 찾아낸 경우 작성한 문서를 그대로 다른 구성원이나 커뮤니티에 공유해서 ‘이런 어려움을 가지고 있는데 혹시 무슨 방법이 없을지?’ 머리를 맞대고 생각해본다. 만약 그래도 답이 보이지 않는다면…

  2. 구글링한다. 세상은 넓기에 해당 요구 사항과 비슷하게 구현된 사례들은 꽤 있을 것이다. 완전히 새로운 개념이 아닌 이상 기존에 알려진 알고리즘이나 프로그램, 기술을 다양하게 접목해보면 문제를 좁혀볼 수 있다. 그렇게 검색된 레퍼런스를 최대한 모아 읽어본다. 그중에 잘못된 데이터들도 있기 마련이니 여러 자료를 취합해보고 내가 올바르다고 느끼고 직접 이해할 수 있는 해결방안에 대해서만 참고로 한다. 이해해야지만 다채롭게 응용해서 적용이 가능하기 때문이다.

  3. 머리를 맞대어도 답이 안 나오고 레퍼런스도 부족해서 구현 방법이 떠오르지 않는다면, 마냥 기다릴 수는 없기에 양해를 구하고 요구 사항의 사양을 조정하거나 TODO로 남겨두고 다른 부분부터 작업을 진행한다. 다른 기능들을 코딩하거나, 샤워를 하던 중에 갑자기 ‘유레카!’하고 외치게 될 수도 있기 때문이다.

1번의 과정을 거치지 않고 바로 2번의 구글링을 진행해도 되지만 구글링은 보통 순간의 상황만 빠르게 넘길 뿐 머리에 오래 남지 않기 때문에 1번과 같은 스스로 탐구해 나아가는 과정을 반드시 가져본다.

아… 아직 미지의 영역에 해당하는 내용이 나왔다. (입사한 이래로 같은 포지션에서 일하는 팀원이 없었던지라 지금까지 계속 혼자 작업해왔다.) [Topic 47. 함께 일하기]에서는 짝 프로그래밍이나 몹 프로그래밍을 어떻게 운용해야 하고 장점을 끌어낼 수 있는지, 그 방법에 대해 알려주고 있다. 나중에 구성원이 추가될 때를 대비해서 적용해 보기 위해 내용들을 잘 새겨둬야겠다.

애자일 개발이 길어야 10년 정도 된 방식인 줄 알았는데 알고 보니 20년이 됐다고 한다. [Topic 48. 애자일의 핵심]을 통해 애자일 개발 방법론을 어떻게 적용해야 좋은지 확인할 수 있었다.

회사에서는 다음과 같은 방식으로 애자일 개발 방법의 하나인 스크럼 개발 방식을 활용하고 있다.

지금 한창 개발 중인 리뉴얼 프로젝트같이 신규 프로젝트로 예를 들어보면, 우선 기능별로 크게 분리한다. 예를 들어 커뮤니티 서비스의 개발이라면 회원 관리(회원 가입, 로그인, 계정 찾기, 정보 수정, 탈퇴 등) 기능, 게시물 관리(작성, 수정, 삭제, 추천/비추천, 댓글 등) 기능, 관리자(관리자 페이지, 회원 관리, 게시물 관리 등) 기능 등으로 나눠 볼 수 있다.

그렇게 나눈 기능 단위를 하나의 시즌(Season) 범위로 잡고 해당 시즌에서 개발해야 할 것들의 목록을 티켓(Ticket)으로 정리해 각각 구현에 걸릴 시간을 예측해둔다. 업무의 집중도 관리를 위해 하나의 티켓당 최대 4시간 정도로 잡는 게 좋다.

해당 시즌에서 구현해야 할 기능이 많으면 많을수록 피드백이 활발하게 이루어져야 하므로 매주 스프린트(Sprint)를 운영하는 게 좋다. (유지보수 같은 경우는 작업할 내용이 비교적 적어 하나의 스프린트를 2~3주로 운영하는 경우도 있음) 가령 스프린트 주기의 기준이 매주 수요일이라면, 수요일에는 지난 스프린트에서 작업했던 내용들을 공유하고, 서로의 작업물을 두고 피드백을 공유하는 회고(스프린트 회고) 시간을 가진다. 그리고 다음 스프린트에 작업해야 할 목록에 관해 서로 피드백을 주고받으며 우선순위별로 정리해둔다. 이런 식으로 스프린트를 반복하면 한 시즌이 끝나게 된다.

하나의 시즌이 끝나면 다음 시즌으로 넘어가기 전에 해당 시즌에서 부족했던 부분들을 짚어, 다음 시즌에는 개선해야 할 것들에 대해 회고(시즌 회고)한다. 회고를 마치면 구성원들의 컨디션에 따라 잠시 휴식기를 가지거나, 컨디션이 좋다면 이어서 개발하는 방식으로 다음 시즌에 대한 스프린트와 개발을 진행한다.

이런 방식으로 개발하면 한 번에 큰 숲을 보지 않고, 나무에 집중할 수 있게 되어 개발에 속도가 붙는다. 물론 이전 시즌에서 좁은 시야로 접근했기 때문에, 다음 시즌에서 구현하다 보니 이전 시즌에서 구현한 것과 서로 맞물리지 않아 리팩토링이 필요할 수도 있다. 리팩터링 업무들이 튀어나오는 건 애자일 방식으로 개발을 진행하다 보면 당연한 일인데, 리팩터링 양이 많거나 혹은 리팩터링 범위가 너무 크다면 이건 애자일 개발 방식의 문제가 아니라 초기에 예측한 설계 자체가 잘못된 것이다. 이때는 자기 자신에 대한 회고를 더욱 열심히 해서 좋은 설계를 할 수 있도록 발전해야 한다.

그리고 큰 그림에만 몰입할 경우, 스프린트 중간에 개발 사양이 바뀌는 일이 생기면 마인드 컨트롤이 불가능해질 정도로 정신에 큰 타격을 입게 된다. ‘맙소사, 이미 다 설계해 뒀는데 말짱 도루묵 됐네…’ 같은 꼴이 된다. 애자일 개발 방식은 중간중간의 사양 변경에도 비교적 유연하게 대처가 가능해 업무 스트레스를 관리하기에도 좋다.

특히 요즘처럼 원격 근무가 활성화된 환경이면 더욱 좋은 게, 매일 오전에 진행되는 스크럼(Scrum) 회의에 당일 해야 할 업무들을 공유하기에 해당 업무들이 끝나면 맘편하게 쉴 수 있다. 이런 식으로 업무를 티켓별로 관리하지 않으면 업무에 대한 경계가 모호해져 밤늦게까지 코드를 붙잡고 있게 될 수도 있다.

오늘 읽은 다른사람의 TIL

  • Assignment 12 - 7장 TIL

  • 앞서 작성된 Assignment 13 - 8장 TIL

참고 자료