<div id="readability-page-1" class="page"><div><p>며칠 전에 “<a href="http://amro.co/software-engineering-isn-t-magic">Software Engineering Isn’t Magic</a>“이라는 글을 읽으면서 많이 공감되었다. 최근에 비슷한 경험도 있어서 개발에 대한 나의 하나의 시각에 대해서 글을 쓰게 되었다. 나도 아직 연차가 많지 않다고 느끼지만, 조금이라도 내 경험을 통해서 신입 개발자들에게 응원이 되었으면 좋겠다.</p><p>몇 달 전에 API가 중복으로 호출하는 때가 있어 확인해달라는 이슈가 있었는데, 당시에 QA 기간이라 신경을 못 쓸 것 같아 신입 개발자에게 확인해보라고 했다. 시간이 좀 지나면서 갑자기 생각난 원인이 될 만한 내용을 신입 개발자에게 얘기했고, 확인해보겠다고 했다. 다행히 내가 생각했던 문제로 인해 API가 중복으로 호출하고 있는 것을 확인했고, 방지하는 코드를 넣어 확인해보니 정상적으로 잘 동작했다. 신입 개발자와 함께 이슈 수정하면서 그 개발자는 어떻게 그렇게 빨리 찾았냐고 나한테 물어봤다. 나 자신도 빠르게 이슈 원인을 찾은 것도 신기했는데, 비슷한 경험이 있었기 때문에 이와 비슷하지 않을까 얘기한 거라고 대답했다.</p><p>내가 입사한 해에 시니어 개발자께서 휴가 간 날에 이슈가 터진 일이 있었다. 앱이 상품 상세 페이지에 진입하면 죽는 이슈였다. 혼자서 이슈를 잘 대응할 수 있을지 걱정하며 원인을 찾아 나섰다. 다행히 원인이 올바르지 않은 데이터 타입으로 내려오고 그것을 casting 하는 부분에서 크래시가 발생한 것을 찾았다. 관련하여 보고했고 무사히 이슈도 해결이 되었다. 이 일 계기로 잘못된 데이터 타입 내려올 경우 크래시가 발생할 수 있다는 것을 깨닫고 if let 혹은 guard let을 해서 안전하게 값을 꺼내는 방법으로 코드를 바꿨다. 그리고 몇 해 지나고 올해, 주니어 개발자가 나에게 잘 동작하는 부분에서 이슈가 나와서 원인 분석해보고 해당 데이터 항목을 사용하고 있는지 물어본 적이 있었다. 혹시 나는 데이터 타입이 다르게 내려와서 그런 거 아닌지 확인해보라고 했다. 잘 되던 동작이 안 된다면 원하는 값으로 안 내려올 가능성이 있기 때문이다. 다행히 내 추론은 맞았고, 백엔드에 원래 사용하던 데이터 타입으로 수정 요청을 했다.</p><p>혼자 몇 시간을 고민하고 삽질했던 시간이 있었기 때문에, 이와 비슷한 문제에 닥친 다른 개발자에게 빠르게 해답을 줄 수 있었다. 어떻게 하면 그렇게 빠르게 알 수 있냐고 물어보면, 오랫동안 고민하는 시간을 나도 똑같이 해서 해결했기 때문이라고 대답한다.</p><p>일이 바쁘지 않는다면 주니어 개발자와 협업할 때 나는 최대한 주니어 개발자가 혼자 문제를 해결할 수 있도록 질문하고 방향만 제시하려고 노력한다. 낚시해서 물고기를 주지 않고 나무 막대기를 주고 낚싯대를 만들어서 물고기를 낚을 수 있도록 해준다. 고군분투하면서 빨리 해결하지 못하겠지만, 낚싯대를 만들면서 깨달은 경험을 가지고 나중에 낚싯대가 부서지면 고칠 수 있고, 더 좋은 낚싯대를 만들 수 있는 거름이 될 거라고 생각된다. 천천히 개발하다 보면 나중에 빠르게 개발할 수 있게 될 것이다.</p></div><div><p> This post is licensed under <a href="https://creativecommons.org/licenses/by/4.0/">CC BY 4.0</a> by the author.</p></div></div>

개발하면서 겪은 경험들은 언젠가 도움이 될 것이다

댓글