agentic coding을 포트폴리오 개발에 어떻게 사용해야 하고 어떻게 사용하지 말아야 하나요?

How should/shouldn't I use agentic coding to develop a portfolio?

Reddit2026-03-19/u/SoaDMTGguy

배경 및 소개

소프트웨어 엔지니어에서 HCI로 전향하는 사람들이 늘어나고, LLM 기반 agentic coding 같은 자동화·보조 도구가 포트폴리오 제작과 프로토타이핑 속도를 크게 높이면서 ‘이걸 써도 되나’라는 윤리·전략적 고민이 커졌다. 특히 전통적 CS 취업 준비처럼 모든 코드를 직접 짜던 규범과, 결과 중심의 UX/HCI 채용 문화 사이의 간극이 혼란을 만든다. 글쓴이는 2023년 해고 이후 HCI 석사를 마무리하며, 디자인과 UX 역량을 보여주기 위한 실천으로 agentic coding을 받아들이고 있다. 다만 이 방식이 편법처럼 느껴지면서도, 현재의 환경에서 현명한 선택인지, 무엇을 하고 하지 말아야 하는지 커뮤니티의 의견을 구한다.

주요 내용

글쓴이는 BS in CS와 10년 경력의 소프트웨어 엔지니어로서 최근 HCI 석사를 끝내며, 포트폴리오와 작업물을 더 빨리 구현하기 위해 agentic coding을 적극 활용하기 시작했다고 밝힌다. CS 인터뷰를 대비하듯 모든 것을 수작업으로 증명하던 과거 기준에 비추면 다소 ‘치팅’처럼 느껴지지만, HCI 영역에서는 오히려 현명한 전략인지 질문을 던진다. 상위 댓글은 명확한 우선순위를 제시한다. 포트폴리오가 더 빨리, 더 자주 세상에 나오도록 돕는다면 agentic coding을 쓰라는 것이다. 시각·인터랙션 자체의 장인성이 핵심인 역할이거나 이미 그 수준의 장인성으로 평가받는 상황이 아니라면, 사이트의 세공 그 자체가 승패를 좌우하지 않는다는 맥락이다. 대신 만들고, 공개하고, 사람들과 대화하며 피드백을 받는 순환을 최우선으로 하라고 조언한다. 또한 agentic coding을 잘 활용해 결과물이 깔끔하게 나왔다면, 이는 오히려 최신 도구와 협업하는 프로그래밍 역량을 보여주는 긍정적 신호가 될 수 있으며, 기존 소프트웨어 엔지니어링 경력을 깎아내리지도 않는다고 본다. 만약 엔지니어링 역량을 명확히 부각하고 싶다면, 포트폴리오의 겉모습으로 간접적으로 드러내기보다 구체적 case study와 성취 기록을 포함하는 편이 훨씬 효과적이라고 강조한다. 요약하면, 장식보다 산출물의 존재와 그에 얽힌 문제정의, 과정, 영향과 학습을 말할 수 있는지에 초점을 맞추라는 제안이다.

결론 및 시사점

토론의 함의는 분명하다. HCI/UX 채용에서는 ‘어떻게 빌드했는가’보다 ‘무엇을 만들었고 어떤 가치를 냈는가’가 더 자주 평가의 중심이 된다. 따라서 agentic coding과 같은 LLM 보조를 전략적으로 활용해 제작·실험·배포의 사이클을 가속하는 것은 시대에 맞는 합리적 선택이다. 이는 수공예적 완성도를 경시하자는 뜻이 아니라, 역할 요구와 커리어 단계에 맞춰 투입 시간을 배분하라는 조언에 가깝다. 특히 엔지니어 출신이라면 도구 활용 역량 자체도 강점으로 포지셔닝할 수 있고, 이를 보완할 증거로 탄탄한 case study와 성과 지표를 제시하면 된다. 다만 시각 디자인·인터랙션의 미세한 완성도가 핵심인 포지션이라면, 해당 영역만큼은 직접적인 craft를 보여줄 샘플을 별도로 준비해야 한다.

💡 agentic coding으로 제작 속도를 끌어올리고, 포트폴리오엔 문제정의-과정-결과와 성과를 담은 case study를 전면에 두라. 역할이 craft 중심일 때만 세공을 깊게 투자하고, 그 외에는 빠른 공개와 대화를 통해 학습 사이클을 돌리는 게 효과적이다.