Amazon
Amazon Culture and STAR Examples
Amazon Culture
- Documentation is truly important. Emphasizing the ability to document well is highly valued.
- Things move fast, which naturally fosters an environment where individuals are motivated to demonstrate the visibility and value of their own work.
- Internal mobility is relatively flexible, and team cultures can vary significantly.
STAR Method
(S) Situation: Describe the situation in which the event took place.
(T) Task: Describe the task you were responsible for. If there was a particular problem or issue, explain it here.
(A) Action: Describe the specific actions you took to complete the task or solve the problem.
(R) Result: Share the outcome of your actions. For example, how did they lead to success, resolve a conflict, or benefit the company?
Amazon’s 16 Leadership Principles
Deliver Results
Deliver results no matter the circumstances and speak through outcomes.
S (Situation)
In Security Assessment projects, clients would frequently request penetration tests right before their Go-Live dates. Our team had a strict SLA of delivering results within 5–7 business days, and this standard had to be met even when multiple requests came in at once. With limited resources, the workload was heavy and required a precise execution of both manual and automated testing processes.
T (Task)
In one particular case, I had to complete an entire pentest on my own within just three days, without any support from teammates. Sticking to the timeline was essential, and compromising on quality or accuracy was not an option.
A (Action)
To prepare for situations like this, I had proactively developed custom scripts and a personal toolkit to automate key test items. I customized Burp Suite with plugins to semi-automate frequent API testing tasks, enabling quick identification of issues like authentication bypasses, IDOR, and CSRF. For manual steps, I had compiled a detailed checklist based on past experience and continuously improved it. For reporting, I used a template-driven script to automate documentation while also providing client-tailored explanations and clearly prioritized findings.
R (Result)
As a result, I completed the test with 100% accuracy within the SLA, allowing the client to proceed with Go-Live without delay. The scripts and checklists I developed were shared with the team, improving overall test efficiency. With the saved time, we were able to take on additional projects. Personally, the extra time allowed me to explore advanced attack scenarios, which fed back into the automation scripts and contributed to continuous productivity improvements.
Ownership
Act on behalf of the entire company, not just your own tasks. “That’s not my job” is not acceptable.
S (Situation)
Our team had a 3rd-party report review process for evaluating external penetration test reports to ensure they met our internal security standards. While a criteria document existed, I noticed during repeated involvement with this task that the criteria were often vague or misaligned with real-world scenarios. I raised the issue with senior members and managers, but no one took the initiative to revise or improve the documentation, causing recurring confusion for both me and other team members.
T (Task)
Although this wasn’t a core task for the team, I decided to revise the criteria document myself in order to reduce wasted time and clarify the review standards.
A (Action)
I systematically documented the recurring problems I faced and analyzed the weaknesses of the current criteria. For example, the existing standards required all reports to include a remediation plan, but most external vendors did not provide this since it was out of their scope. I revised the standards so that internal development teams’ remediation plans could be used instead. For cases where only a summary was provided due to confidentiality, I introduced a new rule to add vendors to a blacklist if detailed explanations via calls were insufficient or showed poor reliability, after discussion with the team.
R (Result)
After the criteria update, repetitive email exchanges during the review process dropped by 30–40%, and team members no longer needed to ask me for clarification—they could assess reports on their own. This experience demonstrated that I wasn’t just someone who followed rules, but someone who proactively identified problems and refined standards to enhance the productivity of the entire team as a responsible security engineer.
Customer Obsession
Leaders start with the customer and work backwards. They work to earn and keep customer trust.
S (Situation)
The Legal team within our company wanted to introduce a new Chrome Extension-based application and submitted a Security Assessment (SA) request to our team. The penetration test didn’t reveal any critical issues, but a low-severity file upload vulnerability was found. The application had already been contracted with an external vendor, and the SA requester was a non-technical manager without IT expertise. The vendor claimed the vulnerability was “unfixable,” which left the requester in a difficult position. However, I believed the issue was technically solvable.
T (Task)
While my role only required me to suggest remediation directions—not implement them—I decided to take ownership of the issue and resolve it myself, as the Legal team lacked the technical context and the vendor was uncooperative.
A (Action)
The vulnerability stemmed from the file upload functionality allowing unnecessary formats, which could permit malicious uploads such as PHP files. I reviewed the public API documentation of the application and located the configuration endpoint that allowed upload format restrictions. I then contacted the vendor’s API administrator to obtain the necessary client ID and credentials, and applied the needed restrictions. After confirming that the vulnerability had been mitigated through re-testing, I updated the final report accordingly.
R (Result)
As a result, the Legal team was able to secure SA approval and successfully implement the application into their workflow. The Legal manager expressed deep appreciation for my hands-on support and clear communication, and I was formally recognized with an internal Uplift award. This experience helped me establish credibility not just as a tester, but as a problem-solving engineer who works from the customer’s perspective.
Bias for Action
Speed matters in business. Many decisions and actions are reversible and do not need extensive study.
S (Situation)
Our team is responsible for security reviews before product launches, and typically delivers reports within a 5–7 business day SLA. However, one team requested a pentest under tight Go-Live deadlines. In our standard process, reports are delivered only after full testing is complete. If medium-severity vulnerabilities are found mid-way, launch is often delayed or I have to re-run the same tests after remediation, which is inefficient.
T (Task)
When a medium or higher severity issue was found mid-test, I immediately emailed the development team with detailed findings, remediation guidance, and personally followed up to prioritize their response. I continued testing in parallel while sharing new findings in real-time, even though this meant I’d have to revalidate multiple patched versions later.
A (Action)
Rather than wait for the final report, I communicated each critical finding immediately, helping the developers begin remediation right away. I managed the ongoing tests in parallel, monitored patch updates, and re-validated them without disrupting the overall workflow.
R (Result)
This parallel approach allowed the security review and patching to happen concurrently, enabling the product to Go-Live on schedule. The development team appreciated the time savings and clarity. Although it added extra workload for me, the organization benefitted by maintaining both launch deadlines and security quality. This workflow was later shared as a best practice for other time-sensitive projects.
Dive Deep
Leaders operate at all levels, stay connected to the details, and audit frequently. No task is beneath them.
S (Situation)
One of the initial steps in mobile app penetration testing is Root Detection Bypass. For Flutter-based apps we tested, traditional scripts couldn’t bypass root detection. We often had to request test versions from developers with security features disabled. I saw this as unrealistic from an attacker’s point of view—true assessments needed to occur in production-like environments.
T (Task)
My goal wasn’t just test convenience, but to technically analyze Flutter root detection mechanisms and develop my own bypass script. Existing automated tools and static analysis methods didn’t work well in this scenario.
A (Action)
I performed reverse engineering to trace the Flutter app’s execution flow and root detection points. I identified suspicious functions and monitored their behavior using Frida-based hooking scripts to see exactly when and why detection was triggered. During research, I found a paper analyzing Flutter security mechanisms, and cross-referenced its methods with my function tracing. I then mapped out key JNI calls involved in detection and developed a Frida script to bypass or neutralize them. After development, I tested the script across several internal apps to validate its stability and reproducibility.
R (Result)
I successfully developed a stable Frida script that bypassed root detection in Flutter apps, which I shared with the team. This significantly improved test coverage and speed for similar apps in the future. More importantly, we no longer needed “test-only” versions—our assessments were now conducted under real production conditions, increasing both the realism and credibility of our findings. This experience helped establish me as an engineer who doesn’t just rely on tools, but deeply understands and dismantles technical barriers.
Have Backbone; Disagree and Commit
Leaders respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Once a decision is determined, they commit wholly.
S (Situation)
Whenever a new version of an application was released, we conducted another round of penetration testing. Traditionally, the same tester would handle the same application repeatedly, which improved efficiency. Our team culture valued autonomy and did not enforce any strict processes. However, from a security quality standpoint, I believed rotating testers could bring diverse perspectives and enhance overall test coverage.
T (Task)
I knew that my suggestion would go against the preferred method of many senior members, but I decided to raise my minority opinion as I believed quality should take precedence. I was prepared to accept the final decision by our manager, but I aimed to back my proposal with solid reasoning and data.
A (Action)
I voluntarily took over a Security Assessment (SA) originally assigned to another tester and discovered vulnerabilities that had been previously missed. I also gathered other cases where tester rotation—due to PTO or scheduling—led to the discovery of new issues. With this data, I built both quantitative and qualitative evidence and presented my case during a team stand-up. I made it clear that while autonomy was important, we couldn’t compromise on security quality. As a result, the manager decided to implement a pilot policy where if a tester had handled the same app three times, it would be reassigned to someone else.
R (Result)
The proposal struck a balance between respecting team autonomy and improving security coverage. In fact, some rotated testers did find issues that had been overlooked before. While my suggestion wasn’t adopted in full, I was able to assert my viewpoint with technical rationale and real examples, and I fully supported the final decision once it was made. This experience demonstrated my responsibility in improving security quality and my ability to advocate for change without disrupting team cohesion.
Insist on the Highest Standards
Leaders continually raise the bar and drive their teams to deliver quality.
S (Situation)
Our team managed a 3rd-party report review process to assess whether external pentest reports met internal security standards. Although we had a criteria document, it was often vague or misaligned with reality, leading to inconsistent evaluations and unnecessary back-and-forth among team members.
T (Task)
Even though I wasn’t officially responsible for maintaining the criteria document, I believed that improving it would directly impact our team’s productivity and the consistency of report quality. I decided to fix the ambiguity and raise the standard to a level that anyone could confidently apply.
A (Action)
I reviewed past assessments where ambiguity in the criteria had caused confusion or rework. For instance, the original criteria required all reports to include a remediation plan, but many vendors did not provide this as it was beyond their scope. I revised the policy to accept internal remediation plans from development teams as valid alternatives. Additionally, in cases where only summary reports were provided due to confidentiality and full details were only shared via calls, I proposed new rules for blacklisting vendors who failed to meet the expected depth or transparency. I also hosted a knowledge-sharing session to explain the revised criteria and later collected feedback to validate its effectiveness.
R (Result)
After implementing the changes, email traffic during the review process dropped by 30–40%, and team members could independently evaluate reports without needing further clarification. Our team began to operate under a consistent and higher-quality standard, and the document was officially adopted as a reference for onboarding new members. This experience demonstrated my commitment not only to doing my job well but to raising our team’s overall quality and eliminating recurring inefficiencies.
Earn Trust
Leaders build trust through integrity, transparency, and consistency.
S (Situation)
When applying to this team, I submitted a coding challenge as part of the hiring process. My solution was highly optimized and cleanly structured—so much so that some team members suspected I had cheated, as it was very similar to the reference answer they had prepared.
The hiring manager and a senior engineer called me directly to walk through my solution, and I calmly explained the logic, choices, and implementation. In the end, they concluded I had not cheated and offered me the role based on merit.
T (Task)
Despite being hired, I understood that some doubts might linger. I wanted to prove myself and earn my teammates’ full trust—not just through performance, but by becoming a technical contributor who lifted the entire team’s capability.
A (Action)
I soon noticed that the team lacked best practices around GitHub collaboration. I initiated a Lunch & Learn session to introduce Git Flow and demonstrated practical examples through live pair programming. I also created a guide on writing pull requests, resolving conflicts, and managing commits. Additionally, I identified inconsistencies in naming conventions and directory structures across projects, created a standard, and shared it via the team wiki. As these practices gained adoption, teammates began asking for my input in code reviews and newer projects.
R (Result)
No one questions my technical ability anymore. In fact, the tools and guidelines I introduced have become standards across multiple projects. My calm explanations during issues and consistent efforts to help the team have earned me a strong reputation. Now, when a complex problem arises, people confidently say, “Ask Daniel—he’ll figure it out.”
Invent and Simplify
Leaders seek out innovative solutions and reduce complexity.
S (Situation)
While automating internal workflows using Microsoft Power Automate, I encountered a case where I needed to compare hash maps. While this logic would take just a single line of code, implementing it within Flow required more than 10 Actions and complex conditional branches. This reduced readability and increased execution cost.
T (Task)
My goal was to restructure this logic for clarity, efficiency, and maintainability. I needed to simplify the complexity and find a way to bypass platform limitations through architectural innovation.
A (Action)
I first analyzed the existing Flow structure and removed redundant conditions and array traversal logic. I then leveraged Power Automate’s external call feature to delegate the hash map comparison to an Azure Function running Python. With this setup, the Flow required only a single HTTP request to perform the entire comparison. Python’s built-in libraries provided both performance and accuracy.
R (Result)
The original 10+ Actions were replaced by a single step, significantly reducing maintenance overhead and cost. This structure became a reusable template for other automation scenarios, and Azure Function-based logic was later adopted as a best practice within the team. This experience showed that I’m not just good with tools—I can redesign systems to improve efficiency at scale.
Learn and Be Curious
Leaders are never done learning and always seek to improve themselves.
S (Situation)
With the rise of AI technologies like ChatGPT, it became clear that future security engineers would need more than traditional defensive skills—they would require competencies in AI and data analysis. At our company, counterfeit apps were frequently appearing in app stores, and our rule-based detection system was hitting its limits.
T (Task)
Rather than treat this as just a surface-level issue, I enrolled in an AI application-focused program at UT Austin’s McCombs Business School. My goal was not just academic learning, but to apply AI techniques directly to my day-to-day work.
A (Action)
The program included hands-on projects, and I used it as an opportunity to build a pipeline that gathered metadata from Google Play and the App Store. I then developed a lightweight model to classify apps that were visually or descriptively similar to our official products, but were actually fakes. I integrated the detection model with our automation system, enabling it to send DMCA emails to app store administrators whenever a counterfeit app was found.
R (Result)
With this system, we were able to detect many apps that were previously missed by rule-based filters. Many were successfully taken down through legal channels, protecting users from impersonators. This experience solidified my value as a security engineer who not only learned AI but applied it to enhance our company’s actual security posture.
Hire and Develop the Best
Leaders hire and mentor the best people and help them grow.
S (Situation)
A new junior security engineer joined our team with a background in infrastructure and system operations, but no experience in penetration testing. He struggled with analyzing vulnerabilities and drafting client-facing reports, which slowed his progress and impacted his confidence.
T (Task)
Though not officially assigned as a mentor, I wanted to help this teammate become more than just a passive learner—I aimed to help him grow into a key contributor capable of working independently.
A (Action)
I created a step-by-step onboarding guide with checklists covering our pentesting process, including Burp Suite usage, report writing tips, and hands-on examples of common vulnerability reproduction. I also initiated weekly 1:1 sessions where we worked through real projects together, focusing not only on “what” to do, but also on “why”—like why a certain vulnerability is rated as high severity, or in what context a payload is effective. While reviewing his work, I provided constructive feedback with encouragement, correcting recurring mistakes and clearly acknowledging improvements.
R (Result)
After about three months, he was handling Security Assessments independently. In fact, during one project, he discovered an OAuth misconfiguration I had missed and shared it with the team. In a retrospective, he credited our sessions with helping him gain confidence, and the manager praised me as a team member who contributes both technically and through people development. This experience showed me that developing others is just as crucial to team success as delivering individual results.
Think Big
Thinking small is a self-fulfilling prophecy. Leaders create and communicate a bold direction that inspires results.
S (Situation)
Our team was responsible not only for mobile app security assessments but also for identifying fake apps in third-party app stores. The existing process was highly manual, with fragmented communications across emails, internal tools, and ad hoc conversations—wasting over three hours per week on coordination alone.
T (Task)
I saw this not just as a repetitive task issue, but as a chance to rethink and automate the entire pipeline. I believed that with the right system in place, our response time and strategic capabilities could be significantly improved.
A (Action)
I used Power Automate to create a workflow triggered by external emails, which queried internal systems and automatically identified the appropriate point of contact. I consolidated scattered internal data into a unified database and built a Power BI dashboard that visualized real-time status, detection rates, and response times. I also restructured our workflow to remove dependency on external detection vendors and migrated everything into internal systems.
R (Result)
The average response time dropped from 3–4 days to under 24 hours, and over three hours of manual work were saved weekly. Beyond our team, this solution was later evaluated by the web pentest team as a potential model for broader adoption. Through this, I gained experience not just in solving a small task, but in scaling an entire security strategy through systems thinking and execution.
Frugality
Accomplish more with less. Constraints breed resourcefulness and innovation.
S (Situation)
During an internal project, we needed a database solution to store and process data. While Microsoft Dataverse offered robust features, it required a paid subscription. At the time, the company was actively pursuing budget reductions.
T (Task)
My goal was to meet all project requirements without incurring extra costs. I needed to verify whether a free alternative—Microsoft Lists—could meet our performance, security, and backup needs.
A (Action)
I listed the project’s essential requirements (e.g., read/write performance, data protection, backup schedules) and compared them against Dataverse and Microsoft Lists. I conducted further research to confirm whether encryption and access control could be implemented within the Microsoft Lists environment, and designed additional logic using Power Automate to automate backups and implement security rules.
R (Result)
In the end, I was able to meet all project needs using Microsoft Lists, avoiding significant licensing costs. The resulting system was lightweight, easy to maintain, and adaptable for other small-scale or MVP projects. I received recognition for turning a constraint into an opportunity and delivering a scalable solution that aligned with our company’s financial goals.
Success and Scale Bring Broad Responsibility
Leaders are determined to make a positive impact on customers, communities, and the world.
S (Situation)
I don’t believe that I reached where I am today by myself. I’ve had mentors, supporters, and environments that empowered me. That’s why I feel a responsibility to give back and apply my skills where they’re most needed.
T (Task)
I wanted to use my technical expertise to create real change for those without access to it. So, I joined Mtree, a volunteer group that introduces science and engineering to communities without electricity. I wasn’t interested in one-time donations—I wanted to be hands-on and present.
A (Action)
In a remote village with no electricity, I demonstrated technologies like drone-based supply delivery, autonomous transport, and more. For children unfamiliar with the concept of “technology,” I explained that engineers are problem-solvers, and that they, too, could identify and fix problems around them. We didn’t just showcase tools—we co-designed solutions for local problems using only the materials they had. I focused on teaching practical scientific thinking and methods that could be applied in their reality.
R (Result)
Where once “I want to be a soldier” was the only dream, ki
아마존 문화 및 STAR 사례 정리
아마존 문화
- Documentation이 진짜 중요하다. 다큐멘테이션을 잘 하는것을 강조해주면 좋은 것 같다.
- 빠른 페이스로 돌아간다. 따라서 자기 스스로가 업무의 가기성을 보이기 위한 노력을 하게 되는 환경이다.
- 내부 포지션 변경이 쉽고 자유로운 편이고 팀마다 분위기가 너무 다를 수 있다.
STAR 대화 기법
(S) Situation. Describe the situation in which the event took place. (T) Task. Describe the task you were asked to complete. If there was a particular problem or issue you were trying to solve, describe that here. (A) Action. Explain what action you took to complete the task or solve the problem. (R) Results. Explain the result of your actions. For example, if your actions resulted in completing a task, resolving a conflict, improving your company’s sales record, etc., explain this. Try to focus on how your actions resulted in a success for the company.
Amazon의 16가지 Leadership Principles
Deliver Results
어떤 상황에서도 목표를 달성하며 결과로 말한다.
S (Situation) Security Assessment 프로젝트에서 고객들이 종종 Go-Live 직전에 펜테스트를 요청하는 일이 많았어. 우리 팀의 SLA는 5~7 영업일 내 결과 제공이었지만, 여러 건이 동시에 몰리는 경우에도 이 SLA는 반드시 지켜져야 했지. 리소스는 한정되어 있었고, 실수 없이 수동/자동 단계를 모두 거쳐야 했기 때문에 작업 부담이 매우 컸어.
T (Task) 그 중 하나의 프로젝트에서는 단 3일 내에 모든 펜테스트를 혼자서 마무리해야 했고, 팀원의 지원도 받을 수 없는 상황이었어. 일정 준수는 물론, 품질과 정확성도 절대 포기할 수 없었어.
A (Action)
이런 상황을 대비해 평소에 주요 테스트 항목을 자동화하는 개인 스크립트와 툴킷을 미리 개발해뒀어. Burp Suite에서 자주 수행하는 API 테스트 작업을 plugin 형태로 커스터마이징해뒀기 때문에, 인증 우회, IDOR, CSRF 등 주요 항목을 반자동화된 방식으로 빠르게 탐지할 수 있었어. 수동 확인이 필요한 경우를 대비해 항목별 점검 체크리스트를 정리해놓았고, 이 리스트는 경험을 바탕으로 계속 보완해 왔어. 테스트 결과 리포트는 템플릿 기반 자동 생성 스크립트를 이용해 작성 시간을 단축하면서도, 클라이언트 맞춤형 설명과 우선순위까지 명확히 제시했지.
R (Result)
그 결과 SLA 내 테스트를 100% 정확하게 완료했고, 고객은 예정된 Go-Live를 지연 없이 진행할 수 있었어. 이 경험을 통해 만든 스크립트와 체크리스트는 팀 내부에 공유되어 전체 테스트 효율을 높이는 데 기여했고, 우리는 남는 시간으로 추가 프로젝트를 수주할 수 있었지. 개인적으로는 절약된 시간 덕분에 심화 공격 시나리오 연구를 할 수 있었고, 이 연구 결과는 다시 자동화 스크립트에 반영되어 지속적인 생산성 향상으로 이어졌어.
Ownership
자신이 맡은 일뿐만 아니라 전체에 대해 주인의식을 갖고 행동한다. “그건 내 일이 아니에요”라는 말은 없다.
S (Situation)
우리 팀에는 외부 업체가 수행한 펜테스트 리포트를 검토하는 3rd party report review 프로세스가 있어. 이는 직접 테스트를 하지 않는 대신, 외부 리포트로 내부 보안 기준을 충족했는지를 판단하는 절차야. 팀에서는 이를 위한 기준(criteria)을 마련해뒀지만, 내가 반복적으로 이 업무를 하면서 기준이 애매하거나 현실과 맞지 않는 부분이 있다는 걸 발견하게 되었어. 시니어와 매니저에게 문제점을 제안하긴 했지만, 누구도 문서를 직접 수정하거나 개선하지 않았고, 그로 인해 나뿐만 아니라 다른 팀원들도 같은 고민을 반복하고 있었어.
T (Task)
이 업무가 팀의 핵심 업무는 아니었지만, 팀원들의 불필요한 시간 낭비를 줄이고 검토 기준의 명확화를 위해 내가 직접 이 기준 문서를 개선하기로 했어.
A (Action)
내가 자주 겪은 문제 상황을 정리해서 기준 문서의 문제점을 체계적으로 분석했어. 예를 들어, 기존 기준에서는 모든 리포트에 remediation plan 포함을 요구했지만, 실제로 대부분의 외주 업체는 그것이 업무 범위가 아니라 포함하지 않았어. 그래서 나는 리포트가 아니라 내부 개발팀이 별도로 제공하는 계획 문서를 기준으로 수용할 수 있도록 기준을 수정했어. 또한 기밀성 문제로 인해 summary만 제공되는 경우, call을 통해 detail을 설명했음에도 내용이 불충분하거나 신뢰도가 떨어지는 업체에 대해서는 팀과 논의 후 blacklist에 추가하는 기준도 새로 만들었어.
R (Result)
이러한 기준 개편 이후, 리뷰 과정에서 반복되던 이메일 커뮤니케이션 횟수가 30~40% 감소했고, 다른 팀원들도 기준에 대해 더 이상 나에게 따로 문의하지 않고 스스로 판단할 수 있게 되었어. 나는 이 경험을 통해 단순히 기준을 따르는 입장이 아니라, 문제를 발견하고 기준을 스스로 정비하여 팀 전체의 생산성을 높인 책임 있는 보안 엔지니어로서의 역할을 보여줄 수 있었어.
Customer Obsession
고객을 최우선으로 생각한다. 내부 결정도 고객에게서 거슬러 올라가서 판단한다.
S (Situation)
회사 내 Legal 팀에서 새로운 Chrome Extension 기반 어플리케이션을 사용하고 싶어 했고, 이를 위한 보안 점검 요청(SA)을 우리 팀에 보냈어. 펜테스트 결과로는 심각한 취약점은 없었지만, Low severity 수준의 file upload 관련 취약점이 발견되었지. 이 어플리케이션은 외부 개발사와 계약된 상태였고, SA 요청자는 IT 지식이 없는 비기술 매니저였어. 문제는 외부 개발자가 해당 취약점을 “수정 불가”라고 주장하고 있어 SA 요청자는 곤란해하고 있었고, 나는 이 기능이 기술적으로 충분히 해결 가능해 보인다고 판단했어.
T (Task)
내 업무 범위는 보안 이슈에 대해 remediation 방향을 제시하는 것까지만 포함되었고, 실제 구현은 책임이 아니었어. 하지만 Legal 팀은 상황을 이해하지 못했고, 외주 개발사는 협조적이지 않았기 때문에, 나는 이 문제를 내가 직접 해결하겠다고 결정했어.
A (Action)
취약점은 파일 업로드 기능이 불필요한 포맷까지 허용하고 있다는 점이었고, 이는 PHP 파일 등 잠재적 악성 코드 업로드를 허용할 수 있는 설정이었어. 나는 해당 어플리케이션의 공개 API 문서를 분석하고, 업로드 포맷을 제한할 수 있는 configuration endpoint를 직접 찾았어. 이후, 어플리케이션 제공사 측 API 담당자에게 연락해 client ID와 credentials를 요청했고, 이를 통해 필요한 제한 설정을 적용했어. 수정 사항은 재검증을 거쳐 취약점이 해결된 것을 확인했고, 이를 리포트에 반영했지.
R (Result)
이 조치를 통해 Legal 팀은 해당 어플리케이션에 대해 정상적으로 SA 승인을 받을 수 있었고, 실제 업무에 도입함으로써 팀 전체의 워크플로우가 개선되었어. Legal 매니저는 내가 보여준 직접적인 도움과 이해하기 쉬운 커뮤니케이션에 대해 깊이 감사했고, 회사 내부 시스템 상에서도 공식적인 Uplift를 수여받았어. 나는 이 경험을 통해 단순히 취약점을 보고하는 역할을 넘어서, 고객의 입장에서 실질적인 문제 해결을 돕는 엔지니어로서의 신뢰를 구축할 수 있었어.
Bias for Action
완벽을 기다리기보다는 빠르게 실천한다.
S (Situation)
우리 팀은 제품 출시 전 보안 검토를 담당하며, 일반적으로 SLA 기준 5~7일 동안 모든 테스트를 완료한 후에 리포트를 제공해. 하지만 특정 팀은 Go-Live 일정이 촉박한 상황에서 펜테스트를 요청했고, 테스트 중 medium severity 취약점이 발견되면 출시가 중단될 수밖에 없는 구조였어. 기존 프로세스상으로는 테스트를 모두 마친 후 리포트를 통보하는 방식이었고, 이후 고객 팀이 remediation을 시작하면 출시가 지연되거나, 내가 동일한 테스트를 반복해야 하는 상황이 생기곤 했지.
T (Task)
테스트 도중 medium 이상의 취약점이 발견되면 리포트가 나오기 전에 즉시 개발팀에 메일로 상세 내용을 전달했어. 취약점 설명과 remediation 가이드를 함께 제공했고, 개발자가 빠르게 대응할 수 있도록 직접 연락해 대응 우선순위를 설명했지. 테스트는 계속 진행하면서 추가 취약점도 실시간으로 공유했고, 내가 그로 인해 중간중간 패치 버전을 다시 점검해야 하는 부담도 감수했어.
A (Action)
테스트 도중 발견된 취약점을 리포트가 완료되기 전 개발팀에 즉시 공유했고, 직접 연락을 통해 우선순위 조정 및 대응을 유도했어. 테스트는 그대로 병행하면서 실시간으로 발견된 이슈를 전달하고, 중간 패치된 버전도 다시 점검하면서도 전체 흐름을 놓치지 않도록 관리했지.
R (Result)
이 방식 덕분에 보안 점검과 취약점 조치가 병렬로 진행되면서, 제품은 원래 예정대로 Go-Live 할 수 있었고, 개발팀은 패치 작업을 미리 시작해 시간을 절약할 수 있었어. 반복 테스트는 나에게 추가 부담이었지만, 조직 차원에서는 출시 일정 유지와 품질 확보라는 두 가지 목표를 동시에 달성할 수 있었고, 이후 이 방식은 다른 긴급 프로젝트에도 참고될 수 있도록 내부적으로 사례로 공유되었어.
Dive Deep
데이터를 끝까지 파고들고, ‘왜’라는 질문을 계속한다.
S (Situation)
모바일 앱 펜테스팅에서 가장 먼저 수행하는 단계 중 하나는 루팅 탐지 우회(Root Detection Bypass)야. 우리가 다루는 앱 중 Flutter 기반으로 개발된 앱은 기존 스크립트들로는 루팅 탐지를 우회하기 어려웠고, 개발사에 “보안 기능이 꺼진 테스트 버전”을 요청해야 할 때도 있었어. 하지만 나는 이 방법이 해커의 관점에선 불완전하다고 생각했고, 실제 환경(prod와 동일 조건)에서의 우회가 가능해야 한다고 판단했어.
T (Task)
내 목표는 단순 테스트 편의가 아니라, Flutter 기반 루팅 탐지를 기술적으로 분석하고, 직접 우회 스크립트를 개발하는 것이었어. 이 작업은 자동화 도구로 해결되지 않았고, 정적인 코드 분석이나 기존 방법론이 통하지 않는 상황이었어.
A (Action)
먼저 Flutter 앱의 실행 플로우와 루팅 감지 포인트를 추적하기 위해 리버스 엔지니어링을 수행했어. 주요 의심 함수를 추출한 후, Frida 기반 hooking 스크립트로 해당 함수들의 실행 흐름을 관찰했고, 어떤 조건에서 차단이 발생하는지 확인했어. 동시에, 관련 정보를 검색하던 중 Flutter 앱 보안 로직 분석에 관한 논문을 발견했고, 논문에서 소개된 감지 방식과 내가 수집한 함수 흐름을 대조했지. 이를 바탕으로 루팅 탐지에 핵심적으로 사용되는 JNI 함수 호출 시점을 정리하고, 그 부분을 우회하거나 무력화하는 Frida 스크립트를 자체적으로 개발했어. 개발 이후 팀 내부 테스트 환경에서 다양한 앱에 적용하며 안정성과 재현성을 검증했지.
R (Result)
그 결과, 나는 Flutter 루팅 탐지를 안정적으로 우회할 수 있는 Frida 스크립트를 완성했고, 이를 팀에 공유함으로써 이후 유사한 앱의 테스트 속도와 범위가 개선되었어. 덕분에 우리는 보안 기능이 꺼진 테스트 버전이 아닌, 실제 prod 환경 조건에서의 테스트가 가능해졌고, 이는 전체적인 보안 평가의 현실성과 신뢰도를 크게 향상시켰지. 이 경험은 내가 단순히 도구를 사용하는 테스터가 아니라, 기술 구조를 깊이 이해하고 직접 파고들어 문제를 푸는 전문가로서 신뢰를 쌓는 계기가 되었어.
Have Backbone; Disagree and Commit
동의하지 않으면 분명하게 의견을 내고, 결정되면 끝까지 헌신한다.
S (Situation)
우리는 동일한 애플리케이션의 새로운 버전이 나올 때마다 펜테스트를 다시 수행해. 기존에는 동일한 테스터가 계속해서 같은 앱을 맡는 경우가 많았고, 이는 테스트 효율성을 높이는 데 기여했지. 팀에는 자율성과 효율성을 중시하는 시니어들이 많았고, 누구의 방식도 강제하지 않는 문화였어. 하지만 나는 보안 품질 관점에서는 테스터를 교체하며 다양한 시각에서 테스트하는 것이 중요하다고 판단했고, 테스트 커버리지를 높이기 위한 구조적 개선이 필요하다고 느꼈어.
T (Task)
나는 이 제안이 다수의 시니어들이 선호하는 기존 방식과 다르다는 걸 알았지만, 보안 엔지니어로서 품질을 우선시해야 한다는 입장에서 소수 의견을 제시하기로 마음먹었어. 최종 판단은 매니저에게 맡기되, 나는 내 주장의 타당성을 명확히 입증하겠다고 결심했지.
A (Action)
우선, 내가 자발적으로 다른 테스터가 맡았던 SA를 진행하고 이전 테스트에서 발견되지 않았던 취약점을 실제로 찾아낸 사례를 정리했어. PTO나 일정으로 인해 테스터가 교체되었을 때 새롭게 발견된 취약점 사례도 모아서, 사례 기반의 정량/정성 데이터로 제안의 근거를 마련했어. 이를 바탕으로 팀 스탠드업 미팅에서 직접 의견을 공유했고, “자율성은 중요하지만, 보안 품질도 고려해야 한다”는 입장을 명확히 전달했지. 매니저는 내 제안이 일리가 있다고 판단했고, 모든 테스트를 다 교체하진 않되, 동일 앱에 대해 3회 이상 테스트한 경우에는 다른 테스터에게 순환하는 정책을 시범 도입하기로 결정했어.
R (Result)
이 제안은 기존 시니어들의 자율성과, 내가 주장한 시큐리티 커버리지 사이에서 균형을 맞춘 타협안으로 채택되었고, 실제로 일부 앱에서 새로운 테스터가 이전에 발견하지 못한 취약점을 식별하는 사례도 이어졌어. 나는 내 의견이 모두 받아들여지진 않았지만, 기술적 근거와 실제 사례로 이견을 제시했고, 결정이 내려진 후에는 팀의 정책에 따라 충실히 협력했어. 이 경험은 내가 조직의 보안 품질을 높이기 위한 책임감을 갖고 행동했으며, 동시에 팀워크를 저해하지 않고 유연하게 조율할 줄 아는 엔지니어라는 점을 보여줬지.
Insist on the Highest Standards
품질과 기준을 높게 유지하며, 타협하지 않는다.
S (Situation)
우리 팀은 외부 보안 업체가 수행한 펜테스트 리포트를 검토하여, 내부 보안 기준에 부합하는지를 평가하는 3rd party report review 프로세스를 운영하고 있었어. 이를 위해 기준 문서(criteria)가 존재했지만, 실제 업무에서 반복적으로 해당 기준이 모호하거나 현실과 맞지 않는 부분이 많았고, 이로 인해 팀원들 간 평가 기준이 일관되지 않거나, 불필요한 커뮤니케이션이 반복되는 문제가 발생하고 있었지.
T (Task)
이 기준 문서는 내가 공식적으로 관리하거나 책임지는 영역은 아니었지만, 나는 리포트 품질을 보장하고 평가의 일관성을 유지하는 것이 우리 팀 전체의 신뢰성과 생산성에 직결된다고 판단했어. 그래서 나는 실제 현업에서 발생하는 문제를 해결하고, 누구나 기준을 명확하게 이해하고 적용할 수 있는 수준으로 개선하기로 결심했지.
A (Action)
우선 내가 직접 수행했던 3rd party 리포트 리뷰 중에서, 기준의 모호함으로 인해 혼란이나 재작업이 발생했던 사례들을 정리했어. 예를 들어, 기존 기준에서는 모든 리포트에 remediation plan을 포함하도록 요구하고 있었지만, 대부분의 외주 업체는 이 항목을 제공하지 않거나 업무 범위에 포함시키지 않았던 현실이 있었어. 나는 이를 개선하기 위해, 리포트 자체에 remediation plan이 없는 경우에는 내부 개발팀에서 작성한 보완 계획 문서를 기준으로 대체할 수 있도록 문서를 수정했어. 또한, 기밀성 문제로 인해 summary report만 제공되고 detail은 call로만 전달되는 경우, 테스트 내용이 불충분하거나 확인이 어려운 업체는 객관적인 평가 기준을 통해 블랙리스트에 등록할 수 있도록 추가 조항을 명시했어. 기준 문서를 단순히 수정한 데서 끝내지 않고, 팀 내부 공유 세션을 열어 개선된 기준에 대한 이해도를 높였고, 이후 적용 사례를 수집해 기준의 정합성과 실효성을 검증했어.
R (Result)
이 기준 개편 이후, 반복되던 이메일 커뮤니케이션 횟수는 약 30~40% 감소했고, 팀원들은 기준에 대한 추가 설명 없이도 리포트를 자율적으로 판단하고 처리할 수 있게 되었어. 무엇보다도, 팀 전체가 일관되고 높은 수준의 기준 아래에서 업무를 수행할 수 있게 되었고, 이 문서는 신규 인력 온보딩 시에도 참조 문서로 정식 등록되었지. 나는 이 경험을 통해 단순히 내 업무의 품질만 지킨 것이 아니라, 우리 팀의 기준을 한 단계 끌어올리고, 반복 오류를 체계적으로 제거해 조직의 품질 문화를 개선하는 데 기여할 수 있었어.
Earn Trust
정직함, 겸손함, 일관된 행동으로 신뢰를 얻는다.
S (Situation)
내가 이 팀에 지원할 때, 사전 과제로 코딩 테스트를 제출해야 했어. 나는 최적화된 코드와 깔끔한 구조로 문제를 풀었는데, 내 풀이가 팀에서 준비한 정답 코드와 매우 유사한 수준이어서, 일부 팀원들이 치팅을 의심했어.
그래서 Hiring Manager와 시니어 엔지니어가 직접 나에게 전화를 걸어, 문제 해결 로직을 설명해보라고 요청했고, 나는 그 자리에서 로직과 선택 이유, 구현 방식을 차분히 설명했지. 결국 그들은 내가 치팅하지 않았다는 것을 이해하고 공정하게 실력을 평가한 끝에 나를 팀에 합류시켰어.
T (Task)
하지만 나는 이 의심이 남아 있을 수 있다는 것을 알았고, 그렇다면 내 실력을 보여주고, 의심 없이 신뢰받는 팀원이 되겠다고 마음을 먹었어. 단지 맡은 일만 하는 것이 아니라, 팀의 기술 역량을 끌어올리는 방식으로 기여하고 싶었지.
A (Action)
입사 후 초기에는 팀원들이 GitHub을 잘 활용하지 못하는 문제가 있다는 걸 파악하고, 내가 직접 준비한 Lunch & Learn 세션에서 Git Flow와 협업 방식을 팀 전체에 설명했어. 실습 기반으로 팀원들과 pair 세션을 진행하면서, pull request 작성, conflict resolution, commit 관리 등 GitHub 실무 중심의 가이드를 문서화했지. 또, 프로젝트별로 naming convention이나 디렉토리 구조가 일관되지 않은 점을 개선하기 위해, 내가 기준을 정하고 wiki에 공유했고, 점차 다른 프로젝트에도 적용되기 시작했어. 이후 코드 리뷰나 신규 프로젝트에서 팀원들이 나에게 먼저 코드를 검토해달라고 요청하는 경우가 많아졌고, 내가 참여한 코드 기반의 품질이나 가이드라인이 팀 내 기준점으로 활용되기 시작했어.
R (Result)
이제는 내 개발 역량을 의심하는 팀원은 아무도 없고, 오히려 내가 만든 가이드라인과 도구들이 팀 전반에 확산되면서 ‘기준을 만드는 사람’으로 인정받고 있어. 기술적인 실력뿐 아니라, 문제 발생 시 차분하게 설명하고, 팀 전체에 도움이 되도록 솔루션을 제공했던 행동들이 누적되어 나는 신뢰받는 팀원이 되었고, 팀워크가 필요한 상황에서도 “이건 Daniel에게 물어보면 확실하게 해결될 거야”라는 믿음을 얻게 되었지.
Invent and Simplify
복잡함을 단순하게 만들고, 새로운 방식을 고민한다.
S (Situation)
내가 사내 업무 자동화를 위해 Microsoft Power Automate Flow를 사용해 자동화 시스템을 구축하고 있었어. 그 중 하나는 hash map을 비교하는 로직이었는데, 코드로는 1줄이면 끝날 작업이 Flow 안에서는 10개 이상의 Action과 복잡한 조건 분기로 구현되어야 했고, 이는 구현 가독성을 떨어뜨리고, 실행당 비용을 높이는 문제로 이어졌어.
T (Task)
나는 이 로직을 가독성 있게 정리하면서, 비용 효율적이고 유지보수 가능한 구조로 단순화하는 방법을 찾기로 했어. 복잡한 로직을 단순화하면서도, 플랫폼 제약을 우회할 수 있는 새로운 아키텍처 설계를 시도해야 했지.
A (Action)
먼저 기존 Flow 내 Action 구조를 분석하고, 불필요하게 반복되는 조건문과 배열 탐색 로직을 정리했어. 이후 Power Automate의 외부 호출 기능을 활용해, Azure Function에 Python 코드를 작성해 hash map 비교 로직을 처리하도록 설계했어. 이로써 Flow에서는 단 하나의 HTTP request Action만으로 전체 로직을 대체할 수 있었고, Python의 표준 라이브러리를 활용해 성능과 정확도도 확보할 수 있었지.
R (Result)
기존에 10개 이상의 Action으로 구성되던 Flow는 1개 Action으로 줄어들었고, 이에 따라 요금도 절감되었으며 유지보수도 쉬워졌어. 팀에서는 이 구조를 기반으로 유사한 자동화 시나리오를 설계할 때 Azure Function을 활용한 구조가 표준 패턴으로 자리잡게 되었고, 나는 이 경험을 통해 단순히 툴을 잘 쓰는 사람을 넘어서, 복잡한 구조를 기술적으로 재설계해 조직 전체의 효율성을 높인 엔지니어로 평가받았어.
Learn and Be Curious
항상 배우고, 스스로를 성장시키는 데 열정적이다.
S (Situation)
최근 ChatGPT를 포함한 AI 기술이 보안 업계에도 빠르게 침투하면서, 앞으로의 보안 엔지니어는 단순한 방어 기술만이 아니라, AI와 데이터 분석 역량을 반드시 갖춰야 한다는 위기감이 들었어. 특히 우리 회사에서도 가짜 앱이 마켓에 등록되는 일이 빈번했고, 기존 룰 기반 필터링으로는 탐지가 한계에 부딪힌 상황이었지.
T (Task)
나는 이 문제를 단순한 이슈로 넘기지 않고, AI를 직접 학습하고 실무에 적용하는 방법을 찾기 위해 작년에 UT Austin의 McCombs Business School에서 AI 응용 중심의 프로그램을 수강하기로 결정했어. 단순한 학문이 아닌, 실제 내 업무에 영향을 줄 수 있는 수준으로 활용하겠다는 게 목표였지.
A (Action)
해당 프로그램에서는 이론 외에도 hands-on 프로젝트가 포함되어 있었고, 나는 이를 활용해 Google Play 및 App Store의 앱 메타데이터를 수집/분석하는 파이프라인을 구성했어. 이후 텍스트, 로고, 앱 설명 등의 특징 벡터를 분석해 우리 회사와 유사하지만 가짜인 앱을 분류할 수 있는 간단한 모델을 개발했지. AI 탐지 모델을 기존 자동화 시스템과 연계해서, 탐지된 앱에 대해 자동으로 앱스토어 관리자에게 DMCA 관련 이메일을 발송하는 로직까지 구현했어.
R (Result)
이 시스템 도입 후, 기존 룰 기반 탐지에서는 놓치고 있던 유사 앱들을 추가로 탐지할 수 있었고, 그 중 다수에 대해 법적 조치 및 앱스토어에서 take-down 성공을 이끌어냈어. 이 덕분에 우리 회사 사용자들이 가짜 앱에 속지 않도록 보호할 수 있었고, 나는 이 경험을 통해 AI 기술을 학습하고, 실무에 연결해 회사의 실제 보안 수준을 높이는 데 기여한 엔지니어로 인정받게 되었어.
Hire and Develop the Best
자신보다 뛰어난 사람을 찾고, 그들이 성장하도록 돕는다.
S (Situation)
우리 팀에 신입 보안 엔지니어가 합류했는데, 이전에는 주로 인프라나 시스템 운영 쪽 경험만 있었고 펜테스트 경험은 전무한 상태였어. 특히 고객 리포트를 작성하거나 실제 취약점 분석을 할 때, 기술적으로 부족함을 느끼고 혼자서 고민하다가 진행 속도가 느려지고, 자신감도 잃는 상황이었지.
T (Task)
공식적인 멘토는 아니었지만, 나는 이 동료가 단순히 빠르게 따라오는 수준이 아니라, 핵심 컨트리뷰터가 될 수 있도록 실력을 끌어올리고 싶었어. 그래서 그가 우리 팀 내에서 자립할 수 있는 기술 기반과 사고방식을 갖추도록 돕는 걸 목표로 삼았지.
A (Action)
먼저 펜테스트 플로우를 단계별로 정리해서 checklist화된 onboarding 가이드를 만들었고, 특히 Burp Suite 사용법, 리포트 작성 요령, 흔히 마주치는 취약점 재현 방법 등을 직접 보여주는 짧은 실습 예제로 구성했어. 그 후 1:1 세션을 주 1회 자청해서 운영하며, 실제 프로젝트를 옆에서 같이 해보면서 분석 포인트를 설명했어. 단순히 “이건 이렇게 해”가 아니라, “왜 이 취약점은 high로 분류되는가?”, “이 payload는 어떤 상황에서 우회가 가능한가?” 같은 생각하는 법을 중심으로 설명했지. 그가 작성한 리포트를 리뷰하면서도 비판적이되 신뢰감 있는 피드백을 주려 노력했고, 반복된 실수는 가볍게 짚고, 잘한 부분은 확실하게 인정해줬어.
R (Result)
3개월이 지나자 이 동료는 단독으로 SA를 처리할 수 있게 되었고, 실제로 한 프로젝트에서는 내가 발견하지 못한 OAuth 구성상의 취약점을 새롭게 탐지해 팀에 공유하기도 했어. 그는 이후 팀 회고에서 내 피드백과 실무 가이드를 통해 보안에 대한 자신감이 생겼다고 표현했고, 매니저도 “기술력과 사람을 함께 성장시킬 수 있는 팀원”으로 나를 평가했어. 나는 이 경험을 통해 단순히 내 퍼포먼스가 아니라, 다른 사람의 성장을 끌어올리는 것이 팀 전체의 장기적 성공으로 이어진다는 걸 실천할 수 있었어.
Think Big
단기적인 개선이 아닌 장기적인 혁신을 추구한다.
S (Situation)
우리 팀은 회사의 모든 모바일 애플리케이션에 대한 보안 점검과, 3rd-party app store에서 유사 앱을 탐지해 위협을 차단하는 역할도 맡고 있어. 하지만 이 과정은 대부분 수작업으로 이루어졌고, 외부 이메일, 내부 툴, 사람 간 대화가 모두 분산되어 있었기 때문에, 평균적으로 주당 3시간 이상이 커뮤니케이션에 낭비되고 있었지.
T (Task)
나는 이 문제를 단순히 반복 작업의 효율성 차원에서 보지 않고, “이 흐름 전체를 자동화하고 시각화된 시스템으로 바꾼다면 조직 전체의 대응 속도와 전략이 달라질 수 있다”고 생각했어. 그래서 기존 방식에 의존하지 않고 새로운 파이프라인을 직접 설계하고 구축하기로 했지.
A (Action)
먼저 Power Automate Flow를 사용해 외부 이메일 트리거 기반으로 내부 시스템을 조회하고, 대응 담당자를 자동으로 찾아 프로세스를 시작하는 흐름을 구축했어. 흩어진 내부 정보들을 정규화해 통합 DB에 수집했고, 이를 기반으로 Power BI 대시보드를 제작하여 실시간 진행 상태, 탐지율, 응답시간 등을 시각화했어. 동시에, 기존에 의존하던 외부 3rd-party 탐지 솔루션을 제거하고, 내부 시스템으로 완전히 전환할 수 있도록 구조를 정리했지.
R (Result)
이 시스템 도입 이후, 기존에 3~4일 걸리던 대응 프로세스는 24시간 이내로 단축되었고, 수작업 의존도도 크게 줄어 평균 주 3시간 이상의 커뮤니케이션 시간이 절감되었어. 더 나아가, 이 시스템은 단순히 우리 팀에 국한되지 않고, 웹 펜테스트 팀에서도 채택이 논의되며 더 큰 보안 파이프라인의 일부로 발전하고 있어. 나는 이 경험을 통해 “작은 문제를 해결하는 수준”을 넘어, 조직의 보안 전략을 확장할 수 있는 시스템을 설계하고, 실행한 경험을 쌓을 수 있었어.
Frugality
제약이 혁신을 만든다고 믿고, 자원을 효율적으로 사용한다.
S (Situation)
내가 진행하던 내부 프로젝트에서는 데이터를 저장하고 연동할 수 있는 DB 시스템 선택이 필요한 상황이었어. Microsoft의 Dataverse는 기능적으로 강력하지만 유료 구독 모델이었고, 당시 회사 내부에서는 예산 절감을 위한 노력이 강하게 추진되고 있는 시점이었지.
T (Task)
나는 프로젝트의 실질적인 요구사항을 정확히 진단하고, 꼭 필요한 수준의 기능만을 확보하면서도 비용을 들이지 않는 방안을 찾아야 했어. 따라서 무료로 사용할 수 있는 Microsoft List를 활용해도 충분한지 판단하고, 비용 대비 효과가 높은 선택을 직접 입증하는 것이 내 과제였지.
A (Action)
먼저 Dataverse의 기능 목록을 기준으로, 내 프로젝트에 꼭 필요한 항목(읽기/쓰기 속도, 보안, 백업 등)을 리스트업하고 Microsoft List와 비교 분석했어. 특히 데이터 보호 측면에서 encryption, 접근 제어, 백업 주기를 Microsoft List 환경에서 구현 가능한지 추가 리서치를 수행했고, 필요 시 Power Automate와 연동해 백업 자동화나 보안 로직을 구현하는 방법도 함께 설계했어. 이 과정을 통해 List를 사용하는 것으로도 충분히 요구사항을 충족할 수 있다는 판단을 내렸고, 실제로 데이터 흐름, 보안 요구사항을 포함한 시스템을 완성했지.
R (Result)
그 결과, Dataverse에 비해 수십만 원 이상의 라이선스 비용을 절감하면서도, 프로젝트가 요구한 데이터 처리와 보안 요건을 모두 만족하는 결과를 만들 수 있었어. 또한, List 기반 구조는 가볍고 유지보수가 쉬워서, 다른 소규모 프로젝트나 MVP 개발 환경에서도 재활용 가능한 프레임워크로 확장되었지. 나는 이 경험을 통해 제약을 단점이 아니라, 시스템을 더 효율적이고 날렵하게 만드는 기회로 활용할 수 있었고, 회사 자원을 아끼는 동시에 확장성 있는 구조를 제시했다는 평가를 받았어.
Success and Scale Bring Broad Responsibility
큰 영향력을 가진 만큼, 사회적 책임도 크다는 것을 인식하고 행동한다.
S (Situation)
나는 내가 지금까지 얻은 것들—기술, 기회, 지식—모두를 혼자 힘으로 이뤘다고 생각하지 않아. 나를 믿어준 사람들, 나를 도와준 환경이 있었기에 지금의 내가 있다고 느껴. 그래서 나는 내가 가진 자원을 사회에 환원해야 한다고 생각했고, 내 역량을 진짜 필요로 하는 곳에서 쓰고 싶었어.
T (Task)
내가 잘할 수 있는 기술을 통해 실질적인 변화가 필요한 사람들을 돕고 싶었고, 그 과정에서 전기도 들어오지 않는 지역에 과학기술을 소개하며 교육하는 Mtree라는 봉사 단체에 합류하게 되었어. 단순한 후원이 아닌, 직접 현지에서 기술의 가치를 경험하게 해주는 활동에 참여하기로 결심했지.
A (Action)
나는 전기가 들어오지 않는 시골 마을에서, 드론으로 물자를 나르고, 자율주행, 무인 운송 기술 등을 실제로 보여줬어. ‘기술’이라는 개념 자체가 생소했던 아이들에게, 엔지니어란 문제를 해결하는 사람이며, 너희도 문제를 찾고 해결할 수 있다고 설명했어. 단순히 보여주는 데 그치지 않고, 그 지역의 문제를 함께 정의하고 어떻게 해결할 수 있을지를 함께 설계했어. 그들이 가진 자원으로 가능한 솔루션을 함께 고민하며, 과학적 사고방식과 실현 가능한 방법론을 교육했지.
R (Result)
그 결과, 예전엔 “군인이 되겠다”는 게 유일한 진로였던 아이들이 “엔지니어가 되고 싶다”고 말하기 시작했고, 내가 가르친 아이들 중 일부는 물 긷는 문제를 스스로 설계한 기초 도르래 장치로 해결했다고 소식을 전해줬어. 나는 이 경험을 통해, 내가 가진 기술이 단지 개인 커리어를 위한 것이 아니라, 세상에 실질적 영향을 줄 수 있다는 것, 그리고 그것이야말로 성공의 본질적 책임이라고 믿게 되었어.
Strive to be Earth’s Best Employer: 구성원이 존중받고 성장할 수 있는 최고의 직장이 되도록 노력한다. S: T: A: R:
Are Right, A Lot: 판단력이 좋고, 데이터를 근거로 자주 옳은 결정을 내린다. => L6 수준에서 많이 물어보는 LP이다.