인턴일지: 2개월차(Agile한 개발 방식)

인턴 하기 전 동기들과 프로젝트를 할 땐...

팀에 따라서 개발 프로세스 방식이 비교적 덜 안정적(?)이기도 했고(회의 시간이 따로 없고 + 문서를 남기지 않는다던가, 기획이 갑자기 수정된다던가), 예상치 못하게 들어오는 추가 요구사항들 때문에 정신이 아찔한 적도 있었고, 개발을 다 해놓고 배포 환경에 대한 지식이 부족해서 배포를 못하게 됐다던가...(죄송합니다)

하는 것들 때문에 

현업에선 개발하는데 있어서 좀 더 정형화된 프로세스가 있을 것이고, 그래서 개발자가 해당 요구사항을 잘 구현하고 성능을 높이는데 좀 더 집중할 수 있을 것이라 생각했다.

 

---

 

그런데 실제 현업 프로세스도 이와 비슷한 면이 있는 것 같았다.

명확히 할 부분은.. 회의 시간은 업무 진행도에 따라 유동적으로 가졌고, 수시로 팀원들과 커뮤니케이션 할 수 있었으며, 회의 이후 업무 진행 문서를 잘 남겨주셨고, 개발을 다 해놓고 배포 환경에 대한 지식이 부족해서 배포를 못하게 되는 일은 절.대. 없었다(사실 마지막 건 현업에선 말도 안되는).

 

다만, 기획이 다 짜여진 상태가 아니라 요구사항이 구체적으로 주어지지 않아 문제가 생기는 것 같았다(내가 담당하는 부분은 아니었지만). 예를 들면 아래와 같은 상황이 생긴다.

 애매 모호한 요구 사항 때문에 개발자가 임의로 "음 대략 이런식으로 반응해야겠지?"하며 "예상"하며 로직을 짠다 ->
 어느 정도 짜면 "그렇게 까진 안해도 될 것 같아요." 라는 답변을 들을 수 있다 -> 그러면 개발자는 로직을 수정한다. (반복)

- 그런데 기획이 다 짜여진게 아니므로 기획이 수정되면 해당 로직은 사라질 수 있다.

- 그러면 해당 로직을 생각하기 위해 개발자가 투자한 시간은 의미 없는 시간이 된다. (기획이 큰 틀에서 벗어나지 않고, 개발자도 그걸 이해하고 있다면 확장성 있게 코드를 작성하겠지만.. 기능 단위로 빠져버린다면?)

 

이 부분은 동기들과 하던 프로젝트랑 비슷하지 않나..?

 

요구 사항 막 바꾸는거 불법 아냐?ㅠㅠ

사실 이런식으로 개발하는게 illegal(불법)이 아니다ㅋㅋ 변화에 유동적으로 대응하는 것이 Agile한 개발 방식이다. 절차적으로 (뒤돌아보지 않고)진행하는 것이 아닌(Waterfall 방식), 요구사항의 변화에 맞춰 기능 구현을 우선으로 두는 방식인데...

생각보다 기능 및 성능 개발도 잘 해야하지만 기획의 방향까지 고려해서 코드를 작성해야하고,
요구사항이 변경되더라도 이에 연연하지 말고 빨리 유동적으로 움직여야겠다고 느꼈다.
서로의 이해도를 확인하기 위해 커뮤니케이션도 자주하는게 좋다.

제가 이해력 떨어져도 친절히 설명해주신 팀원분들... 정말 감사합니다
(나중엔 거의 내 눈빛만 보고도 '얘 이해 못했군' 하고 다시 설명해주시기도 했다. 더 공부해야겠다.) 

만약 기획이 크게 바뀌어 버리면 고려한 사항은 의미가 없어질 수 있지만 소스 수정 방향을 함께 논의해 줄 팀원분들이 있기 때문에 혼자 부담을 안을 필요는 없다. 다만 팀 규모가 작은 편이라 어쨌든 소스 수정을 할 땐 자기가 담당했던 부분들은 거의 그대로 자기가 수정하는 것 같다.

 

 

현 기업만 그런 것인가? 라는 생각도 들었었다.

아직 1년 조금 넘은 스타트업이라 제품의 정체성, 디자인, 기능 등의 기획을 만족하는 만큼 진행하고 개발하려면 여유가 없었을 것이다. 반면 좀 더 규모가 큰 기업이라면 다르지 않을까? 하는 생각이 들었는데, 

부스트캠프부터 네이버 인턴까지

이 분의 회고록에서 멘토님과의 대화를 읽어보면 대규모 팀의 프로세스도 이와 비슷한 것 같다. 

"애매모호한 요구사항과 예상치 못한 상황에 치고 들어오는 추가 사항들, 그리고 구현하다가 새로운 시나리오가 나오면 다시 상의를 하는 등, 유동적으로 움직인다"

 

---

 

결론은,

동기들과 진행하는 프로젝트(너무 엉망진창만 아니면..)와 현업의 프로세스가 크게 다르지 않다. 다른 점은 자기 전문성을 더 키운다면 요구사항이 변경되는 이벤트가 발생해도 대응하는 방식이 더 쉬워질 수도 있다는 것