<div id="readability-page-1" class="page"><div>
        
      <h2>[회고] 개발 회고</h2>
      <blockquote>
  <p>개발 회고</p>
</blockquote>



<h2 id="배경">배경</h2>

<p>회고를 작성하다 보니 내용이 많아서, 따로 글을 작성하게 되었다.</p>



<h2 id="개발-사례-회고">개발 사례 회고</h2>

<h3 id="내용">내용</h3>

<p>아래 내용들은 회고에 이미 적었던 부분이며, 관련해서 형식 없이 이야기하고 의식의 흐름대로 적어보려고 한다.</p>

<ul>
  <li>일반화 및 표준화의 중요성</li>
  <li>어딘가에는 흔적을 남겨 놓아야 한다.</li>
  <li>기술이 다가 아니다.</li>
  <li>리소스만 믿고 의존하면 안 된다.</li>
  <li>우려한 건 언젠가는 발생할 수 있다.</li>
  <li>DEV, STG, PROD의 구분은 중요하다.</li>
  <li>테스트는 너무도 중요하다</li>
  <li>사람을 믿지 말자.</li>
  <li>바쁘더라도 필요한 건 해야 한다.</li>
  <li>컨텍스트 체인지에는 많은 시간이 든다.</li>
  <li>높은 조직의 정책과 당시 상황의 영향</li>
  <li>체력이 튼튼하고 정신을 똑바로 차려야 한다.</li>
</ul>



<h3 id="일반화-및-표준화의-중요성">일반화 및 표준화의 중요성</h3>

<p>회사 Big Data센터에 오면서 전사 데이터에 관한 일을 해왔다. 여기에 와서 가장 크게 느꼈던 부분이 일반화 및 표준화의 중요성이다. 그 반대가 파편화다.</p>

<p>일하는 곳이 전사 조직이 되면서, 전사 데이터를 수집하는 시스템을 만드는 과제를 받았다. 그런데 그 과제를 진행하기에 앞서 이전에 진행했던 과제들을 살펴보았는데, 많은 고생이 있었던 것이 눈에 띄었다. 대표적으로 서비스별로 수집하는 방식이나 포맷이 서로 달랐고, 이러한 부분이 하나로 일원화되지 않은 채 진행된 상황이었다. 글을 읽으면서 “왜?”라고 의문을 가질 수 있다. 그런데 그렇게 된 이유는 분명 있었을거라 생각한다.. 그 이유를 모두 알지는 못하지만, 관련된 추가 이야기는 뒤에 적겠다.</p>

<p>표준화와 일반화가 이루어지지 않으면 파편화가 발생하고, 서비스가 커질수록 그것을 관리하고 유지하는 것이 굉장히 힘들어진다는 것을 경험했다. 서비스가 커질수록 표준화와 일반화는 필수적이라고 생각한다.</p>

<p>리더나 매니저급에서는 단순히 과제를 완수하는 것에 그치지 않고, 최대한 일반화하여 그에 맞추도록 노력해야 실무가 덜 힘들고 품질도 개선될 수 있다고 생각다. 기존에 만들어 놓은 플랫폼이 있는데, 협업하는 곳이 요구하는 대로 모두 맞춰주면 그것은 SI 업체일 뿐, 진정한 협업이 아니라 본다. 물론 어느 정도 이유가 있을 수 있고, 그 의견을 듣고 방법이 하나밖에 없다면 미루거나 하면 되지 않나 싶다.</p>

<p>작은 서비스이고 사람이 관리하기 쉬운 10개? 이하는 문제가 없지만 그 이상이면 플랫폼 성격을 가졌다면 일반화 및 표준화가 중요한 거 같다. 큰 플랫폼이라면, 힘과 영향력을 가진 상위 부서에서 일반화 및 표준화를 위한 방향을 설정하고 가는 것이 맞다고 생각한다.</p>



<h3 id="어딘가에는-흔적을-남겨-놓아야-한다">어딘가에는 흔적을 남겨 놓아야 한다.</h3>

<p>특정 기능을 개발한 사람이 평생 관리한다면 이 이야기는 필요 없겠지만, 프로그램과 달리 사람은 언제든 바뀔 수 있다. 그렇기에 어떤 작업을 왜 했는지 기록으로 남겨두는 것이 중요하다는 것을 몸소 체감했다. 그 방법은 여러 가지가 될 수 있다. 문서로 정리해서 남겨두거나, 코드에서는 주석이나 함수명을 자세히 작성하는 방식이 있을 수 있다. 주석을 다는 것이 코드로 충분히 표현하지 못한 것을 보완하는 방법이라 좋지 않다는 말을 들었지만, 코드로 표현할 수 없다면 주석이라도 남겨두어야 다. “왜 이렇게 되어 있는 거지?”라는 질문을 담당자가 찾아가서 직접 설명을 듣는 시간을 아낄 수 있고, 담당자가 없을 때도 대처할 수 있다.</p>

<p>코드에 의도를 최대한 표현하고, 그렇지 않으면 문서나 다른 곳에 표시를 해두는 것이 팀의 효율성을 위한 일이다.</p>

<p>실제로 올해 너무 바빴던 나머지 이런 상황이 가끔 있었고, 내가 겪은 적도 있었기에 이제는 최대한 기록을 남기는 습관이 생겼다.</p>



<h3 id="기술이-다가-아니다">기술이 다가 아니다.</h3>

<p>올해 <a href="/349-the-first-half-retrospective">[회고] 상반기 회고</a>에도 기록했던 내용이다. 크게 달라진 점이 없어 그대로 가져왔다.</p>

<p>기술이 다가 아니다. 10분 만에 해결될 일이 감정 문제로 10일이 걸릴 수도 있다. 개발은 완료되었지만, 서비스 측에 갑자기 생긴 프로세스로 업무가 늘어난 사례가 있었다. 실무자의 협조가 어렵다고 한 부분을 매니저 또는 더 위에 상급자의 도움을 받아서 더 빠르게 해결한 경우도 있었다. 이렇듯 때로는 개발만이 아닌 사람을 통해서도 문제가 해결될 수 있는 거 같다.</p>



<h3 id="리소스만-믿고-의존하면-안-된다">리소스만 믿고 의존하면 안 된다.</h3>

<p>큰 서비스 개발 경험이 부족해서 그럴 수도 있지만, 개발하다 보면 리소스를 믿는 경향이 있었다. 예를 들면 코드 작성 시 메모리가 충분하다고 생각해 개발했는데 OOM(Out of Memory) 오류가 발생한 경우가 있었고, 옵션을 지나치게 줘서 OOM 오류가 발생한 적도 있었다. 메모리의 예시만 들었지만, 스토리지뿐만 아니라 서비스가 커지면서 네트워크나 데이터베이스에 부하가 걸려 이슈가 발생했던 경험도 있다.</p>

<p>Pod를 실행하면서 OOM 오류가 발생했고, Airflow에서 데이터베이스에 많이 접근하다 보니 병목이 생겼다. 또 인프라 구축 시 옵션을 너무 크게 설정하여 Pod가 죽는 경우도 있었다. 물론 응답 결과가 너무 느리거나 많아서 Swagger에서 응답 없는 상태가 되었던 적도 있다. 서비스가 커지면서 AWS Quota에 걸려 늘려달라고 요청한 경우도 많았다.</p>

<p>초기에 개발 시에는 메모리 신경 쓸 여유가 없지만, 서비스가 커지면서 문제가 터질 수 있다는 점을 항상 염두에 두어야 하고, 가능하다면 미리 대비하는 것이 좋다.</p>



<h3 id="우려한-건-언젠가는-발생할-수-있다">우려한 건 언젠가는 발생할 수 있다.</h3>

<p>“아… 이거 나중에 문제가 될 수 있을 것 같은데?”라는 생각이 들었던 부분이 실제로 발생한 경우가 있었다.</p>

<p>클라우드에서 자동으로 생성되는 부분이 있었는데, 좀 포괄적으로 제외해 놓고 나중에 수정했던 경험이 있다. 이 경우, 문서에도 없고 좀 이상하게 만든 것 같다는 의견이 있었지만, 그래도 우려했던 문제가 발생했던 사례였다. 또 다른 사례로는 인프라 구축 설정값을 하나로만 관리하다가, 서비스가 커지면서 배포가 느려지고 관리가 어려워질 것 같았는데, 담당자가 고생해서 이를 바꿔준 경험이 있다.</p>

<p>너무 당연하고 모두가 아는 이야기지만, 한 번 더 염두에 두고 미리 해결하면 좋을 것 같아서 적어봤다. 물론 일을 하다 보면 그것이 쉽지 않지만… 하하. 적절한 타협은 당연히 필요하다.</p>



<h3 id="dev-stg-prod의-구분은-중요하다">DEV, STG, PROD의 구분은 중요하다.</h3>

<p>개발하는 컴포넌트가 많아짐에 따라 환경 구분의 중요성을 몸소 체감했다.</p>

<p>테스트를 진행하면서 내가 개발한 것과 다른 사람이 개발한 부분이 충돌하거나, 통합 테스트 중에 이슈가 발생하곤 했다. DEV/STG 환경이 일부 겹쳐 있어서 발생한 일이었다.</p>

<p>너무도 당연한 이야기지만, 신규 과제를 진행하는 환경에서는 발생할 수 있기에 적어봤다.</p>



<h3 id="테스트는-너무-중요하다">테스트는 너무 중요하다</h3>

<p>올해 테스트 및 CI/CD 업무를 맡아 진행했는데, 테스트가 있을 때와 없을 때 품질의 차이와 불안함의 체감 정도가 너무 달랐다.</p>

<p>단위 테스트와 통합 테스트가 있었기 때문에 배포할 때 마음이 많이 놓였다.</p>

<p>품질을 높여주고 사람들을 불안하지 않게 해주는 점에서 큰 매력을 느꼈다.</p>

<p>너무 바쁘다 보니 테스트 작성할 시간이 없다는 건 이해하지만, 그래도 테스트만큼은 꼭 작성하는 게 맞다고 생각한다. 나중에 개발할 때도 반드시 도움이 된다.</p>



<h3 id="사람을-믿지-말자">사람을 믿지 말자.</h3>

<p>오해할 수 있지만, 사람이 나빠서 믿지 말자는 이야기가 아니다. 사람이 실수할 수 있기 때문에 사람에게만 의존하면 안 된다는 이야기다.</p>

<p>협업 중에 사람이 직접 매일 작업을 해주겠다고 했던 곳이 있었는데, 결국 이슈가 생기고 연쇄적으로 스트레스를 받았던 기억이 있다. 최근에도 데이터를 수집해야 하는데 데이터를 올려주지 않거나 다른 포맷으로 주는 경우가 있었기에, 직접 데이터를 수집하는 쪽에서 데이터에 직접 접근할 수 있도록 시스템을 만드는 것이 맞다고 생각한다.</p>

<p>결국 모든 것은 자동화해야 하는 것이 맞다. 서로를 위해 시스템화해야 서로가 편하다. 데이터 파이프라인을 만든다고 가정할 때, 데이터베이스에 직접 접근하는 것부터 적재까지 하나의 팀에서 모니터링할 수 있어야 소통이 줄어든다. 또 다른 예로, 비밀번호나 정보를 사람이 직접 입력하면 실수가 있을 수 있기 때문에 검증을 입력한 사람이 직접 하도록 시스템을 만들어야 한다. 마지막으로, 사람이 테스트를 모두 했더라도 최종 테스트는 기계에 의해 진행되어야 품질을 확실히 보장할 수 있다.</p>



<h3 id="바쁘더라도-필요한-건-해야-한다">바쁘더라도 필요한 건 해야 한다.</h3>

<p>위에서 언급한 내용과 일부 겹치긴 한다. 이 부분도 타협의 영역이고 상황에 따라 달라질 수 있지만, 테스트처럼 중요한 부분은 최대한 시간을 내서 해야 한다.</p>

<p>마이그레이션을 하면서 사용하던 옵션을 빠뜨려서 큰 용량의 값을 처리해야 하는 상황이 있었다. 이를 계속 미루다가 결국 용량이 너무 커져 이슈가 발생했다. 반드시 일어날 것 같고 해야 할 것 같다는 강한 의심이 든다면, 바쁘더라도 지금 해결하는 게 좋다. 서비스 측에도 관련된 부분이라 미리 해야  일이었다.</p>

<p>역시 말처럼 쉽지 않다는 걸 아주 잘 알고 있다.</p>



<h3 id="컨텍스트-체인지에는-많은-시간이-든다">컨텍스트 체인지에는 많은 시간이 든다.</h3>

<p>여기서 말하는 컨텍스트 체인지란 업무의 변경을 의미한다. 맡은 업무가 변경될 수도 있고, 해야 하는 일이 바뀔 수도 있다.</p>

<p>올해 잦은 인터럽트로 인해서 하던 일이 자주 바뀌었고, 정신이 없었으며 일을 재개할 때 집중하기 어려웠다.</p>

<p>상반기에 업무 분장을 새로 했는데, 바쁜 와중에 새로운 업무를 시작하니 다시 익히는 데 시간이 많이 소요됐다. 이렇듯 업무가 변경되면 익히는 데 시간이 많이 드는 것 같으므로, 그런 계획이 있다면 충분한 버퍼를 두는 게 좋을 것 같다.</p>



<h3 id="높은-조직의-정책과-당시-상황의-영향">높은 조직의 정책과 당시 상황의 영향</h3>

<p>일을 하다 보면 “왜 저렇게 만들었을까?”라는 질문을 종종 한다. 내가 더 잘 만들 수 있을 것 같다는 자만에서 나오는 질문이 아니라, 조금 돌아서 만드는 느낌을 받을 때가 있었다. 위에서 언급한 파편화가 된 것도 비슷한 맥락이다. 그래서 당시 담당자들과 이야기해 보면 다 이유가 있었다. 팀의 힘이 부족해서 정치나 권력 문제로 상대방에 맞춰야 했던 경우도 있고, “이렇게 안 하면 안 해준다”라는 식의 상황도 있었다. 요구사항이 매번 달라졌고, 일반화가 안 되었으며 여러 가지 이유가 있었다. 이렇듯 당시의 개발 외적인 외부 상황에 따라 개발이 영향을 받아 어려운 방향으로 가는 경우가 있다. 엔지니어가 놓치거나 못한 부분일 수도 있지만, 외부의 영향이 큰 경우도 있다.</p>

<p>파편화된 상황에서 전사 조직으로 바뀌고, 조직 내 힘 있는 리더가 전사에 공표하니 누구나 해야 할 일이 되어서 모두가 대응해 줬다. 기술이 뛰어나도 전사 차원에서 밀어주지 않으면 진행되지 않았을 것이다. 이렇듯 힘 있는 조직에서 정책을 만들어야 일이 진행된다는 것을 경험했고, 그게 맞는 방향이라고 생각한다. 상무급에서 협의하는 것보다 사장급에서 전사에 지시를 내리는 게 훨씬 효율적이다.</p>



<h3 id="체력이-튼튼하고-정신을-똑바로-차려야-한다">체력이 튼튼하고 정신을 똑바로 차려야 한다.</h3>

<p>체력은 아무리 강조해도 부족할 정도로 중요하다. 체력이 있어야 집중할 수 있다. 체력이 떨어지면 집중력도 떨어지고 효율도 나지 않는다. 체력이 부족하면 어떤 일이든 효율이 떨어지게 된다.</p>

<p>이전에는 이슈가 발생해도 큰 문제가 되지 않았지만, 이제는 연관된 서비스가 매우 크고, 사용자가 많아 실수가 나면 안 되는 상황이기 때문에 매번 집중해서 일을 했다.</p>

<p>이슈 발생 시 영향이 큰 경우 실수하면 안 되므로 정신을 차려야 한다. 이를 받쳐주려면 체력이 필요하다.</p>



<h2 id="마무리">마무리</h2>

<p>이 모든 이야기는 올해 느낀 부분으로, 좀 더 자세히 적어서 더 많은 공감을 얻고 싶었지만 회사 관련된 이야기가 많아 세세히 쓰지 못한 것이 아쉽다. 그런데도 제목과 내용을 읽으면서 충분히 공감할 수 있는 사례가 많을 것으로 생각한다. 물론, 이러한 사례들은 상황에 따라 달라질 수 있기 때문에 언제나 유연하게 사고하고 대처해야 한다. 당연히 정답은 아니다.</p>

<p>일을 하면서 몸과 마음이 고생했지만, 그럼에도 몇 가지 배운 점이 있어 긍정적으로 생각한다.</p>

      
        
        
        </div></div>

TWpower’s Tech Blog

개발 회고
배경
회고를 작성하다 보니 내용이 많아서, 따로 글을 작성하게 되었다.
개발 사례 회고
내용
아래 내용들은 회고에 이미 적었던 부분이며, 관련해서 형식 없이 이야기하고 의식의 흐름대로 적어보려고 한다.
일반화 및 표준화의 중요성
어딘가에는 흔적을 남겨 놓아야 한다.
기술이 다가 아니다.
리소스만 믿고 의존하면 안 된다.
우려한 건 언젠가는 발생할 수 있다.
DEV, STG, PROD의 구분은 중요하다.
테스트는 너무도 중요하다
사람을 믿지 말자.
바쁘더라도 필요한 건 해야 한다.
컨텍스트 체인지에는 많은 시간이 든다.
높은 조직의 정책과 당시 상황의 영향
체력이 튼튼하고 정신을 똑바로 차려야 한다.
일반화 및 표준화의 중요성
회사 Big Data센터에 오면서 전사 데이터에 관한 일을 해왔다. 여기에 와서 가장 크게 느꼈던 부분이 일반화 및 표준화의 중요성이다. 그 반대가 파편화다.
일하는 곳이 전사 조직이 되면서, 전사 데이터를 수집하는 시스템을 만드는 과제를 받았다. 그런데 그 과제를 진행하기에 앞서 이전에 진행했던 과제들을 살펴보았는데, 많은 고생이 있었던 것이 눈에 띄었다. 대표적으로 서비스별로 수집하는 방식이나 포맷이 서로 달랐고, 이러한 부분이 하나로 일원화되지 않은 채 진행된 상황이었다. 글을 읽으면서 “왜?”라고 의문을 가질 수 있다. 그런데 그렇게 된 이유는 분명 있었을거라 생각한다.. 그 이유를 모두 알지는 못하지만, 관련된 추가 이야기는 뒤에 적겠다.
표준화와 일반화가 이루어지지 않으면 파편화가 발생하고, 서비스가 커질수록 그것을 관리하고 유지하는 것이 굉장히 힘들어진다는 것을 경험했다. 서비스가 커질수록 표준화와 일반화는 필수적이라고 생각한다.
리더나 매니저급에서는 단순히 과제를 완수하는 것에 그치지 않고, 최대한 일반화하여 그에 맞추도록 노력해야 실무가 덜 힘들고 품질도 개선될 수 있다고 생각다. 기존에 만들어 놓은 플랫폼이 있는데, 협업하는 곳이 요구하는 대로 모두 맞춰주면 그것은 SI 업체일 뿐, 진정한 협업이 아니라 본다. 물론 어느 정도 이유가 있을 수 있고, 그 의견을 듣고 방법이 하나밖에 없다면 미루거나 하면 되지 않나 싶다.
작은 서비스이고 사람이 관리하기 쉬운 10개? 이하는 문제가 없지만 그 이상이면 플랫폼 성격을 가졌다면 일반화 및 표준화가 중요한 거 같다. 큰 플랫폼이라면, 힘과 영향력을 가진 상위 부서에서 일반화 및 표준화를 위한 방향을 설정하고 가는 것이 맞다고 생각한다.
어딘가에는 흔적을 남겨 놓아야 한다.
특정 기능을 개발한 사람이 평생 관리한다면 이 이야기는 필요 없겠지만, 프로그램과 달리 사람은 언제든 바뀔 수 있다. 그렇기에 어떤 작업을 왜 했는지 기록으로 남겨두는 것이 중요하다는 것을 몸소 체감했다. 그 방법은 여러 가지가 될 수 있다. 문서로 정리해서 남겨두거나, 코드에서는 주석이나 함수명을 자세히 작성하는 방식이 있을 수 있다. 주석을 다는 것이 코드로 충분히 표현하지 못한 것을 보완하는 방법이라 좋지 않다는 말을 들었지만, 코드로 표현할 수 없다면 주석이라도 남겨두어야 다. “왜 이렇게 되어 있는 거지?”라는 질문을 담당자가 찾아가서 직접 설명을 듣는 시간을 아낄 수 있고, 담당자가 없을 때도 대처할 수 있다.
코드에 의도를 최대한 표현하고, 그렇지 않으면 문서나 다른 곳에 표시를 해두는 것이 팀의 효율성을 위한 일이다.
실제로 올해 너무 바빴던 나머지 이런 상황이 가끔 있었고, 내가 겪은 적도 있었기에 이제는 최대한 기록을 남기는 습관이 생겼다.
기술이 다가 아니다.
올해 [회고] 상반기 회고에도 기록했던 내용이다. 크게 달라진 점이 없어 그대로 가져왔다.
기술이 다가 아니다. 10분 만에 해결될 일이 감정 문제로 10일이 걸릴 수도 있다. 개발은 완료되었지만, 서비스 측에 갑자기 생긴 프로세스로 업무가 늘어난 사례가 있었다. 실무자의 협조가 어렵다고 한 부분을 매니저 또는 더 위에 상급자의 도움을 받아서 더 빠르게 해결한 경우도 있었다. 이렇듯 때로는 개발만이 아닌 사람을 통해서도 문제가 해결될 수 있는 거 같다.
리소스만 믿고 의존하면 안 된다.
큰 서비스 개발 경험이 부족해서 그럴 수도 있지만, 개발하다 보면 리소스를 믿는 경향이 있었다. 예를 들면 코드 작성 시 메모리가 충분하다고 생각해 개발했는데 OOM(Out of Memory) 오류가 발생한 경우가 있었고, 옵션을 지나치게 줘서 OOM 오류가 발생한 적도 있었다. 메모리의 예시만 들었지만, 스토리지뿐만 아니라 서비스가 커지면서 네트워크나 데이터베이스에 부하가 걸려 이슈가 발생했던 경험도 있다.
Pod를 실행하면서 OOM 오류가 발생했고, Airflow에서 데이터베이스에 많이 접근하다 보니 병목이 생겼다. 또 인프라 구축 시 옵션을 너무 크게 설정하여 Pod가 죽는 경우도 있었다. 물론 응답 결과가 너무 느리거나 많아서 Swagger에서 응답 없는 상태가 되었던 적도 있다. 서비스가 커지면서 AWS Quota에 걸려 늘려달라고 요청한 경우도 많았다.
초기에 개발 시에는 메모리 신경 쓸 여유가 없지만, 서비스가 커지면서 문제가 터질 수 있다는 점을 항상 염두에 두어야 하고, 가능하다면 미리 대비하는 것이 좋다.
우려한 건 언젠가는 발생할 수 있다.
“아… 이거 나중에 문제가 될 수 있을 것 같은데?”라는 생각이 들었던 부분이 실제로 발생한 경우가 있었다.
클라우드에서 자동으로 생성되는 부분이 있었는데, 좀 포괄적으로 제외해 놓고 나중에 수정했던 경험이 있다. 이 경우, 문서에도 없고 좀 이상하게 만든 것 같다는 의견이 있었지만, 그래도 우려했던 문제가 발생했던 사례였다. 또 다른 사례로는 인프라 구축 설정값을 하나로만 관리하다가, 서비스가 커지면서 배포가 느려지고 관리가 어려워질 것 같았는데, 담당자가 고생해서 이를 바꿔준 경험이 있다.
너무 당연하고 모두가 아는 이야기지만, 한 번 더 염두에 두고 미리 해결하면 좋을 것 같아서 적어봤다. 물론 일을 하다 보면 그것이 쉽지 않지만… 하하. 적절한 타협은 당연히 필요하다.
DEV, STG, PROD의 구분은 중요하다.
개발하는 컴포넌트가 많아짐에 따라 환경 구분의 중요성을 몸소 체감했다.
테스트를 진행하면서 내가 개발한 것과 다른 사람이 개발한 부분이 충돌하거나, 통합 테스트 중에 이슈가 발생하곤 했다. DEV/STG 환경이 일부 겹쳐 있어서 발생한 일이었다.
너무도 당연한 이야기지만, 신규 과제를 진행하는 환경에서는 발생할 수 있기에 적어봤다.
테스트는 너무 중요하다
올해 테스트 및 CI/CD 업무를 맡아 진행했는데, 테스트가 있을 때와 없을 때 품질의 차이와 불안함의 체감 정도가 너무 달랐다.
단위 테스트와 통합 테스트가 있었기 때문에 배포할 때 마음이 많이 놓였다.
품질을 높여주고 사람들을 불안하지 않게 해주는 점에서 큰 매력을 느꼈다.
너무 바쁘다 보니 테스트 작성할 시간이 없다는 건 이해하지만, 그래도 테스트만큼은 꼭 작성하는 게 맞다고 생각한다. 나중에 개발할 때도 반드시 도움이 된다.
사람을 믿지 말자.
오해할 수 있지만, 사람이 나빠서 믿지 말자는 이야기가 아니다. 사람이 실수할 수 있기 때문에 사람에게만 의존하면 안 된다는 이야기다.
협업 중에 사람이 직접 매일 작업을 해주겠다고 했던 곳이 있었는데, 결국 이슈가 생기고 연쇄적으로 스트레스를 받았던 기억이 있다. 최근에도 데이터를 수집해야 하는데 데이터를 올려주지 않거나 다른 포맷으로 주는 경우가 있었기에, 직접 데이터를 수집하는 쪽에서 데이터에 직접 접근할 수 있도록 시스템을 만드는 것이 맞다고 생각한다.
결국 모든 것은 자동화해야 하는 것이 맞다. 서로를 위해 시스템화해야 서로가 편하다. 데이터 파이프라인을 만든다고 가정할 때, 데이터베이스에 직접 접근하는 것부터 적재까지 하나의 팀에서 모니터링할 수 있어야 소통이 줄어든다. 또 다른 예로, 비밀번호나 정보를 사람이 직접 입력하면 실수가 있을 수 있기 때문에 검증을 입력한 사람이 직접 하도록 시스템을 만들어야 한다. 마지막으로, 사람이 테스트를 모두 했더라도 최종 테스트는 기계에 의해 진행되어야 품질을 확실히 보장할 수 있다.
바쁘더라도 필요한 건 해야 한다.
위에서 언급한 내용과 일부 겹치긴 한다. 이 부분도 타협의 영역이고 상황에 따라 달라질 수 있지만, 테스트처럼 중요한 부분은 최대한 시간을 내서 해야 한다.
마이그레이션을 하면서 사용하던 옵션을 빠뜨려서 큰 용량의 값을 처리해야 하는 상황이 있었다. 이를 계속 미루다가 결국 용량이 너무 커져 이슈가 발생했다. 반드시 일어날 것 같고 해야 할 것 같다는 강한 의심이 든다면, 바쁘더라도 지금 해결하는 게 좋다. 서비스 측에도 관련된 부분이라 미리 해야  일이었다.
역시 말처럼 쉽지 않다는 걸 아주 잘 알고 있다.
컨텍스트 체인지에는 많은 시간이 든다.
여기서 말하는 컨텍스트 체인지란 업무의 변경을 의미한다. 맡은 업무가 변경될 수도 있고, 해야 하는 일이 바뀔 수도 있다.
올해 잦은 인터럽트로 인해서 하던 일이 자주 바뀌었고, 정신이 없었으며 일을 재개할 때 집중하기 어려웠다.
상반기에 업무 분장을 새로 했는데, 바쁜 와중에 새로운 업무를 시작하니 다시 익히는 데 시간이 많이 소요됐다. 이렇듯 업무가 변경되면 익히는 데 시간이 많이 드는 것 같으므로, 그런 계획이 있다면 충분한 버퍼를 두는 게 좋을 것 같다.
높은 조직의 정책과 당시 상황의 영향
일을 하다 보면 “왜 저렇게 만들었을까?”라는 질문을 종종 한다. 내가 더 잘 만들 수 있을 것 같다는 자만에서 나오는 질문이 아니라, 조금 돌아서 만드는 느낌을 받을 때가 있었다. 위에서 언급한 파편화가 된 것도 비슷한 맥락이다. 그래서 당시 담당자들과 이야기해 보면 다 이유가 있었다. 팀의 힘이 부족해서 정치나 권력 문제로 상대방에 맞춰야 했던 경우도 있고, “이렇게 안 하면 안 해준다”라는 식의 상황도 있었다. 요구사항이 매번 달라졌고, 일반화가 안 되었으며 여러 가지 이유가 있었다. 이렇듯 당시의 개발 외적인 외부 상황에 따라 개발이 영향을 받아 어려운 방향으로 가는 경우가 있다. 엔지니어가 놓치거나 못한 부분일 수도 있지만, 외부의 영향이 큰 경우도 있다.
파편화된 상황에서 전사 조직으로 바뀌고, 조직 내 힘 있는 리더가 전사에 공표하니 누구나 해야 할 일이 되어서 모두가 대응해 줬다. 기술이 뛰어나도 전사 차원에서 밀어주지 않으면 진행되지 않았을 것이다. 이렇듯 힘 있는 조직에서 정책을 만들어야 일이 진행된다는 것을 경험했고, 그게 맞는 방향이라고 생각한다. 상무급에서 협의하는 것보다 사장급에서 전사에 지시를 내리는 게 훨씬 효율적이다.
체력이 튼튼하고 정신을 똑바로 차려야 한다.
체력은 아무리 강조해도 부족할 정도로 중요하다. 체력이 있어야 집중할 수 있다. 체력이 떨어지면 집중력도 떨어지고 효율도 나지 않는다. 체력이 부족하면 어떤 일이든 효율이 떨어지게 된다.
이전에는 이슈가 발생해도 큰 문제가 되지 않았지만, 이제는 연관된 서비스가 매우 크고, 사용자가 많아 실수가 나면 안 되는 상황이기 때문에 매번 집중해서 일을 했다.
이슈 발생 시 영향이 큰 경우 실수하면 안 되므로 정신을 차려야 한다. 이를 받쳐주려면 체력이 필요하다.
마무리
이 모든 이야기는 올해 느낀 부분으로, 좀 더 자세히 적어서 더 많은 공감을 얻고 싶었지만 회사 관련된 이야기가 많아 세세히 쓰지 못한 것이 아쉽다. 그런데도 제목과 내용을 읽으면서 충분히 공감할 수 있는 사례가 많을 것으로 생각한다. 물론, 이러한 사례들은 상황에 따라 달라질 수 있기 때문에 언제나 유연하게 사고하고 대처해야 한다. 당연히 정답은 아니다.
일을 하면서 몸과 마음이 고생했지만, 그럼에도 몇 가지 배운 점이 있어 긍정적으로 생각한다.

[회고] 개발 회고

댓글