저의 성장은 눈에 보이는 화면에서 그 뒤의 설계, 그리고 이게 왜 팔리는지를 이해하는 과정이었습니다. 웹 퍼블리셔로 시작해 웹 표준을 지키며 화면을 그리던 경험은, 지금 프론트엔드 개발자로서 사용자가 쓰기 편한 인터페이스를 만드는 든든한 밑거름이 되었습니다. 백오피스 및 데이터를 시각화하는 프로젝트를 거치며 복잡한 정보를 어떻게 효율적으로 전달할지 고민하게 되었고, 이는 자연스럽게 더 복잡한 비즈니스 로직을 해결하는 엔지니어링의 영역으로 이어졌습니다.

에듀테크와 솔루션, SI 분야에서 일하며 제가 깨달은 것은 명확합니다. 아무리 화려한 기술도 결국 비즈니스 문제를 해결하고 사용자에게 가치를 줄 때만 의미가 있다는 것입니다. 반복되는 운영 업무를 자동화해 리소스를 아끼고, 아무도 쓰지 않던 레거시 시스템을 개편해 도입률을 98%까지 올렸을 때의 쾌감은 제가 왜 개발을 하는지 다시금 깨닫게 해주었습니다. 단순히 코드를 짜는 것을 넘어, 이 기술이 우리 서비스의 신뢰도에 어떤 영향을 줄지 끊임없이 자문하며 일해왔습니다.

현재는 실무에서 느꼈던 부족함을 채우기 위해 한국방송통신대학교에서 컴퓨터과학을 전공하며 이론적인 기초를 다지고 있습니다. 저의 목표는 단순히 프론트엔드 개발자에 머무는 것이 아닙니다. 인프라, 보안, 데이터 정합성 등 시스템 전체를 이해하고 최적화할 수 있는 프로덕트 엔지니어가 되고 싶습니다. 기술적 한계에 부딪힐 때 우회로를 찾거나 아키텍처를 뜯어고쳐 돌파하는 그 과정 자체를 즐기며, 회사의 성장을 기술로 든든하게 뒷받침하겠습니다.

저의 가장 큰 강점은 비즈니스 관점에서 문제를 보고, 다른 직군과 대화할 줄 안다는 점입니다. 개발을 하다 보면 기획이나 디자인 단계에서 구현하기 어려운 난관을 만날 때가 있습니다. 그럴 때 저는 단순히 "안 됩니다"라고 선을 긋지 않습니다. 대신 비즈니스 목표를 해치지 않으면서도 구현 가능한 3~4가지 기술적 대안을 먼저 제시합니다. 이런 태도 덕분에 기획자나 디자이너분들과 "말이 잘 통하는 개발자"라는 신뢰를 쌓을 수 있었고, 이는 프로젝트의 마감 기한을 지키고 완성도를 높이는 핵심 동력이 되었습니다.

또한, 저는 개인의 역량보다 시스템으로 문제를 해결하는 것을 좋아합니다. 누군가 퇴사하면 끊기던 구두 인수인계 관행을 없애기 위해 노션에 문서화 체계를 잡았고, 반복되는 배포 사고를 막기 위해 GitHub Actions를 도입해 파이프라인을 자동화했습니다. "누가 해도 실수하지 않는 환경"을 만드는 것이 팀 전체의 생산성을 높이는 가장 빠른 길이라고 믿기 때문입니다.

성격상의 단점은 초기에 완벽한 설계를 하려다 보니 검토 단계에서 에너지를 많이 쓴다는 점입니다. 하지만 이를 극복하기 위해 요즘은 린(Lean)한 개발 방식을 적극적으로 활용하고 있습니다. 우선순위에 따라 최소 단위의 기능을 먼저 배포하고, 실제 사용자의 데이터와 피드백을 보며 고도화하는 전략을 택합니다. 이를 통해 개발 속도와 품질 사이의 균형을 맞추려 노력하고 있으며, 이런 자기 객관화 과정이 저를 매일 조금씩 더 나은 개발자로 만들고 있습니다.

가장 기억에 남는 성공은 HL7에서 진행한 '대리점 관리 시스템 전면 리뉴얼' 프로젝트입니다. 당시 시스템은 잦은 에러와 데이터 꼬임 현상으로 현업 부서에서 아예 외면받던 상태였습니다. 저는 가장 먼저 불투명한 협업 프로세스부터 정리했습니다. Figma를 도입해 기획과 디자인을 시각화하고 요구사항을 구체적으로 확정했습니다. 기술적으로는 중복된 API 호출을 줄이고 렌더링 성능을 개선해 안정성을 높였습니다. 그 결과, 사용률 0%였던 시스템은 도입률 98%라는 기록적인 수치를 달성했고, "이제 믿고 쓸 수 있겠다"는 현업의 피드백을 받으며 개발팀의 신뢰를 회복할 수 있었습니다.

모바일 수료증 발급 기능을 개발할 때, 데스크톱 환경에서의 완벽한 동작만 믿고 배포를 서둘렀던 것이 화근이었습니다. iOS 기기에서 특정 크기 이상의 캔버스가 빈 화면으로 렌더링되는 치명적인 이슈가 발생했습니다. 환경에 따른 제약 사항을 미리 검토하지 못한 저의 안일함이 만든 기술적 실패였습니다.

당시 당황스러웠지만, 제 실수를 빠르게 인정하고 수습에 집중했습니다. 공식 문서를 샅샅이 뒤져 iOS 캔버스의 메모리 제한 문제를 찾아냈고, 단순히 "안 된다"는 보고 대신 모바일 보기 제한, 즉시 다운로드 방식 변경, 이미지 최적화, S3 URL 활용이라는 4가지 구체적인 기술적 대안을 마련해 팀원들을 설득했습니다. 결국 백엔드 개발자분과 협업해 S3 방식을 채택하며 문제를 해결할 수 있었습니다.

이 경험은 저에게 개발자의 실력은 코드를 짜는 속도가 아니라, 환경의 변수를 고려하는 꼼꼼함에서 나온다는 값진 교훈을 주었습니다. 지금은 어떤 기능을 만들든 최악의 환경을 먼저 시뮬레이션하는 습관을 갖게 되었고, 이러한 신중함은 제가 만드는 제품의 완성도를 높이는 가장 강력한 자산이 되었습니다.